draft-ietf-mmusic-ice-sip-sdp-31.txt   draft-ietf-mmusic-ice-sip-sdp-32.txt 
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) S. Nandakumar Obsoletes: 5245 (if approved) S. Nandakumar
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 4, 2019 A. Keranen Expires: December 5, 2019 A. Keranen
Ericsson Ericsson
June 2, 2019 June 3, 2019
Session Description Protocol (SDP) Offer/Answer procedures for Session Description Protocol (SDP) Offer/Answer procedures for
Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-31 draft-ietf-mmusic-ice-sip-sdp-32
Abstract Abstract
This document describes Session Description Protocol (SDP) Offer/ This document describes Session Description Protocol (SDP) Offer/
Answer procedures for carrying out Interactive Connectivity Answer procedures for carrying out Interactive Connectivity
Establishment (ICE) between the agents. Establishment (ICE) between the agents.
This document obsoletes RFC 5245.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2019. This Internet-Draft will expire on December 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 24
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4 3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4
3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6 3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6
3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6 3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6
3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6
3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6 3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6
3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7 3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7
3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8
3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 8
3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8 3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8
3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 9 3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 9
3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 10 3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 10
3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10
3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 10 3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 11
3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 13 3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 13
3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 15 3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 15
4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 16 4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 17
4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 19 4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 19
4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 19 4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 19
4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 20 4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 20
4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 21 4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 21
4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21 4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22
6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 23 6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 23
6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 24 6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 24
6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 24 6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 24
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24
6.4. Interactions with Preconditions . . . . . . . . . . . . . 25 6.4. Interactions with Preconditions . . . . . . . . . . . . . 25
6.5. Interactions with Third Party Call Control . . . . . . . 25 6.5. Interactions with Third Party Call Control . . . . . . . 25
7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 25 7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 26 8.1. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 26
8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 26 8.2. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 26
8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 26 8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 26
8.2.2. Interactions with Application Layer Gateways and SIP 27 8.2.2. Interactions with Application Layer Gateways and SIP 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 28 9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 28
9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 28 9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 28
9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 29 9.1.2. remote-candidates Attribute . . . . . . . . . . . . . 29
9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 29 9.1.3. ice-lite Attribute . . . . . . . . . . . . . . . . . 29
skipping to change at page 4, line 19 skipping to change at page 4, line 24
Default Destination/Candidate: The default destination for a Default Destination/Candidate: The default destination for a
component of a data stream is the transport address that would be component of a data stream is the transport address that would be
used by an agent that is not ICE aware. A default candidate for a used by an agent that is not ICE aware. A default candidate for a
component is one whose transport address matches the default component is one whose transport address matches the default
destination for that component. For the RTP component, the destination for that component. For the RTP component, the
default connection address is in the "c=" line of the SDP, and the default connection address is in the "c=" line of the SDP, and the
port and transport protocol are in the "m=" line. For the RTCP port and transport protocol are in the "m=" line. For the RTCP
component, the address and port are indicated using the "a=rtcp" component, the address and port are indicated using the "a=rtcp"
attribute defined in [RFC3605], if present; otherwise, the RTCP attribute defined in [RFC3605], if present; otherwise, the RTCP
component address is same as the address of the RTP component, and component address is the same as the address of the RTP component,
its port is one greater than the port of the RTP component. and its port is one greater than the port of the RTP component.
3. SDP Offer/Answer Procedures 3. SDP Offer/Answer Procedures
3.1. Introduction 3.1. Introduction
[RFC8445] defines ICE candidate exchange as the process for ICE [RFC8445] defines ICE candidate exchange as the process for ICE
agents (Initiator and Responder) to exchange their candidate agents (Initiator and Responder) to exchange their candidate
information required for ICE processing at the agents. For the information required for ICE processing at the agents. For the
purposes of this specification, the candidate exchange process purposes of this specification, the candidate exchange process
corresponds to the [RFC3264] Offer/Answer protocol and the corresponds to the [RFC3264] Offer/Answer protocol and the
skipping to change at page 5, line 7 skipping to change at page 5, line 12
Section 4 provides detailed rules for constructing various SDP Section 4 provides detailed rules for constructing various SDP
attributes defined in this specification. attributes defined in this specification.
3.2.1.1. Data Streams 3.2.1.1. Data Streams
Each data stream [RFC8445] is represented by an SDP media description Each data stream [RFC8445] is represented by an SDP media description
("m=" section). ("m=" section).
3.2.1.2. Candidates 3.2.1.2. Candidates
With in a "m=" section, each candidate (including the default Within a "m=" section, each candidate (including the default
candidate) associated with the data stream is represented by an SDP candidate) associated with the data stream is represented by an SDP
candidate attribute. candidate attribute.
Prior to nomination, the "c=" line associated with an "m=" section Prior to nomination, the "c=" line associated with an "m=" section
contains the connection address of the default candidate, while the contains the connection address of the default candidate, while the
"m=" line contains the port and transport protocol of the default "m=" line contains the port and transport protocol of the default
candidate for that "m=" section. candidate for that "m=" section.
After nomination, the "c=" line for a given "m=" section contains the After nomination, the "c=" line for a given "m=" section contains the
connection address of the nominated candidate (the local candidate of connection address of the nominated candidate (the local candidate of
skipping to change at page 6, line 15 skipping to change at page 6, line 19
used. used.
3.2.2. RTP/RTCP Considerations 3.2.2. RTP/RTCP Considerations
If an agent utilizes both RTP and RTCP, and separate ports are used If an agent utilizes both RTP and RTCP, and separate ports are used
for RTP and RTCP, the agent MUST include SDP candidate attributes for for RTP and RTCP, the agent MUST include SDP candidate attributes for
both the RTP and RTCP components and SDP rtcp attribute SHOULD be both the RTP and RTCP components and SDP rtcp attribute SHOULD be
included in the "m=" section, as described in [RFC3605] included in the "m=" section, as described in [RFC3605]
In the cases where the port number for the RTCP is one higher than In the cases where the port number for the RTCP is one higher than
the RTP port and RTCP component address is same as the address of the the RTP port and the RTCP component address is the same as the
RTP component, the SDP rtcp attribute MAY be omitted. address of the RTP component, the SDP rtcp attribute MAY be omitted.
If the agent does not utilize RTCP, it indicates that by including If the agent does not utilize RTCP, it indicates that by including
b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556]. b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556].
3.2.3. Determining Role 3.2.3. Determining Role
The offerer acts as the Initiating agent. The answerer acts as the The offerer acts as the Initiating agent. The answerer acts as the
Responding agent. The ICE roles (controlling and controlled) are Responding agent. The ICE roles (controlling and controlled) are
determined using the procedures in [RFC8445]. determined using the procedures in [RFC8445].
skipping to change at page 6, line 39 skipping to change at page 6, line 43
Once an agent has provided its local candidates to its peer in an SDP 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 offer or answer, the agent MUST be prepared to receive STUN
connectivity check Binding requests on those candidates. connectivity check Binding requests on those candidates.
3.2.5. Verifying ICE Support Procedures 3.2.5. Verifying ICE Support Procedures
The agents will proceed with the ICE procedures defined in [RFC8445] The agents will proceed with the ICE procedures defined in [RFC8445]
and this specification if, for each data stream in the SDP it and this specification if, for each data stream in the SDP it
received, the default destination for each component of that data received, the default destination for each component of that data
stream appears in a candidate attribute. For example, in the case of stream appears in a candidate attribute. For example, in the case of
RTP, the connection address, port and transport protocol are in the RTP, the connection address, port and transport protocol in the "c="
"c=" and "m=" lines, respectively, appear in a candidate attribute and "m=" lines, respectively, appear in a candidate attribute and the
and the value in the rtcp attribute appears in a candidate attribute. value in the rtcp attribute appears in a candidate attribute.
This specification provides no guidance on how an agent should This specification provides no guidance on how an agent should
proceed in the cases where the above condition is not met with the proceed in the cases where the above condition is not met with the
few exceptions noted below: few exceptions noted below:
1. The presence of certain application layer gateways MAY modify the 1. The presence of certain application layer gateways MAY modify the
transport address information as described in Section 8.2.2. The transport address information as described in Section 8.2.2. The
behavior of the responding agent in such a situation is behavior of the responding agent in such a situation is
implementation defined. Informally, the responding agent MAY implementation dependent. Informally, the responding agent MAY
consider the mismatched transport address information as a consider the mismatched transport address information as a
plausible new candidate learnt from the peer and continue its ICE plausible new candidate learnt from the peer and continue its ICE
processing with that transport address included. Alternatively, processing with that transport address included. Alternatively,
the responding agent MAY include an "a=ice-mismatch" attribute in the responding agent MAY include an "a=ice-mismatch" attribute in
its answer for such data streams. If agent chooses to include an its answer for such data streams. If an agent chooses to include
"a=ice-mismatch" attribute in its answer for a data stream, then an "a=ice-mismatch" attribute in its answer for a data stream,
it MUST also omit "a=candidate" attributes, MUST terminate the then it MUST also omit "a=candidate" attributes, MUST terminate
usage of ICE procedures and [RFC3264] procedures MUST be used the usage of ICE procedures and [RFC3264] procedures MUST be used
instead for this data stream. instead for this data stream.
2. The transport address from the peer for the default destination 2. The transport address from the peer for the default destination
correspond to IP address values "0.0.0.0"/"::" and port value of correspond to IPv4/IPv6 address values "0.0.0.0"/"::" and port
"9". This MUST not be considered as a ICE failure by the peer value of "9". This MUST NOT be considered as a ICE failure by
agent and the ICE processing MUST continue as usual. the peer agent and the ICE processing MUST continue as usual.
3. In some cases, controlling/initiator agent may receive the SDP 3. In some cases, the scontrolling/initiator agent may receive the
answer that may omit "a=candidate" attributes for the data SDP answer that may omit "a=candidate" attributes for the data
stream, and instead include a media level "a=ice-mismatch" stream, and instead include a media level "a=ice-mismatch"
attribute. This signals to the offerer that the answerer attribute. This signals to the offerer that the answerer
supports ICE, but that ICE processing was not used for this data supports ICE, but that ICE processing was not used for this data
stream. In this case, ICE processing MUST be terminated for this stream. In this case, ICE processing MUST be terminated for this
data stream and [RFC3264] procedures MUST be followed instead. data stream and [RFC3264] procedures MUST be followed instead.
4. The transport address from the peer for the default destination 4. The transport address from the peer for the default destination
is an FQDN. Regardless of the procedures used to resolve FQDN or is an FQDN. Regardless of the procedures used to resolve FQDN or
the resolution result, this MUST not be considered as a ICE the resolution result, this MUST NOT be considered as a ICE
failure by the peer agent and the ICE processing MUST continue as failure by the peer agent and the ICE processing MUST continue as
usual. usual.
3.2.6. SDP Example 3.2.6. SDP Example
The following is an example SDP message that includes ICE attributes The following is an example SDP message that includes ICE attributes
(lines folded for readability): (lines folded for readability):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 203.0.113.141
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
t=0 0 t=0 0
a=ice-options:ice2 a=ice-options:ice2
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0 m=audio 45664 RTP/AVP 0
b=RS:0 b=RS:0
b=RR:0 b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:1 1 UDP 2130706431 203.0.113.141 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 203.0.113.141 rport 8998
3.3. Initial Offer/Answer Exchange 3.3. Initial Offer/Answer Exchange
3.3.1. Sending the Initial Offer 3.3.1. Sending the Initial Offer
When an offerer generates the initial offer, in each "m=" section it When an offerer generates the initial offer, in each "m=" section it
MUST include SDP candidate attributes for each available candidate MUST include SDP candidate attributes for each available candidate
associated with the "m=" section. In addition, the offerer MUST associated with the "m=" section. In addition, the offerer MUST
include an SDP ice-ufrag and an SDP ice-pwd attribute in the offer. include an SDP ice-ufrag and an SDP ice-pwd attribute in the offer.
It is valid for an offer "m=" line to include no SDP candidate It is valid for an offer "m=" line to include no SDP candidate
attributes and with default destination corresponding to the IP attributes and with default destination corresponding to the IP
address values "0.0.0.0"/"::" and port value of "9". This implies address values "0.0.0.0"/"::" and port value of "9". This implies
that offering agent is only going to use peer reflexive candidates or that the offering agent is only going to use peer reflexive
that additional candidates would be provided in subsequent signaling candidates or that additional candidates would be provided in
messages. subsequent signaling messages.
Note: Within the scope of this document, "Initial Offer" refers to Note: Within the scope of this document, "Initial Offer" refers to
the first SDP offer that is sent in order to negotiate usage of the first SDP offer that is sent in order to negotiate usage of
ICE. It might, or might not, be the initial SDP offer of the SDP ICE. It might, or might not, be the initial SDP offer of the SDP
session. session.
Note: The procedures in this document only consider "m=" sections Note: The procedures in this document only consider "m=" sections
associated with data streams where ICE is used. associated with data streams where ICE is used.
3.3.2. Sending the Initial Answer 3.3.2. Sending the Initial Answer
skipping to change at page 8, line 48 skipping to change at page 9, line 15
In each "m=" line, the answerer MUST use the same transport protocol In each "m=" line, the answerer MUST use the same transport protocol
as was used in the offer "m=" line. If none of the candidates in the as was used in the offer "m=" line. If none of the candidates in the
"m=" line in the answer use the same transport protocol as indicated "m=" line in the answer use the same transport protocol as indicated
in the offer "m=" line, then, in order to avoid ICE mismatch, the in the offer "m=" line, then, in order to avoid ICE mismatch, the
default destination MUST be set to IP address values "0.0.0.0"/"::" default destination MUST be set to IP address values "0.0.0.0"/"::"
and port value of "9". and port value of "9".
It is also valid for an answer "m=" line to include no SDP candidate It is also valid for an answer "m=" line to include no SDP candidate
attributes and with default destination corresponding to the IP attributes and with default destination corresponding to the IP
address values "0.0.0.0"/"::" and port value of "9". This implies address values "0.0.0.0"/"::" and port value of "9". This implies
that answering agent is only going to use peer reflexive candidates that the answering agent is only going to use peer reflexive
or that additional candidates would be provided in subsequent candidates or that additional candidates would be provided in
signaling messages. subsequent signaling messages.
Once the answerer has sent the answer, it can start performing Once the answerer has sent the answer, it can start performing
connectivity checks towards the peer candidates that were provided in connectivity checks towards the peer candidates that were provided in
the offer. the offer.
If the offer does not indicate support of ICE, the answerer MUST NOT If the offer does not indicate support of ICE, the answerer MUST NOT
accept the usage of ICE. If the answerer still accepts the offer, accept the usage of ICE. If the answerer still accepts the offer,
the answerer MUST NOT include any ICE related SDP attributes in the the answerer MUST NOT include any ICE related SDP attributes in the
answer. Instead the answerer will generate the answer according to answer. Instead the answerer will generate the answer according to
normal offer/answer procedures [RFC3264]. normal offer/answer procedures [RFC3264].
If the answerer detects a possibility of the ICE mismatch, procedures If the answerer detects a possibility of the ICE mismatch, procedures
described in (Section 3.2.5) are followed. described in (Section 3.2.5) are followed.
Note: <draft-holmberg-ice-pac>> provides guidance on finding working Note: <draft-holmberg-ice-pac>> provides guidance on finding working
candidate pairs and thus preventing premature declaration of ICE candidate pairs and thus preventing premature declaration of ICE
failure is certain scenarios such as, if the peer has not provided failure in certain scenarios such as, if the peer has not provided
any candidates, or if all provided candidates have failed or have any candidates, or if all provided candidates have failed or have
been discarded. been discarded.
3.3.3. Receiving the Initial Answer 3.3.3. Receiving the Initial Answer
When an offerer receives an initial answer that indicates that the When an offerer receives an initial answer that indicates that the
answerer supports ICE, it can start performing connectivity checks answerer supports ICE, it can start performing connectivity checks
towards the peer candidates that were provided in the answer. towards the peer candidates that were provided in the answer.
If the answer does not indicate that the answerer supports ICE, or if If the answer does not indicate that the answerer supports ICE, or if
the answerer included "a=ice-mismatch" attributes for all the active the answerer included "a=ice-mismatch" attributes for all the active
data streams in the answer, the offerer MUST terminate the usage of data streams in the answer, the offerer MUST terminate the usage of
ICE for the entire session and [RFC3264] procedures MUST be followed ICE for the entire session and [RFC3264] procedures MUST be followed
instead. instead.
On the other hand, if the answer indicates the support for ICE but On the other hand, if the answer indicates the support for ICE but
includes "a=ice-mismatch" in certain active data streams, then the includes "a=ice-mismatch" in certain active data streams, then the
offerer MUST terminate the usage of ICE procedures and [RFC3264] offerer MUST terminate the usage of ICE procedures and [RFC3264]
procedures MUST be used instead for only these data streams. Also, procedures MUST be used instead for only these data streams. Also,
ICE procedures MUST be used for data streams where "a=ice-mismatch" ICE procedures MUST be used for data streams where an "a=ice-
attribute was not included. mismatch" attribute was not included.
If the offerer detects an ICE mismatch for one or more data streams If the offerer detects an ICE mismatch for one or more data streams
in the answer, as described in (Section 3.2.5), the offerer MUST in the answer, as described in (Section 3.2.5), the offerer MUST
terminate the usage of ICE for the entire session. The subsequent terminate the usage of ICE for the entire session. The subsequent
actions taken by the offerer are implementation dependent and are out actions taken by the offerer are implementation dependent and are out
of the scope of this specification. of the scope of this specification.
Note: <draft-holmberg-ice-pac>> provides guidance on finding working Note: <draft-holmberg-ice-pac>> provides guidance on finding working
candidate pairs and thus preventing premature declaration of ICE candidate pairs and thus preventing premature declaration of ICE
failure is certain scenarios such as, if the peer has not provided failure in certain scenarios such as, if the peer has not provided
any candidates, or if all provided candidates have failed or have any candidates, or if all provided candidates have failed or have
been discarded. been discarded.
3.3.4. Concluding ICE 3.3.4. Concluding ICE
Once the state of each check list is Completed, and if the agent is Once the state of each check list is Completed, and if the agent is
the controlling agent, it nominates a candidate pair [RFC8445] and the controlling agent, it nominates a candidate pair [RFC8445] and
checks for each data stream whether the nominated pair matches the checks for each data stream whether the nominated pair matches the
default candidate pair. If there are one or more data streams with a default candidate pair. If there are one or more data streams don't
mismatch, and the peer did not indicate support for the 'ice2' ice- match, and the peer did not indicate support for the 'ice2' ice-
option, the controlling agent MUST generate a subsequent offer option, the controlling agent MUST generate a subsequent offer
(Section 3.4.1), in which the connection address, port and transport (Section 3.4.1), in which the connection address, port and transport
protocol in the "c=" and "m=" lines associated with each data stream protocol in the "c=" and "m=" lines associated with each data stream
match the corresponding local information of the nominated pair for match the corresponding local information of the nominated pair for
that data stream. that data stream.
However, If the support for 'ice2' ice-option is in use, the However, if the support for 'ice2' ice-option is in use, the
nominated candidate is noted and sent in the subsequent offer/answer nominated candidate is noted and sent in the subsequent offer/answer
exchange as the default candidate and no updated offer is needed to exchange as the default candidate and no updated offer is needed to
fix the default candidate. fix the default candidate.
Also as described in [RFC8445], once the controlling agent has Also as described in [RFC8445], once the controlling agent has
nominated a candidate pair for a data stream, the agent MUST NOT nominated a candidate pair for a data stream, the agent MUST NOT
nominate another pair for that data stream during the lifetime of the nominate another pair for that data stream during the lifetime of the
ICE session (i.e. until ICE is restarted). ICE session (i.e. until ICE is restarted).
3.4. Subsequent Offer/Answer Exchanges 3.4. Subsequent Offer/Answer Exchanges
skipping to change at page 12, line 29 skipping to change at page 12, line 43
each component of that data stream. It is needed to avoid a race each component of that data stream. It is needed to avoid a race
condition whereby the controlling agent chooses its pairs, but the condition whereby the controlling agent chooses its pairs, but the
updated offer beats the connectivity checks to the controlled agent, updated offer beats the connectivity checks to the controlled agent,
which doesn't even know these pairs are valid, let alone selected. which doesn't even know these pairs are valid, let alone selected.
See Appendix B for elaboration on this race condition. See Appendix B for elaboration on this race condition.
3.4.1.3. Procedures for Lite Implementations 3.4.1.3. Procedures for Lite Implementations
If the ICE state is running, a lite implementation MUST include all If the ICE state is running, a lite implementation MUST include all
of its candidates for each component of each data stream in of its candidates for each component of each data stream in
"a=candidate" attribute in any subsequent offer. The candidates are "a=candidate" attributes in any subsequent offer. The candidates are
formed identical to the procedures for initial offers. formed identical to the procedures for initial offers.
A lite implementation MUST NOT add additional host candidates in a A lite implementation MUST NOT add additional host candidates in a
subsequent offer. If an agent needs to offer additional candidates, subsequent offer. If an agent needs to offer additional candidates,
it MUST restart ICE. Similarly, the username fragments or passwords it MUST restart ICE. Similarly, the username fragments or passwords
MUST remain the same as used previously. If an agent needs to change MUST remain the same as used previously. If an agent needs to change
one of these, it MUST restart ICE for that data stream. one of these, it MUST restart ICE for that data stream.
If ICE has completed for a data stream and if the agent is If ICE has completed for a data stream and if the agent is
controlled, the default destination for that data stream MUST be set controlled, the default destination for that data stream MUST be set
skipping to change at page 15, line 14 skipping to change at page 15, line 25
Besides the potential role change, change in the Valid list, and Besides the potential role change, change in the Valid list, and
state changes, the construction of the answer is performed state changes, the construction of the answer is performed
identically to the construction of an offer. identically to the construction of an offer.
3.4.3. Receiving Answer for a Subsequent Offer 3.4.3. Receiving Answer for a Subsequent Offer
3.4.3.1. Procedures for Full Implementations 3.4.3.1. Procedures for Full Implementations
There may be certain situations where the offerer receives an SDP There may be certain situations where the offerer receives an SDP
answer that lacks ICE candidates although the initial answer did. answer that lacks ICE candidates although the initial answer included
One example of such an "unexpected" answer might be happen when an them. One example of such an "unexpected" answer might be happen
ICE-unaware B2BUA introduces a media server during call hold using when an ICE-unaware Back-to-Back User Agent (B2BUA) introduces a
3rd party call-control procedures. Omitting further details how this media server during call hold using 3rd party call-control
is done, this could result in an answer being received at the holding procedures. Omitting further details how this is done, this could
UA that was constructed by the B2BUA. With the B2BUA being ICE- result in an answer being received at the holding UA that was
unaware, that answer would not include ICE candidates. constructed by the B2BUA. With the B2BUA being ICE-unaware, that
answer would not include ICE candidates.
Receiving an answer without ICE attributes in this situation might be Receiving an answer without ICE attributes in this situation might be
unexpected, but would not necessarily impair the user experience. unexpected, but would not necessarily impair the user experience.
When the offerer receives an answer indicating support for ICE, the When the offerer receives an answer indicating support for ICE, the
offer performs on of the following actions: offer performs one of the following actions:
o If the offer was a restart, the agent MUST perform ICE restart o If the offer was a restart, the agent MUST perform ICE restart
procedures as specified in Section 3.4.3.1.1 procedures as specified in Section 3.4.3.1.1
o If the offer/answer exchange removed a data stream, or an answer o If the offer/answer exchange removed a data stream, or an answer
rejected an offered data stream, an agent MUST flush the Valid rejected an offered data stream, an agent MUST flush the Valid
list for that data stream. It MUST also terminate any STUN list for that data stream. It MUST also terminate any STUN
transactions in progress for that data stream. transactions in progress for that data stream.
o If the offer/answer exchange added a new data stream, the agent o If the offer/answer exchange added a new data stream, the agent
skipping to change at page 15, line 51 skipping to change at page 16, line 15
o If ICE state is running for a given data stream, the agent o If ICE state is running for a given data stream, the agent
recomputes the check list. If a pair on the new check list was recomputes the check list. If a pair on the new check list was
also on the previous check list, and its state is not Frozen, its also on the previous check list, and its state is not Frozen, its
state is copied over. Otherwise, its state is set to Frozen. If state is copied over. Otherwise, its state is set to Frozen. If
none of the check lists are active (meaning that the pairs in each none of the check lists are active (meaning that the pairs in each
check list are Frozen), appropriate procedures in [RFC8445] are check list are Frozen), appropriate procedures in [RFC8445] are
performed to move candidate(s) to the Waiting state to further performed to move candidate(s) to the Waiting state to further
continue ICE processing. continue ICE processing.
o If ICE state is completed and the SDP answer conforms to o If ICE state is completed and the SDP answer conforms to
Section 3.4.2, the agent MUST reman in the ICE completed state. Section 3.4.2, the agent MUST remain in the ICE completed state.
However, if the ICE support is no longer indicated in the SDP answer, However, if the ICE support is no longer indicated in the SDP answer,
the agent MUST fall-back to [RFC3264] procedures and SHOULD NOT drop the agent MUST fall-back to [RFC3264] procedures and SHOULD NOT drop
the dialog because of the missing ICE support or unexpected answer. the dialog because of the missing ICE support or unexpected answer.
Once the agent sends a new offer later on, it MUST perform an ICE Once the agent sends a new offer later on, it MUST perform an ICE
restart. restart.
3.4.3.1.1. ICE Restarts 3.4.3.1.1. ICE Restarts
The agent MUST remember the nominated pair in the Valid list for each The agent MUST remember the nominated pair in the Valid list for each
skipping to change at page 17, line 40 skipping to change at page 17, line 49
IP address, port and transport protocol, and its properties: the IP address, port and transport protocol, and its properties: the
foundation, component ID, priority, type, and related transport foundation, component ID, priority, type, and related transport
address: address:
<connection-address>: is taken from RFC 4566 [RFC4566]. It is the <connection-address>: is taken from RFC 4566 [RFC4566]. It is the
IP address of the candidate, allowing for IPv4 addresses, IPv6 IP address of the candidate, allowing for IPv4 addresses, IPv6
addresses, and fully qualified domain names (FQDNs). When parsing addresses, and fully qualified domain names (FQDNs). When parsing
this field, an agent can differentiate an IPv4 address and an IPv6 this field, an agent can differentiate an IPv4 address and an IPv6
address by presence of a colon in its value - the presence of a address by presence of a colon in its value - the presence of a
colon indicates IPv6. An agent generating local candidates MUST colon indicates IPv6. An agent generating local candidates MUST
not use FQDN addresses. An agent processing remote candidates NOT use FQDN addresses. An agent processing remote candidates
MUST ignore candidate lines that include candidates with FQDN or MUST ignore candidate lines that include candidates with FQDN or
IP address versions that are not supported or recognized. The IP address versions that are not supported or recognized. The
procedures for generation and handling of FQDN candidates, as well procedures for generation and handling of FQDN candidates, as well
as, how agents indicate support for such procedures, need to be as, how agents indicate support for such procedures, need to be
specified in an extension specification. specified in an extension specification.
<port>: is also taken from RFC 4566 [RFC4566]. It is the port of <port>: is also taken from RFC 4566 [RFC4566]. It is the port of
the candidate. the candidate.
<transport>: indicates the transport protocol for the candidate. <transport>: indicates the transport protocol for the candidate.
skipping to change at page 19, line 4 skipping to change at page 19, line 14
of its purpose). If the candidate is a host candidate, <rel-addr> of its purpose). If the candidate is a host candidate, <rel-addr>
and <rel-port> MUST be omitted. and <rel-port> MUST be omitted.
In some cases, e.g., for privacy reasons, an agent may not want to In some cases, e.g., for privacy reasons, an agent may not want to
reveal the related address and port. In this case the address reveal the related address and port. In this case the address
MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6
candidates) and the port to zero. candidates) and the port to zero.
The candidate attribute can itself be extended. The grammar allows The candidate attribute can itself be extended. The grammar allows
for new name/value pairs to be added at the end of the attribute. for new name/value pairs to be added at the end of the attribute.
Such extensions MUST be made through IETF Review or IESG Approval Such extensions MUST be made through IETF Review or IESG Approval
[RFC5226] and the assignments MUST contain the specific extension and [RFC5226] and the assignments MUST contain the specific extension and
a reference to the document defining the usage of the extension a reference to the document defining the usage of the extension
An implementation MUST ignore any name/value pairs it doesn't An implementation MUST ignore any name/value pairs it doesn't
understand. understand.
Example: SDP line for UDP server reflexive candidate attribute for the RTP component Example: SDP line for UDP server reflexive candidate attribute for the RTP component
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 203.0.113.141 rport 8998
4.2. "remote-candidates" Attribute 4.2. "remote-candidates" Attribute
The syntax of the "remote-candidates" attribute is defined using The syntax of the "remote-candidates" attribute is defined using
Augmented BNF as defined in [RFC5234]. The remote-candidates Augmented BNF as defined in [RFC5234]. The remote-candidates
attribute is a media-level attribute only. attribute is a media-level attribute only.
remote-candidate-att = "remote-candidates:" remote-candidate remote-candidate-att = "remote-candidates:" remote-candidate
0*(SP remote-candidate) 0*(SP remote-candidate)
remote-candidate = component-ID SP connection-address SP port remote-candidate = component-ID SP connection-address SP port
skipping to change at page 19, line 49 skipping to change at page 20, line 11
The syntax of the "ice-lite" and "ice-mismatch" attributes, both of The syntax of the "ice-lite" and "ice-mismatch" attributes, both of
which are flags, is: which are flags, is:
ice-lite = "ice-lite" ice-lite = "ice-lite"
ice-mismatch = "ice-mismatch" ice-mismatch = "ice-mismatch"
"ice-lite" is a session-level attribute only, and indicates that an "ice-lite" is a session-level attribute only, and indicates that an
agent is a lite implementation. "ice-mismatch" is a media-level agent is a lite implementation. "ice-mismatch" is a media-level
attribute and only reported in the answer. It indicates that the attribute and only reported in the answer. It indicates that the
offerer arrived with a default destination for a media component that offer arrived with a default destination for a media component that
didn't have a corresponding candidate attribute. Inclusion of didn't have a corresponding candidate attribute. Inclusion of
"a=ice-mismatch" attribute for a given data stream implies that even "a=ice-mismatch" attribute for a given data stream implies that even
though both agents support ICE, ICE procedures MUST not used for this though both agents support ICE, ICE procedures MUST NOT be used for
data stream and [RFC3264] procedures MUST be used instead. this data stream and [RFC3264] procedures MUST be used instead.
4.4. "ice-ufrag" and "ice-pwd" Attributes 4.4. "ice-ufrag" and "ice-pwd" Attributes
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment The "ice-ufrag" and "ice-pwd" attributes convey the username fragment
and password used by ICE for message integrity. Their syntax is: and password used by ICE for message integrity. Their syntax is:
ice-pwd-att = "ice-pwd:" password ice-pwd-att = "ice-pwd:" password
ice-ufrag-att = "ice-ufrag:" ufrag ice-ufrag-att = "ice-ufrag:" ufrag
password = 22*256ice-char password = 22*256ice-char
ufrag = 4*256ice-char ufrag = 4*256ice-char
skipping to change at page 21, line 15 skipping to change at page 21, line 22
4.5. "ice-pacing" Attribute 4.5. "ice-pacing" Attribute
The "ice-pacing" is a session level attribute that indicates the The "ice-pacing" is a session level attribute that indicates the
desired connectivity check pacing, in milliseconds, for this agent desired connectivity check pacing, in milliseconds, for this agent
(see section 14 of [RFC8445]). The syntax is: (see section 14 of [RFC8445]). The syntax is:
ice-pacing-att = "ice-pacing:" pacing-value ice-pacing-att = "ice-pacing:" pacing-value
pacing-value = 1*10DIGIT pacing-value = 1*10DIGIT
Following the procedures defined in [RFC8445], a default value of Following the procedures defined in [RFC8445], a default value of
50ms is used for an agent when ice-pacing attribute is omitted in the 50ms is used for an agent when the ice-pacing attribute is omitted in
offer or the answer. the offer or the answer.
The same rule applies for ice-pacing attribute values lower than The same rule applies for ice-pacing attribute values lower than
50ms. This mandates that, if an agent includes the ice-pacing 50ms. This mandates that, if an agent includes the ice-pacing
attribute, its value MUST be greater than 50ms or else a value of attribute, its value MUST be greater than 50ms or else a value of
50ms is considered by default for that agent. 50ms is considered by default for that agent.
Also the larger of the ice-pacing attribute values between the offer Also the larger of the ice-pacing attribute values between the offer
and the answer (determined either by the one provided in the ice- and the answer (determined either by the one provided in the ice-
pacing attribute or by picking the default value) MUST be considered pacing attribute or by picking the default value) MUST be considered
for a given ICE session. for a given ICE session.
Example shows ice-pacing value of 5 ms:
a=ice-pacing:5
4.6. "ice-options" Attribute 4.6. "ice-options" Attribute
The "ice-options" attribute is a session- and media-level attribute. The "ice-options" attribute is a session- and media-level attribute.
It contains a series of tokens that identify the options supported by It contains a series of tokens that identify the options supported by
the agent. Its grammar is: the agent. Its grammar is:
ice-options = "ice-options:" ice-option-tag ice-options = "ice-options:" ice-option-tag
0*(SP ice-option-tag) 0*(SP ice-option-tag)
ice-option-tag = 1*ice-char ice-option-tag = 1*ice-char
The existence of an ice-option in an offer indicates that a certain The existence of an ice-option in an offer indicates that a certain
extension is supported by the agent and is willing to use it, if the extension is supported by the agent and it is willing to use it, if
peer agent also includes the same extension in the answer. There the peer agent also includes the same extension in the answer. There
might be further extension specific negotiation needed between the might be further extension specific negotiation needed between the
agents that determine how the extensions gets used in a given agents that determine how the extension gets used in a given session.
session. The details of the negotiation procedures, if present, MUST The details of the negotiation procedures, if present, MUST be
be defined by the specification defining the extension (see defined by the specification defining the extension (see
Section 9.2). Section 9.2).
Example shows 'rtp+ecn' ice-option SDP line from <<RFC6679>>: Example shows 'rtp+ecn' ice-option SDP line from <<RFC6679>>:
a=ice-options:rtp+ecn a=ice-options:rtp+ecn
5. Keepalives 5. Keepalives
All the ICE agents MUST follow the procedures defined in section 11 All the ICE agents MUST follow the procedures defined in section 11
of [RFC8445] for sending keepalives. The keepalives MUST be sent of [RFC8445] for sending keepalives. The keepalives MUST be sent
skipping to change at page 23, line 33 skipping to change at page 23, line 36
through an ICE specific optimization, wherein, the agent retransmits through an ICE specific optimization, wherein, the agent retransmits
the provisional response with the exponential backoff timers the provisional response with the exponential backoff timers
described in [RFC3262]. Such retransmissions MUST cease on receipt described in [RFC3262]. Such retransmissions MUST cease on receipt
of a STUN Binding request with transport address matching candidate of a STUN Binding request with transport address matching candidate
address for one of the data streams signaled in that SDP or on address for one of the data streams signaled in that SDP or on
transmission of the answer in a 2xx response. If no Binding request transmission of the answer in a 2xx response. If no Binding request
is received prior to the last retransmit, the agent does not consider is received prior to the last retransmit, the agent does not consider
the session terminated. For the ICE lite peers , the agent MUST the session terminated. For the ICE lite peers , the agent MUST
cease retransmitting the 18x after sending it four times since there cease retransmitting the 18x after sending it four times since there
will be no Binding request sent and the number four is arbitrarily will be no Binding request sent and the number four is arbitrarily
chosen to limit the number of 18x retransmits ('poor man's version of chosen to limit the number of 18x retransmits (poor man's version of
[RFC3262]' basically). (ICE will actually work even if the peer [RFC3262] basically). (ICE will actually work even if the peer never
never receives the 18x; however, experience has shown that sending it receives the 18x; however, experience has shown that sending it is
is important for middleboxes and firewall traversal). important for middleboxes and firewall traversal).
Once the answer has been sent, the agent SHOULD begin its Once the answer has been sent, the agent SHOULD begin its
connectivity checks. Once candidate pairs for each component of a connectivity checks. Once candidate pairs for each component of a
data stream enter the valid list, the answerer can begin sending data stream enter the valid list, the answerer can begin sending
media on that data stream. media on that data stream.
However, prior to this point, any media that needs to be sent towards However, prior to this point, any media that needs to be sent towards
the caller (such as SIP early media [RFC3960]) MUST NOT be the caller (such as SIP early media [RFC3960]) MUST NOT be
transmitted. For this reason, implementations SHOULD delay alerting transmitted. For this reason, implementations SHOULD delay alerting
the called party until candidates for each component of each data the called party until candidates for each component of each data
skipping to change at page 27, line 8 skipping to change at page 27, line 14
sending media there. If this target is a third-party host, the sending media there. If this target is a third-party host, the
checks will not succeed, and media is never sent. checks will not succeed, and media is never sent.
Unfortunately, ICE doesn't help if it's not used, in which case an Unfortunately, ICE doesn't help if it's not used, in which case an
attacker could simply send the offer without the ICE parameters. attacker could simply send the offer without the ICE parameters.
However, in environments where the set of clients is known, and is However, in environments where the set of clients is known, and is
limited to ones that support ICE, the server can reject any offers or limited to ones that support ICE, the server can reject any offers or
answers that don't indicate ICE support. answers that don't indicate ICE support.
SIP User Agents (UA) [RFC3261] that are not willing to receive non- SIP User Agents (UA) [RFC3261] that are not willing to receive non-
ICE answers MUST include an "ice" Option Tag in the SIP Require ICE answers MUST include an "ice" Option Tag [RFC5768] in the SIP
Header Field in their offer. UAs that rejects non-ICE offers SHOULD Require Header Field in their offer. UAs that rejects non-ICE offers
use a 421 response code, together with an Option Tag "ice" in the SHOULD use a 421 response code, together with an Option Tag "ice" in
Require Header Field in the response. the Require Header Field in the response.
8.2.2. Interactions with Application Layer Gateways and SIP 8.2.2. Interactions with Application Layer Gateways and SIP
Application Layer Gateways (ALGs) are functions present in a Network Application Layer Gateways (ALGs) are functions present in a Network
Address Translation (NAT) device that inspect the contents of packets Address Translation (NAT) device that inspect the contents of packets
and modify them, in order to facilitate NAT traversal for application and modify them, in order to facilitate NAT traversal for application
protocols. Session Border Controllers (SBCs) are close cousins of protocols. Session Border Controllers (SBCs) are close cousins of
ALGs, but are less transparent since they actually exist as ALGs, but are less transparent since they actually exist as
application-layer SIP intermediaries. ICE has interactions with SBCs application-layer SIP intermediaries. ICE has interactions with SBCs
and ALGs. and ALGs.
skipping to change at page 32, line 39 skipping to change at page 32, line 39
9.2. Interactive Connectivity Establishment (ICE) Options Registry 9.2. Interactive Connectivity Establishment (ICE) Options Registry
IANA maintains a registry for ice-options identifiers under the IANA maintains a registry for ice-options identifiers under the
Specification Required policy as defined in "Guidelines for Writing Specification Required policy as defined in "Guidelines for Writing
an IANA Considerations Section in RFCs" [RFC5226]. an IANA Considerations Section in RFCs" [RFC5226].
ICE options are of unlimited length according to the syntax in ICE options are of unlimited length according to the syntax in
Section 4.6; however, they are RECOMMENDED to be no longer than 20 Section 4.6; however, they are RECOMMENDED to be no longer than 20
characters. This is to reduce message sizes and allow for efficient characters. This is to reduce message sizes and allow for efficient
parsing. ICE options are defined at the session leve.. parsing. ICE options are defined at the session level.
A registration request MUST include the following information: A registration request MUST include the following information:
o The ICE option identifier to be registered o The ICE option identifier to be registered
o Name, Email, and Address of a contact person for the registration o Name, Email, and Address of a contact person for the registration
o Organization or individuals having the change control o Organization or individuals having the change control
o Short description of the ICE extension to which the option relates o Short description of the ICE extension to which the option relates
skipping to change at page 37, line 26 skipping to change at page 37, line 26
a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ host a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ host
a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ
srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT
The offer, with the variables replaced with their values, will look The offer, with the variables replaced with their values, will look
like (lines folded for clarity): like (lines folded for clarity):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP6 fe80::6676:baff:fe9c:ee4a o=jdoe 2890844526 2890842807 IN IP6 fe80::6676:baff:fe9c:ee4a
s= s=
c=IN IP6 2001:420:c0e0:1005::61 c=IN IP6 2001:DB8:8101:3a55:4858:a2a9:22ff:99b9
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0 m=audio 45664 RTP/AVP 0
b=RS:0 b=RS:0
b=RR:0 b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 fe80::6676:baff:fe9c:ee4a 8998 typ host a=candidate:1 1 UDP 2130706431 fe80::6676:baff:fe9c:ee4a 8998 typ host
a=candidate:2 1 UDP 1694498815 2001:420:c0e0:1005::61 45664 typ srflx raddr a=candidate:2 1 UDP 1694498815 2001:DB8:8101:3a55:4858:a2a9:22ff:99b9 45664 typ srflx raddr
fe80::6676:baff:fe9c:ee4a rport 8998 fe80::6676:baff:fe9c:ee4a rport 8998
The resulting answer looks like: The resulting answer looks like:
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
s= s=
c=IN IP4 $R-PUB-1.IP c=IN IP4 $R-PUB-1.IP
t=0 0 t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
 End of changes. 46 change blocks. 
81 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/