MMUSIC J. Lennox Internet-Draft Vidyo Intended status: Standards Track H. Schulzrinne Expires: April 29, 2010 Columbia U. October 26, 2009 Mechanisms for Media Source Selection in the Session Description Protocol (SDP) draft-lennox-mmusic-sdp-source-selection-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Lennox & Schulzrinne Expires April 29, 2010 [Page 1] Internet-Draft Media Source Selection in SDP October 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Source-specific media attributes in the Session Description Protocol (SDP) allow endpoints to describe Real-Time Transport Protocol (RTP) sources within a media stream. This document extends that mechanism by defining how participants in a multimedia session can request specific sources from a remote party. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. The "remote-ssrc" Media Attribute . . . . . . . . . . . . . . 5 6. Remote Source Attributes . . . . . . . . . . . . . . . . . . . 6 6.1. The "recv" Remote Source-Level Attribute . . . . . . . . . 6 6.2. The "framerate" Remote Source Attribute . . . . . . . . . 7 6.3. The "imageattr" Remote Source Attribute . . . . . . . . . 8 6.4. The "priority" Remote Source Attribute . . . . . . . . . . 9 7. Source Attributes . . . . . . . . . . . . . . . . . . . . . . 9 7.1. The "information" Source Attribute . . . . . . . . . . . . 9 7.2. The "sending" Source-Level Attribute . . . . . . . . . . . 10 8. Usage With the Offer/Answer Model . . . . . . . . . . . . . . 10 9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12.1. New SDP Media-Level Attributes . . . . . . . . . . . . . . 13 12.2. New SDP Source-Level Attributes . . . . . . . . . . . . . 13 12.3. Registry for Remote Source-Level Attributes . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Changes From Earlier Versions . . . . . . . . . . . . 16 A.1. Changes From Individual Submission Draft -00 . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Lennox & Schulzrinne Expires April 29, 2010 [Page 2] Internet-Draft Media Source Selection in SDP October 2009 1. Introduction The source-attribute specification [RFC5576] provides declarative definitions for Real-Time Protocol (RTP) [RFC3550] media sources in the Session Description Protocol (SDP) [RFC4566]. In some architectures (such as those described in Section 3), it is useful to provide the capability for endpoints to request specific sources of a remote party, asking the sender to selectively enable or disable them, and to specify characteristics of the sources requested. To accomplish this, this document defines a new media attribute, "remote-ssrc", which allows a receiver to indicate that it wishes to receive a remote source, and also allows it to specify attributes of the remote source. This document defines several such remote source attributes: "recv", and "preference" which are applicable to any media type, and "framerate", and "imageattr" which are specific to video sources. Currently no attributes are defined that are specific to audio or other media types. Additionally, several new declarative ([RFC5576]) source attributes are defined: "information", providing human-readable information about a local source, and "sending", which is complementary to the "recv" remote source attribute. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. Architecture The primary use envisioned for this mechanism is for multimedia conferences controlled by a central system. This is similar to the topolgies described by RTP Topologies [RFC5117] as Topo-Mixer, Topo- Video-switch-MCU, or Topo-RTCP-terminating-MCU (depending on the treatment of RTCP), with one crucial difference: rather than only forwarding either a single media source, or an MCU-mixed media source, to receivers, the central mixer can instead simultaneously forward multiple media sources independently to each receiver, as constrained by available bandwidth. In this architecture, the conference server can notify each participant as sources become available in the conference. Participants can then either explicitly request sources from the Lennox & Schulzrinne Expires April 29, 2010 [Page 3] Internet-Draft Media Source Selection in SDP October 2009 server, or allow the server to choose which sources to forward based on its own criteria and policy. A hybrid mode is also possible, in which participants explicitly request some sources while allowing the server to choose others. Receivers can specify parameters for how they will view certain sources or server-selected sources, e.g., the image size or frame rate in which they will display video sources. They can also specify priority among sources in case the server has insufficient bandwidth to send them all. When the first receiver starts viewing a source, the conference server tells the sender to start sending it; prior to this, the sender does not send it. Similarly, when the last receiver stops viewing a source, the server tells the sender to stop sending it. For large conferences, sending each conference source over a separate RTP session, each with its own m= line, would not be practical, due to issues such as server port consumption, NAT binding exhaustion, and ICE setup time. Thus, sources of the same media type are instead sent over a single RTP session, distinguished by their SSRC. This document defines the source negotiation mechanisms needed in SDP to enable the mechanisms defined in this architecture. 4. Overview This mechanism builds upon the declarative source definitions defined in [RFC5576]. That document defines how to describe individual RTP sources within an RTP session in SDP. Each source is identified by its Synchronization Source (SSRC) identifier, and is associated with its CNAME (canonical-name) SDP attribute. To enable the architecture defined in Section 3, this document defines a complementary SDP media attribute which allows the receiver of some RTP sources to let the the sources' sender know which sources the receiver would like to receive. This attribute, "remote-ssrc", is defined in Section 5. A simple example SDP exchange using this mechanism is shown in Figure 1 and Figure 2. For brevity, only the relevant portions of the media sections of the SDP descriptions are given. m=video 49168 RTP/AVP 96 a=rtpmap:96 H264/90000 a=ssrc:12345 cname:user1@host1.example.com a=ssrc:67890 cname:user2@host2.example.com Lennox & Schulzrinne Expires April 29, 2010 [Page 4] Internet-Draft Media Source Selection in SDP October 2009 Figure 1: Notification of media sources In Figure 1 an SDP description indicates, using the mechanisms of [RFC5576], two sources that are available in an RTP session. m=video 49170 RTP/AVP 96 a=rtpmap:96 H264/90000 a=remote-ssrc:12345 recv:on a=remote-ssrc:12345 imageattr:* [x=720,y=576] a=remote-ssrc:12345 framerate:15 Figure 2: Request for a media source. In Figure 2 an SDP description sent in response requests that a specific source be sent, with resolution 720 by 576 and a framerate of 15 frames per second. 5. The "remote-ssrc" Media Attribute The "remote-ssrc" SDP media-level attribute allows a receiver to requested a specific a remote source. a=remote-ssrc: a=remote-ssrc: : The SDP media attribute "remote-ssrc" indicates a property, known as a "remote source-level attribute", of a remote media source (RTP stream) within an RTP session. is the synchronization source ID (SSRC) of the remote source being described, interpreted as a 32-bit unsigned integer in network byte order and represented in decimal. or : represent the source- level receive attribute specific to the given remote media source. The source-level receive attribute follows the syntax of the SDP "a=" line. It thus consists either of a single attribute name (a flag), or an attribute name and value, e.g., "framerate:30". No attributes of the former type are defined by this document. The order of multiple "remote-ssrc" media attributes within an SDP message is not significant. These remote source IDs correspond to sources in the RTP session that may be sent by other session members. The author of the SDP message may have been learned about these sources by observing them in the RTP session, either by receiving RTP packets or seeing RTCP reports from them); from earlier SDP messages containing "ssrc" attributes describing the sources; or from other means such as the SIP Lennox & Schulzrinne Expires April 29, 2010 [Page 5] Internet-Draft Media Source Selection in SDP October 2009 conference event package [RFC4575] or the XCON conference event package [I-D.ietf-xcon-event-package]. The "remote-ssrc" media attribute may be used for any RTP-based media transport. It is not defined for other transport protocols. Though the remote source attributes specified by the "remote-ssrc" property follow the same syntax as (local) source attributes, they are defined independently. All remote source attributes MUST be registered with IANA, using the registry defined in Section 12.3. Figure 3 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the ssrc attribute. The "remote-ssrc" media attribute does not (itself) depend on the SDP charset, though specific remote source attributes may be defined to be. 6. Remote Source Attributes This section defines several specific remote source-level attributes that can be applied to RTP sources. 6.1. The "recv" Remote Source-Level Attribute a=remote-ssrc: recv: The "recv" remote source attribute indicates whether the author of an SDP message is interested in receiving a source. A "recv" remote source attribute with a value of "on" indicates a source that the author of an SDP message is interested in receiving. Similarly, a "recv" remote source attribute with a value of "off" indicates a source that the author of an SDP message is not interested in receiving. There MUST be at most one "recv" remote source-level attributes per remote media source. A "recv" attribute with a value other than "on" or "off" MUST be ignored (for future extensibility). If the media stream containing the source has the media attributes "sendonly" or "inactive", the SDP message MUST NOT list any remote sources with a "recv" attribute with the "on" for that media stream. If "remote-ssrc" attributes are given for a particular remote source, but "recv" is not specified for it, "recv:on" is the default if the Lennox & Schulzrinne Expires April 29, 2010 [Page 6] Internet-Draft Media Source Selection in SDP October 2009 media stream is "sendrecv" or "recvonly". If no remote-ssrc attributes at all are listed for a particular remote source, the choice of whether to send it is left at the sender's discretion. However, for sources associated in with an "ssrc-group" [RFC5576], any unlisted sources of a group SHOULD be treated the same as any listed ones if the requests are consistent unless the semantics specified for the "ssrc-group" dictates otherwise. Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "recv" attribute. Section 8 describes how the "recv" remote source attribute is used with SDP offer/answer [RFC3264]. The "recv" remote source attribute does not depend on the SDP charset. 6.2. The "framerate" Remote Source Attribute a=remote-ssrc: framerate: The "framerate" remote source-level attribute gives the maximum frame rate, in frames per second, which the receiver of a video source would like receive for the video. Higher framerates are likely not to be useful to the receiver. This attribute is analogous in function and syntax to the SDP "framerate" media attribute [RFC4566]. Decimal representations of fractional values using the notation "." are allowed. The frame rate specified MUST be greater than zero. The "framerate" attribute is advisory; a sender MAY send a framerate other than that requested by the receiver if it is not able to send the framerate required. The sender SHOULD attempt to come as close as it can to the requested framerate, subject to other constraints of the system. The "framerate" attribute is defined only for video media. There MUST be at most one "framerate" remote source attribute per remote media source. The "framerate" requested MUST NOT be inconsistent with any fmtp parameters specified for the media stream's payload types. Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "framerate" attribute. Lennox & Schulzrinne Expires April 29, 2010 [Page 7] Internet-Draft Media Source Selection in SDP October 2009 The "framerate" remote source attribute does not depend on the SDP charset. 6.3. The "imageattr" Remote Source Attribute a=remote-ssrc: imageattr: The "imageattr" remote source-level attribute describes the image resolution and other image characteristics with which a video source would like receive the video. Larger resolutions are likely not to be useful to the receiver. It is analogous in function and syntax to the "recv" portion of the SDP "imageattr" media attribute [I-D.ietf-mmusic-image-attributes]. The "imageattr" attribute is advisory; a sender MAY send a resolution other than that requested by the receiver if it is not able to send the resolution required. The sender SHOULD attempt to come as close as it can to the requested resolution, subject to other constraints of the system. Different image attributes MAY be defined per payload type defined in the media stream. The parameter MAY either be one of the media formats (RTP payload types) specified for the media stream, or the character "*" indicating that the "imageattr" attribute applies to all payload types of the session. The parameter gives a list of resolutions and image aspect ratios with which the receiver wishes to display the source. It is described in detail in [I-D.ietf-mmusic-image-attributes]. The "imageattr" attribute is defined only for video media. There MUST be at most one "imageattr" remote source attribute per payload type per remote media source. If an "imageattr" attribute is present with a PT value of "*", it MUST be the only "imageattr" attribute defined for that remote media source. The "imageattr" requested MUST NOT be inconsistent with any fmtp parameters specified for the media stream's payload types. Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "imageattr" attribute. The "imageattr" remote source attribute does not depend on the SDP charset. Lennox & Schulzrinne Expires April 29, 2010 [Page 8] Internet-Draft Media Source Selection in SDP October 2009 6.4. The "priority" Remote Source Attribute a=remote-ssrc: priority: The "priority" remote source-level attribute gives the relative priority among the remote sources requested by a receiver. The parameter is a non-negative decimal integer indicating which streams should be given higher preference if the sender determines that there is insufficient bandwidth (or other resource) available to transmit all the requested streams. Larger numbers indicate a greater priority. Priority values MUST be less than 2**31 - 1, but otherwise their specific values have no semantic significance. Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "priority" attribute. The "priority" remote source attribute does not depend on the SDP charset. 7. Source Attributes This section describes sending source attributes that a sender an use to describe RTP sources. 7.1. The "information" Source Attribute a=ssrc: information: The "information" source attribute provides textual information about a source. It is analogous in function and syntax to the SDP "i=" field for session and media information. There MUST be at most one "information" source attribute per media source. If the "charset" attribute is present at the session or media level, it specifies the character set used in the source description. If the "charset" attribute is not present, the "information" attribute MUST contain ISO 10646 characters in UTF-8 encoding. The "information" attribute is intended to provide a free-form human- readable description of a media source. It is not suitable for parsing by automata. Figure 8 in Section 10 gives a formal Augmented Backus-Naur Form Lennox & Schulzrinne Expires April 29, 2010 [Page 9] Internet-Draft Media Source Selection in SDP October 2009 (ABNF) [RFC5234] grammar for the "information" attribute. 7.2. The "sending" Source-Level Attribute a=ssrc: sending: The "sending" remote source attribute indicates whether the author of an SDP message is interested in currently actively sending a source, due to it having been requested by the other party with a "recv" remote source attribute in an SDP offer/answer exchange. A "sending" source attribute with a value of "on" indicates a source that the author of an SDP message is currently actively sending, due to it having been requested by the other party with a "recv:on" remote source attribute. Similarly, the "sending" source attribute with a value of "off" indicates a source that has been rejected by the other party with the "recv:off" remote source attribute. There MUST be at most one "sending" source-level attribute per media source. Sources which were not listed with "recv-ssrc" in the previous offer or answer SHOULD NOT have a "sending" attribute included. The "sending" attribute is only defined in the context of SDP offer/answer [RFC3264]. A "sending" attribute with a value other than "on" or "off" MUST be ignored (for future extensibility). If the media stream containing the source has the media attributes "recvonly" or "inactive", the stream MUST NOT list any sources with the "sending" attribute with the on. Figure 9 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "sending" attribute. Further description of how the "sending" source attribute is used with SDP offer/answer [RFC3264] is given in Section 8. The "sending" source attribute is not dependent on charset. 8. Usage With the Offer/Answer Model When used with the SDP Offer/Answer Model [RFC3264], the "remote- ssrc" attribute MAY be included either in an SDP offer or answer. Both offers and answers MAY contain both "ssrc" and "remote-ssrc" media attributes. If "remote-ssrc" attributes are present in an SDP offer, the answerer (if it accepts the offer) MUST include all the remotely-requested Lennox & Schulzrinne Expires April 29, 2010 [Page 10] Internet-Draft Media Source Selection in SDP October 2009 active sources in "ssrc" attributes in its answer, except for any sources which are no longer available when the answer is sent. If "remote-ssrc" attributes are present in an answer, no immediate update to SDP is necessary; however, if the endpoint subsequently sends a new SDP offer, it SHOULD include all the remotely-requested sources from the previous offer/answer exchange, unless those sources are lo longer available. In both cases, remote sources with the "recv:on" remote source attribute included (implicitly or explicitly) MUST be listed in the next response with the "sending:on" local source attribute, while remote sources with the "recv:off" remote source attribute MUST have the "sending:off" local source attribute. However, if the send/recv mode of the media stream has changed to "recvonly" or "inactive", sources MUST NOT be listed with the "sending:on" attribute, and thus all remotely-requested sources MUST be listed as "sending:off" instead. In general, all participants in an offer/answer exchange SHOULD list all currently available sources, unless information about available sources is being provided through some other mechanism, such as the SIP conference event package [RFC4575] or the XCON conference event package [I-D.ietf-xcon-event-package]. (Because these event packages support partial updates, whereas SDP does not, source notification through event packages can be more efficient, where applicable, than SDP can be.) In the latter case sources that were not explicitly requested in the most recent SDP offer or answer MAY be omitted. 9. Backward Compatibility TODO: It is not clear if the absence of any "recv-ssrc" attributes, which following this draft would semantically indicate "I don't want to request any specific sources right now" needs to be distinguished from the backward-compatibility case "I don't know anything about the 'recv-ssrc' attribute". Similarly, it's not clear whether "I don't have any sources to list" needs to be distingushed from "I don't know about the 'ssrc' attribute." 10. Formal Grammar This section gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for each of the new media and source attributes defined in this document. Grammars for existing session or media attributes which have been extended to be source attributes are not included. Lennox & Schulzrinne Expires April 29, 2010 [Page 11] Internet-Draft Media Source Selection in SDP October 2009 remote-ssrc-attr = "remote-ssrc:" ssrc-id SP attribute ; The base definition of "attribute" is in RFC 4566. ; (It is the content of "a=" lines.) ssrc-id = integer ; 0 .. 2**32 - 1 attribute =/ remote-ssrc-attr Figure 3: Syntax of the "remote-ssrc" media attribute recv-attr = "recv:" recv-state recv-state = "on" / "off" / token attribute =/ recv-attr Figure 4: Syntax of the "recv" and "inactive" receive source attributes framerate-attr = "framerate:" integer [ "." 1*DIGIT ] attribute =/ framerate-attr Figure 5: Syntax of the "framerate" receive source attribute imageattr-attr = "imageattr:" PT WSP attr_list ; The definition of PT and attr_list are in ; [I-D.ietf-mmusic-image-attributes] attribute =/ imageattr-attr Figure 6: Syntax of the "imageattr" receive source attribute priority-attr = "priority:" integer attribute =/ priority-attr Figure 7: Syntax of the "priority" receive source attribute information-attr = "information:" text ; The definition of text is in [RFC4566] attribute =/ information-attr Lennox & Schulzrinne Expires April 29, 2010 [Page 12] Internet-Draft Media Source Selection in SDP October 2009 Figure 8: Syntax of the "imformation" source attribute sending-attr = "sending:" sending-state sending-state = "on" / "off" / token attribute =/ sending-attr Figure 9: Syntax of the "sending" and "inactive" source attributes 11. Security Considerations All the security considerations of RTP [RFC3550] and of SDP [RFC4566] apply. Explicitly requesting sources of an RTP media stream does not appear to add further security issues. 12. IANA Considerations 12.1. New SDP Media-Level Attributes This document defines a new SDP media-level attribute, "remote-ssrc". This attribute should be registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (media level only)". The "remote-ssrc" attribute is used to identify characteristics of remote media sources within a media stream. Its format is defined in Section 5. 12.2. New SDP Source-Level Attributes This document defines two new SDP source-level attributes, "information" and "sending". These attributes should be registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (source level)". Their format is defined in Section 7. 12.3. Registry for Remote Source-Level Attributes This specification creates a new IANA registry named "att-field (remote source level)" within the SDP parameters registry. Remote source attributes MUST be registered with IANA and documented, under the same rules as for SDP source-level attributes as specified in [RFC5576]: New attribute registrations are accepted according to the Lennox & Schulzrinne Expires April 29, 2010 [Page 13] Internet-Draft Media Source Selection in SDP October 2009 "Specification Required" policy of [RFC5226], provided that the specification includes the following information: o contact name, email address, and telephone number o attribute name (as it will appear in SDP) o long-form attribute name in English o whether the attribute value is subject to the charset attribute o a one-paragraph explanation of the purpose of the attribute o a specification of appropriate attribute values for this attribute The above is the minimum that IANA will accept. Attributes that are expected to see widespread use and interoperability SHOULD be documented with a standards-track RFC that specifies the attribute more precisely. Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability. Remote source-level attributes which are substantially similar in semantics to existing source-level, session-level or media-level attributes SHOULD re-use the same attribute name as those attributes. Remote source-level attributes SHOULD NOT re-use attribute names of other level attributes that are unrelated or substantially different. The initial set of remote source attribute names, with definitions in Section 6 of this document, is in Figure 10. Type SDP Name Reference ---- ------------------ --------- att-field (remote source level) recv [RFCXXXX] framerate [RFCXXXX] imageattr [RFCXXXX] priority [RFCXXXX] Figure 10: Initial Contents of IANA Remote Source Attribute Registry (Note to the RFC-Editor: please replace "XXXX" with the number of this document prior to publication as an RFC.) 13. References Lennox & Schulzrinne Expires April 29, 2010 [Page 14] Internet-Draft Media Source Selection in SDP October 2009 13.1. Normative References [I-D.ietf-mmusic-image-attributes] Johansson, I. and K. Jung, "Negotiation of Generic Image Attributes in SDP", draft-ietf-mmusic-image-attributes-03 (work in progress), October 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 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 Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009. 13.2. Informative References [I-D.ietf-xcon-event-package] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", draft-ietf-xcon-event-package-01 (work in progress), September 2008. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006. [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. Lennox & Schulzrinne Expires April 29, 2010 [Page 15] Internet-Draft Media Source Selection in SDP October 2009 Appendix A. Changes From Earlier Versions Note to the RFC-Editor: please remove this section prior to publication as an RFC. A.1. Changes From Individual Submission Draft -00 o The "recv" and "inactive" remote source attributes have been changed to "recv:on" and "recv:off" respectively. Similarly, the "send" and "inactive" source attributes have been changed to "sending:on" and "sending:off". o Clarified that "imageattr" and "framerate" parameters are advisory, and MUST NOT be inconsistent with payload type parameters. o Tightened some SHOULD requirements to be MUST, and clarified when others apply. o Tightened up ABNF grammar (e.g., to eliminate leading 0 values from integers). o Added Henning Schulzrinne as co-author. o Numerous editorial improvements. Authors' Addresses Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Sixth Floor Hackensack, NJ 07601 US Email: jonathan@vidyo.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science 1214 Amsterdam Ave., Mailcode: 0401 New York, NY 10027 US Email: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs/ Lennox & Schulzrinne Expires April 29, 2010 [Page 16]