The IESG has approved the following document: - 'Negotiating Media Multiplexing Using the Session Description Protocol (SDP)' (draft-ietf-mmusic-sdp-bundle-negotiation-52.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ 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 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.
