Network Working Group M. Garcia Internet Draft Ericsson Expires: October 2002 April 2002 Private 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. The home serving proxy inserts this header typically in an INVITE, en-route to its destination. The header is populated with the 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 10/30/02 Page 1 Garcia The SIP Called Party ID header April 2002 1. Introduction......................................................2 2. Motivation and problem statement..................................2 3. Applicability statement...........................................4 4. The Called Party ID header........................................4 5. P-Called-Party-ID syntax and definition...........................4 6. Usage.............................................................5 6.1 Procedures at the UA.............................................5 6.2 Procedures at the proxy..........................................5 7. Security Considerations...........................................5 8. IANA Considerations...............................................5 9. Author's Addresses................................................6 10. Acknowledgements.................................................6 11. References.......................................................6 11.1 Normative references............................................6 11.2 Informative references..........................................6 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" [3]. 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 [3]. 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 modifies 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. 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 situations, there are two particular cases when the above assumption is not correct: Network Working Group Expiration 10/30/02 Page 2 Garcia The SIP Called Party ID header April 2002 1. The session has been forwarded, redirected, etc by previous SIP entities, before arriving to the called user's proxy. 2. 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, didn't 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. In the next paragraphs we show an example of the current behavior, in the case there has been some sort of call forwarding in the session, so that the UAC is not aware of the terminating ID of the current INVITE. Example of the current behavior: a user registers his business ID 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: A user also registers his personal ID to his/her registrar. 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 suffered 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=03djaoe1 To: sip:other-user@othernetwork.com From: sip:another-user@anothernetwork.com;tag=938s0 Call-ID: 843817637684230@998sdasdh09 Network Working Group Expiration 10/30/02 Page 3 Garcia The SIP Called Party ID header April 2002 CSeq: 101 INVITE The proxy P1 replaces the Request-URI by the SIP URI published during registration time in the Contact. 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=g48sh128 Via: SIP/2.0/UDP 192.0.2.20:5060;branch=03djaoe1 To: sip:other-user@othernetwork.com From: sip:another-user@anothernetwork.com;tag=938s0 Call-ID: 843817637684230@998sdasdh09 CSeq: 101 INVITE When the UA gets the INVITE, it cannot determine whether it got the session invitation due to his registration of the business or the personal ID. Neither the UA, 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 serving the user to insert a P-Called-Party-ID that identifies the ID to which this session is destined. 3. Applicability statement The P-Called-Party-ID header is applicable whenever the following circumstances are met: 1. The UA registers to his home proxy with one or more SIP URIs. 2. The home proxy receives an INVITE destined to a user's ID. 4. The Called Party ID header The P-Called-Party-ID header field provides the URI the request was addressed to. This information is intended to be used by subsequent proxies in the path or by the destination UAS. Typically, a SIP home proxy, inserts the P-Called-Party-ID header field with the contents of the SIP URI received in the Request-URI of the INVITE or any other standalone method or method that initiates a dialog. 5. P-Called-Party-ID syntax and definition The P-Called-Party-ID is an extension 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 *(SEMI called-pty-id-param) called-pty-id-param = generic-param Network Working Group Expiration 10/30/02 Page 4 Garcia The SIP Called Party ID header April 2002 The allowable usage of headers is described in Table 2 of SIP [1]. The following additions to this table are needed for the P-Called-Party- ID. Addition of P-Called-Party-ID to the Table 2 in SIP [1] and section 4.1 of the SIP-specific event notification [2]: Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT _____________________________________________________________________ P-Called-Party-ID R amr - - - o o - - o - 6. Usage 6.1 Procedures at the UA A UAC should not insert a P-Called-Party-ID header field. A UAS MAY receive a P-Called-Party-ID header field. The header is populated with the URI that the session was received to. The UAS may use the information 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 is located in a home network and has authoritative information about the user, may insert a P-Called-Party-ID header field in an INVITE or any other standalone request or other request that initiates a dialog. The header is typically populated with the contents Request-URI in the SIP request that the proxy received. It is necessary that the proxy who inserts the P-Called-Party-ID header have information about the user, in order to not allow 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 that contains 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 field. 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. 8. IANA Considerations Network Working Group Expiration 10/30/02 Page 5 Garcia The SIP Called Party ID header April 2002 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 [4] the SIP extension header name "Called-Party-ID" should also be registered in association with this extension. 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 and the 3GPP CN1 WG members for the 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. 2. A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002. 11.2 Informative references 3. M. Garcia et al, 3GPP requirements on SIP, draft-sipping-garcia- 3gpp-reqs-03.txt, work in progress. 4. 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. Network Working Group Expiration 10/30/02 Page 6