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

Versions: 00 01 02

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]


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