< draft-ietf-mmusic-ice-sip-sdp-28.txt   draft-ietf-mmusic-ice-sip-sdp-29.txt >
MMUSIC M. Petit-Huguenin MMUSIC M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5245 (if approved) S. Nandakumar Obsoletes: 5245 (if approved) S. Nandakumar
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: November 26, 2019 A. Keranen Expires: November 30, 2019 A. Keranen
Ericsson Ericsson
May 25, 2019 May 29, 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-28 draft-ietf-mmusic-ice-sip-sdp-29
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 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 26, 2019. This Internet-Draft will expire on November 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 7 skipping to change at page 7, line 7
few exceptions noted below: few exceptions noted below:
1. The presence of certain application layer gateways MAY modify the 1. The presence of certain application layer gateways MAY modify the
transport address information as described in Section 8.2.2. The transport address information as described in Section 8.2.2. The
behavior of the responding agent in such a situation is behavior of the responding agent in such a situation is
implementation defined. Informally, the responding agent MAY implementation defined. Informally, the responding agent MAY
consider the mismatched transport address information as a consider the mismatched transport address information as a
plausible new candidate learnt from the peer and continue its ICE plausible new candidate learnt from the peer and continue its ICE
processing with that transport address included. Alternatively, processing with that transport address included. Alternatively,
the responding agent MAY include an "a=ice-mismatch" attribute in the responding agent MAY include an "a=ice-mismatch" attribute in
its answer and MAY also omit a=candidate attributes for such data its answer and MAY also omit "a=candidate" attributes for such
streams. data streams.
2. The transport address from the peer for the default destination 2. The transport address from the peer for the default destination
correspond to IP address values "0.0.0.0"/"::" and port value of correspond to IP address values "0.0.0.0"/"::" and port value of
"9". This MUST not be considered as a ICE failure by the peer "9". This MUST not be considered as a ICE failure by the peer
agent and the ICE processing MUST continue as usual. agent and the ICE processing MUST continue as usual.
3. In some cases, controlling/initiator agent may receive the SDP 3. In some cases, controlling/initiator agent may receive the SDP
answer that may omit "a=candidate" attributes for the data answer that may omit "a=candidate" attributes for the data
stream, and instead include a media level "a=ice-mismatch" stream, and instead include a media level "a=ice-mismatch"
attribute. This signals to the offerer that the answerer attribute. This signals to the offerer that the answerer
skipping to change at page 11, line 4 skipping to change at page 11, line 4
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
[RFC8445]. [RFC8445].
The rules governing the ICE restart imply that setting the connection The rules governing the ICE restart imply that setting the connection
address in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will address in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will
cause an ICE restart. Consequently, ICE implementations MUST NOT cause an ICE restart. Consequently, ICE implementations MUST NOT
utilize this mechanism for call hold, and instead MUST use a=inactive utilize this mechanism for call hold, and instead MUST use
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
skipping to change at page 12, line 16 skipping to change at page 12, line 16
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="
line associated with that data stream MUST match the data associated line associated with that data stream MUST match the data associated
with the nominated pair for that data stream. In addition, the with the nominated pair for that data stream. In addition, the
offerer only includes SDP candidates representing the local offerer only includes SDP candidates representing the local
candidates of the nominated candidate pair. The offerer MUST NOT candidates of the nominated candidate pair. The offerer MUST NOT
include any other SDP candidate attributes in the subsequent offer. include any other SDP candidate attributes in the subsequent offer.
In addition, if the agent is controlling, it MUST include the In addition, if the agent is controlling, it MUST include the
a=remote-candidates attribute for each data stream whose check list "a=remote-candidates" attribute for each data stream whose check list
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 attribute in any subsequent offer. The candidates are "a=candidate" attribute in any subsequent offer. The candidates are
formed identical to the procedures for initial offers. formed identical to the procedures for initial offers.
A lite implementation MUST NOT add additional host candidates in a A lite implementation MUST NOT add additional host candidates in a
subsequent offer. If an agent needs to offer additional candidates, subsequent offer. If an agent needs to offer additional candidates,
it MUST restart ICE. Similarly, the username fragments or passwords it MUST restart ICE. Similarly, the username fragments or passwords
MUST remain the same as used previously. If an agent needs to change MUST remain the same as used previously. If an agent needs to change
one of these, it MUST restart ICE for that data stream. one of these, it MUST restart ICE for that data stream.
If ICE has completed for a data stream and if the agent is If ICE has completed for a data stream and if the agent is
controlled, the default destination for that data stream MUST be set controlled, the default destination for that data stream MUST be set
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.
If ICE state is completed and if the agent is controlling (which only If ICE state is completed and if the agent is controlling (which only
happens when both agents are lite), the agent MUST include the happens when both agents are lite), the agent MUST include the
a=remote-candidates attribute for each data stream. The attribute "a=remote-candidates" attribute for each data stream. The attribute
contains the remote candidates from the candidate pairs in the valid contains the remote candidates from the candidate pairs in the valid
list (one pair for each component of each data stream). list (one pair for each component of each data stream).
3.4.2. Sending Subsequent Answer 3.4.2. Sending Subsequent Answer
If ICE is Completed for a data stream, and the offer for that data If ICE is Completed for a data stream, and the offer for that data
stream lacked the a=remote-candidates attribute, the rules for stream lacked the "a=remote-candidates" attribute, the rules for
construction of the answer are identical to those for the offerer, construction of the answer are identical to those for the offerer,
except that the answerer MUST NOT include the a=remote-candidates except that the answerer MUST NOT include the "a=remote-candidates"
attribute in the answer. attribute in the answer.
A controlled agent will receive an offer with the a=remote-candidates A controlled agent will receive an offer with the "a=remote-
attribute for a data stream when its peer has concluded ICE candidates" attribute for a data stream when its peer has concluded
processing for that data stream. This attribute is present in the ICE processing for that data stream. This attribute is present in
offer to deal with a race condition between the receipt of the offer, the offer to deal with a race condition between the receipt of the
and the receipt of the Binding Response that tells the answerer the offer, and the receipt of the Binding Response that tells the
candidate that will be selected by ICE. See Appendix B for an answerer the candidate that will be selected by ICE. See Appendix B
explanation of this race condition. Consequently, processing of an for an explanation of this race condition. Consequently, processing
offer with this attribute depends on the winner of the race. of an offer with this attribute depends on the winner of the race.
The agent forms a candidate pair for each component of the data The agent forms a candidate pair for each component of the data
stream by: stream by:
o Setting the remote candidate equal to the offerer's default o Setting the remote candidate equal to the offerer's default
destination for that component (i.e. the contents of the "m=" and destination for that component (i.e. the contents of the "m=" and
"c=" lines for RTP, and the a=rtcp attribute for RTCP) "c=" lines for RTP, and the "a=rtcp" attribute for RTCP)
o Setting the local candidate equal to the transport address for o Setting the local candidate equal to the transport address for
that same component in the a=remote-candidates attribute in the that same component in the "a=remote-candidates" attribute in the
offer. offer.
The agent then sees if each of these candidate pairs is present in The agent then sees if each of these candidate pairs is present in
the valid list. If a particular pair is not in the valid list, the the valid list. If a particular pair is not in the valid list, the
check has "lost" the race. Call such a pair a "losing pair". check has "lost" the race. Call such a pair a "losing pair".
The agent finds all the pairs in the check list whose remote The agent finds all the pairs in the check list whose remote
candidates equal the remote candidate in the losing pair: candidates equal the remote candidate in the losing pair:
o If none of the pairs are In-Progress, and at least one is Failed, o If none of the pairs are In-Progress, and at least one is Failed,
skipping to change at page 14, line 27 skipping to change at page 14, line 27
SDP ice-pwd and ice-ufrag attribute values. SDP ice-pwd and ice-ufrag attribute values.
3.4.2.2. Lite Implementation specific procedures 3.4.2.2. Lite Implementation specific procedures
If the received offer contains the remote-candidates attribute for a If the received offer contains the remote-candidates attribute for a
data stream, the agent forms a candidate pair for each component of data stream, the agent forms a candidate pair for each component of
the data stream by: the data stream by:
o Setting the remote candidate equal to the offerer's default o Setting the remote candidate equal to the offerer's default
destination for that component (i.e., the contents of the "m=" and destination for that component (i.e., the contents of the "m=" and
"c=" lines for RTP, and the a=rtcp attribute for RTCP). "c=" lines for RTP, and the "a=rtcp" attribute for RTCP).
o Setting the local candidate equal to the transport address for o Setting the local candidate equal to the transport address for
that same component in the a=remote-candidates attribute in the that same component in the "a=remote-candidates" attribute in the
offer. offer.
The state of ICE processing for that data stream is set to Completed. The state of ICE processing for that data stream is set to Completed.
Furthermore, if the agent believed it was controlling, but the offer Furthermore, if the agent believed it was controlling, but the offer
contained the a=remote-candidates attribute, both agents believe they contained the "a=remote-candidates" attribute, both agents believe
are controlling. In this case, both would have sent updated offers they are controlling. In this case, both would have sent updated
around the same time. offers 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 [RFC8445], it was controlling, based on the rules in section 8.2 of [RFC8445], it was controlling,
skipping to change at page 22, line 12 skipping to change at page 22, line 12
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
peer supports ICE by the presence of a=candidate attributes for each peer supports ICE by the presence of "a=candidate" attributes for
media session. each 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].
When ICE is used with SIP, forking may result in a single offer When ICE is used with SIP, forking may result in a single offer
generating a multiplicity of answers. In that case, ICE proceeds generating a multiplicity of answers. In that case, ICE proceeds
completely in parallel and independently for each answer, treating completely in parallel and independently for each answer, treating
the combination of its offer and each answer as an independent offer/ the combination of its offer and each answer as an independent offer/
skipping to change at page 38, line 21 skipping to change at page 38, line 21
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6 a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0 m=audio 3478 RTP/AVP 0
b=RS:0 b=RS:0
b=RR:0 b=RR:0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ host
Appendix B. The remote-candidates Attribute Appendix B. The remote-candidates Attribute
The a=remote-candidates attribute exists to eliminate a race The "a=remote-candidates" attribute exists to eliminate a race
condition between the updated offer and the response to the STUN condition between the updated offer and the response to the STUN
Binding request that moved a candidate into the Valid list. This Binding request that moved a candidate into the Valid list. This
race condition is shown in Figure 1. On receipt of message 4, agent race condition is shown in Figure 1. On receipt of message 4, agent
L adds a candidate pair to the valid list. If there was only a L adds a candidate pair to the valid list. If there was only a
single data stream with a single component, agent L could now send an single data stream with a single component, agent L could now send an
updated offer. However, the check from agent R has not yet generated updated offer. However, the check from agent R has not yet generated
a response, and agent R receives the updated offer (message 7) before a response, and agent R receives the updated offer (message 7) before
getting the response (message 9). Thus, it does not yet know that getting the response (message 9). Thus, it does not yet know that
this particular pair is valid. To eliminate this condition, the this particular pair is valid. To eliminate this condition, the
actual candidates at R that were selected by the offerer (the remote actual candidates at R that were selected by the offerer (the remote
 End of changes. 19 change blocks. 
31 lines changed or deleted 31 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/