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]