Protocol Action: 'Negotiating Media Multiplexing Using the Session Description Protocol (SDP)' to Proposed Standard (draft-ietf-mmusic-sdp-bundle-negotiation-52.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux