Internet Draft E. Henrikson Document: draft-henrikson-sip-original-dialog-id-02 Lucent Expires: November 2002 Technologies Category: Informational May 2002 Private SIP Extension for Original Dialog Identifier draft-henrikson-sip-original-dialog-id-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This memo describes a private extension to SIP in the form of a P-Original-Dialog-ID header. The header is used to correlate two different dialogs across a B2BUA that is non-transparent to dialogs. The contents of the header identify the original dialog (Call-id, From tag, To tag) associated with the SIP entity that inserted the header into a request. When the same instance of the header is received at that SIP entity in a different request, then it is used to correlate the two different dialogs. Table of Contents 1. Background....................................................2 2. Discussion of Mechanism.......................................3 3. Applicability Statement.......................................4 4. P-Original-Dialog-ID syntax and definition....................4 5. Usage.........................................................5 5.1 Procedures at the UA......................................5 5.2 Procedures at the Proxy...................................5 Henrikson Expires - November 2002 [Page 1] Private SIP Extension for Original Dialog Identifier May 2002 5.3 Procedures at the Back to Back UA.........................6 5.4 Examples of Usage.........................................6 6. Security Considerations.......................................8 7. IANA Considerations...........................................8 8. Normative References..........................................8 9. Non-Normative References......................................8 Author's Addresses...............................................9 1. Background Third Generation Partnership Project (3GPP) has selected SIP [1] as the protocol to establish and tear down multimedia sessions in the IP Multimedia Subsystem (IMS). A description of the IMS can be found in 3GPP TS 23.228 [5] and 3GPP TS 24.229 [7]. 3GPP has defined a mechanism by which a stateful proxy (which has additional functions) needs to associate an INVITE request processed earlier with the INVITE request that is being currently processed. The association is needed by the Serving Call Session Control Function (S-CSCF) from the 3GPP architecture to ensure proper routing of an INVITE request with 3GPP Application Servers (AS). A S-CSCF may be required to route an INVITE request to multiple AS in a particular order, as indicated by subscriber profile data, and each AS may be a B2BUA. The S-CSCF needs to keep track of each AS contacted and know that an incoming INVITE request is related to a previous outgoing INVITE request such that each AS may receive the INVITE request before it is sent on towards the intended destination. Also, there is a need for the S-CSCF to associated the different but related dialogs for charging purposes. When a B2BUA AS is involved, there is currently not a way to associate the incoming INVITE request with the previously sent INVITE request at the S-CSCF. The S-CSCF is a SIP proxy with additional functionality as defined in draft-garcia-sipping-3gpp-reqs [3], 3GPP TS 23.218 [6] and 3GPP TS 24.229 [7]. The S-CSCF contacts multiple Application Servers (AS) in a particular order when certain SIP events occur, e.g. receiving an INVITE request. These events are also known as Service Points of Interest (SPI). The HSS (database entity) provides the S- CSCF with the list of events and relative priorities of the Application Servers to contact per event (and other information). The data from the HSS is also known as Filter Criteria. When an event occurs that matches an SPI from the Filter Criteria, the SIP serving proxy needs to contact each AS that is matched before sending the message on towards the final destination. Each AS may alter the message in some way before returning the message to the SIP serving proxy. Since the message may have been changed by the AS, including the components of the dialog identifier, the Henrikson Expires - November 2002 [Page 2] Private SIP Extension for Original Dialog Identifier May 2002 SIP serving proxy needs some way to determine that the received message is related to the original message that it sent to the AS. This will always be needed when an AS is acting as a B2BUA, which starts a new dialog. Consider the following example: UA---P---I---S---AS---S---AS---S---AS---S---AS---S---I---P2---UA2 Every AS hop creates a new dialog -- so the above example actually has 5 seperate dialogs. One may consider using the Route header as a mechanism to get the request sent back to the S-CSCF. However, Route headers don't automatically transit an AS acting as a B2BUA. This could be overcome by using loose-routing and application logic in the B2BUA. But that is not the full problem to be solved. A strong correlation of dialogs is also needed for accounting purposes to treat the sequence of dialogs as a concatenated single dialog. A common identification tag needs to be carried in each related dialog so that the charging functions can associate all the dialogs. The solution provided is to include the original dialog id in the message sent to the AS and to have the AS return the same original dialog id in the message sent back to the SIP serving proxy. Then the SIP serving proxy can make the association between the two messages and know that the incoming message is related to the previous outgoing message, which is part of the sequence to contact each AS that matched the Filter Criteria. 2. Discussion of Mechanism The provided mechanism uses a private header "P-Original-Dialog-ID" in an INVITE request forwarded from a proxy. The same mechanism may be applied to other methods that initiate dialogs. The mechanism only makes sense for stateful proxies that also employ some application specific logic. When a stateful proxy receives an INVITE that does not contain a P- Original-Dialog-ID header, then it may choose to insert a P- Original-Dialog-ID header into an INVITE request prior to forwarding the request. If so, it will populate the contents with the dialog identification fields from the received request: Call- ID, From tag and To tag. If there was no To tag in the received request, then a value of zero will be used for the To parameter in the P-Original-Dialog-ID header. When a stateful proxy receives an INVITE that already contains a P- Original-Dialog-ID header, then it may use this information to look Henrikson Expires - November 2002 [Page 3] Private SIP Extension for Original Dialog Identifier May 2002 for a match with a previously handled dialog. If no match is found, then the message is simply forwarded to the next destination. If a match is found, then depending on the application specific logic that may reside with the proxy, the P-Original-Dialog-ID header may be removed from the outbound message. 3. Applicability Statement This mechanism is suitable when a proxy forwards an initial request for a dialog, or a standalone transaction, to an AS that may act as a B2BUA, and the request is expected to return to the proxy with a need to correlate the original request and the forwarded request for the transaction or the dialog. The P-Original-Dialog-ID header is applicable whenever the following circumstances are met: 1. A UAC sends a REGISTER or dialog initiating request (e.g., INVITE) or a standalone transaction request to a proxy in a private network. 2. The proxy in the private network that receives the request needs to forward the request to one or more Application Servers (AS) in a particular order. 3. One or more AS is a B2BUA and will return the modified request back to the proxy. 4. The proxy in the private network needs to recognize that a received, modified request is related to a previous request. 5. Optionally, the proxy in the private network needs to associate the different dialogs that are all related to the original dialog for charging purposes. 4. P-Original-Dialog-ID syntax and definition All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [2]. Further, the BNF definitions from RFC 3261 [1] are inherited for the P-Original-Dialog-ID header and are not repeated here. Implementers need to be familiar with the notation and content of RFC 3261 [1] and RFC 2234 [2] to understand this document. The syntax for the P-Original-Dialog-ID header is as follows: p-original-dialog-id = "P-Original-Dialog-ID" HCOLON dialog-params *(SEMI dialog-params) dialog-params = call-id / to-tag / from-tag / generic-param call-id = "call-id" EQUAL callid to-tag = "to-tag" EQUAL token Henrikson Expires - November 2002 [Page 4] Private SIP Extension for Original Dialog Identifier May 2002 from-tag = "from-tag" EQUAL token Example: P-Original-Dialog-ID: call-id=123@abc;to-tag=456;from-tag=789 A P-Original-Dialog-ID header may be inserted into an INVITE or other standalone or dialog initiating request by any SIP node traversed by that message. However, there may only be one instance of a P-Original-Dialog-ID in a SIP message. Further, a particular instance of P-Original-Dialog-ID shall contain exactly one of each of the parameters: call-id, to-tag and from-tag. The allowable usage of headers is described in Table 2 of SIP [1]. Addition of P-Original-Dialog-ID to the Table 2 in SIP [1], section 4.1 of the SIP-specific event notification [8], tables 1 and 2 in the SIP INFO method [9], tables 1 and 2 in Reliability of provisional responses in SIP [10], tables 1 and 2 in the SIP UPDATE method [11], tables 1 and 2 in the SIP extension for Instant Messaging [12] and table 1 in the SIP REFER method [13]: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ P-Original-Dialog-ID R ard - - - o o o Header field SUB NOT PRA INF UPD MES REF _______________________________________________________________ P-Original-Dialog-ID o - - - - o - 5. Usage 5.1 Procedures at the UA The UAC and UAS (originating and terminating UA) behave as usual. They are not required to understand the P-Original-Dialog-ID header, but may retrieve the information if received. 5.2 Procedures at the Proxy The P-Original-Dialog-ID header is treated like any other unknown header by intermediate proxies. They simply forward it on towards the destination. If a proxy that supports this extension receives a dialog request without the P-Original-Dialog-ID header, it MAY insert a P- Original-Dialog-ID header prior to forwarding the message. The from-tag parameter MUST be populated with the received From tag value. The to-tag parameter MUST be populated with the received To tag value or the value of zero if there was no To tag present. The Henrikson Expires - November 2002 [Page 5] Private SIP Extension for Original Dialog Identifier May 2002 call-id parameter MUST be populated with the received Call-ID value. If a proxy that supports this extension receives a dialog request with the P-Original-Dialog-ID header, it MAY retrieve the information from the header to use with application specific logic. The proxy SHOULD retain the P-Original-Dialog-ID header in the outbound message. If the next hop for the message is outside the network of the proxy, then the proxy MAY remove the P-Original- Dialog-ID header from the message. The P-Original-Dialog-ID header carries only tag information, and therefore does not reveal information that may affect the privacy of the remote users; however the information contained is of no relevance to the end UAs and therefore MAY be removed as defined above for reasons of protocol efficiency which may be of concern in a radio environment. 5.3 Procedures at the Back to Back UA If a B2BUA that understands the P-Original-Dialog-ID header receives a dialog request with the P-Original-Dialog-ID header, the B2BUA SHOULD copy it from the receiving side UA to the sending side UA. 5.4 Examples of Usage We present example in the context of the scenario presented in the Background section earlier in this document. The network diagram is replicated below: Scenario UA1----P1-----AS-----P1-----P3-----UA2 This example shows the message sequence for an INVITE transaction originating from UA1 eventually arriving at UA2. P1 is an outbound proxy for UA1 which routes the request to an Application Server (AS). In this case the Application Server acts as a B2BUA independent of any knowledge of P1. AS routes the request back to P1 using SIP routeing mechanisms that are not detailed in this example. P1 correlates the original request with the returned request. P1 then routes the call via P3 to UA2. Message sequence for INVITE using P-Original-Dialog-ID: Henrikson Expires - November 2002 [Page 6] Private SIP Extension for Original Dialog Identifier May 2002 F1 INVITE UA1 -> P1 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: . . . F2 INVITE P1 -> AS INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: P-Original-Dialog-ID: call-id=843817637684230@998sdasdh09; to-tag=0;from-tag=456248 . . . F3 INVITE AS -> P1 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP AS:5060;branch=z9hG4bKiokioukju908 To: Joe From: AS@HOMEDOMAIN ;tag=934871 Call-ID: 383749274837591@567ahjk8321 CSeq: 4 INVITE Contact: P-Original-Dialog-ID: call-id=843817637684230@998sdasdh09; to-tag=0;from-tag=456248 . . . P1 removes the P-Original-Dialog-ID header F5 INVITE P1 -> P3 INVITE sip:joe@UA2 Via: SIP/2.0/USP P1:5060;branch=z9hG4bKHSP10120323 Via: SIP/2.0/UDP AS:5060;branch=z9hG4bKiokioukju908 To: Joe From: AS@HOMEDOMAIN ;tag=934871 Call-ID: 383749274837591@567ahjk8321 CSeq: 4 INVITE Contact: . . . Henrikson Expires - November 2002 [Page 7] Private SIP Extension for Original Dialog Identifier May 2002 INVITE propagates toward UA2 as usual. 6. Security Considerations It is possible for proxies between the originating UA and the terminating UA to modify the value of P-Original-Dialog-ID or to insert a P-Original-Dialog-ID into a request for a dialog, e.g. INVITE request. Therefore, an integrity protection mechanism such as IPsec or other available mechanisms SHOULD be applied in order to prevent such attacks. The information contained is tag information from the original request, and therefore knowledge of the contents of this header does not compromise the privacy of the UA or any of the involved proxies. 7. IANA Considerations This document defines the SIP extension header "P-Original-Dialog- ID" which should be included in the registry of SIP headers defined in SIP [1]. As required by the SIP change process draft-tsvarea- sipchange [4] the SIP extension header name "Original-Dialog-ID" should also be registered in association with this extension. 8. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session Initiation Protocol, RFC 3261", March 2002. [2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax specifications: ABNF," RFC 2234, Internet Engineering Task Force, November 1997. 9. Non-Normative References [3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia- sipping-3gpp-reqs-03.txt", March 2002. [4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange", March 2002. [5] 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - Release 5". [6] 3GPP TS 23.218 " IP Multimedia (IM) Session Handling; IM call model - Release 5". Henrikson Expires - November 2002 [Page 8] Private SIP Extension for Original Dialog Identifier May 2002 [7] 3GPP TS 24.229 "IP Multimedia Subsystem (IMS) (Stage 3) - Release 5". [8] A. Roach, SIP-Specific Event Notification, RFC 3265, March 2002. [9] S. Donovan, The SIP INFO method, RFC 2976, October 2000. [10] J. Rosenberg, H. Schulzrinne, Reliability of Provisional Responses in SIP, RFC 3262, March 2002. [11] J. Rosenberg, The Session Initiation Protocol UPDATE Method, draft-ietf-sip-update-02.txt, April 2002, work in progress. [12] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, Session Initiation Protocol Extension for Instant Messaging, draft-ietf-sip-message-04, May 2002, work in progress. [13] R. Sparks, The REFER method, draft-sparks-sip-refer-split- 00.txt, April 2002, work in progress. Author's Addresses Eric Henrikson Lucent Technologies 11601 Willows Rd Suite 100 Redmond, WA 98052 US Phone: +1 425 497 2442 EMail: ehenrikson@lucent.com URI: http://www.lucent.com/ Henrikson Expires - November 2002 [Page 9]