]>
Using SSRC with WebRTC SimulcastGoogleharald@alvestrand.noGeneral
RTCWEB Working GroupInternet-DraftThis document describes a convention for sending “a=ssrc” attributes
in SDP together with “a=simulcast” attributes. This allows SFUs that
need SSRC information to have this info easily accessible.Given that it is intended as an interim measure, it does not aim for
being published as an RFC.In developing the WebRTC specification, the IETF decided on a
form of simulcast that doesn’t require fixed SSRC allocation, but rather
used a combination of SDP tags (a=rid) and RTP header
extensions (RTPStreamId)
to describe the mapping between simulcast layers and RTP streams.The SDP format is described in .This posed a problem for some SFUs, which required information on what
SSRCs the incoming streams were going to appear on in order to be configured
correctly.This document gives a convention for adding information about SSRCs to the
SDP produced by conformant WebRTC implementations in order to make this
information available.This document does not specify an Internet standard. It is an interim
measure, intended to be useful in the time between the introduction of
RID-based simulcast in browsers and the full support of RID-based simulcast
by SFUs.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.The syntax for representing SSRC information is taken from .Each media section in the SDP contains one a=ssrc attribute
per simulcast stream, formatted as a=ssrc:<ssrc> cname:<cname>. The
cname is the sender’s single cname as defined in ;
carrying some attribute is required by the “a=ssrc” syntax, and sending the
cname is compatible with what has been done in other instances.The list of SSRCs used is declared in an attribute with the FID
(Flow Identification) semantic, as defined in .The order of SSRCs in the a=ssrc-group attribute MUST match the order of the
rid attributes in the corresponding streams in the “send” part of the
a=simulcast: attribute.It is RECOMMENDED that both the a=rid: attributes and the a=ssrc: attributes
appear in the same order as the order in the a=simulcast and a=ssrc-group
attributes.It is RECOMMENDED not to use RTX with this configuration, since the inclusion
of the required declarations for associating RTX SSRCs with their main SSRCs
would make the SDP unwieldy and hard to interpret correctly.If an SFU wishes to request that a browser send SSRC information, it should
send an offer containing the line “a=x-please-send-ssrcs”, together with a
line requesting simulcast:The SFU can detect whether the request has been honored by looking for
a=ssrc attributes in the responding answer.If a Javascript application wishes to request that the browser generate
offers containing SSRC, it can include the non-standard attribute
“showSsrcInSimulcastOffer” in the RTCPeerConnection constructor:It is possible to verify that the request is understood by checking for
the presence of this attribute in the RTCPeerConnection parameters:Formally, this amounts to changing the API of a W3C specification, but adding
nonstandard attributes to an initialization dictionary has been done before
in other contexts; it seems like a relatively harmless thing to do, but should
be reviewed in the W3C WEBRTC WG anyway.This specification is intended to give SFU authors time to convert
to the new mechanism. Since the invocation of this mechanism is explicit,
it is easy to check on what the usage is, and emit deprecation warnings;
those should probably be emitted from day 1.Once enough time has passed, this mechanism can be removed.NOTE IN DRAFT: The goal is to make this section empty.The SSRC-group “FID” was picked because it seemed to have the right semantic,
but it’s not clear what it’s been used for elsewhere. Chrome has been using
the group “SIM” without registering it; this might be a better choice.It’s been suggested that it’s better to replace the a=ssrc-group: line with
new tag fields either on the a=ssrc: lines or the a=rid: lines, thus giving
explicit correlation. This, however, breaks the standard format of those
lines. Inventing new syntax for an interim solution seems like a Bad Thing.People have asked whether and how this document should be published. If it
makes sense to publish it as a historical record, it might make sense to
publish as an RFC; it does not make sense to the author to ask for standards
track publication. At the moment, it claims that publication is not sought.This document describes two existing mechanisms: a=simulcast and
a=ssrc-group. Each of these is defined in an RFC with security considerations.The only added attack surface here is the ability to create mismatches
between the two lists of simulcast RTP streams, causing different
implementations to choose different streams to display. This is a special
instance of the general rule that “people who can modify your SDP can mess
things up”; normal precautions when passing SDP around should be adequate.This document has no IANA actions.If it were to be published, this section would have to request IANA to
register the “please-send-ssrc” attribute, and if it mints a new group
semantic for a=ssrc-group, this will also have to be registered.If the document succeeds in being transitory in nature, registration
may not be needed.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Source-Specific Media Attributes in the Session Description Protocol (SDP)The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]The Session Description Protocol (SDP) Grouping FrameworkIn this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS-TRACK]RTP Stream Identifier Source Description (SDES)This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair.RTP Payload Format RestrictionsIn this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" ("restriction identifier") SDP attribute to unambiguously identify the RTP Streams within an RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document.Using Simulcast in SDP and RTP SessionsIn some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Web Real-Time Communication (WebRTC): Media Transport and Use of RTPThe Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported.Many thanks to Amit Hilbuch, Adam Roach, Bernard Aboba, Philip Hancke
and many others who have given input to the design of this mechanism.