[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

SIPPING Working Group                                       G. Camarillo
Internet-Draft                                                 S. Loreto
Expires: December 18, 2008                                      Ericsson
                                                            Jun 16, 2008


 Requirements for correlation of multiple SIP sessions for user to user
                            communications.
          draft-loreto-sipping-context-id-requirements-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 December 18, 2008.

Abstract

   This document shows the need and list the requirements to logically
   correlate an existing SIP dialog, or even multi SIP transactions sent
   outside of a dialog, with a new SIP dialog.  This mechanism can be
   used to implement applications using multiple SIP sessions but also
   in peer-to-peer call control environments.









Camarillo & Loreto      Expires December 18, 2008               [Page 1]


Internet-Draft         SIP Context-ID requirements              Jun 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Enhance messaging conversation  . . . . . . . . . . . . . . 4
     3.2.  Including an external UA in a conversation  . . . . . . . . 4
     3.3.  Correlate the new conversation with a previous one  . . . . 5
     3.4.  Correlate the original INVITE, SUBSCRIBE request and
           recall INVITE in SIP Call Completion scenario . . . . . . . 5
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Informational References  . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9



































Camarillo & Loreto      Expires December 18, 2008               [Page 2]


Internet-Draft         SIP Context-ID requirements              Jun 2008


1.  Introduction

   This document shows the need to define in SIP [RFC3261] a mechanism
   to indicate a generic context, "Context Id", to which SIP signaling
   and application states can be tied.  The Context Id (CId) is used to
   logically correlate an existing SIP dialog, or even multiple SIP
   transactions sent outside of a dialog, with a new SIP dialog.  The
   logical correlation is needed when the different SIP signaling can be
   considered a part of the same conversation space.

   This is especially useful to implement applications using multiple
   SIP sessions, but also in peer-to-peer call control environments
   providing a standard way to associate multiple sessions as part of a
   single call in SIP (as also highlighted in Section 5.4.3 of Sip
   Session Mobility [I-D.shacham-sipping-session-mobility]).

   Sip Service Control [RFC3087] propose to communicate context
   information using a distinctive Request URI.  However the concept is
   only applicable to SIP based services where the initial application
   state should be determined from the context, as for example in
   Conferencing [RFC4579].

   The SIP peer-to-peer control model already provides a "primitive"
   operation to Join a new dialog with an existing dialog.  However,
   while is possible insert a new participant into a conversation space
   with the Join header field [RFC3911], the Join operation is normally
   used to create or join a conference.  It adds a dialog to the
   conversation space associated with the matched dialog and performs a
   media mixing or media combining.  Moreover there is no possibility in
   SIP to correlate multiple SIP transactions sent outside of a dialog,
   with a new SIP dialog.

   Instead the Context Id mechanism allows the insertion of a new dialog
   into a messaging or a multimedia conversation.  It enables the new
   dialog to share all the resources and the user interface associated
   to the same conversation space.

   The Context Id also allows to maintain data related to a conversation
   among users, across the time and across SIP dialogs.

   The rest of this document is organized as follows.  Section 2 defines
   a few terms used in this document.  Section 3 provides three use
   cases for the Context Id mechanism.  Section 4 lists the requirements
   for the Context Id mechanism.







Camarillo & Loreto      Expires December 18, 2008               [Page 3]


Internet-Draft         SIP Context-ID requirements              Jun 2008


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The reader should be familiar with the terminology defined in the SIP
   Call Control Framework [I-D.ietf-sipping-cc-framework].

   Conversation Space:  A set of participants who believe they are
      communicating among one another.  Each conversation space contains
      one or more participants.
   Participants:  SIP User Agents that send original media to or
      terminate and receive media from other members of the conversation
      space.

   This specification makes use of the following additional terminology:

   Context ID:  A protocol element used to indicate a generic context to
      which SIP signaling (e.g.  SIP dialog or stand-alone SIP
      transactions) and application states can be tied.


3.  Use cases

3.1.  Enhance messaging conversation

      Alice and Bob are two participants in a communication space
      exchanging SIP MESSAGE methods sent outside a SIP dialog[RFC3428]:
      The application shows the text sent and received on the screen.

      Alice later wants to add voice to the same application.

      So Alice sends an SIP INVITE request to Bob to establish a voice
      session.

      Alice indicates that the voice session shall be correlated with
      the existing instance of the application where the messages are
      exchanged (assuming the application also supports voice).


3.2.  Including an external UA in a conversation

      Alice establishes a voice session with Bob.







Camarillo & Loreto      Expires December 18, 2008               [Page 4]


Internet-Draft         SIP Context-ID requirements              Jun 2008



      Alice wants to add video to the session using her SIP-enabled
      camera.

      Alice sends a REFER to her camera, which has a SIP user agent on
      it, so that her camera sends an INVITE request to Bob in order to
      establish a video stream.

      Alice wants Bob to treat the video stream from her camera and the
      voice stream from her voice-only user agent as part of the same
      communication space.  That is, Alice wants Bob to treat both
      streams as if both had been established using a single SIP dialog.


3.3.  Correlate the new conversation with a previous one

      Alice and Bob are in communication with each other using SIP
      MESSAGE [RFC3428] methods sent outside a SIP dialog or MSRP
      Sessions [RFC4975].

      Alice left the conversation and close down the messaging
      application.

      After a while Alice wants to continue the conversation she was
      previously having with Bob. Alice wants Bob to treat the new
      conversation as a continuation of the previous one.  That is,
      Alice wants Bob to show the new messages below the ones they have
      previously exchanged.




3.4.  Correlate the original INVITE, SUBSCRIBE request and recall INVITE
      in SIP Call Completion scenario

      Alice wants to call Bob with the call-completion
      service.[I-D.bliss-ietf-call-completion].

      Bob does not answer the call.

      Alice's UA Subscribes for call-completion processing (CC) to the
      URI received in the Call-Info header or to the BOB AoR specifying
      "Event: call-completion" with a parameter call_id={Call-Id of the
      original call).







Camarillo & Loreto      Expires December 18, 2008               [Page 5]


Internet-Draft         SIP Context-ID requirements              Jun 2008



      Eventually, Alice is selected for CC, and is informed of this via
      Notify.  This Notify carries a URI to which the CC completion
      Invite should be sent.

      Alice's UA generates a new Invite to the URI specified.

      Bob's call-completion monitor shall be able to recognize the
      incoming call as the recall of Alice's unanswered call.  Otherwise
      the Invite will be rejected.  Moreover Bob's call-completion
      monitor shall also be able to recognize the relationship between
      the SUBSCRIBE for the CC monitoring and the Initial Invite.





4.  Requirements

   Req.1  It MUST be possible to correlate SIP Requests (e.g.  MESSAGE)
      sent out outside of a dialog with applications started in a
      separate dialog.

   Req.2  It MUST be possible to correlate a new application started in
      a new dialog with another application already existent in a
      separate dialog.

   Req.3  It MUST be possible to correlate the new conversation with a
      previous one (e.g. a user wants continue a chat session he was
      having with his friends the day before)

   Req.4  The Context ID shall be an End to End value.

   Req.5  The Context ID has a defined Time To live.

   Req.6  Time To live of the Context Id shall not be coupled to the
      life cycle of the application process:

      *  It shall be possible to close down the application, and when it
         is launched again resume the Context ID and use it in the new
         application process.

   Req.7  The Context ID Time To live is controlled and administered by
      the application.







Camarillo & Loreto      Expires December 18, 2008               [Page 6]


Internet-Draft         SIP Context-ID requirements              Jun 2008



   Req.8  When correlation of the Context ID to existing dialog is not
      possible, it shall be ignored and handled as a new context.



5.  Security Considerations

   To be done!


6.  IANA Considerations

   This document does not require actions by IANA.


7.  Informational References

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

   [I-D.shacham-sipping-session-mobility]
              Shacham, R., Schulzrinne, H., Thakolsri, S., and W.
              Kellerer, "Session Initiation Protocol (SIP) Session
              Mobility", draft-shacham-sipping-session-mobility-05 (work
              in progress), November 2007.

   [RFC3087]  Campbell, B. and R. Sparks, "Control of Service Context
              using SIP Request-URI", RFC 3087, April 2001.

   [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
              (SIP) Call Control - Conferencing for User Agents",
              BCP 119, RFC 4579, August 2006.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [I-D.ietf-sipping-cc-framework]
              Mahy, R., Sparks, R., Rosenberg, J., Petrie, D., and A.
              Johnston, "A Call Control and Multi-party usage framework
              for the Session Initiation  Protocol (SIP)",
              draft-ietf-sipping-cc-framework-10 (work in progress),
              April 2008.

   [I-D.bliss-ietf-call-completion]
              Worley, D., Huelsemann, M., and D. Alexeitsev, "Call



Camarillo & Loreto      Expires December 18, 2008               [Page 7]


Internet-Draft         SIP Context-ID requirements              Jun 2008


              Completion for Session Initiation Protocol(SIP)",
              draft-bliss-ietf-call-completion-00 (work in progress),
              February 2008.

   [RFC3428]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
              and D. Gurle, "Session Initiation Protocol (SIP) Extension
              for Instant Messaging", RFC 3428, December 2002.

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

   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: gonzalo.camarillo@ericsson.com


   Salvatore Loreto
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: salvatore.loreto@ericsson.com


















Camarillo & Loreto      Expires December 18, 2008               [Page 8]


Internet-Draft         SIP Context-ID requirements              Jun 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Camarillo & Loreto      Expires December 18, 2008               [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/