draft-ietf-mmusic-sdp-simulcast-05.txt   draft-ietf-mmusic-sdp-simulcast-06.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: December 31, 2016 S. Nandakumar Expires: May 4, 2017 S. Nandakumar
M. Zanaty M. Zanaty
Cisco Cisco
June 29, 2016 October 31, 2016
Using Simulcast in SDP and RTP Sessions Using Simulcast in SDP and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-05 draft-ietf-mmusic-sdp-simulcast-06
Abstract Abstract
In some application scenarios it may be desirable to send multiple In some application scenarios it may be desirable to send multiple
differently encoded versions of the same media source in different differently encoded versions of the same media source in different
RTP streams. This is called simulcast. This document describes how RTP streams. This is called simulcast. This document describes how
to accomplish simulcast in RTP and how to signal it in SDP. The to accomplish simulcast in RTP and how to signal it in SDP. The
described solution uses an RTP/RTCP identification method to identify described solution uses an RTP/RTCP identification method to identify
RTP streams belonging to the same media source, and makes an RTP streams belonging to the same media source, and makes an
extension to SDP to relate those RTP streams as being different extension to SDP to relate those RTP streams as being different
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2016. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . 7
3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7 3.3. Receiver Media Source Preferences . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Detailed Description . . . . . . . . . . . . . . . . . . . . 9 6. Detailed Description . . . . . . . . . . . . . . . . . . . . 9
6.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 9 6.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 9
6.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 6.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11
6.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13 6.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13
6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13 6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13
6.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 13 6.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 14
6.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 14 6.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 15
6.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15 6.3.4. Modifying the Session . . . . . . . . . . . . . . . . 15
6.4. Declarative Use . . . . . . . . . . . . . . . . . . . . . 15 6.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 15
6.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 15 6.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16
6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16
6.6.1. Single-Source Client . . . . . . . . . . . . . . . . 16 6.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17
6.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 6.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18
7. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 21 7. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 21 7.1. Outgoing from Endpoint with Media Source . . . . . . . . 21
8. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 9. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
A.1. Modifications Between WG Version -04 and -05 . . . . . . 26 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
A.2. Modifications Between WG Version -03 and -04 . . . . . . 27 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
A.3. Modifications Between WG Version -02 and -03 . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
A.4. Modifications Between WG Version -01 and -02 . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
A.5. Modifications Between WG Version -00 and -01 . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . 29
A.6. Modifications Between Individual Version -00 and WG Appendix A. Changes From Earlier Versions . . . . . . . . . . . 31
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 28 A.1. Modifications Between WG Version -05 and -06 . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 A.2. Modifications Between WG Version -04 and -05 . . . . . . 32
A.3. Modifications Between WG Version -03 and -04 . . . . . . 32
A.4. Modifications Between WG Version -02 and -03 . . . . . . 33
A.5. Modifications Between WG Version -01 and -02 . . . . . . 33
A.6. Modifications Between WG Version -00 and -01 . . . . . . 34
A.7. Modifications Between Individual Version -00 and WG
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 3, line 40 skipping to change at page 4, line 4
provide the wanted functionality by selecting which RTP stream(s) 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. done.
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 RTP/RTCP and SDP signaling for simulcast, and also defines the needed RTP/RTCP and SDP signaling for
it. it.
2. Definitions 2. Definitions
2.1. Terminology 2.1. Terminology
This document makes use of the terminology defined in RTP Taxonomy This document makes use of the terminology defined in RTP Taxonomy
[RFC7656], and RTP Topologies [RFC7667]. In addition, the following [RFC7656], and RTP Topologies [RFC7667]. The following terms are
terms are used: especially noted or here defined:
RTP Mixer: An RTP middle node, defined in [RFC7667] (Section 3.6 to RTP Mixer: An RTP middle node, defined in [RFC7667] (Section 3.6 to
3.9). 3.9).
RTP Switch: A common short term for the terms "switching RTP mixer", RTP Switch: A common short term for the terms "switching RTP mixer",
"source projecting middlebox", and "video switching MCU" as "source projecting middlebox", and "video switching MCU" as
discussed in [RFC7667]. discussed in [RFC7667].
Simulcast Stream: One encoded stream or dependent stream from a set Simulcast Stream: One encoded stream or dependent stream from a set
of concurrently transmitted encoded streams and optional dependent of concurrently transmitted encoded streams and optional dependent
streams, all sharing a common media source, as defined in streams, all sharing a common media source, as defined in
[RFC7656]. Decoding a dependent stream also requires the related [RFC7656]. For example, HD and thumbnail video simulcast versions
(dependent and) encoded stream(s), but in the context of simulcast of a single media source sent concurrently as separate RTP
that is considered a property of the dependent stream constituting Streams.
the simulcast stream. For example, HD and thumbnail video
simulcast versions of a single media source sent concurrently as
separate RTP Streams.
Simulcast Format: Different formats of a simulcast stream serve the Simulcast Format: Different formats of a simulcast stream serve the
same purpose as alternative RTP payload types in non-simulcast same purpose as alternative RTP payload types in non-simulcast
SDP, to allow multiple alternative media formats for a given RTP SDP: to allow multiple alternative media formats for a given RTP
stream. As for multiple RTP payload types on the m-line in offer/ stream. As for multiple RTP payload types on the m-line in offer/
answer [RFC3264], any one of the negotiated alternative formats answer [RFC3264], any one of the negotiated alternative formats
can be used in a single RTP stream at a given point in time, but can be used in a single RTP stream at a given point in time, but
not more than one (based on RTP timestamp). What format is used not more than one (based on RTP timestamp). What format is used
can change dynamically from one RTP packet to another. can change dynamically from one RTP packet to another.
Simulcast Stream Identifier (SCID): The identification value used to Simulcast Stream Identifier (SCID): The identification value used to
refer to individual simulcast streams, identical to the "rid-id" refer to an individual simulcast format, identical to the "rid-id"
identification value for an RTP Constraint [I-D.ietf-mmusic-rid] identification value for an RTP Payload Format Restriction
and the corresponding content of "RtpStreamId" RTCP SDES Item [I-D.ietf-mmusic-rid] and the corresponding content of
[I-D.ietf-avtext-rid]. "RtpStreamId" RTCP SDES Item [I-D.ietf-avtext-rid].
2.2. Requirements Language 2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Use Cases 3. Use Cases
Many use cases of simulcast as described in this document relate to a Many use cases of simulcast as described in this document relate to a
skipping to change at page 5, line 12 skipping to change at page 5, line 18
adapted view of the communication session to each receiving adapted view of the communication session to each receiving
participant: participant:
o Transcoding (decoding and re-encoding) received RTP streams with o Transcoding (decoding and re-encoding) received RTP streams with
characteristics adapted to each receiving participant. This often characteristics adapted to each receiving participant. This often
include mixing or composition of media sources from multiple include mixing or composition of media sources from multiple
participants into a mixed media source originated by the RTP participants into a mixed media source originated by the RTP
Mixer. The main advantage of this approach is that it achieves Mixer. The main advantage of this approach is that it achieves
close to optimal adaptation to individual receiving participants. close to optimal adaptation to individual receiving participants.
The main disadvantages are that it can be very computationally The main disadvantages are that it can be very computationally
expensive to the RTP Mixer and typically also degrades media expensive to the RTP Mixer, typically degrades media Quality of
Quality of Experience (QoE) such as end-to-end delay for the Experience (QoE) such as end-to-end delay for the receiving
receiving participants. participants, and requires RTP Mixer access to media content.
o Switching a subset of all received RTP streams or sub-streams to o Switching a subset of all received RTP streams or sub-streams to
each receiving participant, where the used subset is typically each receiving participant, where the used subset is typically
specific to each receiving participant. The main advantages of specific to each receiving participant. The main advantages of
this approach are that it is computationally cheap to the RTP this approach are that it is computationally cheap to the RTP
Mixer and it has very limited impact on media QoE. The main Mixer, has very limited impact on media QoE, and does not require
disadvantage is that it can be difficult to combine a subset of RTP Mixer (full) access to media content. The main disadvantage
received RTP streams into a perfect fit to the resource situation is that it can be difficult to combine a subset of received RTP
of a receiving participant. streams into a perfect fit to the resource situation 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.
3.1. Reaching a Diverse Set of Receivers 3.1. Reaching a Diverse Set of Receivers
The media sources provided by a sending participant potentially need The media sources provided by a sending participant potentially need
to reach several receiving participants that differ in terms of to reach several receiving participants that differ in terms of
available resources. The receiver resources that typically differ available resources. The receiver resources that typically differ
skipping to change at page 6, line 48 skipping to change at page 7, line 8
of the RTP switch to negotiate a good fit of simulcast streams with of the RTP switch to negotiate a good fit of simulcast streams with
the sending participant. the sending participant.
The maximum number of simulcasted RTP streams that can be sent is The maximum number of simulcasted RTP streams that can be sent is
mainly limited by the amount of processing and uplink network mainly limited by the amount of processing and uplink network
resources available to the sending participant. resources available to the sending participant.
3.2. Application Specific Media Source Handling 3.2. Application Specific Media Source Handling
The application logic that controls the communication session may The application logic that controls the communication session may
include special handling of some media sources. It is for example include special handling of some media sources. It is, for example,
commonly the case that the media from a sending participant is not commonly the case that the media from a sending participant is not
sent back to itself. sent back to itself.
It is also common that a currently active speaker participant is It is also common that a currently active speaker participant is
shown in larger size or higher quality than other participants (the shown in larger size or higher quality than other participants (the
sampling or bitrate aspects of Section 3.1). Not sending the active sampling or bitrate aspects of Section 3.1). 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
skipping to change at page 7, line 30 skipping to change at page 7, line 37
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
The following requirements need to be met to support the use cases in The following requirements need to be met to support the use cases in
previous sections: previous sections:
Editor's note: Consider adding an explicit requirement that the
solution supports use of simulcast even when using multiple codecs
and multiple redundant RTP streams per defined codec (or something
similar), since this is really an existing requirement and should
also fully motivate the use of RID as identification mechanism.
REQ-1: Identification. It must be possible to identify a set of REQ-1: Identification. It must be possible to identify a set of
simulcasted RTP streams as originating from the same media source: simulcasted RTP streams as originating from the same media source:
REQ-1.1: In SDP signaling. REQ-1.1: In SDP signaling.
REQ-1.2: On RTP/RTCP level. REQ-1.2: On RTP/RTCP level, at least with prior knowledge of SDP
(or similar) signaling.
REQ-2: Transport usage. The solution must work when using: REQ-2: Transport usage. The solution must work when using:
REQ-2.1: Legacy SDP with separate media transports per SDP media REQ-2.1: Legacy SDP with separate media transports per SDP media
description. description.
REQ-2.2: Bundled [I-D.ietf-mmusic-sdp-bundle-negotiation] SDP REQ-2.2: Bundled [I-D.ietf-mmusic-sdp-bundle-negotiation] SDP
media descriptions. media descriptions.
REQ-3: Capability negotiation. It must be possible that: REQ-3: Capability negotiation. It must be possible that:
skipping to change at page 8, line 36 skipping to change at page 8, line 38
combination with other RTP mechanisms that generate additional RTP combination with other RTP mechanisms that generate additional RTP
streams: streams:
REQ-5.1: RTP Retransmission [RFC4588]. REQ-5.1: RTP Retransmission [RFC4588].
REQ-5.2: RTP Forward Error Correction [RFC5109]. REQ-5.2: RTP Forward Error Correction [RFC5109].
REQ-5.3: Related payload types such as audio Comfort Noise and/or REQ-5.3: Related payload types such as audio Comfort Noise and/or
DTMF. DTMF.
REQ-5.4: A single simulcast stream can consist of multiple RTP
streams, to support codecs where a dependent stream is
dependent on a set of encoded and dependent streams, each
potentially carried in their own RTP stream.
REQ-6: Interoperability. The solution must be possible to use in: REQ-6: Interoperability. The solution must be possible to use in:
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.
5. Overview 5. Overview
skipping to change at page 9, line 15 skipping to change at page 9, line 23
o An offer or answer can contain multiple, alternative simulcast o An offer or answer can contain multiple, alternative simulcast
stream formats in the same fashion as multiple, alternative stream formats in the same fashion as multiple, alternative
formats can be offered in a media description. formats can be 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
is aligned with the concepts defined in [RFC7656] and will is aligned with the concepts defined in [RFC7656] and will
specifically work in a WebRTC context, both with and without specifically work in a WebRTC context, both with and without
BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping. BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] grouping.
o The codec configuration for a simulcast stream is expressed o The codec configuration for a simulcast stream is expressed
through use of separately specified RTP payload format constraints through use of separately specified RTP payload format
[I-D.ietf-mmusic-rid] with an associated RTP-level identification restrictions [I-D.ietf-mmusic-rid] with an associated RTP-level
mechanism [I-D.ietf-avtext-rid] to identify which RTP payload identification mechanism [I-D.ietf-avtext-rid] to identify which
format constraints an RTP stream adheres to. This complements and RTP payload format restrictions an RTP stream adheres to. This
effectively extends simulcast stream identification and complements and effectively extends simulcast stream
configuration possibilities that could be provided by using only identification and configuration possibilities that could be
SDP formats as identifier. provided by using only SDP formats as identifier. Use of multiple
RTP streams with the same (non-redundancy) media type in the
context of a single media source, where those RTP streams are
using different RtpStreamId, is a strong but not totally
unambiguous indication of those RTP streams being part of a
simulcast.
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). First, This section further details the overview above (Section 5). First,
formal syntax is provided (Section 6.1), followed by the rest of the formal syntax is provided (Section 6.1), followed by the rest of the
SDP attribute definition in Section 6.2. Relating Simulcast Streams SDP attribute definition in Section 6.2. Relating Simulcast Streams
(Section 6.5) provides the definition of the RTP/RTCP mechanisms (Section 6.5) provides the definition of the RTP/RTCP mechanisms
skipping to change at page 10, line 7 skipping to change at page 10, line 19
sc-alt-list = sc-id *( "," sc-id ) sc-alt-list = sc-id *( "," sc-id )
sc-id-paused = "~" sc-id-paused = "~"
sc-id = [sc-id-paused] rid-identifier sc-id = [sc-id-paused] rid-identifier
; SP defined in [RFC5234] ; SP defined in [RFC5234]
; rid-identifier defined in [I-D.ietf-mmusic-rid] ; rid-identifier defined in [I-D.ietf-mmusic-rid]
Figure 1: ABNF for Simulcast Figure 1: ABNF for Simulcast
The "a=simulcast" attribute has a parameter in the form of one or two The "a=simulcast" attribute has a parameter in the form of one or two
simulcast stream descriptions, each consisting of a direction ("send" simulcast stream descriptions, each consisting of a direction ("send"
or "recv"), followed by a list of one or more simulcast streams. The or "recv"), followed by a list of one or more simulcast streams.
simulcast stream identification (SCID) MUST be have the form of an Each simulcast stream consists of one or more alternative simulcast
RTP stream identifier, as described by RTP Payload Format Constraints formats. Each simulcast format is identified by a simulcast stream
identification (SCID). The SCID MUST have the form of an RTP stream
identifier, as described by RTP Payload Format Restrictions
[I-D.ietf-mmusic-rid]. [I-D.ietf-mmusic-rid].
In the list of simulcast streams, each SCID is separated by a In the list of simulcast streams, each simulcast stream is separated
semicolon (";"). Each simulcast stream can in turn be offered in one by a semicolon (";"). Each simulcast stream can in turn be offered
or more alternative formats, where each alternative SCID is separated in one or more alternative formats, represented by SCIDs, separated
by a comma (","). Each simulcast stream can also be specified as by a comma (","). Each SCID can also be specified as initially
initially paused [RFC7728], indicated by prepending a "~" to the paused [RFC7728], indicated by prepending a "~" to the SCID. The
SCID. In case there are alternative SCID, pause can be specified reason to allow separate initial pause states for each SCID is that
individually for each SCID. The reason to allow separate initial pause capability can be specified individually for each RTP payload
pause states for each SCID is that pause capability can be specified type referenced by an SCID. Since pause capability specified via the
individually for each RTP payload type referenced by an SCID. Since "a=rtcp-fb" attribute and SCID specified by "a=rid" can refer to
pause capability specified via the "a=rtcp-fb" attribute and SCID common payload types, it is unfeasible to pause streams with SCID
specified by "a=rid" can refer to common payload types, it is where any of the related RTP payload type(s) do not have pause
unfeasible to pause streams with SCID where any of the related RTP capability.
payload type(s) do not have pause capability.
Examples: Examples:
a=simulcast:send 1,2,3;~4,~5 recv 6;~7,~8 a=simulcast:send 1,2,3;~4,~5 recv 6;~7,~8
a=simulcast:recv 1;4,5 send 6;7 a=simulcast:recv 1;4,5 send 6;7
Figure 2: Simulcast Examples Figure 2: Simulcast Examples
Above are two examples of different "a=simulcast" lines. Above are two examples of different "a=simulcast" lines.
The first line is an example offer to send two simulcast streams and The first line is an example offer to send two simulcast streams and
to receive two simulcast streams. The first simulcast stream in send to receive two simulcast streams. The first simulcast stream in send
direction can be sent in three different alternative formats (SCID 1, direction can be sent in three different alternative formats (SCID 1,
2, 3), and the second simulcast stream in send direction can be sent 2, 3), and the second simulcast stream in send direction can be sent
in two different alternative formats (SCID 4, 5). Both of the second in two different alternative formats (SCID 4, 5). Both of the second
stream alternative formats in send direction are offered as initially simulcast stream alternative formats in send direction are offered as
paused. The first simulcast stream in receive direction has no initially paused. The first simulcast stream in receive direction
alternative formats (SCID 6). The second simulcast stream in receive has no alternative formats (SCID 6). The second simulcast stream in
direction has two alternative formats (SCID 7, 8) that are both receive direction has two alternative formats (SCID 7, 8) that are
offered as initially paused. both offered as initially paused.
The second line is an example answer to the first line, accepting to The second line is an example answer to the first line, accepting to
send and receive the two offered simulcast streams, however send and send and receive the two offered simulcast streams, however send and
receive directions are specified in opposite order compared to the receive directions are specified in opposite order compared to the
first line, which lets the answer keep the same order of simulcast first line, which lets the answer keep the same order of simulcast
streams in the SDP as in the offer, for convenience, even though streams in the SDP as in the offer, for convenience, even though
directionality is reversed. This example answer has removed all directionality is reversed. This example answer has removed all
offered alternative formats for the first simulcast stream (keeping offered alternative formats for the first simulcast stream (keeping
only SCID 1), but kept alternative formats for the second simulcast only SCID 1), but kept alternative formats for the second simulcast
stream in receive direction (4, 5). The answer accepts to send two stream in receive direction (4, 5). The answer thus accepts to send
simulcast streams, without alternatives. The answer does not accept two simulcast streams, without alternatives. The answer does not
initial pause of any simulcast streams, in either direction. More accept initial pause of any simulcast streams, in either direction.
examples can be found in Section 6.6. More examples can be found in Section 6.6.
6.2. Simulcast Capability 6.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 6.1). The meaning of the attribute attribute, "a=simulcast" (Section 6.1). The meaning of the attribute
on SDP session level is undefined and MUST NOT be used. The meaning on SDP session level is undefined, MUST NOT be used by
of including multiple "a=simulcast" lines in a single SDP media implementations of this specification and MUST be ignored if received
description is undefined and MUST NOT be used. on session level. Extensions to this specification MAY define such
session level usage. The meaning of including multiple "a=simulcast"
lines in a single SDP media description is undefined, MUST NOT be
used by implementations of this specification and any additional
"a=simulcast" lines beyond the first under an "m=" line MUST be
ignored if received.
For each desired direction (send/recv), the simulcast attribute There are separate and independent sets of simulcast streams in send
defines a list of simulcast streams (separated by semicolons), each and receive directions. When listing multiple directions, each
of which is a list of alternate simulcast stream formats (separated direction MUST NOT occur more than once on the same line.
by commas). The different simulcast stream formats MUST be
identified through the RTP payload format constraints
[I-D.ietf-mmusic-rid] RTP-level identification mechanism
[I-D.ietf-avtext-rid], here denoted SCID. Simulcast streams using
undefined SCID MUST NOT be used as valid simulcast streams by an RTP
stream receiver.
There are separate and independent sets of parameters for simulcast Simulcast streams using undefined SCID MUST NOT be used as valid
in send and receive directions. When listing multiple directions, simulcast streams by an RTP stream receiver. The direction for an
each direction MUST NOT occur more than once on the same line. SCID MUST be aligned with the direction specified for the
Attribute parameters are grouped by direction and consist of a corresponding RTP stream identifier on the "a=rid" line.
listing of SCID to be used. The direction for an SCID MUST be
aligned with the direction specified for the corresponding RTP stream
identifier on the "a=rid" line.
The number of (non-alternative, see above) SCID in the list sets a The listed number of simulcast streams for a direction sets a limit
limit to the number of supported simulcast streams in that direction. to the number of supported simulcast streams in that direction. The
The order of the listed SCID in the "send" direction suggests a order of the listed simulcast streams in the "send" direction
proposed order of preference, in decreasing order: the SCID listed suggests a proposed order of preference, in decreasing order: the
first is the most preferred and subsequent streams have progressively SCID listed first is the most preferred and subsequent streams have
lower preference. The order of the listed SCID in the "recv" progressively lower preference. The order of the listed SCID in the
direction expresses a preference which simulcast streams that are "recv" direction expresses a preference which simulcast streams that
preferred, with the leftmost being most preferred. This can be of are preferred, with the leftmost being most preferred. This can be
importance if the number of actually sent simulcast streams have to of importance if the number of actually sent simulcast streams have
be reduced for some reason. to be reduced for some reason.
SCID that have explicit dependencies [RFC5583] [I-D.ietf-mmusic-rid] SCID that have explicit dependencies [RFC5583] [I-D.ietf-mmusic-rid]
to other SCID (even in the same media description) MAY be used. to other SCID (even in the same media description) MAY be used.
Alternative SCID MAY be specified as part of the attribute parameters Use of more than a single, alternative simulcast format for a
by expressing each simulcast stream as a comma-separated list of simulcast stream MAY be specified as part of the attribute parameters
by expressing the simulcast stream as a comma-separated list of
alternative SCID. In this case, it is not possible to align what alternative SCID. In this case, it is not possible to align what
alternative SCID that are used between different simulcast streams, alternative SCID that are used across different simulcast streams,
like requiring all simulcast streams to use SCID alternatives like requiring all simulcast streams to use SCID alternatives
referring to the same codec format. The order of the SCID referring to the same codec format. The order of the SCID
alternatives within a simulcast stream is significant; the SCID alternatives within a simulcast stream is significant; the SCID
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. In those cases, such "related" formats MUST NOT
be defined as SCID and listed explicitly in the attribute parameters, be defined as having their own SCID listed explicitly in the
since they are not strictly simulcast streams of the media source, attribute parameters, since they are not strictly simulcast streams
but rather a specific way of generating the RTP stream of a single of the media source, but rather a specific way of generating the RTP
simulcast stream with varying RTP payload type. stream of a single simulcast stream with varying RTP payload type.
If RTP stream pause/resume [RFC7728] is supported, any SCID MAY be If RTP stream pause/resume [RFC7728] is supported, any SCID 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.
If the simulcast stream is specified as a list of alternative SCID,
each of which can be individually prefixed by the paused indication.
All RTP payload types related to such initially paused simulcast All RTP payload types related to such initially paused simulcast
stream MUST be listed in the SDP as pause/resume capable as specified stream MUST be listed in the SDP as pause/resume capable as specified
by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb". by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb".
An initially paused simulcast stream in "send" direction MUST be An initially paused simulcast stream in "send" direction MUST be
considered equivalent to an unsolicited locally paused stream, and be considered equivalent to an unsolicited locally paused stream, and be
handled accordingly. Initially paused simulcast streams are resumed handled accordingly. Initially paused simulcast streams are resumed
as described by the RTP pause/resume specification. An RTP stream as described by the RTP pause/resume specification. An RTP stream
receiver that wishes to resume an unsolicited locally paused stream receiver that wishes to resume an unsolicited locally paused stream
needs to know the SSRC of that stream. The SSRC of an initially needs to know the SSRC of that stream. The SSRC of an initially
skipping to change at page 13, line 23 skipping to change at page 13, line 31
Use of the redundant audio data [RFC2198] format could be seen as a Use of the redundant audio data [RFC2198] format could be seen as a
form of simulcast for loss protection purposes, but is not considered form of simulcast for loss protection purposes, but is not considered
conflicting with the mechanisms described in this memo and MAY conflicting with the mechanisms described in this memo and MAY
therefore be used as any other format. In this case the "red" therefore be used as any other format. In this case the "red"
format, rather than the carried formats, SHOULD be the one to list as format, rather than the carried formats, SHOULD be the one to list as
a simulcast stream on the "a=simulcast" line. a simulcast stream on the "a=simulcast" line.
The media formats and corresponding characteristics of simulcast The media formats and corresponding characteristics of simulcast
streams SHOULD be chosen such that they are different, either as streams SHOULD be chosen such that they are different, either as
different SDP formats with differing "a=rtpmap" and/or "a=fmtp" different SDP formats with differing "a=rtpmap" and/or "a=fmtp"
lines, as differently defined RTP Constraints, or both. If this lines, as differently defined RTP payload format restrictions, or
difference is not required, RTP duplication [RFC7104] procedures both. If this difference is not required, RTP duplication [RFC7104]
SHOULD be considered instead of simulcast. procedures SHOULD be considered instead of simulcast.
6.3. Offer/Answer Use 6.3. Offer/Answer Use
Note: The inclusion of "a=simulcast" or the use of simulcast does Note: The inclusion of "a=simulcast" or the use of simulcast does
not change any of the interpretation or Offer/Answer procedures not change any of the interpretation or Offer/Answer procedures
for other SDP attributes, like "a=fmtp" or "a=rid". for other SDP attributes, like "a=fmtp" or "a=rid".
6.3.1. Generating the Initial SDP Offer 6.3.1. Generating the Initial SDP Offer
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 listing a set of receive attribute in the offer. An offerer listing a set of receive
simulcast streams and/or alternative formats as SCID in the offer simulcast streams and/or alternative formats as SCID in the offer
MUST be prepared to receive RTP streams for any of those simulcast MUST be prepared to receive RTP streams for any of those simulcast
streams and/or alternative formats from the answerer. streams and/or alternative formats from the answerer.
6.3.2. Creating the SDP Answer 6.3.2. Creating the SDP Answer
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. defined in existing SDP Offer/Answer [RFC3264] procedures.
Similarly, an answerer that receives an offer with the "a=simulcast"
attribute on session level SHALL remove it in the answer. An
answerer that understands the attribute but receives multiple
"a=simulcast" attributes under the same "m=" line SHALL ignore and
remove all but the first in the answer.
An answerer that does understand the attribute and that wants to An answerer that does understand the attribute and that wants to
support simulcast in an indicated direction SHALL reverse support simulcast in an indicated direction SHALL reverse
directionality of the unidirectional direction parameters; "send" directionality of the unidirectional direction parameters; "send"
becomes "recv" and vice versa, and include it in the answer. becomes "recv" and vice versa, and include it in the answer.
An answerer that receives an offer with simulcast containing an An answerer that receives an offer with simulcast containing an
"a=simulcast" attribute listing alternative SCID MAY keep all the "a=simulcast" attribute listing alternative SCID MAY keep all the
alternative SCID in the answer, but it MAY also choose to remove any alternative SCID in the answer, but it MAY also choose to remove any
non-desirable alternative SCID in the answer. The answerer MUST NOT non-desirable alternative SCID in the answer. The answerer MUST NOT
add any alternative SCID that were not present in the offer. The add any alternative SCID in send direction in the answer that were
answerer MUST be prepared to receive any of the receive direction not present in the offer receive direction. The answerer MUST be
SCID alternatives, and MAY send any of the send direction prepared to receive any of the receive direction SCID alternatives,
alternatives that are kept in the answer. and MAY send any of the send direction alternatives that are kept in
the answer.
An answerer that receives an offer with simulcast that lists a number An answerer that receives an offer with simulcast that lists a number
of simulcast streams, MAY reduce the number of simulcast streams in of simulcast streams, MAY reduce the number of simulcast streams in
the answer, but MUST NOT add simulcast streams. the answer, but MUST NOT add simulcast streams.
An answerer that receives an offer without RTP stream pause/resume An answerer that receives an offer without RTP stream pause/resume
capability MUST NOT mark any simulcast streams as initially paused in capability MUST NOT mark any simulcast streams as initially paused in
the answer. the answer.
An RTP stream pause/resume capable answerer that receives an offer An RTP stream pause/resume capable answerer that receives an offer
with RTP stream pause/resume capability MAY mark any SCID that refer with RTP stream pause/resume capability MAY mark any SCID that refer
to pause/resume capable formats as initially paused in the answer. to pause/resume capable formats as initially paused in the answer.
An answerer that receives indication in an offer of an SCID being An answerer that receives indication in an offer of an SCID being
initially paused , SHOULD mark that SCID as initially paused also in initially paused SHOULD mark that SCID as initially paused also in
the answer, regardless of direction, unless it has good reason for the answer, regardless of direction, unless it has good reason for
the SCID not being initially paused. One such reason could for the SCID not being initially paused. One such reason could, for
example be that the answerer would otherwise initially not receive example, be that the answerer would otherwise initially not receive
any media of that type at all. any media of that type at all.
6.3.3. Offerer Processing the SDP Answer 6.3.3. Offerer Processing the SDP Answer
An offerer that receives an answer without "a=simulcast" MUST NOT use An offerer that receives an answer without "a=simulcast" MUST NOT use
simulcast towards the answerer. An offerer that receives an answer simulcast towards the answerer. An offerer that receives an answer
with "a=simulcast" without any SCID in a specified direction MUST NOT with "a=simulcast" without any SCID in a specified direction MUST NOT
use simulcast in that direction. use simulcast in that direction.
An offerer that receives an answer where some SCID alternatives are An offerer that receives an answer where some SCID alternatives are
kept MUST be prepared to receive any of the kept send direction SCID kept MUST be prepared to receive any of the kept send direction SCID
alternatives, and MAY send any of the kept receive direction SCID alternatives, and MAY send any of the kept receive direction SCID
alternatives. alternatives.
An offerer that receives an answer where some of the SCID are removed An offerer that receives an answer where some of the SCID are removed
MAY release the corresponding resources (codec, transport, etc) in compared to the offer MAY release the corresponding resources (codec,
its receive direction and MUST NOT send any RTP packets corresponding transport, etc) in its receive direction and MUST NOT send any RTP
to the removed SCID. packets corresponding to the removed SCID.
An offerer that offered some of its SCID as initially paused and that An offerer that offered some of its SCID as initially paused and that
receives an answer that does not indicate RTP stream pause/resume receives an answer that does not indicate RTP stream pause/resume
capability, MUST NOT initially pause any simulcast streams. capability, MUST NOT initially pause any simulcast streams.
An offerer with RTP stream pause/resume capability that receives an An offerer with RTP stream pause/resume capability that receives an
answer where some SCID are marked as initially paused, SHOULD answer where some SCID are marked as initially paused, SHOULD
initially pause those RTP streams regardless if they were marked as initially pause those RTP streams regardless if they were marked as
initially paused also in the offer, unless it has good reason for initially paused also in the offer, unless it has good reason for
those RTP streams not being initially paused. One such reason could those RTP streams not being initially paused. One such reason could,
for example be that the answerer would otherwise initially not for example, be that the answerer would otherwise initially not
receive any media of that type at all. receive any media of that type at all.
6.3.4. Modifying the Session 6.3.4. Modifying the Session
Offers and answers inside an existing session follow the rules for Offers and answers inside an existing session follow the rules for
initial session negotiation, with the additional restriction that any initial session negotiation, with the additional restriction that any
SCID marked as initially paused in such offer or answer MUST already SCID marked as initially paused in such offer or answer MUST already
be paused, thus a new offer/answer MUST NOT replace use of RTP stream be paused, thus a new offer/answer MUST NOT replace use of RTP stream
pause/resume [RFC7728] in the session. Session modification pause/resume [RFC7728] in the session. Session modification
restrictions in section 6.5 of "a=rid" [I-D.ietf-mmusic-rid] also restrictions in section 6.5 of RTP payload format restrictions
apply. [I-D.ietf-mmusic-rid] also apply.
6.4. Declarative Use
When used as a declarative media description, "a=simulcast" line 6.4. Use with Declarative SDP
"recv" direction formats indicate the configured end point's required
capability to recognize and receive a specified set of RTP streams as
simulcast streams. In the same fashion, "a=simulcast" line "send"
direction requests the end point to send a specified set of RTP
streams as simulcast streams.
If multiple alternative simulcast formats are listed, it means that This document does not define the use of "a=simulcast" in declarative
the configured end point MUST be prepared to receive any of the SDP, partly motivated by use of the simulcast format identification
"recv" formats, and MAY send any of the "send" formats for that [I-D.ietf-mmusic-rid] not being defined for use in declarative SDP.
simulcast stream, which is aligned with the semantics of listing If concrete use cases for simulcast in declarative SDP are identified
multiple formats on the "m=" line. in the future, we expect that additional specifications will address
such use.
It may not be beneficial for declarative use to be limited to a Note: It may not be beneficial for declarative use to be limited
single media source per "m=" line, as elaborated further in to a single media source per "m=" line, as elaborated further in
Section 8. Section 9.
6.5. Relating Simulcast Streams 6.5. Relating Simulcast Streams
Simulcast RTP streams MUST be related on RTP level through RID Simulcast RTP streams MUST be related on RTP level through
[I-D.ietf-avtext-rid], as specified in the SDP "a=simulcast" RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP
attribute (Section 6.2) parameters. This is sufficient as long as "a=simulcast" attribute (Section 6.2) parameters. This is sufficient
there is only a single media source per SDP media description. When as long as there is only a single media source per SDP media
using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple description. When using BUNDLE
SDP media descriptions jointly specify a single RTP session, the SDES [I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media
MID identification mechanism in BUNDLE allows relating RTP streams descriptions jointly specify a single RTP session, the SDES MID
back to individual media descriptions, after which the above identification mechanism in BUNDLE allows relating RTP streams back
described RID relations can be used. Use of the RTP header extension to individual media descriptions, after which the above described
RtpStreamId relations can be used. Use of the RTP header extension
[RFC5285] for both MID and RID identifications can be important to [RFC5285] for both MID and RtpStreamId identifications can be
ensure rapid initial reception, required to correctly interpret and important to ensure rapid initial reception, required to correctly
process the RTP streams. Implementers of this specification MUST interpret and process the RTP streams. Implementers of this
support RTCP source description (SDES) item and SHOULD support RTP specification MUST support the RTCP source description (SDES) item
header extension method to signal RID on RTP level. method and SHOULD support RTP header extension method to signal
RtpStreamId on RTP level.
RTP streams MUST only use a single alternative SCID at a time (based RTP streams MUST only use a single alternative SCID at a time (based
on RTP timestamps), but MAY change format on a per-RTP packet basis. on RTP timestamps), but MAY change format on a per-RTP packet basis.
This corresponds to the existing (non-simulcast) SDP offer/answer This corresponds to the existing (non-simulcast) SDP offer/answer
case when multiple formats are included on the "m=" line in the SDP case when multiple formats are included on the "m=" line in the SDP
answer. answer.
6.6. Signaling Examples 6.6. Signaling Examples
These examples describe a client to video conference service, using a These examples describe a client to video conference service, using a
skipping to change at page 16, line 38 skipping to change at page 17, line 11
+---+ +-----------+ +---+ +---+ +-----------+ +---+
Figure 3: Four-party Mixer-based Conference Figure 3: Four-party Mixer-based Conference
6.6.1. Single-Source Client 6.6.1. Single-Source Client
Alice is calling in to the mixer with a simulcast-enabled client Alice is calling in to the mixer with a simulcast-enabled client
capable of a single media source per media type. The client can send capable of a single media source per media type. The client can send
a simulcast of 2 video resolutions and frame rates: HD 1280x720p a simulcast of 2 video resolutions and frame rates: HD 1280x720p
30fps and thumbnail 320x180p 15fps. This is defined below using the 30fps and thumbnail 320x180p 15fps. This is defined below using the
"imageattr" [RFC6236]. In this example, only the "pt" RID parameter "imageattr" [RFC6236]. In this example, only the "pt" "a=rid"
is used, effectively achieving a 1:1 mapping between RID and media parameter is used, effectively achieving a 1:1 mapping between
formats (RTP payload types), to describe simulcast stream formats. RtpStreamId and media formats (RTP payload types), to describe
Alice's Offer: simulcast stream formats. Alice's Offer:
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 pt=97 send a=rid:1 pt=97 send
a=rid:2 pt=98 send a=rid:2 pt=98 send
a=rid:3 pt=97 recv a=rid:3 pt=97 recv
a=simulcast:send 1;2 recv 3 a=simulcast:send 1;2 recv 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
Figure 4: Single-Source Simulcast Offer Figure 4: Single-Source Simulcast Offer
The only thing in the SDP that indicates simulcast capability is the The only thing in the SDP that indicates simulcast capability is the
line in the video media description containing the "simulcast" line in the video media description containing the "simulcast"
attribute. The included "a=fmtp" and "a=imageattr" parameters attribute. The included "a=fmtp" and "a=imageattr" parameters
indicates that sent simulcast streams can differ in video resolution. indicates that sent simulcast streams can differ in video resolution.
The RTP header extension for RtpStreamId is offered to avoid issues
with the initial binding between RTP streams (SSRCs) and the
RtpStreamId identifying the simulcast stream and its format.
The Answer from the server indicates that it too is simulcast The Answer from the server indicates that it too is simulcast
capable. Should it not have been simulcast capable, the capable. Should it not have been simulcast capable, the
"a=simulcast" line would not have been present and communication "a=simulcast" line would not have been present and communication
would have started with the media negotiated in the SDP. would have started with the media negotiated in the SDP. Also the
usage of the RtpStreamId RTP header extension is accepted.
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 pt=97 recv a=rid:1 pt=97 recv
a=rid:2 pt=98 recv a=rid:2 pt=98 recv
a=rid:3 pt=97 send a=rid:3 pt=97 send
a=simulcast:recv 1;2 send 3 a=simulcast:recv 1;2 send 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:RtpStreamId
Figure 5: Single-Source Simulcast Answer Figure 5: Single-Source Simulcast Answer
Since the server is the simulcast media receiver, it reverses the Since the server is the simulcast media receiver, it reverses the
direction of the "simulcast" and "rid" attribute parameters. direction of the "simulcast" and "rid" attribute parameters.
6.6.2. Multi-Source Client 6.6.2. Multi-Source Client
Fred is calling in to the same conference as in the example above Fred is calling in to the same conference as in the example above
with a two-camera, two-display system, thus capable of handling two with a two-camera, two-display system, thus capable of handling two
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 restricted simulcast-enabled in the send direction. Fred's client is restricted
to a single media source per media description. to a single media source per media 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 [RFC7741] and H264, are offered as alternatives for video codecs, VP8 [RFC7741] and H264, are offered as alternatives for
the third simulcast stream for the first media source. Only the the third simulcast stream for the first media source. Only the
highest fidelity simulcast stream are sent from start, the lower highest fidelity simulcast stream is sent from start, the lower
fidelity streams being initially paused. fidelity streams being initially paused.
The second media source is offered with three different simulcast The second media source is offered with three different simulcast
streams. All video streams of this second media source are loss streams. All video streams of this second media source are loss
protected by RTP retransmission [RFC4588]. Also here, all but the protected by RTP retransmission [RFC4588]. Also here, all but the
highest fidelity simulcast stream are initially paused. highest fidelity simulcast stream are initially paused.
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 RID as simulcast stream identification enables example, the use of RtpStreamId as simulcast stream identification
use of a low number of RTP payload types. Note that the use of both enables use of a low number of RTP payload types. Note that the use
BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] and 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 [RFC5285] for carrying these RTP stream identification fields, which
is consequently also included in the SDP. Note also that for RID, is consequently also included in the SDP. Note also that for
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
skipping to change at page 20, line 41 skipping to change at page 20, line 41
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
m=video 49602 RTP/AVPF 96 104 m=video 49602 RTP/AVPF 96 104
a=mid:zen a=mid:zen
a=rtpmap:96 VP8/90000 a=rtpmap:96 VP8/90000
a=fmtp:96 max-fs=3600; max-fr=30 a=fmtp:96 max-fs=3600; max-fr=30
a=rtpmap:104 rtx/90000 a=rtpmap:104 rtx/90000
a=fmtp:104 apt=96;rtx-time=200 a=fmtp:104 apt=96;rtx-time=200
a=rid:5 send pt=96;max-fs=921600;max-fps=30 a=rid:1 send pt=96;max-fs=921600;max-fps=30
a=rid:6 send pt=96;max-fs=614400;max-fps=15 a=rid:2 send pt=96;max-fs=614400;max-fps=15
a=rid:7 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 5;~6;~7 a=simulcast:send 1;~2;~3
Figure 6: Fred's Multi-Source Simulcast Offer Figure 6: 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. RTP Aspects
This section discusses what the different entities in a simulcast
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
simulcasted to a RTP middlebox. That RTP middlebox sends media
sources both to other RTP middleboxes (cascaded middleboxes), as well
as selecting some simulcast format of the media source and sending it
to receiving endpoints. Different types of RTP middleboxes and their
usage of the different simulcast formats results in several different
behaviors.
7.1. Outgoing from Endpoint with Media Source
The most straightforward simulcast case is the RTP streams being
emitted from the endpoint that originates a media source. When
simulcast has been negotiated in the sending direction, the endpoint
can transmit up to the number of RTP streams needed for the
negotiated simulcast streams for that media source. Each RTP stream
(SSRC) is identified by associating (Section 6.5) it with an
RtpStreamId SDES item, transmitted in RTCP and possibly also as an
RTP header extension. In cases where multiple media sources have
been negotiated for the same RTP session and thus BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used, also the MID SDES
item will be sent similarly to the RtpStreamId.
Each RTP stream may not be continuously transmitted due to any of the
following reasons; temporarily paused using Pause/Resume [RFC7728],
sender side application logic temporarily pausing it, or lack of
network resources to transmit this simulcast stream. However, all
simulcast streams that have been negotiated have active and
maintained SSRC (at least in regular RTCP reports), even if no RTP
packets are currently transmitted. The relation between an RTP
Stream (SSRC) and a particular simulcast stream is not expected to
change, except in exceptional situations such as SSRC collisions. At
SSRC changes, the usage of MID and RtpStreamId should enable the
receiver to correctly identify the RTP streams even after an SSRC
change.
7.2. RTP Middlebox to Receiver
RTP streams in a multi-party RTP session can be used in multiple
different ways, when the session utilizes simulcast at least on the
media source to middlebox legs. This is to a large degree due to the
different RTP middlebox behaviors, but also the needs of the
application. This text assumes that the RTP middlebox will select a
media source and choose which simulcast stream for that media source
to deliver to a specific receiver. In many cases, at most one
simulcast stream per media source will be forwarded to a particular
receiver at any instant in time, even if the selected simulcast
stream may vary. For cases where this does not hold due to
application needs, then the RTP stream aspects will fall under the
middlebox to middlebox case Section 7.3.
The selection of which simulcast streams to forward towards the
receiver, is application specific. However, in conferencing
applications, active speaker selection is common. In case the number
of media sources possible to forward, N, is less than the total
amount of media sources available in an multi-media session, the
current and previous speakers (up to N in total) are often the ones
forwarded. To avoid the need for media specific processing to
determine the current speaker(s) in the RTP middlebox, the endpoint
providing a media source may include meta data, such as the RTP
Header Extension for Client-to-Mixer Audio Level Indication
[RFC6464].
The possibilities for stream switching are media type specific, but
for media types with significant interframe dependencies in the
encoding, like most video coding, the switching needs to be made at
suitable switching points in the media stream that breaks or
otherwise deals with the dependency structure. Even if switching
points can be included periodically, it is common to use mechanisms
like Full Intra Requests [RFC5104] to request switching points from
the endpoint performing the encoding of the media source.
Inclusion of the RtpStreamId SDES item for an SSRC in the middlebox
to receiver direction should only occur when use of RtpStreamId has
been negotiated in that direction. It is worth noting that one can
signal multiple RtpStreamIds when simulcast signalling indicates only
a single simulcast stream, allowing one to use all of the
RtpStreamIds as alternatives for that simulcast stream. One reason
for including the RtpStreamId in the middlebox to receiver direction
for an RTP stream is to let the receiver know which restrictions
apply to the currently delivered RTP stream. In case the RtpStreamId
is negotiated to be used, it is important to remember that the used
identifiers will be specific to each signalling session. Even if the
central entity can attempt to coordinate, it is likely that the
RtpStreamIds need to be translated to the leg specific values. The
below cases will have as base line that RtpStreamId is not used in
the mixer to receiver direction.
7.2.1. Media-Switching Mixer
This section discusses the behavior in cases where the RTP middlebox
behaves like the Media-Switching Mixer (Section 3.6.2) in RTP
Topologies [RFC7667]. The fundamental aspect here is that the media
sources delivered from the middlebox will be the mixer's conceptual
or functional ones. For example, one media source may be the main
speaker in high resolution video, while a number of other media
sources are thumbnails of each participant.
The above results in that the RTP stream produced by the mixer is one
that switches between a number of received incoming RTP streams for
different media sources and in different simulcast versions. The
mixer selects the media source to be sent as one of the RTP streams,
and then selects among the available simulcast streams for the most
appropriate one. The selection criteria include available bandwidth
on the mixer to receiver path and restrictions based on the
functional usage of the RTP stream delivered to the receiver. An
example of the latter, is that it is unnecessary to forward a full HD
video to a receiver if the display area is just a thumbnail. Thus,
restrictions may exist to not allow some simulcast streams to be
forwarded for some of the mixer's media sources.
This will result in a single RTP stream being used for a particular
of the RTP mixer's media sources. This RTP stream is at any point in
time a selection of one particular RTP stream arriving to the mixer,
where the RTP header field values are rewritten to provide a
consistent, single RTP stream. If the RTP mixer doesn't receive any
incoming stream matched to this media source, the SSRC will not
transmit, but be kept alive using RTCP. The SSRC and thus RTP stream
for the mixer's media source is expected to be long term stable. It
will only be changed by signalling or other disruptive events. Note
that although the above talks about a single RTP stream, there can in
some cases be multiple RTP streams carrying the selected simulcast
stream for the originating media source, including repair or other
auxiliary RTP streams.
The mixer may communicate the identity of the originating media
source to the receiver by including the CSRC field with the
originating media source's SSRC value. Note that due to the
possibility that the RTP mixer switches between simulcast versions of
the media source, the CSRC value may change, even if the media source
is kept the same.
It is important to note that any MID SDES item from the originating
media source needs to be removed and not be associated with the RTP
stream's SSRC. This as there is nothing in the signalling between
the mixer and the receiver that is structured around the originating
media sources, only the mixer's media sources. If they would be
associated with the SSRC, the receiver would likely believe that
there has been an SSRC collision, and that the RTP stream is spurious
as it doesn't carry the identifiers used to relate it to the correct
context. However, this is not true for CSRC values, as long as they
are never used as SSRC. In these cases one could provide CNAME and
MID as SDES items. A receiver could use this to determine which CSRC
values that are associated with the same originating media source.
If RtpStreamIds are used in this scenario, it should be noted that
the RtpStreamId on a particular SSRC will change based on the actual
simulcast stream selected for switching. These RtpStreamId
identifiers will be local to this leg's signalling context. In
addition, the defined RtpStreamIds and their parameters need to cover
all the media sources and simulcast streams that can be switched into
this media source.
7.2.2. Selective Forwarding Middlebox
This section discusses the behavior in cases where the RTP middlebox
behaves like the Selective Forwarding Middlebox (Section 3.7) in RTP
Topologies [RFC7667]. Applications for this type of RTP middlebox
results in that each originating media source will have a
corresponding media source on the leg between the middlebox and the
receiver. A SFM could go as far as exposing all the simulcast
streams for an media source, however this section will focus on
having a single simulcast stream that can contain any of the
simulcast formats. This section will assume that the SFM projection
mechanism works on media source level, and maps one of the media
source's simulcast streams onto one RTP stream from the SFM to the
receiver.
This usage will result in that the individual RTP stream(s) for one
media source can switch between being active to paused, based on the
subset of media sources the SFM wants to provide the receiver for the
moment. With SFMs there exist no reasons to use CSRC to indicate the
originating stream, as there is a one to one media source mapping.
If the application requires knowing the simulcast version received to
function well, then RtpStreamId should be negotiated on the SFM to
receiver leg. Which simulcast stream that is being forwarded is not
made explicit unless RtpStreamId is used on the leg.
Any MID SDES items being sent by the SFM to the receiver are only
those agreed between the SFM and the receiver, and no MID values from
the originating side of the SFM are to be forwarded.
A SFM could expose corresponding RTP streams for all the media
sources and their simulcast streams, and then for any media source
that is to be provided forward one selected simulcast stream.
However, this is not recommended as it would unnecessarily increase
the number of RTP streams and require the receiver to timely detect
switching between simulcast streams. The above usage requires the
same SFM functionality for switching, while avoiding the
uncertainties of timely detecting that a RTP stream ends. The
benefit would be that the received simulcast stream would be
implicitly provided by which RTP stream would be active for a media
source. However, using RtpStreamId to make this explicit also
exposes which alternative format is used. The conclusion is that
using one RTP stream per simulcast stream is unnecessary. The issue
with timely detecting end of streams, independent if they are stopped
temporarily or long term, is that there is no explicit indication
that the transmission has intentionally been stopped. The RTCP based
Pause and Resume mechanism [RFC7728] includes a PAUSED indication
that provides the last RTP sequence number transmitted prior to the
pause. Due to usage, the timeliness of this solution depends on when
delivery using RTCP can occur in relation to the transmission of the
last RTP packet. If no explicit information is provided at all, then
detection based on non increasing RTCP SR field values and timers
need to be used to determine pause in RTP packet delivery. This
results in that one can usually not determine when the last RTP
packet arrives (if it arrives) that this will be the last. That it
was the last is something that one learns later.
7.3. RTP Middlebox to RTP Middlebox
This relates to the transmission of simulcast streams between RTP
middleboxes or other usages where one wants to enable the delivery of
multiple simultaneous simulcast streams per media source, but the
transmitting entity is not the originating endpoint. For a
particular direction between middlebox A and B, this looks very
similar to the originating to middlebox case on a media source basis.
However, in this case there is usually multiple media sources,
originating from multiple endpoints. This can create situations
where limitations in the number of simultaneous received media
streams can arise, for example due to limitation in network
bandwidth. In this case, a subset of not only the simulcast streams,
but also media sources can be selected. This results in that
individual RTP streams can be become paused at any point and later
being resumed based on various criteria.
The MIDs used between A and B are the ones agreed between these two
identities in signalling. The RtpStreamId values will also be
provided to ensure explicit information about which simulcast stream
they are. The RTP stream to MID and RtpStreamId associations should
here be long term stable.
8. 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.
When transmitting multiple independent streams that originate from When transmitting multiple independent streams that originate from
the same source, it could potentially be done in several different the same source, it could potentially be done in several different
ways using RTP. A general discussion on considerations for use of ways using RTP. A general discussion on considerations for use of
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
skipping to change at page 21, line 36 skipping to change at page 26, line 33
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 with good QoS Thus, 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 8.1. Bitrate Adaptation
Use of multiple simulcast streams can require a significant amount of Use of multiple simulcast streams can require a significant amount of
network resources. If the amount of available network resources network resources. If the amount of available network resources
varies during an RTP session such that it does not match what is varies during an RTP session such that it does not match what is
negotiated in SDP, the bitrate used by the different simulcast negotiated in SDP, the bitrate used by the different simulcast
streams may have to be reduced dynamically. What simulcast streams streams may have to be reduced dynamically. What simulcast streams
to prioritize when allocating available bitrate among the simulcast to prioritize when allocating available bitrate among the simulcast
streams in such adaptation SHOULD be taken from the simulcast stream streams in such adaptation SHOULD be taken from the simulcast stream
order on the "a=simulcast" line. Simulcast streams that have pause/ order on the "a=simulcast" line. Simulcast streams that have pause/
resume capability and that would be given such low bitrate by the resume capability and that would be given such low bitrate by the
adaptation process that they are considered not really useful can be adaptation process that they are considered not really useful can be
temporarily paused until the limiting condition clears. temporarily paused until the limiting condition clears.
8. Limitation 9. Limitation
The chosen approach has a limitation that relates to the use of a The chosen approach has a limitation that relates to the use of a
single RTP session for all simulcast formats of a media source, which single RTP session for all simulcast formats of a media source, which
comes from sending all simulcast streams related to a media source comes from sending all simulcast streams related to a media source
under the same SDP media description. under the same SDP media description.
It is not possible to use different simulcast streams on different It is not possible to use different simulcast streams on different
media transports, limiting the possibilities to apply different QoS media transports, limiting the possibilities to apply different QoS
to different simulcast streams. When using unicast, QoS mechanisms to different simulcast streams. When using unicast, QoS mechanisms
based on individual packet marking are feasible, since they do not based on individual packet marking are feasible, since they do not
require separation of simulcast streams into different RTP sessions require separation of simulcast streams into different RTP sessions
to apply different QoS. to apply different QoS.
It is also not possible to separate different simulcast streams into It is also not possible to separate different simulcast streams into
different multicast groups to allow a multicast receiver to pick the different multicast groups to allow a multicast receiver to pick the
stream it wants, rather than receive all of them. In this case, the stream it wants, rather than receive all of them. In this case, the
only reasonable implementation is to use different RTP sessions for only reasonable implementation is to use different RTP sessions for
each multicast group so that reporting and other RTCP functions each multicast group so that reporting and other RTCP functions
operate as intended. operate as intended. Such simulcast usage in multicast context is
out of scope for the current document and would require additional
specification.
9. IANA Considerations 10. IANA Considerations
This document requests to register a new media-level SDP attribute, This document requests to register a new media-level SDP attribute,
"simulcast", in the "att-field (media level only)" registry within "simulcast", in the "att-field (media level only)" registry within
the SDP parameters registry, according to the procedures of [RFC4566] the SDP parameters registry, according to the procedures of [RFC4566]
and [I-D.ietf-mmusic-sdp-mux-attributes]. and [I-D.ietf-mmusic-sdp-mux-attributes].
Contact name, email: IETF, contacted via mmusic@ietf.org, or a Contact name, email: IETF, contacted via mmusic@ietf.org, or a
successor address designated by IESG successor address designated by IESG
Attribute name: simulcast Attribute name: simulcast
skipping to change at page 23, line 5 skipping to change at page 27, line 46
Attribute value: See Section 6.1 of RFC XXXX. Attribute value: See Section 6.1 of RFC XXXX.
Purpose: Signals simulcast capability for a set of RTP streams Purpose: Signals simulcast capability for a set of RTP streams
MUX category: NORMAL MUX category: NORMAL
Note to RFC Editor: Please replace "RFC XXXX" with the assigned Note to RFC Editor: Please replace "RFC XXXX" with the assigned
number of this RFC. number of this RFC.
10. Security Considerations 11. Security Considerations
The simulcast capability, configuration attributes, and parameters The simulcast capability, configuration attributes, and parameters
are vulnerable to attacks in signaling. are 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.
Security considerations related to the use of RID is covered in Security considerations related to the use of "a=rid" and the
[I-D.ietf-mmusic-rid] and [I-D.ietf-avtext-rid]. There are no RtpStreamId SDES item is covered in [I-D.ietf-mmusic-rid] and
additional security concerns related to their use in this [I-D.ietf-avtext-rid]. There are no additional security concerns
specification. related to their use in this specification.
11. Contributors 12. 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, Peter document. Robert Hansen and Cullen Jennings, from Cisco, Peter
Thatcher, from Google, and Adam Roach, from Mozilla, contributed Thatcher, from Google, and Adam Roach, from Mozilla, contributed
significantly to subsequent versions. significantly to subsequent versions.
12. Acknowledgements 13. Acknowledgements
13. References The authors would like to thank Bernard Aboba, Thomas Belling, Roni
Even, and Adam Roach for the feedback they provided during the
development of this document.
13.1. Normative References 14. References
14.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-04 (work in progress), June 2016. rid-09 (work in progress), October 2016.
[I-D.ietf-mmusic-rid] [I-D.ietf-mmusic-rid]
Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B.,
Roach, A., and B. Campen, "RTP Payload Format Roach, A., and B. Campen, "RTP Payload Format
Constraints", draft-ietf-mmusic-rid-05 (work in progress), Restrictions", draft-ietf-mmusic-rid-08 (work in
March 2016. progress), October 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-36 (work in progress), October 2016.
[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-13 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14
(work in progress), June 2016. (work in progress), September 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>. <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,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://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, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>.
[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
Semantics in the Session Description Protocol", RFC 7104,
DOI 10.17487/RFC7104, January 2014,
<http://www.rfc-editor.org/info/rfc7104>.
[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, <http://www.rfc-editor.org/info/rfc7728>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. 14.2. Informative References
Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
DOI 10.17487/RFC7741, March 2016,
<http://www.rfc-editor.org/info/rfc7741>.
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, Q., and C. Perkins, 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",
draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
December 2015. December 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-31 (work in progress), June 2016.
[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 25, line 50 skipping to change at page 30, line 30
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc4733>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>. <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
skipping to change at page 26, line 30 skipping to change at page 31, line 20
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc6236>.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>.
[RFC7104] Begen, A., Cai, Y., and H. Ou, "Duplication Grouping
Semantics in the Session Description Protocol", RFC 7104,
DOI 10.17487/RFC7104, January 2014,
<http://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>. <http://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>. <http://www.rfc-editor.org/info/rfc7667>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
DOI 10.17487/RFC7741, March 2016,
<http://www.rfc-editor.org/info/rfc7741>.
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 -04 and -05 A.1. Modifications Between WG Version -05 and -06
o Added section on RTP Aspects
o Added a requirement (5-4) on that capability exchange must be
capable of handling multi RTP stream cases.
o Added extmap attribute also on first signalling example as it is a
recommended to use mechanism.
o Clarified the definition of the simulcast attribute and how
simulcast streams relates to simulcast formats and SCIDs.
o Updated References list and moved around some references between
informative and normative categories.
o Editorial improvements and corrections.
A.2. 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 27, line 19 skipping to change at page 32, line 46
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.
A.2. Modifications Between WG Version -03 and -04 A.3. 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.
A.3. Modifications Between WG Version -02 and -03 A.4. 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.
A.4. Modifications Between WG Version -01 and -02 A.5. 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.5. Modifications Between WG Version -00 and -01 A.6. Modifications Between WG Version -00 and -01
o No changes. Only preventing expiry. o No changes. Only preventing expiry.
A.6. Modifications Between Individual Version -00 and WG Version -00 A.7. 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 80 Stockholm SE-164 60 Stockholm
Sweden Sweden
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 2 Farogatan 2
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
 End of changes. 85 change blocks. 
240 lines changed or deleted 522 lines changed or added

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