Internet DRAFT - draft-henrikson-sip-original-dialog-id

draft-henrikson-sip-original-dialog-id





 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 <sip:joe> 
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248 
          Call-ID: 843817637684230@998sdasdh09 
          CSeq: 18 INVITE 
          Contact: <sip:UA@192.0.2.4> 
            . . . 
     
        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 <sip:joe> 
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248 
          Call-ID: 843817637684230@998sdasdh09 
          CSeq: 18 INVITE 
          Contact: <sip:UA@192.0.2.4> 
          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 <sip:joe> 
          From: AS@HOMEDOMAIN <AS@HOMEDOMAIN>;tag=934871 
          Call-ID: 383749274837591@567ahjk8321 
          CSeq: 4 INVITE 
          Contact: <sip:UA@183.0.5.8> 
          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 <sip:joe@UA2> 
          From: AS@HOMEDOMAIN <AS@HOMEDOMAIN>;tag=934871 
          Call-ID: 383749274837591@567ahjk8321 
          CSeq: 4 INVITE 
          Contact: <sip:UA@183.0.5.8> 
           . . . 
     
  
  
 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]