Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers
EricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.comGoogleKungsbron 2Stockholm11122Swedenharald@alvestrand.no
Transport
MMUSIC Working GroupRTPSDPBundleMultiplexingRTCWEBCLUERTCWEBMMUSICAVTWEBBrowser
This specification defines a new SDP Grouping Framework SDP grouping framework
extension, "BUNDLE", that can be used with the Session Description Protocol (SDP)
Offer/Answer mechanism to negotiate the usage of bundled media, which refers
to the usage of a single 5-tuple for media associated with multiple SDP media
descriptions ("m=" lines).
In the IETF RTCWEB WG, a need to use a single 5-tuple for sending and receiving media
associated with multiple SDP media descriptions ("m=" lines) has been identified. This would e.g. allow the usage
of a single set of Interactive Connectivity Establishment (ICE) candidates for multiple media descriptions. Normally
different media types (audio, video etc) will be described using different media
descriptions.
This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be
used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers
to the usage of a single 5-tuple for media associated with multiple SDP media descriptions
("m=" lines).
When an endpoint generates an SDP Offer or SDP Answer , which includes a "BUNDLE" group, each "m=" line associated with the
group will share a single port number value.
As defined in RFC 4566 , the
semantics of multiple "m=" lines using the same port number value are undefined, and
there is no grouping defined by such means. Instead, an explicit grouping mechanism needs
to be used to express the intended semantics. This specification provides such extension.
When media is transported using the Real-Time Protocol (RTP) , the default assumption of the mechanism is that all
media associated with a "BUNDLE" group will form a single RTP Session . However, future specifications can extend the mechanism,
in order to negotiate RTP Session multiplexing, i.e. "BUNDLE" groups where media associated
with a group form multiple RTP Sessions.
The mechanism is backward compatible. Entities that do not support the "BUNDLE" grouping
extension, or do not want to enable the mechanism for a given session, are expected to
generate a "normal" SDP Answer, using different port number values for each "m=" line, to
the SDP Offer. The SDP Offerer
will still use a single port number value for each media, but as the SDP Answerer
will use separate ports a single
5-tuple will not be used for media associated with multiple "m=" lines between the endpoints.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 .
5-tuple: A collection of the following values: source address, source port,
destination address, destination port and protocol.
Bundled media: Two or more RTP streams using a single 5-tuple. The RTCP
streams associated with the RTP streams also use a single 5-tuple, which might
be the same, but can also be different, as the one used by the RTP streams.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 .
The mechanism in this specification only applies to the Session Description Protocol (SDP)
, when used together with the
SDP Offer/Answer mechanism .
This section defines a new SDP Grouping Framework extension, "BUNDLE".
The "BUNDLE" extension can be indicated using an SDP session-level 'group'
attribute. Each SDP media description ("m=" line) that is grouped together,
using an SDP media-level 'mid' attribute, is part of a specific "BUNDLE"
group.
When an SDP Offerer or SDP Answerer generates an SDP Offer or SDP Answer,
that describes bundled media, it MUST insert an SDP session-level 'group'
attribute, with a "BUNDLE" value, and assign SDP media-level 'mid' attribute
values to each "m=" line associated with the "BUNDLE" group.
In addition, the entity that generates the SDP Offer or SDP Answer MUST, for
each "m=" line that is part of the "BUNDLE" group:
1. Use the same port number value.2. Use the same connection data ("c=" line) value.3. Use the same SDP 'rtcp' attribute value, when used.4. Use the same ICE candidate values, when used.5. Insert an SDP 'rtpc-mux' attribute.
NOTE: If an entity wants to disable specific media ("m=" line)
associated with a "BUNDLE" group, it will use a zero port number value for
the "m=" line associated with the media.
When an SDP Offerer creates an SDP Offer, that offers bundled media, it MUST
create the SDP Offer according to the procedures in .
If the associated SDP Answer contains an SDP session-level 'group' attribute,
with a "BUNDLE" value, and the SDP Answer is created according to the proceudres
in (the same
port number value is used for each "m=" line associated with the "BUNDLE" group, etc),
the SDP Offerer can start using the same 5-tuple for sending and receiving media,
associated with the group, between the entities.
If the SDP Answer does not include a session-level SDP 'group' attribute, with a
"BUNDLE" value, the SDP Offerer cannot use the same 5-tuple for media associated
with multiple "m=" lines.
If the SDP Answererer indicates that it will not use bundled media, the SDP Offerer
will still use the single port number value for each "m= line" associated with the
offered "BUNDLE" group, and it will normally be able to separate each individual media.
The default mechanism for separating media received on a single IP address and port
doing this is by using a 5-tuple based mapping for each individual media. If the SDP
Offerer is aware of the Synchronization Source (SSRC) values that the SDP Answerer will use in the media it sends, and
the SSRC values will be unique for each media, the SDP Offerer can separate media based
on the SSRC values.
NOTE: Assuming symmetric media is used, the SDP Offerer can use the port information
from the SDP Answer in order to create the 5-tuple mapping for each media.
If the SDP Offerer is not able to separate multiple media received on a single
port, it MUST send a new SDP Offer, without offering bundled media, where a separate
port number value is provide for each "m=" line of the SDP Offer.
If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has reasons to
believe that the rejection is due to the usage of a single port number value for multiple
"m=" lines, the SDP Offerer SHOULD send a new SDP Offer, without a "BUNDLE" group,
where a separate port number value is provide for each "m=" line of the SDP offer.
When an SDP Answerer receives an SDP Offer, which offers bundled media, and the
SDP Answerer accepts the offered bundle group, the SDP Answerer MUST create an
SDP Answer according to the procedures in .
If the SDP Answerer does not accept the "BUNDLE" group in the SDP Offer, it MUST NOT
include a session-evel 'group' attribute, with a "BUNDLE" value, in
the associated SDP Answer. In addition, the SDP Answerer MUST provide separate
port number values for each "m=" line of the SDP Answer.
This section describes how SDP information, given for each media description,
is calculated into a single value for a "BUNDLE" group.
The total proposed bandwidth is the sum of the proposed bandwidth for each
"m=" line associated with a negotiated BUNDLE group.
When entities negotiate the usage of bundled media, the default assumption
is that all media associated with the bundled media will form a single RTP
session.
The usage of multiple RTP Sessions within a "BUNDLE" group is outside the scope
of this specification. Other specification needs to extend the mechanism in
order to allow negotiation of such bundle groups.
When a single RTP Session is used, media associated with all "m=" lines part
of a bundle group share a single SSRC numbering space.
In addition, the following rules and restrictions apply for a single RTP
Session:
- The dynamic payload type values used in the "m=" lines MUST NOT overlap.- The "proto" value in each "m=" line MUST be identical (e.g. RTP/AVPF).- A given SSRC SHOULD NOT transmit RTP packets using payload types that
originates from different "m=" lines.
NOTE: The last bullet above is to avoid sending multiple media types from the same SSRC.
If transmission of multiple media types are done with time overlap RTP and RTCP fails
to function. Even if done in proper sequence this causes RTP Timestamp rate switching
issues [ref to draft-ietf-avtext-multiple-clock-rates].
This section describes how to use the "BUNDLE" grouping mechanism together
with the Interactive Connectivity Establishment (ICE) mechanism .
When an ICE-enabled SDP Offerer sends an SDP offer, it MUST include ICE candidates
for each "m=" line associated with a "BUNDLE" group. The candidate values MUST be
identical for each "m=" line associated with the group. This rule applies
also to subsequent SDP Offers, when the usage of bundled media has already been
negotiated.
When an ICE-enabled SDP Answerer receives an SDP Offer, offering a "BUNDLE" group and
ICE, if the SDP Answerer enables ICE, MUST include ICE candidates for each "m=" line of
the SDP Answer. This also applies for "m=" lines that are part of a "BUNDLE" group, in
which case the candidate values MUST be identical for each "m=" line associated with
the group. This rule applies also to subsequent SDP Answers, when the usage
of bundled media has already been negotiated.
Once the usage of bundled media has been negotiated, ICE connectivity checks and keep-alives
only needs to be performed for the whole "BUNDLE" group, instead of for each individual m= line
associated with the group.
TBA
The example below shows an SDP Offer, where bundled media is offered. The example also
shows two SDP Answer alternatives: one where bundled media is accepted, and one where
bundled media is rejected (or, not even supported) by the SDP Answerer.
This document requests IANA to register the new SDP Grouping semantic
extension called BUNDLE.
The usage of the SDP grouping mechanism is based on a similar alternative
proposed by Harald Alvestrand. The SDP examples are also modified versions
from the ones in the Alvestrand proposal.
Thanks to the nice flight crew on AY 021 for providing good sparkling
wine, and a nice working athmosphere, for working on this draft.
[RFC EDITOR NOTE: Please remove this section when publishing]Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-00
Draft name changed.Harald Alvestrand added as co-author."Multiplex" terminology changed to "bundle".Added text about single versus multiple RTP Sessions.Added reference to RFC 3550.