draft-ietf-mmusic-sdp-simulcast-11.txt   draft-ietf-mmusic-sdp-simulcast-12.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: June 23, 2018 S. Nandakumar Expires: October 12, 2018 S. Nandakumar
M. Zanaty M. Zanaty
Cisco Cisco
December 20, 2017 April 10, 2018
Using Simulcast in SDP and RTP Sessions Using Simulcast in SDP and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-11 draft-ietf-mmusic-sdp-simulcast-12
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 23, 2018. This Internet-Draft will expire on October 12, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . . 9
5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10
5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 10 5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11
5.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13 5.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13 5.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13
5.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 13 5.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 13
5.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 14 5.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 14
5.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . 15
5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16
5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 16 5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 16
5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18
5.6.3. Simulcast and Redundancy . . . . . . . . . . . . . . 20 5.6.3. Simulcast and Redundancy . . . . . . . . . . . . . . 20
6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Outgoing from Endpoint with Media Source . . . . . . . . 23 6.1. Outgoing from Endpoint with Media Source . . . . . . . . 23
6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 23 6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 23
6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 24 6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 24
6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 26 6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 26
6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 27 6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 27
7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 28 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 28 7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 28
8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 31 13.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 34 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Changes From Earlier Versions . . . . . . . . . . . 35 Appendix B. Changes From Earlier Versions . . . . . . . . . . . 35
B.1. Modifications Between WG Version -10 and -11 . . . . . . 35 B.1. Modifications Between WG Version -11 and -12 . . . . . . 35
B.2. Modifications Between WG Version -09 and -10 . . . . . . 36 B.2. Modifications Between WG Version -10 and -11 . . . . . . 36
B.3. Modifications Between WG Version -08 and -09 . . . . . . 36 B.3. Modifications Between WG Version -09 and -10 . . . . . . 36
B.4. Modifications Between WG Version -07 and -08 . . . . . . 36 B.4. Modifications Between WG Version -08 and -09 . . . . . . 36
B.5. Modifications Between WG Version -06 and -07 . . . . . . 37 B.5. Modifications Between WG Version -07 and -08 . . . . . . 37
B.6. Modifications Between WG Version -05 and -06 . . . . . . 37 B.6. Modifications Between WG Version -06 and -07 . . . . . . 37
B.7. Modifications Between WG Version -04 and -05 . . . . . . 37 B.7. Modifications Between WG Version -05 and -06 . . . . . . 37
B.8. Modifications Between WG Version -03 and -04 . . . . . . 38 B.8. Modifications Between WG Version -04 and -05 . . . . . . 38
B.9. Modifications Between WG Version -02 and -03 . . . . . . 38 B.9. Modifications Between WG Version -03 and -04 . . . . . . 38
B.10. Modifications Between WG Version -01 and -02 . . . . . . 39 B.10. Modifications Between WG Version -02 and -03 . . . . . . 39
B.11. Modifications Between WG Version -00 and -01 . . . . . . 39 B.11. Modifications Between WG Version -01 and -02 . . . . . . 39
B.12. Modifications Between Individual Version -00 and WG B.12. Modifications Between WG Version -00 and -01 . . . . . . 39
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 39 B.13. Modifications Between Individual Version -00 and WG
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Version -00 . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 10 skipping to change at page 4, line 11
The intended scope of the defined mechanism is to support negotiation The intended scope of the defined mechanism is to support negotiation
and usage of simulcast when using SDP offer/answer and media and usage of simulcast when using SDP offer/answer and media
transport over RTP. The media transport topologies considered are transport over RTP. The media transport topologies considered are
point to point RTP sessions as well as centralized multi-party RTP point to point RTP sessions as well as centralized multi-party RTP
sessions, where a media sender will provide the simulcasted streams sessions, where a media sender will provide the simulcasted streams
to an RTP middlebox or endpoint, and middleboxes may further to an RTP middlebox or endpoint, and middleboxes may further
distribute the simulcast streams to other middleboxes or endpoints. distribute the simulcast streams to other middleboxes or endpoints.
Usage of multicast or broadcast transport is out of scope and left Usage of multicast or broadcast transport is out of scope and left
for future extension. for future extension.
This document describes a few scenarios where it is motivated to use This document describes a few scenarios that motivates the use of
simulcast, and also defines the needed RTP/RTCP and SDP signaling for simulcast, and also defines the needed RTP/RTCP and SDP signaling for
it. it.
2. Definitions 2. Definitions
2.1. Terminology 2.1. Terminology
This document makes use of the terminology defined in RTP Taxonomy This document makes use of the terminology defined in RTP Taxonomy
[RFC7656], and RTP Topologies [RFC7667]. The following terms are [RFC7656], and RTP Topologies [RFC7667]. The following terms are
especially noted or here defined: especially noted or here defined:
skipping to change at page 5, line 8 skipping to change at page 5, line 8
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.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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
used to adapt the view of the communication session towards used to adapt the view of the communication session towards
individual participants, and facilitate the media transport between individual participants, and facilitate the media transport between
participants. Thus, these cases target the RTP Mixer type of participants. Thus, these cases target the RTP Mixer type of
topology. topology.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
important to reduce the load on the RTP Mixer and/or minimize QoE important to reduce the load on the RTP Mixer and/or minimize QoE
impact than to achieve an optimal adaptation of resource usage. impact than to achieve an optimal adaptation of resource usage.
3.1. Reaching a Diverse Set of Receivers 3.1. Reaching a Diverse Set of Receivers
The media sources provided by a sending participant potentially need The media sources provided by a sending participant potentially need
to reach several receiving participants that differ in terms of to reach several receiving participants that differ in terms of
available resources. The receiver resources that typically differ available resources. The receiver resources that typically differ
include, but are not limited to: include, but are not limited to:
Codec: This includes codec type (such as SDP MIME type) and can Codec: This includes codec type (such as RTP payload format MIME
include codec configuration. A couple of codec resources that type) and can include codec configuration. A couple of codec
differ only in codec configuration will be "different" if they are resources that differ only in codec configuration will be
somehow not "compatible", like if they differ in video codec "different" if they are somehow not "compatible", like if they
profile, or the transport packetization configuration. differ in video codec profile, or the transport packetization
configuration.
Sampling: This relates to how the media source is sampled, in Sampling: This relates to how the media source is sampled, in
spatial as well as in temporal domain. For video streams, spatial spatial as well as in temporal domain. For video streams, spatial
sampling affects image resolution and temporal sampling affects sampling affects image resolution and temporal sampling affects
video frame rate. For audio, spatial sampling relates to the video frame rate. For audio, spatial sampling relates to the
number of audio channels and temporal sampling affects audio number of audio channels and temporal sampling affects audio
bandwidth. This may be used to suit different rendering bandwidth. This may be used to suit different rendering
capabilities or needs at the receiving endpoints. capabilities or needs at the receiving endpoints.
Bitrate: This relates to the amount of bits sent per second to Bitrate: This relates to the number of bits sent per second to
transmit the media source as an RTP stream, which typically also transmit the media source as an RTP stream, which typically also
affects the Quality of Experience (QoE) for the receiving user. affects the Quality of Experience (QoE) for the receiving user.
Letting the sending participant create a simulcast of a few Letting the sending participant create a simulcast of a few
differently configured RTP streams per media source can be a good differently configured RTP streams per media source can be a good
tradeoff when using an RTP switch as middlebox, instead of sending a tradeoff when using an RTP switch as middlebox, instead of sending a
single RTP stream and using an RTP mixer to create individual single RTP stream and using an RTP mixer to create individual
transcodings to each receiving participant. transcodings to each receiving participant.
This requires that the receiving participants can be categorized in This requires that the receiving participants can be categorized in
skipping to change at page 7, line 26 skipping to change at page 7, line 26
media that instead has to receive special handling towards the active media that instead has to receive special handling towards the active
speaker; typically the previous active speaker. This way, the speaker; typically the previous active speaker. This way, the
previously active speaker is needed both in larger size (to current previously active speaker is needed both in larger size (to current
active speaker) and in small size (to the rest of the participants), active speaker) and in small size (to the rest of the participants),
which can be solved with a simulcast from the previously active which can be solved with a simulcast from the previously active
speaker to the RTP switch. speaker to the RTP switch.
3.3. Receiver Media Source Preferences 3.3. Receiver Media Source Preferences
The application logic that controls the communication session may The application logic that controls the communication session may
allow receiving participants to apply preferences to the allow receiving participants to state preferences on the
characteristics of the RTP stream they receive, for example in terms characteristics of the RTP stream they like to receive, for example
of the aspects listed in Section 3.1. Sending a simulcast of RTP in terms of the aspects listed in Section 3.1. Sending a simulcast
streams is one way of accommodating receivers with conflicting or of RTP streams is one way of accommodating receivers with conflicting
otherwise incompatible preferences. or 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.
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 new SDP media level attribute "a=simulcast" is defined. The A new SDP media level attribute "a=simulcast" is defined. The
attribute describes, independently for send and receive directions, attribute describes, independently for send and receive directions,
the number of simulcast RTP streams as well as potential alternative the number of simulcast RTP streams as well as potential alternative
formats for each simulcast RTP stream. Each simulcast RTP stream, formats for each simulcast RTP stream. Each simulcast RTP stream,
including alternatives, is identified using the RID identifier (rid- including alternatives, is identified using the RID identifier (rid-
id), defined in [I-D.ietf-mmusic-rid]. id), defined in [I-D.ietf-mmusic-rid].
a=simulcast:send 1;2,3 recv 4 a=simulcast:send 1;2,3 recv 4
If the above line is included in an SDP offer, the "send" part If the above line is included in an SDP offer, the "send" part
indicates the offerer's capability and proposal to send two simulcast indicates the offerer's capability and proposal to send two simulcast
RTP streams. Each simulcast RTP stream identifier (rid-id) is RTP streams. Each simulcast stream is described by one or more RTP
separated by a semicolon (";"). When rid-ids are separated by a stream identifiers (rid-id), each group of rid-ids for a simulcast
comma (","), they describe alternative representations for that stream is separated by a semicolon (";"). When a simulcast stream
particular simulcast RTP stream. Thus, the above "send" part is has multiple rid-ids that are separated by a comma (","), they
interpreted as an intention to send two simulcast RTP streams. The describe alternative representations for that particular simulcast
first simulcast RTP stream is identified and restricted according to RTP stream. Thus, the above "send" part is interpreted as an
rid-id 1. The second simulcast RTP stream can be sent as two intention to send two simulcast RTP streams. The first simulcast RTP
alternatives, identified and restricted according to rid-ids 2 and 3. stream is identified and restricted according to rid-id 1. The
The "recv" part of the above line indicates that the offerer desires second simulcast RTP stream can be sent as two alternatives,
to receive a single RTP stream (no simulcast) according to rid-id 4. identified and restricted according to rid-ids 2 and 3. The "recv"
part of the above line indicates that the offerer desires to receive
The RID mechanism, as defined in [I-D.ietf-mmusic-rid], enables an a single RTP stream (no simulcast) according to rid-id 4.
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 A more complete example SDP offer media description is provided
below: below:
m=video 49300 RTP/AVP 97 98 99 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=rtpmap:99 VP8/90000 a=rtpmap:99 VP8/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=fmtp:99 max-fs=240; max-fr=30 a=fmtp:99 max-fs=240; max-fr=30
a=rid:1 send pt=97 max-width=1280;max-height=720 a=rid:1 send pt=97 max-width=1280;max-height=720
a=rid:2 send pt=98 max-width=320;max-height=180 a=rid:2 send pt=98 max-width=320;max-height=180
a=rid:3 send pt=99 max-width=320;max-height=180 a=rid:3 send pt=99 max-width=320;max-height=180
a=rid:4 recv pt=97 a=rid:4 recv pt=97
a=simulcast:send 1;2,3 recv 4 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 above SDP media description can be interpreted on a high level to The above SDP media description can be interpreted at a high level to
say that the offerer is capable of sending two simulcast RTP streams, 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 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 stream encoded as either H.264 or VP8 with a maximum resolution of
320x180 pixels. The offerer can receive one H.264 stream with 320x180 pixels. The offerer can receive one H.264 stream with
maximum 720p resolution. maximum 720p resolution.
The receiver of this SDP offer can generate an SDP answer that The receiver of this SDP offer can generate an SDP answer that
indicates what it accepts. It uses the "a=simulcast" attribute to indicates what it accepts. It uses the "a=simulcast" attribute to
indicate simulcast capability and specify what simulcast RTP streams indicate simulcast capability and specify what simulcast RTP streams
and alternatives to receive and/or send. An example of such and alternatives to receive and/or send. An example of such
skipping to change at page 9, line 35 skipping to change at page 9, line 37
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
It is assumed that a single SDP media description is used to describe 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 a single media source. This is aligned with the concepts defined in
[RFC7656] and will work in a WebRTC context, both with and without [RFC7656] and will work in a WebRTC context, both with and without
BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping of media BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping of media
descriptions. descriptions.
The "a=simulcast" line describes send and receive direction simulcast To summarize, the "a=simulcast" line describes send and receive
streams separately. Each direction can in turn describe one or more direction simulcast streams separately. Each direction can in turn
simulcast streams, separated by semicolon. The identifiers describe one or more simulcast streams, separated by semicolon. The
describing simulcast streams on the "a=simulcast" line are rid-id, as identifiers describing simulcast streams on the "a=simulcast" line
defined by "a=rid" lines in [I-D.ietf-mmusic-rid]. Each simulcast are rid-id, as defined by "a=rid" lines in [I-D.ietf-mmusic-rid].
stream can be offered as a list of alternative rid-id, with each Each simulcast stream can be offered as a list of alternative rid-id,
alternative separated by comma (not in the examples above). A with each alternative separated by comma (not in the examples above).
detailed specification can be found in Section 5 and more detailed A detailed specification can be found in Section 5 and more detailed
examples are outlined in Section 5.6. examples are outlined in Section 5.6.
5. Detailed Description 5. Detailed Description
This section further details the overview above (Section 4). First, This section further details the overview above (Section 4). First,
formal syntax is provided (Section 5.1), followed by the rest of the formal syntax is provided (Section 5.1), followed by the rest of the
SDP attribute definition in Section 5.2. Relating Simulcast Streams SDP attribute definition in Section 5.2. Relating Simulcast Streams
(Section 5.5) provides the definition of the RTP/RTCP mechanisms (Section 5.5) provides the definition of the RTP/RTCP mechanisms
used. The section is concluded with a number of examples. used. The section is concluded with a number of examples.
skipping to change at page 10, line 51 skipping to change at page 11, line 8
pause capability can be specified individually for each RTP payload pause capability can be specified individually for each RTP payload
type referenced by an rid-id. Since pause capability specified via type referenced by an rid-id. Since pause capability specified via
the "a=rtcp-fb" attribute and rid-id specified by "a=rid" can refer the "a=rtcp-fb" attribute and rid-id specified by "a=rid" can refer
to common payload types, it is unfeasible to pause streams with rid- to common payload types, it is unfeasible to pause streams with rid-
id where any of the related RTP payload type(s) do not have pause id where any of the related RTP payload type(s) do not have pause
capability. capability.
5.2. Simulcast Capability 5.2. Simulcast Capability
Simulcast capability is expressed through a new media level SDP Simulcast capability is expressed through a new media level SDP
attribute, "a=simulcast" (Section 5.1). The meaning of the attribute attribute, "a=simulcast" (Section 5.1). The use of this attribute at
on SDP session level is undefined, MUST NOT be used by the session level is undefined. Implementations of this
implementations of this specification and MUST be ignored if received specification MUST NOT use it at the session level and MUST ignore it
on session level. Extensions to this specification MAY define such if received at the session level. Extensions to this specification
session level usage. Each SDP media description MUST contain at most may define such session level usage. Each SDP media description MUST
one "a=simulcast" line. contain at most one "a=simulcast" line.
There are separate and independent sets of simulcast streams in send There are separate and independent sets of simulcast streams in send
and receive directions. When listing multiple directions, each and receive directions. When listing multiple directions, each
direction MUST NOT occur more than once on the same line. direction MUST NOT occur more than once on the same line.
Simulcast streams using undefined rid-id MUST NOT be used as valid Simulcast streams using undefined rid-id MUST NOT be used as valid
simulcast streams by an RTP stream receiver. The direction for an simulcast streams by an RTP stream receiver. The direction for an
rid-id MUST be aligned with the direction specified for the rid-id MUST be aligned with the direction specified for the
corresponding RTP stream identifier on the "a=rid" line. corresponding RTP stream identifier on the "a=rid" line.
skipping to change at page 11, line 36 skipping to change at page 11, line 42
importance if the number of actually sent simulcast streams have to importance if the number of actually sent simulcast streams have to
be reduced for some reason. be reduced for some reason.
rid-id that have explicit dependencies [RFC5583] rid-id that have explicit dependencies [RFC5583]
[I-D.ietf-mmusic-rid] to other rid-id (even in the same media [I-D.ietf-mmusic-rid] to other rid-id (even in the same media
description) MAY be used. description) MAY be used.
Use of more than a single, alternative simulcast format for a Use of more than a single, alternative simulcast format for a
simulcast stream MAY be specified as part of the attribute parameters simulcast stream MAY be specified as part of the attribute parameters
by expressing the simulcast stream as a comma-separated list of by expressing the simulcast stream as a comma-separated list of
alternative rid-id. In this case, it is not possible to align what alternative rid-id. The order of the rid-id alternatives within a
alternative rid-id that are used across different simulcast streams, simulcast stream is significant; the rid-id alternatives are listed
like requiring all simulcast streams to use rid-id alternatives from (left) most preferred to (right) least preferred. For the use
referring to the same codec format. The order of the rid-id of simulcast, this overrides the normal codec preference as expressed
alternatives within a simulcast stream is significant; the rid-id by format type ordering on the "m=" line, using regular SDP rules.
alternatives are listed from (left) most preferred to (right) least This is to enable a separation of general codec preferences and
preferred. For the use of simulcast, this overrides the normal codec simulcast stream configuration preferences. However, the choice of
preference as expressed by format type ordering on the "m=" line, which alternative to use per simulcast stream is independent, and
using regular SDP rules. This is to enable a separation of general there is currently no mechanism for align the choice between
codec preferences and simulcast stream configuration preferences. alternative rid-ids between different simulcast streams.
A simulcast stream can use a codec defined such that the same RTP A simulcast stream can use a codec defined such that the same RTP
SSRC can change RTP payload type multiple times during a session, SSRC can change RTP payload type multiple times during a session,
possibly even on a per-packet basis. A typical example can be a possibly even on a per-packet basis. A typical example can be a
speech codec that makes use of Comfort Noise [RFC3389] and/or DTMF speech codec that makes use of Comfort Noise [RFC3389] and/or DTMF
[RFC4733] formats. [RFC4733] formats.
If RTP stream pause/resume [RFC7728] is supported, any rid-id MAY be If RTP stream pause/resume [RFC7728] is supported, any rid-id MAY be
prefixed by a "~" character to indicate that the corresponding prefixed by a "~" character to indicate that the corresponding
simulcast stream is initially paused already from start of the RTP simulcast stream is initially paused already from start of the RTP
session. In this case, support for RTP stream pause/resume MUST also session. In this case, support for RTP stream pause/resume MUST also
be included under the same "m=" line where "a=simulcast" is included. be included under the same "m=" line where "a=simulcast" is included.
All RTP payload types related to such initially paused simulcast All RTP payload types related to such initially paused simulcast
stream MUST be listed in the SDP as pause/resume capable as specified stream MUST be listed in the SDP as pause/resume capable as specified
by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb". by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb".
An initially paused simulcast stream in "send" direction for the part An initially paused simulcast stream in "send" direction for the
sending the SDP MUST be considered equivalent to an unsolicited endpoint sending the SDP MUST be considered equivalent to an
locally paused stream, and be handled accordingly. Initially paused unsolicited locally paused stream, and be handled accordingly.
simulcast streams are resumed as described by the RTP pause/resume Initially paused simulcast streams are resumed as described by the
specification. An RTP stream receiver that wishes to resume an RTP pause/resume specification. An RTP stream receiver that wishes
unsolicited locally paused stream needs to know the SSRC of that to resume an unsolicited locally paused stream needs to know the SSRC
stream. The SSRC of an initially paused simulcast stream can be of that stream. The SSRC of an initially paused simulcast stream can
obtained from an RTP stream sender RTCP Sender Report (SR) including be obtained from an RTP stream sender RTCP Sender Report (SR)
both the desired SSRC as "SSRC of sender", and the rid-id value in an including both the desired SSRC as "SSRC of sender", and the rid-id
RtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. value in an RtpStreamId RTCP SDES item [I-D.ietf-avtext-rid].
Including an initially paused simulcast stream in "recv" direction If the endpoint sending the SDP includes an "recv" direction
for the part sending the SDP, sent towards an RTP sender, SHOULD simulcast stream that is initially paused, then the remote RTP sender
cause the remote RTP sender to put the stream as unsolicited locally receiving the SDP SHOULD put its RTP stream in a unsolicited locally
paused, unless there are other RTP stream receivers that do not mark paused state. However, this does not apply if there are other RTP
the simulcast stream as initially paused. The reason to require an stream receivers that do not mark the simulcast stream as initially
initially paused "recv" stream to be considered locally paused by the paused. The reason to require an initially paused "recv" stream to
remote RTP sender, instead of making it equivalent to implicitly be considered locally paused by the remote RTP sender, instead of
sending a pause request, is because the pausing RTP sender cannot making it equivalent to implicitly sending a pause request, is
know which receiving SSRC owns the restriction when TMMBR/TMMBN are because the pausing RTP sender cannot know which receiving SSRC owns
used for pause/resume signaling (Section 5.6 of [RFC7728]) since the the restriction when Temporary Maximum Media Stream Bit Rate Request
RTP receiver's SSRC in send direction is sometimes not yet known. (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification
(TMMBN) are used for pause/resume signaling (Section 5.6 of
[RFC7728]) since the RTP receiver's SSRC in send direction is
sometimes not yet known.
Use of the redundant audio data [RFC2198] format could be seen as a Use of the redundant audio data [RFC2198] format could be seen as a
form of simulcast for loss protection purposes, but is not considered form of simulcast for loss protection purposes, but is not considered
conflicting with the mechanisms described in this memo and MAY conflicting with the mechanisms described in this memo and MAY
therefore be used as any other format. In this case the "red" therefore be used as any other format. In this case the "red"
format, rather than the carried formats, SHOULD be the one to list as format, rather than the carried formats, SHOULD be the one to list as
a simulcast stream on the "a=simulcast" line. a simulcast stream on the "a=simulcast" line.
The media formats and corresponding characteristics of simulcast The media formats and corresponding characteristics of simulcast
streams SHOULD be chosen such that they are different, e.g. as streams SHOULD be chosen such that they are different, e.g. as
different SDP formats with differing "a=rtpmap" and/or "a=fmtp" different SDP formats with differing "a=rtpmap" and/or "a=fmtp"
lines, or as differently defined RTP payload format restrictions. If lines, or as differently defined RTP payload format restrictions. If
this difference is not required, RTP duplication [RFC7104] procedures this difference is not required, it is RECOMMENDED to use RTP
SHOULD be considered instead of simulcast. To avoid complications in duplication [RFC7104] procedures instead of simulcast. To avoid
implementations, a single rid-id MUST NOT occur more than once per complications in implementations, a single rid-id MUST NOT occur more
"a=simulcast" line. Note that this does not eliminate use of than once per "a=simulcast" line. Note that this does not eliminate
simulcast as an RTP duplication mechanism, since it is possible to use of simulcast as an RTP duplication mechanism, since it is
define multiple different rid-id that are effectively equivalent. possible to define multiple different rid-id that are effectively
equivalent.
5.3. Offer/Answer Use 5.3. Offer/Answer Use
Note: The inclusion of "a=simulcast" or the use of simulcast does Note: The inclusion of "a=simulcast" or the use of simulcast does
not change any of the interpretation or Offer/Answer procedures not change any of the interpretation or Offer/Answer procedures
for other SDP attributes, like "a=fmtp" or "a=rid". for other SDP attributes, like "a=fmtp" or "a=rid".
5.3.1. Generating the Initial SDP Offer 5.3.1. Generating the Initial SDP Offer
An offerer wanting to use simulcast for a media description SHALL An offerer wanting to use simulcast for a media description SHALL
skipping to change at page 13, line 46 skipping to change at page 14, line 7
directionality of the unidirectional direction parameters; "send" directionality of the unidirectional direction parameters; "send"
becomes "recv" and vice versa, and include it in the answer. becomes "recv" and vice versa, and include it in the answer.
An answerer that receives an offer with simulcast containing an An answerer that receives an offer with simulcast containing an
"a=simulcast" attribute listing alternative rid-id MAY keep all the "a=simulcast" attribute listing alternative rid-id MAY keep all the
alternative rid-id in the answer, but it MAY also choose to remove alternative rid-id in the answer, but it MAY also choose to remove
any non-desirable alternative rid-id in the answer. The answerer any non-desirable alternative rid-id in the answer. The answerer
MUST NOT add any alternative rid-id in send direction in the answer MUST NOT add any alternative rid-id in send direction in the answer
that were not present in the offer receive direction. The answerer that were not present in the offer receive direction. The answerer
MUST be prepared to receive any of the receive direction rid-id MUST be prepared to receive any of the receive direction rid-id
alternatives, and MAY send any of the send direction alternatives alternatives and MAY send any of the send direction alternatives that
that are kept in the answer. are part of the answer.
An answerer that receives an offer with simulcast that lists a number An answerer that receives an offer with simulcast that lists a number
of simulcast streams, MAY reduce the number of simulcast streams in of simulcast streams, MAY reduce the number of simulcast streams in
the answer, but MUST NOT add simulcast streams. the answer, but MUST NOT add simulcast streams.
An answerer that receives an offer without RTP stream pause/resume An answerer that receives an offer without RTP stream pause/resume
capability MUST NOT mark any simulcast streams as initially paused in capability MUST NOT mark any simulcast streams as initially paused in
the answer. the answer.
An RTP stream pause/resume capable answerer that receives an offer An RTP stream pause/resume capable answerer that receives an offer
skipping to change at page 23, line 31 skipping to change at page 23, line 31
simulcast has been negotiated in the sending direction, the endpoint simulcast has been negotiated in the sending direction, the endpoint
can transmit up to the number of RTP streams needed for the can transmit up to the number of RTP streams needed for the
negotiated simulcast streams for that media source. Each RTP stream negotiated simulcast streams for that media source. Each RTP stream
(SSRC) is identified by associating (Section 5.5) it with an (SSRC) is identified by associating (Section 5.5) it with an
RtpStreamId SDES item, transmitted in RTCP and possibly also as an RtpStreamId SDES item, transmitted in RTCP and possibly also as an
RTP header extension. In cases where multiple media sources have RTP header extension. In cases where multiple media sources have
been negotiated for the same RTP session and thus BUNDLE been negotiated for the same RTP session and thus BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used, also the MID SDES [I-D.ietf-mmusic-sdp-bundle-negotiation] is used, also the MID SDES
item will be sent similarly to the RtpStreamId. item will be sent similarly to the RtpStreamId.
Each RTP stream may not be continuously transmitted due to any of the Each RTP stream might not be continuously transmitted due to any of
following reasons; temporarily paused using Pause/Resume [RFC7728], the following reasons; temporarily paused using Pause/Resume
sender side application logic temporarily pausing it, or lack of [RFC7728], sender side application logic temporarily pausing it, or
network resources to transmit this simulcast stream. However, all lack of network resources to transmit this simulcast stream.
simulcast streams that have been negotiated have active and However, all simulcast streams that have been negotiated have active
maintained SSRC (at least in regular RTCP reports), even if no RTP and maintained SSRC (at least in regular RTCP reports), even if no
packets are currently transmitted. The relation between an RTP RTP packets are currently transmitted. The relation between an RTP
Stream (SSRC) and a particular simulcast stream is not expected to Stream (SSRC) and a particular simulcast stream is not expected to
change, except in exceptional situations such as SSRC collisions. At change, except in exceptional situations such as SSRC collisions. At
SSRC changes, the usage of MID and RtpStreamId should enable the SSRC changes, the usage of MID and RtpStreamId should enable the
receiver to correctly identify the RTP streams even after an SSRC receiver to correctly identify the RTP streams even after an SSRC
change. change.
6.2. RTP Middlebox to Receiver 6.2. RTP Middlebox to Receiver
RTP streams in a multi-party RTP session can be used in multiple RTP streams in a multi-party RTP session can be used in multiple
different ways, when the session utilizes simulcast at least on the different ways, when the session utilizes simulcast at least on the
skipping to change at page 28, line 36 skipping to change at page 28, line 36
support. support.
NAT/FW Traversal: Using multiple RTP sessions incurs more cost for NAT/FW Traversal: Using multiple RTP sessions incurs more cost for
NAT/FW traversal unless they can re-use the same transport flow, NAT/FW traversal unless they can re-use the same transport flow,
which can be achieved by Multiplexing Negotiation Using SDP Port which can be achieved by Multiplexing Negotiation Using SDP Port
Numbers [I-D.ietf-mmusic-sdp-bundle-negotiation]. Numbers [I-D.ietf-mmusic-sdp-bundle-negotiation].
7.1. Bitrate Adaptation 7.1. Bitrate Adaptation
Use of multiple simulcast streams can require a significant amount of Use of multiple simulcast streams can require a significant amount of
network resources. If the amount of available network resources network resources. The aggregate bandwidth for all simulcast streams
varies during an RTP session such that it does not match what is for a media source (and thus SDP media description) is bounded by any
negotiated in SDP, the bitrate used by the different simulcast SDP "b=" line applicable to that media source. It is assumed that a
streams may have to be reduced dynamically. What simulcast streams suitable congestion control mechanism is used by the application to
to prioritize when allocating available bitrate among the simulcast ensure that it doesn't cause persistent congestion. If the amount of
streams in such adaptation SHOULD be taken from the simulcast stream available network resources varies during an RTP session such that it
order on the "a=simulcast" line and ordering of alternative simulcast does not match what is negotiated in SDP, the bitrate used by the
formats Section 5.2. Simulcast streams that have pause/resume different simulcast streams may have to be reduced dynamically. When
capability and that would be given such low bitrate by the adaptation a simulcasting media source uses a single media transport for all of
process that they are considered not really useful can be temporarily the simulcast streams, it is likely that a joint congestion control
paused until the limiting condition clears. across all simulcast streams is used for that media source. What
simulcast streams to prioritize when allocating available bitrate
among the simulcast streams in such adaptation SHOULD be taken from
the simulcast stream order on the "a=simulcast" line and ordering of
alternative simulcast formats Section 5.2. Simulcast streams that
have pause/resume capability and that would be given such low bitrate
by the adaptation process that they are considered not really useful
can be temporarily paused until the limiting condition clears.
8. Limitation 8. Limitation
The chosen approach has a limitation that relates to the use of a The chosen approach has a limitation that relates to the use of a
single RTP session for all simulcast formats of a media source, which single RTP session for all simulcast formats of a media source, which
comes from sending all simulcast streams related to a media source comes from sending all simulcast streams related to a media source
under the same SDP media description. under the same SDP media description.
It is not possible to use different simulcast streams on different It is not possible to use different simulcast streams on different
media transports, limiting the possibilities to apply different QoS media transports, limiting the possibilities to apply different QoS
skipping to change at page 29, line 30 skipping to change at page 29, line 37
out of scope for the current document and would require additional out of scope for the current document and would require additional
specification. specification.
9. IANA Considerations 9. IANA Considerations
This document requests to register a new media-level SDP attribute, This document requests to register a new media-level SDP attribute,
"simulcast", in the "att-field (media level only)" registry within "simulcast", in the "att-field (media level only)" registry within
the SDP parameters registry, according to the procedures of [RFC4566] the SDP parameters registry, according to the procedures of [RFC4566]
and [I-D.ietf-mmusic-sdp-mux-attributes]. and [I-D.ietf-mmusic-sdp-mux-attributes].
Contact name, email: IETF, contacted via mmusic@ietf.org, or a Contact name, email: The IESG (iesg@ietf.org)
successor address designated by IESG
Attribute name: simulcast Attribute name: simulcast
Long-form attribute name: Simulcast stream description Long-form attribute name: Simulcast stream description
Charset dependent: No Charset dependent: No
Attribute value: sc-value; see Section 5.1 of RFC XXXX. Attribute value: sc-value; see Section 5.1 of RFC XXXX.
Purpose: Signals simulcast capability for a set of RTP streams Purpose: Signals simulcast capability for a set of RTP streams
skipping to change at page 30, line 46 skipping to change at page 31, line 4
significantly to subsequent versions. significantly to subsequent versions.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Bernard Aboba, Thomas Belling, Roni The authors would like to thank Bernard Aboba, Thomas Belling, Roni
Even, Adam Roach, Inaki Baz Castillo, Paul Kyzivat, and Arun Even, Adam Roach, Inaki Baz Castillo, Paul Kyzivat, and Arun
Arunachalam for the feedback they provided during the development of Arunachalam for the feedback they provided during the development of
this document. this document.
13. References 13. References
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]
Roach, A., "RTP Payload Format Restrictions", draft-ietf- Roach, A., "RTP Payload Format Restrictions", draft-ietf-
mmusic-rid-12 (work in progress), November 2017. mmusic-rid-14 (work in progress), February 2018.
[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-47 (work in progress), December 2017. negotiation-49 (work in progress), March 2018.
[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-17
(work in progress), December 2016. (work in progress), February 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
skipping to change at page 31, line 43 skipping to change at page 31, line 49
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP [RFC7728] Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP
Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728, Stream Pause and Resume", RFC 7728, DOI 10.17487/RFC7728,
February 2016, <https://www.rfc-editor.org/info/rfc7728>. February 2016, <https://www.rfc-editor.org/info/rfc7728>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-avtcore-multiplex-guidelines] [I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
Even, R., and H. Zheng, "Guidelines for using the Even, R., and H. Zheng, "Guidelines for using the
Multiplexing Features of RTP to Support Multiple Media Multiplexing Features of RTP to Support Multiple Media
Streams", draft-ietf-avtcore-multiplex-guidelines-05 (work Streams", draft-ietf-avtcore-multiplex-guidelines-05 (work
in progress), October 2017. in progress), October 2017.
[I-D.ietf-payload-flexible-fec-scheme] [I-D.ietf-payload-flexible-fec-scheme]
Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP
Payload Format for Flexible Forward Error Correction Payload Format for Flexible Forward Error Correction
(FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in (FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in
progress), July 2017. progress), March 2018.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997, DOI 10.17487/RFC2198, September 1997,
<https://www.rfc-editor.org/info/rfc2198>. <https://www.rfc-editor.org/info/rfc2198>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
skipping to change at page 34, line 12 skipping to change at page 34, line 17
RFC 8108, DOI 10.17487/RFC8108, March 2017, RFC 8108, DOI 10.17487/RFC8108, March 2017,
<https://www.rfc-editor.org/info/rfc8108>. <https://www.rfc-editor.org/info/rfc8108>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>. <https://www.rfc-editor.org/info/rfc8285>.
Appendix A. Requirements Appendix A. Requirements
The following requirements have to be met to support the use cases The following requirements are met by the defined solution to support
(Section 3): the use cases (Section 3):
REQ-1: Identification: REQ-1: Identification:
REQ-1.1: It must be possible to identify a set of simulcasted RTP REQ-1.1: It must be possible to identify a set of simulcasted RTP
streams as originating from the same media source in SDP streams as originating from the same media source in SDP
signaling. signaling.
REQ-1.2: An RTP endpoint must be capable of identifying the REQ-1.2: An RTP endpoint must be capable of identifying the
simulcast stream a received RTP stream is associated with, simulcast stream a received RTP stream is associated with,
knowing the content of the SDP signalling. knowing the content of the SDP signalling.
skipping to change at page 35, line 37 skipping to change at page 35, line 40
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 -10 and -11 B.1. Modifications Between WG Version -11 and -12
o Modified Normative statement regarding RTP stream duplication in
Section 5.2.
o Clarified assumption about use of congestion control by
applications.
o Changed to use RFC 8174 boilerplate instead of RFC 2119.
o Clarified explanation of syntax for simulcast attribute in
Section 4.
o Editorial clarification in Section 5.2 and 5.3.2.
o Various minor editorials and nits.
B.2. Modifications Between WG Version -10 and -11
o Added new SDP example section on Simulcast and Redundancy, o Added new SDP example section on Simulcast and Redundancy,
including both RED (RFC2198), RTP RTX (RFC4588), and FEC (draft- including both RED (RFC2198), RTP RTX (RFC4588), and FEC (draft-
ietf-payload-flexible-fec-scheme). ietf-payload-flexible-fec-scheme).
o Removed restriction that "related" payload formats in an RTP o Removed restriction that "related" payload formats in an RTP
stream (such as CN and DTMF) must not have their own rid-id, since stream (such as CN and DTMF) must not have their own rid-id, since
there is no reason to forbid this and corresponding clarification there is no reason to forbid this and corresponding clarification
is made in draft-ietf-mmusic-rid. is made in draft-ietf-mmusic-rid.
o Removed any mention of source-specific signaling and the reference o Removed any mention of source-specific signaling and the reference
to RFC5576, since draft-ietf-mmusic-rid is not defined for source- to RFC5576, since draft-ietf-mmusic-rid is not defined for source-
specific signaling. specific signaling.
o Changed some SDP examples to use a=rid restrictions instead of o Changed some SDP examples to use a=rid restrictions instead of
a=imageattr. a=imageattr.
o Changed reference from the obsoleted RFC 5285 to RFC 8285. o Changed reference from the obsoleted RFC 5285 to RFC 8285.
B.2. Modifications Between WG Version -09 and -10 B.3. Modifications Between WG Version -09 and -10
o Amended overview section with a bit more explanation on the o Amended overview section with a bit more explanation on the
examples, and added an rid-id alternative for one of the streams. examples, and added an rid-id alternative for one of the streams.
o Removed SCID also from the Terminology section, which was o Removed SCID also from the Terminology section, which was
forgotten in -09 when changing SCID to rid-id. forgotten in -09 when changing SCID to rid-id.
B.3. Modifications Between WG Version -08 and -09 B.4. 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 36, line 42 skipping to change at page 37, 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.4. Modifications Between WG Version -07 and -08 B.5. 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.5. Modifications Between WG Version -06 and -07 B.6. 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.6. Modifications Between WG Version -05 and -06 B.7. 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.7. Modifications Between WG Version -04 and -05 B.8. 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 38, line 19 skipping to change at page 38, 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.8. Modifications Between WG Version -03 and -04 B.9. 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.9. Modifications Between WG Version -02 and -03 B.10. 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.10. Modifications Between WG Version -01 and -02 B.11. 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.11. Modifications Between WG Version -00 and -01 B.12. Modifications Between WG Version -00 and -01
o No changes. Only preventing expiry. o No changes. Only preventing expiry.
B.12. Modifications Between Individual Version -00 and WG Version -00 B.13. 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
 End of changes. 47 change blocks. 
154 lines changed or deleted 190 lines changed or added

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