Technical Summary
This specification defines a new Session Description Protocol (SDP) Grouping
Framework extension, 'BUNDLE'. The extension can be used with the
SDP Offer/Answer mechanism to negotiate the usage of a single transport
(5-tuple) for sending and receiving media described by multiple SDP media
descriptions ("m=" sections). Such transport is referred to as a BUNDLE
transport, and the media is referred to as bundled media. The "m=" sections
that use the BUNDLE transport form a BUNDLE group.
To assist endpoints in negotiating the use of bundle this specification defines
a new SDP attribute, 'bundle-only', which can be used to request that specific
media is only used if bundled. The specification also updates RFC 3264,
to allow assigning a zero port value to a "m=" section without meaning that
the media described by the "m=" section is disabled or rejected.
When RTP-based media is used, there are multiple ways to correlate bundled
RTP packets with the appropriate "m=" section. This specification defines a
new Real-time Transport Control Protocol (RTCP) source description (SDES)
item and a new RTP header extension that provides an additional way to do
this correlation by using them to carry a value that associates the RTP/RTCP
packets with a specific "m=" section.
Working Group Summary
The mechanism has been worked on since 2011, and it has been a WG
document since 2012. Originally, there were different approaches to
solving the problem which resulted in significant disagreements and
discussion in the WG about the best way forward. Ultimately, a
compromise proposal agreeable to all parties was reached (as reflected
in the document), and it has been in place for quite a while with very
solid consensus. There has been a number of technical details to sort
out, and the document has also received a lot of editorial feedback.
The current version addresses all known technical issues as well as
editorial comments that can reasonably be addressed (while respecting
previous WG discussions/consensus and also considering sometimes
conflicting editorial comments).
Document Quality
The protocol is an important part of the RTCWeb suite of specifications
and there are existing implementations of earlier versions of the specification.
Personnel
Flemming Andreasen is the Document Shepherd
Ben Campbell is the Responsile Area Director.
RFC Editor Note
RFC Editor Note
Please change "criterium" to "criterion" in sections 7.3.2 and 7.3.3.
Please change the following two paragraphs in section 9.2, right before the first indented list of steps:
OLD:
Applications can implement RTP stacks in many different ways. The
algorithm below details one way that RTP streams can be associated
with "m=" sections, but is not meant to be prescriptive about exactly
how an RTP stack needs to be implemented. Applications MAY use any
algorithm that achieves equivalent results to those described in the
algorithm below.
To prepare to associate RTP streams with the correct "m=" section,
the following steps MUST be followed for each BUNDLE group:
NEW:
Applications can implement RTP stacks in many different ways. The
example algorithm below details one way that RTP streams can be associated
with "m=" sections, but is not meant to be prescriptive about exactly
how an RTP stack needs to be implemented. Applications MAY use any
algorithm that achieves equivalent results to those described in the
example algorithm.
To prepare to associate RTP streams with the correct "m=" section,
the example algorithm takes the following steps for each BUNDLE group:
END.