draft-ietf-mmusic-ice-sip-sdp-22.txt   draft-ietf-mmusic-ice-sip-sdp-23.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: April 12, 2019 A. Keranen Expires: April 12, 2019 A. Keranen
Ericsson Ericsson
October 9, 2018 October 9, 2018
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-22 draft-ietf-mmusic-ice-sip-sdp-23
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 3, line 43 skipping to change at page 3, line 43
Appendix B. The remote-candidates Attribute . . . . . . . . . . 37 Appendix B. The remote-candidates Attribute . . . . . . . . . . 37
Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 37 Appendix C. Why Is the Conflict Resolution Mechanism Needed? . . 37
Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 38 Appendix D. Why Send an Updated Offer? . . . . . . . . . . . . . 38
Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 39 Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
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 [ICE-BIS] 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.
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 RFC
2119 [RFC2119]. 2119 [RFC2119].
Readers should be familiar with the terminology defined in [RFC3264], Readers should be familiar with the terminology defined in [RFC3264],
in [ICE-BIS] 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 IP address is in the "c=" line of the SDP, and the port is default IP address is in the "c=" line of the SDP, and the port is
in the "m=" line. For the RTCP component, the address and port in the "m=" line. For the RTCP component, the address and port
are indicated using the "a=rtcp" attribute defined in [RFC3605], are indicated using the "a=rtcp" attribute defined in [RFC3605],
if present; otherwise, the RTCP component address is same as the if present; otherwise, the RTCP component address is same as the
address of the RTP component, and its port is one greater than the address of the RTP component, and its port is one greater than the
port of the RTP component. port of the RTP component.
3. SDP Offer/Answer Procedures 3. SDP Offer/Answer Procedures
3.1. Introduction 3.1. Introduction
[ICE-BIS] 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
terminologies offerer and answerer correspond to the initiator and terminologies offerer and answerer correspond to the initiator and
responder terminologies from [ICE-BIS] respectively. responder terminologies 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 [ICE-BIS], 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 [ICE-BIS] is represented by an SDP media description Each data stream [RFC8445] is represented by an SDP media description
("m=" section). ("m=" section).
3.2.1.2. Candidates 3.2.1.2. Candidates
With in a "m=" section, each candidate (including the default With in a "m=" section, each candidate (including the default
candidate) associated with the data stream is represented by an SDP candidate) associated with the data stream is represented by an SDP
candidate attribute. candidate attribute.
Prior to nomination, the "c=" line associated with an "m=" section Prior to nomination, the "c=" line associated with an "m=" section
contains the IP address of the default candidate, while the "m=" line contains the IP address of the default candidate, while the "m=" line
skipping to change at page 5, line 29 skipping to change at page 5, line 29
transport corresponding to the nominated candidate for that "m=" transport corresponding to the nominated candidate for that "m="
section. section.
3.2.1.3. Username and Password 3.2.1.3. Username and Password
The ICE username is represented by an SDP ice-ufrag attribute and the The ICE username is represented by an SDP ice-ufrag attribute and the
ICE password is represented by an SDP ice-pwd attribute. ICE password is represented by an SDP ice-pwd attribute.
3.2.1.4. Lite Implementations 3.2.1.4. Lite Implementations
An ICE lite implementation [ICE-BIS] 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. 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
skipping to change at page 6, line 26 skipping to change at page 6, line 26
higher than the RTP port and RTCP component address is same as the higher than the RTP port and RTCP component address is same as the
address of the RTP component, the SDP rtcp attribute MAY be omitted. address of the RTP component, the SDP rtcp attribute MAY be omitted.
If the agent does not utilize RTCP, it indicates that by including If the agent does not utilize RTCP, it indicates that by including
b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556]. b=RS:0 and b=RR:0 SDP attributes, as described in [RFC3556].
3.2.3. Determining Role 3.2.3. Determining Role
The offerer acts as the Initiating agent. The answerer acts as the The offerer acts as the Initiating agent. The answerer acts as the
Responding agent. The ICE roles (controlling and controlled) are Responding agent. The ICE roles (controlling and controlled) are
determined using the procedures in [ICE-BIS]. determined using the procedures in [RFC8445].
3.2.4. STUN Considerations 3.2.4. STUN Considerations
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 [ICE-BIS] 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 IP address and port in the "c=" and "m=" lines, RTP, the IP address and port in the "c=" and "m=" lines,
respectively, appear in a candidate attribute and the value in the respectively, appear in a candidate attribute and the value in the
rtcp attribute appears in a candidate attribute. rtcp attribute appears in a candidate attribute.
If this condition is not met, the agents MUST process the SDP based If this condition is not met, the agents MUST process the SDP based
on normal [RFC3264] procedures, without using any of the ICE on normal [RFC3264] procedures, without using any of the ICE
mechanisms described in the remainder of this specification with the mechanisms described in the remainder of this specification with the
skipping to change at page 8, line 50 skipping to change at page 8, line 50
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 offerer detects an ICE mismatch in the answer, the offerer MUST the offerer detects an ICE mismatch in the answer, the offerer MUST
terminate the usage of ICE. The subsequent actions taken by the terminate the usage of ICE. The subsequent actions taken by the
offerer are implementation dependent and are out of the scope of this offerer are implementation dependent and are out of the scope of this
specification. specification.
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 [ICE-BIS] and the controlling agent, it nominates a candidate pair [RFC8445] and
checks for each data stream whether the nominated pair matches the checks for each data stream whether the nominated pair matches the
default candidate pair. If there are one or more data streams with a default candidate pair. If there are one or more data streams with a
match, and the peer did not indicate support for the 'ice2' ice- match, and the peer did not indicate support for the 'ice2' ice-
option, the controlling agent MUST generate a subsequent offer option, the controlling agent MUST generate a subsequent offer
(Section 3.4.1), in which the IP address, port and transport in the (Section 3.4.1), in which the IP address, port and transport in the
"c=" and "m=" lines associated with each data stream match the "c=" and "m=" lines associated with each data stream match the
corresponding local information of the nominated pair for that data corresponding local information of the nominated pair for that data
stream. stream.
However, If the support for 'ice2' ice-option is in use, the However, If the support for 'ice2' ice-option is in use, the
nominated candidate is noted and sent in the subsequent offer/answer nominated candidate is noted and sent in the subsequent offer/answer
exchange as the default candidate and no updated offer is needed to exchange as the default candidate and no updated offer is needed to
fix the default candidate. fix the default candidate.
Also as described in [ICE-BIS], once the controlling agent has Also as described in [RFC8445], once the controlling agent has
nominated a candidate pair for a data stream, the agent MUST NOT nominated a candidate pair for a data stream, the agent MUST NOT
nominate another pair for that data stream during the lifetime of the nominate another pair for that data stream during the lifetime of the
ICE session (i.e. until ICE is restarted). ICE session (i.e. until ICE is restarted).
3.4. Subsequent Offer/Answer Exchanges 3.4. Subsequent Offer/Answer Exchanges
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 Restarts
An agent MAY restart ICE processing for an existing data stream An agent MAY restart ICE processing for an existing data stream
[ICE-BIS]. [RFC8445].
The rules governing the ICE restart imply that setting the IP address The rules governing the ICE restart imply that setting the IP address
in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will cause an in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will cause an
ICE restart. Consequently, ICE implementations MUST NOT utilize this ICE restart. Consequently, ICE implementations MUST NOT utilize this
mechanism for call hold, and instead MUST use a=inactive and mechanism for call hold, and instead MUST use a=inactive and
a=sendonly as described in [RFC3264]. 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
skipping to change at page 13, line 38 skipping to change at page 13, line 38
around the same time. around the same time.
However, the signaling protocol carrying the offer/answer exchanges However, the signaling protocol carrying the offer/answer exchanges
will have resolved this glare condition, so that one agent is always will have resolved this glare condition, so that one agent is always
the 'winner' by having its offer received before its peer has sent an the 'winner' by having its offer received before its peer has sent an
offer. The winner takes the role of controlling, so that the loser offer. The winner takes the role of controlling, so that the loser
(the answerer under consideration in this section) MUST change its (the answerer under consideration in this section) MUST change its
role to controlled. role to controlled.
Consequently, if the agent was going to send an updated offer since, Consequently, if the agent was going to send an updated offer since,
based on the rules in section 8.2 of [ICE-BIS], it was controlling, based on the rules in section 8.2 of [RFC8445], it was controlling,
it no longer needs to. it no longer needs to.
Besides the potential role change, change in the Valid list, and Besides the potential role change, change in the Valid list, and
state changes, the construction of the answer is performed state changes, the construction of the answer is performed
identically to the construction of an offer. identically to the construction of an offer.
3.4.3. Receiving Answer for a Subsequent Offer 3.4.3. Receiving Answer for a Subsequent Offer
3.4.3.1. Procedures for Full Implementations 3.4.3.1. Procedures for Full Implementations
skipping to change at page 14, line 26 skipping to change at page 14, line 26
procedures as specified in Section 3.4.3.1.1 procedures as specified in Section 3.4.3.1.1
o If the offer/answer exchange removed a data stream, or an answer o If the offer/answer exchange removed a data stream, or an answer
rejected an offered data stream, an agent MUST flush the Valid rejected an offered data stream, an agent MUST flush the Valid
list for that data stream. It MUST also terminate any STUN list for that data stream. It MUST also terminate any STUN
transactions in progress for that data stream. transactions in progress for that data stream.
o If the offer/answer exchange added a new data stream, the agent o If the offer/answer exchange added a new data stream, the agent
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 [ICE-BIS]. 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, and its state is not Frozen, its
state is copied over. Otherwise, its state is set to Frozen. If state is copied over. Otherwise, its state is set to Frozen. If
none of the check lists are active (meaning that the pairs in each none of the check lists are active (meaning that the pairs in each
check list are Frozen), appropriate procedures in [ICE-BIS] are check list are Frozen), appropriate procedures in [RFC8445] are
performed to move candidate(s) to the Waiting state to further performed to move candidate(s) to the Waiting state to further
continue ICE processing. continue ICE processing.
o If ICE state is completed and the SDP answer conforms to o If ICE state is completed and the SDP answer conforms to
Section 3.4.2, the agent MUST reman in the ICE completed state. Section 3.4.2, the agent MUST reman 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 prior
to the restart. The agent will continue to send media using this to the restart. The agent will continue to send media using this
pair, as described in section 12 of [ICE-BIS]. Once these 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 [ICE-BIS] 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 there
as described in section 12 of [ICE-BIS]. The state of ICE processing as described in section 12 of [RFC8445]. The state of ICE processing
for each data stream MUST change to Running, and the state of ICE for each data stream MUST change to Running, and the state of ICE
processing MUST change to Running 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
skipping to change at page 17, line 5 skipping to change at page 17, line 5
<transport>: indicates the transport protocol for the candidate. <transport>: indicates the transport protocol for the candidate.
This specification only defines UDP. However, extensibility is This specification only defines UDP. However, extensibility is
provided to allow for future transport protocols to be used with provided to allow for future transport protocols to be used with
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 [ICE-BIS] 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 dta stream for which
this is a candidate. It MUST start at 1 and MUST increment by 1 this is a candidate. It MUST start at 1 and MUST increment by 1
for each component of a particular candidate. For data streams for each component of a particular candidate. For data streams
based on RTP, candidates for the actual RTP media MUST have a based on RTP, candidates for the actual RTP media MUST have a
component ID of 1, and candidates for RTCP MUST have a component component ID of 1, and candidates for RTCP MUST have a component
ID of 2. See section 13 in [ICE-BIS] for additional discussion on ID of 2. See section 13 in [RFC8445] for additional discussion on
extending ICE to new data streams. 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 [ICE-BIS]. 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
the ones defined by this specification. the ones defined by this specification.
<rel-addr> and <rel-port>: convey transport addresses related to the <rel-addr> and <rel-port>: convey transport addresses related to the
candidate, useful for diagnostics and other purposes. <rel-addr> candidate, useful for diagnostics and other purposes. <rel-addr>
and <rel-port> MUST be present for server reflexive, peer and <rel-port> MUST be present for server reflexive, peer
reflexive, and relayed candidates. If a candidate is server or reflexive, and relayed candidates. If a candidate is server or
peer reflexive, <rel-addr> and <rel-port> are equal to the base peer reflexive, <rel-addr> and <rel-port> are equal to the base
for that server or peer reflexive candidate. If the candidate is for that server or peer reflexive candidate. If the candidate is
relayed, <rel-addr> and <rel-port> are equal to the mapped address relayed, <rel-addr> and <rel-port> are equal to the mapped address
in the Allocate response that provided the client with that in the Allocate response that provided the client with that
relayed candidate (see Appendix B.3 of [ICE-BIS] for a discussion relayed candidate (see Appendix B.3 of [RFC8445] for a discussion
of its purpose). If the candidate is a host candidate, <rel-addr> of its purpose). If the candidate is a host candidate, <rel-addr>
and <rel-port> MUST be omitted. and <rel-port> MUST be omitted.
In some cases, e.g., for privacy reasons, an agent may not want to In some cases, e.g., for privacy reasons, an agent may not want to
reveal the related address and port. In this case the address reveal the related address and port. In this case the address
MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6 MUST be set to "0.0.0.0" (for IPv4 candidates) or "::" (for IPv6
candidates) and the port to zero. candidates) and the port to zero.
The candidate attribute can itself be extended. The grammar allows The candidate attribute can itself be extended. The grammar allows
for new name/value pairs to be added at the end of the attribute. for new name/value pairs to be added at the end of the attribute.
skipping to change at page 19, line 47 skipping to change at page 19, line 47
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, in milliseconds, for this agent
(see section 14 of [ICE-BIS]). The syntax is: (see section 14 of [RFC8445]). The syntax is:
ice-pacing-att = "ice-pacing:" pacing-value ice-pacing-att = "ice-pacing:" pacing-value
pacing-value = 1*10DIGIT pacing-value = 1*10DIGIT
Following the procedures defined in [ICE-BIS], a default value of Following the procedures defined in [RFC8445], a default value of
50ms is used for an agent when ice-pacing attribute is omitted in the 50ms is used for an agent when ice-pacing attribute is omitted in the
offer or the answer. offer or the answer.
The same rule applies for ice-pacing attribute values lower than The same rule applies for ice-pacing attribute values lower than
50ms. This mandates that, if an agent includes the ice-pacing 50ms. This mandates that, if an agent includes the ice-pacing
attribute, its value MUST be greater than 50ms or else a value of attribute, its value MUST be greater than 50ms or else a value of
50ms is considered by default for that agent. 50ms is considered by default for that agent.
Also the larger of the ice-pacing attribute values between the offer Also the larger of the ice-pacing attribute values between the offer
and the answer (determined either by the one provided in the ice- and the answer (determined either by the one provided in the ice-
skipping to change at page 20, line 48 skipping to change at page 20, line 48
be defined by the specification defining the extension (see be 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 [ICE-BIS] 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
peer supports ICE by the presence of a=candidate attributes for each peer supports ICE by the presence of a=candidate attributes for each
media session. media session.
6. SIP Considerations 6. SIP Considerations
Note that ICE is not intended for NAT traversal for SIP, which is Note that ICE is not intended for NAT traversal for SIP, which is
assumed to be provided via another mechanism [RFC5626]. assumed to be provided via another mechanism [RFC5626].
skipping to change at page 32, line 14 skipping to change at page 32, line 14
10. Acknowledgments 10. Acknowledgments
A large part of the text in this document was taken from [RFC5245], A large part of the text in this document was taken from [RFC5245],
authored by Jonathan Rosenberg. authored by Jonathan Rosenberg.
Some of the text in this document was taken from [RFC6336], authored Some of the text in this document was taken from [RFC6336], authored
by Magnus Westerlund and Colin Perkins. by Magnus Westerlund and Colin Perkins.
Many thanks to Christer Holmberg for providing text suggestions in Many thanks to Christer Holmberg for providing text suggestions in
Section 3 that aligns with [ICE-BIS] Section 3 that aligns with [RFC8445]
Thanks to Thomas Stach for text help, Roman Shpount for suggesting Thanks to Thomas Stach for text help, Roman Shpount for suggesting
RTCP candidate handling and Simon Perreault for advising on IPV6 RTCP candidate handling and Simon Perreault for advising on IPV6
address selection when candidate-address includes FQDN. address selection when candidate-address includes FQDN.
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
[ICE-BIS] Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols",
draft-ietf-ice-rfc5245bis-00 (work in progress), March
2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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>.
skipping to change at page 34, line 10 skipping to change at page 34, line 5
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5768] Rosenberg, J., "Indicating Support for Interactive [RFC5768] Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Initiation Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April Protocol (SIP)", RFC 5768, DOI 10.17487/RFC5768, April
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>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<http://www.rfc-editor.org/info/rfc8445>.
11.2. Informative References 11.2. Informative References
[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,
<http://www.rfc-editor.org/info/rfc3960>. <http://www.rfc-editor.org/info/rfc3960>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
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,
skipping to change at page 35, line 31 skipping to change at page 35, line 31
[8] mailto:iesg@ietf.org [8] mailto:iesg@ietf.org
[9] mailto:christer.holmberg@ericsson.com [9] mailto:christer.holmberg@ericsson.com
[10] mailto:rshpount@turbobridge.com [10] mailto:rshpount@turbobridge.com
[11] mailto:thomass.stach@gmail.com [11] mailto:thomass.stach@gmail.com
Appendix A. Examples Appendix A. Examples
For the example shown in section 16 of [ICE-BIS] 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
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio $NAT-PUB-1.PORT RTP/AVP 0 m=audio $NAT-PUB-1.PORT RTP/AVP 0
 End of changes. 32 change blocks. 
40 lines changed or deleted 40 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/