[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: September 6, 2009                                 March 5, 2009


 Requirements for Dialog Correlation in the Session Initiation Protocol
                                 (SIP)
          draft-loreto-sipping-context-id-requirements-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 September 6, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document justifies the need and lists the requirements for
   correlating SIP (Session Initiation Protocol) dialogs.  The



Camarillo & Loreto      Expires September 6, 2009               [Page 1]


Internet-Draft    SIP Session Correlation Requirements        March 2009


   correlated dialogs may or may not be related 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.  The
   logical correlation of two SIP dialogs is also useful, for instance,
   to correlate an incoming with an outgoing dialog at a B2BUA.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Media Session correlation: Use Cases . . . . . . . . . . . . .  4
     2.1.  Using Two Separate UAs to Start a Conversation . . . . . .  4
     2.2.  Showing a Pre-recorded Video During a Conversation . . . .  4
     2.3.  Sending a File from a PC During a Conversation . . . . . .  5
     2.4.  Including Live Video in a Conversation . . . . . . . . . .  5
     2.5.  Including Remote Live Video in a Conversation  . . . . . .  5
     2.6.  Using Two Separate UAs in a Conversation . . . . . . . . .  6
   3.  Dialogs correlation: Use Cases . . . . . . . . . . . . . . . .  6
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Media Session correlation  . . . . . . . . . . . . . . . .  7
     4.2.  Dialog correlation . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Common requirements  . . . . . . . . . . . . . . . . . . .  7
   5.  Existing Mechanisms  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Informational References . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10























Camarillo & Loreto      Expires September 6, 2009               [Page 2]


Internet-Draft    SIP Session Correlation Requirements        March 2009


1.  Introduction

   This document shows the need to logically correlate multiple SIP
   (Session Initiation Protocol) dialogs.  The correlated dialogs may or
   may not be related 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 established by the different SIP dialogs as
   part of a single media session, there is a need to correlate those
   dialogs.

   Also in many situations, the processing of a SIP call involves a
   number of different SIP dialogs that can or can not be related to the
   same multimedia session.  A special case is the presence of the
   B2BUA's and other middle-boxes in the end-to-end path.  A B2BUA is a
   logical entity that acts as both user agent server (UAS) and user
   agent client (UAC), and then breaks an end-to-end SIP dialog in two
   distinct SIP dialogs that are difficult to correlate outside the
   context of the B2BUA.  In order to treat those two different SIP
   dialogs as part of a SIP call, there is a need to correlate those
   dialogs.

   The requirements to correlate different SIP dialogs as part of a
   single media session and the requirements to correlate SIP dialogs
   that belong to the same SIP session but not necessary involve media
   seem to be semantically different.  For this reason this document
   contains two distinct set of requirement one for correlating "media
   sessions" and different one to correlate "dialogs".

   The remainder of this document is organized as follows.  Section 2
   contains use cases where multiple dialogs are required to establish a
   multimedia session.  Section 3 contains use cases where multiple
   dialogs needs to be correlate using a unique identifier.  Section 4
   contains the two set of requirements for a mechanism to correlate SIP
   dialogs.  Section 5 analyzes existing mechanisms against the



Camarillo & Loreto      Expires September 6, 2009               [Page 3]


Internet-Draft    SIP Session Correlation Requirements        March 2009


   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.  Media Session correlation: Use Cases

   This section lists use cases where the UAC or the UAS is distributed.
   That is, the user initiating the session will use several UAs in
   parallel during the session or the user receiving the session
   invitation 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
   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.




Camarillo & Loreto      Expires September 6, 2009               [Page 4]


Internet-Draft    SIP Session Correlation Requirements        March 2009


   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.

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.



Camarillo & Loreto      Expires September 6, 2009               [Page 5]


Internet-Draft    SIP Session Correlation Requirements        March 2009


   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.

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

   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.


3.  Dialogs correlation: Use Cases

   This section lists use cases where multiple dialogs need to be
   correlate.

   1. Certain SIP applications need to reference dialogs in out-of-
      dialog requests at a layer above the SIP message dialog matching
      rules, and wish it to work across B2BUA domains.
      For example, the SIP Media Control Channel Framework
      [I-D.ietf-mediactrl-sip-control-framework] needs to reference a
      dialog identifier used between a UAC and UAS by a third party.
      The mechanism originally used the Call-ID and remote/local-tags
      for such matching, but changed due to concerns over B2BUA's
      changing them, and now uses a new "cfw-id" SDP attribute instead
      which does not rely on the Call-ID value.

   2. Multiple RFC 3265 Event packages use the Call-ID value in their
      package bodies to reference established sessions, even though they
      don't actually need to match a Call-ID per se - and should work
      across B2BUA domains.






Camarillo & Loreto      Expires September 6, 2009               [Page 6]


Internet-Draft    SIP Session Correlation Requirements        March 2009



   3. The call admission control (CAC) only allows SIP INVITE requests
      if the network has sufficient bandwidth for the given SDP.
      However if a call request is forked by B2BUA's, or crosses them,
      the CAC model treats each fork as a separate call because there is
      no mechanism to tie them together.  This leads to rejected forks
      due to CAC, when they should have been allowed to proceed.
      Currently proprietary SIP headers are used for this purpose.

   5. Troubleshooting SIP sessions becomes complicated when multiple
      legs of the session are on different sides of B2BUA's, because it
      is impossible to correlate the legs together.
      Currently proprietary mechanisms are used to achieve this.

   6. When SIP requests cross B2BUA's, the only form of loop detection
      that will stop a loop is the Max-Forwards hop-count limit being
      reached (value reaching zero).  Via header values are removed by
      B2BUA's, so both spirals and simple loops cannot be detected by
      Via branch-parameter matching.
      A mechanism to correlate legs of the sessions on both sides of
      B2BUA's could be used to limit or avoid the loop.



4.  Requirements

4.1.  Media Session correlation

   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.

4.2.  Dialog correlation

   REQ1  It must be possible to identify a set of dialogs which have a
      direct correlation with each other such that they represent the
      same SIP session, with as high a probability as possible.

4.3.  Common requirements

   REQ1  It must be possible, when establishing a dialog, to specify
      that it be correlated with one or more already existing dialogs,
      which dialogs, at the time they were created, did not need to
      specify that they might be correlated with in the future.







Camarillo & Loreto      Expires September 6, 2009               [Page 7]


Internet-Draft    SIP Session Correlation Requirements        March 2009



   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.

   REQ4  It must be possible to correlate outside the context of the
      B2BUA the dialog entering with the one leaving a B2BUA.
      This requirement drives the following requirements:

      REQ4.1  It must be possible for correlated dialogs that pass
         through B2BUA'2 to continue to be correlate.

      REQ4.2  The correlation mechanism must not reveal any information
         related to any SIP device or domain identity, including IP
         Address, port, hostname, domain name, username, Address-of-
         Record, MAC address, IP address family, transport type, etc.

      REQ4.3  The correlation mechanism not reveal to the receiver of it
         that the Call-ID, tags, or any other SIP header or body portion
         have been changed by middle-boxes, with as high a probability
         as possible.



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 September 6, 2009               [Page 8]


Internet-Draft    SIP Session Correlation Requirements        March 2009


   the semantics for the correlations created by Join are different than
   the ones described in the previous requirements.

   The Third Part Call Control mechanism [RFC3725] allows the caller to
   make transparent for the callee the fact that it is using separate
   devices for different media, and then making everything in one dialog
   for the callee.  However there are use cases where it is preferable
   not to use a centralized and heavy mechanism as 3pcc but instead
   using a distributed and lighter mechanism.  Moreover in 3pcc, the
   Controller is a central point for signaling, it has complete control
   over the call and then it needs to be involved for all the session
   time.  With a correlation mechanism the UA that establishes the first
   dialog does not necessarily need to be involved all the session time.
   It could leave the session before the whole session ends.


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.

   [I-D.ietf-mediactrl-sip-control-framework]
              Boulton, C., Melanchuk, T., and S. McGlashan, "Media
              Control Channel Framework",
              draft-ietf-mediactrl-sip-control-framework-10 (work in
              progress), February 2009.

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




Camarillo & Loreto      Expires September 6, 2009               [Page 9]


Internet-Draft    SIP Session Correlation Requirements        March 2009


   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
              Camarillo, "Best Current Practices for Third Party Call
              Control (3pcc) in the Session Initiation Protocol (SIP)",
              BCP 85, RFC 3725, April 2004.


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 September 6, 2009              [Page 10]


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