Session Description Protocol (SDP) Capability Negotiation
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, mmusic mailing list <firstname.lastname@example.org>, mmusic chair <email@example.com> Subject: Protocol Action: 'SDP Capability Negotiation' to Proposed Standard The IESG has approved the following document: - 'SDP Capability Negotiation ' <draft-ietf-mmusic-sdp-capability-negotiation-13.txt> as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-13.txt
Technical Summary This document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Working Group Summary The MMUSIC Working Group has consensus to publish this document as a Proposed Standard. Document Quality This mechanism was specifically designed to allow some shortcomings seen in the field that could help deploy secure RTP (SRTP). See page 11 of the document, these SDP extensions allow an SDP agent to offer both RTP and SRTP as alternatives, with SRTP being the preferred option using the Offer/Answer mechanism. Personnel The Proto Shepherd is Jean-Francois Mule, and the Responsible Area Director is Robert Sparks. Cullen Jennings was the Responsible Area Director for the majority of this document's IESG processing. RFC Editor Note (These notes apply to version 13 of the document) Please delete the entire following paragraph from Section 3.10: The Transport Independent Application Specific Maximum (TIAS) bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and alleviate bandwidth variability concerns due to different transport protocols, since there are some inconsistencies between [RFC3264] and [RFC3890]. More specifically, [RFC3264] defines the bandwidth parameter to apply to the receive direction for unicast streams, whereas [RFC3890] intends to use bandwidth in the send direction. Implementers are encouraged to look for an expected future solution to this. and remove the following Informative Reference: [RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP).", RFC 3890, September 2004.