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.