One document matched: draft-schmidt-mmusic-media-dependency-00.txt

Network Working Group                                        Ch. Schmidt
Internet-Draft                                          Siemens Networks
Intended status: Standards Track                        January 18, 2007
Expires: July 22, 2007


      The SDP (Session Description Protocol) Dependency Attribute
                draft-schmidt-mmusic-media-dependency-00

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 July 22, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Schmidt                   Expires July 22, 2007                 [Page 1]

Internet-Draft          SDP Dependency attribute            January 2007


Abstract

   The Session Description Protocol (SDP) was intended for describing
   multimedia sessions for the purposes of session announcement, session
   invitation, and other forms of multimedia session initiation.
   Together with Offer/Answer model it defines a mechanism, how two
   entities can reach a common view of a multimedia session between
   them.

   In certain cases, there are dependencies between media streams, for
   example a text stream for subtitling make sense only together with a
   video stream.  To avoid senseless connections, the SDP mechanism can
   be extended with a new Session Description Protocol (SDP) media-level
   attribute: "dependency".  The "dependency" attribute allows the
   offerer to define dependencies of media streams.  The updated offer/
   answer mechanism used with new "dependency" attribute can be used
   furthermore, that in a multi-party SIP session all participants share
   at least one common media type.

































Schmidt                   Expires July 22, 2007                 [Page 2]

Internet-Draft          SDP Dependency attribute            January 2007


1.  Introduction

   The overall framework for tightly coupled SIP conferencing is defined
   in RFC 4353 [5].  The conferencing architecture defines the central
   component called 'focus'.  The focus maintains a SIP signaling
   relationship with each participant in the conference.  Each
   conference is composed of a particular set of media types that the
   focus is managing.  The standard offer/answer techniques defined in
   RFC 3264 [4] are used for adding and removing media types in the
   conference.  When the set of media types in the conference changes,
   the focus will need to generate a re-INVITE to each participant in
   order to add or remove the media streams.  When a media stream is
   being added, a participant can reject the offered media stream, in
   which case he will not receive or contribute to that stream.
   Rejection of a stream by a participant does not imply that the stream
   is no longer part of the conference, only that this participant is
   not involved in it.

   In some cases, there are dependencies between media streams.  For
   example, a text-stream for subtitling may only make sense together
   with a video stream.  Knowledge about these dependencies can avoid
   setup of senseless connections.  This information is not included in
   the current SDP specifications.  A solution could be an enhancement
   of offer/answer model that allows to the offerer to indicate in the
   offer, that one media stream can be accepted only if another
   dependant media streams are also accepted.

   The Offer/answer model as defined now does not allow to define
   dependencies between media streams.  This specification defines a
   solution how the SDP (defined in RFC 4566 [3]) can be enhanced with a
   new attribute that allows the definition of media dependencies and
   the marking of media streams as mandatory or optional.

   The current treatment of multimedia conferences may potentially lead
   to multi-party multimedia conferences where, after the conference is
   set up, different conference participants use different, non
   overlapping, media type sets in one conference so no content can be
   delivered to all the conference participants.  As an example, if one
   conference user A uses audio together with text messaging, user B
   uses audio only and user C uses text messaging only.  In such a
   configuration, the user B cannot communicate directly with user C,
   the information exchange can be done only via user A. This
   configuration can be in some cases undesired.

   The updated offer/answer mechanism used with new "dependency"
   attribute can also be used, to avoid this behavior.  It could be
   achieved, that in a multi-party SIP session all participants share at
   least one common media type.



Schmidt                   Expires July 22, 2007                 [Page 3]

Internet-Draft          SDP Dependency attribute            January 2007


2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.












































Schmidt                   Expires July 22, 2007                 [Page 4]

Internet-Draft          SDP Dependency attribute            January 2007


3.  Motivation for the New Dependency Attribute

   Even though the order of 'm' lines in offer can be considered as
   preference of the offerer, the handling defined in Offer/Answer model
   [4] limits the usage of such an ordered list.  As the order of the
   media-lines in an offer cannot be changed in the subsequent offer of
   the same SIP session, the newly offered media stream cannot be placed
   to the position in the ordered list wished by the offerer.

   The SDP [3] and its extensions already define several attributes to
   be used on the media-level, but none of them is appropriate to be
   used in the context of ordering media streams based on the
   preferences of the offerer.

   The most desirable seems to be the 'i' line, defined in RFC 4566 [3],
   that can be used to label media streams with any text value,
   including the number.  Nevertheless, values of the 'i' line are
   intended for human users and not for automata.  Moreover, the usage
   of 'i' line for other purpose than defining of media stream
   dependencies (for example by clients not supporting extension defined
   in this document) may lead to interoperability problems.

   Also usage of some other possible attributes defined in RFC 4566 [3]
   and its extensions can be considered as their misuse and is not
   recommended.


























Schmidt                   Expires July 22, 2007                 [Page 5]

Internet-Draft          SDP Dependency attribute            January 2007


