Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers
EricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.com
Transport
MMUSIC Working GroupRTPSDPMultiplexingRTCWEBWEBBrowser
This document defines how to use the Session Description Protocol (SDP) in order
to negotiate the usage of multiplexed media.
In the IETF RTCWEB WG, a need for media multiplexing has been identified. In order
to be able to establish media sessions with entities that do not support multiplexing,
there needs to be a mechanism to negotiate whether multiplexing will be used or not.
This document defines a mechanism to negotiate the usage of multiplexing using
the Session Description Protocol (SDP) , by indicating identical "m=" line port number values to every
media stream that would be part of a multiplex.
As defined in RFC 4566, the semantics of multiple "m=" lines using the same transport
address 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. Therefore,
this specification defines an SDP grouping framework extension, MULTIPLEX, which is used to group media that is part
of a multiplex.
The mechanism is backward compatible. Entities that do not support the MULTIPLEX grouping
extension, or do not want to enable multiplexing within the session associated with the
SDP offer, are expected to generate a "normal" SDP answer, are expected to generate a
"normal" SDP answer, using different port numbers for each "m=" line, to the SDP offer.
The offerer will still use a single port for each media, but as the answerer will use separate
ports there will be no multiplexing of media 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 BCP 14, RFC 2119 .
The mechanism in this specification only applies to SDP, when used together with the
SDP offer/answer media negotiation mechanism .
This section defines a new SDP Grouping Framework extension, MULTIPLEX.
The MULTIPEX extension can be indicated using an SDP session-level "a=group"
attribute. Every "m=" line that is grouped together, using an SDP media-level
"a=mid" attribute, is part of a specific multiplex.
OPEN ISSUE: We need a reference to the specification defining the actual
multiplexing mechanism.
This section defines the SDP offer/answer procedures for
negotiating the usage of multiplexing.
When an SDP offerer wants to offer multiplexed media, it inserts
the same port number value for each "m=" line that is part of
the offered multiplex. In addition, the SDP offerer inserts
an SDP session-level "a=group" attribute, with a "MULTIPLEX" value, and
assigns an SDP media-level "a=mid" attribute value for each
"m=" line that is part of the offered multiplex.
NOTE: If the SDP offerer wants to disable a specific stream within a
multiplex, it will use a zero port number value for the "m=" line associated
with the stream.
If the associated SDP answer includes the session-level "a=group" attribute,
with a "MULTIPLEX" value, and associated "m=" lines with identical
port number values, the SDP offerer can enable media multiplexing between
the entities.
If the associated SDP does not include the session-level "a=group" attribute,
with a "MULTIPLEX" value, the SDP offerer MUST NUT enable media multiplexing
between the entities, even if two or more "m=" lines in the SDP answer contain
identical port number values.
If the SDP answer indicates that multiplexing will not be enabled, the offerer
will still receive multiple media on the single port that it included in the
SDP offer, and it normally will be able to separate each individual media.
The default mechanism for doing this is by using a 5-tuple based mapping for
each individual media. If the offerer is aware of the SSRC values that the
remote peer will use in the media it sends, and the values will be unique
for each media, the offerer can also separate media based on the SSRC values.
NOTE: Assuming symmetric media is used, the offerer can use the port information
from the SDP answer in order to create the 5-tuple mapping for each media.
If the offerer is not able to separate multiple media on a single port, it MUST
send a new SDP offer, without using the "MULTIPLEX" grouping, where each media (m= line)
is given a different port number value.
NOTE: If the SDP offer is rejected, and the SDP offerer has reasons to
believe that the rejection is due to the fact that the SDP offer
contained identical "m=" line port number values, the SDP offerer
might send a new SDP offer, without offered multiplex (and with
separate port number values for each "m=" line).
When an SDP answerer receives an SDP offer, offering multiplexing, if
the SDP answerer accepts the offered multiplexing, it MUST include
a session-level "a=group" attribute, with a "MULTIPLEX" value, in the
SDP answer. In addition, the SDP answerer assigns an SDP media-level "a=mid"
attribute value for each "m=" line that is part of the multiplex.
If the SDP answerer does not accept the offered multiplex, it MUST NOT
include a session-evel "a=group" attribute, with a "MULTIPLEX" value, in
the SDP answer. In addition, it MUST assign separate port number values
for each "m=" line in the SDP answer.
NOTE: If the SDP answerer wants to disable a specific stream within a
multiplex, it will use a zero port number value for the "m=" line associated
with the stream.
When an entity that supports the Interactive Connectivity Establishment (ICE)
mechanism sends an SDP offer,
it MUST include ICE candidates for each "m=" line of the SDP offer, even if it offers
multiplexing and the SDP "m=" line port value numbers are identical. This is true also
for subsequent SDP offers, when the usage of multiplexing has previously been negotiated.
When an entity that supports ICE and multiplexing receives an SDP offer, offering multiplexing
and ICE, if it accepts the multiplex, and ICE, it MUST include ICE candidates for each "m=" line
of the SDP answer, even if the SDP "m=" line port value numbers are identical.
The candidate information inserted in an SDP offer or answer MUST be identical for each "m=" line
associated with a specific MULTIPLEX SDP group.
Once the usage of multiplexing has been negotiated, ICE connectivity checks and keep-alives
only needs to be performed for the whole multiplex, represented by a MULTIPLEX SDP group, instead
of for individual m= lines associated with the multiplex.
TBA
The example below shows an SDP offer, where multiplexing is offered. The example also
shows two SDP answer alternatives: one where multiplexing is accepted, and one where
multiplexing is rejected (or, not even supported) by the SDP answerer.
This document requests IANA to register the new SDP Grouping semantic
extension called MULTIPLEX.
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.
[RFC EDITOR NOTE: Please remove this section when publishing]Changes from draft-holmberg-mmusic-sdp-multiplex-negotiation-xx