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, . [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, . [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, . [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]