draft-ietf-mmusic-sdp-media-content-04.txt   draft-ietf-mmusic-sdp-media-content-05.txt 
MMUSIC Working Group J. Hautakorpi MMUSIC Working Group J. Hautakorpi
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Expires: January 1, 2007 Ericsson Expires: March 1, 2007 Ericsson
June 30, 2006 August 28, 2006
The SDP (Session Description Protocol) Content Attribute The SDP (Session Description Protocol) Content Attribute
draft-ietf-mmusic-sdp-media-content-04.txt draft-ietf-mmusic-sdp-media-content-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 1, 2007. This Internet-Draft will expire on March 1, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines a new Session Description Protocol (SDP) media- This document defines a new Session Description Protocol (SDP) media-
level attribute, 'content'. The 'content' attribute defines the level attribute, 'content'. The 'content' attribute defines the
content of the media stream in more detailed level than the media content of the media stream in more detailed level than the media
description line. The sender of an SDP session description can description line. The sender of an SDP session description can
attach the 'content' attribute to one or more media streams. The attach the 'content' attribute to one or more media streams. The
receiving application can then treat each media stream differently receiving application can then treat each media stream differently
(e.g., show it on a big screen or small screen) based on its content. (e.g., show it on a big screen or small screen) based on its content.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related Techniques . . . . . . . . . . . . . . . . . . . . . 3 3. Related Techniques . . . . . . . . . . . . . . . . . . . . . . 3
4. Motivation for the New Content Attribute . . . . . . . . . . 4 4. Motivation for the New Content Attribute . . . . . . . . . . . 4
5. The Content Attribute . . . . . . . . . . . . . . . . . . . 5 5. The Content Attribute . . . . . . . . . . . . . . . . . . . . 5
6. The Content Attribute in the Offer/Answer Model . . . . . . 6 6. The Content Attribute in the Offer/Answer Model . . . . . . . 6
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Operation with SMIL . . . . . . . . . . . . . . . . . . . . 8 8. Operation with SMIL . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1 Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2 Informational References . . . . . . . . . . . . . . . . 10 12.2. Informational References . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [1] is a protocol that is The Session Description Protocol (SDP) [1] is a protocol that is
intended for describing multimedia sessions for the purposes of intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of session announcement, session invitation, and other forms of
multimedia session initiation. One of the most typical use cases of multimedia session initiation. One of the most typical use cases of
SDP is the one where it is used with the Session Initiation Protocol SDP is the one where it is used with the Session Initiation Protocol
(SIP) [5]. (SIP) [5].
skipping to change at page 5, line 20 skipping to change at page 5, line 23
5. The Content Attribute 5. The Content Attribute
This specification defines a new media-level value attribute, This specification defines a new media-level value attribute,
'content'. Its formatting in SDP is described by the following BNF 'content'. Its formatting in SDP is described by the following BNF
[2]: [2]:
content-attribute = "a=content:" mediacnt-tag content-attribute = "a=content:" mediacnt-tag
mediacnt-tag = mediacnt *("," mediacnt) mediacnt-tag = mediacnt *("," mediacnt)
mediacnt = "slides" / "speaker" / "sl" / "main" mediacnt = "slides" / "speaker" / "sl" / "main"
/ "alt" / "user-floor" / "txp" / "alt" / mediacnt-ext
/ mediacnt-ext
mediacnt-ext = token mediacnt-ext = token
The 'content' attribute contains a token, which MAY be attached to a The 'content' attribute contains a token, which MAY be attached to a
media stream by a sending application. It describes the content of media stream by a sending application. It describes the content of
the transmitted media stream to the receiving application. Multiple the transmitted media stream to the receiving application. Multiple
'content' attribute values MAY be attached to a single media stream. 'content' attribute values MAY be attached to a single media stream.
This document provides a set of pre-defined values for the 'content' This document provides a set of pre-defined values for the 'content'
attribute. Other values can be defined in the future. The pre- attribute. Other values can be defined in the future. The pre-
defined values are: defined values are:
skipping to change at page 6, line 16 skipping to change at page 6, line 16
A typical use case for this is a concert, where the camera is A typical use case for this is a concert, where the camera is
shooting the performer. shooting the performer.
alt: This means that the media stream is taken from the alternative alt: This means that the media stream is taken from the alternative
source. A typical use case for this is an event, where there is a source. A typical use case for this is an event, where there is a
separate ambient sound and the main sound. The alternative audio separate ambient sound and the main sound. The alternative audio
stream could be e.g., the sound of a jungle. Another example is stream could be e.g., the sound of a jungle. Another example is
the video of the conference room while the main is the video of the video of the conference room while the main is the video of
the speaker. This is similar to the 'live' role in H.239. the speaker. This is similar to the 'live' role in H.239.
user-floor: This indicates that a user level floor control is
required. In other words, human users have to take care of the
floor control. The user interface of the receiving application
must indicate the need for user level floor control to the human
user.
A typical use case is a situation where the other endpoint of the
connection is a walkie-talkie type of device, and human users must
say 'over' each time they stop transmitting.
txp: This indicates that the media stream is originated from a
textphone that is incapable of handling simultaneous two-way
communication. This limitation requires special behavior from the
user of a terminal receiving the indication. The indication
should be used for an indication in the user interface.
A typical use case is a connection where one endpoint is an analog
textphone of a kind that cannot handle two-way simultaneous text
communication, and the other one is a native IP based real time
text capable terminal. The human user of the IP terminal need to
change behaviour when this indication is received, and apply
formal turn-taking habits. They may also need to figure out to
what extent it is possible to interrupt the other party if the
need arises.
All of these values can be used with any media type. The application All of these values can be used with any media type. The application
can make decisions on how to handle a single media stream based on can make decisions on how to handle a single media stream based on
both the media type and the value of the 'content' attribute. both the media type and the value of the 'content' attribute.
Therefore the situation where one value of 'content' attribute occurs Therefore the situation where one value of 'content' attribute occurs
more than once in a single session descriptor is not problematic. more than once in a single session descriptor is not problematic.
6. The Content Attribute in the Offer/Answer Model 6. The Content Attribute in the Offer/Answer Model
This specification does not define a means to discover whether or not This specification does not define a means to discover whether or not
the peer endpoint understands the 'content' attribute because the peer endpoint understands the 'content' attribute because
skipping to change at page 9, line 17 skipping to change at page 8, line 34
Attribute name: 'content'. Attribute name: 'content'.
Type of attribute Media level. Type of attribute Media level.
Subject to charset: No. Subject to charset: No.
Purpose of attribute: The 'content' attribute gives information from Purpose of attribute: The 'content' attribute gives information from
the content of the media stream to the receiving application. the content of the media stream to the receiving application.
Allowed attribure values: "slides", "speaker", "sl", "main", "alt", Allowed attribure values: "slides", "speaker", "sl", "main", "alt",
"user-floor", "txp", and any other and any other registered values.
registered values.
The IANA is requested to create a subregistry for 'content' attribute The IANA is requested to create a subregistry for 'content' attribute
values under the Session Description Protocol (SDP) Parameters values under the Session Description Protocol (SDP) Parameters
registry. The initial values for the subregistry are presented in registry. The initial values for the subregistry are presented in
the following, and IANA is requested to add them into its database: the following, and IANA is requested to add them into its database:
Value of 'content' attribute Reference Description Value of 'content' attribute Reference Description
---------------------------- --------- ----------- ---------------------------- --------- -----------
slides RFC xxxx Presentation slides slides RFC xxxx Presentation slides
speaker RFC xxxx Image from the speaker speaker RFC xxxx Image from the speaker
sl RFC xxxx Sign language sl RFC xxxx Sign language
main RFC xxxx Main media stream main RFC xxxx Main media stream
alt RFC xxxx Alternative media stream alt RFC xxxx Alternative media stream
user-floor RFC xxxx User level floor control req.
txp RFC xxxx Media from a textphone
Note for the RFC Editor: The 'RFC xxxx' in the above should be a Note for the RFC Editor: The 'RFC xxxx' in the above should be a
reference to the coming RFC number of this draft. reference to the coming RFC number of this draft.
As per the terminology in RFC 2434 [4], the registration policy for As per the terminology in RFC 2434 [4], the registration policy for
new values for the 'content' parameter shall be 'Specification new values for the 'content' parameter shall be 'Specification
Required'. Required'.
If new values for the 'content' attribute are specified in the
future, they should consist of a meta description of the contents of
a media stream. New values for the 'content' attribute should not
describe things like what to do in order to handle a stream.
11. Acknowledgements 11. Acknowledgements
Authors would like to thank Arnoud van Wijk and Roni Even, who Authors would like to thank Arnoud van Wijk and Roni Even, who
provided valuable ideas for this document. We wish to thank also Tom provided valuable ideas for this document. We wish to thank also Tom
Taylor for a thorough review. Taylor for a thorough review.
12. References 12. References
12.1 Normative References 12.1. Normative References
[1] Handley, M., "SDP: Session Description Protocol", [1] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
12.2 Informational References 12.2. Informational References
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
 End of changes. 11 change blocks. 
53 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/