draft-ietf-mmusic-sdp-simulcast-10.txt   draft-ietf-mmusic-sdp-simulcast-11.txt 
Network Working Group B. Burman Network Working Group B. Burman
Internet-Draft M. Westerlund Internet-Draft M. Westerlund
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 21, 2018 S. Nandakumar Expires: June 23, 2018 S. Nandakumar
M. Zanaty M. Zanaty
Cisco Cisco
July 20, 2017 December 20, 2017
Using Simulcast in SDP and RTP Sessions Using Simulcast in SDP and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-10 draft-ietf-mmusic-sdp-simulcast-11
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 35 skipping to change at page 1, line 35
and/or receive simulcast RTP streams. and/or receive simulcast RTP streams.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at 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 January 21, 2018. This Internet-Draft will expire on June 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . 10 5. Detailed Description . . . . . . . . . . . . . . . . . . . . 9
5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10 5.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10
5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 5.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . 16 5.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 15
5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 5.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16
5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17 5.6.1. Single-Source Client . . . . . . . . . . . . . . . . 16
5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 5.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18
6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6.3. Simulcast and Redundancy . . . . . . . . . . . . . . 20
6.1. Outgoing from Endpoint with Media Source . . . . . . . . 21 6. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21 6.1. Outgoing from Endpoint with Media Source . . . . . . . . 23
6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 22 6.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 23
6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24 6.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 24
6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25 6.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 26
7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26 6.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 27
7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 28
8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . 29 13.1. Normative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix B. Changes From Earlier Versions . . . . . . . . . . . 33 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 34
B.1. Modifications Between WG Version -09 and -10 . . . . . . 33 Appendix B. Changes From Earlier Versions . . . . . . . . . . . 35
B.2. Modifications Between WG Version -08 and -09 . . . . . . 33 B.1. Modifications Between WG Version -10 and -11 . . . . . . 35
B.3. Modifications Between WG Version -07 and -08 . . . . . . 34 B.2. Modifications Between WG Version -09 and -10 . . . . . . 36
B.4. Modifications Between WG Version -06 and -07 . . . . . . 34 B.3. Modifications Between WG Version -08 and -09 . . . . . . 36
B.5. Modifications Between WG Version -05 and -06 . . . . . . 34 B.4. Modifications Between WG Version -07 and -08 . . . . . . 36
B.6. Modifications Between WG Version -04 and -05 . . . . . . 35 B.5. Modifications Between WG Version -06 and -07 . . . . . . 37
B.7. Modifications Between WG Version -03 and -04 . . . . . . 35 B.6. Modifications Between WG Version -05 and -06 . . . . . . 37
B.8. Modifications Between WG Version -02 and -03 . . . . . . 36 B.7. Modifications Between WG Version -04 and -05 . . . . . . 37
B.9. Modifications Between WG Version -01 and -02 . . . . . . 36 B.8. Modifications Between WG Version -03 and -04 . . . . . . 38
B.10. Modifications Between WG Version -00 and -01 . . . . . . 36 B.9. Modifications Between WG Version -02 and -03 . . . . . . 38
B.11. Modifications Between Individual Version -00 and WG B.10. Modifications Between WG Version -01 and -02 . . . . . . 39
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 37 B.11. Modifications Between WG Version -00 and -01 . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 B.12. Modifications Between Individual Version -00 and WG
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 8, line 31 skipping to change at page 8, line 31
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=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=rid:1 send pt=97 max-width=1280;max-height=720
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:2 send pt=98 max-width=320;max-height=180
a=imageattr:99 send [x=320,y=180] recv [x=320,y=180] a=rid:3 send pt=99 max-width=320;max-height=180
a=rid:1 send pt=97
a=rid:2 send pt=98
a=rid:3 send pt=99
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 on 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
skipping to change at page 9, line 26 skipping to change at page 9, line 21
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=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=rid:1 recv pt=97 max-width=1280;max-height=720
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=rid:2 recv pt=98 max-width=320;max-height=180
a=rid:1 recv pt=97
a=rid:2 recv pt=98
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: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
skipping to change at page 11, line 7 skipping to change at page 10, line 48
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 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.
It is possible to use source-specific signaling [RFC5576] with
"a=simulcast", but it is only in certain cases possible to learn from
that signaling which SSRC will belong to a particular simulcast
stream.
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 meaning of the attribute
on SDP session level is undefined, MUST NOT be used by on SDP session level is undefined, MUST NOT be used by
implementations of this specification and MUST be ignored if received implementations of this specification and MUST be ignored if received
on session level. Extensions to this specification MAY define such on session level. Extensions to this specification MAY define such
session level usage. Each SDP media description MUST contain at most session level usage. Each SDP media description MUST contain at most
one "a=simulcast" line. one "a=simulcast" line.
skipping to change at page 12, line 16 skipping to change at page 11, line 51
alternatives are listed from (left) most preferred to (right) least alternatives are listed from (left) most preferred to (right) least
preferred. For the use of simulcast, this overrides the normal codec preferred. For the use of simulcast, this overrides the normal codec
preference as expressed by format type ordering on the "m=" line, preference as expressed by format type ordering on the "m=" line,
using regular SDP rules. This is to enable a separation of general using regular SDP rules. This is to enable a separation of general
codec preferences and simulcast stream configuration preferences. codec preferences and simulcast stream configuration preferences.
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. In those cases, such "related" formats MUST NOT [RFC4733] formats.
be defined as having their own rid-id listed explicitly in the
attribute parameters, since they are not strictly simulcast streams
of the media source, but rather a specific way of generating the RTP
stream of a single simulcast stream with varying RTP payload type.
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".
skipping to change at page 16, line 21 skipping to change at page 15, line 52
Simulcast RTP streams MUST be related on RTP level through Simulcast RTP streams MUST be related on RTP level through
RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP
"a=simulcast" attribute (Section 5.2) parameters. This is sufficient "a=simulcast" attribute (Section 5.2) parameters. This is sufficient
as long as there is only a single media source per SDP media as long as there is only a single media source per SDP media
description. When using BUNDLE description. When using BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media [I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media
descriptions jointly specify a single RTP session, the SDES MID descriptions jointly specify a single RTP session, the SDES MID
identification mechanism in BUNDLE allows relating RTP streams back identification mechanism in BUNDLE allows relating RTP streams back
to individual media descriptions, after which the above described to individual media descriptions, after which the above described
RtpStreamId relations can be used. Use of the RTP header extension RtpStreamId relations can be used. Use of the RTP header extension
[RFC5285] for both MID and RtpStreamId identifications can be [RFC8285] for both MID and RtpStreamId identifications can be
important to ensure rapid initial reception, required to correctly important to ensure rapid initial reception, required to correctly
interpret and process the RTP streams. Implementers of this interpret and process the RTP streams. Implementers of this
specification MUST support the RTCP source description (SDES) item specification MUST support the RTCP source description (SDES) item
method and SHOULD support RTP header extension method to signal method and SHOULD support RTP header extension method to signal
RtpStreamId on RTP level. RtpStreamId on RTP level.
NOTE: For the case where it is clear from SDP that RTP PT uniquely NOTE: For the case where it is clear from SDP that RTP PT uniquely
maps to corresponding RtpStreamId, an RTP receiver can use RTP PT maps to corresponding RtpStreamId, an RTP receiver can use RTP PT
to relate simulcast streams. This can sometimes enable decoding to relate simulcast streams. This can sometimes enable decoding
even in advance to receiving RtpStreamId information in RTCP SDES even in advance to receiving RtpStreamId information in RTCP SDES
skipping to change at page 17, line 36 skipping to change at page 17, line 15
v=0 v=0
o=alice 2362969037 2362969040 IN IP4 192.0.2.156 o=alice 2362969037 2362969040 IN IP4 192.0.2.156
s=Simulcast Enabled Client s=Simulcast Enabled Client
t=0 0 t=0 0
c=IN IP4 192.0.2.156 c=IN IP4 192.0.2.156
m=audio 49200 RTP/AVP 0 m=audio 49200 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 49300 RTP/AVP 97 98 m=video 49300 RTP/AVP 97 98
a=rtpmap:97 H264/90000 a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
a=rid:1 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:RtpStreamId
Figure 5: Single-Source Simulcast Offer Figure 5: Single-Source Simulcast Offer
skipping to change at page 18, line 23 skipping to change at page 18, line 15
v=0 v=0
o=server 823479283 1209384938 IN IP4 192.0.2.2 o=server 823479283 1209384938 IN IP4 192.0.2.2
s=Answer to Simulcast Enabled Client s=Answer to Simulcast Enabled Client
t=0 0 t=0 0
c=IN IP4 192.0.2.43 c=IN IP4 192.0.2.43
m=audio 49672 RTP/AVP 0 m=audio 49672 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
m=video 49674 RTP/AVP 97 98 m=video 49674 RTP/AVP 97 98
a=rtpmap:97 H264/90000 a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f; max-fs=3600; max-mbps=108000 a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b; max-fs=240; max-mbps=3600 a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720] a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180] a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
a=rid:1 recv pt=97 a=rid:1 recv pt=97
a=rid:2 recv pt=98 a=rid:2 recv pt=98
a=rid:3 send pt=97 a=rid: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:RtpStreamId
Figure 6: Single-Source Simulcast Answer Figure 6: Single-Source Simulcast Answer
skipping to change at page 19, line 19 skipping to change at page 19, line 9
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.
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
[RFC5285] 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 SDES attribute is named RtpStreamId
[I-D.ietf-avtext-rid]. [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
skipping to change at page 20, line 11 skipping to change at page 20, line 11
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 SDES attribute is named RtpStreamId
[I-D.ietf-avtext-rid]. [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
m=video 49600 RTP/AVPF 100 101 103 m=video 49600 RTP/AVPF 100 101 103
a=mid:bar a=mid:bar
a=rtpmap:100 H264-SVC/90000 a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264/90000 a=rtpmap:101 H264/90000
a=rtpmap:103 VP8/90000 a=rtpmap:103 VP8/90000
a=fmtp:100 profile-level-id=42400d; max-fs=3600; max-mbps=108000; \ 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=54000 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:RtpStreamId
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
skipping to change at page 20, line 51 skipping to change at page 20, line 48
a=rid:1 send pt=96;max-fs=921600;max-fps=30 a=rid:1 send pt=96;max-fs=921600;max-fps=30
a=rid:2 send pt=96;max-fs=614400;max-fps=15 a=rid:2 send pt=96;max-fs=614400;max-fps=15
a=rid:3 send pt=96;max-fs=230400;max-fps=30 a=rid:3 send pt=96;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:RtpStreamId
a=rtcp-fb:* ccm pause nowait a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1;~2;~3 a=simulcast:send 1;~2;~3
Figure 7: Fred's Multi-Source Simulcast Offer Figure 7: Fred's Multi-Source Simulcast Offer
Note: Empty lines in the SDP above are added only for readability 5.6.3. Simulcast and Redundancy
and would not be present in an actual SDP.
The example in this section looks at applying simulcast with audio
and video redundancy formats. The audio media description uses codec
and bitrate restrictions, combining it with RTP Payload for Redundant
Audio Data [RFC2198] for enhanced packet loss resilience. The video
media description applies both resolution and bitrate restrictions,
combining it with FEC in the form of Flexible FEC
[I-D.ietf-payload-flexible-fec-scheme] and RTP Retransmission
[RFC4588].
The audio source is offered to be sent as two simulcast streams. The
first simulcast stream is encoded with Opus, restricted to 50 kbps
(rid-id=5), and the second simulcast stream is encoded either with
G.711 (rid-id=7) or with G.711 combined with LPC for redundancy (rid-
id=6). In this example, stand-alone LPC is not offered as an
possible payload type for the second simulcast stream's RID, which
could e.g. be motivated by not providing sufficient quality.
The video source is offered to be sent as two simulcast streams, both
with two alternative simulcast formats. Redundancy and repair are
offered in the form of both Flexible FEC and RTP Retransmission. The
Flexible FEC is not bound to any particular RTP streams and is
therefore possible to use across all RTP streams that are being sent
as part of this media description.
v=0
o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d
s=Offer from Simulcast Enabled Client using Redundancy
t=0 0
c=IN IP6 2001:db8::c000:27d
a=group:BUNDLE foo bar
m=audio 49200 RTP/AVP 97 98 99 100 101 102
a=mid:foo
a=rtpmap:97 G711/8000
a=rtpmap:98 LPC/8000
a=rtpmap:99 OPUS/48000/1
a=rtpmap:100 RED/8000/1
a=rtpmap:101 CN/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:99 useinbandfec=1; usedtx=0
a=fmtp:100 97/98
a=fmtp:102 0-15
a=ptime:20
a=maxptime:40
a=rid:5 send pt=99,102;max-br=64000
a=rid:6 send pt=100,97,101,102
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
a=simulcast:send 5;6
m=video 49600 RTP/AVPF 103 104 105 106 107
a=mid:bar
a=rtpmap:103 H264/90000
a=rtpmap:104 VP8/90000
a=rtpmap:105 rtx/90000
a=rtpmap:106 rtx/90000
a=rtpmap:107 flexfec/90000
a=fmtp:103 profile-level-id=42c00d;max-fs=3600;max-mbps=108000
a=fmtp:104 max-fs=3600; max-fr=30
a=fmtp:105 apt=103;rtx-time=200
a=fmtp:106 apt=104;rtx-time=200
a=fmtp:107 repair-window=2000
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: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=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1,2;3,4
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
skipping to change at page 26, line 22 skipping to change at page 28, line 22
the different RTP multiplexing alternatives can be found in the different RTP multiplexing alternatives can be found in
Guidelines for Multiplexing in RTP Guidelines for Multiplexing in RTP
[I-D.ietf-avtcore-multiplex-guidelines]. Discussion and [I-D.ietf-avtcore-multiplex-guidelines]. Discussion and
clarification on how to handle multiple streams in an RTP session can clarification on how to handle multiple streams in an RTP session can
be found in [RFC8108]. be found in [RFC8108].
The network aspects that are relevant for simulcast are: The network aspects that are relevant for simulcast are:
Quality of Service: When using simulcast it might be of interest to Quality of Service: When using simulcast it might be of interest to
prioritize a particular simulcast stream, rather than applying prioritize a particular simulcast stream, rather than applying
equal treatment to all streams. For example, lower bit-rate equal treatment to all streams. For example, lower bitrate
streams may be prioritized over higher bit-rate streams to streams may be prioritized over higher bitrate streams to minimize
minimize congestion or packet losses in the low bit-rate streams. congestion or packet losses in the low bitrate streams. Thus,
Thus, there is a benefit to use a simulcast solution with good QoS there is a benefit to use a simulcast solution with good QoS
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
skipping to change at page 29, line 6 skipping to change at page 31, line 6
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]
Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., Roach, A., "RTP Payload Format Restrictions", draft-ietf-
Roach, A., and B. Campen, "RTP Payload Format mmusic-rid-12 (work in progress), November 2017.
Restrictions", draft-ietf-mmusic-rid-11 (work in
progress), July 2017.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-38 (work in progress), April 2017. negotiation-47 (work in progress), December 2017.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 2016.
[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,
<http://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, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[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, <http://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,
<http://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, <http://www.rfc-editor.org/info/rfc7728>. February 2016, <https://www.rfc-editor.org/info/rfc7728>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-avtcore-multiplex-guidelines] [I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand, Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
"Guidelines for using the Multiplexing Features of RTP to Even, R., and H. Zheng, "Guidelines for using the
Support Multiple Media Streams", draft-ietf-avtcore- Multiplexing Features of RTP to Support Multiple Media
multiplex-guidelines-03 (work in progress), October 2014. Streams", draft-ietf-avtcore-multiplex-guidelines-05 (work
in progress), October 2017.
[I-D.ietf-payload-flexible-fec-scheme]
Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP
Payload Format for Flexible Forward Error Correction
(FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in
progress), July 2017.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389,
September 2002, <http://www.rfc-editor.org/info/rfc3389>. September 2002, <https://www.rfc-editor.org/info/rfc3389>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>. <https://www.rfc-editor.org/info/rfc4588>.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", RFC 4733, Digits, Telephony Tones, and Telephony Signals", RFC 4733,
DOI 10.17487/RFC4733, December 2006, DOI 10.17487/RFC4733, December 2006,
<http://www.rfc-editor.org/info/rfc4733>. <https://www.rfc-editor.org/info/rfc4733>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>. February 2008, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)",
RFC 5583, DOI 10.17487/RFC5583, July 2009, RFC 5583, DOI 10.17487/RFC5583, July 2009,
<http://www.rfc-editor.org/info/rfc5583>. <https://www.rfc-editor.org/info/rfc5583>.
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184, Payload Format for H.264 Video", RFC 6184,
DOI 10.17487/RFC6184, May 2011, DOI 10.17487/RFC6184, May 2011,
<http://www.rfc-editor.org/info/rfc6184>. <https://www.rfc-editor.org/info/rfc6184>.
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis,
"RTP Payload Format for Scalable Video Coding", RFC 6190, "RTP Payload Format for Scalable Video Coding", RFC 6190,
DOI 10.17487/RFC6190, May 2011, DOI 10.17487/RFC6190, May 2011,
<http://www.rfc-editor.org/info/rfc6190>. <https://www.rfc-editor.org/info/rfc6190>.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", Attributes in the Session Description Protocol (SDP)",
RFC 6236, DOI 10.17487/RFC6236, May 2011, RFC 6236, DOI 10.17487/RFC6236, May 2011,
<http://www.rfc-editor.org/info/rfc6236>. <https://www.rfc-editor.org/info/rfc6236>.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011, DOI 10.17487/RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>. <https://www.rfc-editor.org/info/rfc6464>.
[RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping [RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
Semantics in the Session Description Protocol", RFC 7104, Semantics in the Session Description Protocol", RFC 7104,
DOI 10.17487/RFC7104, January 2014, DOI 10.17487/RFC7104, January 2014,
<http://www.rfc-editor.org/info/rfc7104>. <https://www.rfc-editor.org/info/rfc7104>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <https://www.rfc-editor.org/info/rfc7656>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015, DOI 10.17487/RFC7667, November 2015,
<http://www.rfc-editor.org/info/rfc7667>. <https://www.rfc-editor.org/info/rfc7667>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", RFC 7741, Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
DOI 10.17487/RFC7741, March 2016, DOI 10.17487/RFC7741, March 2016,
<http://www.rfc-editor.org/info/rfc7741>. <https://www.rfc-editor.org/info/rfc7741>.
[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
RFC 8108, DOI 10.17487/RFC8108, March 2017, RFC 8108, DOI 10.17487/RFC8108, March 2017,
<http://www.rfc-editor.org/info/rfc8108>. <https://www.rfc-editor.org/info/rfc8108>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017,
<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 have to be met to support the use cases
(Section 3): (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
skipping to change at page 33, line 29 skipping to change at page 35, line 37
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 -09 and -10 B.1. Modifications Between WG Version -10 and -11
o Added new SDP example section on Simulcast and Redundancy,
including both RED (RFC2198), RTP RTX (RFC4588), and FEC (draft-
ietf-payload-flexible-fec-scheme).
o Removed restriction that "related" payload formats in an RTP
stream (such as CN and DTMF) must not have their own rid-id, since
there is no reason to forbid this and corresponding clarification
is made in draft-ietf-mmusic-rid.
o Removed any mention of source-specific signaling and the reference
to RFC5576, since draft-ietf-mmusic-rid is not defined for source-
specific signaling.
o Changed some SDP examples to use a=rid restrictions instead of
a=imageattr.
o Changed reference from the obsoleted RFC 5285 to RFC 8285.
B.2. 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.2. Modifications Between WG Version -08 and -09 B.3. 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 34, line 13 skipping to change at page 36, line 42
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.3. Modifications Between WG Version -07 and -08 B.4. 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.4. Modifications Between WG Version -06 and -07 B.5. 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.5. Modifications Between WG Version -05 and -06 B.6. 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.6. Modifications Between WG Version -04 and -05 B.7. 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 35, line 39 skipping to change at page 38, 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.7. Modifications Between WG Version -03 and -04 B.8. 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.8. Modifications Between WG Version -02 and -03 B.9. 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.9. Modifications Between WG Version -01 and -02 B.10. 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.10. Modifications Between WG Version -00 and -01 B.11. Modifications Between WG Version -00 and -01
o No changes. Only preventing expiry. o No changes. Only preventing expiry.
B.11. Modifications Between Individual Version -00 and WG Version -00 B.12. 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. 61 change blocks. 
129 lines changed or deleted 204 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/