4.  The Dependency Attribute

   This specification defines a new media-level value attribute:
   "dependency".  Its formatting in SDP is described by the following
   BNF [2]:

      dependency-attribute = "a=dependency:mandatory=" pointers
      ";optional=" pointers / "a=dependency:mandatory=" pointers /
      "a=dependency:optional=" pointers

      pointers = pointer *( "," pointer)

      pointer = token

      token = 1*(token-char)

      token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39

      / %x41-5A / %x5E-7E

      The pointer element is defined in the SDP Label Attribute [7] but
      included here to provide support for the implementor of this SDP
      feature.

      This new "dependency" attribute SHALL contain one or two lists of
      SDP Labels - mandatory and optional.  Each list SHALL contain a
      list of tokens defined by an offerer (or her application) that are
      connected to media stream in the SDP message.

      The mandatory list contains dependencies that must be fulfilled in
      order to ensure the correct session setup, while the optional list
      contains the dependencies that are recommeded to the answerer.
      E.g. subtitling does not make sense without video (mandatory
      dependency), while subtitling with video is useful but not
      necessary (optional dependency).

   Example (see also section 6):

      a=dependency:mandatory=1,3;optional=2












Schmidt                   Expires July 22, 2007                 [Page 6]

Internet-Draft          SDP Dependency attribute            January 2007


5.  The Dependency Attribute in Offer/Answer Model

   In this section, we define extensions to the offer/answer model
   defined in RFC3264 [4] to allow establishment of the multimedia
   session with media stream dependencies.

   An offerer that wants to use dependency extension defined in this
   document MAY include the "dependency" attribute in each media-level
   section in the SDP offer.  In addition, each media stream in the SDP
   message generated by the offerer, which is referenced in an
   "dependency" attribute of another media stream, MUST include the
   label attribute defined in RFC4574 [7].

   When the answerer receives an offer with "dependency" attributes and
   supports extension defined in this document, the answerer SHALL use
   the following rules when generating the answer:

      (1) When any media stream from the offer is accepted, all media
      streams with label listed as mandatory in the "dependency"
      attribute MUST be accepted too.

      (2) When any media label included in the mandatory list is not
      recognized as valid label of any media included in the SDP
      message, the answerer SHALL reject the entire offered session.

   This specification does not mandate any handling for the media types
   with labels listed as optional in the "dependency" attribute, but it
   is RECOMMENDED that when any media stream from the offer is accepted,
   all media streams with label listed as optional in the "dependency"
   attribute are accepted by the application too.





















Schmidt                   Expires July 22, 2007                 [Page 7]

Internet-Draft          SDP Dependency attribute            January 2007


6.  Example

   The following is an example of an SDP session description that uses
   the "dependency" attribute:

      v=0

      c=IN IP4 1.2.3.4

      m=audio 1234 RTP/AVP ...

      a=label:1

      m=video 2346 RTP/AVP ...

      a=label:2

      a=dependency:mandatory=1;optional=3

      m=message 3456 TCP/MSRP ...

      i=subtitles for audio

      a=label:3

      a=dependency:mandatory=2

   The example above, when used in the offer, represents the session
   where at least audio shall be used by all multi-party multimedia
   session participants.  Video can be used only together with audio.
   Subtitles can be used only together with audio and video.  Video is
   recommended to be used together with subtitles.



















Schmidt                   Expires July 22, 2007                 [Page 8]

Internet-Draft          SDP Dependency attribute            January 2007


7.  Security Considerations

   An attacker may attempt to add, modify, or remove "dependency"
   attributes from a session description.  This could result in an
   application behaving in a non-desirable way.  So, it is strongly
   RECOMMENDED that integrity protection be applied to the SDP session
   descriptions.  For session descriptions carried in SIP RFC3261 [6],
   S/MIME is the natural choice to provide such end-to-end integrity
   protection, as described in [6] Other applications MAY use a
   different form of integrity protection.









































Schmidt                   Expires July 22, 2007                 [Page 9]

Internet-Draft          SDP Dependency attribute            January 2007


8.  IANA Considerations

      Contact name: NN nn@nn.com

      Attribute name: "dependency".

      Type of attribute: Media level.

      Subject to charset: Not.

      Purpose of attribute: The 'dependency' attribute allows definition
      of media stream dependencies in the offer.  The media stream
      dependencies allow establishment of multi-party multimedia session
      where all participants share at least one common media type.

      Allowed attribute values: Mandatory and optional lists of tokens
      with media stream labels


































Schmidt                   Expires July 22, 2007                [Page 10]

Internet-Draft          SDP Dependency attribute            January 2007


9.  Acknowledgements


















































Schmidt                   Expires July 22, 2007                [Page 11]

Internet-Draft          SDP Dependency attribute            January 2007


10.  References

   [1]  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [3]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

   [4]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        the Session Description Protocol (SDP)", RFC 3264, June 2002.

   [5]  Rosenberg, J., "A Framework for Conferencing with the Session
        Initiation Protocol (SIP)", RFC 4353, February 2006.

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

   [7]  Levin, O. and G. Camarillo, "The Session Description Protocol
        (SDP) Label Attribute", August 2006.




























Schmidt                   Expires July 22, 2007                [Page 12]

Internet-Draft          SDP Dependency attribute            January 2007


Author's Address

   Christian Schmidt
   Siemens Networks
   St.-Martin-Str.76
   Munich  81617
   Germany

   Phone: +49 89 636 75192
   Email: christian-schmidt@siemens.com









































Schmidt                   Expires July 22, 2007                [Page 13]

Internet-Draft          SDP Dependency attribute            January 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Schmidt                   Expires July 22, 2007                [Page 14]