SIPPING Working Group G. Camarillo Internet-Draft S. Loreto Intended status: Informational Ericsson Expires: April 23, 2009 October 20, 2008 Requirements for Dialog Correlation in the Session Initiation Protocol (SIP) draft-loreto-sipping-context-id-requirements-01.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 April 23, 2009. Abstract This document justifies the need and lists the requirements for correlating SIP (Session Initiation Protocol) dialogs that relate to the same multimedia session. Being able to logically correlate multiple SIP dialogs is useful for applications that, for different reasons, need to establish several SIP dialogs to provide a given service. Camarillo & Loreto Expires April 23, 2009 [Page 1] Internet-Draft SIP Session Correlation Requirements October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Distributed User Agent Client: Use Cases . . . . . . . . . . . 3 2.1. Using Two Separate UAs to Start a Conversation . . . . . . 3 2.2. Showing a Pre-recorded Video During a Conversation . . . . 4 2.3. Sending a File from a PC During a Conversation . . . . . . 4 2.4. Including Live Video in a Conversation . . . . . . . . . . 5 2.5. Including Remote Live Video in a Conversation . . . . . . . 5 3. Distributed User Agent Server: Use Cases . . . . . . . . . . . 5 3.1. Using Two Separate UAs in a Conversation . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Informational References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Camarillo & Loreto Expires April 23, 2009 [Page 2] Internet-Draft SIP Session Correlation Requirements October 2008 1. Introduction This document shows the need to logically correlate multiple SIP (Session Initiation Protocol) dialogs that relate to the same multimedia session. The SIP specification [RFC3261] defines a multimedia session as "an exchange of data between an association of participants". SDP (Session Description Protocol) is the default session description format in SIP. The SDP (Session Description Protocol) specification [RFC4566] defines a multimedia session as "a set of multimedia senders and receivers and the data streams flowing from senders to receivers". Generally, a given participant uses a single SIP dialog to establish (or participate in) a given multimedia session. For example, two SIP user agents can use a SIP dialog between them to establish a multimedia session consisting on an audio stream and a video stream. Still, in some situations, several SIP dialogs are required to establish a single multimedia session. In order to treat the different media streams establish by the different SIP dialogs as part of a single media session, there is a need to correlate those dialogs. The remainder of this document is organized as follows. Section 2 and Section 3 contain use cases where multiple dialogs are required to establish a multimedia session. Section 4 contains requirements for a mechanism to correlate SIP dialogs that relate to a single multimedia session. Section 5 analyzes existing mechanisms against the requirements we have identified and concludes that a new mechanism will need to be developed since there is no existing mechanism that meets all of them. 2. Distributed User Agent Client: Use Cases This section lists use cases where the UAC is distributed. That is, the user initiating the session will use several UAs in parallel during the session. 2.1. Using Two Separate UAs to Start a Conversation Laura is at her office. On her desk, she has a PC with a soft client and a desk phone. The PC has a low-quality built-in microphone and is connected to high-quality speakers. Laura wants to establish a voice session with Bob using the desk phone as the microphone and the soft client as the speaker. Two SIP dialogs will be established: one between the desk phone and Camarillo & Loreto Expires April 23, 2009 [Page 3] Internet-Draft SIP Session Correlation Requirements October 2008 Bob's UA and one between the soft client and Bob's UA. The former dialog will establish a send-only (from Laura's perspective) audio stream. The latter dialog will establish a receive-only (from Laura's perspective) audio stream. Laura wants Bob to treat the send-only audio stream from her deskphone and the receive-only audio stream from her softclient as part of the same communication space. That is, Laura wants Bob to treat both streams as if both had been established using a single SIP dialog. 2.2. Showing a Pre-recorded Video During a Conversation Bob has a voice-only phone and an IP-TV device. Laura has an integrated advanced multimedia phone with camera. Bob is talking on his voice-only phone with Laura, who is on her multimedia phone. Bob wants to show Laura part of the TV show he recorded last night. A SIP dialog between Bob's IP-TV device and Laura's UA needs to be established. This dialog will establish a video stream. Bob talks about the show with Laura on his voice-only phone while Laura watches the show. Bob wants Laura to treat the video stream from his IP-TV device and the voice stream from his voice-only phone as part of the same communication space. That is, Bob wants Laura to treat both streams as if both had been established using a single SIP dialog. 2.3. Sending a File from a PC During a Conversation Bob has a voice-only phone and a PC with a soft client. Laura has an integrated advanced multimedia phone with support for file transfers. Bob wants to send a file to Laura from his PC during his conversation with Laura on his voice-only phone. A SIP dialog between Bob's PC and Laura's multimedia phone needs to be established. This dialog will establish a file transfer session. Bob wants Laura to treat the file transfer from his PC and the voice stream from his voice-only phone as part of the same communication space. That is, Bob wants Laura to treat both streams as if both had been established using a single SIP dialog. Camarillo & Loreto Expires April 23, 2009 [Page 4] Internet-Draft SIP Session Correlation Requirements October 2008 2.4. Including Live Video in a Conversation Bob has a voice-only phone and a PC which has a soft client, a Webcam, and a low-quality built-in microphone. Laura has an integrated advanced multimedia phone with camera. Bob wants to send a live video to Laura from his PC during his conversation with Laura. A SIP dialog between Bob's PC and Laura's multimedia phone needs to be established. This dialog will establish a video stream. Bob wants Laura to treat the live video stream from his PC and the voice stream from his voice-only phone as part of the same communication space. That is, Bob wants Laura to treat both streams as if both had been established using a single SIP dialog. 2.5. Including Remote Live Video in a Conversation Bob, who is at his office, has a multimedia phone. At his summer cottage, Bob has a webcam-phone (e.g. a video-surveillance system). Laura has an integrated advanced multimedia phone with a camera. During his conversation with Laura, Bob wants to show her the new summer cottage he just bought. A SIP dialog between Bob's webcam phone at this summer cottage and Laura's multimedia phone needs to be established. This dialog will establish a video stream. Bob wants Laura to treat the live video stream from his webcam-phone and the voice stream from his voice-only phone as part of the same communication space. That is, Bob wants Laura to treat both streams as if both had been established using a single SIP dialog. 3. Distributed User Agent Server: Use Cases This section lists use cases where the UAS is distributed. That is, the user receiving the session invitation will use several UAs in parallel during the session. 3.1. Using Two Separate UAs in a Conversation Laura has a PC with a softclient and a desk phone. Bob has an integrated advanced multimedia phone with camera. Laura receives on her desk phone an incoming voice-video call from Bob. Camarillo & Loreto Expires April 23, 2009 [Page 5] Internet-Draft SIP Session Correlation Requirements October 2008 Laura decides to answer the Bob's session invitation by establishing a voice session with Bob using the desk phone and the video session using her multimedia phone. Two SIP dialogs need to be established: one between Bob's UA and Laura's desk phone and one between Bob's UA and Laura's multimedia phone. Laura wants Bob to treat the audio stream from her deskphone and the video stream from her softclient as part of the same communication space. That is, Laura wants Bob to treat both streams as if both had been established using a single SIP dialog. 4. Requirements REQ1 It must be possible to correlate an already existing dialog or dialogs with a new dialog or dialogs as relating to the same media session. REQ2 The state information associated to the correlation among a set of SIP dialogs must expire (i.e., can be discarded) when the last of the SIP dialogs is terminated. REQ3 UAs that do not implement the correlation mechanism and, thus, do not understand the correlation information they received should be able to handle the individual SIP dialogs that were supposed to be correlated as well as possible. That is, the correlation mechanism should not keep them from trying to handle the SIP dialogs. 5. Existing Mechanisms This section analyses existing mechanisms against the requirements we have identified. Currently, there is no mechanism that meets those requirements. Thus, a new mechanism will need to be develop in order to meet those requirements. SIP Service Control [RFC3087] proposes to communicate context information using a distinctive Request URI. However, dialogs to be correlated do not necessary share the same Request URI. The Join header field [RFC3911] allows inserting a new participant into a given conversation space. However, 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. Therefore, while the mechanics of the Join mechanism are suitable to correlate dialogs, Camarillo & Loreto Expires April 23, 2009 [Page 6] Internet-Draft SIP Session Correlation Requirements October 2008 the semantics for the correlations created by Join are different than the ones described in the previous requirements. 6. Security Considerations To be done. 7. IANA Considerations This document does not require any actions by the IANA. 8. 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. [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: gonzalo.camarillo@ericsson.com Camarillo & Loreto Expires April 23, 2009 [Page 7] Internet-Draft SIP Session Correlation Requirements October 2008 Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Camarillo & Loreto Expires April 23, 2009 [Page 8] Internet-Draft SIP Session Correlation Requirements October 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 April 23, 2009 [Page 9]