Internet DRAFT - draft-rocky-sipping-calling-party-category
draft-rocky-sipping-calling-party-category
SIPPING WG Rocky Wang, Ed.
Internet Draft Youzhu Shi
Expires: April 23, 2006 Huawei Technologies
October 21, 2005
A header to deliver the calling party category
draft-rocky-sipping-calling-party-category-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
SS7 ISUP [3] defines a Calling Party's Category (CPC) parameter that
characterizes the station used to originate a call and carries other
important state that can describe the originating party. Based on the
CPC parameter from the calling network, the called network can do
some special processes related to the calling party category, just
like override the calee's DND and some other barring services.
Rocky Expires - April 2006 [Page 1]
Internet-Draft Calling party category in SIP October 2005
This document specifies a way to deliver the calling party category
to implement some supplementary services derived from the PSTN
network.
Table of Contents
1. Introduction...................................................2
2. Conventions....................................................3
3. The P-CPC header field.........................................3
4. Usage..........................................................4
5. Security Considerations........................................6
6. IANA Considerations............................................6
7. References.....................................................6
7.1 Normative References........................................6
7.2 Informational References....................................6
Acknowledgment....................................................7
Author's Address..................................................7
Intellectual Property Statement...................................7
Disclaimer of Validity............................................8
Copyright Statement...............................................8
1. I
ntroduction
The Do Not Disturb (DND) supplementary service allows the served user
to instruct the network to automatically reject incoming calls
because he does not want to be disturbed.
The Anonymous Call Rejection (ACR) supplementary service allows the
served user to reject incoming calls from users or subscribers who
have restricted the presentation of their calling party identifier.
DND and ACR are popular supplementary services in the public switch
telephone network (PSTN) and have already been used by a great number
of subscribers.
But there are some provisions for exceptional cases that the calling
party should have the opportunity to override the DND or ACR service
to reach the called party even though the services are activated and
the service-specific conditions are met. For an instance, a call from
a police station, emergency call center or from an operator who has
the rights to override the served user's services.
SS7 ISUP [3] defines a Calling Party's Category (CPC) parameter that
characterizes the station used to originate a call and carries other
important state that can describe the originating party. Based on the
CPC parameter from the calling network, the called network can do
some special processes related to the calling party category, just
like the cases described above.
Rocky Expires - April 2006 [Page 2]
Internet-Draft Calling party category in SIP October 2005
This document defines a new header to deliver the calling party
category.
The draft [8] defines a URI parameter, "cpc", to deliver the CPC
parameter. But the calling party category is always required to be
considered as a part of the caller's profile or subscription. That
is, the calling network must know the detail of it and it must be
asserted by the network if it is provided by the calling party
station. So, it is better that only the network equipments add,
remove or read and process it, and in this case it is better to
deliver such a parameter by a separated header field.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [4].
3. The P-CPC header field
The P-CPC header field MAY appear in any request out of a dialog.
The syntax of the header field follows the standard SIP header syntax.
P-CPC = "P-CPC" HCOLON cpc-value
*( SEMI cpc-param )
cpc-value = "ordinary" / "operator" / "test" / "payphone" /
"prison" / "hotel" / "hospital" / "police" /
"cellular" / "cellular-roaming" / "freecharge" /
"data" / "unknown" / token
cpc-param = cpc-pname [ "=" cpc-pvalue ]
cpc-pname = 1*paramchar
cpc-pvalue = 1*paramchar
The "paramchar" is defined in RFC3261 [1].
The semantics of these Calling Party Category values are described
below:
ordinary: The caller has been identified, and has no special
features.
operator: The call was generated by an operator position.
test: This is a test call that has been originated as part of a
maintenance procedure.
payphone: The calling station is a payphone.
prison: The calling station is in a prison.
hotel: The calling station is in a hotel or motel.
hospital: The calling station is in a medical facility.
police: The calling station is associated with a branch of law
enforcement.
cellular: The calling station is a radio-telephone operating in
Rocky Expires - April 2006 [Page 3]
Internet-Draft Calling party category in SIP October 2005
its home network.
cellular-roaming: The calling station is a radio-telephone roaming
in another network
freecharge: The caller is a free-charge subscriber.
data: The calling station is a data station.
unknown: The CPC could not be ascertained.
To enables the network received the P-CPC header do some special
process based on the calling party category, the P-CPC header is
should only appear in the request message out of a dialog.
4. Usage
-------- ******************* --------
| LEC1 | *** *** | LEC2 |
-------- * * --------
\ * ------- * /
\SS7 * |proxy| * /SS7
\ * ------- * /
\|---| |---|/
|NS1| VoIP Network |NS2|\
/|---| |---| \
SIP/ * * \SIP
/ * ------- * \
/ * |proxy| * \
------- * ------- * --------
| UE1 | ** ** | LEC2 |
------- ******************** --------
Figure 1: Motivation for SIP-T in ISUP-SIP interconnection
In Figure 1 a VoIP cloud serves as a transit network for telephone
calls, where SIP is employed as the VoIP protocol used to set up and
tear down these VoIP calls. For the convenience of description, we
suppose there is a call from the left side to the right side and NS1,
NS2 will be calling and called network server separately. The call
can be originating from Local Exchange Carriera (LEC1) or from a SIP
user endpoint (UE1). In both of the cases, the NS1 will route the
call to the called network on behalf of the caller and it will be as
an interworking unit to complete the conversion between SS7 signals
and SIP messages, and a proxy server to transfer the request on
behalf of the user. After the request traverses a set of intermediary
network entities and reaches NS2, NS2 will route the call to LEC2 as
an interworking unit or transfer the request to the callee endpoint
as a proxy.
If the call initiates from UE1, a SIP user endpoint, UE1 SHOULD NOT
add the CPC information into the outgoing request message because the
CPC is always related to the caller service profile or subscription.
Rocky Expires - April 2006 [Page 4]
Internet-Draft Calling party category in SIP October 2005
NS1 SHOULD add a P-CPC header into the initial request message
towards to the called network. Ther are 2 cases below:
If the call is from LEC1, NS1, as an interworking unit, should map
the received CPC information from LEC1 into the P-CPC header of the
initial request.
If the call is from UE1, it should map the subscriber category into
the P-CPC header of the initial request. In this case, NS1 can get
the calling subscriber category from the subscriber service profile
or his subscription which can be stored locally or a separated
database server. If the request is from UE1 and have already taken a
P-CPC header, NS1 must overwrite the header with the subscriber
category value from the database in the network before do any process
related to the CPC information or transfer it towards to the callee.
The intermediary network entities between NS1 and NS2 should transfer
the P-CPC header without change. When it needs, any intermediary
network entity can read and process it.
When NS2 receives this request, it can do some special processing
related to the CPC information, for example implementing the DND and
ACR override by the caller if his category is "police".
If the callee is a SIP subscriber, before routes the request to US2,
NS2 SHOULD remove P-CPC header from the request to ensure not
transfer this information to the called endpoint because the calling
party category information is sensitive under many circumstances.
If the intermediary network entities or NS2 receives a request
without P-CPC header, but it requires the calling party category, it
can simply reject the call directly. As an alternative solution, the
entity can also do the process as if the request takes a P-CPC header
and the value is "ordinary", but in this case it should not add a P-
CPC header into the message transferring out.
Also because the calling party category is sensitive under many
circumstances, when NS1 or the intermediary network entity sends
request message out and if the next hop is not trusted, it should
remove the P-CPC header from the outgoing request.
The P-CPC header defined here can be taken by any initial request
message out of a dialog for any type of communication, including
MESSAGE. But typically, it will be used for phone call and
interworking between SIP and PSTN networks. If it is needed, it can
also used by some other cases.
Rocky Expires - April 2006 [Page 5]
Internet-Draft Calling party category in SIP October 2005
5. Security Considerations
The information contained in the P-CPC header may be of a private
nature, and it may not be appropriate for this value to be revealed
to the destination user (typically it would not be so revealed in the
PSTN). To reach this, before sending the request to the called party
endpoint, the server, any logical entity it is, should remove this
header and maybe some other sensitive information also.
Otherwise, this mechanism adds no new security considerations to
those discussed in [1].
6. IANA Considerations
This extension defines a new header field:
Name of Header: P-CPC
Short form: none
Normative description: section 3 of this document
7. References
7.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] International Telecommunications Union, "Recommendation Q.763:
Signalling System No. 7: ISDN user part formats and codes",
December 1999, <http://www.itu.int>.
[4] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2 Informational References
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[6] American National Standards Institute, "ANSI T1.113-2000,
Signaling System No. 7, ISDN User Part", 2000,
<http://www.ansi.org>.
[7] ETSI, "Services and Protocols for Advanced Networks (SPAN);
Anonymous Call Rejection (ACR) Supplementary Service; Service
description", ETSI EN 301 798 v1.1.1, October 2000, <http://
Rocky Expires - April 2006 [Page 6]
Internet-Draft Calling party category in SIP October 2005
webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=6618>.
[8] Rohan Mahy, "The Calling Party's Category tel URI Parameter",
draft-mahy-iptel-cpc-02 (work in progress), February 21, 2005.
Acknowledgment
We would like to thank Rohan Mahy for his draft giveing us some idea
to resolve the problem under some circumstances.
We also thank Peili Xu, Smile Wang, Qing Zhou, Mukund and Prasanna
for providing useful comments.
Author's Address
Rocky Wang (Editor)
Huawei Technologies Co., Ltd.
Huadian Building,
Bantian, Longgang District,
Shenzhen 518129
P.R.C.
EMail: rocky.wang@huawei.com
Youzhu Shi
Huawei Technologies Co., Ltd.
Huadian Building,
Bantian, Longgang District,
Shenzhen 518129
P.R.C.
EMail: cainong@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
Rocky Expires - April 2006 [Page 7]
Internet-Draft Calling party category in SIP October 2005
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Rocky Expires - April 2006 [Page 8]
