draft-ietf-mmusic-ice-sip-sdp-27.txt   draft-ietf-mmusic-ice-sip-sdp-28.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 19, 2019 A. Keranen Expires: November 26, 2019 A. Keranen
Ericsson Ericsson
May 18, 2019 May 25, 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-27 draft-ietf-mmusic-ice-sip-sdp-28
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 19, 2019. This Internet-Draft will expire on November 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 3. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4 3.2. Generic Procedures . . . . . . . . . . . . . . . . . . . 4
3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6 3.2.2. RTP/RTCP Considerations . . . . . . . . . . . . . . . 6
3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6 3.2.3. Determining Role . . . . . . . . . . . . . . . . . . 6
3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6 3.2.4. STUN Considerations . . . . . . . . . . . . . . . . . 6
3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6 3.2.5. Verifying ICE Support Procedures . . . . . . . . . . 6
3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7 3.2.6. SDP Example . . . . . . . . . . . . . . . . . . . . . 7
3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 7 3.3. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8
3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 7 3.3.1. Sending the Initial Offer . . . . . . . . . . . . . . 8
3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8 3.3.2. Sending the Initial Answer . . . . . . . . . . . . . 8
3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 9 3.3.3. Receiving the Initial Answer . . . . . . . . . . . . 9
3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 9 3.3.4. Concluding ICE . . . . . . . . . . . . . . . . . . . 10
3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 3.4. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10
3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 10 3.4.1. Sending Subsequent Offer . . . . . . . . . . . . . . 10
3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 12 3.4.2. Sending Subsequent Answer . . . . . . . . . . . . . . 13
3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 14 3.4.3. Receiving Answer for a Subsequent Offer . . . . . . . 15
4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 16 4.1. "candidate" Attribute . . . . . . . . . . . . . . . . . . 16
4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 19 4.2. "remote-candidates" Attribute . . . . . . . . . . . . . . 19
4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 19 4.3. "ice-lite" and "ice-mismatch" Attributes . . . . . . . . 19
4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 20 4.4. "ice-ufrag" and "ice-pwd" Attributes . . . . . . . . . . 20
4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 21 4.5. "ice-pacing" Attribute . . . . . . . . . . . . . . . . . 20
4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21 4.6. "ice-options" Attribute . . . . . . . . . . . . . . . . . 21
5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22 6.1. Latency Guidelines . . . . . . . . . . . . . . . . . . . 22
6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 23 6.1.1. Offer in INVITE . . . . . . . . . . . . . . . . . . . 23
6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 24 6.1.2. Offer in Response . . . . . . . . . . . . . . . . . . 24
6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 24 6.2. SIP Option Tags and Media Feature Tags . . . . . . . . . 24
6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24 6.3. Interactions with Forking . . . . . . . . . . . . . . . . 24
6.4. Interactions with Preconditions . . . . . . . . . . . . . 25 6.4. Interactions with Preconditions . . . . . . . . . . . . . 25
6.5. Interactions with Third Party Call Control . . . . . . . 25 6.5. Interactions with Third Party Call Control . . . . . . . 25
skipping to change at page 6, line 43 skipping to change at page 6, line 43
3.2.5. Verifying ICE Support Procedures 3.2.5. Verifying ICE Support Procedures
The agents will proceed with the ICE procedures defined in [RFC8445] The agents will proceed with the ICE procedures defined in [RFC8445]
and this specification if, for each data stream in the SDP it and this specification if, for each data stream in the SDP it
received, the default destination for each component of that data received, the default destination for each component of that data
stream appears in a candidate attribute. For example, in the case of stream appears in a candidate attribute. For example, in the case of
RTP, the connection address, port and transport protocol are in the RTP, the connection address, port and transport protocol are in the
"c=" and "m=" lines, respectively, appear in a candidate attribute "c=" and "m=" lines, respectively, appear in a candidate attribute
and the value in the rtcp attribute appears in a candidate attribute. and the value in the rtcp attribute appears in a candidate attribute.
If this condition is not met, the agents MUST process the SDP based This specification provides no guidance on how an agent should
on normal [RFC3264] procedures, without using any of the ICE proceed in the cases where the above condition is not met with the
mechanisms described in the remainder of this specification with the
few exceptions noted below: few exceptions noted below:
1. The presence of certain application layer gateways MAY modify the 1. The presence of certain application layer gateways MAY modify the
transport address information as described in Section 8.2.2. The transport address information as described in Section 8.2.2. The
behavior of the responding agent in such a situation is behavior of the responding agent in such a situation is
implementation defined. Informally, the responding agent MAY implementation 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 data
streams. 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.
In some cases, controlling/initiator agent may receive the SDP answer 3. In some cases, controlling/initiator agent may receive the SDP
that may omit "a=candidate" attributes for the media streams, and answer that may omit "a=candidate" attributes for the data
instead include a session level "a=ice-mismatch" attribute. This stream, and instead include a media level "a=ice-mismatch"
signals to the offerer that the answerer supports ICE, but that ICE attribute. This signals to the offerer that the answerer
processing was not used for this session. This specification supports ICE, but that ICE processing was not used for this data
provides no guidance on how an agent should proceed in such a failure stream. In this case, ICE processing MUST be terminated for this
case. data stream and [RFC3264] procedures MUST be followed instead.
4. The transport address from the peer for the default destination
is an FQDN. Regardless of the procedures used to resolve FQDN or
the resolution result, this MUST not be considered as a ICE
failure by the peer agent and the ICE processing MUST continue as
usual.
3.2.6. SDP Example 3.2.6. SDP Example
The following is an example SDP message that includes ICE attributes The following is an example SDP message that includes ICE attributes
(lines folded for readability): (lines folded for readability):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
skipping to change at page 8, line 49 skipping to change at page 9, line 9
attributes and with default destination corresponding to the IP attributes and with default destination corresponding to the IP
address values "0.0.0.0"/"::" and port value of "9". This implies address values "0.0.0.0"/"::" and port value of "9". This implies
that answering agent is only going to use peer reflexive candidates that answering agent is only going to use peer reflexive candidates
or that additional candidates would be provided in subsequent or that additional candidates would be provided in subsequent
signaling messages. 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.
In certain scenarios when either no candidates were provided in the
offer or all the provided candidates were discarded (say, due to
unsupported address type or FQDN name resolution failure), the
answerer MUST NOT consider this as immediate ICE processing failure
but instead MUST wait for the peer reflexive candidates to arrive to
carryout the connectivity checks or eventually time out on the
connectivity checks (see [draft-holmberg-ice-pac]).
If the offer does not indicate support of ICE, the answerer MUST NOT If the offer does not indicate support of ICE, the answerer MUST NOT
accept the usage of ICE. If the answerer still accepts the offer, accept the usage of ICE. If the answerer still accepts the offer,
the answerer MUST NOT include any ICE related SDP attributes in the the answerer MUST NOT include any ICE related SDP attributes in the
answer. Instead the answerer will generate the answer according to answer. Instead the answerer will generate the answer according to
normal offer/answer procedures [RFC3264]. normal offer/answer procedures [RFC3264].
If the answerer detects a possibility of the ICE mismatch, procedures If the answerer detects a possibility of the ICE mismatch, procedures
described in (Section 3.2.5) are followed. described in (Section 3.2.5) are followed.
Note: <draft-holmberg-ice-pac>> provides guidance on finding working
candidate pairs and thus preventing premature declaration of ICE
failure is certain scenarios such as, if the peer has not provided
any candidates, or if all provided candidates have failed or have
been discarded.
3.3.3. Receiving the Initial Answer 3.3.3. Receiving the Initial Answer
When an offerer receives an initial answer that indicates that the When an offerer receives an initial answer that indicates that the
answerer supports ICE, it can start performing connectivity checks answerer supports ICE, it can start performing connectivity checks
towards the peer candidates that were provided in the answer. towards the peer candidates that were provided in the answer.
In certain scenarios when either no candidates were provided in the
answer or all the provided candidates were discarded (say, due to
unsupported address type or FQDN name resolution failure), the
offerer MUST NOT consider this as immediate ICE processing failure
but instead MUST wait for the peer reflexive candidates to arrive to
carryout the connectivity checks or eventually time out on the
connectivity checks (see [draft-holmberg-ice-pac]).
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 answerer included "a=ice-mismatch" attributes for all the active
terminate the usage of ICE. The subsequent actions taken by the data streams in the answer, the offerer MUST terminate the usage of
offerer are implementation dependent and are out of the scope of this ICE for the entire session and [RFC3264] procedures MUST be followed
specification. instead.
On the other hand, if the answer indicates the support for ICE but
includes "a=ice-mismatch" in certain active data streams, then the
offerer MUST terminate the usage of ICE procedures and [RFC3264]
procedures MUST be used instead for only these data streams. Also,
ICE procedures MUST be used for data streams where "a=ice-mismatch"
attribute was not included.
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
terminate the usage of ICE for the entire session. The subsequent
actions taken by the offerer are implementation dependent and are out
of the scope of this specification.
Note: <draft-holmberg-ice-pac>> provides guidance on finding working
candidate pairs and thus preventing premature declaration of ICE
failure is certain scenarios such as, if the peer has not provided
any candidates, or if all provided candidates have failed or have
been discarded.
3.3.4. Concluding ICE 3.3.4. Concluding ICE
Once the state of each check list is Completed, and if the agent is Once the state of each check list is Completed, and if the agent is
the controlling agent, it nominates a candidate pair [RFC8445] and the controlling agent, it nominates a candidate pair [RFC8445] and
checks for each data stream whether the nominated pair matches the checks for each data stream whether the nominated pair matches the
default candidate pair. If there are one or more data streams with a default candidate pair. If there are one or more data streams 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 connection address, port and transport (Section 3.4.1), in which the connection address, port and transport
skipping to change at page 12, line 20 skipping to change at page 12, line 36
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 media 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
skipping to change at page 17, line 35 skipping to change at page 17, line 35
extension-att-name = token extension-att-name = token
extension-att-value = *VCHAR extension-att-value = *VCHAR
ice-char = ALPHA / DIGIT / "+" / "/" ice-char = ALPHA / DIGIT / "+" / "/"
This grammar encodes the primary information about a candidate: its This grammar encodes the primary information about a candidate: its
IP address, port and transport protocol, and its properties: the IP address, port and transport protocol, and its properties: the
foundation, component ID, priority, type, and related transport foundation, component ID, priority, type, and related transport
address: address:
<connection-address>: is taken from RFC 4566 [RFC4566]. It is the <connection-address>: is taken from RFC 4566 [RFC4566]. It is the
IP address of the candidate. When parsing this field, an agent IP address of the candidate, allowing for IPv4 addresses, IPv6
can differentiate an IPv4 address and an IPv6 address by presence addresses, and fully qualified domain names (FQDNs). When parsing
of a colon in its value -- the presence of a colon indicates IPv6. this field, an agent can differentiate an IPv4 address and an IPv6
An agent MUST ignore candidate lines that include candidates with address by presence of a colon in its value - the presence of a
IP address versions that are not supported or recognized. An IP colon indicates IPv6. An agent generating local candidates MUST
address SHOULD be used, but an FQDN MAY be used in place of an IP not use FQDN addresses. An agent processing remote candidates
address. In that case, when receiving an offer or answer MUST ignore candidate lines that include candidates with FQDN or
containing an FQDN in an a=candidate attribute, the FQDN is looked IP address versions that are not supported or recognized. The
up in the DNS first using an AAAA record (assuming the agent procedures for generation and handling of FQDN candidates, as well
supports IPv6), and if no result is found or the agent only as, how agents indicate support for such procedures, need to be
supports IPv4, using an A record. If a FQDN returns multiple IP specified in an extension specification.
addresses an agent MUST only use one of them throughout the
duration of the ICE session. Since an agent does not know whether
the peer listens to the chosen IP address and port, it is
RECOMMENDED to not use FQDNs that will resolve into multiple IP
addresses.
<port>: is also taken from RFC 4566 [RFC4566]. It is the port of <port>: is also taken from RFC 4566 [RFC4566]. It is the port of
the candidate. the candidate.
<transport>: indicates the transport protocol for the candidate. <transport>: indicates the transport protocol for the candidate.
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.
skipping to change at page 20, line 4 skipping to change at page 19, line 45
a=remote-candidates:1 192.0.2.3 45664 a=remote-candidates:1 192.0.2.3 45664
a=remote-candidates:2 192.0.2.3 45665 a=remote-candidates:2 192.0.2.3 45665
4.3. "ice-lite" and "ice-mismatch" Attributes 4.3. "ice-lite" and "ice-mismatch" Attributes
The syntax of the "ice-lite" and "ice-mismatch" attributes, both of The syntax of the "ice-lite" and "ice-mismatch" attributes, both of
which are flags, is: which are flags, is:
ice-lite = "ice-lite" ice-lite = "ice-lite"
ice-mismatch = "ice-mismatch" ice-mismatch = "ice-mismatch"
"ice-lite" is a session-level attribute only, and indicates that an "ice-lite" is a session-level attribute only, and indicates that an
agent is a lite implementation. "ice-mismatch" is a media-level agent is a lite implementation. "ice-mismatch" is a media-level
attribute only, and when present in an answer, indicates that the attribute and only reported in the answer. It indicates that the
offer arrived with a default destination for a media component that offer arrived with a default destination for a media component that
didn't have a corresponding candidate attribute. didn't have a corresponding candidate attribute.
4.4. "ice-ufrag" and "ice-pwd" Attributes 4.4. "ice-ufrag" and "ice-pwd" Attributes
The "ice-ufrag" and "ice-pwd" attributes convey the username fragment The "ice-ufrag" and "ice-pwd" attributes convey the username fragment
and password used by ICE for message integrity. Their syntax is: and password used by ICE for message integrity. Their syntax is:
ice-pwd-att = "ice-pwd:" password ice-pwd-att = "ice-pwd:" password
ice-ufrag-att = "ice-ufrag:" ufrag ice-ufrag-att = "ice-ufrag:" ufrag
 End of changes. 18 change blocks. 
58 lines changed or deleted 68 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/