Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-06

's-GRUU)                     |
     |                     Call-ID: (call-id four)                   |
     |                     Contact: (Alice's-GRUU)                   |
     |-------------------------------------------------------------->|
     |                     200 OK                                    |
     |                     Contact: (Carol's-GRUU)                   |
     |<--------------------------------------------------------------|
     |                     ACK                                       |
     |-------------------------------------------------------------->|
     |                                |                              |
     | F7 NOTIFY (Bob's-GRUU)         |                              |

Sparks                   Expires August 20, 2007               [Page 21]
Internet-Draft           Multiple Dialog Usages            February 2007

     |    Call-ID: (call-id three)    |                              |
     |------------------------------->|                              |
     |    200 OK                      |                              |
     |<-------------------------------|                              |
     |    BYE (Alice's-GRUU)          |                              |
     |    Call-ID: (call-id one)      |                              |
     |<-------------------------------|   BYE (Carol's-GRUU)         |
     |                                |   Call-ID: (call-id two)     |
     |    200 OK                      |----------------------------->|
     |------------------------------->|   200 OK                     |
     |                                |<-----------------------------|
     |                                |                              |

                  Figure 5: Transfer without dialog reuse

   In message F1, Alice invites Bob indicating support for GRUUs (and
   offering a GRUU for herself):

      Message F1 (abridged, detailing pertinent fields)

        INVITE sip:bob@example.com SIP/2.0
        Call-ID: 13jfdwer230jsdw@alice.example.com
        Supported: gruu
        Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>

   Message F2 carries Bob's GRUU to Alice.

      Message F2 (abridged, detailing pertinent fields)

        SIP/2.0 200 OK
        Supported: gruu
        To: <sip:bob@example.com>;tag=totag1
        From: <sip:alice@example.com>;tag=fromtag1
        Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>

   Bob decides to try to transfer Alice to Carol, so he puts Alice on
   hold and sends an INVITE to Carol.  Carol and Bob negotiate GRUU
   support similar to what happened in F1 and F2.

Sparks                   Expires August 20, 2007               [Page 22]
Internet-Draft           Multiple Dialog Usages            February 2007

      Message F3 (abridged, detailing pertinent fields)

        INVITE sip:carol@example.com SIP/2.0
        Supported: gruu
        Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
        Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>

      Message F4 (abridged, detailing pertinent fields)

        SIP/2.0 200 OK
        Supported: gruu
        To: <sip:carol@example.com>;tag=totag2
        From: <sip:bob@example.com>;tag=fromtag2
        Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
        Contact: <sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)>

   After consulting Carol, Bob places her on hold and refers Alice to
   her using message F5.  Notice that the Refer-To URI is Carol's GRUU,
   and that this is on a different Call-ID than message F1.  (The URI in
   the Refer-To header is line-broken for readability in this draft, it
   would not be valid to break the URI this way in a real message)

      Message F5 (abridged, detailing pertinent fields)

        REFER sip:aanewmr203raswdf@example.com SIP/2.0
        Call-ID: 39fa99r0329493asdsf3n@bob.example.com
        Refer-To: <sip:carol@example.com;g=urn:uid:(Carol's UA's bits)
                   ?Replaces=23rasdnfoa39i4jnasdf@bob.example.com;
                    to-tag=totag2;from-tag=fromtag2>
        Target-Dialog: 13jfdwer230jsdw@alice.example.com;
                       local-tag=fromtag1;remote-tag=totag1
        Supported: gruu
        Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>

   Alice uses the information in the Target-Dialog header field to
   determine that this REFER is associated with the dialog she already
   has in place with Bob. Alice is now in a position to use the same
   admission policy she used for in-dialog REFERs: "Do I have a call
   with this person?".  She accepts the REFER. sends Bob the obligatory
   immediate NOTIFY, and proceeds to INVITE Carol with message F6.

Sparks                   Expires August 20, 2007               [Page 23]
Internet-Draft           Multiple Dialog Usages            February 2007

      Message F6 (abridged, detailing pertinent fields)

            sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)
            \                                                   /
              \                                                /
               |                                              |
               v                                              v
        INVITE                                                  SIP/2.0
        Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com
        Replaces: 23rasdnfoa39i4jnasdf@bob.example.com;
                  to-tag=totag2;from-tag=fromtag2
        Supported: gruu
        Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>

   Carol accepts Alice's invitation to replace her dialog (invite usage)
   with Bob and notifies him that the REFERenced INVITE succeeded with
   F7:

      Message F7 (abridged, detailing pertinent fields)

        NOTIFY sip:boaiidfjjereis@example.com SIP/2.0
        Subscription-State: terminated;reason=noresource
        Call-ID: 39fa99r0329493asdsf3n@bob.example.com
        Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
        Content-Type: message/sipfrag

        SIP/2.0 200 OK

   Bob then ends his invite usages with both Alice and Carol using BYEs.

7.  Security Considerations

   Handling multiple usages within a single dialog is complex and
   introduces scenarios where the right thing to do is not clear.  The
   ambiguities described here can result in unexpected disruption of
   communication if response codes are chosen carelessly.  Furthermore,
   these ambiguities could be exploited, particularly by third-parties
   injecting unauthenticated requests or inappropriate responses.
   Implementations choosing to create or accept multiple usages within a
   dialog should give extra attention to the security considerations in
   [1], especially those concerning authenticity of requests and
   processing of responses.

   Service implementations should carefully consider the effects on
   their service of peers making different choices in these areas of

Sparks                   Expires August 20, 2007               [Page 24]
Internet-Draft           Multiple Dialog Usages            February 2007

   ambiguity.  A service that requires multiple usages needs to pay
   particular attention to the effect on service and network utilization
   when a client fails to destroy a dialog the service believes should
   be destroyed.  A service that disallows multiple usages should
   consider the effect on clients that, for instance, destroy the entire
   dialog when only a usage should be torn down.  In the worst case of a
   service deployed into a network with a large number of misbehaving
   clients trying to create multiple usages in an automated fashion, a
   retry storm similar to an avalanche restart could be induced.

8.  IANA Considerations

   This document has no actions for IANA.

9.  Conclusion

   Handling multiple usages within a single dialog is complex and
   introduces scenarios where the right thing to do is not clear.
   Implementations should avoid entering into multiple usages whenever
   possible.  New applications should be designed to never introduce
   multiple usages.

   There are some accepted SIP practices, including transfer, that
   currently require multiple usages.  Recent work, most notably GRUU,
   makes those practices unnecessary.  The standardization of those
   practices and the implementations should be revised as soon as
   possible to use only single-usage dialogs.

10.  Acknowledgments

   The ideas in this draft have been refined over several IETF meetings
   with many participants.  Significant contribution was provided by
   Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan
   Rosenberg, Paul Kyzivat, and Rohan Mahy.  Members of the reSIProcate
   project also shared their difficulties and discoveries while
   implementing multiple-usage dialog handlers.

11.  Informative References

   [1]   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.

   [2]   Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol

Sparks                   Expires August 20, 2007               [Page 25]
Internet-Draft           Multiple Dialog Usages            February 2007

         (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [3]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [4]   Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [5]   Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
         "Join" Header", RFC 3911, October 2004.

   [6]   Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
         Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.

   [7]   Rosenberg, J., "Obtaining and Using Globally Routable User
         Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
         (SIP)", draft-ietf-sip-gruu-11 (work in progress),
         October 2006.

   [8]   Levin, O., "Suppression of Session Initiation Protocol (SIP)
         REFER Method Implicit Subscription", RFC 4488, May 2006.

   [9]   Rosenberg, J., "Request Authorization through Dialog
         Identification in the Session Initiation Protocol (SIP)",
         RFC 4538, June 2006.

   [10]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [11]  Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP)
         Event Package for Key Press Stimulus  (KPML)",
         draft-ietf-sipping-kpml-08 (work in progress), July 2006.

Appendix A.  Change Log

   RFC-EDITOR: Please remove this entire Change Log section while
   formatting this document for publication.

A.1.  draft-ietf-05->draft-ietf-06

   o  Noted that 481 to CANCEL is special and affects only the CANCEL
      transaction, not any associated INVITE usage.
   o  Noted that certain errors to BYE can effectively terminate a usage
      in the usage creation and destruction overview.

Sparks                   Expires August 20, 2007               [Page 26]
Internet-Draft           Multiple Dialog Usages            February 2007

A.2.  draft-ietf-04->draft-ietf-05

   o  Fixed the flaw with the GRUU message description text that Paul
      caught.
   o  Integrated Paul's table and further simplified the comment/
      exception text.

A.3.  draft-ietf-03->draft-ietf-04

   o  Many minor editorial fixes addressing WGLC comments
   o  Aligned with changes to GRUU
   o  Added a short overview
   o  Added a table summarizing the survey of responses and removed the
      description from those responses that were not exceptional.

A.4.  draft-ietf-02->draft-ietf-03

   o  Removed discussion of the retargetting affect of provisional
      responses - that is a general problem that will now be addressed
      in SIP.
   o  Added a Security Considerations section (blush) summarizing points
      from the document and the list discussion.
   o  Added a no-op IANA Considerations section.

A.5.  draft-ietf-01->draft-ietf-02

   o  Incorporated editorial-fix contributions from the list
   o  Noted that REFERs using norefersub (RFC4488) don't create a new
      subscribe usage
   o  Changed the affect of 403 to affect only the transaction, not the
      usage.  This is motivated by text in 3261 (bottom of page 87 -
      pointed out by Brian Stucker) which states that a UA receiving a
      non-2xx final response to a re-INVITE must leave the session
      parameters unchanged as if the re-INVITE had not been issued.
      There are other recommendations in this document that violate that
      normative must (404,410, etc) but on review, I believe they are
      correct (except for 403) and that this text in 3261 needs to be
      updated to recognize the conditions under which they're sent.
   o  Added text concerning the race condition wherein endpoints failing
      over rapidly to 3263 destinations may stimulate a merged-request
      response.
   o  Corrected the 481 inconsistency Paul Kyzivat pointed out (by
      removing the inconsistent paragraph)

A.6.  draft-ietf-00->draft-ietf-01

Sparks                   Expires August 20, 2007               [Page 27]
Internet-Draft           Multiple Dialog Usages            February 2007

   o  Changed 481 to only affect the usage the response occurred in,
      closing the last open issue.  Added some text justifying this
      recommendation.
   o  Added 422 Session Interval Too Small
   o  Added 417 Unknown Resource-Priority
   o  Added 428 Use Identity Header
   o  Added 436 Bad Identity-Info
   o  Added 437 Unsupported Certificate
   o  Added 438 Invalid Identity header
   o  Added a section categorizing messages that create and destroy
      usages
   o  Made sure all descriptions in Section 5 addressed the generic
      multi-usage case.
   o  Clarified that the mechanics described in matching messages to
      usages applied equally to UACs and UASs.
   o  More explicitly noted that REFER creates a subscribe-usage

A.7.  draft-sparks-01->draft-ietf-00
   o  Draft rename

A.8.  draft-sparks-00->01
   o  Changed 480 to affect only the usage the response occurred in.
   o  Closed the open issue on 482.  Usages and dialogs are destroyed
      even though there is an edge condition in which the response is
      only stimulated by certain methods (due to method specific routing
      rules).
   o  Closed the open issue on 483.  Usages are not terminated since the
      request might succeed if retried with a greater initial Max-
      Forwards
   o  Closed the open issue on 502, accepting -00s suggestion that the
      same reasoning used for 482 applies.
   o  Redid the transfer example to not require a GRUU per usage, but
      instead leverage the target-dialog concepts common to Join and
      Replaces.

Author's Address

   Robert J. Sparks
   Estacado Systems

   Email: RjS@estacado.net

Sparks                   Expires August 20, 2007               [Page 28]
Internet-Draft           Multiple Dialog Usages            February 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Sparks                   Expires August 20, 2007               [Page 29]