draft-ietf-mmusic-sdp-source-attributes-01.txt   draft-ietf-mmusic-sdp-source-attributes-02.txt 
MMUSIC J. Lennox MMUSIC J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Intended status: Standards Track J. Ott Intended status: Standards Track J. Ott
Expires: August 28, 2008 Helsinki University of Technology Expires: May 4, 2009 Helsinki University of Technology
T. Schierl T. Schierl
Fraunhofer HHI Fraunhofer HHI
February 25, 2008 October 31, 2008
Source-Specific Media Attributes in the Session Description Protocol Source-Specific Media Attributes in the Session Description Protocol
(SDP) (SDP)
draft-ietf-mmusic-sdp-source-attributes-01 draft-ietf-mmusic-sdp-source-attributes-02
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 38 skipping to change at page 1, line 38
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 August 28, 2008. This Internet-Draft will expire on May 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Session Description Protocol provides mechanisms to describe The Session Description Protocol provides mechanisms to describe
attributes of multimedia sessions and of individual media streams attributes of multimedia sessions and of individual media streams
(e.g., Real-time Transport Protocol (RTP) sessions) within a (e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session, but does not provide any mechanism to describe multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. This document individual media sources within a media stream. This document
defines a mechanism to describe RTP media sources, identified by defines a mechanism to describe RTP media sources, identified by
their Synchronization Source Identifiers (SSRCs), in SDP, associate their Synchronization Source Identifiers (SSRCs), in SDP, associate
skipping to change at page 2, line 38 skipping to change at page 2, line 34
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 13 12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 13
12.2. Registry for Source-Level Attributes . . . . . . . . . . . 14 12.2. Registry for Source-Level Attributes . . . . . . . . . . . 14
12.3. Registry for Source Grouping Semantics . . . . . . . . . . 15 12.3. Registry for Source Grouping Semantics . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 17 Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 17
A.1. Changes From Working Group Draft -00 . . . . . . . . . . . 17 A.1. Changes From Working Group Draft -01 . . . . . . . . . . . 17
A.2. Changes From Individual Submission Draft -01 . . . . . . . 17 A.2. Changes From Working Group Draft -00 . . . . . . . . . . . 17
A.3. Changes From Individual Submission Draft -00 . . . . . . . 17 A.3. Changes From Individual Submission Draft -01 . . . . . . . 17
A.4. Changes From Individual Submission Draft -00 . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] provides mechanisms The Session Description Protocol (SDP) [RFC4566] provides mechanisms
to describe attributes of multimedia sessions and of media streams to describe attributes of multimedia sessions and of media streams
(e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within
a multimedia session, but does not provide any mechanism to describe a multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. individual media sources within a media stream.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
example, MIKEY [RFC3830][RFC4567]), the values used MUST be example, MIKEY [RFC3830][RFC4567]), the values used MUST be
consistent. (These attributes MAY provide additional information consistent. (These attributes MAY provide additional information
about a source described by an "ssrc" attribute, or MAY describe about a source described by an "ssrc" attribute, or MAY describe
additional sources.) additional sources.)
Though the source-level attributes specified by the ssrc property Though the source-level attributes specified by the ssrc property
follow the same syntax as session-level and media-level attributes, follow the same syntax as session-level and media-level attributes,
they are defined independently. All source-level attributes MUST be they are defined independently. All source-level attributes MUST be
registered with IANA, using the registry defined in Section 12.2. registered with IANA, using the registry defined in Section 12.2.
Figure 9 in Section 10 gives a formal Augmented Backus-Naur Form Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the ssrc attribute. (ABNF) [RFC5234] grammar for the ssrc attribute.
The "ssrc" media attribute is not dependent on charset. The "ssrc" media attribute is not dependent on charset.
4.2. The "ssrc-group" Media Attribute 4.2. The "ssrc-group" Media Attribute
a=ssrc-group:<semantics> <ssrc-id> ... a=ssrc-group:<semantics> <ssrc-id> ...
The SDP media attribute "ssrc-group" expresses a relationship among The SDP media attribute "ssrc-group" expresses a relationship among
several sources of an RTP session. It is analogous to the "group" several sources of an RTP session. It is analogous to the "group"
skipping to change at page 7, line 19 skipping to change at page 7, line 19
The ssrc-group attribute indicates the sources in a group by listing The ssrc-group attribute indicates the sources in a group by listing
the <ssrc-id>s of the sources in the group. It MUST list at least the <ssrc-id>s of the sources in the group. It MUST list at least
one <ssrc-id> for a group, and MAY list any number of additional one <ssrc-id> for a group, and MAY list any number of additional
ones. Every <ssrc-id> listed in an ssrc-group attribute MUST be ones. Every <ssrc-id> listed in an ssrc-group attribute MUST be
defined by a corresponding "ssrc:" line in the same media defined by a corresponding "ssrc:" line in the same media
description. description.
The "ssrc-group" media attribute is not dependent on charset. The "ssrc-group" media attribute is not dependent on charset.
Figure 10 in Section 10 gives a formal Augmented Backus-Naur Form Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the ssrc-group attribute. (ABNF) [RFC5234] grammar for the ssrc-group attribute.
5. Usage of Identified Source Identifiers in RTP 5. Usage of Identified Source Identifiers in RTP
The synchronization source identifiers used in an RTP session are The synchronization source identifiers used in an RTP session are
chosen randomly and independently by endpoints. As such, it is chosen randomly and independently by endpoints. As such, it is
possible for two RTP endpoints to choose the same SSRC identifier. possible for two RTP endpoints to choose the same SSRC identifier.
Though the probability of this is low, the RTP specification Though the probability of this is low, the RTP specification
[RFC3550] requires that all RTP endpoints MUST be prepared to detect [RFC3550] requires that all RTP endpoints MUST be prepared to detect
and resolve collisions. and resolve collisions.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
SSRC with a different CNAME, it SHOULD assume there has been an SSRC SSRC with a different CNAME, it SHOULD assume there has been an SSRC
collision, and that the description of the source that was carried in collision, and that the description of the source that was carried in
the SDP description is not applicable to the actual source being the SDP description is not applicable to the actual source being
received. This source attribute is REQUIRED to be present if any received. This source attribute is REQUIRED to be present if any
source attributes are present for a source. The cname attribute MUST source attributes are present for a source. The cname attribute MUST
NOT occur more than once for the same ssrc-id within a given media NOT occur more than once for the same ssrc-id within a given media
stream. stream.
The "cname" source attribute is not dependent on charset. The "cname" source attribute is not dependent on charset.
Figure 11 in Section 10 gives a formal Augmented Backus-Naur Form Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the cname attribute. (ABNF) [RFC5234] grammar for the cname attribute.
6.2. The "previous-ssrc" Source Attribute 6.2. The "previous-ssrc" Source Attribute
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ... a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...
The "previous-ssrc" source attribute associates a media source with The "previous-ssrc" source attribute associates a media source with
previous source identifiers used for the same media source. previous source identifiers used for the same media source.
Following an SSRC change due to an SSRC collision involving a media Following an SSRC change due to an SSRC collision involving a media
source described in SDP, the updated session description describing source described in SDP, the updated session description describing
skipping to change at page 10, line 7 skipping to change at page 10, line 7
media source, the previous-ssrc attribute SHOULD be included if the media source, the previous-ssrc attribute SHOULD be included if the
session description was generated before the participant timeout of session description was generated before the participant timeout of
the old SSRC, and MAY be included after that point. This attribute, the old SSRC, and MAY be included after that point. This attribute,
if present, MUST list at least one previous SSRC, and MAY list any if present, MUST list at least one previous SSRC, and MAY list any
number of additional SSRCs for the source, if the source has collided number of additional SSRCs for the source, if the source has collided
more than once. This attribute MUST be present only once for each more than once. This attribute MUST be present only once for each
source. source.
The "previous-ssrc" source attribute is not dependent on charset. The "previous-ssrc" source attribute is not dependent on charset.
Figure 12 in Section 10 gives a formal Augmented Backus-Naur Form Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form
(ABNF) [RFC5234] grammar for the previous-ssrc attribute. (ABNF) [RFC5234] grammar for the previous-ssrc attribute.
6.3. The "fmtp" Source Attribute 6.3. The "fmtp" Source Attribute
a=ssrc:<ssrc> fmtp:<format> <format specific parameters> a=ssrc:<ssrc> fmtp:<format> <format specific parameters>
The "fmtp" source attribute allows format-specific parameters to be The "fmtp" source attribute allows format-specific parameters to be
conveyed about a given source. The <format> parameter MUST be one of conveyed about a given source. The <format> parameter MUST be one of
the media formats (i.e., RTP payload types) specified for the media the media formats (i.e., RTP payload types) specified for the media
stream. The meaning of the <format specific parameters> is unique stream. The meaning of the <format specific parameters> is unique
skipping to change at page 10, line 42 skipping to change at page 10, line 42
7. Examples 7. Examples
This section gives several examples of SDP descriptions of media This section gives several examples of SDP descriptions of media
sessions containing source attributes. For brevity, only the media sessions containing source attributes. For brevity, only the media
sections of the descriptions are given. sections of the descriptions are given.
m=audio 49168 RTP/AVP 0 m=audio 49168 RTP/AVP 0
a=ssrc:314159 cname:user@example.com a=ssrc:314159 cname:user@example.com
Figure 6: Example: declaration of a single synchronization source Figure 1: Example: declaration of a single synchronization source
The example in Figure 6 shows an audio stream advertising a single The example in Figure 1 shows an audio stream advertising a single
source. source.
m=video 49170 RTP/AVP 96 m=video 49170 RTP/AVP 96
a=rtpmap:96 H264/90000 a=rtpmap:96 H264/90000
a=ssrc:12345 cname:another-user@example.com a=ssrc:12345 cname:another-user@example.com
a=ssrc:67890 cname:another-user@example.com a=ssrc:67890 cname:another-user@example.com
Figure 7: Example: a media stream containing several independent Figure 2: Example: a media stream containing several independent
sources from a single session member. sources from a single session member.
The example in Figure 7 shows a video stream where one participant The example in Figure 2 shows a video stream where one participant
(identified by a single CNAME) has several cameras. The sources (identified by a single CNAME) has several cameras. The sources
could be further distinguished by RTCP Source Description (SDES) could be further distinguished by RTCP Source Description (SDES)
information. information.
m=video 49174 RTP/AVPF 96 98 m=video 49174 RTP/AVPF 96 98
a=rtpmap:96 H.264/90000 a=rtpmap:96 H.264/90000
a=rtpmap:98 rtx/90000 a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96;rtx-time=3000 a=fmtp:98 apt=96;rtx-time=3000
a=ssrc-group:FID 11111 22222 a=ssrc-group:FID 11111 22222
a=ssrc:11111 cname:user3@example.com a=ssrc:11111 cname:user3@example.com
a=ssrc:22222 cname:user3@example.com a=ssrc:22222 cname:user3@example.com
a=ssrc-group:FID 33333 44444 a=ssrc-group:FID 33333 44444
a=ssrc:33333 cname:user3@example.com a=ssrc:33333 cname:user3@example.com
a=ssrc:44444 cname:user3@example.com a=ssrc:44444 cname:user3@example.com
Figure 8: Example: relationship among several sources: retransmission Figure 3: Example: relationship among several sources: retransmission
sources sources
The example in Figure 8 shows how the relationships among sources The example in Figure 3 shows how the relationships among sources
used for RTP Retransmission [RFC4588] can be explicitly signaled. used for RTP Retransmission [RFC4588] can be explicitly signaled.
This prevents the complexity of associating original sources with This prevents the complexity of associating original sources with
retransmission sources when SSRC multiplexing is used for RTP retransmission sources when SSRC multiplexing is used for RTP
retransmission, as is described in Section 5.3 of [RFC4588]. retransmission, as is described in Section 5.3 of [RFC4588].
8. Usage With the Offer/Answer Model 8. Usage With the Offer/Answer Model
When used with the SDP Offer/Answer Model [RFC3264], SDP source- When used with the SDP Offer/Answer Model [RFC3264], SDP source-
specific attributes describe only the sources with which each party specific attributes describe only the sources with which each party
is willing to send (whether it is sending RTP data or RTCP report is willing to send (whether it is sending RTP data or RTCP report
skipping to change at page 12, line 42 skipping to change at page 12, line 42
attributes which have been extended to be source attributes are not attributes which have been extended to be source attributes are not
included. included.
ssrc-attr = "ssrc:" ssrc-id SP attribute ssrc-attr = "ssrc:" ssrc-id SP attribute
; The base definition of "attribute" is in RFC 4566. ; The base definition of "attribute" is in RFC 4566.
; (It is the content of "a=" lines.) ; (It is the content of "a=" lines.)
ssrc-id = integer ; 0 - 2**32 - 1 ssrc-id = integer ; 0 - 2**32 - 1
attribute =/ ssrc-attr attribute =/ ssrc-attr
Figure 9: Syntax of the ssrc media attribute Figure 4: Syntax of the ssrc media attribute
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id) ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
; The definition of "semantics" is in RFC 3388. ; The definition of "semantics" is in RFC 3388.
; (It is the type of grouping being done.) ; (It is the type of grouping being done.)
attribute =/ ssrc-group-attr attribute =/ ssrc-group-attr
Figure 10: Syntax of the ssrc-group media attribute Figure 5: Syntax of the ssrc-group media attribute
cname-attr = "cname:" cname cname-attr = "cname:" cname
cname = byte-string cname = byte-string
; Following the syntax conventions for CNAME as defined in RFC 3550. ; Following the syntax conventions for CNAME as defined in RFC 3550.
; The definition of "byte-string" is in RFC 4566. ; The definition of "byte-string" is in RFC 4566.
attribute =/ cname-attr attribute =/ cname-attr
Figure 11: Syntax of the cname source attribute Figure 6: Syntax of the cname source attribute
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id) previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
attribute =/ previous-ssrc-attr attribute =/ previous-ssrc-attr
Figure 12: Syntax of the previous-ssrc source attribute Figure 7: Syntax of the previous-ssrc source attribute
11. Security Considerations 11. Security Considerations
All the security implications of RTP [RFC3550] and of SDP [RFC4566] All the security implications of RTP [RFC3550] and of SDP [RFC4566]
apply. Explicitly describing the multiplexed sources of an RTP media apply. Explicitly describing the multiplexed sources of an RTP media
stream does not appear to add any further security issues. stream does not appear to add any further security issues.
12. IANA Considerations 12. IANA Considerations
12.1. New SDP Media-Level Attributes 12.1. New SDP Media-Level Attributes
skipping to change at page 14, line 14 skipping to change at page 14, line 14
12.2. Registry for Source-Level Attributes 12.2. Registry for Source-Level Attributes
This specification creates a new IANA registry named "att-field This specification creates a new IANA registry named "att-field
(source level)" within the SDP parameters registry. Source (source level)" within the SDP parameters registry. Source
attributes MUST be registered with IANA and documented, under the attributes MUST be registered with IANA and documented, under the
same rules as for SDP session-level and media-level attributes as same rules as for SDP session-level and media-level attributes as
specified in [RFC4566]: specified in [RFC4566]:
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC2434], provided that the "Specification Required" policy of [RFC5226], provided that the
specification includes the following information: specification includes the following information:
o contact name, email address, and telephone number o contact name, email address, and telephone number
o attribute name (as it will appear in SDP) o attribute name (as it will appear in SDP)
o long-form attribute name in English o long-form attribute name in English
o whether the attribute value is subject to the charset attribute o whether the attribute value is subject to the charset attribute
o a one-paragraph explanation of the purpose of the attribute o a one-paragraph explanation of the purpose of the attribute
o a specification of appropriate attribute values for this attribute o a specification of appropriate attribute values for this attribute
The above is the minimum that IANA will accept. Attributes that are The above is the minimum that IANA will accept. Attributes that are
skipping to change at page 14, line 43 skipping to change at page 14, line 43
of software in a manner that might inhibit interoperability. of software in a manner that might inhibit interoperability.
Source-level attributes which are substantially similar in semantics Source-level attributes which are substantially similar in semantics
to existing session-level or media-level attributes SHOULD re-use the to existing session-level or media-level attributes SHOULD re-use the
same attribute name as those session-level or media-level attributes. same attribute name as those session-level or media-level attributes.
Source-level attributes SHOULD NOT re-use attribute names of session- Source-level attributes SHOULD NOT re-use attribute names of session-
level or media-level attributes that are unrelated or substantially level or media-level attributes that are unrelated or substantially
different. different.
The initial set of source attribute names, with definitions in The initial set of source attribute names, with definitions in
Section 6 of this document, is in Figure 13. Section 6 of this document, is in Figure 8.
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
att-field (source level) att-field (source level)
cname [RFCXXXX] cname [RFCXXXX]
previous-ssrc [RFCXXXX] previous-ssrc [RFCXXXX]
fmtp [RFCXXXX] fmtp [RFCXXXX]
Figure 13: Initial Contents of IANA Source Attribute Registry Figure 8: Initial Contents of IANA Source Attribute Registry
(Note to the RFC-Editor: please replace "XXXX" with the number of (Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.) this document prior to publication as an RFC.)
12.3. Registry for Source Grouping Semantics 12.3. Registry for Source Grouping Semantics
This specification creates a new IANA registry named "Semantics for This specification creates a new IANA registry named "Semantics for
the "ssrc-group" SDP Attribute" within the SDP parameters registry. the "ssrc-group" SDP Attribute" within the SDP parameters registry.
Source group semantics MUST be defined in standards-track RFCs, under Source group semantics MUST be defined in standards-track RFCs, under
the same rules as [RFC3388]: the same rules as [RFC3388]:
skipping to change at page 15, line 30 skipping to change at page 15, line 30
any length, but SHOULD be no more than four characters long. any length, but SHOULD be no more than four characters long.
o Reference to an standards track RFC. o Reference to an standards track RFC.
Source grouping semantics values which are substantially similar to Source grouping semantics values which are substantially similar to
existing media grouping semantics values SHOULD re-use the same existing media grouping semantics values SHOULD re-use the same
semantics name as that media gropuing semantics. Source grouping semantics name as that media gropuing semantics. Source grouping
semantics SHOULD NOT re-use source grouping semantics names that are semantics SHOULD NOT re-use source grouping semantics names that are
unrelated or substantially different. unrelated or substantially different.
The initial set of source grouping semantics values, for the The initial set of source grouping semantics values, for the
semantics specified in Section 4.2 of this document, is in Figure 14. semantics specified in Section 4.2 of this document, is in Figure 9.
Semantics Token Reference Semantics Token Reference
------------------- ----- --------- ------------------- ----- ---------
Flow Identification FID [RFCXXXX] Flow Identification FID [RFCXXXX]
Forward Error Correction FEC [RFCXXXX] Forward Error Correction FEC [RFCXXXX]
Figure 14: Initial Contents of IANA Source Group Semantics Registry Figure 9: Initial Contents of IANA Source Group Semantics Registry
(Note to the RFC-Editor: please replace "XXXX" with the number of (Note to the RFC-Editor: please replace "XXXX" with the number of
this document prior to publication as an RFC.) this document prior to publication as an RFC.)
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References 13.2. Informative References
[I-D.ietf-avt-rtcpssm] [I-D.ietf-avt-rtcpssm]
Ott, J., "RTCP Extensions for Single-Source Multicast Ott, J., "RTCP Extensions for Single-Source Multicast
Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17 Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-17
(work in progress), January 2008. (work in progress), January 2008.
skipping to change at page 17, line 26 skipping to change at page 17, line 26
July 2006. July 2006.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
A.1. Changes From Working Group Draft -00 A.1. Changes From Working Group Draft -01
o Updated reference to RFC 2434 to [RFC5226].
A.2. Changes From Working Group Draft -00
o Removed discussion of ssrc-multiplexing for layered codecs. o Removed discussion of ssrc-multiplexing for layered codecs.
o Clarified that each "ssrc" attribute specifies only a single o Clarified that each "ssrc" attribute specifies only a single
source-level attribute. source-level attribute.
o Clarified that "ssrc-group" semantics are defined separately from o Clarified that "ssrc-group" semantics are defined separately from
"group" semantics. "group" semantics.
o Clarified reference for the Td parameter. o Clarified reference for the Td parameter.
o Updated references. o Updated references.
o Corrected typographical errors. o Corrected typographical errors.
A.2. Changes From Individual Submission Draft -01 A.3. Changes From Individual Submission Draft -01
o Added definitions of the new IANA registries and registrations o Added definitions of the new IANA registries and registrations
needed. needed.
o Clarified that none of the attributes defined in the document are o Clarified that none of the attributes defined in the document are
dependent on the charset attribute. dependent on the charset attribute.
o Clarified that ssrc attributes must be consistent with other SDP o Clarified that ssrc attributes must be consistent with other SDP
mechanisms (such as MIKEY) that also specify SSRCs. mechanisms (such as MIKEY) that also specify SSRCs.
o Removed open issues section. o Removed open issues section.
A.3. Changes From Individual Submission Draft -00 A.4. Changes From Individual Submission Draft -00
o Clarified that this document is expressly defining declarative o Clarified that this document is expressly defining declarative
source descriptions, not source offer/answer or other information. source descriptions, not source offer/answer or other information.
o Removed the definitions of the "information", "bandwidth", o Removed the definitions of the "information", "bandwidth",
"sendrecv", "sendonly", "recvonly", "inactive", "charset", "sendrecv", "sendonly", "recvonly", "inactive", "charset",
"sdplang", "lang", "framerate", and "quality" source attributes. "sdplang", "lang", "framerate", and "quality" source attributes.
They are all unnecessary for source decodability, and to the They are all unnecessary for source decodability, and to the
extent they are otherwise useful they are probably better handled extent they are otherwise useful they are probably better handled
by RTCP Source Description (SDES) packets or feedback (AVPF) by RTCP Source Description (SDES) packets or feedback (AVPF)
messages. messages.
o Added text to the Backward Compatibility and Security o Added text to the Backward Compatibility and Security
Considerations sections. Considerations sections.
skipping to change at page 19, line 44 skipping to change at line 854
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 31 change blocks. 
38 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/