idnits 2.17.1 draft-westerlund-mmusic-max-ssrc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (September 19, 2013) is 3870 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 informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft M. Westerlund 4 Intended status: Standards Track B. Burman 5 Expires: March 23, 2014 F. Jansson 6 Ericsson 7 September 19, 2013 9 Multiple Synchronization Sources (SSRC) in SDP Media Descriptions 10 draft-westerlund-mmusic-max-ssrc-02.txt 12 Abstract 14 This document describes use-cases where endpoints, for a given media 15 type, use multiple media sources. It also describes how endpoints 16 normally support media sources, and limitations associated with the 17 support of multiple sources. 19 This document also defines two new SDP attributes, "max-send-ssrc" 20 and "max-recv-ssrc". The attributes allows an entity to, for a given 21 media description, indicate sending and receiving capabilities of 22 multiple media sources, based on codec usage . 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 23, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Multiple Media Stream Support . . . . . . . . . . . . . . . . 3 60 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Multiple Source Support Limitations . . . . . . . . . . . 4 62 4. SDP max-send-ssrc And max-recv-ssrc Attributes . . . . . . . 4 63 4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.4. Use in Offer/Answer . . . . . . . . . . . . . . . . . . . 6 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 An RTP session [RFC3550] contains a Synchronization Sources (SSRC) 78 space. This space can encompass a number of endpoints and network 79 entities, and associated media streams, within the RTP session. As 80 defined in RFC 3550, within an RTP session, each entity may use zero, 81 one or multiple SSRCs to indicate a physical media source (e.g. a 82 camera or a microphone), a conceptual source (e.g. the most active 83 speaker, selected by an RTP mixer, within a conference), or to 84 identify a receiver that provides feedback and reports on reception. 85 A given SSRC value is associated with a physical media source. 86 Multiple SSRC values can be associated with the same source. 88 The Session Description Protocol (SDP) [RFC4566] describes media 89 streams using media descriptions (m- lines). Each m- line is 90 normally associated with a given media type (e.g. audio or video). 92 Multiple media streams and media sources might be associated with a 93 single SDP media description. Each media stream will share the 94 parameters and characteristics (e.g. payload type values and codecs) 95 that have been indicated in the SDP media description. 97 This document describes use-cases where endpoints, for a given media 98 type, use multiple media sources. It also describes how endpoints 99 normally support media sources, and limitations associated with the 100 support of multiple sources. 102 This document also defines two new SDP attributes, "max-send-ssrc" 103 and "max-recv-ssrc". The attributes allows an entity to, for a given 104 media description, indicate sending and receiving capabilities of 105 multiple media sources, based on codec usage . 107 2. Definitions 109 2.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2.2. Terminology 117 The following terms and abbreviations are used in this document: 119 Encoding: A particular encoding is the choice of the media encoder 120 (codec) that has been used to compress the media, the fidelity of 121 that encoding through the choice of sampling, bit-rate and other 122 configuration parameters. 124 Different encodings: An encoding is different when some parameter 125 that characterize the encoding of a particular media source has 126 been changed. Such changes can be one or more of the following 127 parameters; codec, codec configuration, bit-rate, sampling. 129 Media source: The source of a stream of data of one Media Type, It 130 can either be a single media capturing device such as a video 131 camera, a microphone, or a specific output of a media production 132 function, such as an audio mixer, or some video editing function. 134 Media stream: Within the scope of this document, a media stream 135 represents a media flow, associated with a media source 136 (identified by a SSRC value) and an SDP media description (m- 137 line). 139 3. Multiple Media Stream Support 141 3.1. General 143 Many applications and systems have been designed to ensure that any 144 given endpoint only needs to, for a given SDP media description, send 145 or receive a single media stream, associated with a single source. 146 Some applications might be able to switch between different SSRC 147 values, but will still only be able to process media associated with 148 a single SSRC value at any given time. 150 Then there is some applications that are designed to use multiple 151 SSRCs simultaneously. Some send media from multiple media sources, 152 for example an application which sends video from multiple cameras. 153 Some RTP extension mechanisms require endpoints to be able to handle 154 multiple SSRCs. An example is the mechanism for SSRC multiplexed RTP 155 retransmissions [RFC4588]. Multicast applications typically support 156 multiple media streams, as they might receive media from multiple 157 remote entities. Some unicast multi-party applications also receive 158 multiple media sources from a central entity relaying sources from 159 multiple origins. 161 NOTE: Even if an endpoint is not used in scenarios where multiple 162 media streams (SSRCs) are sent and received, according to RFC 3550, 163 the endpoint need to be able to support cases where the SSRC value 164 used for a media stream is changed, e.g. due to an SSRC value 165 collision [RFC3550]. 167 3.2. Multiple Source Support Limitations 169 The theoretical maximum number of sources, for a given RTP session, 170 is 2^32. However, even if applications, for a given RTP session, are 171 able to handle multiple media streams simultaneously, entities only 172 have resources to handle a given number (typically far smaller the 173 theoretical maximum number) of media streams. The number of 174 supported media streams might depend on the type of codecs, or codec 175 configurations, that are used for the media streams. Networks might 176 also put constrains on the number of media streams that can be 177 supported. 179 In environments where endpoints, for a given SDP media description, 180 have different amount of resources to handle multiple media stream of 181 handling multiple media streams, network entities (e.g. RTP mixers) 182 might be used, in order to select, or combine, media streams into a 183 number of media streams that is supported by the endpoints to which 184 the media is sent. The policies and algorithms to select and combine 185 media streams are outside the scope of this document. 187 4. SDP max-send-ssrc And max-recv-ssrc Attributes 189 4.1. Introduction 191 As different applications end entities typically are able to 192 simultaneously handle a different number of media streams associated 193 with a given SDP media description, it is necessary for an entity to 194 be able to declare how many media streams it able to simultaneously 195 send and receive, and whether the used codecs and codec 196 configurations have impact on the number of media streams. 198 This section defines two new media level SDP attributes, "max-send- 199 ssrc" and "max-recv-ssrc". The attributes are used to, for a given 200 SDP media description, indicate the multiple stream capabilities of 201 an entity. The "max-send-ssrc" attribute is used to indicate 202 simultaneous sending capabilities, and the "max-recv-ssrc" attribute 203 is used to indicate simultaneous receiving capabilities. 205 4.2. Usage 207 The SDP attributes are used to describe multiple stream capabilities 208 based on which codecs or codec configurations are used for each 209 stream. The attributes allow to describe multiple alternatives. 211 Each alternative contains one or more codecs or codec configurations 212 (indexed using the payload type value which has describes the codec 213 in the SDP), and for each codec the number of simultaneous streams 214 the endpoint is able to handle. 216 For a given alternative, payload type values can be explicitly 217 listed. It is also possible to use a payload type range, which 218 includes all payload type values within the range. Alternatively it 219 is possible to use a wildcard value, which indicates that the 220 indicated number of SSRCs is independent of which codec is used. 222 The number of streams that an entity can simultaneous send can be 223 different from the number it can receive. 225 4.3. Syntax 227 The syntax for the attributes is in ABNF [RFC5234]: 229 max-ssrc = "a="( "max-send-ssrc:" / "max-recv-ssrc:" ) alt-list 230 alt-list = alt-set *(WSP alt-set) 231 alt-set = "{" alt *("&" alt)) "}" 232 alt = pt ":" limit 233 pt = ( pt-list / pt-wildcard ) 234 pt-list = ( pt-value / pt-range ) *(","( pt-value / pt-range )) 235 pt-value = 1*3DIGIT 236 pt-range = pt-value "-" pt-value 237 pt-wildcard = "*" 238 limit = 1*8DIGIT 239 ; WSP and DIGIT defined in [RFC5234] 241 4.4. Use in Offer/Answer 243 An SDP Offerer that supports and uses the mechanism in this document 244 MUST include the SDP attributes in the initial SDP offer of a 245 session. If the SDP Answerer also supports and uses the mechanism, 246 the attributes MUST be included in each subsequent SDP Offer and 247 Answer during the session. 249 An SDP Answerer MUST NOT include the SDP attributes in the SDP Answer 250 unless the associated SDP Offer also contains them. 252 For sendrecv SDP media descriptions (m- lines), an endpoint that uses 253 the mechanism described in this document MUST include both the "max- 254 send-ssrc" and "max-recv-ssrc" attributes in an SDP Offer and Answer 255 [RFC3264], also for directions in which the endpoint only supports a 256 single SSRC. 258 For sendonly or recvonly SDP media descriptions, an endpoint MUST 259 include that attribute which corresponds to the direction attribute. 260 For information purpose, the endpoint MAY include also the other 261 attribute. 263 TODO: Guidance text is needed, which describes how the SDP Answerer 264 indciates its capabilities in a way so that they match the 265 capabilities of the SDP Offerer as far as possible. 267 5. Examples 269 The SDP examples below are not complete. Only the relevant parts are 270 shown. 272 m=video 49200 RTP/AVP 99 273 a=rtpmap:99 H264/90000 274 a=max-send-ssrc:{*:2} 275 a=max-recv-ssrc:{*:4} 277 The SDP indicates that the endpoint is able to send 2 simultaneous 278 SSRCs, and is able to receive 4 simultaneous SSRCs. The wildcarded 279 payload type value indicates that the indicated capabilities apply 280 for any of the indicated codecs (only a single one in this example). 282 m=video 50324 RTP/AVP 96 97 283 a=rtpmap:96 H264/90000 284 a=rtpmap:97 H263-2000/90000 285 a=max-recv-ssrc:{96:2&97:3} {96:1&97:4} {97:5} 286 a=max-send-ssrc:{* 1} 288 The SDP indicates 3 different receiving capability alternatives. The 289 first alternative indicates that the endpoint is able to receive at 290 most 2 SSRCs using the H.264 codec (payload type value 96) and 3 291 SSRCs using the H.263 codec (payload type value 97). The second 292 alternative indicates that the endpoint is able to receive 1 SSRC 293 using the H.264 codec and 4 SSRCs using the H.263 codec. The third 294 alternative indicates that the endpoint is able to receive 5 SSRCs 295 using the H.263 codec. The SDP indicates that the endpoint is only 296 able to send one SSRC, no matter which of the indicated codecs are 297 used. 299 6. IANA Considerations 301 This document registers two media level SDP attributes. 303 TODO: IANA registration template 305 7. Security Considerations 307 The "max-recv-ssrc" and "max-send-ssrc" SDP attributes describe 308 capabilities of the endpoint that sends the attributes. Knowledge of 309 the capabilities might be used to trigger different kind of attacks. 310 The primary security concern is when a malicious man-in-the-middle 311 (MiTM) modifies the attribute values so that endpoints have wrong 312 information about the capabilities of the other endpoints. Such 313 modification of the capabilities might cause bad user experience, or 314 prevent services all together. For example, if an endpoint has 315 indicated that it is only able to receive a single media stream, and 316 a MiTM increases that number, the endpoint might end up receiving 317 more media streams than it is able to handle. 319 In order to prevent a MiTM to modify the SDP attributes, it is 320 RECOMMENDED to use a mechanism that provides authentication and 321 integrity protection of the SDP. 323 8. References 325 8.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 331 with Session Description Protocol (SDP)", RFC 3264, June 332 2002. 334 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 335 Jacobson, "RTP: A Transport Protocol for Real-Time 336 Applications", STD 64, RFC 3550, July 2003. 338 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 339 Specifications: ABNF", STD 68, RFC 5234, January 2008. 341 8.2. Informative References 343 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 344 Description Protocol", RFC 4566, July 2006. 346 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 347 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 348 July 2006. 350 Authors' Addresses 352 Christer Holmberg 353 Ericsson 354 Hirsalantie 11 355 Jorvas 02420 356 Finland 358 Email: christer.holmberg@ericsson.com 359 Magnus Westerlund 360 Ericsson 361 Farogatan 6 362 SE-164 80 Kista 363 Sweden 365 Phone: +46 10 714 82 87 366 Email: magnus.westerlund@ericsson.com 368 Bo Burman 369 Ericsson 370 Farogatan 6 371 SE-164 80 Kista 372 Sweden 374 Phone: +46 10 714 13 11 375 Email: bo.burman@ericsson.com 377 Fredrik Jansson 378 Ericsson 379 Farogatan 6 380 Kista SE-164 80 381 Sweden 383 Phone: +46 10 719 00 00 384 Email: fredrik.k.jansson@ericsson.com