summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4574.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4574.txt')
-rw-r--r--doc/rfc/rfc4574.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc4574.txt b/doc/rfc/rfc4574.txt
new file mode 100644
index 0000000..56144a3
--- /dev/null
+++ b/doc/rfc/rfc4574.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group O. Levin
+Request for Comments: 4574 Microsoft Corporation
+Category: Standards Track G. Camarillo
+ Ericsson
+ August 2006
+
+
+ The Session Description Protocol (SDP) Label Attribute
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines a new Session Description Protocol (SDP)
+ media-level attribute: "label". The "label" attribute carries a
+ pointer to a media stream in the context of an arbitrary network
+ application that uses SDP. The sender of the SDP document can attach
+ the "label" attribute to a particular media stream or streams. The
+ application can then use the provided pointer to refer to each
+ particular media stream in its context.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Terminology .....................................................2
+ 3. Motivation for the New label Attribute ..........................2
+ 4. The Label Attribute .............................................3
+ 5. The Label Attribute in the Offer/Answer Model ...................4
+ 6. Example .........................................................4
+ 7. Security Considerations .........................................4
+ 8. IANA Considerations .............................................5
+ 9. Acknowledgements ................................................5
+ 10. References .....................................................6
+ 10.1. Normative References ......................................6
+ 10.2. Informative References ....................................6
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 1]
+
+RFC 4574 SDP Label Attribute August 2006
+
+
+1. Introduction
+
+ SDP is being used by a variety of distributed-over-the-network
+ applications. These applications deal with multiple sessions being
+ described by SDP [4] and serving multiple users or services in the
+ context of a single application instance. Applications of this kind
+ need a means to identify a particular media stream across multiple
+ SDP descriptions exchanged with different users.
+
+ The XCON framework is an example of a centralized conference
+ architecture that uses SDP according to the offer/answer mechanism
+ defined in [3] to establish media streams with each of the conference
+ participants. Additionally, XCON identifies the need to uniquely
+ identify a media stream in terms of its role in a conference
+ regardless of its media type, transport protocol, and media format.
+ This can be accomplished by using an external document that points to
+ the appropriate media stream and provides information (e.g., the
+ media stream's role in the conference) about it. The SIP Event
+ Package for Conference State [7] defines and uses a concrete format
+ for such external documents.
+
+ This specification defines the SDP [4] "label" media-level attribute,
+ which provides a pointer to a media stream that is described by an
+ 'm' line in an SDP session description.
+
+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.
+
+3. Motivation for the New label Attribute
+
+ Even though SDP and its extensions already provide a few ways to
+ refer to a media stream, none of them is appropriate to be used in
+ the context of external documents that may be created before the
+ session description itself and need to be handled by automata.
+
+ The 'i' SDP attribute, defined in RFC 2327 [4], can be used to label
+ media streams. Nevertheless, values of the 'i' attribute are
+ intended for human users and not for automata.
+
+
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 2]
+
+RFC 4574 SDP Label Attribute August 2006
+
+
+ The 'mid' SDP attribute, defined in RFC 3388 [6], can be used to
+ identify media streams as well. Nevertheless, the scope of 'mid' is
+ too limited to be used by applications dealing with multiple SDP
+ sessions. This is because values of the 'mid' attribute are
+ meaningful in the context of a single SDP session, not in the context
+ of a broader application (e.g., a multiparty application).
+
+ Another way of referring to a media stream is by using the order of
+ the 'm' line in the SDP session document (e.g., the 5th media stream
+ in the session description). This is the mechanism used in the
+ offer/answer model [3].
+
+ The problem with this mechanism is that it can only be used to refer
+ to media streams in session descriptions that exist already. There
+ are scenarios where a static document needs to refer, using a
+ pointer, to a media stream that will be negotiated by SDP means and
+ created in the future. When the media stream is eventually created,
+ the application needs to label the media stream so that the pointer
+ in the static document points to the proper media stream in the
+ session description.
+
+4. The Label Attribute
+
+ This specification defines a new media-level value attribute:
+ 'label'. Its formatting in SDP is described by the following ABNF
+ [2]:
+
+ label-attribute = "a=label:" pointer
+
+ pointer = token
+
+ token = 1*(token-char)
+
+ token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
+ / %x41-5A / %x5E-7E
+
+ The token-char and token elements are defined in [4] but included
+ here to provide support for the implementor of this SDP feature.
+
+ The 'label' attribute contains a token that is defined by an
+ application and is used in its context. The new attribute can be
+ attached to 'm' lines in multiple SDP documents allowing the
+ application to logically group the media streams across SDP sessions
+ when necessary.
+
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 3]
+
+RFC 4574 SDP Label Attribute August 2006
+
+
+5. The Label Attribute in the Offer/Answer Model
+
+ This specification does not define a means to discover whether or not
+ the peer endpoint understands the 'label' attribute because 'label'
+ values are informative only at the offer/answer model level.
+
+ At the offer/answer level, it means that the fact that an offer does
+ not contain label attributes does not imply that the answer should
+ not have them. It also means that the fact that an offer contains
+ label attributes does not imply that the answer should have them too.
+
+ In addition to the basic offer/answer rule above, applications that
+ use 'label' as a pointer to media streams MUST specify its usage
+ constraints. For example, such applications MAY mandate support for
+ 'label'. In this case, the application will define means for
+ negotiation of the 'label' attribute support as a part of its
+ specification.
+
+6. Example
+
+ The following is an example of an SDP session description that uses
+ the 'label' attribute:
+
+ v=0
+ o=bob 280744730 28977631 IN IP4 host.example.com
+ s=
+ i=A Seminar on the session description protocol
+ c=IN IP4 192.0.2.2
+ t=0 0
+ m=audio 6886 RTP/AVP 0
+ a=label:1
+ m=audio 22334 RTP/AVP 0
+ a=label:2
+
+7. Security Considerations
+
+ An attacker may attempt to add, modify, or remove 'label' 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 [5], S/MIME is the natural choice
+ to provide such end-to-end integrity protection, as described in RFC
+ 3261 [5]. Other applications MAY use a different form of integrity
+ protection.
+
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 4]
+
+RFC 4574 SDP Label Attribute August 2006
+
+
+8. IANA Considerations
+
+ The IANA has registered the following new SDP attribute:
+
+ Contact name: Orit Levin oritl@microsoft.com.
+
+ Attribute name: "label".
+
+ Type of attribute: Media level.
+
+ Subject to charset: Not.
+
+ Purpose of attribute: The 'label' attribute associates a media
+ stream with a label. This label allows the media stream to be
+ referenced by external documents.
+
+ Allowed attribute values: A token.
+
+9. Acknowledgements
+
+ Robert Sparks, Adam Roach, and Rohan Mahy provided useful comments on
+ this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 5]
+
+RFC 4574 SDP Label Attribute August 2006
+
+
+10. References
+
+10.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
+ Session Description Protocol (SDP)", RFC 3264, June 2002.
+
+ [4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+10.2. Informative References
+
+ [5] 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.
+
+ [6] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
+ "Grouping of Media Lines in the Session Description Protocol
+ (SDP)", RFC 3388, December 2002.
+
+ [7] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
+ Initiation Protocol (SIP) Event Package for Conference State",
+ RFC 4575, August 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 6]
+
+RFC 4574 SDP Label Attribute August 2006
+
+
+Authors' Addresses
+
+ Orit Levin
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ EMail: oritl@microsoft.com
+
+
+ Gonzalo Camarillo
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Gonzalo.Camarillo@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 7]
+
+RFC 4574 SDP Label Attribute August 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Levin & Camarillo Standards Track [Page 8]
+