draft-ietf-mmusic-trickle-ice-sip-14.txt   draft-ietf-mmusic-trickle-ice-sip-15.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: August 27, 2018 Unaffiliated Expires: December 4, 2018 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
February 23, 2018 June 2, 2018
A Session Initiation Protocol (SIP) Usage for Trickle ICE A Session Initiation Protocol (SIP) Usage for Incremental Provisioning
draft-ietf-mmusic-trickle-ice-sip-14 of Candidates for the Interactive Connectivity Establishment (Trickle
ICE)
draft-ietf-mmusic-trickle-ice-sip-15
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
them in parallel. them in parallel.
This document defines usage semantics for Trickle ICE with the This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP) and defines a new SIP Info Package Session Initiation Protocol (SIP), defines a new SIP Info Package to
to support this usage. support this usage together with the corresponding media type, SDP
attribute and SIP option tag.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 27, 2018. This Internet-Draft will expire on December 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 40 skipping to change at page 2, line 40
4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 9 4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 9
4.1.3. Sending the Initial Answer . . . . . . . . . . . . . 9 4.1.3. Sending the Initial Answer . . . . . . . . . . . . . 9
4.1.4. Receiving the Initial Answer . . . . . . . . . . . . 10 4.1.4. Receiving the Initial Answer . . . . . . . . . . . . 10
4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10
4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10 4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10
4.3.1. Establishing Dialog State through Reliable 4.3.1. Establishing Dialog State through Reliable
Offer/Answer Delivery . . . . . . . . . . . . . . . . 11 Offer/Answer Delivery . . . . . . . . . . . . . . . . 11
4.3.2. Establishing Dialog State through Unreliable 4.3.2. Establishing Dialog State through Unreliable
Offer/Answer Delivery . . . . . . . . . . . . . . . . 12 Offer/Answer Delivery . . . . . . . . . . . . . . . . 12
4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14 4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14
4.3.4. Considerations for Third Party Call Control . . . . . 15 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 16
4.4. Delivering Candidates in INFO Requests . . . . . . . . . 17 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 20
5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 22 5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 21
5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 22
5.2. Trickle ICE Discovery with Globally Routable User Agent 5.2. Trickle ICE Discovery with Globally Routable User Agent
URIs (GRUU) . . . . . . . . . . . . . . . . . . . . . . . 22 URIs (GRUU) . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 23 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 22
6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 24 6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 24
7. Considerations for Media Multiplexing . . . . . . . . . . . . 26 7. Considerations for Media Multiplexing . . . . . . . . . . . . 26
8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 29 8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 28
8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 30 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 29
9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 30 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 29
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 30 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 29
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 31
10.2. Overall Description . . . . . . . . . . . . . . . . . . 33 10.2. Overall Description . . . . . . . . . . . . . . . . . . 32
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 32
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 33 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 33
10.5. Info Package Parameters . . . . . . . . . . . . . . . . 34 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 33
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 34 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 33
10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34 10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 33
10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 33
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 33
10.10. Info Package Security Considerations . . . . . . . . . . 35 10.10. Info Package Security Considerations . . . . . . . . . . 34
11. Deployment Considerations . . . . . . . . . . . . . . . . . . 35 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 34
12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 35
12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 37
12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 37
13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
16.1. Normative References . . . . . . . . . . . . . . . . . . 43 16.1. Normative References . . . . . . . . . . . . . . . . . . 42
16.2. Informative References . . . . . . . . . . . . . . . . . 45 16.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
The Interactive Connectivity Establishment (ICE) protocol The Interactive Connectivity Establishment (ICE) protocol
[I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address [I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address
Translator (NAT) traversal that consists of three main phases. Translator (NAT) traversal that consists of three main phases.
During the first phase an agent gathers a set of candidate transport During the first phase an agent gathers a set of candidate transport
addresses (source IP address, port and transport protocol). This is addresses (source IP address, port and transport protocol). This is
followed by a second phase where these candidates are sent to a followed by a second phase where these candidates are sent to a
remote agent within the Session Description Protocol (SDP) body of a remote agent within the Session Description Protocol (SDP) body of a
SIP message. At the remote agent the gathering procedure is repeated SIP message. At the remote agent the gathering procedure is repeated
and candidates are sent to the first agent. Finally, a third phase and candidates are sent to the first agent. Once the candidate
starts where connectivity between all candidates in both sets is information is available, a third phase starts in parallel where
checked (connectivity checks). Once these phases have been connectivity between all candidates in both sets is checked
completed, and only then, both agents can begin communication. (connectivity checks). Once these phases have been completed, and
only then, both agents can begin communication.
According to [I-D.ietf-ice-rfc5245bis] the three phases above happen According to [I-D.ietf-ice-rfc5245bis] the three phases above happen
consecutively, in a blocking way, which can introduce undesirable consecutively, in a blocking way, which can introduce undesirable
setup delay during session establishment. The Trickle ICE extension setup delay during session establishment. The Trickle ICE extension
[I-D.ietf-ice-trickle] defines generic semantics required for these [I-D.ietf-ice-trickle] defines generic semantics required for these
ICE phases to happen in a parallel, non-blocking way and hence speed ICE phases to happen in a parallel, non-blocking way and hence speed
up session establishment. up session establishment.
This specification defines a usage of Trickle ICE with the Session This specification defines a usage of Trickle ICE with the Session
Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates
are to be exchanged incrementally using SIP INFO requests [RFC6086] are to be exchanged incrementally using SIP INFO requests [RFC6086]
and how the Half Trickle and Full Trickle modes defined in and how the Half Trickle and Full Trickle modes defined in
[I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs)
depending on their expectations for support of Trickle ICE by a depending on their expectations for support of Trickle ICE by a
remote agent. remote agent.
This document defines a new Info Package as specified in [RFC6086] This document defines a new Info Package as specified in [RFC6086]
for use with Trickle ICE. for use with Trickle ICE together with the corresponding media type,
SDP attribute and SIP option tag.
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 BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119], [RFC8174] when, and only when, they appear in all 14 [RFC2119], [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification makes use of terminology defined by the protocol This specification makes use of terminology defined by the protocol
skipping to change at page 9, line 18 skipping to change at page 9, line 18
[I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address.
If the Offerer wants to use RTCP multiplexing [RFC5761] and/or If the Offerer wants to use RTCP multiplexing [RFC5761] and/or
exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still
will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in
the initial Offer. the initial Offer.
In any case, the Offerer MUST include the attribute "a=ice- In any case, the Offerer MUST include the attribute "a=ice-
options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST
include in each "m="-line a "a=mid:" attribute in accordance to include in each "m="-line a "a=mid:" attribute in accordance to
[RFC5888]. [RFC5888]. The a=mid: attribute identifies the m-line to which a
candidate belongs and helps in case of multiple m-lines, when
candidates gathering could occur in a order different from the order
of the m-lines.
4.1.2. Receiving the Initial Offer 4.1.2. Receiving the Initial Offer
If the initial Offer included candidates, the Answerer uses these If the initial Offer included candidates, the Answerer uses these
candidates to start ICE processing as specified in candidates to start ICE processing as specified in
[I-D.ietf-ice-trickle]. [I-D.ietf-ice-trickle].
If the initial Offer included the attribute a=ice-options:trickle, If the initial Offer included the attribute a=ice-options:trickle,
the Answerer MUST be prepared for receiving trickled candidates later the Answerer MUST be prepared for receiving trickled candidates later
on. on.
In case of a "m/c=" line with default values none of the eventually In case of a "m/c=" line with default values none of the eventually
trickled candidates will match the default destination. This trickled candidates will match the default destination. This
situation MUST NOT cause an ICE mismatch (see situation MUST NOT cause an ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]). [I-D.ietf-mmusic-ice-sip-sdp]).
4.1.3. Sending the Initial Answer 4.1.3. Sending the Initial Answer
If the Answerer includes candidates in its initial Answerer, it MUST If the Answerer includes candidates in its initial Answer, it MUST
encode these candidates as specified in encode these candidates as specified in
[I-D.ietf-mmusic-ice-sip-sdp]. [I-D.ietf-mmusic-ice-sip-sdp].
If the Answerer wants to send its initial Answer before knowing any If the Answerer wants to send its initial Answer before knowing any
candidate for one or more media descriptions, it MUST set the port to candidate for one or more media descriptions, it MUST set the port to
the default value '9' for these media descriptions. If the Answerer the default value '9' for these media descriptions. If the Answerer
does not want to include the host IP address in the corresponding does not want to include the host IP address in the corresponding
c-line, e.g. due to privacy reasons, it SHOULD include a default c-line, e.g. due to privacy reasons, it SHOULD include a default
address in the c-line, which is set to the IPv4 address 0.0.0.0 or to address in the c-line, which is set to the IPv4 address 0.0.0.0 or to
the IPv6 equivalent ::. the IPv6 equivalent ::.
skipping to change at page 10, line 20 skipping to change at page 10, line 25
options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST
include in each "m="-line a "a=mid:" attribute in accordance to include in each "m="-line a "a=mid:" attribute in accordance to
[RFC5888]. [RFC5888].
4.1.4. Receiving the Initial Answer 4.1.4. Receiving the Initial Answer
If the initial Answer included candidates, the Offerer uses these If the initial Answer included candidates, the Offerer uses these
candidates to start ICE processing as specified in candidates to start ICE processing as specified in
[I-D.ietf-ice-trickle]. [I-D.ietf-ice-trickle].
If the initial Answer included the attribute a=ice-options:trickle,
the Offerer MUST be prepared for receiving trickled candidates later
on.
In case of a "m/c=" line with default values none of the eventually In case of a "m/c=" line with default values none of the eventually
trickled candidates will match the default destination. This trickled candidates will match the default destination. This
situation MUST NOT cause an ICE mismatch (see situation MUST NOT cause an ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]). [I-D.ietf-mmusic-ice-sip-sdp]).
4.2. Subsequent Offer/Answer Exchanges 4.2. Subsequent Offer/Answer Exchanges
Subsequent Offer/Answer exchanges are handled as for regular ICE (see Subsequent Offer/Answer exchanges are handled as for regular ICE (see
section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]). section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]).
If an Offer or Answer needs to be sent while the ICE agents are in If an Offer or Answer needs to be sent while the ICE agents are in
the middle of trickling section 4.2.1.2.1 of the middle of trickling section 3.2 of [I-D.ietf-mmusic-ice-sip-sdp])
[I-D.ietf-mmusic-ice-sip-sdp]) applies. This means that an ICE agent applies. This means that an ICE agent includes candidate attributes
includes candidate attributes for all local candidates it had for all local candidates it had trickled previously for a specific
trickled previously for a specific media stream. media stream.
[RFC EDITOR NOTE: The section 4.2.1.2.1 in above sentence is correct [RFC EDITOR NOTE: The section 3.2 in above sentence is correct for
for version 16 of said I-D. Authors need to cross-check during version 20 of said I-D. Authors need to cross-check during Auth48
Auth48 since it could have have changed in the meantime.] since it could have have changed in the meantime.]
4.3. Establishing the Dialog 4.3. Establishing the Dialog
In order to be able to start trickling, the following two conditions In order to be able to start trickling, the following two conditions
need to be satisfied at the SIP UAs: need to be satisfied at the SIP UAs:
o Trickle ICE support at the peer agent MUST be confirmed. o Trickle ICE support at the peer agent MUST be confirmed.
o The dialog at both peers MUST be in early or confirmed state. o A dialog MUST have been created between the peers.
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.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery
skipping to change at page 12, line 37 skipping to change at page 12, line 37
| | | |
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]. These retransmissions MUST back-off timers described in [RFC3262]. These retransmissions MUST
cease on receipt of an INFO request carrying a 'trickle-ice' Info cease on receipt of an INFO request carrying a 'trickle-ice' Info
Package body or on transmission of the Answer in a 2xx response. Package body, on receipt of any other in-dialog request from the
This is similar to the procedure described in section 8.1.1 of offerer or on transmission of the Answer in a 2xx response. The
offerer cannot send in-dialog requests until it receives a response,
so the arrival of such a request proves that the response has
arrived. Using the INFO request for dialog confirmation is similar
to the procedure described in section 6.1.1 of
[I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is
replaced by the INFO request. replaced by the INFO request.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for
version 16 of said I-D. Authors need to cross-check during Auth48 version 20 of said I-D. Authors need to cross-check during Auth48
since it could have have changed in the meantime.] since it could have have changed in the meantime.]
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 request MUST repeat the candidates that were already provided in INFO request 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). when new candidates have not been learned since then). The first
case could happen when Half Trickle is used and all candidate were
already in the initial offer. The second case could happen when Full
Trickle is used and the offerer is currently gathering additional
candidates, but did not yet get them. Also, if the initial Offer did
not contain any candidates, depending on how the Offerer gathers its
candidates and how long it takes to do so, this INFO could still
contain no candidates.
If available, the Offerer SHOULD also deliver newly learned When Full Trickle is used and if newly learned candidates are
candidates in this INFO request, unless it wants to hold back some available, the Offerer SHOULD also deliver these candidates in said
candidates in reserve, e.g. in case that these candidates are INFO request, unless it wants to hold back some candidates in
expensive to use and would only be trickled if all other candidates reserve, e.g. in case that these candidates are expensive to use and
failed. would only be trickled if all other candidates failed.
The Offerer SHOULD include an end-of-candidates attribute in case The Offerer SHOULD include an end-of-candidates attribute in case
candidate discovery has ended in the mean time and no further candidate discovery has ended in the mean time and no further
candidates are to be trickled. candidates are to be trickled.
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 established at both ends Answerer has an indication that a dialog is established at both ends
and can begin trickling (Figure 5). and can begin trickling (Figure 5).
Note: The +SRFLX in Figure 5 indicates that additionally newly Note: The +SRFLX in Figure 5 indicates that additionally newly
skipping to change at page 14, line 19 skipping to change at page 14, line 50
The ability to convey arbitrary candidates in INFO message bodies The ability 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 can therefore respond to an INVITE Answer. Trickle ICE Agents can therefore respond to an INVITE
request with provisional responses without an SDP Answer [RFC3261]. request with provisional responses without an SDP Answer [RFC3261].
Such provisional responses serve for establishing an early dialog. Such 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]. These retransmissions MUST cease on receipt described in [RFC3262]. These retransmissions MUST cease on receipt
of an INFO request or on transmission of the Answer in a 2xx of an INFO request carrying a 'trickle-ice' Info Package body, on
response. This is again similar to the procedure described in receipt any in-dialog request from the offerer or on transmission of
section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer the Answer in a 2xx response. The offerer cannot send in-dialog
is not yet provided. requests until it receives a response, so the arrival of such a
request proves that the response has arrived. This is again similar
to the procedure described in section 6.1.1 of
[I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet
provided.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for [RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for
version 16 of said I-D. Authors need to cross-check during Auth48 version 20 of said I-D. Authors need to cross-check during Auth48
since it could have have changed in the meantime.] since it could have have changed in the meantime.]
Note: The +SRFLX in Figure 6 indicates that additionally newly Note: The +SRFLX in Figure 6 indicates that additionally newly
learned server-reflexive candidates are included. learned server-reflexive candidates are included.
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
skipping to change at page 15, line 44 skipping to change at page 16, line 10
and used candidates, if any, and MAY include all newly gathered and used candidates, if any, and MAY include all newly gathered
candidates since the last INFO request was sent. However, if that candidates since the last INFO request was sent. However, if that
Answer was already sent in a unreliable provisional response, the Answer was already sent in a unreliable provisional response, the
Answerers MUST repeat exactly the same Answer in the 200 OK response Answerers MUST repeat exactly the same Answer in the 200 OK response
to the INVITE request in order to fulfill the corresponding to the INVITE request in order to fulfill the corresponding
requirements in [RFC3264]. In case that trickling continued, an requirements in [RFC3264]. In case that trickling continued, an
Offerer needs to be prepared for receiving fewer candidates in that Offerer needs to be prepared for receiving fewer candidates in that
repeated Answer than previously exchanged via trickling and MUST repeated Answer than previously exchanged via trickling and MUST
ignore the candidate information in that 200 OK response. ignore the candidate information in that 200 OK response.
4.3.4. Considerations for Third Party Call Control
Third Party Call Control (3PCC) for SIP can be performed using
several signaling variants as described in [RFC3725]. We give
specific consideration for 3PCC that starts with an offerless INVITE
request [RFC3261]. As specified in Section 4 this offerless INVITE
MUST include the SIP option-tag 'trickle-ice' in a SIP Supported:
header field in order to indicate support for Trickle-ICE to the
Offerer (at the User Agent Server (UAS)). Then, a UAS has the option
to send its Offer in a reliable provisional response [RFC3262] or in
the 200 OK response to the INVITE request.
Agents that had sent an Offer in a reliable provisional response and
that received an Answer in a PRACK request [RFC3262] are also in a
situation where support for Trickle ICE is confirmed and the SIP
dialog is guaranteed to be in a state that allows in-dialog INFO
requests (see Figure 7).
Alice Bob
| |
| INVITE |
|------------------------>|
| 183 (Offer) |
|<------------------------|
| PRACK (Answer) |
|------------------------>|
| |
| +----------------------+
| |Bob: I know Alice can|
| |trickle and I know her|
| |dialog is in the early|
| |state. Send INFO! |
| +----------------------+
| |
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| |
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| 200 OK/ACK |
|<------------------------|
Note: SRFLX denotes server-reflexive candidates
Figure 7: A SIP Offerer in a 3PCC scenario can also freely start
trickling as soon as it receives an Answer.
Trickle ICE Agents that send an Offer in a 200 OK response and
receive an Answer in an ACK message can still create a dialog and
confirm support for Trickle ICE by sending an unreliable provisional
response similar to Section 4.3.3. As specified in Section 4 this
unreliable provisional response MUST include the SIP option-tag
'trickle-ice' in a SIP Supported: header field in order to indicate
support for Trickle-ICE to the UAC. According to [RFC3261], this
unreliable response cannot contain an Offer.
The Trickle ICE Agent, i.e. the user Agent server (UAS), retransmits
the provisional response with the exponential back-off timers
described in [RFC3262]. Retransmits MUST cease on receipt of an INFO
request or on transmission of the Answer in a 2xx response. The peer
Trickle ICE Agent (the UAC) MUST send a Trickle ICE INFO request as
soon as it receives an unreliable provisional response (see
Figure 8).
Alice Bob
| |
| INVITE |
|------------------------>|
| 183 (-) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +-----------------------+
| |Bob: I know Alice can |
| |trickle and I know her |
| |dialog is in the early |
| |state. |
| |INFO can be sent. |
| +-----------------------+
| |
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| |
| 200 (Offer) |
|<------------------------|
| ACK (Answer) |
|------------------------>|
| |
Note: SRFLX denotes server-reflexive candidates
Figure 8: A SIP UAC in a 3PCC scenario can also freely start
trickling as soon as it receives an unreliable provisional response.
4.4. Delivering Candidates in INFO Requests 4.4. Delivering Candidates in INFO Requests
Whenever new ICE candidates become available for sending, agents Whenever new ICE candidates become available for sending, agents
encode them in "a=candidate:" attributes as described by encode them in "a=candidate:" attributes as described by
[I-D.ietf-mmusic-ice-sip-sdp]. For example: [I-D.ietf-mmusic-ice-sip-sdp]. For example:
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 8998 raddr 2001:db8:a0b:12f0::1 rport 8998
The use of SIP INFO requests happens within the context of the Info The use of SIP INFO requests happens within the context of the Info
Package as defined Section 10. The Media Type [RFC6838] for their Package as defined Section 10. The Media Type [RFC6838] for their
payload MUST be set to 'application/trickle-ice-sdpfrag' as defined payload MUST be set to 'application/trickle-ice-sdpfrag' as defined
in Section 9. The Info request body adheres to the grammar as in Section 9. The Info request body adheres to the grammar as
specified in Section 9.2. specified in Section 9.2.
Since neither the "a=candidate:" nor the "a=end-of-candidates" Since neither the "a=candidate:" nor the "a=end-of-candidates"
attributes contain information that would allow correlating them to a attributes contain information that would allow correlating them to a
specific "m=" line, this is handled through the use of pseudo "m=" specific "m=" line, this is handled through the use of pseudo "m="
lines and identification tags in "a=mid:" attributes as defined in lines.
[RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in [RFC4566], but provide no semantics other than indicating Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in
to which "m=" line a candidate belongs. Consequently, the receiving [RFC4566] It is linked to the corresponding "m=" line in the SDP
agent MUST ignore any remaining content of the pseudo "m=" line, Offer or Answer via the identification tag in a "a=mid:" attribute
which is not defined in this document. This guarantees that the which is defined in [RFC5888]. A pseudo "m=" line does not provide
'application/trickle-ice-sdpfrag' bodies do not interfere with the semantics other than indicating to which "m=" line a candidate
Offer/Answer procedures as specified in [RFC3264]. belongs. Consequently, the receiving agent MUST ignore any remaining
content of the pseudo "m=" line, which is not defined in this
document. This guarantees that the 'application/trickle-ice-sdpfrag'
bodies do not interfere with the Offer/Answer procedures as specified
in [RFC3264].
When sending the INFO request, the agent MAY, if already known to the When sending the INFO request, the agent MAY, if already known to the
agent, include the same content into the pseudo "m=" line as for the agent, include the same content into the pseudo "m=" line as for the
"m=" line in the corresponding Offer or Answer. However, since "m=" line in the corresponding Offer or Answer. However, since
Trickle-ICE might be decoupled from the Offer/Answer negotiation this Trickle-ICE might be decoupled from the Offer/Answer negotiation this
content might be unknown to the agent. In this case, the agent MUST content might be unknown to the agent. In this case, the agent MUST
include the following default values. include the following default values.
o The media field is set to 'audio'. o The media field is set to 'audio'.
skipping to change at page 19, line 6 skipping to change at page 17, line 22
"a=mid:" attribute for every "m=" line whose candidate list they "a=mid:" attribute for every "m=" line whose candidate list they
intend to update. Such "a=mid:" attributes MUST immediately precede intend to update. Such "a=mid:" attributes MUST immediately precede
the list of candidates for that specific "m=" line. the list of candidates for that specific "m=" line.
All "a=candidate:" or "a=end-of-candidates" attributes following an All "a=candidate:" or "a=end-of-candidates" attributes following an
"a=mid:" attribute, up until (and excluding) the next occurrence of a "a=mid:" attribute, up until (and excluding) the next occurrence of a
pseudo "m=" line, pertain to the "m=" line identified by that pseudo "m=" line, pertain to the "m=" line identified by that
identification tag. identification tag.
Note, that there is no requirement that the Info request body Note, that there is no requirement that the Info request body
contains as many pseudo m= lines as the Offer/Answer contains m= contains as many pseudo m= lines as the Offer/Answer contains
lines, nor that the pseudo m= lines be in the same order as the m=lines, nor that the pseudo m= lines be in the same order as the
m=lines that they pertain to. The correspondence can be made via the m=lines that they pertain to. The correspondence can be made via the
"a=mid:" attributes. "a=mid:" attributes since candidates are grouped in sections headed
by "pseudo" m=lines. These sections contain "a=mid:" attribute
values which point back to the true m=line.
An "a=end-of-candidates" attribute, preceding any pseudo "m=" line, An "a=end-of-candidates" attribute, preceding the first pseudo "m="
indicates the end of all trickling from that agent, as opposed to end line, indicates the end of all trickling from that agent, as opposed
of trickling for a specific "m=" line, which would be indicated by a to end of trickling for a specific "m=" line, which would be
media level "a=end-of-candidates" attribute. indicated by a media level "a=end-of-candidates" attribute.
Refer to Figure 9 for an example of the INFO request content. Refer to Figure 7 for an example of the INFO request content.
The use of pseudo "m=" lines allows for a structure similar to the The use of pseudo "m=" lines allows for a structure similar to the
one in SDP Offers and Answers where separate media-level and session- one in SDP Offers and Answers where separate media-level and session-
level sections can be distinguished. In the current case, lines level sections can be distinguished. In the current case, lines
preceding any pseudo "m=" line are considered to be session-level. preceding the first pseudo "m=" line are considered to be session-
Lines appearing in between or after pseudo "m=" lines will be level. Lines appearing in between or after pseudo "m=" lines will be
interpreted as media-level. interpreted as media-level.
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, the "a=group:" attribute from that same
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 allow mapping them to a specific ICE generation. An attributes that allow mapping them to a specific ICE generation. An
agent MUST discard any received INFO requests containing "a=ice-pwd:" agent MUST discard any received INFO requests containing "a=ice-pwd:"
and "a=ice-ufrag:" attributes that do not match those of the current and "a=ice-ufrag:" attributes that do not match those of the current
ICE Negotiation Session. 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, they will also if they were present as session-level attributes, they will also
appear at the beginning of all INFO request payloads, i.e. preceding appear at the beginning of all INFO request payloads, i.e. preceding
all pseudo "m=" lines. If they were originally exchanged as media the first pseudo "m=" line. If they were originally exchanged as
level attributes, potentially overriding session-level values, then media level attributes, potentially overriding session-level values,
they will also be included in INFO request payloads following the then they will also be included in INFO request payloads following
corresponding pseudo "m=" lines. the corresponding pseudo "m=" lines.
Note that [I-D.ietf-ice-trickle] requires that when candidates are Note that [I-D.ietf-ice-trickle] requires that when candidates are
trickled, each candidate must be delivered to the receiving Trickle trickled, each candidate must be delivered to the receiving Trickle
ICE implementation not more than once and in the same order as it was ICE implementation not more than once and in the same order as it was
conveyed. If the signaling protocol provides any candidate conveyed. If the signaling protocol provides any candidate
retransmissions, they need to be hidden from the ICE implementation. retransmissions, they need to be hidden from the ICE implementation.
This requirement is fulfilled as follows. This requirement is fulfilled as follows.
Since the agent is not fully aware of the state of the ICE Since the agent is not fully aware of the state of the ICE
Negotiation Session at its peer it MUST include all currently known Negotiation Session at its peer it MUST include all currently known
and used local candidates in every INFO request. I.e. the agent MUST and used local candidates in every INFO request. I.e. the agent MUST
repeat in the INFO request body all candidates that were previously repeat in the INFO request body all candidates that were previously
sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in
the same order as they were gathered. In other words, the sequence the same order as they were sent before. In other words, the
of a previously sent list of candidates MUST NOT change in subsequent sequence of a previously sent list of candidates MUST NOT change in
INFO requests and newly gathered candidates MUST be added at the end subsequent INFO requests and newly gathered candidates MUST be added
of that list. Although repeating all candidates creates some at the end of that list. Although repeating all candidates creates
overhead, it also allows easier handling of problems that could arise some overhead, it also allows easier handling of problems that could
from unreliable transports, like e.g. loss of messages and arise from unreliable transports, like e.g. loss of messages and
reordering, which can be detected through the CSeq: header field in reordering, which can be detected through the CSeq: header field in
the INFO request. the INFO request.
In addition, an ICE agent needs to adhere to section 17 of
[I-D.ietf-ice-trickle] on preserving candidate order while trickling.
When receiving INFO requests carrying any candidates, agents MUST When receiving INFO requests carrying any candidates, agents MUST
therefore first identify and discard the attribute 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. the Offer/Answer exchange preceding them.
Such candidates are considered to be equal if their IP address port, Such candidates are considered to be equal if their IP address port,
transport and component ID are the same. After identifying and transport and component ID are the same. After identifying and
discarding the known candidates, the agents MUST forward the actually discarding the known candidates, the agents MUST forward the actually
new candidates to the ICE Agents in the same order as they were new candidates to the ICE Agents in the same order as they were
received in the INFO request body. The ICE Agents will then process received in the INFO request body. The ICE Agents will then process
skipping to change at page 20, line 41 skipping to change at page 19, line 11
Receiving an "a=end-of-candidates" attribute in an INFO request body Receiving an "a=end-of-candidates" attribute in an INFO request body
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the
current ICE generation - is an indication from the peer agent that it current ICE generation - is an indication from the peer agent that it
will not send any further candidates. When included at session will not send any further candidates. When included at session
level, i.e. before any pseudo "m=" line, this indication applies to level, i.e. before any pseudo "m=" line, this indication applies to
the whole session; when included at media level the indication the whole session; when included at media level the indication
applies only to the corresponding "m=" line. Handling of such end- applies only to the corresponding "m=" line. Handling of such end-
of-candidates indications is defined in [I-D.ietf-ice-trickle]. of-candidates indications is defined in [I-D.ietf-ice-trickle].
Note: At the time of writing this specification there were ongoing The example in Figure 7 shows the content of a candidate delivering
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
request. However, if an implementation according to this
specification receives such an INFO request with a missing candidate
it would have to treat that as an exceptional case. Implementing
appropriate recovery procedures at the receiving side is advisable
for this situation. Ignoring that a candidate was missing might be a
sensible strategy.
The example in Figure 9 shows the content of a candidate delivering
INFO request. In the example the "a=end-of-candidates" attributes INFO request. In the example the "a=end-of-candidates" attributes
indicate that the candidate gathering is finished and that no further indicate that the candidate gathering is finished and that no further
INFO requests follow. INFO requests follow.
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/trickle-ice-sdpfrag Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: 862 Content-length: 862
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 2130706431 2001:db8:a0b:12f0::1 5000 typ host a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host
raddr 2001:db8:a0b:12f0::1 rport 8998 a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host
a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 8998 raddr 192.0.2.1 rport 8998
a=end-of-candidates a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx
m=audio 9 RTP/AVP 0 raddr 192.0.2.1 rport 8998
a=mid:2 a=end-of-candidates
a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host m=audio 9 RTP/AVP 0
a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host a=mid:2
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host
raddr 2001:db8:a0b:12f0::1 rport 9998 a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host
raddr 2001:db8:a0b:12f0::1 rport 9998 a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host
a=end-of-candidates a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx
raddr 192.0.2.1 rport 9998
a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx
raddr 192.0.2.1 rport 9998
a=end-of-candidates
Note: In a real INFO request there will be no line breaks Note: In a real INFO request there will be no line breaks
in the a=candidate: attributes in the a=candidate: attributes
Figure 9: An Example for the Content of an INFO Request Figure 7: An Example for the Content of an INFO Request
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 attribute "a=ice-options:trickle" and MUST and Answers using the attribute "a=ice-options:trickle" and MUST
include the SIP option-tag "trickle-ice" in a SIP Supported: header include the SIP option-tag "trickle-ice" in a SIP Supported: or
field. This makes discovery fairly straightforward for Answerers or Require: header field. This makes discovery fairly straightforward
for cases where Offers need to be generated within existing dialogs for Answerers or for cases where Offers need to be generated within
(i.e., when sending UPDATE or re-INVITE requests). In both scenarios existing dialogs (i.e., when sending UPDATE or re-INVITE requests).
prior SDP bodies will have provided the necessary information.
In both scenarios prior SDP bodies will have provided the necessary
information.
Obviously, such information is not available at the time a first Obviously, such information is not available at the time a first
Offer is being constructed and it is therefore impossible for ICE Offer is being constructed and it is therefore impossible for ICE
Agents to determine support for incremental provisioning that way. Agents to determine support for incremental provisioning that way.
The following options are suggested as ways of addressing this issue. The following options are suggested as ways of addressing this issue.
5.1. Provisioning Support for Trickle ICE 5.1. Provisioning Support for Trickle ICE
In certain situations it may be possible for integrators deploying In certain situations it may be possible for integrators deploying
Trickle ICE to know in advance that some or all endpoints reachable Trickle ICE to know in advance that some or all endpoints reachable
from within the deployment will support Trickle ICE. This is the from within the deployment will support Trickle ICE. This is the
case, for example, if Session Border Controllers (SBC) with support case, for example, if Session Border Controllers (SBC) with support
for this specification are used to connect to UAs that do not support for this specification are used to connect to UAs that do not support
Trickle ICE. Trickle ICE.
While the exact mechanism for allowing such provisioning is out of While the exact mechanism for allowing such provisioning is out of
scope here, this specification encourages trickle ICE implementations scope here, this specification encourages trickle ICE implementations
to allow the option in the way they find most appropriate. to allow the option in the way they find most appropriate.
However, an Offerer assuming Trickle ICE support MUST include a SIP
Require: trickle-ice header field. That way, if the provisioned
assumption of Trickle ICE support ends up being incorrect, the
failure is (a) operationally easy to track down, and (b) recoverable
by the client, i.e., they can re-send the request without the SIP
Require: header field and without the assumption of Trickle ICE
support.
5.2. Trickle ICE Discovery with Globally Routable User Agent URIs 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs
(GRUU) (GRUU)
[RFC3840] provides a way for SIP User Agents to query for support of [RFC3840] provides a way for SIP User Agents to query for support of
specific capabilities using, among others, OPTIONS requests. Support specific capabilities using, among others, OPTIONS requests. Support
for GRUU according to [RFC5627] on the other hand allows SIP requests for GRUU according to [RFC5627] on the other hand allows SIP requests
to be addressed to specific UAs (as opposed to arbitrary instances of to be addressed to specific UAs (as opposed to arbitrary instances of
an address of record). Combining the two and using the "trickle-ice" an address of record). Combining the two and using the "trickle-ice"
option tag defined in Section 10.6 provides SIP UAs with a way of option tag defined in Section 10.6 provides SIP UAs with a way of
learning the capabilities of specific SIP UA instances and then learning the capabilities of specific SIP UA instances and then
addressing them directly with INVITE requests that require Trickle addressing them directly with INVITE requests that require Trickle
ICE support. ICE support.
Such learning of capabilities may happen in different ways. One Such learning of capabilities may happen in different ways. One
option for a SIP UA is to learn the GRUU instance ID of a peer option for a SIP UA is to learn the GRUU instance ID of a peer
through presence and then to query its capabilities with an OPTIONS through presence and then to query its capabilities with an OPTIONS
request. Alternatively, it can also just send an OPTIONS request to request. Alternatively, it can also just send an OPTIONS request to
the Address of Record (AOR) it intends to contact and then inspect the Address of Record (AOR) it intends to contact and then inspect
the returned response(s) for support of both GRUU and Trickle ICE the returned response(s) for support of both GRUU and Trickle ICE
(Figure 10). It is noted that using the GRUU means that the INVITE (Figure 8). It is noted that using the GRUU means that the INVITE
request can go only to that particular device. This prevents the use request can go only to that particular device. This prevents the use
of forking for that request. of forking for that request.
Alice Bob Alice Bob
| | | |
| OPTIONS sip:b1@example.com SIP/2.0 | | OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 200 OK | | 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a | | Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... | | ;audio;video|;trickle-ice;... |
|<--------------------------------------------------| |<--------------------------------------------------|
| | | |
| INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 | | INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 |
| Supported: trickle-ice |
| (Offer) |
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 183 (Answer) | | 183 (Answer) |
|<--------------------------------------------------| |<--------------------------------------------------|
| INFO/OK (Trickling) | | INFO/OK (Trickling) |
|<------------------------------------------------->| |<------------------------------------------------->|
| | | |
| ... | | ... |
| | | |
Figure 10: Trickle ICE support discovery with OPTIONS and GRUU Figure 8: Trickle ICE support discovery with OPTIONS and GRUU
Confirming support for Trickle ICE through [RFC3840] gives SIP UAs Confirming support for Trickle ICE through [RFC3840] gives SIP UAs
the options to engage in Full Trickle negotiation (as opposed to the the options to engage in Full Trickle negotiation (as opposed to the
more lengthy Half Trickle) from the very first Offer they send. more lengthy Half Trickle) from the very first Offer they send.
5.3. Fall-back to Half Trickle 5.3. Fall-back to Half Trickle
In cases where none of the other mechanisms in this section are In cases where none of the other mechanisms in this section are
acceptable, SIP UAs should use the Half Trickle mode defined in acceptable, SIP UAs should use the Half Trickle mode defined in
[I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions
skipping to change at page 24, line 39 skipping to change at page 23, line 42
| |<----------------------------| | | |<----------------------------| |
| | Connectivity Checks |<--------------| | | Connectivity Checks |<--------------|
| |<===========================>| | | |<===========================>| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| |<----------------------------| | | |<----------------------------| |
| | | | | | | |
| |<======= MEDIA FLOWS =======>| | | |<======= MEDIA FLOWS =======>| |
| | | | | | | |
Figure 11: Example - A typical (Half) Trickle ICE exchange with SIP Figure 9: Example - A typical (Half) Trickle ICE exchange with SIP
It is worth reminding that once a single Offer or Answer had been It is worth reminding that once a single Offer or Answer had been
exchanged within a specific dialog, support for Trickle ICE will have exchanged within a specific dialog, support for Trickle ICE will have
been determined. No further use of Half Trickle will therefore be been determined. No further use of Half Trickle will therefore be
necessary within that same dialog and all subsequent exchanges can necessary within that same dialog and all subsequent exchanges can
use the Full Trickle mode of operation. use the Full Trickle mode of operation.
6. Considerations for RTP and RTCP Multiplexing 6. Considerations for RTP and RTCP Multiplexing
The following consideration describe options for Trickle-ICE in order The following consideration describe options for Trickle-ICE in order
skipping to change at page 25, line 13 skipping to change at page 24, line 19
optimized with respect to providing RTCP candidates. optimized with respect to providing RTCP candidates.
Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux"
attribute for RTP/RTCP multiplexing [RFC5761] is already considered attribute for RTP/RTCP multiplexing [RFC5761] is already considered
in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in
[RFC5761] itself. These considerations are still valid for Trickle [RFC5761] itself. These considerations are still valid for Trickle
ICE, however, trickling provides more flexibility for the sequence of ICE, however, trickling provides more flexibility for the sequence of
candidate exchange in case of RTCP multiplexing. candidate exchange in case of RTCP multiplexing.
[RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct [RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct
for version 15 of said I-D. Authors need to cross-check during for version 17 of said I-D. Authors need to cross-check during
Auth48 since it could have have changed in the meantime.] Auth48 since it could have have changed in the meantime.]
If the Offerer supports RTP/RTCP multiplexing exclusively as If the Offerer supports RTP/RTCP multiplexing exclusively as
specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that
document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" document apply for the handling of the "a=rtcp-mux-only", "a=rtcp"
and the "a=rtcp-mux" attributes. and the "a=rtcp-mux" attributes.
While a Half Trickle Offerer has to send an Offer compliant to While a Half Trickle Offerer has to send an Offer compliant to
[I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for
all components, the flexibility of a Full Trickle Offerer allows to all components, the flexibility of a Full Trickle Offerer allows to
skipping to change at page 26, line 40 skipping to change at page 25, line 40
a=mid:1 a=mid:1
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host
This INFO request indicates that the Answerer supports and uses RTP This INFO request indicates that the Answerer supports and uses RTP
and RTCP multiplexing as well. It allows the Offerer to omit and RTCP multiplexing as well. It allows the Offerer to omit
gathering of RTCP candidates or releasing already gathered RTCP gathering of RTCP candidates or releasing already gathered RTCP
candidates. If the INFO request did not contain the a=rtcp-mux candidates. If the INFO request did not contain the a=rtcp-mux
attribute, the Offerer has to gather RTCP candidates unless it wants attribute, the Offerer has to gather RTCP candidates unless it wants
to wait until receipt of an Answer that eventually confirms support to wait until receipt of an Answer that eventually confirms support
or non-support for RTP and RTCP multiplexing. or non-support for RTP and RTCP multiplexing. In case the Offerer
had sent RTCP candidates in a previous INFO request, it still needs
to repeat them in subsequent INFO requests, even in case that support
for RTCP multiplexing was confirmed by the Answerer and the Offerer
has released its RTCP candidates.
7. Considerations for Media Multiplexing 7. Considerations for Media Multiplexing
The following considerations describe options for Trickle-ICE in The following considerations describe options for Trickle-ICE in
order to give some guidance to implementors on how trickling can be order to give some guidance to implementors on how trickling can be
optimized with respect to providing candidates in case of Media optimized with respect to providing candidates in case of Media
Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed
that the reader is familiar with that the reader is familiar with
[I-D.ietf-mmusic-sdp-bundle-negotiation]. [I-D.ietf-mmusic-sdp-bundle-negotiation].
skipping to change at page 27, line 28 skipping to change at page 26, line 37
supported by the Answerer and if the suggested Offerer BUNDLE address supported by the Answerer and if the suggested Offerer BUNDLE address
was selected. In this case, the Offerer does not need to trickle was selected. In this case, the Offerer does not need to trickle
further candidates for the remaining "m=" lines in a bundle. further candidates for the remaining "m=" lines in a bundle.
However, if BUNDLE is not supported, the Full Trickle Offerer needs However, if BUNDLE is not supported, the Full Trickle Offerer needs
to gather and trickle candidates for the remaining "m=" lines as to gather and trickle candidates for the remaining "m=" lines as
necessary. If the Answerer selects an Offerer BUNDLE address necessary. If the Answerer selects an Offerer BUNDLE address
different from the suggested Offerer BUNDLE address, the Full Trickle different from the suggested Offerer BUNDLE address, the Full Trickle
Offerer needs to gather and trickle candidates for the "m=" line that Offerer needs to gather and trickle candidates for the "m=" line that
carries the selected Offerer BUNDLE address. carries the selected Offerer BUNDLE address.
A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute A Trickle Answerer SHOULD include an "a=group:BUNDLE" attribute
[I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle- [I-D.ietf-mmusic-sdp-bundle-negotiation] at session level in the
ice-sdpfrag body if it supports and uses bundling. When doing so, application/trickle-ice-sdpfrag body if it supports and uses
the Answerer MUST include all identification-tags in the same order bundling. When doing so, the Answerer MUST include all
that is used or will be used in the Answer. identification-tags in the same order that is used or will be used in
the Answer.
Receipt of this attribute at the Offerer in an INFO request prior to Receipt of this attribute at the Offerer in an INFO request prior to
the Answer indicates that the Answerer supports and uses bundling. the Answer indicates that the Answerer supports and uses bundling.
The Offerer can use this information e.g. for stopping the gathering The Offerer can use this information e.g. for stopping the gathering
of candidates for the remaining "m=" lines in a bundle and/or for of candidates for the remaining "m=" lines in a bundle and/or for
freeing corresponding resources. freeing corresponding resources.
This behaviour is illustrated by the following example Offer that This behaviour is illustrated by the following example Offer that
indicates support for Media Multiplexing. indicates support for Media Multiplexing.
In case the Offerer had sent already candidates for m-lines in a
bundle in a previous INFO request, it still needs to repeat them in
subsequent INFO requests, even in case that support for bundling was
confirmed by the Answerer and the Offerer has released no longer
needed candidates.
v=0 v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s= s=
c=IN IP6 2001:db8:a0b:12f0::3 c=IN IP6 2001:db8:a0b:12f0::3
t=0 0 t=0 0
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8 a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0 m=audio 10000 RTP/AVP 0
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
m=video 10002 RTP/AVP 31
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
The example Offer indicates support for RTP and RTCP multiplexing and The example Offer indicates support for RTP and RTCP multiplexing and
contains a "a=candidate:" attribute only for the m-line with the contains a "a=candidate:" attribute only for the m-line with the
suggested Offerer bundle address. Once the dialog is established as suggested Offerer bundle address. Once the dialog is established as
described in Section 4.3 the Answerer sends the following INFO described in Section 4.3 the Answerer sends the following INFO
request. 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
skipping to change at page 31, line 5 skipping to change at page 30, line 5
The grammar of an 'application/trickle-ice-sdpfrag' body is based on The grammar of an 'application/trickle-ice-sdpfrag' body is based on
the following ABNF [RFC5234]. It specifies the subset of existing the following ABNF [RFC5234]. It specifies the subset of existing
SDP attributes, that is needed or useful for trickling candidates. SDP attributes, that is needed or useful for trickling candidates.
The grammar uses the indicator for case-sensitivity %s as defined in The grammar uses the indicator for case-sensitivity %s as defined in
[RFC7405], but also imports grammars for other SDP attributes that [RFC7405], but also imports grammars for other SDP attributes that
precede the production of [RFC7405]. A sender SHOULD use lower-case precede the production of [RFC7405]. A sender SHOULD use lower-case
for attributes from such earlier grammars, but a receiver MUST treat for attributes from such earlier grammars, but a receiver MUST treat
them case-insensitively. them case-insensitively.
; Syntax ; Syntax
trickle-ice-sdpfrag = session-level-fields trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions pseudo-media-descriptions
session-level-fields = [bundle-group-attribute CRLF] session-level-fields = *(session-level-field CRLF)
[ice-lite-attribute CRLF]
ice-pwd-attribute CRLF
ice-ufrag-attribute CRLF
[ice-options-attribute CRLF]
[ice-pacing-attribute CRLF]
[end-of-candidates-attribute CRLF]
extension-attribute-fields
; for future extensions
ice-lite-attribute = %s"a" "=" ice-lite session-level-field = ice-lite-attribute /
ice-pwd-attribute = %s"a" "=" ice-pwd-att ice-pwd-attribute /
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att ice-ufrag-attribute /
ice-pacing-attribute = %s"a" "=" ice-pacing-att ice-options-attribute /
ice-options-attribute = %s"a" "=" ice-options ice-pacing-attribute /
bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics end-of-candidates-attribute /
*(SP identification-tag) bundle-group-attribute /
bundle-semantics = "BUNDLE" extension-attribute-fields
end-of-candidates-attribute = %s"a" "=" end-of-candidates ; for future extensions
end-of-candidates = %s"end-of-candidates"
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field ice-lite-attribute = %s"a" "=" ice-lite
trickle-ice-attribute-fields ice-pwd-attribute = %s"a" "=" ice-pwd-att
[extension-attribute-fields] ) ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
; for future extensions ice-pacing-attribute = %s"a" "=" ice-pacing-att
trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF ice-options-attribute = %s"a" "=" ice-options
[%s"a" "=" %s"rtcp" CRLF] end-of-candidates-attribute = %s"a" "=" end-of-candidates
[%s"a" "=" %s"rtcp-mux" CRLF] end-of-candidates = %s"end-of-candidates"
[%s"a" "=" %s"rtcp-mux-only" CRLF] bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
*(candidate-attributes CRLF) *(SP identification-tag)
[ice-pwd-attribute CRLF] bundle-semantics = "BUNDLE"
[ice-ufrag-attribute CRLF] extension-attribute-fields = attribute-fields
[remote-candidate-attribute CRLF]
[end-of-candidates-attribute CRLF] pseudo-media-descriptions = *( media-field
remote-candidate-attribute = %s"a" "=" remote-candidate-att trickle-ice-attribute-fields )
candidate-attributes = %s"a" "=" candidate-attribute trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
trickle-ice-attribute-field = mid-attribute /
candidate-attributes /
ice-pwd-attribute /
ice-ufrag-attribute /
remote-candidate-attribute /
end-of-candidates-attribute /
rtcp-attribute /
rtcp-mux-attribute /
rtcp-mux-only-attribute /
extension-attribute-fields
; for future extensions
rtcp-attribute = %s"a" "=" %s"rtcp"
rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux"
rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only"
candidate-attributes = %s"a" "=" candidate-attribute
remote-candidate-attribute = %s"a" "=" remote-candidate-att
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
pacing-att, ice-options, candidate-attribute remote-candidate-att pacing-att, ice-options, candidate-attribute remote-candidate-att
from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute
; from [RFC5888], media-field, attribute-fields from [RFC4566]. The ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The
"a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux"
attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in
[I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal
grammar in their corresponding RFC and are reproduced here. grammar in their corresponding RFC and are reproduced here.
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,
if they were present as session-level attributes, they will also
appear at the beginning of all INFO request payloads, i.e. preceding
all pseudo "m=" lines. If they were originally exchanged as media
level attributes, potentially overriding session-level values, then
they will also be included in INFO request payloads following the
corresponding pseudo "m=" lines.
An Agent MUST ignore any received unknown extension-attribute-fields. An Agent MUST ignore any received unknown extension-attribute-fields.
10. Info Package 10. Info Package
10.1. Rationale - Why INFO? 10.1. Rationale - Why INFO?
The decision to use SIP INFO requests as a candidate transport method The decision to use SIP INFO requests as a candidate transport method
is based primarily on their lightweight nature. Once a dialog has is based primarily on their lightweight nature. Once a dialog has
been established, INFO requests can be exchanged both ways with no been established, INFO requests can be exchanged both ways with no
restrictions on timing and frequency and no risk of collision. restrictions on timing and frequency and no risk of collision.
skipping to change at page 34, line 18 skipping to change at page 33, line 29
10.6. SIP Option Tags 10.6. SIP Option Tags
[RFC6086] allows Info Package specifications to define SIP option- [RFC6086] allows Info Package specifications to define SIP option-
tags. This specification extends the option-tag construct of the SIP tags. This specification extends the option-tag construct of the SIP
grammar as follows: grammar as follows:
option-tag /= "trickle-ice" option-tag /= "trickle-ice"
SIP entities that support this specification MUST place the 'trickle- SIP entities that support this specification MUST place the 'trickle-
ice' option-tag in a SIP Supported: header field within all SIP ice' option-tag in a SIP Supported: or Require: header field within
INVITE requests and responses. all SIP INVITE requests and responses.
When responding to, or generating a SIP OPTIONS request a SIP entity When responding to, or generating a SIP OPTIONS request a SIP entity
MUST also include the 'trickle-ice' option-tag in a SIP Supported: MUST also include the 'trickle-ice' option-tag in a SIP Supported: or
header field. Require: header field.
10.7. Info Request Body Parts 10.7. Info Request Body Parts
Entities implementing this specification MUST include a payload of Entities implementing this specification MUST include a payload of
type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in
SIP INFO requests. The payload is used to convey SDP-encoded ICE SIP INFO requests. The payload is used to convey SDP-encoded ICE
candidates. candidates.
10.8. Info Package Usage Restrictions 10.8. Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions. This document does not define any Info Package Usage Restrictions.
10.9. Rate of INFO Requests 10.9. Rate of INFO Requests
Given that IP addresses may be gathered rapidly a Trickle ICE Agent Given that IP addresses may be gathered rapidly a Trickle ICE Agent
with many network interfaces might create a high rate of INFO with many network interfaces might create a high rate of INFO
requests if every newly detected candidate is trickled individually requests if every newly detected candidate is trickled individually
without aggregation. Implementors MUST consider aggregating ICE without aggregation. An implementation MUST aggregate ICE candidates
candidates in case that UDP is used as transport protocol and send in case that an unreliable transport protocol such as UDP is used. A
INFOs only at some configurable intervals. Trickle ICE agent MUST NOT have more than one INFO request pending at
any one time. When INFO messages are sent over an unreliable
transport, they are retransmitted according to the rules specified in
[RFC3261] section 17.1.2.1."
If the INFO requests are sent on top of TCP, which is probably the If the INFO requests are sent on top of TCP, which is probably the
standard way, this is not an issue for the network anymore, but it standard way, this is not an issue for the network anymore, but it
can remain one for SIP proxies and other intermediaries forwarding can remain one for SIP proxies and other intermediaries forwarding
the SIP INFO messages. Also, an endpoint may not be able to tell the SIP INFO messages. Also, an endpoint may not be able to tell
that it has congestion controlled transport all the way. that it has congestion controlled transport all the way.
10.10. Info Package Security Considerations 10.10. Info Package Security Considerations
See Section 13 See Section 13
11. Deployment Considerations 11. Deployment Considerations
Trickle ICE uses two mechanism for exchange of candidate information. Trickle ICE uses two mechanisms for exchange of candidate
This imposes new requirements to certain middleboxes that are used in information. This imposes new requirements to certain middleboxes
some networks, e.g. for monitoring purposes. While the first that are used in some networks, e.g. for monitoring purposes. While
mechanism, SDP Offers and Answers, is already used by regular ICE and the first mechanism, SDP Offers and Answers, is already used by
is assumed to be supported, the second mechanism, INFO request regular ICE and is assumed to be supported, the second mechanism,
bodies, needs to be considered by such middleboxes as well when INFO request bodies, needs to be considered by such middleboxes as
trickle ICE is used. Such middleboxes need to make sure that they well when trickle ICE is used. Such middleboxes need to make sure
remain in the signaling path of the INFO requests and need to that they remain in the signaling path of the INFO requests and need
understand the INFO request body. to understand the INFO request body.
12. IANA Considerations 12. IANA Considerations
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document. ] document. ]
12.1. SDP 'end-of-candidates' Attribute 12.1. SDP 'end-of-candidates' Attribute
This section defines a new SDP media-level and session-level This section defines a new SDP media-level and session-level
attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a
skipping to change at page 39, line 22 skipping to change at page 38, line 22
scope of this document scope of this document
14. Acknowledgements 14. Acknowledgements
The authors like to thank Flemming Andreasen, Ayush Jain, Paul The authors like to thank Flemming Andreasen, Ayush Jain, Paul
Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin
Thomson for reviewing and/or making various suggestions for Thomson for reviewing and/or making various suggestions for
improvements and optimizations. improvements and optimizations.
The authors also like to thank Flemming Andreasen for shepherding The authors also like to thank Flemming Andreasen for shepherding
this document and Ben Campbell for his AD review and suggestions. this document and Ben Campbell for his AD review and suggestions. In
addition, the author like to thank Benjamin Kaduk, Adam Roach, Mirja
Kuehlewind and Eric Rescorla for their comments and/or text proposals
for improving the document during IESG review.
Many thanks to Dale Worley for Gen-Art review and proposed Many thanks to Dale Worley for Gen-Art review and proposed
enhancements for several sections. enhancements for several sections.
Many thanks to Joerg Ott for TSV-Art review and suggested Many thanks to Joerg Ott for TSV-Art review and suggested
improvements. improvements.
The authors thank Shawn Emery for Security Directorate review. The authors thank Shawn Emery for Security Directorate review.
15. Change Log 15. Change Log
skipping to change at page 43, line 10 skipping to change at page 42, line 10
o addressing comments from Gen-Art review, TSV-Art review and o addressing comments from Gen-Art review, TSV-Art review and
Security Directorate review Security Directorate review
o Numerous editorial improvements/corrections/clarifications o Numerous editorial improvements/corrections/clarifications
Changes from draft-ietf-mmusic-trickle-ice-sip-13 Changes from draft-ietf-mmusic-trickle-ice-sip-13
o added expansions for SDP,GRUU, AOR, STUN, TURN o added expansions for SDP,GRUU, AOR, STUN, TURN
o some editorial corrections o some editorial corrections
Changes from draft-ietf-mmusic-trickle-ice-sip-14
Addressing comments from IESG review
o Clarification/enhancement in section 5 and Fig. 10 based on
comments from Benjamin Kaduk
o Clarification on sequence for sending candidates, definition of
pseudo m-lines, usage of a=mid attribute, usage of INFO as ACK for
receipt of 18x based on comments from Eric Rescorla
o Removal of 3PCC Section 3.4, removal of NATted IPv6 addresses,
adding more flexibility to in the grammar, explicit mentioning of
Require: header field, usage of Require: header field in case of
provisioning, text on repetition of candidates in case of RTCP mux
and Bundle, various other editorial improvements/corrections based
on comments from Adam Roach
o Modified text on rate limitation of INFO requests based on
comments of Mirja Kuehlewind, Adam Roach and Roman Shpount
o some editorial corrections
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-17 (work in progress), February 2018. rfc5245bis-20 (work in progress), March 2018.
[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-16 (work in progress), Protocol", draft-ietf-ice-trickle-21 (work in progress),
February 2018. April 2018.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer "Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-20 (work in
progress), November 2017. progress), April 2018.
[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-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[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-48 (work in progress), January 2018. negotiation-51 (work in progress), May 2018.
[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-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), December 2016. (work in progress), February 2018.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://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,
skipping to change at page 45, line 19 skipping to change at page 44, line 38
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
16.2. Informative References 16.2. Informative References
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
2002, <https://www.rfc-editor.org/info/rfc3311>. 2002, <https://www.rfc-editor.org/info/rfc3311>.
 End of changes. 68 change blocks. 
331 lines changed or deleted 317 lines changed or added

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