draft-ietf-mmusic-sdp-simulcast-02.txt   draft-ietf-mmusic-sdp-simulcast-03.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: April 8, 2016 S. Nandakumar Expires: April 21, 2016 S. Nandakumar
M. Zanaty M. Zanaty
Cisco Cisco
October 6, 2015 October 19, 2015
Using Simulcast in SDP and RTP Sessions Using Simulcast in SDP and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-02 draft-ietf-mmusic-sdp-simulcast-03
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 discusses the RTP streams. This is called simulcast. This document discusses the
best way of accomplishing simulcast in RTP and how to signal it in best way of accomplishing simulcast in RTP and how to signal it in
SDP. A solution is defined by making an extension to SDP, and using SDP. A solution is defined by making an extension to SDP, and using
RTP/RTCP identification methods to relate RTP streams belonging to RTP/RTCP identification methods to relate RTP streams belonging to
the same media source. The SDP extension consists of a new media the same media source. The SDP extension consists of a new media
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 8, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 5 3.1. Reaching a Diverse Set of Receivers . . . . . . . . . . . 5
3.2. Application Specific Media Source Handling . . . . . . . 6 3.2. Application Specific Media Source Handling . . . . . . . 6
3.3. Receiver Adaptation in Multicast/Broadcast . . . . . . . 7 3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7
3.4. Receiver Media Source Preferences . . . . . . . . . . . . 8 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Detailed Description . . . . . . . . . . . . . . . . . . . . 9
6. Detailed Description . . . . . . . . . . . . . . . . . . . . 10 6.1. Simulcast Capability . . . . . . . . . . . . . . . . . . 9
6.1. Simulcast Capability . . . . . . . . . . . . . . . . . . 10 6.1.1. Declarative Use . . . . . . . . . . . . . . . . . . . 11
6.1.1. Declarative Use . . . . . . . . . . . . . . . . . . . 12
6.1.2. Offer/Answer Use . . . . . . . . . . . . . . . . . . 12 6.1.2. Offer/Answer Use . . . . . . . . . . . . . . . . . . 12
6.2. Relating Simulcast Streams . . . . . . . . . . . . . . . 14 6.2. Relating Simulcast Streams . . . . . . . . . . . . . . . 14
6.3. Signaling Examples . . . . . . . . . . . . . . . . . . . 14 6.3. Signaling Examples . . . . . . . . . . . . . . . . . . . 14
6.3.1. Unified Plan Client . . . . . . . . . . . . . . . . . 15 6.3.1. Unified Plan Client . . . . . . . . . . . . . . . . . 14
6.3.2. Multi-Source Client . . . . . . . . . . . . . . . . . 16 6.3.2. Multi-Source Client . . . . . . . . . . . . . . . . . 16
7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 18 7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8.1. Single RTP Session . . . . . . . . . . . . . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2. SDP Format Identification . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8.3. RID Identification . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 23 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 23
A.1. Modifications Between WG Version -01 and -02 . . . . . . 23 A.1. Modifications Between WG Version -02 and -03 . . . . . . 23
A.2. Modifications Between WG Version -00 and -01 . . . . . . 23 A.2. Modifications Between WG Version -01 and -02 . . . . . . 24
A.3. Modifications Between Individual Version -00 and WG A.3. Modifications Between WG Version -00 and -01 . . . . . . 24
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 23 A.4. Modifications Between Individual Version -00 and WG
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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).
skipping to change at page 3, line 24 skipping to change at page 3, line 26
different participants' constraints with the minimum possible impact different participants' constraints with the minimum possible impact
on both video quality and server performance. on both video quality and server performance.
Simulcast is defined in this memo as the act of simultaneously Simulcast is defined in this memo as the act of simultaneously
sending multiple different encoded streams of the same media source, sending multiple different encoded streams of the same media source,
e.g. the same video source encoded with different video encoder types e.g. the same video source encoded with different video encoder types
or image resolutions. This can be done in several ways and for or image resolutions. This can be done in several ways and for
different purposes. This document focuses on the case where it is different purposes. This document focuses on the case where it is
desirable to provide a media source as multiple encoded streams over desirable to provide a media source as multiple encoded streams over
RTP [RFC3550] towards an intermediary so that the intermediary can RTP [RFC3550] towards an intermediary so that the intermediary can
provide the wanted functionality by selecting which RTP stream to provide the wanted functionality by selecting which RTP stream(s) to
forward to other participants in the session, and more specifically forward to other participants in the session, and more specifically
how the identification and grouping of the involved RTP streams are how the identification and grouping of the involved RTP streams are
done. From an RTP perspective, simulcast is a specific application done. From an RTP perspective, simulcast is a specific application
of the aspects discussed in RTP Multiplexing Guidelines of the aspects discussed in RTP Multiplexing Guidelines
[I-D.ietf-avtcore-multiplex-guidelines]. [I-D.ietf-avtcore-multiplex-guidelines].
This document describes a few scenarios where it is motivated to use This document describes a few scenarios where it is motivated to use
simulcast, and also defines the needed SDP signaling for it. simulcast, and also defines the needed SDP signaling for it.
2. Definitions 2. Definitions
skipping to change at page 5, line 20 skipping to change at page 5, line 23
this approach are that it is computationally cheap to the RTP this approach are that it is computationally cheap to the RTP
Mixer and it has very limited impact on media QoE. The main Mixer and it has very limited impact on media QoE. The main
disadvantage is that it can be difficult to combine a subset of disadvantage is that it can be difficult to combine a subset of
received RTP streams into a perfect fit to the resource situation received RTP streams into a perfect fit to the resource situation
of a receiving participant. of a receiving participant.
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.
A multicast/broadcast case where the receivers themselves selects the
most appropriate simulcast stream and tune in to the right media
transport to receive that stream is also considered (Section 3.3) .
This enables large, heterogeneous receiver populations, when it comes
to capabilities and the use of network path bandwidth resources.
3.1. Reaching a Diverse Set of Receivers 3.1. Reaching a Diverse Set of Receivers
The media sources provided by a sending participant potentially need The media sources provided by a sending participant potentially need
to reach several receiving participants that differ in terms of to reach several receiving participants that differ in terms of
available resources. The receiver resources that typically differ available resources. The receiver resources that typically differ
include, but are not limited to: include, but are not limited to:
Codec: This includes codec type (such as SDP MIME type) and can Codec: This includes codec type (such as SDP MIME type) and can
include codec configuration options (e.g. SDP fmtp parameters). include codec configuration options (e.g. SDP fmtp parameters).
A couple of codec resources that differ only in codec A couple of codec resources that differ only in codec
skipping to change at page 7, line 16 skipping to change at page 7, line 8
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). Not sending the active
speaker media back to itself means there is some other participant's speaker media back to itself means there is some other participant's
media that instead has to receive special handling towards the active media that instead has to receive special handling towards the active
speaker; typically the previous active speaker. This way, the speaker; typically the previous active speaker. This way, the
previously active speaker is needed both in larger size (to current previously active speaker is needed both in larger size (to current
active speaker) and in small size (to the rest of the participants), active speaker) and in small size (to the rest of the participants),
which can be solved with a simulcast from the previously active which can be solved with a simulcast from the previously active
speaker to the RTP switch. speaker to the RTP switch.
3.3. Receiver Adaptation in Multicast/Broadcast 3.3. Receiver Media Source Preferences
When using broadcast or multicast technology to distribute real-time
media streams to large populations of receivers, there can still be
significant heterogeneity among the receiver population. This can
depend on several factors:
Network Bandwidth: The network paths to individual receivers will
have variations in the bandwidth, thus putting different limits on
the supported bit-rates that can be received.
Endpoint Capabilities: The end point's hardware and software can
have varying capabilities in relation to screen resolution,
decoding capabilities, and supported media codecs.
To handle these variations, a transmitter of real-time media may want
to apply simulcast to a media source and provide it as a set of
different encoded streams, enabling the receivers to select the best
fit from this set themselves. The end point capabilities will
usually result in a single initial choice. However, the network
bandwidth can vary over time, which requires a client to continuously
monitor its reception to determine if the received RTP streams still
fit within the available bandwidth. If not, another set of encoded
streams from the ones offered in the simulcast will have to be
chosen.
When using IP multicast, the level of granularity that the receiver
can select from is decided by its ability to choose different
multicast addresses. Thus, different simulcast streams need to be
put on different media transports using different multicast
addresses. If these simulcast streams are described using SDP, they
need to be part of different SDP media descriptions, as SDP binds to
transport on media description level.
3.4. Receiver Media Source Preferences
The application logic that controls the communication session may The application logic that controls the communication session may
allow receiving participants to apply preferences to the allow receiving participants to apply preferences to the
characteristics of the RTP stream they receive, for example in terms characteristics of the RTP stream they receive, for example in terms
of the aspects listed in Section 3.1. Sending a simulcast of RTP of the aspects listed in Section 3.1. Sending a simulcast of RTP
streams is one way of accommodating receivers with conflicting or streams is one way of accommodating receivers with conflicting or
otherwise incompatible preferences. otherwise incompatible preferences.
4. Requirements 4. Requirements
skipping to change at page 9, line 41 skipping to change at page 8, line 44
capability and configurations in SDP [RFC4566]: capability and configurations in SDP [RFC4566]:
o An offer or answer can contain a number of simulcast streams, o An offer or answer can contain a number of simulcast streams,
separate for send and receive directions. separate for send and receive directions.
o An offer or answer can contain multiple, alternative simulcast o An offer or answer can contain multiple, alternative simulcast
streams in the same fashion as multiple, alternative codecs can be streams in the same fashion as multiple, alternative codecs can be
offered in a media description. offered in a media description.
o A single media source per SDP media description is assumed, which o A single media source per SDP media description is assumed, which
makes the solution work in an Unified Plan is aligned with the concepts defined in
[I-D.roach-mmusic-unified-plan] context (although different from [I-D.ietf-avtext-rtp-grouping-taxonomy] and will specifically work
what is currently defined there), both with and without BUNDLE in a WebRTC context, both with and without BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation] grouping. This is also [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping.
aligned with the concepts defined in
[I-D.ietf-avtext-rtp-grouping-taxonomy].
o The codec configuration for each simulcast stream is expressed in o The codec configuration for a simulcast stream can be expressed in
terms of existing SDP formats (and typically RTP payload types). two alternative ways, with complementing drawbacks and benefits:
Some codecs may rely on codec configuration based on general
attributes that apply for all formats within a media description, * Through existing SDP formats (corresponding to RTP payload
and which could thus not be used to separate different simulcast types), enabling the use of simulcast with a minimum set of
streams. When many different media formats and/or simulcast additions to existing SDP specifications.
streams are used in the SDP, the available RTP payload type number
space may not be sufficient. This can be particularly prominent * Through use of a separately specified RTP-level identification
when BUNDLE is used. To mitigate those limitations, this memo mechanism [I-D.pthatcher-mmusic-rid], which complements and
also allows optional use of a separately specified RTP-level effectively extends the available simulcast stream
identification mechanism [I-D.pthatcher-mmusic-rid], which identification and configuration possibilities provided by
complements and effectively extends the available simulcast stream using SDP formats.
identification number space. This also specifies a number of
codec agnostic constraint attributes that may be used to define
simulcast streams.
o It is possible, but not required to use source-specific signaling o It is possible, but not required to use source-specific signaling
[RFC5576] with the proposed solution. [RFC5576] with the proposed solution.
6. Detailed Description 6. Detailed Description
This section further details the overview above (Section 5). This section further details the overview above (Section 5).
6.1. Simulcast Capability 6.1. Simulcast Capability
Simulcast capability is expressed as a new media level SDP attribute, Simulcast capability is expressed as a new media level SDP attribute,
"a=simulcast". For each desired direction (send/recv/sendrecv), the "a=simulcast". For each desired direction (send/recv), the simulcast
simulcast attribute defines a list of simulcast streams (separated by attribute defines a list of simulcast streams (separated by
semicolons), each of which is a list of simulcast formats (separated semicolons), each of which is a list of simulcast formats (separated
by commas). The meaning of the attribute on SDP session level is by commas). The meaning of the attribute on SDP session level is
undefined and MUST NOT be used. There MUST NOT be more than one undefined and MUST NOT be used. The ABNF [RFC5234] for this
"a=simulcast" attribute per media description. The ABNF [RFC5234] attribute is:
for this attribute is:
sc-attr = "a=simulcast:" 1*3( WSP sc-dir-list ) sc-attr = "a=simulcast:" 1*2( WSP sc-str-list ) [WSP sc-pause-list]
sc-dir-list = sc-dir WSP sc-id-type "=" sc-alt-list *( ";" sc-alt-list ) sc-str-list = sc-dir WSP sc-id-type "=" sc-alt-list *( ";" sc-alt-list )
sc-dir = "send" / "recv" / "sendrecv" sc-pause-list = "paused=" sc-alt-list
sc-dir = "send" / "recv"
sc-id-type = "pt" / "rid" / token sc-id-type = "pt" / "rid" / token
sc-alt-list = sc-id *( "," sc-id ) sc-alt-list = sc-id *( "," sc-id )
sc-id = fmt / rid-value / token sc-id = fmt / rid-identifier / token
; WSP defined in [RFC5234] ; WSP defined in [RFC5234]
; fmt, token defined in [RFC4566] ; fmt, token defined in [RFC4566]
; rid-value defined in [I-D.pthatcher-mmusic-rid] ; rid-identifier defined in [I-D.pthatcher-mmusic-rid]
Figure 1: ABNF for Simulcast Figure 1: ABNF for Simulcast
There are separate and independent sets of parameters for simulcast There are separate and independent sets of parameters for simulcast
in send and receive directions. When listing multiple directions, in send and receive directions. When listing multiple directions,
each direction MUST NOT occur more than once on the same line. each direction MUST NOT occur more than once on the same line.
Two simulcast stream identification methods are defined; "pt" using Two simulcast stream identification methods are defined; "pt" using
RTP payload type (SDP format), and "rid" using an additional RTP- RTP payload type (SDP format), and "rid" using an additional RTP-
level identification mechanism [I-D.pthatcher-mmusic-rid]. level identification mechanism [I-D.pthatcher-mmusic-rid]. Different
identification methods MUST NOT be used for different directions on a
single "a=simulcast" line. Implementations that support both
identification methods MAY include one "a=simulcast" line for each
identification method for the same "m="-line. Multiple "a=simulcast"
lines with the same identification method MUST NOT be used for a
single "m="-line.
Attribute parameters are grouped by direction and consist of a Attribute parameters are grouped by direction and consist of a
listing of simulcast stream identifications to be used. The number listing of simulcast stream identifications to be used. The number
of (non-alternative, see below) identifications in the list sets a of (non-alternative, see below) identifications in the list sets a
limit to the number of supported simulcast streams in that direction. limit to the number of supported simulcast streams in that direction.
Simulcast stream identifications present in "sendrecv" direction MUST The order of the listed simulcast versions in the "send" direction
NOT be present also in "send" or "recv" directions, since the meaning suggests a proposed order of preference, in decreasing order: the
of that would be ambiguous. The order of the listed simulcast stream listed first is the most preferred Section 3.1, and subsequent
streams in the "send" direction is not significant. The order of the streams have progressively lower preference. The order of the listed
listed simulcast streams in the "recv" direction expresses a simulcast streams in the "recv" direction expresses a preference
preference which simulcast streams that are preferred, with the which simulcast streams that are preferred, with the leftmost being
leftmost being most preferred. This can be of importance if the most preferred. This can be of importance if the number of actually
number of actually sent simulcast streams have to be reduced for some sent simulcast streams have to be reduced for some reason.
reason.
Editor's note: Consider to remove the sendrecv definitions, as
they don't match PTs and RIDs unidirectionality.
Formats that have explicit dependencies [RFC5583] Formats that have explicit dependencies [RFC5583]
[I-D.pthatcher-mmusic-rid] to other formats (even in the same media [I-D.pthatcher-mmusic-rid] to other formats (even in the same media
description) MAY be listed as different simulcast streams. description) MAY be listed as different simulcast streams.
Alternative simulcast formats MAY be specified as part of the Alternative simulcast formats MAY be specified as part of the
attribute parameters by expressing each simulcast stream as a comma- attribute parameters by expressing each simulcast stream as a comma-
separated list of alternative format identifiers. In this case, separated list of alternative format identifiers. In this case,
there MUST NOT be any capability restriction in what alternatives can there MUST NOT be any capability restriction in what alternative
be used across different simulcast streams, like requiring all formats can be used across different simulcast streams, like
simulcast streams to use the same codec alternative. The order of requiring all simulcast streams to use the same codec format
the alternatives within a simulcast stream is significant; the alternative. The order of the format alternatives within a simulcast
alternatives are listed from (left) most preferred to (right) least stream is significant; the alternatives are listed from (left) most
preferred. For the use of simulcast, this overrides the normal codec preferred to (right) least preferred. For the use of simulcast, this
preference as expressed by format type ordering on the m-line, using overrides the normal codec preference as expressed by format type
regular SDP rules. This is to enable a separation of general codec ordering on the "m="-line, using regular SDP rules. This is to
preferences and simulcast stream codec preferences. enable a separation of general 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. In those cases, such "related" formats MUST NOT
be listed explicitly in the attribute parameters, since they are not be listed explicitly in the attribute parameters, since they are not
strictly simulcast streams of the media source, but rather a specific strictly simulcast streams of the media source, but rather a specific
way of generating the RTP stream of a single simulcast stream with way of generating the RTP stream of a single simulcast stream with
varying RTP payload type. Instead, only a single simulcast stream varying RTP payload type. Instead, only a single simulcast stream
identification MUST be used per simulcast stream or alternative identification MUST be used per simulcast stream or alternative
simulcast format (if there are such) in the SDP. The used simulcast simulcast format (if there are such) in the SDP. The used simulcast
stream identification SHOULD be the codec format most relevant to the stream identification SHOULD be the codec format most relevant to the
media description, if possible to identify, for example the audio media description, if possible to identify, for example the audio
codec rather than the DTMF. What codec format to choose in the case codec rather than the DTMF. What codec format to choose in the case
of switching between multiple equally "important" formats is left of switching between multiple equally "important" formats is left
open, but it is assumed that in the presence of such strong relation open, but it is assumed that in the presence of such strong relation
it does not matter which is chosen. it does not matter which is chosen.
If RTP stream pause/resume [I-D.ietf-avtext-rtp-stream-pause] is
supported, the optional "paused=" parameter MAY be used in
conjunction with "rid" simulcast stream identification to specify
that a certain simulcast stream is initially paused already from
start of the RTP session. In this case, support for RTP stream
pause/resume MUST also be included under the same "m="-line listing
"a=simulcast". Initially paused simulcast streams MUST NOT be used
with "pt" identification. Initially paused simulcast streams are
resumed as described by the RTP pause/resume specification.
An initially paused simulcast stream in "send" direction MUST be
considered equivalent to an unsolicited locally paused stream, and be
handled accordingly.
An initially paused simulcast stream in "recv" direction SHOULD cause
the remote RTP sender to put the stream as unsolicited locally
paused, unless there are other RTP stream receivers that do not mark
the simulcast stream as initially paused. The reason to require an
initially paused "recv" stream to be considered locally paused by the
remote RTP sender, instead of making it equivalent to implicitly
sending a pause request, is because the pausing RTP sender cannot
know which SSRC owns the restriction when TMMBR/TMMBN are used for
pause/resume signaling since the RTP receiver's SSRC in send
direction is not known yet.
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.
Editor's note: Consider adding the possibility to put an RTP
stream in "paused" state [I-D.ietf-avtext-rtp-stream-pause] from
the beginning of the session, possibly starting it at a later
point in time by applying RTP/RTCP level procedures from that
specification.
6.1.1. Declarative Use 6.1.1. Declarative Use
When used as a declarative media description, a=simulcast "recv" When used as a declarative media description, a=simulcast "recv"
direction formats indicates the configured end point's required direction formats indicates the configured end point's required
capability to recognize and receive a specified set of RTP streams as capability to recognize and receive a specified set of RTP streams as
simulcast streams. In the same fashion, a=simulcast "send" direction simulcast streams. In the same fashion, a=simulcast "send" direction
requests the end point to send a specified set of RTP streams as requests the end point to send a specified set of RTP streams as
simulcast streams. The "sendrecv" direction combines "send" and simulcast streams.
"recv" requirements, using the same format values for both.
If multiple simulcast formats are listed, it means that the If multiple simulcast formats are listed, it means that the
configured end point MUST be prepared to receive any of the "recv" configured end point MUST be prepared to receive any of the "recv"
formats, and MAY send any of the "send" formats for that simulcast formats, and MAY send any of the "send" formats for that simulcast
stream. stream.
Editor's note: The external RTP identification mechanism currently Editor's note: The RID identification mechanism currently lacks a
lacks a declarative use definition. As declarative use may also declarative use definition. As declarative use may also not
not follow unified plan with a single media source per m= line, it follow unified plan with a single media source per '"m="-line, it
is uncertain if declarative can be defined for the mechanism in is uncertain if declarative can be defined for the mechanism in
its current shape. its current shape.
6.1.2. Offer/Answer Use 6.1.2. Offer/Answer Use
An offerer wanting to use simulcast SHALL include the "a=simulcast" An offerer wanting to use simulcast SHALL include the "a=simulcast"
attribute in the offer. An offerer that receives an answer without attribute in the offer. An offerer that receives an answer without
"a=simulcast" MUST NOT use simulcast towards the answerer. An "a=simulcast" MUST NOT use simulcast towards the answerer. An
offerer that receives an answer with "a=simulcast" not listing a offerer that receives an answer with "a=simulcast" not listing a
direction or without any simulcast stream identifications in a direction or without any simulcast stream identifications in a
specified direction MUST NOT use simulcast in that direction. specified direction MUST NOT use simulcast in that direction.
An answerer that does not understand the concept of simulcast will An answerer that does not understand the concept of simulcast will
also not know the attribute and will remove it in the SDP answer, as also not know the attribute and will remove it in the SDP answer, as
defined in existing SDP Offer/Answer [RFC3264] procedures. An defined in existing SDP Offer/Answer [RFC3264] procedures.
answerer that does understand the attribute and that wants to support
simulcast in an indicated direction SHALL reverse directionality of An answerer that does understand the attribute and that wants to
the unidirectional direction parameters; "send" becomes "recv" and support simulcast in an indicated direction SHALL reverse
vice versa, and include it in the answer. If the offered direction directionality of the unidirectional direction parameters; "send"
is "sendrecv", the answerer MAY keep it, but MAY also change it to becomes "recv" and vice versa, and include it in the answer. Note
"send" or "recv" to indicate that it is only interested in simulcast that, like all other use of SDP format tags ("pt:") for the send
for a single direction. Note that, like all other use of SDP format direction in Offer/Answer, format tags related to the simulcast
tags ("pt:") for the send direction in Offer/Answer, format tags stream identification send direction in an offer are placeholders
related to the simulcast stream identification send direction in an that refer to information in the offer SDP, and the actual formats
offer ("send" or "sendrecv") are placeholders that refer to that will be used on the wire (including RTP Payload Format numbers)
information in the offer SDP, and the actual formats that will be depends on information included in the SDP answer.
used on the wire (including RTP Payload Format numbers) depends on
information included in the SDP answer.
An offerer listing a set of receive simulcast streams and/or An offerer listing a set of receive simulcast streams and/or
alternative formats in the offer MUST be prepared to receive RTP alternative formats in the offer MUST be prepared to receive RTP
streams for any of those simulcast streams and/or alternative formats streams for any of those simulcast streams and/or alternative formats
from the answerer. from the answerer.
An answerer that receives an offer with simulcast containing an An answerer that receives an offer with simulcast containing an
"a=simulcast" attribute listing alternative formats for simulcast "a=simulcast" attribute listing alternative formats for simulcast
streams MAY keep all the alternatives in the answer, but it MAY also streams MAY keep all the alternatives in the answer, but it MAY also
choose to remove any non-desirable alternatives per simulcast stream choose to remove any non-desirable alternatives per simulcast stream
skipping to change at page 14, line 5 skipping to change at page 13, line 21
alternatives, and MAY send any of the kept receive direction alternatives, and MAY send any of the kept receive direction
alternatives from the answer. Similarly, the answerer MUST be alternatives from the answer. Similarly, the answerer MUST be
prepared to receive any of the kept receive direction alternatives, prepared to receive any of the kept receive direction alternatives,
and MAY send any of the kept send direction alternatives in the and MAY send any of the kept send direction alternatives in the
answer. answer.
The offerer and answerer MUST NOT send more than a single alternative The offerer and answerer MUST NOT send more than a single alternative
format at a time (based on RTP timestamps) per simulcast stream, but format at a time (based on RTP timestamps) per simulcast stream, but
MAY change format on a per-RTP packet basis. This corresponds to the MAY change format on a per-RTP packet basis. This corresponds to the
existing (non-simulcast) SDP offer/answer case when multiple formats existing (non-simulcast) SDP offer/answer case when multiple formats
are included on the m-line in the SDP answer. are included on the "m="-line in the SDP answer.
An offerer that receives an answer where some of the simulcast An offerer that receives an answer where some of the simulcast
streams are removed MAY release the corresponding resources (codec, streams are removed MAY release the corresponding resources (codec,
transport, etc) in its receive direction and MUST NOT send any RTP transport, etc) in its receive direction and MUST NOT send any RTP
streams corresponding to the removed simulcast streams. streams corresponding to the removed simulcast streams.
Simulcast streams or formats using undefined simulcast stream Simulcast streams or formats using undefined simulcast stream
identifications MUST NOT be used as valid simulcast streams by an RTP identifications MUST NOT be used as valid simulcast streams by an RTP
stream receiver. stream receiver.
An offerer that is capable of using both simulcast stream
identification methods MAY include one "a=simulcast" line per
identification method in the offer. Note that it is in general not
expected that the "pt" identification method will provide feature
parity with the "rid" method, and the different "a=simulcast" lines
can therefore express different use of simulcast functionality.
However, for some configurations the different identification methods
can be equivalent.
An answerer receiving an offer listing both simulcast stream
identification methods MUST choose only one and remove the other from
the answer. An answerer not supporting a simulcast stream
identification method in the offer MUST remove the non-supported
"a=simulcast" line from the answer, possibly falling back to not
using simulcast at all.
The media formats and corresponding characteristics of encoded The media formats and corresponding characteristics of encoded
streams used in a simulcast SHOULD be chosen such that they are streams used in a simulcast SHOULD be chosen such that they are
different. If this difference is not required, RTP duplication different. If this difference is not required, RTP duplication
[RFC7104] procedures SHOULD be considered instead of simulcast. [RFC7104] procedures SHOULD be considered instead of simulcast.
Note: The inclusion of "a=simulcast" or the use of simulcast does Note: The inclusion of "a=simulcast" or the use of simulcast does
not change any of the interpretation or Offer/Answer procedures not change any of the interpretation or Offer/Answer procedures
for other SDP attributes, like "a=fmtp" or "a=rid". for other SDP attributes, like "a=fmtp" or "a=rid".
6.2. Relating Simulcast Streams 6.2. Relating Simulcast Streams
skipping to change at page 14, line 42 skipping to change at page 14, line 26
[I-D.ietf-mmusic-sdp-bundle-negotiation] with multiple SDP media [I-D.ietf-mmusic-sdp-bundle-negotiation] with multiple SDP media
descriptions to specify a single RTP session, there is an descriptions to specify a single RTP session, there is an
identification mechanism that allows relating RTP streams back to identification mechanism that allows relating RTP streams back to
individual media descriptions, after which the above RTP payload type individual media descriptions, after which the above RTP payload type
and RID relations can be used. and RID relations can be used.
BUNDLE's MID is an RTCP source description (SDES) item. To ensure BUNDLE's MID is an RTCP source description (SDES) item. To ensure
rapid initial reception, required to correctly process the RTP rapid initial reception, required to correctly process the RTP
streams, it is also defined as an RTP header extension [RFC5285]. streams, it is also defined as an RTP header extension [RFC5285].
Editor's note: Consider making RID an SDES item too, for the same
reasons as MID.
6.3. Signaling Examples 6.3. Signaling Examples
These examples describe a client to video conference service, using a These examples describe a client to video conference service, using a
centralized media topology with an RTP mixer. centralized media topology with an RTP mixer.
+---+ +-----------+ +---+ +---+ +-----------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Mixer | | Mixer |
+---+ | | +---+ +---+ | | +---+
skipping to change at page 16, line 31 skipping to change at page 16, line 13
Figure 4: Unified Plan Simulcast Answer Figure 4: Unified Plan 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" attribute parameters. direction of the "simulcast" attribute parameters.
6.3.2. Multi-Source Client 6.3.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
separate media sources in each direction, where each media source is separate media sources in each direction, where each media source is
simulcast-enabled in the send direction. Fred's client is a Unified simulcast-enabled in the send direction. Fred's client is restricted
Plan client, restricted to a single media source per media to a single media source per media description.
description.
The first two simulcast streams for the first media source use The first two simulcast streams for the first media source use
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 [I-D.ietf-payload-vp8] and H264, are offered as video codecs, VP8 [I-D.ietf-payload-vp8] and H264, are offered as
alternatives for the third simulcast stream for the first media alternatives for the third simulcast stream for the first media
source. RID is used as simulcast stream identification, reducing the source. RID is used as simulcast stream identification, reducing the
number of media formats needed. number of media formats needed. Only the highest fidelity simulcast
stream are sent from start, the lower 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]. RID is used as simulcast protected by RTP retransmission [RFC4588]. RID is used as simulcast
stream identification. stream identification. Also here, all but the 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, use of RID as simulcast stream identification enables use of example, use of RID as simulcast stream identification enables use of
a low number of RTP payload types. Note that the use of both BUNDLE a low number of RTP payload types. Note that the use of both BUNDLE
and RID recommends using the RTP header extension [RFC5285] for and RID recommends using the RTP header extension [RFC5285] for
carrying these fields. carrying these fields.
v=0 v=0
o=fred 238947129 823479223 IN IP4 192.0.2.125 o=fred 238947129 823479223 IN IP4 192.0.2.125
s=Offer from Simulcast Enabled Multi-Source Client s=Offer from Simulcast Enabled Multi-Source Client
t=0 0 t=0 0
c=IN IP4 192.0.2.125 c=IN IP4 192.0.2.125
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/AVP 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=108000; \
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=54000
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-fr=60;depend=2 a=rid:1 send pt=100;max-width=1280;max-height=720;max-fr=60;depend=2
a=rid:2 send pt=101 max-width=1280;max-height=720;max-fr=30 a=rid:2 send pt=101;max-width=1280;max-height=720;max-fr=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:rid a=extmap:2 urn:ietf:params:rtp-hdrext:rid
a=simulcast: send rid=1;2;4,3 a=rtcp-fb:* ccm pause nowait
a=simulcast: send rid=1;2;4,3 paused=2,3,4
m=video 49602 RTP/AVP 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:5 send pt=96 max-fs=921600;max-fr=30 a=rid:5 send pt=96;max-fs=921600;max-fr=30
a=rid:6 send pt=96 max-fs=614400;max-fr=15 a=rid:6 send pt=96;max-fs=614400;max-fr=15
a=rid:7 send pt=96 max-fs=230400;max-fr=30 a=rid:7 send pt=96;max-fs=230400;max-fr=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:rid a=extmap:2 urn:ietf:params:rtp-hdrext:rid
a=simulcast: send rid=6;5;7 a=rtcp-fb:* ccm pause nowait
a=simulcast: send rid=5;6;7 paused=6,7
Figure 5: Fred's Multi-Source Simulcast Offer Figure 5: Fred's Multi-Source Simulcast Offer
Note: Empty lines in the SDP above are added only for readability Note: Empty lines in the SDP above are added only for readability
and would not be present in an actual SDP. and would not be present in an actual SDP.
7. Network Aspects 7. Network Aspects
Simulcast is in this memo defined as the act of sending multiple Simulcast is in this memo defined as the act of sending multiple
alternative encoded streams of the same underlying media source. alternative encoded streams of the same underlying media source.
skipping to change at page 18, line 29 skipping to change at page 18, line 29
be found in [I-D.ietf-avtcore-rtp-multi-stream]. be found in [I-D.ietf-avtcore-rtp-multi-stream].
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 bit-rate
streams may be prioritized over higher bit-rate streams to streams may be prioritized over higher bit-rate streams to
minimize congestion or packet losses in the low bit-rate streams. minimize congestion or packet losses in the low bit-rate streams.
Thus, there is a benefit to use a simulcast solution that supports Thus, there is a benefit to use a simulcast solution that supports
QoS as good as possible. By separating simulcast streams into QoS as good as possible.
different RTP sessions and send those RTP sessions over different
media transports, a simulcast stream can be prioritized by
existing flow based QoS mechanisms. When using unicast, QoS
mechanisms based on individual packet marking are also feasible,
which do not require separation of simulcast streams into
different RTP sessions to apply different QoS. The proposed
solution can be extended to support this functionality with an
optional mid: prefix before the RTP payload types of a simulcast
stream, to describe simulcast across multiple media descriptions.
Editor's note: With the chosen approach, it is not possible to NAT/FW Traversal: Using multiple RTP sessions incurs more cost for
use different simulcast streams on different transports, so NAT/FW traversal unless they can re-use the same transport flow,
either that description should be removed, or the solution has which can be achieved by Multiplexing Negotiation Using SDP Port
to be amended to cater also for that case. Numbers [I-D.ietf-mmusic-sdp-bundle-negotiation].
NAT/FW Traversal: Using multiple RTP sessions will incur more cost 8. Limitations
for NAT/FW traversal unless they can re-use the same transport
flow, which can be achieved by either one of multiplexing multiple
RTP sessions on a single lower layer transport
[I-D.westerlund-avtcore-transport-multiplexing] or Multiplexing
Negotiation Using SDP Port Numbers
[I-D.ietf-mmusic-sdp-bundle-negotiation]. If flow based QoS with
any differentiation is desirable, the cost for additional
transport flows is likely necessary.
Multicast: Multiple RTP sessions will be required to enable The chosen approach has a few limitations that are described in this
combining simulcast with multicast. Different simulcast streams section. Some relate to the use of a single RTP session for all
have to be separated to different multicast groups to allow a simulcast formats of a media source, while others relate to the two
multicast receiver to pick the stream it wants, rather than different simulcast stream identification methods.
receive all of them. In this case, the only reasonable
implementation is to use different RTP sessions for each multicast
group so that reporting and other RTCP functions operate as
intended. The proposed solution can be extended to support this
functionality with an optional mid: prefix before the RTP payload
types of a simulcast stream, to describe simulcast across multiple
media descriptions.
Editor's note: As with QoS above, different simulcast streams on 8.1. Single RTP Session
different multicast groups are not possible with the chosen
approach, and text must be changed accordingly.
8. IANA Considerations The limitations in this section come from sending all simulcast
streams related to a media source under the same SDP media
description, which also means they are sent in the same RTP session.
It is not possible to use different simulcast streams on different
transports, limiting the possibilities to apply different QoS to
different simulcast streams. When using unicast, QoS mechanisms
based on individual packet marking are feasible, since they do not
require separation of simulcast streams into different RTP sessions
to apply different QoS.
It is not possible to separate different simulcast streams into
different multicast groups to allow a multicast receiver to pick the
stream it wants, rather than receive all of them. In this case, the
only reasonable implementation is to use different RTP sessions for
each multicast group so that reporting and other RTCP functions
operate as intended.
8.2. SDP Format Identification
The limitations in this section come from and thus apply only when
using SDP format (RTP payload type) as simulcast stream
identification method.
The available RTP payload type number space may not be sufficient
when many different media formats and/or simulcast streams are used
in the SDP. This can be particularly prominent when BUNDLE is used,
and for any technology that adds to the number of required RTP
payload types in a multiplicative way, such as for example adding RTP
retransmission [RFC4588] and Forward Error Correction [RFC5109].
Flexible FEC Scheme [I-D.ietf-payload-flexible-fec-scheme] can be
used for RTP retransmissions and would avoid the double consumption
of the PT space that RTP Retransmission [RFC4588] causes.
Only existing SDP attributes and parameters can be used to define
codec configuration for a simulcast format. Any codec that does not
define a sufficient set of codec parameters in "a=fmtp", or can make
use of other SDP attributes, may not be capable of expressing the
desired simulcast format dimensions (Section 3.1) with necessary
precision, or not at all. One example of this is the ability to
separate simulcast formats by bandwidth for codecs lacking a codec-
specific bandwidth parameter, since the SDP "b="-line covers all RTP
payload types listed on an "m="-line.
A simulcast stream signaled as initially paused is not possible to
resume by a remote peer, because it cannot know which target SSRC to
use in the RESUME message [I-D.ietf-avtext-rtp-stream-pause].
8.3. RID Identification
The limitations in this section come from and thus apply only when
using RID as simulcast stream identification method.
Use of the additional "a=rid"-line in SDP and the corresponding RID
RTCP SDES item and RTP header extension requires some additional
implementation complexity, and incurs some extra bandwidth cost to
carry the RID RTCP SDES item and RTP header extension.
9. IANA Considerations
This document requests to register a new SDP attribute, simulcast. This document requests to register a new SDP attribute, simulcast.
Formal registrations to be written. Formal registrations to be written.
9. Security Considerations 10. Security Considerations
The simulcast capability, configuration attributes and parameters are The simulcast capability, configuration attributes and parameters are
vulnerable to attacks in signaling. vulnerable to attacks in signaling.
A false inclusion of the "a=simulcast" attribute may result in A false inclusion of the "a=simulcast" attribute may result in
simultaneous transmission of multiple RTP streams that would simultaneous transmission of multiple RTP streams that would
otherwise not be generated. The impact is limited by the media otherwise not be generated. The impact is limited by the media
description joint bandwidth, shared by all simulcast streams description joint bandwidth, shared by all simulcast streams
irrespective of their number. There may however be a large number of irrespective of their number. There may however be a large number of
unwanted RTP streams that will impact the share of bandwidth unwanted RTP streams that will impact the share of bandwidth
allocated for the originally wanted RTP stream. allocated for the originally wanted RTP stream.
A hostile removal of the "a=simulcast" attribute will result in A hostile removal of the "a=simulcast" attribute will result in
simulcast not being used. simulcast not being used.
Neither of the above will likely have any major consequences and can Neither of the above will likely have any major consequences and can
be mitigated by signaling that is at least integrity and source be mitigated by signaling that is at least integrity and source
authenticated to prevent an attacker to change it. authenticated to prevent an attacker to change it.
10. Contributors 11. Contributors
Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have
contributed with important material to the first versions of this contributed with important material to the first versions of this
document. Robert Hansen and Cullen Jennings, from Cisco, and Peter document. Robert Hansen and Cullen Jennings, from Cisco, and Peter
Thatcher, from Google, contributed significantly to subsequent Thatcher, from Google, contributed significantly to subsequent
versions. versions.
11. Acknowledgements 12. Acknowledgements
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-avtext-rtp-stream-pause]
Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP
Stream Pause and Resume", draft-ietf-avtext-rtp-stream-
pause-10 (work in progress), September 2015.
[I-D.pthatcher-mmusic-rid] [I-D.pthatcher-mmusic-rid]
Thatcher, P., Zanaty, M., Nandakumar, S., Roach, A., Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B.,
Burman, B., and B. Campen, "RTP Payload Format Roach, A., and B. Campen, "RTP Payload Format
Constraints", draft-pthatcher-mmusic-rid-00 (work in Constraints", draft-pthatcher-mmusic-rid-02 (work in
progress), October 2015. progress), October 2015.
[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>. <http://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,
skipping to change at page 21, line 5 skipping to change at page 21, line 39
[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>. <http://www.rfc-editor.org/info/rfc5234>.
[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>. <http://www.rfc-editor.org/info/rfc7104>.
12.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., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to "Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore- Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-03 (work in progress), October 2014. multiplex-guidelines-03 (work in progress), October 2014.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple Media Streams in a Single RTP Session",
skipping to change at page 21, line 31 skipping to change at page 22, line 17
ietf-avtcore-rtp-topologies-update-10 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
July 2015. July 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015. 2015.
[I-D.ietf-avtext-rtp-stream-pause]
Burman, B., Akram, A., Even, R., and M. Westerlund, "RTP
Stream Pause and Resume", draft-ietf-avtext-rtp-stream-
pause-10 (work in progress), September 2015.
[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-23 (work in progress), July 2015. negotiation-23 (work in progress), July 2015.
[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-01 (work in
progress), October 2015.
[I-D.ietf-payload-vp8] [I-D.ietf-payload-vp8]
Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", draft-ietf- Galligan, "RTP Payload Format for VP8 Video", draft-ietf-
payload-vp8-17 (work in progress), September 2015. payload-vp8-17 (work in progress), September 2015.
[I-D.roach-mmusic-unified-plan]
Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for
Using SDP with Large Numbers of Media Flows", draft-roach-
mmusic-unified-plan-00 (work in progress), July 2013.
[I-D.westerlund-avtcore-transport-multiplexing]
Westerlund, M. and C. Perkins, "Multiplexing Multiple RTP
Sessions onto a Single Lower-Layer Transport", draft-
westerlund-avtcore-transport-multiplexing-07 (work in
progress), October 2013.
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc3264>.
skipping to change at page 23, line 24 skipping to change at page 23, line 47
[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>. <http://www.rfc-editor.org/info/rfc6236>.
Appendix A. Changes From Earlier Versions Appendix A. 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.
A.1. Modifications Between WG Version -01 and -02 A.1. Modifications Between WG Version -02 and -03
o Removed text on multicast / broadcast from use cases, since it is
not supported by the solution.
o Removed explicit references to unified plan draft.
o Added possibility to initiate simulcast streams in paused mode.
o Enabled an offerer to offer multiple stream identification (pt or
rid) methods and have the answerer choose which to use.
o Added a preference indication also in send direction offers.
o Added a section on limitations of the current proposal, including
identification method specific limitations.
A.2. 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.
A.2. Modifications Between WG Version -00 and -01 A.3. Modifications Between WG Version -00 and -01
o No changes. Only preventing expiry. o No changes. Only preventing expiry.
A.3. Modifications Between Individual Version -00 and WG Version -00 A.4. 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
Kistavagen 25 Kistavagen 25
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
 End of changes. 57 change blocks. 
229 lines changed or deleted 269 lines changed or added

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