draft-ietf-mmusic-sdp-simulcast-06.txt   draft-ietf-mmusic-sdp-simulcast-07.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: May 4, 2017 S. Nandakumar Expires: August 4, 2017 S. Nandakumar
M. Zanaty M. Zanaty
Cisco Cisco
October 31, 2016 January 31, 2017
Using Simulcast in SDP and RTP Sessions Using Simulcast in SDP and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-06 draft-ietf-mmusic-sdp-simulcast-07
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 May 4, 2017. This Internet-Draft will expire on August 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Detailed Description . . . . . . . . . . . . . . . . . . . . 9 6. Detailed Description . . . . . . . . . . . . . . . . . . . . 9
6.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 9 6.1. Simulcast Attribute . . . . . . . . . . . . . . . . . . . 10
6.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11 6.2. Simulcast Capability . . . . . . . . . . . . . . . . . . 11
6.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 13 6.3. Offer/Answer Use . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 13 6.3.1. Generating the Initial SDP Offer . . . . . . . . . . 14
6.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 14 6.3.2. Creating the SDP Answer . . . . . . . . . . . . . . . 14
6.3.3. Offerer Processing the SDP Answer . . . . . . . . . . 15 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. Use with Declarative SDP . . . . . . . . . . . . . . . . 15 6.4. Use with Declarative SDP . . . . . . . . . . . . . . . . 16
6.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16 6.5. Relating Simulcast Streams . . . . . . . . . . . . . . . 16
6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16 6.6. Signaling Examples . . . . . . . . . . . . . . . . . . . 16
6.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17 6.6.1. Single-Source Client . . . . . . . . . . . . . . . . 17
6.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18 6.6.2. Multi-Source Client . . . . . . . . . . . . . . . . . 18
7. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. RTP Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Outgoing from Endpoint with Media Source . . . . . . . . 21 7.1. Outgoing from Endpoint with Media Source . . . . . . . . 21
7.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21 7.2. RTP Middlebox to Receiver . . . . . . . . . . . . . . . . 21
7.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 23 7.2.1. Media-Switching Mixer . . . . . . . . . . . . . . . . 23
7.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24 7.2.2. Selective Forwarding Middlebox . . . . . . . . . . . 24
7.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25 7.3. RTP Middlebox to RTP Middlebox . . . . . . . . . . . . . 25
8. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26 8. Network Aspects . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26 8.1. Bitrate Adaptation . . . . . . . . . . . . . . . . . . . 26
9. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 28 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 29 14.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 31 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 32
A.1. Modifications Between WG Version -05 and -06 . . . . . . 32 A.1. Modifications Between WG Version -05 and -06 . . . . . . 32
A.2. Modifications Between WG Version -04 and -05 . . . . . . 32 A.2. Modifications Between WG Version -04 and -05 . . . . . . 32
A.3. Modifications Between WG Version -03 and -04 . . . . . . 32 A.3. Modifications Between WG Version -03 and -04 . . . . . . 33
A.4. Modifications Between WG Version -02 and -03 . . . . . . 33 A.4. Modifications Between WG Version -02 and -03 . . . . . . 33
A.5. Modifications Between WG Version -01 and -02 . . . . . . 33 A.5. Modifications Between WG Version -01 and -02 . . . . . . 33
A.6. Modifications Between WG Version -00 and -01 . . . . . . 34 A.6. Modifications Between WG Version -00 and -01 . . . . . . 34
A.7. Modifications Between Individual Version -00 and WG A.7. Modifications Between Individual Version -00 and WG
Version -00 . . . . . . . . . . . . . . . . . . . . . . . 34 Version -00 . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 42 skipping to change at page 3, line 42
e.g. the same video source encoded with different video encoder types e.g. the same video source encoded with different video encoder types
or image resolutions. This can be done in several ways and for or image resolutions. This can be done in several ways and for
different purposes. This document focuses on the case where it is different purposes. This document focuses on the case where it is
desirable to provide a media source as multiple encoded streams over desirable to provide a media source as multiple encoded streams over
RTP [RFC3550] towards an intermediary so that the intermediary can RTP [RFC3550] towards an intermediary so that the intermediary can
provide the wanted functionality by selecting which RTP stream(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.
The intended scope of the defined mechanism is to support negotiation
and usage of simulcast when using SDP offer/answer and media
transport over RTP. The media transport topologies considered are
point to point RTP sessions as well as centralized multi-party RTP
sessions, where a media sender will provide the simulcasted streams
to an RTP middlebox or endpoint, and middleboxes may further
distribute the simulcast streams to other middleboxes or endpoints.
Usage of multicast or broadcast transport is out of scope and left
for future extension.
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]. The following terms are [RFC7656], and RTP Topologies [RFC7667]. The following terms are
especially noted or here defined: 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",
skipping to change at page 7, line 37 skipping to change at page 7, line 43
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:
REQ-1: Identification. It must be possible to identify a set of REQ-1: Identification:
simulcasted RTP streams as originating from the same media source:
REQ-1.1: In SDP signaling. REQ-1.1: It must be possible to identify a set of simulcasted RTP
streams as originating from the same media source in SDP
signaling.
REQ-1.2: On RTP/RTCP level, at least with prior knowledge of SDP REQ-1.2: An RTP endpoint must be capable of identifying the
(or similar) signaling. simulcast stream a received RTP stream is associated with,
knowing the content of the SDP signalling.
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 9, line 36 skipping to change at page 9, line 42
RTP payload format restrictions an RTP stream adheres to. This RTP payload format restrictions an RTP stream adheres to. This
complements and effectively extends simulcast stream complements and effectively extends simulcast stream
identification and configuration possibilities that could be identification and configuration possibilities that could be
provided by using only SDP formats as identifier. Use of multiple provided by using only SDP formats as identifier. Use of multiple
RTP streams with the same (non-redundancy) media type in the RTP streams with the same (non-redundancy) media type in the
context of a single media source, where those RTP streams are context of a single media source, where those RTP streams are
using different RtpStreamId, is a strong but not totally using different RtpStreamId, is a strong but not totally
unambiguous indication of those RTP streams being part of a unambiguous indication of those RTP streams being part of a
simulcast. simulcast.
o It is possible, but not required to use source-specific signaling o It is possible to use source-specific signaling [RFC5576] with the
[RFC5576] with the proposed solution. proposed solution, but it is only in certain cases possible to
learn from that signaling which SSRC will belong to a particular
simulcast stream.
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
used. The section is concluded with a number of examples. used. The section is concluded with a number of examples.
6.1. Simulcast Attribute 6.1. Simulcast Attribute
skipping to change at page 10, line 22 skipping to change at page 10, line 29
; 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. or "recv"), followed by a list of one or more simulcast streams.
Each simulcast stream consists of one or more alternative simulcast Each simulcast stream consists of one or more alternative simulcast
formats. Each simulcast format is identified by a simulcast stream formats. Each simulcast format is identified by a simulcast stream
identification (SCID). The SCID MUST have the form of an RTP stream identifier (SCID). The SCID MUST have the form of an RTP stream
identifier, as described by RTP Payload Format Restrictions 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 simulcast stream is separated In the list of simulcast streams, each simulcast stream is separated
by a semicolon (";"). Each simulcast stream can in turn be offered by a semicolon (";"). Each simulcast stream can in turn be offered
in one or more alternative formats, represented by SCIDs, separated in one or more alternative formats, represented by SCIDs, separated
by a comma (","). Each SCID can also be specified as initially by a comma (","). Each SCID can also be specified as initially
paused [RFC7728], indicated by prepending a "~" to the SCID. The paused [RFC7728], indicated by prepending a "~" to the SCID. The
reason to allow separate initial pause states for each SCID is that reason to allow separate initial pause states for each SCID is that
pause capability can be specified individually for each RTP payload pause capability can be specified individually for each RTP payload
skipping to change at page 11, line 34 skipping to change at page 11, line 45
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, MUST NOT be used by on SDP session level is undefined, MUST NOT be used by
implementations of this specification and MUST be ignored if received implementations of this specification and MUST be ignored if received
on session level. Extensions to this specification MAY define such on session level. Extensions to this specification MAY define such
session level usage. The meaning of including multiple "a=simulcast" session level usage. The meaning of including multiple "a=simulcast"
lines in a single SDP media description is undefined, MUST NOT be lines in a single SDP media description is undefined, MUST NOT be
used by implementations of this specification and any additional used by implementations of this specification, and any additional
"a=simulcast" lines beyond the first under an "m=" line MUST be "a=simulcast" lines beyond the first in a media description MUST be
ignored if received. ignored if received.
There are separate and independent sets of simulcast streams in send There are separate and independent sets of simulcast streams in send
and receive directions. When listing multiple directions, each and receive directions. When listing multiple directions, each
direction MUST NOT occur more than once on the same line. direction MUST NOT occur more than once on the same line.
Simulcast streams using undefined SCID MUST NOT be used as valid Simulcast streams using undefined SCID MUST NOT be used as valid
simulcast streams by an RTP stream receiver. The direction for an simulcast streams by an RTP stream receiver. The direction for an
SCID MUST be aligned with the direction specified for the SCID MUST be aligned with the direction specified for the
corresponding RTP stream identifier on the "a=rid" line. corresponding RTP stream identifier on the "a=rid" line.
The listed number of simulcast streams for a direction sets a limit The listed number of simulcast streams for a direction sets a limit
to the number of supported simulcast streams in that direction. The to the number of supported simulcast streams in that direction. The
order of the listed simulcast streams in the "send" direction order of the listed simulcast streams in the "send" direction
suggests a proposed order of preference, in decreasing order: the suggests a proposed order of preference, in decreasing order: the
SCID listed first is the most preferred and subsequent streams have SCID listed first is the most preferred and subsequent streams have
progressively lower preference. The order of the listed SCID in the progressively lower preference. The order of the listed SCID in the
"recv" direction expresses a preference which simulcast streams that "recv" direction expresses which simulcast streams that are
are preferred, with the leftmost being most preferred. This can be preferred, with the leftmost being most preferred. This can be of
of importance if the number of actually sent simulcast streams have importance if the number of actually sent simulcast streams have to
to be reduced for some reason. 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.
Use of more than a single, alternative simulcast format for a Use of more than a single, alternative simulcast format for a
simulcast stream MAY be specified as part of the attribute parameters simulcast stream MAY be specified as part of the attribute parameters
by expressing the simulcast stream as a comma-separated list of by expressing the simulcast stream as a comma-separated list of
alternative 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 across 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
skipping to change at page 13, line 29 skipping to change at page 13, line 40
direction is sometimes not yet known. direction is sometimes not yet known.
Use of the redundant audio data [RFC2198] format could be seen as a Use of the redundant audio data [RFC2198] format could be seen as a
form of simulcast for loss protection purposes, but is not considered form of simulcast for loss protection purposes, but is not considered
conflicting with the mechanisms described in this memo and MAY conflicting with the mechanisms described in this memo and MAY
therefore be used as any other format. In this case the "red" therefore be used as any other format. In this case the "red"
format, rather than the carried formats, SHOULD be the one to list as format, rather than the carried formats, SHOULD be the one to list as
a simulcast stream on the "a=simulcast" line. a simulcast stream on the "a=simulcast" line.
The media formats and corresponding characteristics of simulcast The media formats and corresponding characteristics of simulcast
streams SHOULD be chosen such that they are different, either as streams SHOULD be chosen such that they are different, e.g. as
different SDP formats with differing "a=rtpmap" and/or "a=fmtp" different SDP formats with differing "a=rtpmap" and/or "a=fmtp"
lines, as differently defined RTP payload format restrictions, or lines, or as differently defined RTP payload format restrictions. If
both. If this difference is not required, RTP duplication [RFC7104] this difference is not required, RTP duplication [RFC7104] procedures
procedures SHOULD be considered instead of simulcast. SHOULD be considered instead of simulcast. To avoid complications in
implementations, a single SCID MUST NOT occur more than once per
"a=simulcast" line. Note that this does not eliminate use of
simulcast as an RTP duplication mechanism, since it is possible to
define multiple different SCID that are effectively equivalent.
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"
skipping to change at page 14, line 13 skipping to change at page 14, line 27
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" Similarly, an answerer that receives an offer with the "a=simulcast"
attribute on session level SHALL remove it in the answer. An attribute on session level SHALL remove it in the answer. An
answerer that understands the attribute but receives multiple answerer that understands the attribute but receives multiple
"a=simulcast" attributes under the same "m=" line SHALL ignore and "a=simulcast" attributes in the same media description and that
remove all but the first in the answer. desires to use simulcast 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
skipping to change at page 16, line 5 skipping to change at page 16, line 16
6.4. Use with Declarative SDP 6.4. Use with Declarative SDP
This document does not define the use of "a=simulcast" in declarative This document does not define the use of "a=simulcast" in declarative
SDP, partly motivated by use of the simulcast format identification SDP, partly motivated by use of the simulcast format identification
[I-D.ietf-mmusic-rid] not being defined for use in declarative SDP. [I-D.ietf-mmusic-rid] not being defined for use in declarative SDP.
If concrete use cases for simulcast in declarative SDP are identified If concrete use cases for simulcast in declarative SDP are identified
in the future, we expect that additional specifications will address in the future, we expect that additional specifications will address
such use. such use.
Note: It may not be beneficial for declarative use to be limited
to a single media source per "m=" line, as elaborated further in
Section 9.
6.5. Relating Simulcast Streams 6.5. Relating Simulcast Streams
Simulcast RTP streams MUST be related on RTP level through Simulcast RTP streams MUST be related on RTP level through
RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP RtpStreamId [I-D.ietf-avtext-rid], as specified in the SDP
"a=simulcast" attribute (Section 6.2) parameters. This is sufficient "a=simulcast" attribute (Section 6.2) parameters. This is sufficient
as long as there is only a single media source per SDP media as long as there is only a single media source per SDP media
description. When using BUNDLE description. When using BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media [I-D.ietf-mmusic-sdp-bundle-negotiation], where multiple SDP media
descriptions jointly specify a single RTP session, the SDES MID descriptions jointly specify a single RTP session, the SDES MID
identification mechanism in BUNDLE allows relating RTP streams back identification mechanism in BUNDLE allows relating RTP streams back
to individual media descriptions, after which the above described to individual media descriptions, after which the above described
RtpStreamId relations can be used. Use of the RTP header extension RtpStreamId relations can be used. Use of the RTP header extension
[RFC5285] for both MID and RtpStreamId identifications can be [RFC5285] for both MID and RtpStreamId identifications can be
important to ensure rapid initial reception, required to correctly important to ensure rapid initial reception, required to correctly
interpret and process the RTP streams. Implementers of this interpret and process the RTP streams. Implementers of this
specification MUST support the RTCP source description (SDES) item specification MUST support the RTCP source description (SDES) item
method and SHOULD support RTP header extension method to signal method and SHOULD support RTP header extension method to signal
RtpStreamId on RTP level. RtpStreamId on RTP level.
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 (and SCID) on a per-RTP
This corresponds to the existing (non-simulcast) SDP offer/answer packet basis. This corresponds to the existing (non-simulcast) SDP
case when multiple formats are included on the "m=" line in the SDP offer/answer case when multiple formats are included on the "m=" line
answer. in the SDP answer, enabling per-RTP packet change of RTP payload
type.
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
centralized media topology with an RTP mixer. centralized media topology with an RTP mixer.
+---+ +-----------+ +---+ +---+ +-----------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | | +---+ +---+ | | +---+
| Mixer | | Mixer |
skipping to change at page 21, line 13 skipping to change at page 21, line 13
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. RTP Aspects 7. RTP Aspects
This section discusses what the different entities in a simulcast This section discusses what the different entities in a simulcast
media path can expect to happen on RTP level. This is explored from media path can expect to happen on RTP level. This is explored from
source to sink by starting in an endpoint with a media source that is source to sink by starting in an endpoint with a media source that is
simulcasted to a RTP middlebox. That RTP middlebox sends media simulcasted to an RTP middlebox. That RTP middlebox sends media
sources both to other RTP middleboxes (cascaded middleboxes), as well sources both to other RTP middleboxes (cascaded middleboxes), as well
as selecting some simulcast format of the media source and sending it as selecting some simulcast format of the media source and sending it
to receiving endpoints. Different types of RTP middleboxes and their to receiving endpoints. Different types of RTP middleboxes and their
usage of the different simulcast formats results in several different usage of the different simulcast formats results in several different
behaviors. behaviors.
7.1. Outgoing from Endpoint with Media Source 7.1. Outgoing from Endpoint with Media Source
The most straightforward simulcast case is the RTP streams being The most straightforward simulcast case is the RTP streams being
emitted from the endpoint that originates a media source. When emitted from the endpoint that originates a media source. When
skipping to change at page 25, line 39 skipping to change at page 25, line 39
7.3. RTP Middlebox to RTP Middlebox 7.3. RTP Middlebox to RTP Middlebox
This relates to the transmission of simulcast streams between RTP This relates to the transmission of simulcast streams between RTP
middleboxes or other usages where one wants to enable the delivery of middleboxes or other usages where one wants to enable the delivery of
multiple simultaneous simulcast streams per media source, but the multiple simultaneous simulcast streams per media source, but the
transmitting entity is not the originating endpoint. For a transmitting entity is not the originating endpoint. For a
particular direction between middlebox A and B, this looks very particular direction between middlebox A and B, this looks very
similar to the originating to middlebox case on a media source basis. similar to the originating to middlebox case on a media source basis.
However, in this case there is usually multiple media sources, However, in this case there is usually multiple media sources,
originating from multiple endpoints. This can create situations originating from multiple endpoints. This can create situations
where limitations in the number of simultaneous received media where limitations in the number of simultaneously received media
streams can arise, for example due to limitation in network streams can arise, for example due to limitation in network
bandwidth. In this case, a subset of not only the simulcast streams, bandwidth. In this case, a subset of not only the simulcast streams,
but also media sources can be selected. This results in that but also media sources can be selected. This results in that
individual RTP streams can be become paused at any point and later individual RTP streams can be become paused at any point and later
being resumed based on various criteria. being resumed based on various criteria.
The MIDs used between A and B are the ones agreed between these two The MIDs used between A and B are the ones agreed between these two
identities in signalling. The RtpStreamId values will also be identities in signalling. The RtpStreamId values will also be
provided to ensure explicit information about which simulcast stream provided to ensure explicit information about which simulcast stream
they are. The RTP stream to MID and RtpStreamId associations should they are. The RTP stream to MID and RtpStreamId associations should
skipping to change at page 26, line 42 skipping to change at page 26, line 42
8.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 and ordering of alternative simulcast
resume capability and that would be given such low bitrate by the formats Section 6.2. Simulcast streams that have pause/resume
adaptation process that they are considered not really useful can be capability and that would be given such low bitrate by the adaptation
temporarily paused until the limiting condition clears. process that they are considered not really useful can be temporarily
paused until the limiting condition clears.
9. 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
skipping to change at page 29, line 13 skipping to change at page 29, line 19
progress), October 2016. progress), October 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-36 (work in progress), October 2016. 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-14 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), September 2016. (work in progress), December 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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>.
 End of changes. 31 change blocks. 
50 lines changed or deleted 68 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/