Protocol Action: 'Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)' to Proposed Standard (draft-ietf-mmusic-ice-sip-sdp-39.txt)

[The IESG <[e-mail]>]

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.