idnits 2.17.1 draft-lennox-mmusic-sdp-max-sources-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC J. Lennox 3 Internet-Draft Vidyo 4 Intended status: Standards Track July 6, 2009 5 Expires: January 7, 2010 7 A Session Description Protocol (SDP) Attribute for Maximum Media Source 8 Count Indication 9 draft-lennox-mmusic-sdp-max-sources-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 7, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Real-Time Transport Protocol (RTP) is a multi-point protocol, 48 supporting multiple simultaneous sending sources in an RTP session. 50 However, many existing RTP endpoints cannot usefully receive more 51 than one simultaneous source. This document provides a Session 52 Description Protocol (SDP) attribute that allows endpoints to 53 indicate the maximum number of sources they can usefully receive. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. The "max-sources" Media Attribute . . . . . . . . . . . . . . . 3 60 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 4 61 5. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. New SDP Media-Level Attribute . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 The Real-Time Transport Protocol (RTP) [RFC3550] is a multi-point 74 protocol. It supports multiple simultaneous media senders, and, as 75 documented in RTP Topologies [RFC5117], scales from two-party point- 76 to-point sessions to large, wide-area sessions. 78 However, many existing systems do not make use of this capability. 79 Especially for Voice-over-IP and multimedia conferencing systems 80 using SIP [RFC3261], many existing terminals will not decode more 81 than a single RTP stream at a time per RTP session. Indeed, many 82 deployed systems are known to misbehave badly upon receiving more 83 than one simultaneous RTP stream in an RTP session. 85 Thus, even if endpoints can receive, decode, and usefully present 86 multiple sources in an RTP session, there is no portable way for 87 their peers to know this and take advantage of it. 89 To remedy this situation, this document defines a new SDP attribute, 90 "max-sources", which specifies the maximum number of sources that an 91 endpoint in an RTP session can usefully process. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119] and 98 indicate requirement levels for compliant implementations. 100 3. The "max-sources" Media Attribute 102 This section defines a new SDP media-level attribute, "max-sources", 103 which indicates the maximum number of sources supported in an RTP 104 session. 106 a=max-sources: 107 a=max-sources:unlimited 109 The SDP media attribute "max-sources" indicates the maximum number of 110 RTP sources that an RTP receiver supports within an RTP session. 111 is the maximum number of sources that can usefully be 112 decoded, expressed as a positive decimal integer or the string 113 "unlimited". Thus, it indicates the maximum number of RTP senders 114 that should be present in the session, other than those that the SDP 115 author itself will send. 117 The "max-sources" media attribute MAY be used for any RTP-based media 118 transport. It is not defined for other transports. 120 The "max-sources" attribute is only defined for SDP Offer/Answer 121 [RFC3264] messages, not declarative SDP. A receiver of a "max- 122 sources" attribute in an offer or answer SHOULD restrict the number 123 of sources that it transmits on the RTP session to the number of 124 sources mentioned in the SDP message. 126 The "max-sources" attribute does not support the value of "0". If no 127 sources are supported on a session, an appropriate SDP sendrecv 128 attribute (e.g. "sendonly") SHOULD be used instead. 130 The "max-sources" attribute SHOULD NOT be used with RTP sessions sent 131 over any-source multicast (those that RTP Topologies [RFC5117] 132 describes as "Topo-Multicast", or the multicast side of "Topo- 133 Translator"), because new participants cannot immediately determine 134 how many existing senders are present in the RTP session. 136 For the unicast portion of translator-based topologies, it is the 137 translator's responsibility to forward only the appropriate number of 138 sources along the unicast path. 140 Figure 1 in Section 5 gives a formal Augmented Backus-Naur Form 141 (ABNF) [RFC5234] grammar for the "max-sources" attribute. 143 The "max-sources" media attribute is not dependent on charset. 145 4. Backward Compatibility 147 As mentioned in the introduction, it is unclear with existing 148 endpoints whether they can usefully support multiple sources on an 149 RTP session. In most circumstances, therefore, existing endpoints 150 will default to sending only a single source per session. This will 151 be compatible with any requested value of "max-sources" even if the 152 receiver of the SDP does not support the attribute. 154 5. Formal Grammar 156 This section gives a formal Augmented Backus-Naur Form (ABNF) 157 [RFC5234] grammar for each the "max-sources" media attribute. 159 max-sources-attr = "max-sources:" ( 1*DIGIT / "unlimited" ) 161 attribute =/ max-sources-attr 163 Figure 1: Syntax of the "max-sources" media attribute 165 6. Security Considerations 167 All the security implications of RTP [RFC3550] and of SDP [RFC4566] 168 apply. Explicitly indicating the number of RTP sources supported in 169 an RTP media stream does not appear to add further security issues. 171 7. IANA Considerations 173 7.1. New SDP Media-Level Attribute 175 This document defines a new SDP media-level attribute, "max-sources". 176 This attribute should be registered by IANA under "Session 177 Description Protocol (SDP) Parameters" under "att-field (media level 178 only)". Its format is defined in Section 3 180 8. References 182 8.1. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 188 with Session Description Protocol (SDP)", RFC 3264, 189 June 2002. 191 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 192 Jacobson, "RTP: A Transport Protocol for Real-Time 193 Applications", STD 64, RFC 3550, July 2003. 195 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 196 Description Protocol", RFC 4566, July 2006. 198 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 199 Specifications: ABNF", STD 68, RFC 5234, January 2008. 201 8.2. Informative References 203 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 204 A., Peterson, J., Sparks, R., Handley, M., and E. 205 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 206 June 2002. 208 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 209 January 2008. 211 Appendix A. Open issues 213 o Does "max-sources" need to be defined for declarative SDP (e.g. 214 for RTSP)? 216 Author's Address 218 Jonathan Lennox 219 Vidyo, Inc. 220 433 Hackensack Avenue 221 Sixth Floor 222 Hackensack, NJ 07601 223 US 225 Email: jonathan@vidyo.com