Skip to main content

Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-39

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: mmusic-chairs@ietf.org, adam@nostrum.com, mmusic@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-mmusic-ice-sip-sdp@ietf.org, fandreas@cisco.com, rfc-editor@rfc-editor.org
Subject: 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 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/


Ballot Text

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

draft-ietf-mmusic-ice-sip-sdp

Please make the following 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 5.5

OLD

   Once both agents have indicated the pacing value they with to use,
   both agents MUST use the larger of the indicated values.

NEW

  As defined in [RFC8445], regardless of the Ta value chosen for each agent,
  the combination of all transactions from all agents (if a given
  implementation runs several concurrent agents) will not be sent more often
  than once every 5 ms.

  As defined in [RFC8445], once both agents have indicated the pacing value
  they want to use, both agents will use the larger of the indicated values.

---------------------------------------------------------------------------

Section 6

OLD

   All the ICE agents MUST follow the procedures defined in section 11
   of [RFC8445] for sending keepalives.  The keepalives MUST be sent
   regardless of whether the data stream is currently inactive,

NEW

   All the ICE agents MUST follow the procedures defined in section 11 of
   [RFC8445] for sending keepalives.  As defined in [RFC8445], the keepalives
   will be sent regardless of whether the data stream is currently inactive,

---------------------------------------------------------------------------

Section 9.3

After the paragraph ending "...and media is never sent", please add:

    The ICE extension defined in [RFC7675] can be used to further protect
    against voice hammer attacks.

And add RFC 7675 as an informative 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.

---------------------------------------------------------------------------

Section 12:

Please add two more bullets:


    o ICE mismatch is now optional, and an agent has an option to not
      trigger mismatch and instead treat the default candidate as an
      additional candidate.


    o FQDNs and "0.0.0.0"/"::" IP addresses with port "9" default
      candidates do not trigger ICE mismatch.