draft-ietf-mmusic-ice-sip-sdp-35.txt   draft-ietf-mmusic-ice-sip-sdp-36.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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: December 8, 2019 A. Keranen
Ericsson Ericsson
June 6, 2019 June 6, 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-35 draft-ietf-mmusic-ice-sip-sdp-36
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 3, line 33 skipping to change at page 3, line 33
9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 30 9.1.5. ice-pwd Attribute . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . 35
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. The remote-candidates Attribute . . . . . . . . . . 38 Appendix B. The remote-candidates Attribute . . . . . . . . . . 37
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 39 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 38
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 40 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 39
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 41 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in
2119 [RFC2119]. [RFC8174].
Readers should be familiar with the terminology defined in [RFC3264], Readers should be familiar with the terminology defined in [RFC3264],
in [RFC8445] and the following: in [RFC8445] and the following:
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
skipping to change at page 4, line 35 skipping to change at page 4, line 35
and 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 terms
terminologies offerer and answerer correspond to the initiator and "offerer" and "answerer" correspond to the initiator and responder
responder terminologies from [RFC8445] respectively. roles from [RFC8445] respectively.
Once the initiating agent has gathered, pruned and prioritized its Once the initiating agent has gathered, pruned, and prioritized its
set of candidates [RFC8445], the candidate exchange with the peer set of candidates [RFC8445], the candidate exchange with the peer
agent begins. agent begins.
3.2. Generic Procedures 3.2. Generic Procedures
3.2.1. Encoding 3.2.1. Encoding
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
Within a "m=" section, each candidate (including the default Within an "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 5, line 51 skipping to change at page 5, line 51
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. If an agent
receives an SDP offer or answer with ICE attributes but without the receives an SDP offer or answer with ICE attributes but without the
"ice2" ice-options attribute value, the agent assumes that the peer "ice2" ice-options attribute value, the agent assumes that the peer
is compliant to [RFC5245]. 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
that "m=" section, unless an SDP extension specifying otherwise is that "m=" section, unless an SDP extension specifying otherwise is
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]
skipping to change at page 6, line 43 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 in the "c=" RTP, the connection address, port, and transport protocol in the "c="
and "m=" lines, respectively, appear in a candidate attribute and the and "m=" lines, respectively, appear in a candidate attribute 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
skipping to change at page 9, line 25 skipping to change at page 9, line 25
that the answering agent is only going to use peer reflexive that the answering 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.
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 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 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 in 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 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 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 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 in 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
skipping to change at page 11, line 26 skipping to change at page 11, line 26
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.
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
If an agent wishes to add a new data stream, it sets the fields in If an agent wishes to add a new data stream, it sets the fields in
the SDP for this data stream as if this was an initial offer for that the SDP for this data stream as if this were an initial offer for
data stream (see Section 3.2.1). This will cause ICE processing to that data stream (see Section 3.2.1). This will cause ICE processing
begin for this data stream. to begin for this data stream.
3.4.1.2. Procedures for Full Implementations 3.4.1.2. Procedures for Full Implementations
This section describes additional procedures for full This section describes additional procedures for full
implementations, covering existing data streams. implementations, covering existing data streams.
3.4.1.2.1. Before Nomination 3.4.1.2.1. Before Nomination
When an offerer sends a subsequent offer; in each "m=" section for When an offerer sends a subsequent offer; in each "m=" section for
which a candidate pair has not yet been nominated, the offer MUST which a candidate pair has not yet been nominated, the offer MUST
include the same set of ICE-related information that the offerer include the same set of ICE-related information that the offerer
included in the previous offer or answer. The agent MAY include included in the previous offer or answer. The agent MAY include
additional candidates it did not offer previously, but which it has additional candidates it did not offer previously, but which it has
gathered since the last offer/ answer exchange, including peer gathered since the last offer/answer exchange, including peer
reflexive candidates. reflexive candidates.
The agent MAY change the default destination for media. As with The agent MAY change the default destination for media. As with
initial offers, there MUST be a set of candidate attributes in the initial offers, there MUST be a set of candidate attributes in the
offer matching this default destination. offer matching this default destination.
3.4.1.2.2. After Nomination 3.4.1.2.2. After Nomination
Once a candidate pair has been nominated for a data stream, the Once a candidate pair has been nominated for a data stream, the
connection address, port and transport protocol in each "c=" and "m=" connection address, port and transport protocol in each "c=" and "m="
skipping to change at page 12, line 41 skipping to change at page 12, line 41
is in the completed state. The attribute contains the remote is in the completed state. The attribute contains the remote
candidates corresponding to the nominated pair in the valid list for candidates corresponding to the nominated pair in the valid list for
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" attributes 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 identically 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 and 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
to the remote candidate of the candidate pair for that component in to the remote candidate of the candidate pair for that component in
the valid list. For a lite implementation, there is always just a the valid list. For a lite implementation, there is always just a
single candidate pair in the valid list for each component of a data single candidate pair in the valid list for each component of a data
stream. Additionally, the agent MUST include a candidate attribute stream. Additionally, the agent MUST include a candidate attribute
for each default destination. for each default destination.
skipping to change at page 15, line 28 skipping to change at page 15, line 28
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 included answer that lacks ICE candidates although the initial answer included
them. One example of such an "unexpected" answer might be happen them. One example of such an "unexpected" answer might be happen
when an ICE-unaware Back-to-Back User Agent (B2BUA) introduces a when an ICE-unaware Back-to-Back User Agent (B2BUA) introduces a
media server during call hold using 3rd party call-control media server during call hold using 3rd party call-control procedures
procedures. Omitting further details how this is done, this could [RFC3725]. Omitting further details how this is done, this could
result in an answer being received at the holding UA that was result in an answer being received at the holding UA that was
constructed by the B2BUA. With the B2BUA being ICE-unaware, that constructed by the B2BUA. With the B2BUA being ICE-unaware, that
answer would not include ICE candidates. 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 one of the following actions: offer performs one of the following actions:
skipping to change at page 16, line 7 skipping to change at page 16, line 7
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
MUST create a new check list for it (and an empty Valid list to MUST create a new check list for it (and an empty Valid list to
start of course) which in turn triggers the candidate processing start of course) which in turn triggers the candidate processing
procedures [RFC8445]. procedures [RFC8445].
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, its state is copied over.
state is copied over. Otherwise, its state is set to Frozen. If Otherwise, its state is set to Frozen. If none of the check lists
none of the check lists are active (meaning that the pairs in each are active (meaning that the pairs in each check list are Frozen),
check list are Frozen), appropriate procedures in [RFC8445] are appropriate procedures in [RFC8445] are performed to move
performed to move candidate(s) to the Waiting state to further candidate(s) to the Waiting state to further continue ICE
continue ICE processing. 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 remain 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
component of the data stream, called the previous selected pair prior component of the data stream, called the "previous selected pair",
to the restart. The agent will continue to send media using this prior to the restart. The agent will continue to send media using
pair, as described in section 12 of [RFC8445]. Once these this pair, as described in section 12 of [RFC8445]. Once these
destinations are noted, the agent MUST flush the valid and check destinations are noted, the agent MUST flush the valid and check
lists, and then recompute the check list and its states, thus lists, and then recompute the check list and its states, thus
triggering the candidate processing procedures [RFC8445] triggering the candidate processing procedures [RFC8445]
3.4.3.2. Procedures for Lite Implementations 3.4.3.2. Procedures for Lite Implementations
If ICE is restarting for a data stream, the agent MUST start a new If ICE is restarting for a data stream, the agent MUST start a new
Valid list for that data stream. It MUST remember the nominated pair Valid list for that data stream. It MUST remember the nominated pair
in the previous Valid list for each component of the data stream, in the previous Valid list for each component of the data stream,
called the previous selected pairs, and continue to send media there called the "previous selected pairs", and continue to send media
as described in section 12 of [RFC8445]. The state of ICE processing there as described in section 12 of [RFC8445]. The state of ICE
for each data stream MUST change to Running, and the state of ICE processing for each data stream MUST change to Running, and the state
processing MUST change to Running of ICE processing MUST change to Running
4. Grammar 4. Grammar
This specification defines eight new SDP attributes -- the This specification defines eight new SDP attributes -- the
"candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-
ufrag", "ice-pwd", "ice-pacing", and "ice-options" attributes. ufrag", "ice-pwd", "ice-pacing", and "ice-options" attributes.
This section also provides non-normative examples of the attributes This section also provides non-normative examples of the attributes
defined. defined.
skipping to change at page 18, line 23 skipping to change at page 18, line 23
ICE by extending the sub-registry "ICE Transport Protocols" under ICE by extending the sub-registry "ICE Transport Protocols" under
"Interactive Connectivity Establishment (ICE)" registry. "Interactive Connectivity Establishment (ICE)" registry.
<foundation>: is composed of 1 to 32 <ice-char>s. It is an <foundation>: is composed of 1 to 32 <ice-char>s. It is an
identifier that is equivalent for two candidates that are of the identifier that is equivalent for two candidates that are of the
same type, share the same base, and come from the same STUN same type, share the same base, and come from the same STUN
server. The foundation is used to optimize ICE performance in the server. The foundation is used to optimize ICE performance in the
Frozen algorithm as described in [RFC8445] Frozen algorithm as described in [RFC8445]
<component-id>: is a positive integer between 1 and 256 (inclusive) <component-id>: is a positive integer between 1 and 256 (inclusive)
that identifies the specific component of the dta stream for which that identifies the specific component of the data stream for
this is a candidate. It MUST start at 1 and MUST increment by 1 which this is a candidate. It MUST start at 1 and MUST increment
for each component of a particular candidate. For data streams by 1 for each component of a particular candidate. For data
based on RTP, candidates for the actual RTP media MUST have a streams based on RTP, candidates for the actual RTP media MUST
component ID of 1, and candidates for RTCP MUST have a component have a component ID of 1, and candidates for RTCP MUST have a
ID of 2. See section 13 in [RFC8445] for additional discussion on component ID of 2. See section 13 in [RFC8445] for additional
extending ICE to new data streams. discussion on extending ICE to new data streams.
<priority>: is a positive integer between 1 and (2**31 - 1) <priority>: is a positive integer between 1 and (2**31 - 1)
inclusive. The procedures for computing candidate's priority is inclusive. The procedures for computing candidate's priority is
described in section 5.1.2 of [RFC8445]. described in section 5.1.2 of [RFC8445].
<cand-type>: encodes the type of candidate. This specification <cand-type>: encodes the type of candidate. This specification
defines the values "host", "srflx", "prflx", and "relay" for host, defines the values "host", "srflx", "prflx", and "relay" for host,
server reflexive, peer reflexive, and relayed candidates, server reflexive, peer reflexive, and relayed candidates,
respectively. Specifications for new candidate types MUST define respectively. Specifications for new candidate types MUST define
how, if at all, various steps in the ICE processing differ from how, if at all, various steps in the ICE processing differ from
skipping to change at page 19, line 16 skipping to change at page 19, line 16
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
[RFC8126] and the assignments MUST contain the specific extension and [RFC8126] 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 Example: SDP line for UDP server reflexive candidate attribute for
the RTP component the RTP component
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
skipping to change at page 20, line 45 skipping to change at page 20, line 45
is effectively a default that applies to all data streams, unless is effectively a default that applies to all data streams, unless
overridden by a media-level value. Whether present at the session or overridden by a media-level value. Whether present at the session or
media-level, there MUST be an ice-pwd and ice-ufrag attribute for media-level, there MUST be an ice-pwd and ice-ufrag attribute for
each data stream. If two data streams have identical ice-ufrag's, each data stream. If two data streams have identical ice-ufrag's,
they MUST have identical ice-pwd's. they MUST have identical ice-pwd's.
The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the
beginning of a session (the same applies when ICE is restarting for beginning of a session (the same applies when ICE is restarting for
an agent). an agent).
The ice-ufrag attribute MUST contain at least 24 bits of randomness, [RFC8445] requires the ice-ufrag attribute to contain at least 24
and the ice-pwd attribute MUST contain at least 128 bits of bits of randomness, and the ice-pwd attribute to contain at least 128
randomness. This means that the ice-ufrag attribute will be at least bits of randomness. This means that the ice-ufrag attribute will be
4 characters long, and the ice-pwd at least 22 characters long, since at least 4 characters long, and the ice-pwd at least 22 characters
the grammar for these attributes allows for 6 bits of information per long, since the grammar for these attributes allows for 6 bits of
character. The attributes MAY be longer than 4 and 22 characters, information per character. The attributes MAY be longer than 4 and
respectively, of course, up to 256 characters. The upper limit 22 characters, respectively, of course, up to 256 characters. The
allows for buffer sizing in implementations. Its large upper limit upper limit allows for buffer sizing in implementations. Its large
allows for increased amounts of randomness to be added over time. upper limit allows for increased amounts of randomness to be added
For compatibility with the 512 character limitation for the STUN over time. For compatibility with the 512 character limitation for
username attribute value and for bandwidth conservation the STUN username attribute value and for bandwidth conservation
considerations, the ice-ufrag attribute MUST NOT be longer than 32 considerations, the ice-ufrag attribute MUST NOT be longer than 32
characters when sending, but an implementation MUST accept up to 256 characters when sending, but an implementation MUST accept up to 256
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
skipping to change at page 22, line 10 skipping to change at page 22, line 10
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 it is willing to use it, if extension is supported by the agent and it is willing to use it, if
the 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 extension gets used in a given session. agents that determine how the extension gets used in a given session.
The details of the negotiation procedures, if present, MUST be The details of the negotiation procedures, if present, MUST 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
regardless of whether the data stream is currently inactive, regardless of whether the data stream is currently inactive,
sendonly, recvonly, or sendrecv, and regardless of the presence or sendonly, recvonly, or sendrecv, and regardless of the presence or
value of the bandwidth attribute. An agent can determine that its value of the bandwidth attribute. An agent can determine that its
skipping to change at page 23, line 36 skipping to change at page 23, line 36
candidates. ICE requires that a provisional response with an SDP be candidates. ICE requires that a provisional response with an SDP be
transmitted reliably. This can be done through the existing transmitted reliably. This can be done through the existing
Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or
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
cease retransmitting the 18x after sending it four times since there retransmitting the 18x after sending it four times since there will
will be no Binding request sent and the number four is arbitrarily be no Binding request sent and the number four is arbitrarily chosen
chosen to limit the number of 18x retransmits (poor man's version of to limit the number of 18x retransmits (poor man's version of
[RFC3262] basically). (ICE will actually work even if the peer never [RFC3262] basically). (ICE will actually work even if the peer never
receives the 18x; however, experience has shown that sending it is receives the 18x; however, experience has shown that sending it 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
skipping to change at page 27, line 15 skipping to change at page 27, line 15
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 [RFC5768] in the SIP ICE answers MUST include an "ice" Option Tag [RFC5768] in the SIP
Require Header Field in their offer. UAs that rejects non-ICE offers Require Header Field in their offer. UAs that reject non-ICE offers
SHOULD use a 421 response code, together with an Option Tag "ice" in will generally use a 421 response code, together with an Option Tag
the Require Header Field in the response. "ice" in 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 29, line 7 skipping to change at page 29, line 7
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides one of many possible candidate Establishment (ICE), and provides one of many possible candidate
addresses for communication. These addresses are validated with addresses for communication. These addresses are validated with
an end-to-end connectivity check using Session Traversal Utilities an end-to-end connectivity check using Session Traversal Utilities
for NAT (STUN). for NAT (STUN).
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [1] Contact Email: esg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
9.1.2. remote-candidates Attribute 9.1.2. remote-candidates Attribute
Attribute Name: remote-candidates Attribute Name: remote-candidates
Type of Attribute: media-level Type of Attribute: media-level
skipping to change at page 29, line 30 skipping to change at page 29, line 30
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the identity of the remote Establishment (ICE), and provides the identity of the remote
candidates that the offerer wishes the answerer to use in its candidates that the offerer wishes the answerer to use in its
answer. answer.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [2] Contact Email: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
9.1.3. ice-lite Attribute 9.1.3. ice-lite Attribute
Attribute Name: ice-lite Attribute Name: ice-lite
Type of Attribute: session-level Type of Attribute: session-level
skipping to change at page 30, line 4 skipping to change at page 30, line 4
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates that an agent has the minimum Establishment (ICE), and indicates that an agent has the minimum
functionality required to support ICE inter-operation with a peer functionality required to support ICE inter-operation with a peer
that has a full implementation. that has a full implementation.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [3] Contact Email: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
9.1.4. ice-mismatch Attribute 9.1.4. ice-mismatch Attribute
Attribute Name: ice-mismatch Attribute Name: ice-mismatch
Type of Attribute: media-level Type of Attribute: media-level
skipping to change at page 30, line 27 skipping to change at page 30, line 27
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates that an agent is ICE capable, Establishment (ICE), and indicates that an agent is ICE capable,
but did not proceed with ICE due to a mismatch of candidates with but did not proceed with ICE due to a mismatch of candidates with
the default destination for media signaled in the SDP. the default destination for media signaled in the SDP.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [4] Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
9.1.5. ice-pwd Attribute 9.1.5. ice-pwd Attribute
Attribute Name: ice-pwd Attribute Name: ice-pwd
Type of Attribute: session- or media-level Type of Attribute: session- or media-level
skipping to change at page 30, line 49 skipping to change at page 30, line 49
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the password used to protect Establishment (ICE), and provides the password used to protect
STUN connectivity checks. STUN connectivity checks.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [5] Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
9.1.6. ice-ufrag Attribute 9.1.6. ice-ufrag Attribute
Attribute Name: ice-ufrag Attribute Name: ice-ufrag
Type of Attribute: session- or media-level Type of Attribute: session- or media-level
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the fragments used to construct Establishment (ICE), and provides the fragments used to construct
the username in STUN connectivity checks. the username in STUN connectivity checks.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [6] Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: TRANSPORT Mux Category: TRANSPORT
9.1.7. ice-options Attribute 9.1.7. ice-options Attribute
Attribute Name: ice-options Attribute Name: ice-options
Long Form: ice-options Long Form: ice-options
skipping to change at page 31, line 46 skipping to change at page 31, line 46
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and indicates the ICE options or extensions Establishment (ICE), and indicates the ICE options or extensions
used by the agent. used by the agent.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [7] Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
9.1.8. ice-pacing Attribute 9.1.8. ice-pacing Attribute
This specification also defines a new SDP attribute, "ice-pacing" This specification also defines a new SDP attribute, "ice-pacing"
according to the following data: according to the following data:
skipping to change at page 32, line 24 skipping to change at page 32, line 24
Subject to charset: No Subject to charset: No
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE) to indicate desired connectivity check pacing Establishment (ICE) to indicate desired connectivity check pacing
values. values.
Appropriate Values: See Section 4 of RFC XXXX. Appropriate Values: See Section 4 of RFC XXXX.
Contact Name: IESG Contact Name: IESG
Contact e-mail: iesg@ietf.org [8] Contact e-mail: iesg@ietf.org
Reference: RFCXXXX Reference: RFCXXXX
Mux Category: NORMAL Mux Category: NORMAL
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" [RFC8126]. an IANA Considerations Section in RFCs" [RFC8126].
skipping to change at page 33, line 30 skipping to change at page 33, line 30
Many thanks to Flemming Andreasen for shepherd review feedback. Many thanks to Flemming Andreasen for shepherd review feedback.
Thanks to following experts for their reviews and constructive Thanks to following experts for their reviews and constructive
feedback: Christer Holmberg, Adam Roach, Peter Saint-Andre and the feedback: Christer Holmberg, Adam Roach, Peter Saint-Andre and the
MMUSIC WG. MMUSIC WG.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<http://www.rfc-editor.org/info/rfc3262>. <http://www.rfc-editor.org/info/rfc3262>.
skipping to change at page 34, line 47 skipping to change at page 34, line 42
2010, <http://www.rfc-editor.org/info/rfc5768>. 2010, <http://www.rfc-editor.org/info/rfc5768>.
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
RFC 6336, April 2010, RFC 6336, April 2010,
<http://www.rfc-editor.org/info/rfc6336>. <http://www.rfc-editor.org/info/rfc6336>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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-holmberg-ice-pac]
skipping to change at page 36, line 11 skipping to change at page 36, line 5
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, DOI 10.17487/RFC5626, October 2009,
<http://www.rfc-editor.org/info/rfc5626>. <http://www.rfc-editor.org/info/rfc5626>.
[RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing, [RFC5898] Andreasen, F., Camarillo, G., Oran, D., and D. Wing,
"Connectivity Preconditions for Session Description "Connectivity Preconditions for Session Description
Protocol (SDP) Media Streams", RFC 5898, Protocol (SDP) Media Streams", RFC 5898,
DOI 10.17487/RFC5898, July 2010, DOI 10.17487/RFC5898, July 2010,
<http://www.rfc-editor.org/info/rfc5898>. <http://www.rfc-editor.org/info/rfc5898>.
11.3. URIs [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
[1] mailto:iesg@ietf.org for RTP over UDP", RFC 6679, August 2012,
<http://www.rfc-editor.org/info/rfc6679>.
[2] mailto:iesg@ietf.org
[3] mailto:iesg@ietf.org
[4] mailto:iesg@ietf.org
[5] mailto:iesg@ietf.org
[6] mailto:iesg@ietf.org
[7] mailto:iesg@ietf.org
[8] mailto:iesg@ietf.org
[9] mailto:christer.holmberg@ericsson.com
[10] mailto:rshpount@turbobridge.com
[11] mailto:thomass.stach@gmail.com
Appendix A. Examples Appendix A. Examples
For the example shown in section 15 of [RFC8445] the resulting offer For the example shown in section 15 of [RFC8445] the resulting offer
(message 5) encoded in SDP looks like: (message 5) encoded in SDP looks like:
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP o=jdoe 2890844526 2890842807 IN IP6 $L-PRIV-1.IP
s= s=
c=IN IP6 $NAT-PUB-1.IP c=IN IP6 $NAT-PUB-1.IP
skipping to change at page 40, line 46 skipping to change at page 39, line 46
Appendix D. Why Send an Updated Offer? Appendix D. Why Send an Updated Offer?
Section 11.1 describes rules for sending media. Both agents can send Section 11.1 describes rules for sending media. Both agents can send
media once ICE checks complete, without waiting for an updated offer. media once ICE checks complete, without waiting for an updated offer.
Indeed, the only purpose of the updated offer is to "correct" the SDP Indeed, the only purpose of the updated offer is to "correct" the SDP
so that the default destination for media matches where media is so that the default destination for media matches where media is
being sent based on ICE procedures (which will be the highest- being sent based on ICE procedures (which will be the highest-
priority nominated candidate pair). priority nominated candidate pair).
This begs the question -- why is the updated offer/answer exchange This raises the question -- why is the updated offer/answer exchange
needed at all? Indeed, in a pure offer/answer environment, it would needed at all? Indeed, in a pure offer/answer environment, it would
not be. The offerer and answerer will agree on the candidates to use not be. The offerer and answerer will agree on the candidates to use
through ICE, and then can begin using them. As far as the agents through ICE, and then can begin using them. As far as the agents
themselves are concerned, the updated offer/answer provides no new themselves are concerned, the updated offer/answer provides no new
information. However, in practice, numerous components along the information. However, in practice, numerous components along the
signaling path look at the SDP information. These include entities signaling path look at the SDP information. These include entities
performing off-path QoS reservations, NAT traversal components such performing off-path QoS reservations, NAT traversal components such
as ALGs and Session Border Controllers (SBCs), and diagnostic tools as ALGs and Session Border Controllers (SBCs), and diagnostic tools
that passively monitor the network. For these tools to continue to that passively monitor the network. For these tools to continue to
function without change, the core property of SDP -- that the function without change, the core property of SDP -- that the
skipping to change at page 41, line 21 skipping to change at page 40, line 21
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. Christer Holmberg
* Ericsson * Ericsson
* Email: christer.holmberg@ericsson.com [9] * Email: christer.holmberg@ericsson.com
2. Roman Shpount 2. Roman Shpount
* TurboBridge * TurboBridge
* rshpount@turbobridge.com [10] * rshpount@turbobridge.com
3. Thomas Stach 3. Thomas Stach
* thomass.stach@gmail.com [11] * 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
Suhas Nandakumar Suhas Nandakumar
Cisco Systems Cisco Systems
 End of changes. 47 change blocks. 
114 lines changed or deleted 93 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/