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]