Dispatch Working Group N. Bishai Internet-Draft S. Loreto Intended status: Standards Track Ericsson Expires: April 15, 2010 A. Haruna Nokia Oct 12, 2009 Updates to Referred-By in the Session Initiation Protocol (SIP). draft-loreto-dispatch-3892bis-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract SIP Referred-By header field conveys the referrer identity of a Bishai, et al. Expires April 15, 2010 [Page 1] Internet-Draft Updates to Referred-By SIP header Oct 2009 request. This header field may be used when exploding a SIP MESSAGE or a SIP INVITE request to a pre-defined group URI and the P-Asserted-Identity header field or From header field in the exploded SIP requests needs to carry another value (e.g. the URI of a pre- defined group, or a conference focus URI). In those cases, the Referred-By header field in the resulting exploded requests is set to the P-Asserted-Identity or to the From header field value of the original SIP request received before exploding, so as to convey to the receiver the identity of the original inviting sender. RFC 3892 restricts the value of the header to only one SIP URI. However the P-Asserted-Identity header field currently allows two URI values and may be expanded in the future to carry more than two values as described in draft-ietf-sipping-update-pai-09. This document extends the Referred-By definition to support more than one value as well. Bishai, et al. Expires April 15, 2010 [Page 2] Internet-Draft Updates to Referred-By SIP header Oct 2009 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Inclusion of URIs in a Referred-By header . . . . . . . . . . 5 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Referrer Behaviour . . . . . . . . . . . . . . . . . . . . 5 4.2. General handling . . . . . . . . . . . . . . . . . . . . . 5 5. The Referred-By Header Field . . . . . . . . . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informational References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Bishai, et al. Expires April 15, 2010 [Page 3] Internet-Draft Updates to Referred-By SIP header Oct 2009 1. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 2. Introduction SIP has a mechanism for conveying the identity of the referrer of a request by means of the Referred-By header field [RFC3892]. This header field may be used when exploding a SIP MESSAGE request to a pre-defined group URI and when exploding a SIP INVITE request to an ad-hoc group or to a pre-defined group URI. The Referred-By header is only included if the P-Asserted-Identity header field [RFC3325] or From header field needs to carry another value (e.g. the URI of a pre-defined group, or a conference focus URI, in the exploded SIP requests). In those cases, the Referred-By header field in the resulting exploded requests is set to the P-Asserted-Identity header field or to the From header field of the original SIP request received before exploding so as to convey to the receiver the identity of the original inviting sender. However, [RFC3892] restricts the value of the header to only one SIP URI. Since RFC 3325 allows the P-Asserted-Identity header field to contain at most two URIs, where one is SIP or SIPS URI [RFC3261] and the other is a TEL URI [RFC3966], and moreover [I-D.ietf-sipping-update-pai] provides forwards compatibility by mandating tolerance to the receipt of unexpected URIs, then the Referred-By definition in [RFC3892] needs to be extended to contain more than one URI value as well. The TEL URI in the Referred-By is needed in specific cases: o When the message is interworked to a legacy service that does not support the SIP URI and a reply address is needed in that legacy service format. For instance if an Instant Message is sent through an interworking function to an SMS user then the sender's TEL URI can be translated into an MSISDN in the interworking function and sent as the sender address in the SMS message. The SMS user is then able to use this address to send replies to the sender. Because it is not possible to predict ahead of time if the message will be interworked or not, there is a need to have always both the SIP URI and the TEL URI Bishai, et al. Expires April 15, 2010 [Page 4] Internet-Draft Updates to Referred-By SIP header Oct 2009 o Usually clients, in order to be able to display the name or identity of the calling party, need the TEL URI. In fact most of the addresses stored in the client's contact list are based on phone numbers. So the client uses the TEL URI to find the person's name in the contact list and displays the name along with the TEL URI. This document extends [RFC3892] by allowing all values of the P-Asserted-Identity header field to be carried in the Referred-By header field. 3. Inclusion of URIs in a Referred-By header [RFC3892] does not allow more than one URI in the Referred-By header. However, if the contents of the Referred-By header come from a P-Asserted-Identity header field, then all of the URIs present in the P-Asserted-Identity header field should be copied into the Referred-By header field. 4. Behaviour This document updates [RFC3892] by allowing a Referred-By header to contain two or more URIs as defined for P-Asserted-Identity header field in [I-D.ietf-sipping-update-pai]. 4.1. Referrer Behaviour A server can generate a SIP Request because of exploder functionality for SIP MESSAGE sent to a pre-defined group URI or for SIP INVITE sent to an ad-hoc group or to a pre-defined group URI. In this particular case the server MAY include in the request a Referred-By header field to report the identity of the user on behalf of which the server is acting and whose identity the server is in a position to assert, copying all of the URIs present in the P-Asserted-Identity header field. A server SHOULD do so only in cases where it can expect to be trusted by the first proxy. If Privacy was requested then there will only be one URI in the Referred-By header containing an anonymous URI. 4.2. General handling If a server generates a SIP Request because of exploder functionality for a request containing a P-Asserted-Identity header field that carries an unexpected number of URIs or unexpected URI schemes it MUST act as specified in Section 4.5 of Bishai, et al. Expires April 15, 2010 [Page 5] Internet-Draft Updates to Referred-By SIP header Oct 2009 [I-D.ietf-sipping-update-pai]. 5. The Referred-By Header Field The BNF in [RFC3892] is augmented from this: Referred-By = ("Referred-By" / "b") HCOLON referrer-uri *( SEMI (referredby-id-param / generic-param) ) referrer-uri = ( name-addr / addr-spec ) to this: Referred-By = ("Referred-By" / "b") HCOLON referrer-uri ( SEMI (referredby-id-param / generic-param) ) *(COMMA referrer-uri *( SEMI (referredby-id-param / generic-param) )) referrer-uri = ( name-addr / addr-spec ) A Referred-By header field value MUST consist of exactly one name- addr or addr-spec. There may be one or two Referred-By values. If there is one value, it MUST be a sip, sips, or tel URI. If there are two values, one value MUST be a sip or sips URI and the other MUST be a tel URI. 6. Examples Figure 1 shows an example of a server acting as conference server. In this case a User (User1) sends an INVITE request F1 that contains an SDP body to a pre-defined group with identity sip: pre-definedgroup@example.com . The group has members User1, User2 , User3 and User4. The server answers with a 200 (OK) response and generates an INVITE request to each of the remaining members of the group identified by the URIs corresponding to each user in the group membership document. The conference server includes SDP and a Refer-by header including all the values received in the initial request from User1 in each of the outgoing INVITE requests. Note that these examples consist of partial SIP messages that illustrate only the relevant headers. Bishai, et al. Expires April 15, 2010 [Page 6] Internet-Draft Updates to Referred-By SIP header Oct 2009 +--------+ +---------+ +--------+ +--------+ +--------+ |User1 | | Server | | User2 | | User3 | | User4 | | | | | | | | | | | +--------+ +---------+ +--------+ +--------+ +--------+ | | | | | | F1 INVITE | | | | | ---------------->| | | | | F2 200 OK | | | | |<---------------- | F3 INVITE | | | | | ------------->| | | | | F4 INVITE | | | | | ------------------------>| | | | F5 INVITE | | | | | ----------------------------------->| | | F6 200 OK | | | | |<------------- | | | | | F7 200 OK | | | | |<------------------------ | | | | F8 200 OK | | | | |<----------------------------------- | | | | | | | | | | | | | | | | Figure 1: Flow diagram Figure 2 shows an example of the INVITE request F1 sent to a pre- defined group, which carrries an application/sdp body that describes the session to be set up. Bishai, et al. Expires April 15, 2010 [Page 7] Internet-Draft Updates to Referred-By SIP header Oct 2009 INVITE sip: pre-definedgroup@example.com SIP/2.0 Via: SIP/2.0/TCP atlanta.example.com ;branch=z9hG4bKhjhs8axs83 Max-Forwards: 70 To: "My Team" < sip: pre-definedgroup@example.com > From: User1 ;tag=32431 Call-ID: d432fa84b4c76e65710 CSeq: 1 INVITE Contact: Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog Content-Type: application/sdp Content-Length:(appropriate value) v=0 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000 Figure 2: INVITE request sent to the pre-defined group Figure 3 shows an example of the INVITE request F1 received at the server within a SIP trusted domain. The SIP proxy creates and inserts the P-asserted identity from the identities of the user according to [RFC 3892] and forwards it to the Server. Bishai, et al. Expires April 15, 2010 [Page 8] Internet-Draft Updates to Referred-By SIP header Oct 2009 INVITE sip: pre-definedgroup@example.com SIP/2.0 Via: SIP/2.0/TCP atlanta.example.com ;branch=z9hG4bKhjhs8axs83 Max-Forwards: 70 To: "My Team" < sip: pre-definedgroup@example.com > From: User1 ;tag=32431 Call-ID: d432fa84b4c76e65710 CSeq: 2 INVITE P-Asserted-Identity: "User1" P-Asserted-Identity: tel: +358504834400 Contact: Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog Content-Type: application/sdp Content-Length:(appropriate value) v=0 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000 Figure 3: INVITE request received at the pre-defind group The out-going INVITE requests F3, F4, and F5 sent out by the server (pre-defined group) to the members of the group are the same. All those INVITE requests includes a Refer-By header field containing the values of all the asserted identities in the initial INVITE request F1 received by the server. The out-going INVITE requests also contain application/sdp body that describes the session to be set up. Figure 4 shows an example of the message F3. Bishai, et al. Expires April 15, 2010 [Page 9] Internet-Draft Updates to Referred-By SIP header Oct 2009 INVITE sip:User2@example.com SIP/2.0 Via: SIP/2.0/TCP Groups.example.com ; Branch=z9hG4bKhjhs8as454 Max-Forwards: 70 To: From: "My Team" < sip: pre-definedgroup@example.com >; tag=234332 Call-ID: 389sn189dasdf CSeq: 1 INVITE Contact: < sip: pre-definedgroup@Groups.example.com>;isfocus Referred-By: < sip:user1@example.com >, ;cid="20498723.2UWQHN307yhb3@ atlanta.example.com" Allow: INVITE, ACK, CANCEL, BYE, REFER Allow-Events: dialog, conference Content-Type: application/sdp Content-Length: (appropriate value) v=0 o=conf 2890844343 2890844343 IN IP4 conference.example.com s=- c=IN IP4 192.0.2.5 t=0 0 m=audio 40000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 40002 RTP/AVP 31 a=rtpmap:31 H261/90000 Figure 4 7. IANA Considerations This document requires no IANA actions. 8. Security considerations The use of the Referred-By header raises a number of security considerations, which are discussed fully in [RFC3892]. This document raises no additional security considerations. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Bishai, et al. Expires April 15, 2010 [Page 10] Internet-Draft Updates to Referred-By SIP header Oct 2009 [RFC3261] 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. [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informational References [I-D.ietf-sipping-update-pai] Elwell, J., "Updates to Asserted Identity in the Session Initiation Protocol (SIP)", draft-ietf-sipping-update-pai-09 (work in progress), January 2009. Authors' Addresses Nadia Bishai Ericsson 8500 Decarie Blvd. Montreal H4P-2N2 Canada Email: nadia.bishai@ericsson.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Bishai, et al. Expires April 15, 2010 [Page 11] Internet-Draft Updates to Referred-By SIP header Oct 2009 Adamu Haruna Nokia Finland Email: adamu.haruna@nokia.com Bishai, et al. Expires April 15, 2010 [Page 12]