draft-ietf-mmusic-sdp-simulcast-12.txt   draft-ietf-mmusic-sdp-simulcast-13.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: October 12, 2018 S. Nandakumar Expires: December 29, 2018 S. Nandakumar
M. Zanaty M. Zanaty
Cisco Cisco
April 10, 2018 June 27, 2018
Using Simulcast in SDP and RTP Sessions Using Simulcast in SDP and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-12 draft-ietf-mmusic-sdp-simulcast-13
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 October 12, 2018. This Internet-Draft will expire on December 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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 . . . . . . . . . . . . . . . . . . . 10 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10
5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 16
5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . 18 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18
5.6.3. Simulcast and Redundancy . . . . . . . . . . . . . . 20 5.6.3. Simulcast and Redundancy . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . 32 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 -11 and -12 . . . . . . 35 B.1. Modifications Between WG Version -12 and -13 . . . . . . 35
B.2. Modifications Between WG Version -10 and -11 . . . . . . 36 B.2. Modifications Between WG Version -11 and -12 . . . . . . 36
B.3. Modifications Between WG Version -09 and -10 . . . . . . 36 B.3. Modifications Between WG Version -10 and -11 . . . . . . 36
B.4. Modifications Between WG Version -08 and -09 . . . . . . 36 B.4. Modifications Between WG Version -09 and -10 . . . . . . 37
B.5. Modifications Between WG Version -07 and -08 . . . . . . 37 B.5. Modifications Between WG Version -08 and -09 . . . . . . 37
B.6. Modifications Between WG Version -06 and -07 . . . . . . 37 B.6. Modifications Between WG Version -07 and -08 . . . . . . 37
B.7. Modifications Between WG Version -05 and -06 . . . . . . 37 B.7. Modifications Between WG Version -06 and -07 . . . . . . 38
B.8. Modifications Between WG Version -04 and -05 . . . . . . 38 B.8. Modifications Between WG Version -05 and -06 . . . . . . 38
B.9. Modifications Between WG Version -03 and -04 . . . . . . 38 B.9. Modifications Between WG Version -04 and -05 . . . . . . 38
B.10. Modifications Between WG Version -02 and -03 . . . . . . 39 B.10. Modifications Between WG Version -03 and -04 . . . . . . 39
B.11. Modifications Between WG Version -01 and -02 . . . . . . 39 B.11. Modifications Between WG Version -02 and -03 . . . . . . 39
B.12. Modifications Between WG Version -00 and -01 . . . . . . 39 B.12. Modifications Between WG Version -01 and -02 . . . . . . 40
B.13. Modifications Between Individual Version -00 and WG B.13. Modifications Between WG Version -00 and -01 . . . . . . 40
B.14. Modifications Between Individual Version -00 and WG
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 40 Version -00 . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 4, line 8 skipping to change at page 4, line 9
how the identification and grouping of the involved RTP streams are how the identification and grouping of the involved RTP streams are
done. done.
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 Simulcast could, as part of a distributed multi-party scenario, be
for future extension. used point-to-point between middleboxes. Usage of multicast or
broadcast transport is out of scope and left for future extensions.
This document describes a few scenarios that motivates the use of This document describes a few scenarios that motivate 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 22 skipping to change at page 5, line 24
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.
There are two principle approaches for an RTP Mixer to provide this There are two principal approaches for an RTP Mixer to provide this
adapted view of the communication session to each receiving adapted view of the communication session to each receiving
participant: participant:
o Transcoding (decoding and re-encoding) received RTP streams with o Transcoding (decoding and re-encoding) received RTP streams with
characteristics adapted to each receiving participant. This often characteristics adapted to each receiving participant. This often
include mixing or composition of media sources from multiple include mixing or composition of media sources from multiple
participants into a mixed media source originated by the RTP participants into a mixed media source originated by the RTP
Mixer. The main advantage of this approach is that it achieves Mixer. The main advantage of this approach is that it achieves
close to optimal adaptation to individual receiving participants. close to optimal adaptation to individual receiving participants.
The main disadvantages are that it can be very computationally The main disadvantages are that it can be very computationally
skipping to change at page 5, line 45 skipping to change at page 5, line 47
participants, and requires RTP Mixer access to media content. participants, and requires RTP Mixer access to media content.
o Switching a subset of all received RTP streams or sub-streams to o Switching a subset of all received RTP streams or sub-streams to
each receiving participant, where the used subset is typically each receiving participant, where the used subset is typically
specific to each receiving participant. The main advantages of specific to each receiving participant. The main advantages of
this approach are that it is computationally cheap to the RTP this approach are that it is computationally cheap to the RTP
Mixer, has very limited impact on media QoE, and does not require Mixer, has very limited impact on media QoE, and does not require
RTP Mixer (full) access to media content. The main disadvantage RTP Mixer (full) access to media content. The main disadvantage
is that it can be difficult to combine a subset of received RTP is that it can be difficult to combine a subset of received RTP
streams into a perfect fit to the resource situation of a streams into a perfect fit to the resource situation of a
receiving participant. receiving participant. It is also a disadvantage that sending
multiple RTP streams consumes more network resources from the
sending participant to the RTP Mixer.
The use of simulcast relates to the latter approach, where it is more The use of simulcast relates to the latter approach, where it is more
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
skipping to change at page 6, line 29 skipping to change at page 6, line 33
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 number 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 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
terms of available resources and that the sending participant can terms of available resources and that the sending participant can
choose a matching configuration for a single RTP stream per category choose a matching configuration for a single RTP stream per category
skipping to change at page 7, line 14 skipping to change at page 7, line 18
3.2. Application Specific Media Source Handling 3.2. Application Specific Media Source Handling
The application logic that controls the communication session may The application logic that controls the communication session may
include special handling of some media sources. It is, for example, include special handling of some media sources. It is, for example,
commonly the case that the media from a sending participant is not commonly the case that the media from a sending participant is not
sent back to itself. sent back to itself.
It is also common that a currently active speaker participant is It is also common that a currently active speaker participant is
shown in larger size or higher quality than other participants (the shown in larger size or higher quality than other participants (the
sampling or bitrate aspects of Section 3.1). Not sending the active sampling or bitrate aspects of Section 3.1) in a receiving client.
speaker media back to itself means there is some other participant's Many conferencing systems do not send the active speaker's media back
media that instead has to receive special handling towards the active to the sender itself, which means there is some other participant's
speaker; typically the previous active speaker. This way, the media that instead is forwarded to the active speaker; typically the
previously active speaker is needed both in larger size (to current previous active speaker. This way, the previously active speaker is
active speaker) and in small size (to the rest of the participants), needed both in larger size (to current active speaker) and in small
which can be solved with a simulcast from the previously active size (to the rest of the participants), which can be solved with a
speaker to the RTP switch. simulcast from the previously active 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 state preferences on the allow receiving participants to state preferences on the
characteristics of the RTP stream they like to receive, for example characteristics of the RTP stream they like to receive, for example
in terms of the aspects listed in Section 3.1. Sending a simulcast in terms of the aspects listed in Section 3.1. Sending a simulcast
of RTP streams is one way of accommodating receivers with conflicting of RTP streams is one way of accommodating receivers with conflicting
or otherwise incompatible preferences. or otherwise incompatible preferences.
skipping to change at page 8, line 34 skipping to change at page 8, line 39
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:rtp-stream-id
Figure 1: Example Simulcast Media Description in Offer Figure 1: Example Simulcast Media Description in Offer
The above SDP media description can be interpreted at 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.
skipping to change at page 9, line 23 skipping to change at page 9, line 28
alternative that it doesn't support (rid-id 3). The send part alternative that it doesn't support (rid-id 3). The send part
confirms to the offerer that it will receive one stream for this confirms to the offerer that it will receive one stream for this
media source according to rid-id 4. The corresponding, more complete media source according to rid-id 4. The corresponding, more complete
example SDP answer media description could look like: 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=rid:1 recv pt=97 max-width=1280;max-height=720 a=rid:1 recv pt=97;max-width=1280;max-height=720
a=rid:2 recv pt=98 max-width=320;max-height=180 a=rid:2 recv pt=98;max-width=320;max-height=180
a=rid:4 send pt=97 a=rid:4 send pt=97
a=simulcast:recv 1;2 send 4 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:rtp-stream-id
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.
To summarize, the "a=simulcast" line describes send and receive To summarize, the "a=simulcast" line describes send and receive
skipping to change at page 10, line 10 skipping to change at page 10, line 16
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.
5.1. Simulcast Attribute 5.1. Simulcast Attribute
This document defines a new SDP media-level "a=simulcast" attribute, This document defines a new SDP media-level "a=simulcast" attribute,
with value according to the following ABNF [RFC5234] syntax: with value according to the following ABNF [RFC5234] syntax and its
update for Case-Sensitive String Support in ABNF [RFC7405]:
sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] ) sc-value = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] )
sc-send = "send" SP sc-str-list sc-send = %s"send" SP sc-str-list
sc-recv = "recv" SP sc-str-list sc-recv = %s"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 Note to RFC Editor: Replace "I-D.ietf-mmusic-rid" in the above
skipping to change at page 10, line 45 skipping to change at page 10, line 52
[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
by a semicolon (";"). Each simulcast stream can in turn be offered by a semicolon (";"). Each simulcast stream can in turn be offered
in one or more alternative formats, represented by rid-ids, separated in one or more alternative formats, represented by rid-ids, separated
by a comma (","). Each rid-id can also be specified as initially by a comma (","). Each rid-id can also be specified as initially
paused [RFC7728], indicated by prepending a "~" to the rid-id. The paused [RFC7728], indicated by prepending a "~" to the rid-id. The
reason to allow separate initial pause states for each rid-id is that reason to allow separate initial pause states for each rid-id is that
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 applies only to specified payload types and
to common payload types, it is unfeasible to pause streams with rid- rid-id specified by "a=rid" can refer to multiple different payload
id where any of the related RTP payload type(s) do not have pause types, it is unfeasible to pause streams with rid-id where any of the
capability. related RTP payload type(s) do not have pause 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 use of this attribute at attribute, "a=simulcast" (Section 5.1). The use of this attribute at
the session level is undefined. Implementations of this the session level is undefined. Implementations of this
specification MUST NOT use it at the session level and MUST ignore it specification MUST NOT use it at the session level and MUST ignore it
if received at the session level. Extensions to this specification if received at the session level. Extensions to this specification
may define such session level usage. Each SDP media description MUST may define such session level usage. Each SDP media description MUST
contain at most one "a=simulcast" line. contain at most one "a=simulcast" line.
skipping to change at page 11, line 50 skipping to change at page 12, line 5
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. The order of the rid-id alternatives within a alternative rid-id. The order of the rid-id alternatives within a
simulcast stream is significant; the rid-id alternatives are listed simulcast stream is significant; the rid-id alternatives are listed
from (left) most preferred to (right) least preferred. For the use from (left) most preferred to (right) least preferred. For the use
of simulcast, this overrides the normal codec preference as expressed of simulcast, this overrides the normal codec preference as expressed
by format type ordering on the "m=" line, using regular SDP rules. by format type ordering on the "m=" line, using regular SDP rules.
This is to enable a separation of general codec preferences and This is to enable a separation of general codec preferences and
simulcast stream configuration preferences. However, the choice of simulcast stream configuration preferences. However, the choice of
which alternative to use per simulcast stream is independent, and which alternative to use per simulcast stream is independent, and
there is currently no mechanism for align the choice between there is currently no mechanism to align the choice between
alternative rid-ids between different simulcast streams. 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 an 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 An initially paused simulcast stream in "send" direction for the
endpoint sending the SDP MUST be considered equivalent to an endpoint sending the SDP MUST be considered equivalent to an
unsolicited locally paused stream, and be handled accordingly. unsolicited locally paused stream, and be handled accordingly.
Initially paused simulcast streams are resumed as described by the Initially paused simulcast streams are resumed as described by the
RTP pause/resume specification. An RTP stream receiver that wishes RTP pause/resume specification. An RTP stream receiver that wishes
to resume an unsolicited locally paused stream needs to know the SSRC to resume an unsolicited locally paused stream needs to know the SSRC
of that stream. The SSRC of an initially paused simulcast stream can of that stream. The SSRC of an initially paused simulcast stream can
be obtained from an RTP stream sender RTCP Sender Report (SR) be obtained from an RTP stream sender RTCP Sender Report (SR)
including both the desired SSRC as "SSRC of sender", and the rid-id including both the desired SSRC as "SSRC of sender", and the rid-id
value in an RtpStreamId RTCP SDES item [I-D.ietf-avtext-rid]. value in an RtpStreamId RTCP SDES item [I-D.ietf-avtext-rid].
If the endpoint sending the SDP includes an "recv" direction If the endpoint sending the SDP includes an "recv" direction
simulcast stream that is initially paused, then the remote RTP sender simulcast stream that is initially paused, then the remote RTP sender
receiving the SDP SHOULD put its RTP stream in a unsolicited locally receiving the SDP SHOULD put its RTP stream in a unsolicited locally
paused state. However, this does not apply if there are other RTP paused state. The simulcast stream sender does not put the stream in
stream receivers that do not mark the simulcast stream as initially the locally paused state if there are other RTP stream receivers in
paused. The reason to require an initially paused "recv" stream to the session that do not mark the simulcast stream as initially
be considered locally paused by the remote RTP sender, instead of paused. However, in centralized conferencing the RTP sender usually
making it equivalent to implicitly sending a pause request, is does not see the SDP signalling from RTP receivers and cannot make
because the pausing RTP sender cannot know which receiving SSRC owns this determination. The reason to require an initially paused "recv"
the restriction when Temporary Maximum Media Stream Bit Rate Request stream to be considered locally paused by the remote RTP sender,
(TMMBR) and Temporary Maximum Media Stream Bit Rate Notification instead of making it equivalent to implicitly sending a pause
(TMMBN) are used for pause/resume signaling (Section 5.6 of request, is because the pausing RTP sender cannot know which
[RFC7728]) since the RTP receiver's SSRC in send direction is receiving SSRC owns the restriction when Temporary Maximum Media
sometimes not yet known. Stream Bit Rate Request (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
skipping to change at page 17, line 27 skipping to change at page 17, line 44
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 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 recv pt=97
a=simulcast:send 1;2 recv 3 a=simulcast:send 1;2 recv 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
Figure 5: Single-Source Simulcast Offer Figure 5: Single-Source Simulcast Offer
The only thing in the SDP that indicates simulcast capability is the The only thing in the SDP that indicates simulcast capability is the
line in the video media description containing the "simulcast" line in the video media description containing the "simulcast"
attribute. The included "a=fmtp" and "a=imageattr" parameters attribute. The included "a=fmtp" and "a=imageattr" parameters
indicates that sent simulcast streams can differ in video resolution. indicates that sent simulcast streams can differ in video resolution.
The RTP header extension for RtpStreamId is offered to avoid issues The RTP header extension for RtpStreamId is offered to avoid issues
with the initial binding between RTP streams (SSRCs) and the with the initial binding between RTP streams (SSRCs) and the
RtpStreamId identifying the simulcast stream and its format. RtpStreamId identifying the simulcast stream and its format.
skipping to change at page 18, line 23 skipping to change at page 18, line 31
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:3 send pt=97
a=simulcast:recv 1;2 send 3 a=simulcast:recv 1;2 send 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
Figure 6: Single-Source Simulcast Answer Figure 6: Single-Source Simulcast Answer
Since the server is the simulcast media receiver, it reverses the Since the server is the simulcast media receiver, it reverses the
direction of the "simulcast" and "rid" attribute parameters. direction of the "simulcast" and "rid" attribute parameters.
5.6.2. Multi-Source Client 5.6.2. Multi-Source Client
Fred is calling in to the same conference as in the example above Fred is calling in to the same conference as in the example above
with a two-camera, two-display system, thus capable of handling two with a two-camera, two-display system, thus capable of handling two
skipping to change at page 18, line 49 skipping to change at page 19, line 10
different codecs, H264-SVC [RFC6190] and H264 [RFC6184]. These two different codecs, H264-SVC [RFC6190] and H264 [RFC6184]. These two
simulcast streams also have a temporal dependency. Two different simulcast streams also have a temporal dependency. Two different
video codecs, VP8 [RFC7741] and H264, are offered as alternatives for video codecs, VP8 [RFC7741] and H264, are offered as alternatives for
the third simulcast stream for the first media source. Only the the third simulcast stream for the first media source. Only the
highest fidelity simulcast stream is sent from start, the lower highest fidelity simulcast stream is sent from start, the lower
fidelity streams being initially paused. fidelity streams being initially paused.
The second media source is offered with three different simulcast The second media source is offered with three different simulcast
streams. All video streams of this second media source are loss streams. All video streams of this second media source are loss
protected by RTP retransmission [RFC4588]. Also here, all but the protected by RTP retransmission [RFC4588]. Also here, all but the
highest fidelity simulcast stream are initially paused. highest fidelity simulcast stream are initially paused. Note that
the lower resolution is more prioritized than the medium resolution
simulcast stream.
Fred's client is also using BUNDLE to send all RTP streams from all Fred's client is also using BUNDLE to send all RTP streams from all
media descriptions in the same RTP session on a single media media descriptions in the same RTP session on a single media
transport. Although using many different simulcast streams in this transport. Although using many different simulcast streams in this
example, the use of RtpStreamId as simulcast stream identification example, the use of RtpStreamId as simulcast stream identification
enables use of a low number of RTP payload types. Note that the use enables use of a low number of RTP payload types. Note that the use
of both BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and "a=rid" of both BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and "a=rid"
[I-D.ietf-mmusic-rid] recommends using the RTP header extension [I-D.ietf-mmusic-rid] recommends using the RTP header extension
[RFC8285] for carrying these RTP stream identification fields, which [RFC8285] for carrying these RTP stream identification fields, which
is consequently also included in the SDP. Note also that for is consequently also included in the SDP. Note also that for
"a=rid", the corresponding SDES attribute is named RtpStreamId "a=rid", the corresponding RtpStreamId SDES attribute RTP header
[I-D.ietf-avtext-rid]. extension is named rtp-stream-id [I-D.ietf-avtext-rid].
v=0 v=0
o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d
s=Offer from Simulcast Enabled Multi-Source Client s=Offer from Simulcast Enabled Multi-Source Client
t=0 0 t=0 0
c=IN IP6 2001:db8::c000:27d c=IN IP6 2001:db8::c000:27d
a=group:BUNDLE foo bar zen a=group:BUNDLE foo bar zen
m=audio 49200 RTP/AVP 99 m=audio 49200 RTP/AVP 99
a=mid:foo a=mid:foo
a=rtpmap:99 G722/8000 a=rtpmap:99 G722/8000
skipping to change at page 20, line 29 skipping to change at page 20, line 29
a=fmtp:100 profile-level-id=42400d;max-fs=3600;max-mbps=216000; \ a=fmtp:100 profile-level-id=42400d;max-fs=3600;max-mbps=216000; \
mst-mode=NI-TC mst-mode=NI-TC
a=fmtp:101 profile-level-id=42c00d;max-fs=3600;max-mbps=108000 a=fmtp:101 profile-level-id=42c00d;max-fs=3600;max-mbps=108000
a=fmtp:103 max-fs=900; max-fr=30 a=fmtp:103 max-fs=900; max-fr=30
a=rid:1 send pt=100;max-width=1280;max-height=720;max-fps=60;depend=2 a=rid:1 send pt=100;max-width=1280;max-height=720;max-fps=60;depend=2
a=rid:2 send pt=101;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=101;max-width=1280;max-height=720;max-fps=30
a=rid:3 send pt=101;max-width=640;max-height=360 a=rid:3 send pt=101;max-width=640;max-height=360
a=rid:4 send pt=103;max-width=640;max-height=360 a=rid:4 send pt=103;max-width=640;max-height=360
a=depend:100 lay bar:101 a=depend:100 lay bar:101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:* ccm pause nowait a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1;2;~4,3 a=simulcast:send 1;2;~4,3
m=video 49602 RTP/AVPF 96 104 m=video 49602 RTP/AVPF 96 104
a=mid:zen a=mid:zen
a=rtpmap:96 VP8/90000 a=rtpmap:96 VP8/90000
a=fmtp:96 max-fs=3600; max-fr=30 a=fmtp:96 max-fs=3600; max-fr=30
a=rtpmap:104 rtx/90000 a=rtpmap:104 rtx/90000
a=fmtp:104 apt=96;rtx-time=200 a=fmtp:104 apt=96;rtx-time=200
a=rid:1 send pt=96;max-fs=921600;max-fps=30 a=rid:1 send max-fs=921600;max-fps=30
a=rid:2 send pt=96;max-fs=614400;max-fps=15 a=rid:2 send max-fs=614400;max-fps=15
a=rid:3 send pt=96;max-fs=230400;max-fps=30 a=rid:3 send max-fs=230400;max-fps=30
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=rtcp-fb:* ccm pause nowait a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1;~2;~3 a=simulcast:send 1;~3;~2
Figure 7: Fred's Multi-Source Simulcast Offer Figure 7: Fred's Multi-Source Simulcast Offer
5.6.3. Simulcast and Redundancy 5.6.3. Simulcast and Redundancy
The example in this section looks at applying simulcast with audio The example in this section looks at applying simulcast with audio
and video redundancy formats. The audio media description uses codec and video redundancy formats. The audio media description uses codec
and bitrate restrictions, combining it with RTP Payload for Redundant and bitrate restrictions, combining it with RTP Payload for Redundant
Audio Data [RFC2198] for enhanced packet loss resilience. The video Audio Data [RFC2198] for enhanced packet loss resilience. The video
media description applies both resolution and bitrate restrictions, media description applies both resolution and bitrate restrictions,
skipping to change at page 22, line 19 skipping to change at page 22, line 19
c=IN IP6 2001:db8::c000:27d c=IN IP6 2001:db8::c000:27d
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 49200 RTP/AVP 97 98 99 100 101 102 m=audio 49200 RTP/AVP 97 98 99 100 101 102
a=mid:foo a=mid:foo
a=rtpmap:97 G711/8000 a=rtpmap:97 G711/8000
a=rtpmap:98 LPC/8000 a=rtpmap:98 LPC/8000
a=rtpmap:99 OPUS/48000/1 a=rtpmap:99 OPUS/48000/1
a=rtpmap:100 RED/8000/1 a=rtpmap:100 RED/8000/1
a=rtpmap:101 CN/8000 a=rtpmap:101 CN/8000
a=rtpmap:102 telephone-event/8000 a=rtpmap:102 telephone-event/8000
a=fmtp:99 useinbandfec=1; usedtx=0 a=fmtp:99 useinbandfec=1;usedtx=0
a=fmtp:100 97/98 a=fmtp:100 97/98
a=fmtp:102 0-15 a=fmtp:102 0-15
a=ptime:20 a=ptime:20
a=maxptime:40 a=maxptime:40
a=rid:5 send pt=99,102;max-br=64000 a=rid:1 send pt=99,102;max-br=64000
a=rid:6 send pt=100,97,101,102 a=rid:2 send pt=100,97,101,102
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=simulcast:send 5;6 a=simulcast:send 1;2
m=video 49600 RTP/AVPF 103 104 105 106 107 m=video 49600 RTP/AVPF 103 104 105 106 107
a=mid:bar a=mid:bar
a=rtpmap:103 H264/90000 a=rtpmap:103 H264/90000
a=rtpmap:104 VP8/90000 a=rtpmap:104 VP8/90000
a=rtpmap:105 rtx/90000 a=rtpmap:105 rtx/90000
a=rtpmap:106 rtx/90000 a=rtpmap:106 rtx/90000
a=rtpmap:107 flexfec/90000 a=rtpmap:107 flexfec/90000
a=fmtp:103 profile-level-id=42c00d;max-fs=3600;max-mbps=108000 a=fmtp:103 profile-level-id=42c00d;max-fs=3600;max-mbps=108000
a=fmtp:104 max-fs=3600; max-fr=30 a=fmtp:104 max-fs=3600; max-fr=30
a=fmtp:105 apt=103;rtx-time=200 a=fmtp:105 apt=103;rtx-time=200
a=fmtp:106 apt=104;rtx-time=200 a=fmtp:106 apt=104;rtx-time=200
a=fmtp:107 repair-window=2000 a=fmtp:107 repair-window=2000
a=rid:1 send pt=103;max-width=1280;max-height=720;max-fps=30 a=rid:1 send pt=103;max-width=1280;max-height=720;max-fps=30
a=rid:2 send pt=104;max-width=1280;max-height=720;max-fps=30 a=rid:2 send pt=104;max-width=1280;max-height=720;max-fps=30
a=rid:3 send pt=103;max-width=640;max-height=360;max-br=300000 a=rid:3 send pt=103;max-width=640;max-height=360;max-br=300000
a=rid:4 send pt=104;max-width=640;max-height=360;max-br=300000 a=rid:4 send pt=104;max-width=640;max-height=360;max-br=300000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=rtcp-fb:* ccm pause nowait a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1,2;3,4 a=simulcast:send 1,2;3,4
Figure 8: Simulcast and Redundancy Example
6. RTP Aspects 6. RTP Aspects
This section discusses what the different entities in a simulcast This section discusses what the different entities in a simulcast
media path can expect to happen on RTP level. This is explored from media path can expect to happen on RTP level. This is explored from
source to sink by starting in an endpoint with a media source that is source to sink by starting in an endpoint with a media source that is
simulcasted to an RTP middlebox. That RTP middlebox sends media simulcasted to an RTP middlebox. That RTP middlebox sends media
sources both to other RTP middleboxes (cascaded middleboxes), as well sources both to other RTP middleboxes (cascaded middleboxes), as well
as selecting some simulcast format of the media source and sending it as selecting some simulcast format of the media source and sending it
to receiving endpoints. Different types of RTP middleboxes and their to receiving endpoints. Different types of RTP middleboxes and their
usage of the different simulcast formats results in several different usage of the different simulcast formats results in several different
skipping to change at page 31, line 13 skipping to change at page 31, line 13
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-14 (work in progress), February 2018. mmusic-rid-15 (work in progress), May 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-49 (work in progress), March 2018. negotiation-52 (work in progress), May 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-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018. (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>.
skipping to change at page 31, line 45 skipping to change at page 31, line 45
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[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>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
skipping to change at page 35, line 40 skipping to change at page 35, line 46
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 -11 and -12 B.1. Modifications Between WG Version -12 and -13
o Examples corrected to follow RID ABNF
o Example Figure 7 now comments on priority for second media source.
o Clarified a SHOULD limitation.
o Added urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id in
examples with RTX.
o ABNF now uses RFC 7405 to indicate case sensitivity
o Various minor editorials and nits.
B.2. Modifications Between WG Version -11 and -12
o Modified Normative statement regarding RTP stream duplication in o Modified Normative statement regarding RTP stream duplication in
Section 5.2. Section 5.2.
o Clarified assumption about use of congestion control by o Clarified assumption about use of congestion control by
applications. applications.
o Changed to use RFC 8174 boilerplate instead of RFC 2119. o Changed to use RFC 8174 boilerplate instead of RFC 2119.
o Clarified explanation of syntax for simulcast attribute in o Clarified explanation of syntax for simulcast attribute in
Section 4. Section 4.
o Editorial clarification in Section 5.2 and 5.3.2. o Editorial clarification in Section 5.2 and 5.3.2.
o Various minor editorials and nits. o Various minor editorials and nits.
B.2. Modifications Between WG Version -10 and -11 B.3. 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.3. Modifications Between WG Version -09 and -10 B.4. 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.4. Modifications Between WG Version -08 and -09 B.5. 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 37, line 13 skipping to change at page 37, line 37
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.5. Modifications Between WG Version -07 and -08 B.6. 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.6. Modifications Between WG Version -06 and -07 B.7. 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.7. Modifications Between WG Version -05 and -06 B.8. 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.8. Modifications Between WG Version -04 and -05 B.9. 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 39 skipping to change at page 39, line 19
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.9. Modifications Between WG Version -03 and -04 B.10. 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.10. Modifications Between WG Version -02 and -03 B.11. 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.11. Modifications Between WG Version -01 and -02 B.12. 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.12. Modifications Between WG Version -00 and -01 B.13. Modifications Between WG Version -00 and -01
o No changes. Only preventing expiry. o No changes. Only preventing expiry.
B.13. Modifications Between Individual Version -00 and WG Version -00 B.14. 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. 54 change blocks. 
94 lines changed or deleted 127 lines changed or added

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