Network Working Group M. Garcia Internet Draft Ericsson Expires: December 2002 June 2002 Private Session Initiation Protocol (SIP) extension for Called Party Identity Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This memo describes a private extension to SIP in the form of a P-Called-Party-ID header. A proxy inserts this header typically in an INVITE, en-route to its destination. The header is populated with the Request-URI received by the proxy in the request. The UAS identifies which ID out of several IDs the invitation was sent to (for example, the user may be using simultaneously a personal and a business SIP URI to receive invitation to sessions). The UAS may use the information to render different distinctive audiovisual alerting tones, depending on the ID used to receive the invitation to the session. Table of contents Network Working Group Expiration 12/04/02 [Page 1] Garcia The SIP Called Party ID header June 2002 1. Introduction......................................................2 2. Motivation and problem statement..................................2 3. Applicability statement...........................................4 4. The Called Party ID header........................................5 5. P-Called-Party-ID syntax and definition...........................5 6. Usage.............................................................5 6.1 Procedures at the UA.............................................5 6.2 Procedures at the proxy..........................................6 7. Security Considerations...........................................6 8. IANA Considerations...............................................6 9. Author's Addresses................................................7 10. Acknowledgements.................................................7 11. References.......................................................7 11.1 Normative references............................................7 11.2 Informative references..........................................7 1. Introduction The 3rd Generation Partnership Project (3GPP) has chosen SIP [1] as the signaling protocol for the IP Multimedia Subsystem (IMS). A collection of 3GPP requirements related to SIP are stated in the "3GPP requirements to SIP" [2]. Users in the 3GPP IP Multimedia Subsystem (IMS) may get one or several SIP URIs to identify the user. For instance, a user may get a business SIP URI and a personal one. As an example of utilization, the user may make available the business SIP URI to co-workers and may make available the personal SIP URI to members of the family. At a certain point in time, both the business SIP URI and the personal SIP URI are registered to the network, so both URIs can receive invitations to new sessions. When the user receives an invitation to join a session, he/she should be aware of which of the several registered SIP URIs this session was sent to. This requirement is stated in section 6.10.3 of the 3GPP requirements on SIP Internet Draft [2]. 2. Motivation and problem statement The problem arises during the terminating side of a session establishment. When the SIP server that is serving a user gets an INVITE and, the SIP sever retargets the SIP URI in the Request-URI field and replaces it by the SIP URI published by the user in the Contact header field of the REGISTER message at registration time. When the UAS receives the SIP request, it cannot determine which identity the request was sent towards. Someone can argue that the To header field conveys the semantics of the called user, and therefore, this extension is not needed. Although the To header field in SIP may convey the called party ID in most Network Working Group Expiration 12/04/02 [Page 2] Garcia The SIP Called Party ID header June 2002 situations, there are two particular cases when the above assumption is not correct: 1. The session has been forwarded, redirected, etc. by previous SIP entities, before arriving to the called user's proxy. 2. The UAC builds an INVITE request and the the To header field is not the same as the Request-URI. The problem of using the To header field is that this field is populated by the UAC and not modified by proxies in the path. If the UAC, for any reason, did not populate the To header field with the SIP URI of the destination user, then the destination user is not able to distinguish which ID the session is intended to be received. Another possible solution to the problem is built upon the differentiation of the Contact header value between different URIs at registration time. The UA can differentiate each identity it registers by assigning a different Contact header value. For instance, when the UA registers sip:id1, the Contact value can be sip:id1@ua1; the registration of sip:id2 can be bound to the Contact value siP:id2@ua2. The solution described above assumes that the UA explicitly registers each of his address-of-record URIs, and therefore, it has full control over the contact address values assigned to each registration. However, in the case the UA does not have full control of his address- of-record URIs registered, because of, e.g., a 3rd party registration, the solution does not work. This is the case of the 3GPP registration, where the UA may have previously indicated to the network, by means outside SIP, that some other address-of-record URIs may be automatically registered when the UA registers a particular address- of-record URI. The requirement is covered in section 6.10.2.2 of the 3GPP requirements on SIP [2]. In the next paragraphs we show an example of the problem, in the case there has been some sort of call forwarding in the session, so that the UAC is not aware of the intended destination URI in the current INVITE. Example of the current behavior: a user registers his business URI to his/her registrar. F1 Register UA -> P1 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: sip:user1-business@example.com From: sip:user1-business@example.com;tag=456248 Call-ID: 843817637684230998sdasdh09 CSeq: 1826 REGISTER Contact: The user also registers his personal URI to his/her registrar. Network Working Group Expiration 12/04/02 [Page 3] Garcia The SIP Called Party ID header June 2002 F2 Register UA -> P1 REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashdt8 To: sip:user1-personal@example.com From: sip:user1-personal@example.com;tag=346249 Call-ID: 2Q3817637684230998sdasdh10 CSeq: 1827 REGISTER Contact: Later, the proxy/registrar receives an INVITE destined to the user's business SIP URI. We assume that this SIP INVITE has undergone some sort of forwarding in the past, and as such, the To header field is not populated with the SIP URI of the user. In this case, we assume that the session was initiated to sip:other-user@othernetwork.com, who has forwarded this session to sip:user1-business@example.com F3 INVITE P2 -> P1 INVITE sip:user1-business@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1 To: sip:other-user@othernetwork.com From: sip:another-user@anothernetwork.com;tag=938s0 Call-ID: 843817637684230998sdasdh09 CSeq: 101 INVITE The proxy P1 retargets the user and replaces the Request-URI by the SIP URI published during registration time in the Contact header value. F4 INVITE P1 -> UA INVITE sip:user1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bKg48sh128 Via: SIP/2.0/UDP 192.0.2.20:5060;branch=z9hG4bK03djaoe1 To: sip:other-user@othernetwork.com From: sip:another-user@anothernetwork.com;tag=938s0 Call-ID: 843817637684230998sdasdh09 CSeq: 101 INVITE When the UAS receives the INVITE, it cannot determine whether it got the session invitation due to his registration of the business or the personal ID. Neither the UAS, nor proxies or application servers can provide this user a service based on the destination of the session. We solve this problem by allowing the proxy that is responsible for the home domain (as defined in RFC 3261 [1]) of the user to insert a P-Called-Party-ID header that identifies the URI to which this session is destined. 3. Applicability statement The P-Called-Party-ID is applicable when the UAS needs to be aware of the intended address-of-record in the request, before the proxy retargeted to the contact address. The UAS may be interested in Network Working Group Expiration 12/04/02 [Page 4] Garcia The SIP Called Party ID header June 2002 applying different audiovisual alerting effects or other filtering services, depending on the intended destination of the request. It is specially valuable when the UAS has registered several address-of- record URIs to his registrar, and therefore, is not aware of the address-of-record that hit his proxy/registrar unless this extension is used. 4. The Called Party ID header The P-Called-Party-ID header field provides the UAS with the URI the request was addressed to, before a proxy retargeted the request. This information is intended to be used by subsequent proxies in the path or by the destination UAS. Typically, a SIP proxy, inserts the P-Called-Party-ID header field when it retargets the user by replacing the Request-URI with the address-of-record. The P-Called-Party-ID header value is populated with the contents of the Request-URI in the INVITE, any other method that initiates a dialog or any other standalone request outside a dialog (such as MESSAGE [8]). This extension MUST NOT be used in REGISTER request. 5. P-Called-Party-ID syntax and definition The P-Called-Party-ID is an extension to SIP in the form of a SIP header. The syntax of the P-Called-Party-ID header is based on the ABNF of SIP [1] and its syntax is described as follows: P-Called-Party-ID = "P-Called-Party-ID" HCOLON called-pty-id-spec called-pty-id-spec = addr-spec The allowable usage of headers is described in Table 2 of SIP [1]. Addition of P-Called-Party-ID to the Table 2 in SIP [1], section 4.1 of the SIP-specific event notification [4], tables 1 and 2 in the SIP INFO method [5], tables 1 and 2 in Reliability of provisional responses in SIP [6], tables 1 and 2 in the SIP UPDATE method [7], tables 1 and 2 in the SIP extension for Instant Messaging [8] and table 1 in the SIP REFER method [9]: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Called-Party-ID R amr - - - o o - Header field SUB NOT PRA INF UPD MES REF _______________________________________________________________ P-Called-Party-ID o - - - - o o 6. Usage 6.1 Procedures at the UA Network Working Group Expiration 12/04/02 [Page 5] Garcia The SIP Called Party ID header June 2002 A UAC SHOULD NOT insert a P-Called-Party-ID header field in any SIP request or response. A UAS may receive a P-Called-Party-ID header field. The header is populated with the URI that the request was intended for. The UAS may use the value in the P-Called-Party-ID header field to provide services based on the destination of the called party, such as filtering of calls depending on the date and time, distinctive presentation services, distinctive alerting tones, etc. 6.2 Procedures at the proxy A proxy that has authoritative information about the user, may insert a P-Called-Party-ID header field in an INVITE, any other request that initiates a dialog or any other standalone request outside a dialog (such as MESSAGE [8]) except REGISTER. The header is typically populated with the contents of the Request-URI in the SIP request that the proxy received. It is necessary that the proxy which inserts the P-Called-Party-ID header have information about the user, in order to prevent a wrong delivery of the called party ID. This information may have been learnt through a registration process, for instance. A proxy or application server that receives a request containing a P- Called-Party-ID header may use the contents of the header to provide a service to the user based on the URI of that header value. 7. Security Considerations Due to the nature of the header this extension does not introduce any security concern. It is possible for an attacker to modify the contents of the header. However, this modification will not cause any harm to the session establishment. An eavesdropper may collect the list identities a user is registered. This may have privacy implications. To mitigate this problem, it is RECOMMENDED that this extension is used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop- by-hop. 8. IANA Considerations This document defines the SIP extension header "P-Called-Party-ID" which should be included in the registry of SIP headers defined in SIP [1]. As required by the SIP change process [3] the SIP extension header name "Called-Party-ID" should also be registered in association with this extension. Network Working Group Expiration 12/04/02 [Page 6] Garcia The SIP Called Party ID header June 2002 The following is the registration for the P-Called-Party-ID header field: RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: P-Called-Party-ID Compact Form: none The following is the registration for the Called-Party-ID header field: RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] (not yet specified, only reserved) Header Field Name: Called-Party-ID Compact Form: none 9. Author's Addresses Miguel A. Garcia Ericsson FIN-02420, Jorvas, Finland Tel: +358 9299 3553 e-mail: miguel.a.garcia@ericsson.com 10. Acknowledgements The author would like to thank Andrew Allen, Gabor Bajko, Gonzalo Camarillo, Keith Drage, Georg Mayer, Dean Willis, Rohan Mahy, Ya-Ching Tan and the 3GPP CN1 Working Group members for their valuable comments on this document. 11. References 11.1 Normative references 1. J. Rosenberg, H. Schulzrinne, G. Camarillo et al, Session Initiation Protocol, RFC 3261, March 2002. 11.2 Informative references 2. M. Garcia et al, 3GPP requirements on SIP, draft-garcia-sipping- 3gpp-reqs-03.txt, Marcg 2002,work in progress. 3. S. Bradner, R. Mahy, A. Mankin, J. Ott, B. Rosen, D. Willis, SIP change process, draft-tsvarea-sipchange-01.txt, February 2002, work in progress. 4. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002. 5. S. Donovan, The SIP INFO method, RFC 2976, October 2000. Network Working Group Expiration 12/04/02 [Page 7] Garcia The SIP Called Party ID header June 2002 6. J. Rosenberg, H. Schulzrinne, Reliability of Provisional Responses in SIP, RFC 3262, March 2002. 7. J. Rosenberg, The Session Initiation Protocol UPDATE Method, draft-ietf-sip-update-02.txt, April 2002, work in progress. 8. B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, Session Initiation Protocol Extension for Instant Messaging, draft-ietf-sip-message-04.txt, May 2002, work in progress. 9. R. Sparks, The REFER method, draft-ietf-sip-refer-04.txt, May 2002, work in progress. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Expiration Date This memo is filed as and expires December 4, 2002. Network Working Group Expiration 12/04/02 [Page 8]