idnits 2.17.1 draft-ietf-mmusic-sdp-simulcast-10.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 (July 20, 2017) is 2466 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) == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-rid-11 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-12) exists of draft-ietf-avtcore-multiplex-guidelines-03 -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Burman 3 Internet-Draft M. Westerlund 4 Intended status: Standards Track Ericsson 5 Expires: January 21, 2018 S. Nandakumar 6 M. Zanaty 7 Cisco 8 July 20, 2017 10 Using Simulcast in SDP and RTP Sessions 11 draft-ietf-mmusic-sdp-simulcast-10 13 Abstract 15 In some application scenarios it may be desirable to send multiple 16 differently encoded versions of the same media source in different 17 RTP streams. This is called simulcast. This document describes how 18 to accomplish simulcast in RTP and how to signal it in SDP. The 19 described solution uses an RTP/RTCP identification method to identify 20 RTP streams belonging to the same media source, and makes an 21 extension to SDP to relate those RTP streams as being different 22 simulcast formats of that media source. The SDP extension consists 23 of a new media level SDP attribute that expresses capability to send 24 and/or receive simulcast RTP streams. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 21, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 6 66 3.2. Application Specific Media Source Handling . . . . . . . 7 67 3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7 68 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Detailed Description . . . . . . . . . . . . . . . . . . . . 10 70 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10 71 5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 72 5.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13 73 5.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13 74 5.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 13 75 5.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 14 76 5.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 77 5.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 15 78 5.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16 79 5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 80 5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17 81 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 82 6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 6.1. Outgoing from Endpoint with Media Source . . . . . . . . 21 84 6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21 85 6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 22 86 6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24 87 6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25 88 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26 89 7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26 90 8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 97 13.2. Informative References . . . . . . . . . . . . . . . . . 29 98 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 32 99 Appendix B. Changes From Earlier Versions . . . . . . . . . . . 33 100 B.1. Modifications Between WG Version -09 and -10 . . . . . . 33 101 B.2. Modifications Between WG Version -08 and -09 . . . . . . 33 102 B.3. Modifications Between WG Version -07 and -08 . . . . . . 34 103 B.4. Modifications Between WG Version -06 and -07 . . . . . . 34 104 B.5. Modifications Between WG Version -05 and -06 . . . . . . 34 105 B.6. Modifications Between WG Version -04 and -05 . . . . . . 35 106 B.7. Modifications Between WG Version -03 and -04 . . . . . . 35 107 B.8. Modifications Between WG Version -02 and -03 . . . . . . 36 108 B.9. Modifications Between WG Version -01 and -02 . . . . . . 36 109 B.10. Modifications Between WG Version -00 and -01 . . . . . . 36 110 B.11. Modifications Between Individual Version -00 and WG 111 Version -00 . . . . . . . . . . . . . . . . . . . . . . . 37 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 114 1. Introduction 116 Most of today's multiparty video conference solutions make use of 117 centralized servers to reduce the bandwidth and CPU consumption in 118 the endpoints. Those servers receive RTP streams from each 119 participant and send some suitable set of possibly modified RTP 120 streams to the rest of the participants, which usually have 121 heterogeneous capabilities (screen size, CPU, bandwidth, codec, etc). 122 One of the biggest issues is how to perform RTP stream adaptation to 123 different participants' constraints with the minimum possible impact 124 on both video quality and server performance. 126 Simulcast is defined in this memo as the act of simultaneously 127 sending multiple different encoded streams of the same media source, 128 e.g. the same video source encoded with different video encoder types 129 or image resolutions. This can be done in several ways and for 130 different purposes. This document focuses on the case where it is 131 desirable to provide a media source as multiple encoded streams over 132 RTP [RFC3550] towards an intermediary so that the intermediary can 133 provide the wanted functionality by selecting which RTP stream(s) to 134 forward to other participants in the session, and more specifically 135 how the identification and grouping of the involved RTP streams are 136 done. 138 The intended scope of the defined mechanism is to support negotiation 139 and usage of simulcast when using SDP offer/answer and media 140 transport over RTP. The media transport topologies considered are 141 point to point RTP sessions as well as centralized multi-party RTP 142 sessions, where a media sender will provide the simulcasted streams 143 to an RTP middlebox or endpoint, and middleboxes may further 144 distribute the simulcast streams to other middleboxes or endpoints. 145 Usage of multicast or broadcast transport is out of scope and left 146 for future extension. 148 This document describes a few scenarios where it is motivated to use 149 simulcast, and also defines the needed RTP/RTCP and SDP signaling for 150 it. 152 2. Definitions 154 2.1. Terminology 156 This document makes use of the terminology defined in RTP Taxonomy 157 [RFC7656], and RTP Topologies [RFC7667]. The following terms are 158 especially noted or here defined: 160 RTP Mixer: An RTP middle node, defined in [RFC7667] (Section 3.6 to 161 3.9). 163 RTP Session: An association among a group of participants 164 communicating with RTP, as defined in [RFC3550] and amended by 165 [RFC7656]. 167 RTP Stream: A stream of RTP packets containing media data, as 168 defined in [RFC7656]. 170 RTP Switch: A common short term for the terms "switching RTP mixer", 171 "source projecting middlebox", and "video switching MCU" as 172 discussed in [RFC7667]. 174 Simulcast Stream: One encoded stream or dependent stream from a set 175 of concurrently transmitted encoded streams and optional dependent 176 streams, all sharing a common media source, as defined in 177 [RFC7656]. For example, HD and thumbnail video simulcast versions 178 of a single media source sent concurrently as separate RTP 179 Streams. 181 Simulcast Format: Different formats of a simulcast stream serve the 182 same purpose as alternative RTP payload types in non-simulcast 183 SDP: to allow multiple alternative media formats for a given RTP 184 stream. As for multiple RTP payload types on the m-line in offer/ 185 answer [RFC3264], any one of the negotiated alternative formats 186 can be used in a single RTP stream at a given point in time, but 187 not more than one (based on RTP timestamp). What format is used 188 can change dynamically from one RTP packet to another. 190 2.2. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119]. 196 3. Use Cases 198 The use cases of simulcast described in this document relate to a 199 multi-party communication session where one or more central nodes are 200 used to adapt the view of the communication session towards 201 individual participants, and facilitate the media transport between 202 participants. Thus, these cases target the RTP Mixer type of 203 topology. 205 There are two principle approaches for an RTP Mixer to provide this 206 adapted view of the communication session to each receiving 207 participant: 209 o Transcoding (decoding and re-encoding) received RTP streams with 210 characteristics adapted to each receiving participant. This often 211 include mixing or composition of media sources from multiple 212 participants into a mixed media source originated by the RTP 213 Mixer. The main advantage of this approach is that it achieves 214 close to optimal adaptation to individual receiving participants. 215 The main disadvantages are that it can be very computationally 216 expensive to the RTP Mixer, typically degrades media Quality of 217 Experience (QoE) such as end-to-end delay for the receiving 218 participants, and requires RTP Mixer access to media content. 220 o Switching a subset of all received RTP streams or sub-streams to 221 each receiving participant, where the used subset is typically 222 specific to each receiving participant. The main advantages of 223 this approach are that it is computationally cheap to the RTP 224 Mixer, has very limited impact on media QoE, and does not require 225 RTP Mixer (full) access to media content. The main disadvantage 226 is that it can be difficult to combine a subset of received RTP 227 streams into a perfect fit to the resource situation of a 228 receiving participant. 230 The use of simulcast relates to the latter approach, where it is more 231 important to reduce the load on the RTP Mixer and/or minimize QoE 232 impact than to achieve an optimal adaptation of resource usage. 234 3.1. Reaching a Diverse Set of Receivers 236 The media sources provided by a sending participant potentially need 237 to reach several receiving participants that differ in terms of 238 available resources. The receiver resources that typically differ 239 include, but are not limited to: 241 Codec: This includes codec type (such as SDP MIME type) and can 242 include codec configuration. A couple of codec resources that 243 differ only in codec configuration will be "different" if they are 244 somehow not "compatible", like if they differ in video codec 245 profile, or the transport packetization configuration. 247 Sampling: This relates to how the media source is sampled, in 248 spatial as well as in temporal domain. For video streams, spatial 249 sampling affects image resolution and temporal sampling affects 250 video frame rate. For audio, spatial sampling relates to the 251 number of audio channels and temporal sampling affects audio 252 bandwidth. This may be used to suit different rendering 253 capabilities or needs at the receiving endpoints. 255 Bitrate: This relates to the amount of bits sent per second to 256 transmit the media source as an RTP stream, which typically also 257 affects the Quality of Experience (QoE) for the receiving user. 259 Letting the sending participant create a simulcast of a few 260 differently configured RTP streams per media source can be a good 261 tradeoff when using an RTP switch as middlebox, instead of sending a 262 single RTP stream and using an RTP mixer to create individual 263 transcodings to each receiving participant. 265 This requires that the receiving participants can be categorized in 266 terms of available resources and that the sending participant can 267 choose a matching configuration for a single RTP stream per category 268 and media source. For example, a set of receiving participants 269 differ only in screen resolution; some are able to display video with 270 at most 360p resolution and some support 720p resolution. A sending 271 participant can then reach all receivers with best possible 272 resolution by creating a simulcast of RTP streams with 360p and 720p 273 resolution for each sent video media source. 275 The maximum number of simulcasted RTP streams that can be sent is 276 mainly limited by the amount of processing and uplink network 277 resources available to the sending participant. 279 3.2. Application Specific Media Source Handling 281 The application logic that controls the communication session may 282 include special handling of some media sources. It is, for example, 283 commonly the case that the media from a sending participant is not 284 sent back to itself. 286 It is also common that a currently active speaker participant is 287 shown in larger size or higher quality than other participants (the 288 sampling or bitrate aspects of Section 3.1). Not sending the active 289 speaker media back to itself means there is some other participant's 290 media that instead has to receive special handling towards the active 291 speaker; typically the previous active speaker. This way, the 292 previously active speaker is needed both in larger size (to current 293 active speaker) and in small size (to the rest of the participants), 294 which can be solved with a simulcast from the previously active 295 speaker to the RTP switch. 297 3.3. Receiver Media Source Preferences 299 The application logic that controls the communication session may 300 allow receiving participants to apply preferences to the 301 characteristics of the RTP stream they receive, for example in terms 302 of the aspects listed in Section 3.1. Sending a simulcast of RTP 303 streams is one way of accommodating receivers with conflicting or 304 otherwise incompatible preferences. 306 4. Overview 308 This memo defines SDP [RFC4566] signaling that covers the above 309 described simulcast use cases and functionalities. A number of 310 requirements for such signaling are elaborated in Appendix A. 312 A new SDP media level attribute "a=simulcast" is defined. The 313 attribute describes, independently for send and receive directions, 314 the number of simulcast RTP streams as well as potential alternative 315 formats for each simulcast RTP stream. Each simulcast RTP stream, 316 including alternatives, is identified using the RID identifier (rid- 317 id), defined in [I-D.ietf-mmusic-rid]. 319 a=simulcast:send 1;2,3 recv 4 321 If the above line is included in an SDP offer, the "send" part 322 indicates the offerer's capability and proposal to send two simulcast 323 RTP streams. Each simulcast RTP stream identifier (rid-id) is 324 separated by a semicolon (";"). When rid-ids are separated by a 325 comma (","), they describe alternative representations for that 326 particular simulcast RTP stream. Thus, the above "send" part is 327 interpreted as an intention to send two simulcast RTP streams. The 328 first simulcast RTP stream is identified and restricted according to 329 rid-id 1. The second simulcast RTP stream can be sent as two 330 alternatives, identified and restricted according to rid-ids 2 and 3. 331 The "recv" part of the above line indicates that the offerer desires 332 to receive a single RTP stream (no simulcast) according to rid-id 4. 334 The RID mechanism, as defined in [I-D.ietf-mmusic-rid], enables an 335 SDP offerer or answerer to specify a number of different RTP stream 336 restrictions for a rid-id by using the "a=rid" line. Examples of 337 such restrictions are maximum bitrate, maximum spatial video 338 resolution (width and height), maximum video framerate, etc. Each 339 rid-id may also be restricted to use only a subset of the RTP payload 340 types in the associated SDP media description. Those RTP payload 341 types can have their own configurations and parameters affecting what 342 can be sent or received, using the "a=fmtp" line as well as other SDP 343 attributes. 345 A more complete example SDP offer media description is provided 346 below: 348 m=video 49300 RTP/AVP 97 98 99 349 a=rtpmap:97 H264/90000 350 a=rtpmap:98 H264/90000 351 a=rtpmap:99 VP8/90000 352 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 353 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 354 a=fmtp:99 max-fs=240;max-fr=30 355 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] 356 a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] 357 a=imageattr:99 send [x=320,y=180] recv [x=320,y=180] 358 a=rid:1 send pt=97 359 a=rid:2 send pt=98 360 a=rid:3 send pt=99 361 a=rid:4 recv pt=97 362 a=simulcast:send 1;2,3 recv 4 363 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId 365 Figure 1: Example Simulcast Media Description in Offer 367 The above SDP media description can be interpreted on a high level to 368 say that the offerer is capable of sending two simulcast RTP streams, 369 one H.264 encoded stream in up to 720p resolution, and one additional 370 stream encoded as either H.264 or VP8 with a maximum resolution of 371 320x180 pixels. The offerer can receive one H.264 stream with 372 maximum 720p resolution. 374 The receiver of this SDP offer can generate an SDP answer that 375 indicates what it accepts. It uses the "a=simulcast" attribute to 376 indicate simulcast capability and specify what simulcast RTP streams 377 and alternatives to receive and/or send. An example of such 378 answering "a=simulcast" attribute, corresponding to the above offer, 379 is: 381 a=simulcast:recv 1;2 send 4 383 With this SDP answer, the answerer indicates in the "recv" part that 384 it wants to receive the two simulcast RTP streams. It has removed an 385 alternative that it doesn't support (rid-id 3). The send part 386 confirms to the offerer that it will receive one stream for this 387 media source according to rid-id 4. The corresponding, more complete 388 example SDP answer media description could look like: 390 m=video 49674 RTP/AVP 97 98 391 a=rtpmap:97 H264/90000 392 a=rtpmap:98 H264/90000 393 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000 394 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600 395 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] 396 a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] 397 a=rid:1 recv pt=97 398 a=rid:2 recv pt=98 399 a=rid:4 send pt=97 400 a=simulcast:recv 1;2 send 4 401 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId 403 Figure 2: Example Simulcast Media Description in Answer 405 It is assumed that a single SDP media description is used to describe 406 a single media source. This is aligned with the concepts defined in 407 [RFC7656] and will work in a WebRTC context, both with and without 408 BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping of media 409 descriptions. 411 The "a=simulcast" line describes send and receive direction simulcast 412 streams separately. Each direction can in turn describe one or more 413 simulcast streams, separated by semicolon. The identifiers 414 describing simulcast streams on the "a=simulcast" line are rid-id, as 415 defined by "a=rid" lines in [I-D.ietf-mmusic-rid]. Each simulcast 416 stream can be offered as a list of alternative rid-id, with each 417 alternative separated by comma (not in the examples above). A 418 detailed specification can be found in Section 5 and more detailed 419 examples are outlined in Section 5.6. 421 5. Detailed Description 423 This section further details the overview above (Section 4). First, 424 formal syntax is provided (Section 5.1), followed by the rest of the 425 SDP attribute definition in Section 5.2. Relating Simulcast Streams 426 (Section 5.5) provides the definition of the RTP/RTCP mechanisms 427 used. The section is concluded with a number of examples. 429 5.1. Simulcast Attribute 431 This document defines a new SDP media-level "a=simulcast" attribute, 432 with value according to the following ABNF [RFC5234] syntax: 434 sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] ) 435 sc-send = "send" SP sc-str-list 436 sc-recv = "recv" SP sc-str-list 437 sc-str-list = sc-alt-list *( ";" sc-alt-list ) 438 sc-alt-list = sc-id *( "," sc-id ) 439 sc-id-paused = "~" 440 sc-id = [sc-id-paused] rid-id 441 ; SP defined in [RFC5234] 442 ; rid-id defined in [I-D.ietf-mmusic-rid] 444 Figure 3: ABNF for Simulcast Value 446 Note to RFC Editor: Replace "I-D.ietf-mmusic-rid" in the above 447 figure with RFC number of draft-ietf-mmusic-rid before publication 448 of this document. 450 The "a=simulcast" attribute has a parameter in the form of one or two 451 simulcast stream descriptions, each consisting of a direction ("send" 452 or "recv"), followed by a list of one or more simulcast streams. 453 Each simulcast stream consists of one or more alternative simulcast 454 formats. Each simulcast format is identified by a simulcast stream 455 identifier (rid-id). The rid-id MUST have the form of an RTP stream 456 identifier, as described by RTP Payload Format Restrictions 457 [I-D.ietf-mmusic-rid]. 459 In the list of simulcast streams, each simulcast stream is separated 460 by a semicolon (";"). Each simulcast stream can in turn be offered 461 in one or more alternative formats, represented by rid-ids, separated 462 by a comma (","). Each rid-id can also be specified as initially 463 paused [RFC7728], indicated by prepending a "~" to the rid-id. The 464 reason to allow separate initial pause states for each rid-id is that 465 pause capability can be specified individually for each RTP payload 466 type referenced by an rid-id. Since pause capability specified via 467 the "a=rtcp-fb" attribute and rid-id specified by "a=rid" can refer 468 to common payload types, it is unfeasible to pause streams with rid- 469 id where any of the related RTP payload type(s) do not have pause 470 capability. 472 It is possible to use source-specific signaling [RFC5576] with 473 "a=simulcast", but it is only in certain cases possible to learn from 474 that signaling which SSRC will belong to a particular simulcast 475 stream. 477 5.2. Simulcast Capability 479 Simulcast capability is expressed through a new media level SDP 480 attribute, "a=simulcast" (Section 5.1). The meaning of the attribute 481 on SDP session level is undefined, MUST NOT be used by 482 implementations of this specification and MUST be ignored if received 483 on session level. Extensions to this specification MAY define such 484 session level usage. Each SDP media description MUST contain at most 485 one "a=simulcast" line. 487 There are separate and independent sets of simulcast streams in send 488 and receive directions. When listing multiple directions, each 489 direction MUST NOT occur more than once on the same line. 491 Simulcast streams using undefined rid-id MUST NOT be used as valid 492 simulcast streams by an RTP stream receiver. The direction for an 493 rid-id MUST be aligned with the direction specified for the 494 corresponding RTP stream identifier on the "a=rid" line. 496 The listed number of simulcast streams for a direction sets a limit 497 to the number of supported simulcast streams in that direction. The 498 order of the listed simulcast streams in the "send" direction 499 suggests a proposed order of preference, in decreasing order: the 500 rid-id listed first is the most preferred and subsequent streams have 501 progressively lower preference. The order of the listed rid-id in 502 the "recv" direction expresses which simulcast streams that are 503 preferred, with the leftmost being most preferred. This can be of 504 importance if the number of actually sent simulcast streams have to 505 be reduced for some reason. 507 rid-id that have explicit dependencies [RFC5583] 508 [I-D.ietf-mmusic-rid] to other rid-id (even in the same media 509 description) MAY be used. 511 Use of more than a single, alternative simulcast format for a 512 simulcast stream MAY be specified as part of the attribute parameters 513 by expressing the simulcast stream as a comma-separated list of 514 alternative rid-id. In this case, it is not possible to align what 515 alternative rid-id that are used across different simulcast streams, 516 like requiring all simulcast streams to use rid-id alternatives 517 referring to the same codec format. The order of the rid-id 518 alternatives within a simulcast stream is significant; the rid-id 519 alternatives are listed from (left) most preferred to (right) least 520 preferred. For the use of simulcast, this overrides the normal codec 521 preference as expressed by format type ordering on the "m=" line, 522 using regular SDP rules. This is to enable a separation of general 523 codec preferences and simulcast stream configuration preferences. 525 A simulcast stream can use a codec defined such that the same RTP 526 SSRC can change RTP payload type multiple times during a session, 527 possibly even on a per-packet basis. A typical example can be a 528 speech codec that makes use of Comfort Noise [RFC3389] and/or DTMF 529 [RFC4733] formats. In those cases, such "related" formats MUST NOT 530 be defined as having their own rid-id listed explicitly in the 531 attribute parameters, since they are not strictly simulcast streams 532 of the media source, but rather a specific way of generating the RTP 533 stream of a single simulcast stream with varying RTP payload type. 535 If RTP stream pause/resume [RFC7728] is supported, any rid-id MAY be 536 prefixed by a "~" character to indicate that the corresponding 537 simulcast stream is initially paused already from start of the RTP 538 session. In this case, support for RTP stream pause/resume MUST also 539 be included under the same "m=" line where "a=simulcast" is included. 540 All RTP payload types related to such initially paused simulcast 541 stream MUST be listed in the SDP as pause/resume capable as specified 542 by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb". 544 An initially paused simulcast stream in "send" direction for the part 545 sending the SDP MUST be considered equivalent to an unsolicited 546 locally paused stream, and be handled accordingly. Initially paused 547 simulcast streams are resumed as described by the RTP pause/resume 548 specification. An RTP stream receiver that wishes to resume an 549 unsolicited locally paused stream needs to know the SSRC of that 550 stream. The SSRC of an initially paused simulcast stream can be 551 obtained from an RTP stream sender RTCP Sender Report (SR) including 552 both the desired SSRC as "SSRC of sender", and the rid-id value in an 553 RtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. 555 Including an initially paused simulcast stream in "recv" direction 556 for the part sending the SDP, sent towards an RTP sender, SHOULD 557 cause the remote RTP sender to put the stream as unsolicited locally 558 paused, unless there are other RTP stream receivers that do not mark 559 the simulcast stream as initially paused. The reason to require an 560 initially paused "recv" stream to be considered locally paused by the 561 remote RTP sender, instead of making it equivalent to implicitly 562 sending a pause request, is because the pausing RTP sender cannot 563 know which receiving SSRC owns the restriction when TMMBR/TMMBN are 564 used for pause/resume signaling (Section 5.6 of [RFC7728]) since the 565 RTP receiver's SSRC in send direction is sometimes not yet known. 567 Use of the redundant audio data [RFC2198] format could be seen as a 568 form of simulcast for loss protection purposes, but is not considered 569 conflicting with the mechanisms described in this memo and MAY 570 therefore be used as any other format. In this case the "red" 571 format, rather than the carried formats, SHOULD be the one to list as 572 a simulcast stream on the "a=simulcast" line. 574 The media formats and corresponding characteristics of simulcast 575 streams SHOULD be chosen such that they are different, e.g. as 576 different SDP formats with differing "a=rtpmap" and/or "a=fmtp" 577 lines, or as differently defined RTP payload format restrictions. If 578 this difference is not required, RTP duplication [RFC7104] procedures 579 SHOULD be considered instead of simulcast. To avoid complications in 580 implementations, a single rid-id MUST NOT occur more than once per 581 "a=simulcast" line. Note that this does not eliminate use of 582 simulcast as an RTP duplication mechanism, since it is possible to 583 define multiple different rid-id that are effectively equivalent. 585 5.3. Offer/Answer Use 587 Note: The inclusion of "a=simulcast" or the use of simulcast does 588 not change any of the interpretation or Offer/Answer procedures 589 for other SDP attributes, like "a=fmtp" or "a=rid". 591 5.3.1. Generating the Initial SDP Offer 593 An offerer wanting to use simulcast for a media description SHALL 594 include one "a=simulcast" attribute in that media description in the 595 offer. An offerer listing a set of receive simulcast streams and/or 596 alternative formats as rid-id in the offer MUST be prepared to 597 receive RTP streams for any of those simulcast streams and/or 598 alternative formats from the answerer. 600 5.3.2. Creating the SDP Answer 602 An answerer that does not understand the concept of simulcast will 603 also not know the attribute and will remove it in the SDP answer, as 604 defined in existing SDP Offer/Answer [RFC3264] procedures. Since SDP 605 session level simulcast is undefined in this memo, an answerer that 606 receives an offer with the "a=simulcast" attribute on SDP session 607 level SHALL remove it in the answer. An answerer that understands 608 the attribute but receives multiple "a=simulcast" attributes in the 609 same media description SHALL disable use of simulcast by removing all 610 "a=simulcast" lines for that media description in the answer. 612 An answerer that does understand the attribute and that wants to 613 support simulcast in an indicated direction SHALL reverse 614 directionality of the unidirectional direction parameters; "send" 615 becomes "recv" and vice versa, and include it in the answer. 617 An answerer that receives an offer with simulcast containing an 618 "a=simulcast" attribute listing alternative rid-id MAY keep all the 619 alternative rid-id in the answer, but it MAY also choose to remove 620 any non-desirable alternative rid-id in the answer. The answerer 621 MUST NOT add any alternative rid-id in send direction in the answer 622 that were not present in the offer receive direction. The answerer 623 MUST be prepared to receive any of the receive direction rid-id 624 alternatives, and MAY send any of the send direction alternatives 625 that are kept in the answer. 627 An answerer that receives an offer with simulcast that lists a number 628 of simulcast streams, MAY reduce the number of simulcast streams in 629 the answer, but MUST NOT add simulcast streams. 631 An answerer that receives an offer without RTP stream pause/resume 632 capability MUST NOT mark any simulcast streams as initially paused in 633 the answer. 635 An RTP stream pause/resume capable answerer that receives an offer 636 with RTP stream pause/resume capability MAY mark any rid-id that 637 refer to pause/resume capable formats as initially paused in the 638 answer. 640 An answerer that receives indication in an offer of an rid-id being 641 initially paused SHOULD mark that rid-id as initially paused also in 642 the answer, regardless of direction, unless it has good reason for 643 the rid-id not being initially paused. One reason to remove an 644 initial pause in the answer compared to the offer could, for example, 645 be that all receive direction simulcast streams for a media source 646 the answerer accepts in the answer would otherwise be paused. 648 5.3.3. Offerer Processing the SDP Answer 650 An offerer that receives an answer without "a=simulcast" MUST NOT use 651 simulcast towards the answerer. An offerer that receives an answer 652 with "a=simulcast" without any rid-id in a specified direction MUST 653 NOT use simulcast in that direction. 655 An offerer that receives an answer where some rid-id alternatives are 656 kept MUST be prepared to receive any of the kept send direction rid- 657 id alternatives, and MAY send any of the kept receive direction rid- 658 id alternatives. 660 An offerer that receives an answer where some of the rid-id are 661 removed compared to the offer MAY release the corresponding resources 662 (codec, transport, etc) in its receive direction and MUST NOT send 663 any RTP packets corresponding to the removed rid-id. 665 An offerer that offered some of its rid-id as initially paused and 666 that receives an answer that does not indicate RTP stream pause/ 667 resume capability, MUST NOT initially pause any simulcast streams. 669 An offerer with RTP stream pause/resume capability that receives an 670 answer where some rid-id are marked as initially paused, SHOULD 671 initially pause those RTP streams regardless if they were marked as 672 initially paused also in the offer, unless it has good reason for 673 those RTP streams not being initially paused. One such reason could, 674 for example, be that the answerer would otherwise initially not 675 receive any media of that type at all. 677 5.3.4. Modifying the Session 679 Offers inside an existing session follow the same rules as for 680 initial SDP offer, with these additions: 682 1. rid-id marked as initially paused in the offerer's send direction 683 SHALL reflect the offerer's opinion of the current pause state at 684 the time of creating the offer. This is purely informational, 685 and RTP stream pause/resume [RFC7728] signaling in the ongoing 686 session SHALL take precedence in case of any conflict or 687 ambiguity. 689 2. rid-id marked as initially paused in the offerer's receive 690 direction SHALL (as in an initial offer) reflect the offerer's 691 desired rid-id pause state. Except for the case where the 692 offerer already paused the corresponding RTP stream through RTP 693 stream pause/resume [RFC7728] signaling , this is identical to 694 the conditions at an initial offer. 696 Creation of SDP answers and processing of SDP answers inside an 697 existing session follow the same rules as described above for initial 698 SDP offer/answer. 700 Session modification restrictions in section 6.5 of RTP payload 701 format restrictions [I-D.ietf-mmusic-rid] also apply. 703 5.4. Use with Declarative SDP 705 This document does not define the use of "a=simulcast" in declarative 706 SDP, partly motivated by use of the simulcast format identification 707 [I-D.ietf-mmusic-rid] not being defined for use in declarative SDP. 709 If concrete use cases for simulcast in declarative SDP are identified 710 in the future, the authors of this memo expect that additional 711 specifications will address such use. 713 5.5. Relating Simulcast Streams 715 Simulcast RTP streams MUST be related on RTP level through 716 RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP 717 "a=simulcast" attribute (Section 5.2) parameters. This is sufficient 718 as long as there is only a single media source per SDP media 719 description. When using BUNDLE 720 [I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media 721 descriptions jointly specify a single RTP session, the SDES MID 722 identification mechanism in BUNDLE allows relating RTP streams back 723 to individual media descriptions, after which the above described 724 RtpStreamId relations can be used. Use of the RTP header extension 725 [RFC5285] for both MID and RtpStreamId identifications can be 726 important to ensure rapid initial reception, required to correctly 727 interpret and process the RTP streams. Implementers of this 728 specification MUST support the RTCP source description (SDES) item 729 method and SHOULD support RTP header extension method to signal 730 RtpStreamId on RTP level. 732 NOTE: For the case where it is clear from SDP that RTP PT uniquely 733 maps to corresponding RtpStreamId, an RTP receiver can use RTP PT 734 to relate simulcast streams. This can sometimes enable decoding 735 even in advance to receiving RtpStreamId information in RTCP SDES 736 and/or RTP header extensions. 738 RTP streams MUST only use a single alternative rid-id at a time 739 (based on RTP timestamps), but MAY change format (and rid-id) on a 740 per-RTP packet basis. This corresponds to the existing (non- 741 simulcast) SDP offer/answer case when multiple formats are included 742 on the "m=" line in the SDP answer, enabling per-RTP packet change of 743 RTP payload type. 745 5.6. Signaling Examples 747 These examples describe a client to video conference service, using a 748 centralized media topology with an RTP mixer. 750 +---+ +-----------+ +---+ 751 | A |<---->| |<---->| B | 752 +---+ | | +---+ 753 | Mixer | 754 +---+ | | +---+ 755 | F |<---->| |<---->| J | 756 +---+ +-----------+ +---+ 758 Figure 4: Four-party Mixer-based Conference 760 5.6.1. Single-Source Client 762 Alice is calling in to the mixer with a simulcast-enabled client 763 capable of a single media source per media type. The client can send 764 a simulcast of 2 video resolutions and frame rates: HD 1280x720p 765 30fps and thumbnail 320x180p 15fps. This is defined below using the 766 "imageattr" [RFC6236]. In this example, only the "pt" "a=rid" 767 parameter is used, effectively achieving a 1:1 mapping between 768 RtpStreamId and media formats (RTP payload types), to describe 769 simulcast stream formats. Alice's Offer: 771 v=0 772 o=alice 2362969037 2362969040 IN IP4 192.0.2.156 773 s=Simulcast Enabled Client 774 t=0 0 775 c=IN IP4 192.0.2.156 776 m=audio 49200 RTP/AVP 0 777 a=rtpmap:0 PCMU/8000 778 m=video 49300 RTP/AVP 97 98 779 a=rtpmap:97 H264/90000 780 a=rtpmap:98 H264/90000 781 a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 782 a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 783 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] 784 a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] 785 a=rid:1 send pt=97 786 a=rid:2 send pt=98 787 a=rid:3 recv pt=97 788 a=simulcast:send 1;2 recv 3 789 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId 791 Figure 5: Single-Source Simulcast Offer 793 The only thing in the SDP that indicates simulcast capability is the 794 line in the video media description containing the "simulcast" 795 attribute. The included "a=fmtp" and "a=imageattr" parameters 796 indicates that sent simulcast streams can differ in video resolution. 797 The RTP header extension for RtpStreamId is offered to avoid issues 798 with the initial binding between RTP streams (SSRCs) and the 799 RtpStreamId identifying the simulcast stream and its format. 801 The Answer from the server indicates that it too is simulcast 802 capable. Should it not have been simulcast capable, the 803 "a=simulcast" line would not have been present and communication 804 would have started with the media negotiated in the SDP. Also the 805 usage of the RtpStreamId RTP header extension is accepted. 807 v=0 808 o=server 823479283 1209384938 IN IP4 192.0.2.2 809 s=Answer to Simulcast Enabled Client 810 t=0 0 811 c=IN IP4 192.0.2.43 812 m=audio 49672 RTP/AVP 0 813 a=rtpmap:0 PCMU/8000 814 m=video 49674 RTP/AVP 97 98 815 a=rtpmap:97 H264/90000 816 a=rtpmap:98 H264/90000 817 a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 818 a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 819 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] 820 a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] 821 a=rid:1 recv pt=97 822 a=rid:2 recv pt=98 823 a=rid:3 send pt=97 824 a=simulcast:recv 1;2 send 3 825 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId 827 Figure 6: Single-Source Simulcast Answer 829 Since the server is the simulcast media receiver, it reverses the 830 direction of the "simulcast" and "rid" attribute parameters. 832 5.6.2. Multi-Source Client 834 Fred is calling in to the same conference as in the example above 835 with a two-camera, two-display system, thus capable of handling two 836 separate media sources in each direction, where each media source is 837 simulcast-enabled in the send direction. Fred's client is restricted 838 to a single media source per media description. 840 The first two simulcast streams for the first media source use 841 different codecs, H264-SVC [RFC6190] and H264 [RFC6184]. These two 842 simulcast streams also have a temporal dependency. Two different 843 video codecs, VP8 [RFC7741] and H264, are offered as alternatives for 844 the third simulcast stream for the first media source. Only the 845 highest fidelity simulcast stream is sent from start, the lower 846 fidelity streams being initially paused. 848 The second media source is offered with three different simulcast 849 streams. All video streams of this second media source are loss 850 protected by RTP retransmission [RFC4588]. Also here, all but the 851 highest fidelity simulcast stream are initially paused. 853 Fred's client is also using BUNDLE to send all RTP streams from all 854 media descriptions in the same RTP session on a single media 855 transport. Although using many different simulcast streams in this 856 example, the use of RtpStreamId as simulcast stream identification 857 enables use of a low number of RTP payload types. Note that the use 858 of both BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and "a=rid" 859 [I-D.ietf-mmusic-rid] recommends using the RTP header extension 860 [RFC5285] for carrying these RTP stream identification fields, which 861 is consequently also included in the SDP. Note also that for 862 "a=rid", the corresponding SDES attribute is named RtpStreamId 863 [I-D.ietf-avtext-rid]. 865 v=0 866 o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d 867 s=Offer from Simulcast Enabled Multi-Source Client 868 t=0 0 869 c=IN IP6 2001:db8::c000:27d 870 a=group:BUNDLE foo bar zen 872 m=audio 49200 RTP/AVP 99 873 a=mid:foo 874 a=rtpmap:99 G722/8000 876 m=video 49600 RTP/AVPF 100 101 103 877 a=mid:bar 878 a=rtpmap:100 H264-SVC/90000 879 a=rtpmap:101 H264/90000 880 a=rtpmap:103 VP8/90000 881 a=fmtp:100 profile-level-id=42400d; max-fs=3600; max-mbps=108000; \ 882 mst-mode=NI-TC 883 a=fmtp:101 profile-level-id=42c00d; max-fs=3600; max-mbps=54000 884 a=fmtp:103 max-fs=900; max-fr=30 885 a=rid:1 send pt=100;max-width=1280;max-height=720;max-fps=60;depend=2 886 a=rid:2 send pt=101;max-width=1280;max-height=720;max-fps=30 887 a=rid:3 send pt=101;max-width=640;max-height=360 888 a=rid:4 send pt=103;max-width=640;max-height=360 889 a=depend:100 lay bar:101 890 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 891 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId 892 a=rtcp-fb:* ccm pause nowait 893 a=simulcast:send 1;2;~4,3 895 m=video 49602 RTP/AVPF 96 104 896 a=mid:zen 897 a=rtpmap:96 VP8/90000 898 a=fmtp:96 max-fs=3600; max-fr=30 899 a=rtpmap:104 rtx/90000 900 a=fmtp:104 apt=96;rtx-time=200 901 a=rid:1 send pt=96;max-fs=921600;max-fps=30 902 a=rid:2 send pt=96;max-fs=614400;max-fps=15 903 a=rid:3 send pt=96;max-fs=230400;max-fps=30 904 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 905 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId 906 a=rtcp-fb:* ccm pause nowait 907 a=simulcast:send 1;~2;~3 909 Figure 7: Fred's Multi-Source Simulcast Offer 911 Note: Empty lines in the SDP above are added only for readability 912 and would not be present in an actual SDP. 914 6. RTP Aspects 916 This section discusses what the different entities in a simulcast 917 media path can expect to happen on RTP level. This is explored from 918 source to sink by starting in an endpoint with a media source that is 919 simulcasted to an RTP middlebox. That RTP middlebox sends media 920 sources both to other RTP middleboxes (cascaded middleboxes), as well 921 as selecting some simulcast format of the media source and sending it 922 to receiving endpoints. Different types of RTP middleboxes and their 923 usage of the different simulcast formats results in several different 924 behaviors. 926 6.1. Outgoing from Endpoint with Media Source 928 The most straightforward simulcast case is the RTP streams being 929 emitted from the endpoint that originates a media source. When 930 simulcast has been negotiated in the sending direction, the endpoint 931 can transmit up to the number of RTP streams needed for the 932 negotiated simulcast streams for that media source. Each RTP stream 933 (SSRC) is identified by associating (Section 5.5) it with an 934 RtpStreamId SDES item, transmitted in RTCP and possibly also as an 935 RTP header extension. In cases where multiple media sources have 936 been negotiated for the same RTP session and thus BUNDLE 937 [I-D.ietf-mmusic-sdp-bundle-negotiation] is used, also the MID SDES 938 item will be sent similarly to the RtpStreamId. 940 Each RTP stream may not be continuously transmitted due to any of the 941 following reasons; temporarily paused using Pause/Resume [RFC7728], 942 sender side application logic temporarily pausing it, or lack of 943 network resources to transmit this simulcast stream. However, all 944 simulcast streams that have been negotiated have active and 945 maintained SSRC (at least in regular RTCP reports), even if no RTP 946 packets are currently transmitted. The relation between an RTP 947 Stream (SSRC) and a particular simulcast stream is not expected to 948 change, except in exceptional situations such as SSRC collisions. At 949 SSRC changes, the usage of MID and RtpStreamId should enable the 950 receiver to correctly identify the RTP streams even after an SSRC 951 change. 953 6.2. RTP Middlebox to Receiver 955 RTP streams in a multi-party RTP session can be used in multiple 956 different ways, when the session utilizes simulcast at least on the 957 media source to middlebox legs. This is to a large degree due to the 958 different RTP middlebox behaviors, but also the needs of the 959 application. This text assumes that the RTP middlebox will select a 960 media source and choose which simulcast stream for that media source 961 to deliver to a specific receiver. In many cases, at most one 962 simulcast stream per media source will be forwarded to a particular 963 receiver at any instant in time, even if the selected simulcast 964 stream may vary. For cases where this does not hold due to 965 application needs, then the RTP stream aspects will fall under the 966 middlebox to middlebox case Section 6.3. 968 The selection of which simulcast streams to forward towards the 969 receiver, is application specific. However, in conferencing 970 applications, active speaker selection is common. In case the number 971 of media sources possible to forward, N, is less than the total 972 amount of media sources available in an multi-media session, the 973 current and previous speakers (up to N in total) are often the ones 974 forwarded. To avoid the need for media specific processing to 975 determine the current speaker(s) in the RTP middlebox, the endpoint 976 providing a media source may include meta data, such as the RTP 977 Header Extension for Client-to-Mixer Audio Level Indication 978 [RFC6464]. 980 The possibilities for stream switching are media type specific, but 981 for media types with significant interframe dependencies in the 982 encoding, like most video coding, the switching needs to be made at 983 suitable switching points in the media stream that breaks or 984 otherwise deals with the dependency structure. Even if switching 985 points can be included periodically, it is common to use mechanisms 986 like Full Intra Requests [RFC5104] to request switching points from 987 the endpoint performing the encoding of the media source. 989 Inclusion of the RtpStreamId SDES item for an SSRC in the middlebox 990 to receiver direction should only occur when use of RtpStreamId has 991 been negotiated in that direction. It is worth noting that one can 992 signal multiple RtpStreamIds when simulcast signalling indicates only 993 a single simulcast stream, allowing one to use all of the 994 RtpStreamIds as alternatives for that simulcast stream. One reason 995 for including the RtpStreamId in the middlebox to receiver direction 996 for an RTP stream is to let the receiver know which restrictions 997 apply to the currently delivered RTP stream. In case the RtpStreamId 998 is negotiated to be used, it is important to remember that the used 999 identifiers will be specific to each signalling session. Even if the 1000 central entity can attempt to coordinate, it is likely that the 1001 RtpStreamIds need to be translated to the leg specific values. The 1002 below cases will have as base line that RtpStreamId is not used in 1003 the mixer to receiver direction. 1005 6.2.1. Media-Switching Mixer 1007 This section discusses the behavior in cases where the RTP middlebox 1008 behaves like the Media-Switching Mixer (Section 3.6.2) in RTP 1009 Topologies [RFC7667]. The fundamental aspect here is that the media 1010 sources delivered from the middlebox will be the mixer's conceptual 1011 or functional ones. For example, one media source may be the main 1012 speaker in high resolution video, while a number of other media 1013 sources are thumbnails of each participant. 1015 The above results in that the RTP stream produced by the mixer is one 1016 that switches between a number of received incoming RTP streams for 1017 different media sources and in different simulcast versions. The 1018 mixer selects the media source to be sent as one of the RTP streams, 1019 and then selects among the available simulcast streams for the most 1020 appropriate one. The selection criteria include available bandwidth 1021 on the mixer to receiver path and restrictions based on the 1022 functional usage of the RTP stream delivered to the receiver. As an 1023 example of the latter, it is unnecessary to forward a full HD video 1024 to a receiver if the display area is just a thumbnail. Thus, 1025 restrictions may exist to not allow some simulcast streams to be 1026 forwarded for some of the mixer's media sources. 1028 This will result in a single RTP stream being used for each of the 1029 RTP mixer's media sources. This RTP stream is at any point in time a 1030 selection of one particular RTP stream arriving to the mixer, where 1031 the RTP header field values are rewritten to provide a consistent, 1032 single RTP stream. If the RTP mixer doesn't receive any incoming 1033 stream matched to this media source, the SSRC will not transmit, but 1034 be kept alive using RTCP. The SSRC and thus RTP stream for the 1035 mixer's media source is expected to be long term stable. It will 1036 only be changed by signalling or other disruptive events. Note that 1037 although the above talks about a single RTP stream, there can in some 1038 cases be multiple RTP streams carrying the selected simulcast stream 1039 for the originating media source, including redundancy or other 1040 auxiliary RTP streams. 1042 The mixer may communicate the identity of the originating media 1043 source to the receiver by including the CSRC field with the 1044 originating media source's SSRC value. Note that due to the 1045 possibility that the RTP mixer switches between simulcast versions of 1046 the media source, the CSRC value may change, even if the media source 1047 is kept the same. 1049 It is important to note that any MID SDES item from the originating 1050 media source needs to be removed and not be associated with the RTP 1051 stream's SSRC. That is, there is nothing in the signalling between 1052 the mixer and the receiver that is structured around the originating 1053 media sources, only the mixer's media sources. If they would be 1054 associated with the SSRC, the receiver would likely believe that 1055 there has been an SSRC collision, and that the RTP stream is spurious 1056 as it doesn't carry the identifiers used to relate it to the correct 1057 context. However, this is not true for CSRC values, as long as they 1058 are never used as SSRC. In these cases one could provide CNAME and 1059 MID as SDES items. A receiver could use this to determine which CSRC 1060 values that are associated with the same originating media source. 1062 If RtpStreamIds are used in the scenario described by this section, 1063 it should be noted that the RtpStreamId on a particular SSRC will 1064 change based on the actual simulcast stream selected for switching. 1065 These RtpStreamId identifiers will be local to this leg's signalling 1066 context. In addition, the defined RtpStreamIds and their parameters 1067 need to cover all the media sources and simulcast streams received by 1068 the RTP mixer that can be switched into this media source, sent by 1069 the RTP mixer. 1071 6.2.2. Selective Forwarding Middlebox 1073 This section discusses the behavior in cases where the RTP middlebox 1074 behaves like the Selective Forwarding Middlebox (Section 3.7) in RTP 1075 Topologies [RFC7667]. Applications for this type of RTP middlebox 1076 results in that each originating media source will have a 1077 corresponding media source on the leg between the middlebox and the 1078 receiver. A Selective Forwarding Middlebox (SFM) could go as far as 1079 exposing all the simulcast streams for an media source, however this 1080 section will focus on having a single simulcast stream that can 1081 contain any of the simulcast formats. This section will assume that 1082 the SFM projection mechanism works on media source level, and maps 1083 one of the media source's simulcast streams onto one RTP stream from 1084 the SFM to the receiver. 1086 This usage will result in that the individual RTP stream(s) for one 1087 media source can switch between being active to paused, based on the 1088 subset of media sources the SFM wants to provide the receiver for the 1089 moment. With SFMs there exist no reasons to use CSRC to indicate the 1090 originating stream, as there is a one to one media source mapping. 1091 If the application requires knowing the simulcast version received to 1092 function well, then RtpStreamId should be negotiated on the SFM to 1093 receiver leg. Which simulcast stream that is being forwarded is not 1094 made explicit unless RtpStreamId is used on the leg. 1096 Any MID SDES items being sent by the SFM to the receiver are only 1097 those agreed between the SFM and the receiver, and no MID values from 1098 the originating side of the SFM are to be forwarded. 1100 A SFM could expose corresponding RTP streams for all the media 1101 sources and their simulcast streams, and then for any media source 1102 that is to be provided forward one selected simulcast stream. 1103 However, this is not recommended as it would unnecessarily increase 1104 the number of RTP streams and require the receiver to timely detect 1105 switching between simulcast streams. The above usage requires the 1106 same SFM functionality for switching, while avoiding the 1107 uncertainties of timely detecting that a RTP stream ends. The 1108 benefit would be that the received simulcast stream would be 1109 implicitly provided by which RTP stream would be active for a media 1110 source. However, using RtpStreamId to make this explicit also 1111 exposes which alternative format is used. The conclusion is that 1112 using one RTP stream per simulcast stream is unnecessary. The issue 1113 with timely detecting end of streams, independent if they are stopped 1114 temporarily or long term, is that there is no explicit indication 1115 that the transmission has intentionally been stopped. The RTCP based 1116 Pause and Resume mechanism [RFC7728] includes a PAUSED indication 1117 that provides the last RTP sequence number transmitted prior to the 1118 pause. Due to usage, the timeliness of this solution depends on when 1119 delivery using RTCP can occur in relation to the transmission of the 1120 last RTP packet. If no explicit information is provided at all, then 1121 detection based on non increasing RTCP SR field values and timers 1122 need to be used to determine pause in RTP packet delivery. This 1123 results in that one can usually not determine when the last RTP 1124 packet arrives (if it arrives) that this will be the last. That it 1125 was the last is something that one learns later. 1127 6.3. RTP Middlebox to RTP Middlebox 1129 This relates to the transmission of simulcast streams between RTP 1130 middleboxes or other usages where one wants to enable the delivery of 1131 multiple simultaneous simulcast streams per media source, but the 1132 transmitting entity is not the originating endpoint. For a 1133 particular direction between middlebox A and B, this looks very 1134 similar to the originating to middlebox case on a media source basis. 1135 However, in this case there is usually multiple media sources, 1136 originating from multiple endpoints. This can create situations 1137 where limitations in the number of simultaneously received media 1138 streams can arise, for example due to limitation in network 1139 bandwidth. In this case, a subset of not only the simulcast streams, 1140 but also media sources can be selected. This results in that 1141 individual RTP streams can be become paused at any point and later 1142 being resumed based on various criteria. 1144 The MIDs used between A and B are the ones agreed between these two 1145 identities in signalling. The RtpStreamId values will also be 1146 provided to ensure explicit information about which simulcast stream 1147 they are. The RTP stream to MID and RtpStreamId associations should 1148 here be long term stable. 1150 7. Network Aspects 1152 Simulcast is in this memo defined as the act of sending multiple 1153 alternative encoded streams of the same underlying media source. 1154 When transmitting multiple independent streams that originate from 1155 the same source, it could potentially be done in several different 1156 ways using RTP. A general discussion on considerations for use of 1157 the different RTP multiplexing alternatives can be found in 1158 Guidelines for Multiplexing in RTP 1159 [I-D.ietf-avtcore-multiplex-guidelines]. Discussion and 1160 clarification on how to handle multiple streams in an RTP session can 1161 be found in [RFC8108]. 1163 The network aspects that are relevant for simulcast are: 1165 Quality of Service: When using simulcast it might be of interest to 1166 prioritize a particular simulcast stream, rather than applying 1167 equal treatment to all streams. For example, lower bit-rate 1168 streams may be prioritized over higher bit-rate streams to 1169 minimize congestion or packet losses in the low bit-rate streams. 1170 Thus, there is a benefit to use a simulcast solution with good QoS 1171 support. 1173 NAT/FW Traversal: Using multiple RTP sessions incurs more cost for 1174 NAT/FW traversal unless they can re-use the same transport flow, 1175 which can be achieved by Multiplexing Negotiation Using SDP Port 1176 Numbers [I-D.ietf-mmusic-sdp-bundle-negotiation]. 1178 7.1. Bitrate Adaptation 1180 Use of multiple simulcast streams can require a significant amount of 1181 network resources. If the amount of available network resources 1182 varies during an RTP session such that it does not match what is 1183 negotiated in SDP, the bitrate used by the different simulcast 1184 streams may have to be reduced dynamically. What simulcast streams 1185 to prioritize when allocating available bitrate among the simulcast 1186 streams in such adaptation SHOULD be taken from the simulcast stream 1187 order on the "a=simulcast" line and ordering of alternative simulcast 1188 formats Section 5.2. Simulcast streams that have pause/resume 1189 capability and that would be given such low bitrate by the adaptation 1190 process that they are considered not really useful can be temporarily 1191 paused until the limiting condition clears. 1193 8. Limitation 1195 The chosen approach has a limitation that relates to the use of a 1196 single RTP session for all simulcast formats of a media source, which 1197 comes from sending all simulcast streams related to a media source 1198 under the same SDP media description. 1200 It is not possible to use different simulcast streams on different 1201 media transports, limiting the possibilities to apply different QoS 1202 to different simulcast streams. When using unicast, QoS mechanisms 1203 based on individual packet marking are feasible, since they do not 1204 require separation of simulcast streams into different RTP sessions 1205 to apply different QoS. 1207 It is also not possible to separate different simulcast streams into 1208 different multicast groups to allow a multicast receiver to pick the 1209 stream it wants, rather than receive all of them. In this case, the 1210 only reasonable implementation is to use different RTP sessions for 1211 each multicast group so that reporting and other RTCP functions 1212 operate as intended. Such simulcast usage in multicast context is 1213 out of scope for the current document and would require additional 1214 specification. 1216 9. IANA Considerations 1218 This document requests to register a new media-level SDP attribute, 1219 "simulcast", in the "att-field (media level only)" registry within 1220 the SDP parameters registry, according to the procedures of [RFC4566] 1221 and [I-D.ietf-mmusic-sdp-mux-attributes]. 1223 Contact name, email: IETF, contacted via mmusic@ietf.org, or a 1224 successor address designated by IESG 1226 Attribute name: simulcast 1228 Long-form attribute name: Simulcast stream description 1230 Charset dependent: No 1232 Attribute value: sc-value; see Section 5.1 of RFC XXXX. 1234 Purpose: Signals simulcast capability for a set of RTP streams 1236 MUX category: NORMAL 1238 Note to RFC Editor: Please replace "RFC XXXX" with the assigned 1239 number of this RFC. 1241 10. Security Considerations 1243 The simulcast capability, configuration attributes, and parameters 1244 are vulnerable to attacks in signaling. 1246 A false inclusion of the "a=simulcast" attribute may result in 1247 simultaneous transmission of multiple RTP streams that would 1248 otherwise not be generated. The impact is limited by the media 1249 description joint bandwidth, shared by all simulcast streams 1250 irrespective of their number. There may however be a large number of 1251 unwanted RTP streams that will impact the share of bandwidth 1252 allocated for the originally wanted RTP stream. 1254 A hostile removal of the "a=simulcast" attribute will result in 1255 simulcast not being used. 1257 Neither of the above will likely have any major consequences and can 1258 be mitigated by signaling that is at least integrity and source 1259 authenticated to prevent an attacker to change it. 1261 Security considerations related to the use of "a=rid" and the 1262 RtpStreamId SDES item is covered in [I-D.ietf-mmusic-rid] and 1263 [I-D.ietf-avtext-rid]. There are no additional security concerns 1264 related to their use in this specification. 1266 11. Contributors 1268 Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have 1269 contributed with important material to the first versions of this 1270 document. Robert Hansen and Cullen Jennings, from Cisco, Peter 1271 Thatcher, from Google, and Adam Roach, from Mozilla, contributed 1272 significantly to subsequent versions. 1274 12. Acknowledgements 1276 The authors would like to thank Bernard Aboba, Thomas Belling, Roni 1277 Even, Adam Roach, Inaki Baz Castillo, Paul Kyzivat, and Arun 1278 Arunachalam for the feedback they provided during the development of 1279 this document. 1281 13. References 1283 13.1. Normative References 1285 [I-D.ietf-avtext-rid] 1286 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 1287 Identifier Source Description (SDES)", draft-ietf-avtext- 1288 rid-09 (work in progress), October 2016. 1290 [I-D.ietf-mmusic-rid] 1291 Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., 1292 Roach, A., and B. Campen, "RTP Payload Format 1293 Restrictions", draft-ietf-mmusic-rid-11 (work in 1294 progress), July 2017. 1296 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1297 Holmberg, C., Alvestrand, H., and C. Jennings, 1298 "Negotiating Media Multiplexing Using the Session 1299 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1300 negotiation-38 (work in progress), April 2017. 1302 [I-D.ietf-mmusic-sdp-mux-attributes] 1303 Nandakumar, S., "A Framework for SDP Attributes when 1304 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1305 (work in progress), December 2016. 1307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1308 Requirement Levels", BCP 14, RFC 2119, 1309 DOI 10.17487/RFC2119, March 1997, 1310 . 1312 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1313 Jacobson, "RTP: A Transport Protocol for Real-Time 1314 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1315 July 2003, . 1317 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1318 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1319 July 2006, . 1321 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1322 Specifications: ABNF", STD 68, RFC 5234, 1323 DOI 10.17487/RFC5234, January 2008, 1324 . 1326 [RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP 1327 Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, 1328 February 2016, . 1330 13.2. Informative References 1332 [I-D.ietf-avtcore-multiplex-guidelines] 1333 Westerlund, M., Perkins, C., and H. Alvestrand, 1334 "Guidelines for using the Multiplexing Features of RTP to 1335 Support Multiple Media Streams", draft-ietf-avtcore- 1336 multiplex-guidelines-03 (work in progress), October 2014. 1338 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 1339 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 1340 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 1341 DOI 10.17487/RFC2198, September 1997, 1342 . 1344 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1345 with Session Description Protocol (SDP)", RFC 3264, 1346 DOI 10.17487/RFC3264, June 2002, 1347 . 1349 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 1350 Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, 1351 September 2002, . 1353 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1354 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1355 DOI 10.17487/RFC4588, July 2006, 1356 . 1358 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 1359 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 1360 DOI 10.17487/RFC4733, December 2006, 1361 . 1363 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 1364 "Codec Control Messages in the RTP Audio-Visual Profile 1365 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 1366 February 2008, . 1368 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 1369 Correction", RFC 5109, DOI 10.17487/RFC5109, December 1370 2007, . 1372 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1373 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 1374 2008, . 1376 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1377 Media Attributes in the Session Description Protocol 1378 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 1379 . 1381 [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding 1382 Dependency in the Session Description Protocol (SDP)", 1383 RFC 5583, DOI 10.17487/RFC5583, July 2009, 1384 . 1386 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP 1387 Payload Format for H.264 Video", RFC 6184, 1388 DOI 10.17487/RFC6184, May 2011, 1389 . 1391 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 1392 "RTP Payload Format for Scalable Video Coding", RFC 6190, 1393 DOI 10.17487/RFC6190, May 2011, 1394 . 1396 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 1397 Attributes in the Session Description Protocol (SDP)", 1398 RFC 6236, DOI 10.17487/RFC6236, May 2011, 1399 . 1401 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 1402 Transport Protocol (RTP) Header Extension for Client-to- 1403 Mixer Audio Level Indication", RFC 6464, 1404 DOI 10.17487/RFC6464, December 2011, 1405 . 1407 [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping 1408 Semantics in the Session Description Protocol", RFC 7104, 1409 DOI 10.17487/RFC7104, January 2014, 1410 . 1412 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 1413 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 1414 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 1415 DOI 10.17487/RFC7656, November 2015, 1416 . 1418 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1419 DOI 10.17487/RFC7667, November 2015, 1420 . 1422 [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 1423 Galligan, "RTP Payload Format for VP8 Video", RFC 7741, 1424 DOI 10.17487/RFC7741, March 2016, 1425 . 1427 [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 1428 "Sending Multiple RTP Streams in a Single RTP Session", 1429 RFC 8108, DOI 10.17487/RFC8108, March 2017, 1430 . 1432 Appendix A. Requirements 1434 The following requirements have to be met to support the use cases 1435 (Section 3): 1437 REQ-1: Identification: 1439 REQ-1.1: It must be possible to identify a set of simulcasted RTP 1440 streams as originating from the same media source in SDP 1441 signaling. 1443 REQ-1.2: An RTP endpoint must be capable of identifying the 1444 simulcast stream a received RTP stream is associated with, 1445 knowing the content of the SDP signalling. 1447 REQ-2: Transport usage. The solution must work when using: 1449 REQ-2.1: Legacy SDP with separate media transports per SDP media 1450 description. 1452 REQ-2.2: Bundled [I-D.ietf-mmusic-sdp-bundle-negotiation] SDP 1453 media descriptions. 1455 REQ-3: Capability negotiation. It must be possible that: 1457 REQ-3.1: Sender can express capability of sending simulcast. 1459 REQ-3.2: Receiver can express capability of receiving simulcast. 1461 REQ-3.3: Sender can express maximum number of simulcast streams 1462 that can be provided. 1464 REQ-3.4: Receiver can express maximum number of simulcast streams 1465 that can be received. 1467 REQ-3.5: Sender can detail the characteristics of the simulcast 1468 streams that can be provided. 1470 REQ-3.6: Receiver can detail the characteristics of the simulcast 1471 streams that it prefers to receive. 1473 REQ-4: Distinguishing features. It must be possible to have 1474 different simulcast streams use different codec parameters, as can 1475 be expressed by SDP format values and RTP payload types. 1477 REQ-5: Compatibility. It must be possible to use simulcast in 1478 combination with other RTP mechanisms that generate additional RTP 1479 streams: 1481 REQ-5.1: RTP Retransmission [RFC4588]. 1483 REQ-5.2: RTP Forward Error Correction [RFC5109]. 1485 REQ-5.3: Related payload types such as audio Comfort Noise and/or 1486 DTMF. 1488 REQ-5.4: A single simulcast stream can consist of multiple RTP 1489 streams, to support codecs where a dependent stream is 1490 dependent on a set of encoded and dependent streams, each 1491 potentially carried in their own RTP stream. 1493 REQ-6: Interoperability. The solution must be possible to use in: 1495 REQ-6.1: Interworking with non-simulcast legacy clients using a 1496 single media source per media type. 1498 REQ-6.2: WebRTC environment with a single media source per SDP 1499 media description. 1501 Appendix B. Changes From Earlier Versions 1503 NOTE TO RFC EDITOR: Please remove this section prior to publication. 1505 B.1. Modifications Between WG Version -09 and -10 1507 o Amended overview section with a bit more explanation on the 1508 examples, and added an rid-id alternative for one of the streams. 1510 o Removed SCID also from the Terminology section, which was 1511 forgotten in -09 when changing SCID to rid-id. 1513 B.2. Modifications Between WG Version -08 and -09 1515 o Changed SCID to rid-id, to align with ietf-draft-mmusic-rid 1516 naming. 1518 o Changed Overview to be based on examples and shortened it. 1520 o Changed semantics of initially paused rid-id in modified SDP 1521 offers from requiring it to follow actual RFC 7728 pause state to 1522 an informational offerer's opinion at the time of offer creation, 1523 not in any way overriding or amending RFC 7728 signaling. 1525 o Replaced text on ignoring all but the first of multiple 1526 "a=simulcast" lines in a media description with mandating that at 1527 most one "a=simulcast" line is included. 1529 o Clarified with a note that, for the case it is clear from the SDP 1530 that RTP PT uniquely maps to RtpStreamId, an RTP receiver can use 1531 RTP PT to relate simulcast streams. 1533 o Moved Section 4 Requirements to become Appendix A. 1535 o Editorial corrections and clarifications. 1537 B.3. Modifications Between WG Version -07 and -08 1539 o Correcting syntax of SDP examples in section 6.6.1, as found by 1540 Inaki Baz Castillo. 1542 o Changing ABNF to only define the sc-value, not the SDP attribute 1543 itself, as suggested by Paul Kyzivat. 1545 o Changing I-D reference to newly published RFC 8108. 1547 o Adding list of modifications between -06 and -07. 1549 B.4. Modifications Between WG Version -06 and -07 1551 o A scope clarification, as result of the discussion with Roni Even. 1553 o A reformulation of the identification requirements for simulcast 1554 stream. 1556 o Correcting the statement related to source specific signalling 1557 (RFC 5576) to address Roni Even's comment. 1559 o Update of the last paragraph in Section 6.2 regarding simulcast 1560 stream differences as well as forbidding multiple instances of the 1561 same SCID within a single a=simulcast line. 1563 o Removal of note in Section 6.4 as result of issue raised by Roni 1564 Even. 1566 o Use of "m=" has been changed to media description and a few other 1567 editorial improvements and clarifications. 1569 B.5. Modifications Between WG Version -05 and -06 1571 o Added section on RTP Aspects 1573 o Added a requirement (5-4) on that capability exchange must be 1574 capable of handling multi RTP stream cases. 1576 o Added extmap attribute also on first signalling example as it is a 1577 recommended to use mechanism. 1579 o Clarified the definition of the simulcast attribute and how 1580 simulcast streams relates to simulcast formats and SCIDs. 1582 o Updated References list and moved around some references between 1583 informative and normative categories. 1585 o Editorial improvements and corrections. 1587 B.6. Modifications Between WG Version -04 and -05 1589 o Aligned with recent changes in draft-ietf-mmusic-rid and draft- 1590 ietf-avtext-rid. 1592 o Modified the SDP offer/answer section to follow the generally 1593 accepted structure, also adding a brief text on modifying the 1594 session that is aligned with draft-ietf-mmusic-rid. 1596 o Improved text around simulcast stream identification (as opposed 1597 to the simulcast stream itself) to consistently use the acronym 1598 SCID and defined that in the Terminology section. 1600 o Changed references for RTP-level pause/resume and VP8 payload 1601 format that are now published as RFC. 1603 o Improved IANA registration text. 1605 o Removed unused reference to draft-ietf-payload-flexible-fec- 1606 scheme. 1608 o Editorial improvements and corrections. 1610 B.7. Modifications Between WG Version -03 and -04 1612 o Changed to only use RID identification, as was consensus during 1613 IETF 94. 1615 o ABNF improvements. 1617 o Clarified offer-answer rules for initially paused streams. 1619 o Changed references for RTP topologies and RTP taxonomy documents 1620 that are now published as RFC. 1622 o Added reference to the new RID draft in AVTEXT. 1624 o Re-structured section 6 to provide an easy reference by the 1625 updated IANA section. 1627 o Added a sub-section 7.1 with a discussion of bitrate adaptation. 1629 o Editorial improvements. 1631 B.8. Modifications Between WG Version -02 and -03 1633 o Removed text on multicast / broadcast from use cases, since it is 1634 not supported by the solution. 1636 o Removed explicit references to unified plan draft. 1638 o Added possibility to initiate simulcast streams in paused mode. 1640 o Enabled an offerer to offer multiple stream identification (pt or 1641 rid) methods and have the answerer choose which to use. 1643 o Added a preference indication also in send direction offers. 1645 o Added a section on limitations of the current proposal, including 1646 identification method specific limitations. 1648 B.9. Modifications Between WG Version -01 and -02 1650 o Relying on the new RID solution for codec constraints and 1651 configuration identification. This has resulted in changes in 1652 syntax to identify if pt or RID is used to describe the simulcast 1653 stream. 1655 o Renamed simulcast version and simulcast version alternative to 1656 simulcast stream and simulcast format respectively, and improved 1657 definitions for them. 1659 o Clarification that it is possible to switch between simulcast 1660 version alternatives, but that only a single one be used at any 1661 point in time. 1663 o Changed the definition so that ordering of simulcast formats for a 1664 specific simulcast stream do have a preference order. 1666 B.10. Modifications Between WG Version -00 and -01 1668 o No changes. Only preventing expiry. 1670 B.11. Modifications Between Individual Version -00 and WG Version -00 1672 o Added this appendix. 1674 Authors' Addresses 1676 Bo Burman 1677 Ericsson 1678 Gronlandsgatan 31 1679 SE-164 60 Stockholm 1680 Sweden 1682 Email: bo.burman@ericsson.com 1684 Magnus Westerlund 1685 Ericsson 1686 Farogatan 2 1687 SE-164 80 Stockholm 1688 Sweden 1690 Phone: +46 10 714 82 87 1691 Email: magnus.westerlund@ericsson.com 1693 Suhas Nandakumar 1694 Cisco 1695 170 West Tasman Drive 1696 San Jose, CA 95134 1697 USA 1699 Email: snandaku@cisco.com 1701 Mo Zanaty 1702 Cisco 1703 170 West Tasman Drive 1704 San Jose, CA 95134 1705 USA 1707 Email: mzanaty@cisco.com