draft-ietf-mmusic-ice-sip-sdp-36.txt   draft-ietf-mmusic-ice-sip-sdp-37.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 8, 2019 A. Keranen Expires: January 31, 2020 A. Keranen
Ericsson Ericsson
June 6, 2019 R. Shpount
TurboBridge
C. Holmberg
Ericsson
July 30, 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-36 draft-ietf-mmusic-ice-sip-sdp-37
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. This document obsoletes RFC 5245.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 42
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 8, 2019. This Internet-Draft will expire on January 31, 2020.
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 36 skipping to change at page 2, line 42
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 . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . 11
3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 11 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 . . . . . . . 16
4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 17 4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 17
4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 19 4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 20
4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 20 4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 20
4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 20 4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 21
4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 21 4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 22
4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21 4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 22
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 23
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . 25
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 25
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 . . . . . . . 26
7. Relationship with ANAT . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . 27
8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 26 8.2.1. The Voice Hammer Attack . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . . . 29
9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 28 9.1. SDP Attributes . . . . . . . . . . . . . . . . . . . . . 29
9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 28 9.1.1. candidate Attribute . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . 30
9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 30 9.1.4. ice-mismatch Attribute . . . . . . . . . . . . . . . 30
9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 30 9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 31
9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 31 9.1.6. ice-ufrag Attribute . . . . . . . . . . . . . . . . . 31
9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 31 9.1.7. ice-options Attribute . . . . . . . . . . . . . . . . 32
9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 32 9.1.8. ice-pacing Attribute . . . . . . . . . . . . . . . . 32
9.2. Interactive Connectivity Establishment (ICE) Options 9.2. Interactive Connectivity Establishment (ICE) Options
Registry . . . . . . . . . . . . . . . . . . . . . . . . 32 Registry . . . . . . . . . . . . . . . . . . . . . . . . 33
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. The remote-candidates Attribute . . . . . . . . . . 37 Appendix B. The remote-candidates Attribute . . . . . . . . . . 38
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 40 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document describes how Interactive Connectivity Establishment This document describes how Interactive Connectivity Establishment
(ICE) is used with Session Description Protocol (SDP) offer/answer (ICE) is used with Session Description Protocol (SDP) offer/answer
[RFC3264]. The ICE specification [RFC8445] describes procedures that [RFC3264]. The ICE specification [RFC8445] describes procedures that
are common to all usages of ICE and this document gives the are common to all usages of ICE and this document gives the
additional details needed to use ICE with SDP offer/answer. additional details needed to use ICE with SDP offer/answer.
This document obsoletes RFC 5245. This document obsoletes RFC 5245.
skipping to change at page 5, line 43 skipping to change at page 5, line 43
An ICE lite implementation [RFC8445] MUST include an SDP ice-lite An ICE lite implementation [RFC8445] MUST include an SDP ice-lite
attribute. A full implementation MUST NOT include that attribute. attribute. A full implementation MUST NOT include that attribute.
3.2.1.5. ICE Extensions 3.2.1.5. ICE Extensions
An agent uses the SDP ice-options attribute to indicate support of An agent uses the SDP ice-options attribute to indicate support of
ICE extensions. ICE extensions.
An agent compliant to this specification MUST include an SDP ice- An agent compliant to this specification MUST include an SDP ice-
options attribute with an "ice2" attribute value. If an agent options attribute with an "ice2" attribute value [RFC8445]. If an
receives an SDP offer or answer with ICE attributes but without the agent receives an SDP offer or answer that does not contain an SDP
"ice2" ice-options attribute value, the agent assumes that the peer ice-options attribute with an "ice2" attribute value, the agent can
is compliant to [RFC5245]. assume that the peer is compliant to [RFC5245].
3.2.1.6. Inactive and Disabled Data Streams 3.2.1.6. Inactive and Disabled Data Streams
If an "m=" section is marked as inactive [RFC4566], or has a If an "m=" section is marked as inactive [RFC4566], or has a
bandwidth value of zero [RFC4566], the agent MUST still include ICE- bandwidth value of zero [RFC4566], the agent MUST still include ICE-
related SDP attributes. related SDP attributes.
If the port value associated with an "m=" section is set to zero If the port value associated with an "m=" section is set to zero
(implying a disabled stream) as defined in section 8.2 of [RFC3264], (implying a disabled stream) as defined in section 8.2 of [RFC3264],
the agent SHOULD NOT include ICE-related SDP candidate attributes in the agent SHOULD NOT include ICE-related SDP candidate attributes in
skipping to change at page 8, line 28 skipping to change at page 8, line 28
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
203.0.113.141 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 attribute, an SDP ice-pwd attribute and an
SDP ice-options attribute with an "ice2" attribute value in the
offer. If the offerer is a full ICE implementation, it SHOULD
include an ice-pacing attribute in the offer (if not included, the
default value will apply). A lite ICE implementation MUST NOT
included the ice-pacing attribute in the offer (as it will not
perform connectivity checks).
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 the offering agent is only going to use peer reflexive that the offering agent is only going to use peer reflexive
candidates or that additional candidates would be provided in candidates or that additional candidates would be provided in
subsequent signaling 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
skipping to change at page 8, line 52 skipping to change at page 9, line 12
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
When an answerer receives an initial offer that indicates that the When an answerer receives an initial offer that indicates that the
offerer supports ICE, and if the answerer accepts the offer and the offerer supports ICE, and if the answerer accepts the offer and the
usage of ICE, in each "m=" section within the answer, it MUST include usage of ICE, in each "m=" section within the answer, it MUST include
SDP candidate attributes for each available candidate associated with SDP candidate attributes for each available candidate associated with
the "m=" section. In addition, the answerer MUST include an SDP ice- the "m=" section. In addition, the answerer MUST include an SDP ice-
ufrag and an SDP ice-pwd attribute in the answer. ufrag attribute, an SDP ice-pwd attribute and an SDP ice-options
attribute with an "ice2" attribute value in the answer. If the
answerer is a full ICE implementation, it SHOULD include an ice-
pacing attribute in the answerer (if not included, the default value
will apply). A lite ICE implementation MUST NOT included the ice-
pacing attribute in the answer (as it will not perform connectivity
chekcks).
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
skipping to change at page 9, line 32 skipping to change at page 9, line 47
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 an ICE mismatch, procedures If the answerer detects a possibility of an 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
candidate pairs and thus preventing premature declaration of ICE
failure in certain scenarios such as, if the peer has not provided
any candidates, or if all provided candidates have failed or have
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
skipping to change at page 10, line 14 skipping to change at page 10, line 24
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 an "a=ice- ICE procedures MUST be used for data streams where an "a=ice-
mismatch" 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
candidate pairs and thus preventing premature declaration of ICE
failure in certain scenarios such as, if the peer has not provided
any candidates, or if all provided candidates have failed or have
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 agent has successfully nominated a pair [RFC8445], the state
the controlling agent, it nominates a candidate pair [RFC8445] and of the check list associated with the pair is set to Completed. Once
checks for each data stream whether the nominated pair matches the the state of each check list is set to either Completed or Failed,
default candidate pair. If there are one or more data streams don't for each Completed check list the agent checks whether the nominated
match, and the peer did not indicate support for the 'ice2' ice- pair matches the default candidate pair. If there are one or more
option, the controlling agent MUST generate a subsequent offer pairs that do not match, and the peer did not indicate support for
(Section 3.4.1), in which the connection address, port and transport the 'ice2' ice-option, the controlling agent MUST generate a
subsequent offer, 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 (Section 3.4.1.2.2). If the peer did indicate
support for the 'ice2' ice-option, the controlling agent does not
immediately need to generate an updated offer in order to align a
connection address, port and protocol with a nominated pair.
However, later in the session, whenever the controlling agent does
sent a subsequent offer, it MUST do the alignment as described above.
However, if the support for 'ice2' ice-option is in use, the If there are one or more check lists with the state set to Failed,
nominated candidate is noted and sent in the subsequent offer/answer the controlling agent MUST generate a subsequent offer in order to
exchange as the default candidate and no updated offer is needed to remove the associated data streams by setting the port value of the
fix the default candidate. data streams to zero (Section 3.4.1.1.2), even if the peer did
indicate support for the 'ice2' ice-option. If needed, such offer
can also be used to align the connection address, port and transport
protocol, as described above.
Also as described in [RFC8445], once the controlling agent has As described in [RFC8445], once the controlling agent has nominated a
nominated a candidate pair for a data stream, the agent MUST NOT candidate pair for a check list, the agent MUST NOT nominate another
nominate another pair for that data stream during the lifetime of the pair for that check list during the lifetime of the ICE session (i.e.
ICE session (i.e. until ICE is restarted). until ICE is restarted).
[draft-ietf-ice-pac] provides a mechanism for allowing the ICE
process to run long enough in order to find working candidate pairs,
by waiting for potential peer-reflexive candidates, even though no
candidate pairs were received from the peer or all current candidate
pairs associated with a check list have either failed or been
discarded. It is OPTIONAL for an ICE agent to support the mechanism.
3.4. Subsequent Offer/Answer Exchanges 3.4. Subsequent Offer/Answer Exchanges
Either agent MAY generate a subsequent offer at any time allowed by Either agent MAY generate a subsequent offer at any time allowed by
[RFC3264]. This section defines rules for construction of subsequent [RFC3264]. This section defines rules for construction of subsequent
offers and answers. offers and answers.
Should a subsequent offer fail, ICE processing continues as if the Should a subsequent offer fail, ICE processing continues as if the
subsequent offer had never been made. subsequent offer had never been made.
3.4.1. Sending Subsequent Offer 3.4.1. Sending Subsequent Offer
3.4.1.1. Procedures for All Implementations 3.4.1.1. Procedures for All Implementations
3.4.1.1.1. ICE Restarts 3.4.1.1.1. ICE Restart
An agent MAY restart ICE processing for an existing data stream An agent MAY restart ICE processing for an existing data stream
[RFC8445]. [RFC8445].
The rules governing the ICE restart imply that setting the connection The rules governing the ICE restart imply that setting the connection
address in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will address in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will
cause an ICE restart. Consequently, ICE implementations MUST NOT cause an ICE restart. Consequently, ICE implementations MUST NOT
utilize this mechanism for call hold, and instead MUST use utilize this mechanism for call hold, and instead MUST use
"a=inactive" and "a=sendonly" as described in [RFC3264]. "a=inactive" and "a=sendonly" as described in [RFC3264].
To restart ICE, an agent MUST change both the ice-pwd and the ice- To restart ICE, an agent MUST change both the ice-pwd and the ice-
ufrag for the data stream in an offer. However, it is permissible to ufrag for the data stream in an offer. However, it is permissible to
use a session-level attribute in one offer, but to provide the same use a session-level attribute in one offer, but to provide the same
ice-pwd or ice-ufrag as a media-level attribute in a subsequent ice-pwd or ice-ufrag as a media-level attribute in a subsequent
offer. This MUST NOT be considered as ICE restart. offer. This MUST NOT be considered as ICE restart.
An agent sets the rest of the ICE-related fields in the SDP for this An agent sets the rest of the ICE-related fields in the SDP for this
data stream as it would in an initial offer of this data stream (see data stream as it would in an initial offer of this data stream (see
Section 3.2.1). Consequently, the set of candidates MAY include Section 3.2.1). Consequently, the set of candidates MAY include
some, none, or all of the previous candidates for that data stream some, none, or all of the previous candidates for that data stream
and MAY include a totally new set of candidates. and MAY include a totally new set of candidates. The agent MAY
modify the attribute values of the SDP ice-options and SDP ice-pacing
attributes, and it MAY change its role using the SDP ice-lite
attribute. The agent MUST NOT modify the SDP ice-options, ice-pacing
and ice-lite attributes in a subsequent offer unless the offer is
sent in order to request an ICE restart.
3.4.1.1.2. Removing a Data Stream 3.4.1.1.2. Removing a Data Stream
If an agent removes a data stream by setting its port to zero, it If an agent removes a data stream by setting its port to zero, it
MUST NOT include any candidate attributes for that data stream and MUST NOT include any candidate attributes for that data stream and
SHOULD NOT include any other ICE-related attributes defined in SHOULD NOT include any other ICE-related attributes defined in
Section 4 for that data stream. Section 4 for that data stream.
3.4.1.1.3. Adding a Data Stream 3.4.1.1.3. Adding a Data Stream
skipping to change at page 14, line 25 skipping to change at page 14, line 46
Once there are no losing pairs, the agent can generate the answer. Once there are no losing pairs, the agent can generate the answer.
It MUST set the default destination for media to the candidates in It MUST set the default destination for media to the candidates in
the remote-candidates attribute from the offer (each of which will the remote-candidates attribute from the offer (each of which will
now be the local candidate of a candidate pair in the valid list). now be the local candidate of a candidate pair in the valid list).
It MUST include a candidate attribute in the answer for each It MUST include a candidate attribute in the answer for each
candidate in the remote-candidates attribute in the offer. candidate in the remote-candidates attribute in the offer.
3.4.2.1. ICE Restart 3.4.2.1. ICE Restart
If the offerer in a subsequent offer requested an ICE restart for a If the offerer in a subsequent offer requested an ICE restart
data stream, and if the answerer accepts the offer, the answerer Section 3.4.1.1.1 for a data stream, and if the answerer accepts the
follows the procedures for generating an initial answer. offer, the answerer follows the procedures for generating an initial
answer.
For a given data stream, the answerer MAY include the same candidates For a given data stream, the answerer MAY include the same candidates
that were used in the previous ICE session, but it MUST change the that were used in the previous ICE session, but it MUST change the
SDP ice-pwd and ice-ufrag attribute values. SDP ice-pwd and ice-ufrag attribute values.
The answerer MAY modify the attribute values of the SDP ice-options
and SDP ice-pacing attributes, and it MAY change its role using the
SDP ice-lite attribute. The answerer MUST NOT modify the SDP ice-
options, ice-pacing and ice-lite attributes in a subsequent answer
unless the answer is sent for an offer that was used to request an
ICE restart Section 3.4.1.1.1. If any of the SDP attributes have
been modified in a subsequent offer that is not used to request an
ICE restart, the answerer MUST reject the offer.
3.4.2.2. Lite Implementation specific procedures 3.4.2.2. Lite Implementation specific procedures
If the received offer contains the remote-candidates attribute for a If the received offer contains the remote-candidates attribute for a
data stream, the agent forms a candidate pair for each component of data stream, the agent forms a candidate pair for each component of
the data stream by: the data stream by:
o Setting the remote candidate equal to the offerer's default o Setting the remote candidate equal to the offerer's default
destination for that component (i.e., the contents of the "m=" and destination for that component (i.e., the contents of the "m=" and
"c=" lines for RTP, and the "a=rtcp" attribute for RTCP). "c=" lines for RTP, and the "a=rtcp" attribute for RTCP).
skipping to change at page 21, line 19 skipping to change at page 22, line 8
characters when receiving. characters when receiving.
Example shows sample ice-ufrag and ice-pwd SDP lines: Example shows sample ice-ufrag and ice-pwd SDP lines:
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
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 (Ta interval), in milliseconds,
(see section 14 of [RFC8445]). The syntax is: that the sender wishes to use. See section 14.2 of [RFC8445] for
more information regarding selecting a pacing value. 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 If absent in an offer and answer the default value of the attribute
50ms is used for an agent when the ice-pacing attribute is omitted in is 50 ms, which is the recommended value specified in [RFC8445].
the offer or the answer.
The same rule applies for ice-pacing attribute values lower than
50ms. This mandates that, if an agent includes the ice-pacing
attribute, its value MUST be greater than 50ms or else a value of
50ms is considered by default for that agent.
Also the larger of the ice-pacing attribute values between the offer Once both agents have indicated the pacing value they with to use,
and the answer (determined either by the one provided in the ice- both agents MUST use the larger of the indicated values.
pacing attribute or by picking the default value) MUST be considered
for a given ICE session.
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
skipping to change at page 35, line 7 skipping to change at page 35, line 37
May 2017, <http://www.rfc-editor.org/info/rfc8174>. May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<http://www.rfc-editor.org/info/rfc8445>. <http://www.rfc-editor.org/info/rfc8445>.
11.2. Informative References 11.2. Informative References
[draft-holmberg-ice-pac] [draft-ietf-ice-pac]
Holmberg, C. and J. Uberti, "Interactive Connectivity Holmberg, C. and J. Uberti, "Interactive Connectivity
Establishment Patiently Awaiting Connectivity (ICE PAC)", Establishment Patiently Awaiting Connectivity (ICE PAC)",
draft-holmberg-ice-pac-01 (work in progress), March 2019, draft-ietf-ice-pac-02 (work in progress), July 2019,
<http://www.ietf.org/internet-drafts/ <http://www.ietf.org/internet-drafts/
draft-holmberg-ice-pac-01.txt>. draft-ietf-ice-pac-02.txt>.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<http://www.rfc-editor.org/info/rfc3725>. <http://www.rfc-editor.org/info/rfc3725>.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing
Tone Generation in the Session Initiation Protocol (SIP)", Tone Generation in the Session Initiation Protocol (SIP)",
RFC 3960, DOI 10.17487/RFC3960, December 2004, RFC 3960, DOI 10.17487/RFC3960, December 2004,
skipping to change at page 40, line 17 skipping to change at page 41, line 17
function without change, the core property of SDP -- that the function without change, the core property of SDP -- that the
existing, pre-ICE definitions of the addresses used for media -- the existing, pre-ICE definitions of the addresses used for media -- the
"m=" and "c=" lines and the rtcp attribute -- must be retained. For "m=" and "c=" lines and the rtcp attribute -- must be retained. For
this reason, an updated offer must be sent. this reason, an updated offer must be sent.
Appendix E. Contributors Appendix E. Contributors
Following experts have contributed textual and structural Following experts have contributed textual and structural
improvements for this work improvements for this work
1. Christer Holmberg 1. Thomas Stach
* Ericsson
* Email: christer.holmberg@ericsson.com
2. Roman Shpount
* TurboBridge
* rshpount@turbobridge.com
3. Thomas Stach
* thomass.stach@gmail.com * thomass.stach@gmail.com
Authors' Addresses Authors' Addresses
Marc Petit-Huguenin Marc Petit-Huguenin
Impedance Mismatch Impedance Mismatch
Email: marc@petit-huguenin.org Email: marc@petit-huguenin.org
skipping to change at page 41, line 4 skipping to change at page 41, line 35
Email: marc@petit-huguenin.org Email: marc@petit-huguenin.org
Suhas Nandakumar Suhas Nandakumar
Cisco Systems Cisco Systems
707 Tasman Dr 707 Tasman Dr
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
Email: snandaku@cisco.com Email: snandaku@cisco.com
Ari Keranen Ari Keranen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
Roman Shpount
TurboBridge
4905 Del Ray Avenue, Suite 300
Bethesda, MD 20814
USA
Phone: +1 (240) 292-6632
Email: rshpount@turbobridge.com
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
 End of changes. 42 change blocks. 
102 lines changed or deleted 119 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/