--- 1/draft-ietf-mmusic-sdp-simulcast-09.txt 2017-07-20 06:13:17.717416562 -0700 +++ 2/draft-ietf-mmusic-sdp-simulcast-10.txt 2017-07-20 06:13:17.793418367 -0700 @@ -1,21 +1,21 @@ Network Working Group B. Burman Internet-Draft M. Westerlund Intended status: Standards Track Ericsson -Expires: January 4, 2018 S. Nandakumar +Expires: January 21, 2018 S. Nandakumar M. Zanaty Cisco - July 3, 2017 + July 20, 2017 Using Simulcast in SDP and RTP Sessions - draft-ietf-mmusic-sdp-simulcast-09 + draft-ietf-mmusic-sdp-simulcast-10 Abstract In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 4, 2018. + This Internet-Draft will expire on January 21, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,63 +59,64 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 6 3.2. Application Specific Media Source Handling . . . . . . . 7 3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5. Detailed Description . . . . . . . . . . . . . . . . . . . . 9 - 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 9 - 5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 10 - 5.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 12 - 5.3.1. Generating the Initial SDP Offer . . . . . . . . . . 12 - 5.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 12 - 5.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 13 - 5.3.4. Modifying the Session . . . . . . . . . . . . . . . . 14 + 5. Detailed Description . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10 + 5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 + 5.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13 + 5.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13 + 5.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 13 + 5.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 14 + 5.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 5.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 15 - 5.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 15 - 5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 15 - 5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 16 - 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 17 - 6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 6.1. Outgoing from Endpoint with Media Source . . . . . . . . 20 - 6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 20 + 5.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16 + 5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 + 5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17 + 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 + 6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 6.1. Outgoing from Endpoint with Media Source . . . . . . . . 21 + 6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21 6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 22 - 6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 23 - 6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 24 - 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 25 - 7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 25 + 6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24 + 6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25 + 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26 + 7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26 8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 13.2. Informative References . . . . . . . . . . . . . . . . . 28 - Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 31 - Appendix B. Changes From Earlier Versions . . . . . . . . . . . 32 - B.1. Modifications Between WG Version -08 and -09 . . . . . . 32 - B.2. Modifications Between WG Version -07 and -08 . . . . . . 33 - B.3. Modifications Between WG Version -06 and -07 . . . . . . 33 - B.4. Modifications Between WG Version -05 and -06 . . . . . . 33 - B.5. Modifications Between WG Version -04 and -05 . . . . . . 34 - B.6. Modifications Between WG Version -03 and -04 . . . . . . 34 - B.7. Modifications Between WG Version -02 and -03 . . . . . . 35 - B.8. Modifications Between WG Version -01 and -02 . . . . . . 35 - B.9. Modifications Between WG Version -00 and -01 . . . . . . 35 - B.10. Modifications Between Individual Version -00 and WG - Version -00 . . . . . . . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 13.2. Informative References . . . . . . . . . . . . . . . . . 29 + Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 32 + Appendix B. Changes From Earlier Versions . . . . . . . . . . . 33 + B.1. Modifications Between WG Version -09 and -10 . . . . . . 33 + B.2. Modifications Between WG Version -08 and -09 . . . . . . 33 + B.3. Modifications Between WG Version -07 and -08 . . . . . . 34 + B.4. Modifications Between WG Version -06 and -07 . . . . . . 34 + B.5. Modifications Between WG Version -05 and -06 . . . . . . 34 + B.6. Modifications Between WG Version -04 and -05 . . . . . . 35 + B.7. Modifications Between WG Version -03 and -04 . . . . . . 35 + B.8. Modifications Between WG Version -02 and -03 . . . . . . 36 + B.9. Modifications Between WG Version -01 and -02 . . . . . . 36 + B.10. Modifications Between WG Version -00 and -01 . . . . . . 36 + B.11. Modifications Between Individual Version -00 and WG + Version -00 . . . . . . . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction Most of today's multiparty video conference solutions make use of centralized servers to reduce the bandwidth and CPU consumption in the endpoints. Those servers receive RTP streams from each participant and send some suitable set of possibly modified RTP streams to the rest of the participants, which usually have heterogeneous capabilities (screen size, CPU, bandwidth, codec, etc). One of the biggest issues is how to perform RTP stream adaptation to @@ -180,27 +180,20 @@ Simulcast Format: Different formats of a simulcast stream serve the same purpose as alternative RTP payload types in non-simulcast SDP: to allow multiple alternative media formats for a given RTP stream. As for multiple RTP payload types on the m-line in offer/ answer [RFC3264], any one of the negotiated alternative formats can be used in a single RTP stream at a given point in time, but not more than one (based on RTP timestamp). What format is used can change dynamically from one RTP packet to another. - Simulcast Stream Identifier (SCID): The identification value used to - refer to an individual simulcast format, identical to the "rid-id" - identification value for an RTP Payload Format Restriction - - [I-D.ietf-mmusic-rid] and the corresponding content of - "RtpStreamId" RTCP SDES Item [I-D.ietf-avtext-rid]. - 2.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Use Cases The use cases of simulcast described in this document relate to a multi-party communication session where one or more central nodes are @@ -309,62 +302,117 @@ of the aspects listed in Section 3.1. Sending a simulcast of RTP streams is one way of accommodating receivers with conflicting or otherwise incompatible preferences. 4. Overview This memo defines SDP [RFC4566] signaling that covers the above described simulcast use cases and functionalities. A number of requirements for such signaling are elaborated in Appendix A. - A new SDP media level attribute "a=simulcast" is defined: + A new SDP media level attribute "a=simulcast" is defined. The + attribute describes, independently for send and receive directions, + the number of simulcast RTP streams as well as potential alternative + formats for each simulcast RTP stream. Each simulcast RTP stream, + including alternatives, is identified using the RID identifier (rid- + id), defined in [I-D.ietf-mmusic-rid]. - m=video 49300 RTP/AVP 97 98 + a=simulcast:send 1;2,3 recv 4 + + If the above line is included in an SDP offer, the "send" part + indicates the offerer's capability and proposal to send two simulcast + RTP streams. Each simulcast RTP stream identifier (rid-id) is + separated by a semicolon (";"). When rid-ids are separated by a + comma (","), they describe alternative representations for that + particular simulcast RTP stream. Thus, the above "send" part is + interpreted as an intention to send two simulcast RTP streams. The + first simulcast RTP stream is identified and restricted according to + rid-id 1. The second simulcast RTP stream can be sent as two + alternatives, identified and restricted according to rid-ids 2 and 3. + The "recv" part of the above line indicates that the offerer desires + to receive a single RTP stream (no simulcast) according to rid-id 4. + + The RID mechanism, as defined in [I-D.ietf-mmusic-rid], enables an + SDP offerer or answerer to specify a number of different RTP stream + restrictions for a rid-id by using the "a=rid" line. Examples of + such restrictions are maximum bitrate, maximum spatial video + resolution (width and height), maximum video framerate, etc. Each + rid-id may also be restricted to use only a subset of the RTP payload + types in the associated SDP media description. Those RTP payload + types can have their own configurations and parameters affecting what + can be sent or received, using the "a=fmtp" line as well as other SDP + attributes. + + A more complete example SDP offer media description is provided + below: + + m=video 49300 RTP/AVP 97 98 99 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 + a=rtpmap:99 VP8/90000 a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 + a=fmtp:99 max-fs=240;max-fr=30 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] + a=imageattr:99 send [x=320,y=180] recv [x=320,y=180] a=rid:1 send pt=97 a=rid:2 send pt=98 - a=rid:3 recv pt=97 - a=simulcast:send 1;2 recv 3 + a=rid:3 send pt=99 + a=rid:4 recv pt=97 + a=simulcast:send 1;2,3 recv 4 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Figure 1: Example Simulcast Media Description in Offer - The corresponding SDP answer media description example extract could - look like: + The above SDP media description can be interpreted on a high level to + say that the offerer is capable of sending two simulcast RTP streams, + one H.264 encoded stream in up to 720p resolution, and one additional + stream encoded as either H.264 or VP8 with a maximum resolution of + 320x180 pixels. The offerer can receive one H.264 stream with + maximum 720p resolution. + + The receiver of this SDP offer can generate an SDP answer that + indicates what it accepts. It uses the "a=simulcast" attribute to + indicate simulcast capability and specify what simulcast RTP streams + and alternatives to receive and/or send. An example of such + answering "a=simulcast" attribute, corresponding to the above offer, + is: + + a=simulcast:recv 1;2 send 4 + + With this SDP answer, the answerer indicates in the "recv" part that + it wants to receive the two simulcast RTP streams. It has removed an + alternative that it doesn't support (rid-id 3). The send part + confirms to the offerer that it will receive one stream for this + media source according to rid-id 4. The corresponding, more complete + example SDP answer media description could look like: m=video 49674 RTP/AVP 97 98 a=rtpmap:97 H264/90000 a=rtpmap:98 H264/90000 a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:1 recv pt=97 a=rid:2 recv pt=98 - a=rid:3 send pt=97 - a=simulcast:recv 1;2 send 3 + a=rid:4 send pt=97 + a=simulcast:recv 1;2 send 4 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId Figure 2: Example Simulcast Media Description in Answer - The above are only SDP media description extracts, not a complete - SDP. The only difference to non-simulcast SDP media descriptions is - the added "a=simulcast" line. It is assumed that a single SDP media - description is used to describe a single media source. This is - aligned with the concepts defined in [RFC7656] and will work in a - WebRTC context, both with and without BUNDLE - [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping of media + It is assumed that a single SDP media description is used to describe + a single media source. This is aligned with the concepts defined in + [RFC7656] and will work in a WebRTC context, both with and without + BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping of media descriptions. The "a=simulcast" line describes send and receive direction simulcast streams separately. Each direction can in turn describe one or more simulcast streams, separated by semicolon. The identifiers describing simulcast streams on the "a=simulcast" line are rid-id, as defined by "a=rid" lines in [I-D.ietf-mmusic-rid]. Each simulcast stream can be offered as a list of alternative rid-id, with each alternative separated by comma (not in the examples above). A detailed specification can be found in Section 5 and more detailed @@ -388,20 +436,24 @@ sc-recv = "recv" SP sc-str-list sc-str-list = sc-alt-list *( ";" sc-alt-list ) sc-alt-list = sc-id *( "," sc-id ) sc-id-paused = "~" sc-id = [sc-id-paused] rid-id ; SP defined in [RFC5234] ; rid-id defined in [I-D.ietf-mmusic-rid] Figure 3: ABNF for Simulcast Value + Note to RFC Editor: Replace "I-D.ietf-mmusic-rid" in the above + figure with RFC number of draft-ietf-mmusic-rid before publication + of this document. + The "a=simulcast" attribute has a parameter in the form of one or two simulcast stream descriptions, each consisting of a direction ("send" or "recv"), followed by a list of one or more simulcast streams. Each simulcast stream consists of one or more alternative simulcast formats. Each simulcast format is identified by a simulcast stream identifier (rid-id). The rid-id MUST have the form of an RTP stream identifier, as described by RTP Payload Format Restrictions [I-D.ietf-mmusic-rid]. In the list of simulcast streams, each simulcast stream is separated @@ -627,21 +679,21 @@ Offers inside an existing session follow the same rules as for initial SDP offer, with these additions: 1. rid-id marked as initially paused in the offerer's send direction SHALL reflect the offerer's opinion of the current pause state at the time of creating the offer. This is purely informational, and RTP stream pause/resume [RFC7728] signaling in the ongoing session SHALL take precedence in case of any conflict or ambiguity. - 2. rid-id marked as initally paused in the offerer's receive + 2. rid-id marked as initially paused in the offerer's receive direction SHALL (as in an initial offer) reflect the offerer's desired rid-id pause state. Except for the case where the offerer already paused the corresponding RTP stream through RTP stream pause/resume [RFC7728] signaling , this is identical to the conditions at an initial offer. Creation of SDP answers and processing of SDP answers inside an existing session follow the same rules as described above for initial SDP offer/answer. @@ -1231,22 +1283,22 @@ 13.1. Normative References [I-D.ietf-avtext-rid] Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Identifier Source Description (SDES)", draft-ietf-avtext- rid-09 (work in progress), October 2016. [I-D.ietf-mmusic-rid] Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., Roach, A., and B. Campen, "RTP Payload Format - Restrictions", draft-ietf-mmusic-rid-10 (work in - progress), March 2017. + Restrictions", draft-ietf-mmusic-rid-11 (work in + progress), July 2017. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-38 (work in progress), April 2017. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 @@ -1443,21 +1495,29 @@ REQ-6.1: Interworking with non-simulcast legacy clients using a single media source per media type. REQ-6.2: WebRTC environment with a single media source per SDP media description. Appendix B. Changes From Earlier Versions NOTE TO RFC EDITOR: Please remove this section prior to publication. -B.1. Modifications Between WG Version -08 and -09 +B.1. Modifications Between WG Version -09 and -10 + + o Amended overview section with a bit more explanation on the + examples, and added an rid-id alternative for one of the streams. + + o Removed SCID also from the Terminology section, which was + forgotten in -09 when changing SCID to rid-id. + +B.2. Modifications Between WG Version -08 and -09 o Changed SCID to rid-id, to align with ietf-draft-mmusic-rid naming. o Changed Overview to be based on examples and shortened it. o Changed semantics of initially paused rid-id in modified SDP offers from requiring it to follow actual RFC 7728 pause state to an informational offerer's opinion at the time of offer creation, not in any way overriding or amending RFC 7728 signaling. @@ -1467,71 +1527,71 @@ most one "a=simulcast" line is included. o Clarified with a note that, for the case it is clear from the SDP that RTP PT uniquely maps to RtpStreamId, an RTP receiver can use RTP PT to relate simulcast streams. o Moved Section 4 Requirements to become Appendix A. o Editorial corrections and clarifications. -B.2. Modifications Between WG Version -07 and -08 +B.3. Modifications Between WG Version -07 and -08 o Correcting syntax of SDP examples in section 6.6.1, as found by Inaki Baz Castillo. o Changing ABNF to only define the sc-value, not the SDP attribute itself, as suggested by Paul Kyzivat. o Changing I-D reference to newly published RFC 8108. o Adding list of modifications between -06 and -07. -B.3. Modifications Between WG Version -06 and -07 +B.4. Modifications Between WG Version -06 and -07 o A scope clarification, as result of the discussion with Roni Even. o A reformulation of the identification requirements for simulcast stream. o Correcting the statement related to source specific signalling (RFC 5576) to address Roni Even's comment. o Update of the last paragraph in Section 6.2 regarding simulcast stream differences as well as forbidding multiple instances of the same SCID within a single a=simulcast line. o Removal of note in Section 6.4 as result of issue raised by Roni Even. o Use of "m=" has been changed to media description and a few other editorial improvements and clarifications. -B.4. Modifications Between WG Version -05 and -06 +B.5. Modifications Between WG Version -05 and -06 o Added section on RTP Aspects o Added a requirement (5-4) on that capability exchange must be capable of handling multi RTP stream cases. o Added extmap attribute also on first signalling example as it is a recommended to use mechanism. o Clarified the definition of the simulcast attribute and how simulcast streams relates to simulcast formats and SCIDs. o Updated References list and moved around some references between informative and normative categories. o Editorial improvements and corrections. -B.5. Modifications Between WG Version -04 and -05 +B.6. Modifications Between WG Version -04 and -05 o Aligned with recent changes in draft-ietf-mmusic-rid and draft- ietf-avtext-rid. o Modified the SDP offer/answer section to follow the generally accepted structure, also adding a brief text on modifying the session that is aligned with draft-ietf-mmusic-rid. o Improved text around simulcast stream identification (as opposed to the simulcast stream itself) to consistently use the acronym @@ -1540,85 +1600,86 @@ o Changed references for RTP-level pause/resume and VP8 payload format that are now published as RFC. o Improved IANA registration text. o Removed unused reference to draft-ietf-payload-flexible-fec- scheme. o Editorial improvements and corrections. -B.6. Modifications Between WG Version -03 and -04 +B.7. Modifications Between WG Version -03 and -04 o Changed to only use RID identification, as was consensus during IETF 94. o ABNF improvements. o Clarified offer-answer rules for initially paused streams. o Changed references for RTP topologies and RTP taxonomy documents that are now published as RFC. o Added reference to the new RID draft in AVTEXT. o Re-structured section 6 to provide an easy reference by the updated IANA section. o Added a sub-section 7.1 with a discussion of bitrate adaptation. o Editorial improvements. -B.7. Modifications Between WG Version -02 and -03 +B.8. Modifications Between WG Version -02 and -03 o Removed text on multicast / broadcast from use cases, since it is not supported by the solution. o Removed explicit references to unified plan draft. o Added possibility to initiate simulcast streams in paused mode. o Enabled an offerer to offer multiple stream identification (pt or rid) methods and have the answerer choose which to use. o Added a preference indication also in send direction offers. o Added a section on limitations of the current proposal, including identification method specific limitations. -B.8. Modifications Between WG Version -01 and -02 +B.9. Modifications Between WG Version -01 and -02 o Relying on the new RID solution for codec constraints and configuration identification. This has resulted in changes in syntax to identify if pt or RID is used to describe the simulcast stream. o Renamed simulcast version and simulcast version alternative to simulcast stream and simulcast format respectively, and improved definitions for them. o Clarification that it is possible to switch between simulcast version alternatives, but that only a single one be used at any point in time. o Changed the definition so that ordering of simulcast formats for a specific simulcast stream do have a preference order. -B.9. Modifications Between WG Version -00 and -01 +B.10. Modifications Between WG Version -00 and -01 o No changes. Only preventing expiry. -B.10. Modifications Between Individual Version -00 and WG Version -00 +B.11. Modifications Between Individual Version -00 and WG Version -00 o Added this appendix. Authors' Addresses + Bo Burman Ericsson Gronlandsgatan 31 SE-164 60 Stockholm Sweden Email: bo.burman@ericsson.com Magnus Westerlund Ericsson