Internet Draft E. Henrikson Document: draft-henrikson-sip-original-dialog-id-01 Lucent Expires: November 2002 Technologies Category: Informational May 2002 Private SIP Extension for Original Dialog Identifier draft-henrikson-sip-original-dialog-id-01 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 document proposes a private SIP extension header used in conjunction with INVITE requests to provide a mechanism by which a stateful proxy may 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 Third Generation Partnership Project (3GPP) architecture to ensure proper routing of an INVITE request with 3GPP Application Servers (AS). A S-CSCF may route an INVITE request to multiple AS, as indicated by a subscriber profile, 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. 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 P-Original-Dialog-ID header provides a way to accomplish this association. The same mechanism may be applied to any SIP method that is used to initiate a dialog. Henrikson Expires - November 2002 [Page 1] Private SIP Extension for Original Dialog Identifier May 2002 Table of Contents 1. Background....................................................2 2. Discussion of Mechanism.......................................3 3. Applicability Statement.......................................3 4. Syntax........................................................3 5. Usage.........................................................4 5.1 Procedures at the UA......................................4 5.2 Procedures at the Proxy...................................4 5.3 Procedures at the Back to Back UA.........................5 5.4 Examples of Usage.........................................5 6. Security Considerations.......................................6 7. IANA Considerations...........................................7 8. Normative References..........................................7 9. Non-Normative References......................................7 Author's Addresses...............................................7 1. Background 3GPP has defined a mechanism for the S-CSCF (a SIP proxy with additional functionality, which acts as the SIP serving proxy, see draft-garcia-sipping-3gpp-reqs [3]) to contact multiple Application Servers (AS) 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 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. 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. Henrikson Expires - November 2002 [Page 2] Private SIP Extension for Original Dialog Identifier May 2002 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 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 forwarding 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. 4. Syntax 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 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: P-Original-Dialog-ID = "P-Original-Dialog-ID" HCOLON ( "od-from-tag" EQUAL od-from-tag ) ( COMMA "od-to-tag" EQUAL od-to-tag ) Henrikson Expires - November 2002 [Page 3] Private SIP Extension for Original Dialog Identifier May 2002 ( COMMA "od-call-id" EQUAL od-call-id ) od-from-tag = token od-to-tag = token od-call-id = callid The allowable usage of headers is described in Table 2 of SIP [1]. The following additions to this table are needed for the P- Original-Dialog-ID header. Addition of P-Original-Dialog-ID to SIP Table 2: Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT ------------------------------------------------------------------- P-Original-Dialog-ID R ard - - - o o 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 od- from-tag parameter will be populated with the received From tag value. The od-to-tag parameter will be populated with the received To tag value or the value of zero if there was no To tag present. The od-call-id parameter will 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. Henrikson Expires - November 2002 [Page 4] Private SIP Extension for Original Dialog Identifier May 2002 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-----P2-----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 P2. In this case the Application Server acts as a proxy, but it could equally act as a B2BUA independent of any knowledge of P1. P2 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: 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: . . . Henrikson Expires - November 2002 [Page 5] Private SIP Extension for Original Dialog Identifier May 2002 F2 INVITE P1 -> P2 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: od-from-tag=456248,od-to-tag=0, od-call-id=843817637684230@998sdasdh09 . . . F3 INVITE P2 -> P1 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP P2:5060;branch=z9hG4bKiokioukju908 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: od-from-tag=456248,od-to-tag=0, od-call-id=843817637684230@998sdasdh09 . . . P2 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 P2:5060;branch=z9hG4bKiokioukju908 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: . . . 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 Henrikson Expires - November 2002 [Page 6] Private SIP Extension for Original Dialog Identifier May 2002 insert a P-Original-Dialog-ID into a request for a dialog, e.g. INVITE request. It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore desirable to apply transitive mutual authentication using sips: or other available mechanisms 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. 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 7] Private SIP Extension for Original Dialog Identifier May 2002 Henrikson Expires - November 2002 [Page 8]