draft-ietf-mmusic-trickle-ice-sip-06.txt   draft-ietf-mmusic-trickle-ice-sip-07.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track T. Stach Intended status: Standards Track T. Stach
Expires: May 4, 2017 Unaffiliated Expires: September 4, 2017 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
October 31, 2016 March 3, 2017
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-06 draft-ietf-mmusic-trickle-ice-sip-07
Abstract Abstract
The Interactive Connectivity Establishment (ICE) protocol describes a The Interactive Connectivity Establishment (ICE) protocol describes a
Network Address Translator (NAT) traversal mechanism for UDP-based Network Address Translator (NAT) traversal mechanism for UDP-based
multimedia sessions established with the Offer/Answer model. The ICE multimedia sessions established with the Offer/Answer model. The ICE
extension for Incremental Provisioning of Candidates (Trickle ICE) extension for Incremental Provisioning of Candidates (Trickle ICE)
defines a mechanism that allows ICE agents to shorten session defines a mechanism that allows ICE agents to shorten session
establishment delays by making the candidate gathering and establishment delays by making the candidate gathering and
connectivity checking phases of ICE non-blocking and by executing connectivity checking phases of ICE non-blocking and by executing
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 4, 2017. This Internet-Draft will expire on September 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 17 skipping to change at page 3, line 17
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 29
10.10. Info Package Security Considerations . . . . . . . . . . 29 10.10. Info Package Security Considerations . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 29 11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 29
11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 30 11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 30
11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 32 11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 32
11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 32 11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
15.1. Normative References . . . . . . . . . . . . . . . . . . 34 15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 36 15.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The Interactive Connectivity Establishment protocol The Interactive Connectivity Establishment protocol
[I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal [I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal
that consists of three main phases: a phase where an agent gathers a that consists of three main phases: a phase where an agent gathers a
set of candidate transport addresses (source IP address, port and set of candidate transport addresses (source IP address, port and
transport protocol), a second phase where these candidates are sent transport protocol), a second phase where these candidates are sent
to a remote agent and this gathering procedure is repeated and, to a remote agent and this gathering procedure is repeated and,
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification makes use of all terminology defined by the This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in protocol for Interactive Connectivity Establishment in
[I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension
[I-D.ietf-ice-trickle]. It is assumed that the reader will be [I-D.ietf-ice-trickle]. It is assumed that the reader will be
familiar with the terminology from both of them. familiar with the terminology from both documents.
3. Protocol Overview 3. Protocol Overview
Using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE Using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE
candidates are exchanged using SDP Offer/Answer as per [RFC3264]. candidates are exchanged solely using SDP Offer/Answer as per
This specification defines an additional mechanism where candidates [RFC3264]. This specification defines an additional mechanism where
can be exchanged using SIP INFO messages and a newly defined Info candidates can be exchanged using SIP INFO messages and a newly
Package [RFC6086]. This allows ICE candidates to also be sent in defined Info Package [RFC6086]. This allows ICE candidates to also
parallel to an ongoing Offer/Answer negotiation and/or after the be sent in parallel to an ongoing Offer/Answer negotiation and/or
completion of the Offer/Answer negotiation. after the completion of the Offer/Answer negotiation.
Typically, in cases where Trickle ICE is fully supported, the Offerer Typically, in cases where Trickle ICE is fully supported, the Offerer
would send an INVITE request containing a subset of candidates. Once would send an INVITE request containing a subset of candidates. Once
an early dialog is established the Offerer can continue sending an early dialog is established the Offerer can continue sending
candidates in INFO requests within that dialog. candidates in INFO requests within that dialog.
Similarly, an Answerer can send ICE candidates using INFO messages Similarly, an Answerer can send ICE candidates using INFO messages
within the dialog established by its 18x provisional response. within the dialog established by its 18x provisional response.
Figure 1 shows such a sample exchange: Figure 1 shows such a sample exchange:
skipping to change at page 6, line 9 skipping to change at page 6, line 9
Contrary to other protocols, like XMPP [RFC6120], where "in advance" Contrary to other protocols, like XMPP [RFC6120], where "in advance"
capability discovery is widely implemented, the mechanisms that allow capability discovery is widely implemented, the mechanisms that allow
this for SIP (i.e., a combination of UA Capabilities [RFC3840] and this for SIP (i.e., a combination of UA Capabilities [RFC3840] and
GRUU [RFC5627]) have only seen low levels of adoption. This presents GRUU [RFC5627]) have only seen low levels of adoption. This presents
an issue for Trickle ICE implementations as SIP UAs do not have an an issue for Trickle ICE implementations as SIP UAs do not have an
obvious means of verifying that their peer will support incremental obvious means of verifying that their peer will support incremental
candidate provisioning. candidate provisioning.
The Half Trickle mode of operation defined in the Trickle ICE The Half Trickle mode of operation defined in the Trickle ICE
specification [I-D.ietf-ice-trickle] provides one way around this, by specification [I-D.ietf-ice-trickle] provides one way around this, by
requiring first Offers to contain a complete set of ICE candidates requiring the first Offer to contain a complete set of local ICE
and only using incremental provisioning for the rest of the sessions. candidates and only using incremental provisioning of remote
candidates for the rest of the session.
While using Half Trickle does provide a working solution it also While using Half Trickle does provide a working solution it also
comes at the price of increased latency. Section 5 therefore makes comes at the price of increased latency. Section 5 therefore makes
several alternative suggestions that enable SIP UAs to engage in Full several alternative suggestions that enable SIP UAs to engage in Full
Trickle right from their first Offer: Section 5.1 discusses the use Trickle right from their first Offer: Section 5.1 discusses the use
of on-line provisioning as a means of allowing use of Trickle ICE for of on-line provisioning as a means of allowing use of Trickle ICE for
all endpoints in controlled environments. Section 5.2 describes all endpoints in controlled environments. Section 5.2 describes
anticipatory discovery for implementations that actually do support anticipatory discovery for implementations that actually do support
GRUU and UA Capabilities and Section 5.4 discusses the implementation GRUU and UA Capabilities and Section 5.4 discusses the implementation
and use of Half Trickle by SIP UAs where none of the above are an and use of Half Trickle by SIP UAs where none of the above are an
skipping to change at page 8, line 7 skipping to change at page 8, line 7
SIP User Agents. Then, such INFO requests do not impact the state of SIP User Agents. Then, such INFO requests do not impact the state of
the Offer/Answer transaction other than providing additional the Offer/Answer transaction other than providing additional
candidates. Consequently, INFO requests are not considered Offers or candidates. Consequently, INFO requests are not considered Offers or
Answers. Nevertheless, candidates that have been exchanged using Answers. Nevertheless, candidates that have been exchanged using
INFO SHALL be included in subsequent Offers or Answers. The version INFO SHALL be included in subsequent Offers or Answers. The version
number in the "o=" line of that subsequent offer would need to be number in the "o=" line of that subsequent offer would need to be
incremented by 1 per the rules in [RFC3264]. incremented by 1 per the rules in [RFC3264].
4. Incremental Signaling of ICE candidates 4. Incremental Signaling of ICE candidates
Trickle ICE agents will construct Offers and Answers as specified in Trickle ICE agents will construct Offers and Answers with ICE
[I-D.ietf-ice-trickle] with the following additional SIP-specific descriptions compliant to [I-D.ietf-ice-trickle] and the following
additions: additional SIP-specific additions:
1. Trickle ICE agents MUST indicate support for Trickle ICE by 1. Trickle ICE agents MUST indicate support for Trickle ICE by
including the option-tag 'trickle-ice' in a SIP Supported: header including the option-tag 'trickle-ice' in a SIP Supported: header
field within all SIP INVITE requests and responses. field within all SIP INVITE requests and responses.
2. Trickle ICE agents MAY exchange additional ICE candidates using 2. Trickle ICE agents MAY exchange additional ICE candidates using
INFO requests within an existing INVITE dialog usage (including INFO requests within an existing INVITE dialog usage (including
an early dialog) as specified in [RFC6086]. The INFO messages an early dialog) as specified in [RFC6086]. The INFO messages
carry an Info-Package: trickle-ice. Trickle ICE agents MUST be carry an Info-Package: trickle-ice. Trickle ICE agents MUST be
prepared to receive INFO requests within that same dialog usage, prepared to receive INFO requests within that same dialog usage,
skipping to change at page 8, line 37 skipping to change at page 8, line 37
The following section provide further details on how Trickle ICE The following section provide further details on how Trickle ICE
agents establish the INVITE dialog usage such that they can trickle agents establish the INVITE dialog usage such that they can trickle
candidates. candidates.
4.1. Establishing the dialog 4.1. Establishing the dialog
In order for SIP UAs to be able to start trickling, the following two In order for SIP UAs to be able to start trickling, the following two
conditions need to be satisfied: conditions need to be satisfied:
o Trickle ICE support in the peer agent MUST be confirmed. o Trickle ICE support at the peer agent MUST be confirmed.
o The dialog at both sides MUST be in early or confirmed state. o The dialog at both peers MUST be in early or confirmed state.
Section 5 discusses in detail the various options for satisfying the Section 5 discusses in detail the various options for satisfying the
first of the above conditions. Regardless of those mechanisms first of the above conditions. Regardless of those mechanisms
however, agents are certain to have a clear understanding of whether however, agents are certain to have a clear understanding of whether
their peers support trickle ICE once an Offer and an Answer have been their peers support trickle ICE once an Offer and an Answer have been
exchanged, which also allows for ICE processing to commence (see exchanged, which also allows for ICE processing to commence (see
Figure 3). Figure 3).
4.1.1. Asserting dialog state through reliable Offer/Answer delivery 4.1.1. Asserting dialog state through reliable Offer/Answer delivery
Alice Bob Alice Bob
skipping to change at page 9, line 41 skipping to change at page 9, line 41
confirmed support for Trickle ICE within the Answerer (or lack confirmed support for Trickle ICE within the Answerer (or lack
thereof) and to have fully initialized the SIP dialog at both ends. thereof) and to have fully initialized the SIP dialog at both ends.
Offerers and Answerers in the above situation can therefore freely Offerers and Answerers in the above situation can therefore freely
commence trickling within the newly established dialog. commence trickling within the newly established dialog.
4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery
The situation is a bit more delicate for agents that have received an The situation is a bit more delicate for agents that have received an
Offer in an INVITE request and have sent an Answer in an unreliable Offer in an INVITE request and have sent an Answer in an unreliable
provisional response because, once the response has been sent, the provisional response because, once the response has been sent, the
Answerer does no know when or if it has been received (Figure 4). Answerer does not know when or if it has been received (Figure 4).
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| | | |
| +----------------------+ | +----------------------+
| |Bob: I don't know if | | |Bob: I don't know if |
skipping to change at page 10, line 27 skipping to change at page 10, line 27
| | Can I send INFO??? | | | Can I send INFO??? |
| +----------------------+ | +----------------------+
| | | |
Figure 4: A SIP UA that sent an Answer in an unreliable provisional Figure 4: A SIP UA that sent an Answer in an unreliable provisional
response does not know if it was received and if the dialog at the response does not know if it was received and if the dialog at the
side of the Offerer has entered the early state side of the Offerer has entered the early state
In order to clear this ambiguity as soon as possible, the answerer In order to clear this ambiguity as soon as possible, the answerer
needs to retransmit the provisional response with the exponential needs to retransmit the provisional response with the exponential
back-off timers described in [RFC3262]. Retransmits MUST cease on back-off timers described in [RFC3262]. These retransmissions MUST
receipt of a INFO request or on transmission of the answer in a 2xx cease on receipt of a INFO request or on transmission of the answer
response. This is similar to the procedure described in section in a 2xx response. This is similar to the procedure described in
13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding section 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN
Request is replaced by the INFO request. binding Request is replaced by the INFO request.
The Offerer MUST send a Trickle ICE INFO request as soon as it The Offerer MUST send a Trickle ICE INFO request as soon as it
receives an SDP Answer in an unreliable provisional response. This receives an SDP Answer in an unreliable provisional response. This
INFO message MUST repeat the candidates that were already provided in INFO message MUST repeat the candidates that were already provided in
the Offer (as would be the case when Half Trickle is performed or the Offer (as would be the case when Half Trickle is performed or
when new candidates have not been learned since then) and/or they MAY when new candidates have not been learned since then) and/or they MAY
also deliver new candidates (if available). An end-of-candidates also deliver new candidates (if available). An end-of-candidates
indication MAY be included in case candidate discovery has ended in indication MAY be included in case candidate discovery has ended in
the mean time. the mean time.
As soon as an Answerer has received such an INFO request, the As soon as an Answerer has received such an INFO request, the
Answerer has an indication that a dialog is well established at both Answerer has an indication that a dialog is established at both ends
ends and MAY begin trickling (Figure 5). Note: The +SRFLX in and MAY begin trickling (Figure 5).
Figure 5 indicates that additionally newly learned server-reflexive
candidates are includes. Note: The +SRFLX in Figure 5 indicates that additionally newly
learned server-reflexive candidates are included.
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|------------------------>| |------------------------>|
| | | |
skipping to change at page 11, line 32 skipping to change at page 11, line 32
|<------------------------| |<------------------------|
Figure 5: A SIP UA that received an INFO request after sending an Figure 5: A SIP UA that received an INFO request after sending an
unreliable provisional response knows that the dialog at the side of unreliable provisional response knows that the dialog at the side of
the receiver has entered the early state the receiver has entered the early state
When sending the Answer in the 200 OK response, the Answerer MUST When sending the Answer in the 200 OK response, the Answerer MUST
repeat exactly the same Answer that was previously sent in the repeat exactly the same Answer that was previously sent in the
unreliable provisional response in order to fulfill the corresponding unreliable provisional response in order to fulfill the corresponding
requirements in [RFC3264]. In other words, that Offerer needs to be requirements in [RFC3264]. In other words, that Offerer needs to be
prepared to receive fewer candidates in that repeated Answer than prepared to receive a different number of candidates in that repeated
previously exchanged via trickling. Answer than previously exchanged via trickling.
4.1.3. Initiating Trickle ICE without an SDP Answer 4.1.3. Initiating Trickle ICE without an SDP Answer
The possibility to convey arbitrary candidates in INFO message bodies The possibility to convey arbitrary candidates in INFO message bodies
allows ICE agents to initiate trickling without actually sending an allows ICE agents to initiate trickling without actually sending an
Answer. Trickle ICE Agents MAY therefore respond to INVITEs with Answer. Trickle ICE Agents MAY therefore respond to an INVITE
provisional responses without an SDP Answer. Such provisional request with provisional responses without an SDP Answer. Such
responses serve for establishing an early dialog. provisional responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way, MUST Agents that choose to establish the dialog in this way, MUST
retransmit these responses with the exponential back-off timers retransmit these responses with the exponential back-off timers
described in [RFC3262]. Retransmits MUST cease on receipt of an INFO described in [RFC3262]. These retransmissions MUST cease on receipt
request or on transmission of the answer in a 2xx response. This is of an INFO request or on transmission of the answer in a 2xx
again similar to the procedure described in section 12.1.1 of response. This is again similar to the procedure described in
[I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet section 12.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer
provided. is not yet provided.
Note: The +SRFLX in Figure 6 indicates that additionally newly
learned server-reflexive candidates are included.
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|------------------------>| |------------------------>|
| | | |
skipping to change at page 16, line 6 skipping to change at page 16, line 6
Note that while this specification uses the "a=mid:" attribute Note that while this specification uses the "a=mid:" attribute
from [RFC5888], it does not define any grouping semantics. from [RFC5888], it does not define any grouping semantics.
Consequently, using the "a=group:" attribute from that same Consequently, using the "a=group:" attribute from that same
specification is neither needed nor used in Trickle ICE for SIP. specification is neither needed nor used in Trickle ICE for SIP.
All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:"
attributes that would allow mapping them to a specific ICE attributes that would allow mapping them to a specific ICE
generation. An agent MUST discard any received INFO requests generation. An agent MUST discard any received INFO requests
containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not
match those of the current ICE processing session. match those of the current ICE Negotiation Session.
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
same level as the ones in the Offer/Answer exchange. In other words, same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes there, they will if they were present as session-level attributes, they will also
also appear at the beginning of all INFO message payloads, preceding appear at the beginning of all INFO message payloads, i.e. preceding
all "a=mid:" attributes. If they were originally exchanged as media all "a=mid:" attributes. If they were originally exchanged as media
level attributes, potentially overriding session-level values, then level attributes, potentially overriding session-level values, then
they will also be included in INFO message payloads, following the they will also be included in INFO message payloads, following the
corresponding "a=mid:" attribute. corresponding "a=mid:" attribute.
In every INFO request agents MUST include all currently known and Since the agent is not fully aware of the state of the ICE
used local candidates. This allows easier handling of problems that Negotiation Session at its peer it MUST include all currently known
could arise from unreliable transports, like e.g. loss of messages and used local candidates in every INFO request. I.e. all candidates
and reordering. Mis-ordering can be detected through the CSeq: that were previously sent under the same combination of "a=ice-pwd:"
and "a=ice-ufrag:" need to be repeated. Although repeating all
candidates creates some overhead, it also allows easier handling of
problems that could arise from unreliable transports, like e.g. loss
of messages and reordering, which can be detected through the CSeq:
header field in the INFO request. header field in the INFO request.
When receiving INFO requests carrying any candidates, agents will When receiving INFO requests carrying any candidates, agents will
therefore first identify and discard the SDP lines containing therefore first identify and discard the attribute lines containing
candidates they have already received in previous INFO requests or in candidates they have already received in previous INFO requests or in
the Offer/Answer exchange preceding them. Two candidates are the Offer/Answer exchange preceding them. Two candidates are
considered to be equal if their IP address port, transport and considered to be equal if their IP address port, transport and
component ID are the same. After identifying and discarding known component ID are the same. After identifying and discarding known
candidates, the ICE agents will then receive and process the candidates, the ICE agents will then process the remaining, actually
remaining, actually new candidates according to the rules described new candidates according to the rules described in
in [I-D.ietf-ice-trickle]. [I-D.ietf-ice-trickle].
Note: At the time of writing this specification there were ongoing
discussions if a functionality for removing already exchanged
candidates would be useful. Such a functionality is out of the scope
of this specification and most likely needs to be signaled by means
of a yet to be defined ICE extension, although it could in principle
be achieved quite easily, e.g. without anticipating any solution by
simply omitting a previously sent candidate from a subsequent INFO
message. However, if an implementation according to this
specification receives such an INFO message with a missing candidate
it MAY treat that as an exceptional case. Implementing appropriate
recovery procedures at the receiving side is RECOMMENDED for this
situation. Ignoring that a candidate was missing might be a sensible
strategy.
The following example shows the content of one sample candidate The following example shows the content of one sample candidate
delivering INFO request: delivering INFO request:
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/sdp Content-type: application/sdp
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: ... Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:1 a=mid:1
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx a=candidate:2 1 UDP 1658497328 203.0.113.3 5000 typ srflx
raddr 10.0.1.1 rport 8998 raddr 10.0.1.1 rport 8998
a=end-of-candidates a=end-of-candidates
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:2 a=mid:2
a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx a=candidate:2 1 UDP 1658497328 203.0.113.3 5002 typ srflx
raddr 10.0.1.1 rport 9000 raddr 10.0.1.1 rport 9000
a=end-of-candidates a=end-of-candidates
5. Initial discovery of Trickle ICE support 5. Initial discovery of Trickle ICE support
SIP User Agents (UAs) that support and intend to use trickle ICE are SIP User Agents (UAs) that support and intend to use trickle ICE are
REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers
and Answers using the following attribute: "a=ice-options:trickle". and Answers using the following attribute: "a=ice-options:trickle".
This makes discovery fairly straightforward for Answerers or for This makes discovery fairly straightforward for Answerers or for
cases where Offers need to be generated within existing dialogs cases where Offers need to be generated within existing dialogs
skipping to change at page 34, line 13 skipping to change at page 34, line 13
Changes from draft-ietf-mmusic-trickle-ice-sip-03 Changes from draft-ietf-mmusic-trickle-ice-sip-03
o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis
and draft-ietf-mmusic-ice-sip-sdp and draft-ietf-mmusic-ice-sip-sdp
o Corrected Figure 10, credits to Ayush Jain for finding the bug o Corrected Figure 10, credits to Ayush Jain for finding the bug
o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic- o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-
ice-sip-sdp ice-sip-sdp
o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic- o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-
mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive
o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for
the application/trickle-ice-sdpfrag body the application/trickle-ice-sdpfrag body
Changes from draft-ietf-mmusic-trickle-ice-sip-04 Changes from draft-ietf-mmusic-trickle-ice-sip-04
o considered comments from Christer Holmberg o considered comments from Christer Holmberg
o corrected grammar for INFO package, such that ice-ufrag/pwd are o corrected grammar for INFO package, such that ice-ufrag/pwd are
also allowed on media-level as specified in also allowed on media-level as specified in
skipping to change at page 34, line 41 skipping to change at page 34, line 41
o considered further comments from Christer Holmberg o considered further comments from Christer Holmberg
o editorial comments on section 3 addressed o editorial comments on section 3 addressed
o moved section 3.1 to section 10.1 and applied some edits o moved section 3.1 to section 10.1 and applied some edits
o replaced the term "previously sent candidates" with "currently o replaced the term "previously sent candidates" with "currently
known and used candidates". known and used candidates".
Changes from draft-ietf-mmusic-trickle-ice-sip-06
o editorial fixes
o additional text on the content of the INFO messages.
o recommendation on what to do if a previously sent candidate is
unexpectedly missing in a subsequent INFO
o terminology alignment with draft-ietf-ice-trickle-07
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-04 (work in progress), Protocol", draft-ietf-ice-trickle-07 (work in progress),
September 2016. February 2017.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using
Interactive Connectivity Establishment (ICE) with Session Interactive Connectivity Establishment (ICE) with Session
Description Protocol (SDP) offer/answer and Session Description Protocol (SDP) offer/answer and Session
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip- Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip-
sdp-10 (work in progress), July 2016. sdp-11 (work in progress), January 2017.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-10 (work in progress), August 2016. exclusive-11 (work in progress), February 2017.
[I-D.ietf-mmusic-rfc5245bis] [I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-mmusic- Translator (NAT) Traversal", draft-ietf-mmusic-
rfc5245bis-05 (work in progress), September 2015. rfc5245bis-05 (work in progress), September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-36 (work in progress), October 2016. negotiation-36 (work in progress), October 2016.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), September 2016. (work in progress), December 2016.
[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,
 End of changes. 31 change blocks. 
62 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/