draft-ietf-mmusic-trickle-ice-sip-13.txt   draft-ietf-mmusic-trickle-ice-sip-14.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 25, 2018 Unaffiliated Expires: August 27, 2018 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
February 21, 2018 February 23, 2018
A Session Initiation Protocol (SIP) Usage for Trickle ICE A Session Initiation Protocol (SIP) Usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-13 draft-ietf-mmusic-trickle-ice-sip-14
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 46 skipping to change at page 1, line 46
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 25, 2018. This Internet-Draft will expire on August 27, 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 36 skipping to change at page 2, line 36
3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6
4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7
4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8 4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8
4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 8 4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 8
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.3.4. Considerations for Third Party Call Control . . . . . 15
4.4. Delivering Candidates in INFO Requests . . . . . . . . . 17 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 17
5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 22 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 22
5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 URIs (GRUU) . . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 23 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . 29
8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 30 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 30
9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 30 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 30
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 30 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 30
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32
skipping to change at page 3, line 29 skipping to change at page 3, line 29
12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35
12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36
12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38
12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38
13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
16.1. Normative References . . . . . . . . . . . . . . . . . . 43 16.1. Normative References . . . . . . . . . . . . . . . . . . 43
16.2. Informative References . . . . . . . . . . . . . . . . . 45 16.2. Informative References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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. There, the gathering procedure is repeated and remote agent within the Session Description Protocol (SDP) body of a
candidates are sent to the first agent. Finally, a third phase SIP message. At the remote agent the gathering procedure is repeated
and candidates are sent to the first agent. Finally, a third phase
starts where connectivity between all candidates in both sets is starts where connectivity between all candidates in both sets is
checked (connectivity checks). Once these phases have been checked (connectivity checks). Once these phases have been
completed, and only then, both agents can begin communication. 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
skipping to change at page 4, line 30 skipping to change at page 4, line 32
"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
for Interactive Connectivity Establishment in for Interactive Connectivity Establishment in
[I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension [I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension
[I-D.ietf-ice-trickle]. It is assumed that the reader is familiar [I-D.ietf-ice-trickle]. It is assumed that the reader is familiar
with the terminology from both documents. with the terminology from both documents.
[I-D.ietf-ice-rfc5245bis] also describes how ICE makes use of the
Session Traversal Utilities for NAT (STUN) protocol [RFC5389] and its
extension Traversal Using Relay NAT (TURN) [RFC5766].
3. Protocol Overview 3. Protocol Overview
When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the
the ICE candidates are exchanged solely via SDP Offer/Answer as per ICE candidates are exchanged solely via SDP Offer/Answer as per
[RFC3264]. This specification defines an additional mechanism where [RFC3264]. This specification defines an additional mechanism where
candidates can be exchanged using SIP INFO messages and a newly candidates can be exchanged using SIP INFO messages and a newly
defined Info Package [RFC6086]. This allows ICE candidates also to defined Info Package [RFC6086]. This allows ICE candidates also to
be sent in parallel to an ongoing Offer/Answer negotiation and/or be sent in parallel to an ongoing Offer/Answer negotiation and/or
after the 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
sends an INVITE request containing a subset of candidates. Once an sends an INVITE request containing a subset of candidates. Once an
early dialog is established the Offerer can continue sending early dialog is established the Offerer can continue sending
candidates in INFO requests within that dialog. candidates in INFO requests within that dialog.
skipping to change at page 5, line 44 skipping to change at page 5, line 48
In order to benefit from Trickle ICE's full potential and reduce In order to benefit from Trickle ICE's full potential and reduce
session establishment latency to a minimum, Trickle ICE agents need session establishment latency to a minimum, Trickle ICE agents need
to generate SDP Offers and Answers that contain incomplete, to generate SDP Offers and Answers that contain incomplete,
potentially empty sets of candidates. Such Offers and Answers can potentially empty sets of candidates. Such Offers and Answers can
only be handled meaningfully by agents that actually support only be handled meaningfully by agents that actually support
incremental candidate provisioning, which implies the need to confirm incremental candidate provisioning, which implies the need to confirm
such support before using it. such support before using it.
Contrary to other protocols, where "in advance" capability discovery Contrary to other protocols, where "in advance" capability discovery
is widely implemented, the mechanisms that allow this for SIP (i.e., is widely implemented, the mechanisms that allow this for SIP (i.e.,
a combination of UA Capabilities [RFC3840] and GRUU [RFC5627]) have a combination of UA Capabilities [RFC3840] and Globally Routable User
only seen low levels of adoption. This presents an issue for Trickle Agent URIs (GRUU) [RFC5627]) have only seen low levels of adoption.
ICE implementations as SIP UAs do not have an obvious means of This presents an issue for Trickle ICE implementations as SIP UAs do
verifying that their peer will support incremental candidate not have an obvious means of verifying that their peer will support
provisioning. incremental 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, specification [I-D.ietf-ice-trickle] provides one way around this, by
by requiring the first Offer to contain a complete set of local ICE requiring the first Offer to contain a complete set of local ICE
candidates and only using incremental provisioning of remote candidates and only using incremental provisioning of remote
candidates for the rest of the session. 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
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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 requests SHALL be included in subsequent Offers or Answers. The INFO requests SHALL be included in subsequent Offers or Answers. The
version number in the "o=" line of that subsequent Offer needs to be version number in the "o=" line of that subsequent Offer needs 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 exchange ICE descriptions compliant to Trickle ICE Agents will exchange ICE descriptions compliant to
[I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO [I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO
request bodies. This requires the following SIP-specific extensions: request bodies. This requires the following SIP-specific extensions:
1. Trickle ICE Agents MUST indicate support for Trickle ICE by 1. Trickle ICE Agents MUST indicate support for Trickle ICE by
including the SIP option-tag 'trickle-ice' in a SIP Supported: including the SIP option-tag 'trickle-ice' in a SIP Supported:
header field within all SIP INVITE requests and responses. header field within all SIP INVITE requests and responses.
2. Trickle ICE Agents MUST indicate support for Trickle ICE by 2. Trickle ICE Agents MUST indicate support for Trickle ICE by
including the ice-option 'trickle' within all SDP Offers and including the ice-option 'trickle' within all SDP Offers and
Answers in accordance to [I-D.ietf-ice-trickle]. Answers in accordance to [I-D.ietf-ice-trickle].
skipping to change at page 9, line 10 skipping to change at page 9, line 10
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 ::.
In this case, the Offerer obviously cannot know the RTCP transport In this case, the Offerer obviously cannot know the RTCP transport
address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086].
This avoids potential ICE mismatch (see This avoids potential ICE mismatch (see
[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].
4.1.2. Receiving the Initial Offer 4.1.2. Receiving the Initial Offer
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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 ::.
In this case, the Answerer obviously cannot know the RTCP transport In this case, the Answerer obviously cannot know the RTCP transport
address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086].
This avoids potential ICE mismatch (see This avoids potential ICE mismatch (see
[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 Answerer accepts to use RTCP multiplexing [RFC5761] and/or If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or
exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will
include the "a=rtcp-mux" attribute in the initial Answer. include the "a=rtcp-mux" attribute in the initial Answer.
In any case, the Answerer MUST include the attribute "a=ice- In any case, the Answerer 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].
4.1.4. Receiving the Initial Answer 4.1.4. Receiving the Initial Answer
skipping to change at page 11, line 12 skipping to change at page 11, line 12
o The dialog at both peers 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.3.1. Establishing Dialog State through Reliable Offer/Answer delivery 4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| PRACK/OK | | PRACK/OK |
|------------------------>| |------------------------>|
| | | |
skipping to change at page 14, line 21 skipping to change at page 14, line 21
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 or on transmission of the Answer in a 2xx
response. This is again similar to the procedure described in response. This is again similar to the procedure described in
section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer
is not yet provided. is not yet provided.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for
version 16 of said I-D. Authors need to cross-check during Auth48 version 16 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
skipping to change at page 16, line 9 skipping to change at page 16, line 9
several signaling variants as described in [RFC3725]. We give several signaling variants as described in [RFC3725]. We give
specific consideration for 3PCC that starts with an offerless INVITE specific consideration for 3PCC that starts with an offerless INVITE
request [RFC3261]. As specified in Section 4 this offerless INVITE request [RFC3261]. As specified in Section 4 this offerless INVITE
MUST include the SIP option-tag 'trickle-ice' in a SIP Supported: MUST include the SIP option-tag 'trickle-ice' in a SIP Supported:
header field in order to indicate support for Trickle-ICE to the 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 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 to send its Offer in a reliable provisional response [RFC3262] or in
the 200 OK response to the INVITE request. the 200 OK response to the INVITE request.
Agents that had sent an Offer in a reliable provisional response and 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 that received an Answer in a PRACK request [RFC3262] are also in a
situation where support for Trickle ICE is confirmed and the SIP situation where support for Trickle ICE is confirmed and the SIP
dialog is guaranteed to be in a state that allows in-dialog INFO dialog is guaranteed to be in a state that allows in-dialog INFO
requests (see Figure 7). requests (see Figure 7).
Alice Bob Alice Bob
| | | |
| INVITE | | INVITE |
|------------------------>| |------------------------>|
| 183 (Offer) | | 183 (Offer) |
|<------------------------| |<------------------------|
skipping to change at page 18, line 9 skipping to change at page 18, line 9
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 and identification tags in "a=mid:" attributes as defined in
[RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in [RFC4566], but provide no semantics other than indicating defined in [RFC4566], but provide no semantics other than indicating
skipping to change at page 19, line 31 skipping to change at page 19, line 31
preceding any pseudo "m=" line are considered to be session-level. preceding any pseudo "m=" line are considered to be session-level.
Lines appearing in between or after pseudo "m=" lines will be 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 Consequently, 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 allows 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 all pseudo "m=" lines. If they were originally exchanged as media
level attributes, potentially overriding session-level values, then level attributes, potentially overriding session-level values, then
skipping to change at page 22, line 35 skipping to change at page 22, line 35
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.
5.2. Trickle ICE Discovery with Globally Routable User Agent URIs 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs
(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 Globally Routable User Agent URIs (GRUU) according to [RFC5627] for GRUU according to [RFC5627] on the other hand allows SIP requests
on the other hand allows SIP requests to be addressed to specific UAs to be addressed to specific UAs (as opposed to arbitrary instances of
(as opposed to arbitrary instances of an address of record). an address of record). Combining the two and using the "trickle-ice"
Combining the two and using the "trickle-ice" option tag defined in option tag defined in Section 10.6 provides SIP UAs with a way of
Section 10.6 provides SIP UAs with a way of learning the capabilities learning the capabilities of specific SIP UA instances and then
of specific SIP UA instances and then addressing them directly with addressing them directly with INVITE requests that require Trickle
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 AOR it intends to contact and then inspect the returned the Address of Record (AOR) it intends to contact and then inspect
response(s) for support of both GRUU and Trickle ICE (Figure 10). It the returned response(s) for support of both GRUU and Trickle ICE
is noted that using the GRUU means that the INVITE request can go (Figure 10). It is noted that using the GRUU means that the INVITE
only to that particular device. This prevents the use of forking for request can go only to that particular device. This prevents the use
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;... |
|<--------------------------------------------------| |<--------------------------------------------------|
skipping to change at page 25, line 5 skipping to change at page 25, line 5
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
to give some guidance to implementors on how trickling can be to give some guidance to implementors on how trickling can be
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 15 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
skipping to change at page 29, line 30 skipping to change at page 29, line 30
Independent of using Full Trickle or Half Trickle mode, the rules Independent of using Full Trickle or Half Trickle mode, the rules
from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and
Answerer, when putting attributes as specified in Section 9.2 in the Answerer, when putting attributes as specified in Section 9.2 in the
application/trickle-ice-sdpfrag body. application/trickle-ice-sdpfrag body.
8. SDP 'end-of-candidates' Attribute 8. SDP 'end-of-candidates' Attribute
8.1. Definition 8.1. Definition
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
property attribute [RFC4566], and hence has no value. By including property attribute [RFC4566], and hence has no value. By including
this attribute in an Offer or Answer the sending agent indicates that this attribute in an Offer or Answer the sending agent indicates that
it will not trickle further candidates. When included at session it will not trickle further candidates. When included at session
level this indication applies to the whole session, when included at level this indication applies to the whole session, when included at
media level the indication applies only to the corresponding media media level the indication applies only to the corresponding media
description. description.
Name: end-of-candidates Name: end-of-candidates
Value: N/A Value: N/A
skipping to change at page 35, line 29 skipping to change at page 35, line 29
understand the INFO request body. 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
property attribute [RFC4566] , and hence has no value. property attribute [RFC4566] , and hence has no value.
Name: end-of-candidates Name: end-of-candidates
Value: N/A Value: N/A
Usage Level: media and session Usage Level: media and session
Charset Dependent: no Charset Dependent: no
Purpose: The sender indicates that it will not trickle Purpose: The sender indicates that it will not trickle
skipping to change at page 38, line 32 skipping to change at page 38, line 32
+-------------+-----------+ +-------------+-----------+
| Name | Reference | | Name | Reference |
+-------------+-----------+ +-------------+-----------+
| trickle-ice | [RFCXXXX] | | trickle-ice | [RFCXXXX] |
| | | | | |
+-------------+-----------+ +-------------+-----------+
12.4. SIP Option Tag 'trickle-ice' 12.4. SIP Option Tag 'trickle-ice'
This specification registers a new SIP option tag 'trickle-ice' as This specification registers a new SIP option tag 'trickle-ice' as
per the guidelines in Section 27.1 of [RFC3261] and updates the per the guidelines in Section 27.1 of [RFC3261] and updates the
"Option Tags" section of the SIP Parameter Registry with the "Option Tags" section of the SIP Parameter Registry with the
following entry: following entry:
+-------------+-------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+-------------+-------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
| trickle-ice | This option tag is used to indicate | [RFCXXXX] | | trickle-ice | This option tag is used to indicate | [RFCXXXX] |
| | that a UA supports and understands | | | | that a UA supports and understands | |
| | Trickle-ICE. | | | | Trickle-ICE. | |
+-------------+-------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
skipping to change at page 43, line 4 skipping to change at page 43, line 4
o Added Deployment Considerations section o Added Deployment Considerations section
o Fixed ref for rfc5245bis o Fixed ref for rfc5245bis
Changes from draft-ietf-mmusic-trickle-ice-sip-12 Changes from draft-ietf-mmusic-trickle-ice-sip-12
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
o added expansions for SDP,GRUU, AOR, STUN, TURN
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-17 (work in progress), February 2018.
skipping to change at page 45, line 36 skipping to change at page 45, line 41
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
<https://www.rfc-editor.org/info/rfc3725>. <https://www.rfc-editor.org/info/rfc3725>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004, DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/rfc3840>. <https://www.rfc-editor.org/info/rfc3840>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
<https://www.rfc-editor.org/info/rfc5627>. <https://www.rfc-editor.org/info/rfc5627>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>.
Authors' Addresses Authors' Addresses
Emil Ivov Emil Ivov
Jitsi Jitsi
Strasbourg 67000 Strasbourg 67000
France France
Phone: +33 6 72 81 15 55 Phone: +33 6 72 81 15 55
Email: emcho@jitsi.org Email: emcho@jitsi.org
Thomas Stach Thomas Stach
Unaffiliated Unaffiliated
Vienna 1130 Vienna 1130
Austria Austria
Email: thomass.stach@gmail.com Email: thomass.stach@gmail.com
Enrico Marocco Enrico Marocco
Telecom Italia Telecom Italia
Via G. Reiss Romoli, 274 Via G. Reiss Romoli, 274
 End of changes. 32 change blocks. 
45 lines changed or deleted 68 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/