The IESG has approved the following document: - 'Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)' (draft-ietf-mmusic-ice-sip-sdp-39.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 Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ Technical Summary This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. Working Group Summary The document has been in progress since 2013 (as a companion document to the now published RFC 8445). The document has generally been non-controversial, however more recently (starting in July 2018 at IETF 102), the lack of DNS and mDNS support was raised as a concern by a few people. A consensus call to leave it out was made at IETF 102. Recent MMUSIC mailing list discussions raised the issue again, however in the interest of moving the document forward, the previous consensus was reconfirmed, with provisions in this document to enable DNS procedures to be added as an extension later on. Document Quality The document obseletes RFC 5245, which has a number of existing implementations. The document is one of the deliverables needed by RTCWeb, and as such is expected to see significant implementation. Roman Shpount in particular has been instrumental in moving this document forward by resolving a variety of issues and contributing specific text proposals. Christer Holmberg and Adam Roach have been very helpful as well. Personnel Flemming Andreasen is the Document Shepherd Adam Roach is the Responsible Area Director RFC Editor Note Please make the following three changes to the document prior to publication. --------------------------------------------------------------------------- Section 4.2.4: OLD Once an agent has provided its local candidates to its peer in an SDP offer or answer, the agent MUST be prepared to receive STUN connectivity check Binding requests on those candidates. NEW Once an agent has provided its local candidates to its peer in an SDP offer or answer, the agent MUST be prepared to receive STUN [RFC5389] connectivity check Binding requests on those candidates. Also, please add RFC 5389 as a normative reference. --------------------------------------------------------------------------- Section 10.2: OLD A registration request MUST include the following information: o The ICE option identifier to be registered o Short description of the ICE extension to which the option relates o Reference(s) to the specification defining the ICE option and the related extensions NEW A registration request MUST include the following information: o The ICE option identifier to be registered o Name and email address of organization or individuals having change control o Short description of the ICE extension to which the option relates o Reference(s) to the specification defining the ICE option and the related extensions --------------------------------------------------------------------------- Section 10.3: OLD A registration request MUST include the following information: o The name of the attribute extension. o A short description of the attribute extension. o A reference to a specification that describes the semantics, usage and possible values of the attribute extension. NEW A registration request MUST include the following information: o The name of the attribute extension. o A short description of the attribute extension. o Name and email address of organization or individuals having change control o A reference to a specification that describes the semantics, usage and possible values of the attribute extension. _______________________________________________ IETF-Announce mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-announce
