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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/