< draft-ietf-mmusic-trickle-ice-sip-08.txt   draft-ietf-mmusic-trickle-ice-sip-09.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: January 22, 2018 Unaffiliated Expires: April 13, 2018 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
July 21, 2017 October 10, 2017
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-08 draft-ietf-mmusic-trickle-ice-sip-09
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). Session Initiation Protocol (SIP) and defines a new Info Package as
specified in [RFC6086].
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 http://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 January 22, 2018. This Internet-Draft will expire on April 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5 3.1. Discovery issues . . . . . . . . . . . . . . . . . . . . 5
3.2. Relationship with the Offer/Answer Model . . . . . . . . 6 3.2. Relationship with the Offer/Answer Model . . . . . . . . 6
4. Incremental Signaling of ICE candidates . . . . . . . . . . . 8 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7
4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 8 4.1. Initial Offer/Answer exchange . . . . . . . . . . . . . . 8
4.1.1. Asserting dialog state through reliable Offer/Answer 4.1.1. Sending the initial Offer . . . . . . . . . . . . . . 8
delivery . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Receiving the initial Offer . . . . . . . . . . . . . 9
4.1.2. Asserting dialog state through unreliable 4.1.3. Sending the initial Answer . . . . . . . . . . . . . 9
Offer/Answer delivery . . . . . . . . . . . . . . . . 9 4.1.4. Receiving the initial Answer . . . . . . . . . . . . 9
4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 11 4.2. Establishing the dialog . . . . . . . . . . . . . . . . . 9
4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 12 4.2.1. Asserting dialog state through reliable Offer/Answer
4.2. Delivering candidates in INFO messages . . . . . . . . . 14 delivery . . . . . . . . . . . . . . . . . . . . . . 9
5. Initial discovery of Trickle ICE support . . . . . . . . . . 18 4.2.2. Asserting dialog state through unreliable
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 19 Offer/Answer delivery . . . . . . . . . . . . . . . . 10
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19 4.2.3. Initiating Trickle ICE without an SDP Answer . . . . 12
5.3. Trickle ICE discovery through other protocols . . . . . . 20 4.2.4. Considerations for 3PCC . . . . . . . . . . . . . . . 14
5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 20 4.3. Delivering candidates in INFO messages . . . . . . . . . 15
5. Initial discovery of Trickle ICE support . . . . . . . . . . 19
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 20
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 20
5.3. Trickle ICE discovery through other protocols . . . . . . 21
5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 21
6. Considerations for RTP and RTCP multiplexing . . . . . . . . 23 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 23
7. Considerations for Media Multiplexing . . . . . . . . . . . . 24 7. Considerations for Media Multiplexing . . . . . . . . . . . . 24
8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 27 8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 27
8.1. Defintion . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Defintion . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. Offer/Answer procedures . . . . . . . . . . . . . . . . . 27 8.2. Offer/Answer procedures . . . . . . . . . . . . . . . . . 27
9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 28 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 28
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 30 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 30
skipping to change at page 3, line 13 skipping to change at page 3, line 18
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 31 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 31
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 31 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 31
10.5. Info Package Parameters . . . . . . . . . . . . . . . . 31 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 31
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 31 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 31
10.7. Info Message Body Parts . . . . . . . . . . . . . . . . 32 10.7. Info Message Body Parts . . . . . . . . . . . . . . . . 32
10.8. Info Package Usage Restrictions . . . . . . . . . . . . 32 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 32
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 32 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 32
10.10. Info Package Security Considerations . . . . . . . . . . 32 10.10. Info Package Security Considerations . . . . . . . . . . 32
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 32 11.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 32
11.2. application/trickle-ice-sdpfrag MIME Type . . . . . . . 33 11.2. application/trickle-ice-sdpfrag Media Type . . . . . . . 33
11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 35 11.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 35
11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 35 11.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 36
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.1. Normative References . . . . . . . . . . . . . . . . . . 38 15.1. Normative References . . . . . . . . . . . . . . . . . . 38
15.2. Informative References . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The Interactive Connectivity Establishment protocol The Interactive Connectivity Establishment protocol
[I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal [I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal
that consists of three main phases: a phase where an agent gathers a that consists of three main phases: a phase where an agent gathers a
set of candidate transport addresses (source IP address, port and set of candidate transport addresses (source IP address, port and
transport protocol), a second phase where these candidates are sent transport protocol), a second phase where these candidates are sent
to a remote agent and this gathering procedure is repeated and, to a remote agent. There, this gathering procedure is repeated and,
finally, a third phase where connectivity between all candidates in finally, a third phase starts where connectivity between all
both sets is checked (connectivity checks). Once these phases have candidates in both sets is checked (connectivity checks). Once these
been completed, and only then, can both agents begin communication. phases have been completed, and only then, both agents can begin
According to [I-D.ietf-mmusic-rfc5245bis] the three phases above communication. According to [I-D.ietf-mmusic-rfc5245bis] the three
happen consecutively, in a blocking way, which can introduce phases above happen consecutively, in a blocking way, which can
undesirable latency during session establishment. introduce undesirable latency during session establishment.
The Trickle ICE extension [I-D.ietf-ice-trickle] defines generic The Trickle ICE extension [I-D.ietf-ice-trickle] defines generic
semantics required for these ICE phases to happen simultaneously, in semantics required for these ICE phases to happen simultaneously, in
a non-blocking way and hence speed up session establishment. a non-blocking way and hence speed 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 incrementally exchanged with SIP INFO requests and how the are to be exchanged incrementally with SIP INFO requests [RFC6086]
Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle] and how the Half Trickle and Full Trickle modes defined in
are to be used by SIP User Agents (UAs) depending on their
expectations for support of Trickle ICE by a remote agent. [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
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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification makes use of all terminology defined by the This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in protocol for Interactive Connectivity Establishment in
[I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension
[I-D.ietf-ice-trickle]. It is assumed that the reader will be [I-D.ietf-ice-trickle]. It is assumed that the reader will be
familiar with the terminology from both documents. familiar with the terminology from both documents.
3. Protocol Overview 3. Protocol Overview
Using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the
candidates are exchanged solely using 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 to also 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
would send an INVITE request containing a subset of candidates. Once would send an INVITE request containing a subset of candidates. Once
an early dialog is established the Offerer can continue sending an early dialog is established the Offerer can continue sending
candidates in INFO requests within that dialog. candidates in INFO requests within that dialog.
Similarly, an Answerer can send ICE candidates using INFO messages Similarly, an Answerer can send ICE candidates using INFO requests
within the dialog established by its 18x provisional response. within the dialog established by its 18x provisional response.
Figure 1 shows such a sample exchange: Figure 1 shows such a sample exchange:
STUN/Turn STUN/TURN STUN/Turn STUN/TURN
Servers Alice Bob Servers Servers Alice Bob Servers
| | | | | | | |
| STUN Bi.Req. | INVITE (Offer) | | | STUN Bi.Req. | INVITE (Offer) | |
|<--------------|------------------------>| | |<--------------|------------------------>| |
| | 183 (Answer) | TURN Alloc Req | | | 183 (Answer) | TURN Alloc Req |
| STUN Bi.Resp. |<------------------------|--------------->| | STUN Bi.Resp. |<------------------------|--------------->|
skipping to change at page 5, line 25 skipping to change at page 5, line 25
| |<------------------------| | | |<------------------------| |
| | | | | | | |
| | More Cands & ConnChecks| | | | More Cands & ConnChecks| |
| |<=======================>| | | |<=======================>| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| |<------------------------| | | |<------------------------| |
| | ACK | | | | ACK | |
| |------------------------>| | | |------------------------>| |
| | | | | | | |
| | 5245 SIP re-INVITE | |
| |------------------------>| |
| | 200 OK | |
| |<------------------------| |
| | ACK | |
| |------------------------>| |
| | | |
| |<===== MEDIA FLOWS =====>| | | |<===== MEDIA FLOWS =====>| |
| | | | | | | |
Figure 1: Sample Trickle ICE scenario with SIP Figure 1: Sample Trickle ICE scenario with SIP
3.1. Discovery issues 3.1. Discovery issues
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,
skipping to change at page 7, line 30 skipping to change at page 7, line 30
| SIP INFO (more candidates) | | SIP INFO (more candidates) |
|----------------------------------------------------->| |----------------------------------------------------->|
| SIP INFO (more candidates) | | SIP INFO (more candidates) |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| STUN Binding Requests/Responses | | STUN Binding Requests/Responses |
|----------------------------------------------------->| |----------------------------------------------------->|
| STUN Binding Requests/Responses | | STUN Binding Requests/Responses |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| | | |
| | | |
| | 5245 SIP re-INVITE | |
| |--------------------->| |
| | 200 OK | |
| |<---------------------| |
Figure 2: Distinguishing between Trickle ICE and traditional Figure 2: Distinguishing between Trickle ICE and traditional
signaling. signaling.
From an architectural viewpoint, as displayed on Figure 2, exchanging From an architectural viewpoint, as displayed in Figure 2, exchanging
candidates through SIP INFO requests could be represented as candidates through SIP INFO requests could be represented as
signaling between ICE agents and not between Offer/Answer modules of signaling between ICE Agents and not between Offer/Answer modules of
SIP User Agents. Then, such INFO requests do not impact the state of SIP User Agents. Then, such INFO requests do not impact the state of
the Offer/Answer transaction other than providing additional the Offer/Answer transaction other than providing additional
candidates. Consequently, INFO requests are not considered Offers or candidates. Consequently, INFO requests are not considered Offers or
Answers. Nevertheless, candidates that have been exchanged using Answers. Nevertheless, candidates that have been exchanged using
INFO SHALL be included in subsequent Offers or Answers. The version INFO SHALL be included in subsequent Offers or Answers. The version
number in the "o=" line of that subsequent offer would need to be number in the "o=" line of that subsequent offer would need to be
incremented by 1 per the rules in [RFC3264]. incremented by 1 per the rules in [RFC3264].
4. Incremental Signaling of ICE candidates 4. Incremental Signaling of ICE candidates
Trickle ICE agents will construct Offers and Answers with ICE Trickle ICE Agents will construct Offers and Answers with ICE
descriptions compliant to [I-D.ietf-ice-trickle] and the following descriptions compliant to [I-D.ietf-ice-trickle] and the following
additional SIP-specific additions: additional SIP-specific additions:
1. Trickle ICE agents MUST indicate support for Trickle ICE by 1. Trickle ICE Agents MUST indicate support for Trickle ICE by
including the option-tag 'trickle-ice' in a SIP Supported: header including the SIP option-tag 'trickle-ice' in a SIP Supported:
field within all SIP INVITE requests and responses. header field within all SIP INVITE requests and responses.
2. Trickle ICE agents MAY exchange additional ICE candidates using 2. Trickle ICE Agents MUST indicate support for Trickle ICE by
including the ice-option 'trickle' within all SDP Offers and
Answers in accordance to [I-D.ietf-ice-trickle].
3. Trickle ICE Agents MAY include any number of ICE candidates, i.e.
from zero to the complete set of candidates, in their initial
Offer or Answer. If the complete candidate set is included
already in the initial Offer, this is called Half-Trickle.
4. Trickle ICE Agents MAY exchange additional ICE candidates using
INFO requests within an existing INVITE dialog usage (including INFO requests within an existing INVITE dialog usage (including
an early dialog) as specified in [RFC6086]. The INFO messages an early dialog) as specified in [RFC6086]. The INFO requests
carry an Info-Package: trickle-ice. Trickle ICE agents MUST be carry an Info-Package: trickle-ice. Trickle ICE Agents MUST be
prepared to receive INFO requests within that same dialog usage, prepared to receive INFO requests within that same dialog usage,
containing additional candidates or an indication for the end of containing additional candidates or an indication for the end of
such candidates such candidates.
3. Trickle ICE agents MAY exchange additional ICE candidates before 5. Trickle ICE Agents MAY exchange additional ICE candidates before
the Answerer has sent the Answer provided that an invite dialog the Answerer has sent the Answer provided that an invite dialog
usage is established at both Trickle ICE agents. Note that in usage is established at both Trickle ICE Agents. Note that in
case of forking multiple early dialogs will exist. case of forking multiple early dialogs will exist.
The following section provide further details on how Trickle ICE The following sections provide further details on how Trickle ICE
agents establish the INVITE dialog usage such that they can trickle Agents perform the initial Offers/Answers exchange and establish the
candidates. INVITE dialog usage such that they can trickle candidates.
4.1. Establishing the dialog 4.1. Initial Offer/Answer exchange
In order for SIP UAs to be able to start trickling, the following two 4.1.1. Sending the initial Offer
conditions need to be satisfied:
If the Offerer includes candidates in its initial Offer, it MUST
encode these candidates as specified in
[I-D.ietf-mmusic-ice-sip-sdp].
If the Offerer wants to send its initial Offer before knowing any
candidate of one or more media descriptions, it MUST include the
following default values in the corresponding "m=" line.
o The media field is set to 'audio'.
o The port value is set to '9'.
o The proto value is set to 'RTP/AVP'.
In any case, the Offerer MUST include the attribute a=ice-
options:trickle in accordance to [I-D.ietf-ice-trickle].
4.1.2. Receiving the initial Offer
If the initial Offer included candidates, the Answerer MUST treat
these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp].
If the initial Offer included the attribute a=ice-options:trickle,
the Answerer MUST be prepared for receiving trickled candidates later
on.
In case of a "m=" lines with default values neither of the eventually
trickled candidates will match the default destination. This
situation MUST NOT cause an ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]).
4.1.3. Sending the initial Answer
Section Section 4.1.1 applies to the Answerer with the roles of
Offerer and Answer being swapped.
4.1.4. Receiving the initial Answer
Section Section 4.1.2 applies to the Answerer with the roles of
Offerer and Answer being swapped.
4.2. Establishing the dialog
In order to be able to start trickling, the following two conditions
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 The dialog at both peers MUST be in early or confirmed state.
Section 5 discusses in detail the various options for satisfying the Section 5 discusses in detail the various options for satisfying the
first of the above conditions. Regardless of those mechanisms first of the above conditions. Regardless of those mechanisms,
however, agents are certain to have a clear understanding of whether however, agents are certain to have a clear understanding of whether
their peers support trickle ICE once an Offer and an Answer have been their peers support trickle ICE once an Offer and an Answer have been
exchanged, which also allows for ICE processing to commence (see exchanged, which also allows for ICE processing to commence (see
Figure 3). Figure 3).
4.1.1. Asserting dialog state through reliable Offer/Answer delivery 4.2.1. Asserting 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 9, line 28 skipping to change at page 10, line 28
| | | |
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|------------------------>| |------------------------>|
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|<------------------------| |<------------------------|
| | | |
Figure 3: SIP Offerer can freely trickle as soon as it receives an Figure 3: SIP Offerer can freely trickle as soon as it receives an
Answer. Answer.
Satisfying both conditions is also relatively trivial for ICE agents As shown in Figure 3 satisfying both conditions is relatively trivial
that have sent an Offer in an INVITE and that have received an Answer for ICE Agents that have sent an Offer in an INVITE and that have
in a reliable provisional response. It is guaranteed to have received an Answer in a reliable provisional response. It is
confirmed support for Trickle ICE within the Answerer (or lack guaranteed to have confirmed support for Trickle ICE at the Answerer
thereof) and to have fully initialized the SIP dialog at both ends. (or lack thereof) and to have fully initialized the SIP dialog at
Offerers and Answerers in the above situation can therefore freely both ends. Offerers and Answerers (after receipt of the PRACK
commence trickling within the newly established dialog. request) in the above situation can therefore freely commence
trickling within the newly established dialog.
4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 4.2.2. Asserting dialog state through unreliable Offer/Answer delivery
The situation is a bit more delicate for agents that have received an The situation is a bit more delicate for agents that have received an
Offer in an INVITE request and have sent an Answer in an unreliable Offer in an INVITE request and have sent an Answer in an unreliable
provisional response because, once the response has been sent, the provisional response because, once the response has been sent, the
Answerer does not know when or if it has been received (Figure 4). Answerer does not know when or if it has been received (Figure 4).
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
skipping to change at page 10, line 25 skipping to change at page 11, line 25
| |her dialog is already | | |her dialog is already |
| |in the early state. | | |in the early state. |
| | Can I send INFO??? | | | Can I send INFO??? |
| +----------------------+ | +----------------------+
| | | |
Figure 4: A SIP UA that sent an Answer in an unreliable provisional Figure 4: A SIP UA that sent an Answer in an unreliable provisional
response does not know if it was received and if the dialog at the response does not know if it was received and if the dialog at the
side of the Offerer has entered the early state side of the Offerer has entered the early state
In order to clear this ambiguity as soon as possible, the answerer In order to clear this ambiguity as soon as possible, the Answerer
needs to retransmit the provisional response with the exponential needs to retransmit the provisional response with the exponential
back-off timers described in [RFC3262]. These retransmissions MUST back-off timers described in [RFC3262]. These retransmissions MUST
cease on receipt of a INFO request or on transmission of the answer cease on receipt of an INFO request or on transmission of the answer
in a 2xx response. This is similar to the procedure described in in a 2xx response. This is similar to the procedure described in
section 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN
binding Request is replaced by the INFO request. binding Request is replaced by the INFO request.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for
version 14 of said I-D. Please cross-check 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 message 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) and/or they MAY when new candidates have not been learned since then) and/or they MAY
also deliver new candidates (if available). The Offerer MAY include also deliver newly learned candidates (if available). The Offerer
an end-of-candidates attribute in case candidate discovery has ended MAY include an end-of-candidates attribute in case candidate
in the mean time. discovery has ended in the mean time.
As soon as an Answerer has received such an INFO request, the As soon as an Answerer has received such an INFO request, the
Answerer has an indication that a dialog is established at both ends Answerer has an indication that a dialog is established at both ends
and MAY begin trickling (Figure 5). and MAY begin trickling (Figure 5).
Note: The +SRFLX in Figure 5 indicates that additionally newly Note: The +SRFLX in Figure 5 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 11, line 28 skipping to change at page 12, line 28
| INFO/OK (+SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|<------------------------| |<------------------------|
| | | |
| 200/ACK (Answer) | | 200/ACK (Answer) |
|<------------------------| |<------------------------|
Figure 5: A SIP UA that received an INFO request after sending an Figure 5: A SIP UA that received an INFO request after sending an
unreliable provisional response knows that the dialog at the side of unreliable provisional response knows that the dialog at the side of
the receiver has entered the early state the receiver has entered the early state
When sending the Answer in the 200 OK response, the Answerer MUST When sending the Answer in the 200 OK response to the INVITE request,
repeat exactly the same Answer that was previously sent in the the Answerer MUST repeat exactly the same Answer that was previously
unreliable provisional response in order to fulfill the corresponding sent in the unreliable provisional response in order to fulfill the
requirements in [RFC3264]. In other words, that Offerer needs to be corresponding requirements in [RFC3264]. Thus, the Offerer needs to
prepared to receive a different number of candidates in that repeated be prepared for receiving a different number of candidates in that
Answer than previously exchanged via trickling. repeated Answer than previously exchanged via trickling and MUST
ignore the candidate information in that 200 OK response.
4.1.3. Initiating Trickle ICE without an SDP Answer 4.2.3. Initiating Trickle ICE without an SDP Answer
The possibility to convey arbitrary candidates in INFO message bodies The possibility to convey arbitrary candidates in INFO message bodies
allows ICE agents to initiate trickling without actually sending an allows ICE Agents to initiate trickling without actually sending an
Answer. Trickle ICE Agents MAY therefore respond to an INVITE Answer. Trickle ICE Agents MAY therefore respond to an INVITE
request with provisional responses without an SDP Answer. Such request with provisional responses without an SDP Answer. Such
provisional responses serve for establishing an early dialog. provisional responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way, MUST Agents that choose to establish the dialog in this way, MUST
retransmit these responses with the exponential back-off timers retransmit these responses with the exponential back-off timers
described in [RFC3262]. 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 12.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
version 14 of said I-D. Please cross-check 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 (-) |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
skipping to change at page 12, line 31 skipping to change at page 13, line 38
| 183 (Answer) opt. | | 183 (Answer) opt. |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|<------------------------| |<------------------------|
| 200/ACK (Answer) | | 200/ACK (Answer) |
|<------------------------| |<------------------------|
Figure 6: A SIP UA sends an unreliable provisional response without Figure 6: A SIP UA sends an unreliable provisional response without
an Answer for establishing an early dialog an Answer for establishing an early dialog
When sending the Answer the agent MUST repeat all currently known and When sending the Answer, the agent MUST repeat all currently known
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. If that Answer was candidates since the last INFO request was sent. If that Answer was
sent in a unreliable provisional response, the Answerers MUST repeat sent in a unreliable provisional response, the Answerers MUST repeat
exactly the same Answer in the 200 OK response in order to fulfill exactly the same Answer in the 200 OK response to the INVITE request
the corresponding requirements in [RFC3264]. In other words, an in order to fulfill the corresponding requirements in [RFC3264]. In
Offerer needs to be prepared to receive fewer candidates in that case that trickling continued, an Offerer needs to be prepared for
repeated Answer than previously exchanged via trickling. receiving fewer candidates in that repeated Answer than previously
exchanged via trickling and MUST ignore the candidate information in
that 200 OK response.
4.1.4. Considerations for 3PCC 4.2.4. Considerations for 3PCC
Agents that have sent an Offer in a reliable provisional response and Agents that have sent an Offer in a reliable provisional response and
that receive an Answer in a PRACK are also in a situation where that receive an Answer in a PRACK are also in a situation where
support for Trickle ICE is confirmed and the SIP dialog is guaranteed support for Trickle ICE is confirmed and the SIP dialog is guaranteed
to be in a state that would allow in-dialog INFO requests (see to be in a state that would allow in-dialog INFO requests (see
Figure 7). Figure 7).
Alice Bob Alice Bob
| | | |
| INVITE | | INVITE |
skipping to change at page 13, line 35 skipping to change at page 14, line 43
|------------------------>| |------------------------>|
| 200 OK/ACK | | 200 OK/ACK |
|<------------------------| |<------------------------|
Figure 7: A SIP Offerer in a 3PCC scenario can also freely start Figure 7: A SIP Offerer in a 3PCC scenario can also freely start
trickling as soon as it receives an Answer. trickling as soon as it receives an Answer.
Trickle Agents that send an Offer in a 200 OK and receive an Answer Trickle Agents that send an Offer in a 200 OK and receive an Answer
in an ACK can still create a dialog and confirm support for Trickle in an ACK can still create a dialog and confirm support for Trickle
ICE by sending an unreliable provisional response similar to ICE by sending an unreliable provisional response similar to
Section 4.1.3. According to [RFC3261], this unreliable response MUST Section 4.2.3. According to [RFC3261], this unreliable response MUST
NOT contain an Offer. NOT contain an Offer.
The Trickle Agent (at the UAS) retransmits the provisional response The Trickle Agent (at the UAS) retransmits the provisional response
with the exponential back-off timers described in [RFC3262]. with the exponential back-off timers described in [RFC3262].
Retransmits MUST cease on receipt of a INFO request or on Retransmits MUST cease on receipt of an INFO request or on
transmission of the answer in a 2xx response. The peer Trickle Agent transmission of the answer in a 2xx response. The peer Trickle Agent
(at the UAC) MUST send a Trickle ICE INFO request as soon as they (at the UAC) MUST send a Trickle ICE INFO request as soon as they
receive an unreliable provisional response (see Figure 8). receive an unreliable provisional response (see Figure 8).
Alice Bob Alice Bob
| | | |
| INVITE | | INVITE |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
|<------------------------| |<------------------------|
skipping to change at page 14, line 34 skipping to change at page 15, line 34
| | | |
| 200 (Offer) | | 200 (Offer) |
|<------------------------| |<------------------------|
| ACK (Answer) | | ACK (Answer) |
|------------------------>| |------------------------>|
| | | |
Figure 8: A SIP UAC in a 3PCC scenario can also freely start Figure 8: A SIP UAC in a 3PCC scenario can also freely start
trickling as soon as it receives an unreliable provisional response. trickling as soon as it receives an unreliable provisional response.
4.2. Delivering candidates in INFO messages 4.3. Delivering candidates in INFO messages
Whenever new ICE candidates become available for sending, agents Whenever new ICE candidates become available for sending, agents
would encode them in "a=candidate" lines as described by would encode them in "a=candidate" lines as described by
[I-D.ietf-ice-trickle]. For example: [I-D.ietf-mmusic-ice-sip-sdp]. For example:
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998 raddr 10.0.1.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 MIME type for their payload MUST Package as defined Section 10. The Media Type [RFC6838] for their
be set to 'application/trickle-ice-sdpfrag' as defined in Section 9. payload MUST be set to 'application/trickle-ice-sdpfrag' as defined
in Section 9.
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
to which "m=" line a candidate belongs. Consequently, the receiving to which "m=" line a candidate belongs. Consequently, the receiving
agent MUST ignore any remaining content of the pseudo m-line, which agent MUST ignore any remaining content of the pseudo "m=" line,
is not defined in this document. This guarantees that the which is not defined in this document. This guarantees that the
'application/trickle-ice-sdpfrag' bodies do not interfere with the 'application/trickle-ice-sdpfrag' bodies do not interfere with the
Offer/Answer procedures as specified in [RFC3264]. 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
corresponding Offer or Answer. However, since Trickle-ICE might be "m=" line in the corresponding Offer or Answer. However, since
decoupled from the Offer/Answer negotiation this content might be Trickle-ICE might be decoupled from the Offer/Answer negotiation this
unknown to the agent. In this case, the agent MUST include the content might be unknown to the agent. In this case, the agent MUST
following default values. include the following default values.
o The media is set to 'audio'. o The media field is set to 'audio'.
o The port value is set to '9'. o The port value is set to '9'.
o The proto value is set to 'RTP/AVP'. o The proto value is set to 'RTP/AVP'.
o The fmt SHOULD appear only once and is set to '0' o The fmt SHOULD appear only once and is set to '0'
Agents MUST include a pseudo "m=" line and an identification tag in a Agents MUST include a pseudo "m=" line and an identification tag in a
"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. All the list of candidates for that specific "m=" line. All
"a=candidate" or "a=end-of-candidates" attributes following an "a=candidate" or "a=end-of-candidates" attributes following an
"a=mid:" attribute, up until (and excluding) the next occurrence of "a=mid:" attribute, up until (and excluding) the next occurrence of a
an "a=mid:" attribute, pertain to the "m=" line identified by that pseudo "m=" line, pertain to the "m=" line identified by that
identification tag. An "a=end-of-candidates" attribute, preceding identification tag. An "a=end-of-candidates" attribute, preceding
any "a=mid:" attributes, indicates the end of all trickling from that any pseudo "m=" line, indicates the end of all trickling from that
agent, as opposed to end of trickling for a specific "m=" line, which agent, as opposed to end of trickling for a specific "m=" line, which
would be indicated by a media level "a=end-of-candidates" attribute. would be indicated by a media level "a=end-of-candidates" attribute.
The use of "a=mid:" attributes allows for a structure similar to the Refer to Figure 9 for an example of the INFO request content.
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 "a=mid:" attributes are considered to be session-level. preceding any pseudo "m=" line are considered to be session-level.
Lines appearing in between or after "a=mid:" attributes 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, using 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 would allow mapping them to a specific ICE attributes that would allow mapping them to a specific ICE
generation. An agent MUST discard any received INFO requests generation. An agent MUST discard any received INFO requests
containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not
match those of the current ICE Negotiation Session. match those of the current ICE Negotiation Session.
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
same level as the ones in the Offer/Answer exchange. In other words, same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes, they will also if they were present as session-level attributes, they will also
appear at the beginning of all INFO message payloads, i.e. preceding appear at the beginning of all INFO request payloads, i.e. preceding
all "a=mid:" attributes. 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
they will also be included in INFO message payloads, following the they will also be included in INFO request payloads following the
corresponding "a=mid:" attribute. 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
skipping to change at page 16, line 48 skipping to change at page 17, line 51
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.
When receiving INFO requests carrying any candidates, agents will When receiving INFO requests carrying any candidates, agents will
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. Two candidates are the Offer/Answer exchange preceding them. Two candidates are
considered to be equal if their IP address port, transport and considered to be equal if their IP address port, transport and
component ID are the same. After identifying and discarding known component ID are the same. After identifying and discarding known
candidates, the agents MUST forward the actually new candidates to candidates, the agents MUST forward the actually new candidates to
the ICE agents in the same order as they were received in the INFO the ICE Agents in the same order as they were received in the INFO
request body. The ICE agents will then process the new candidates request body. The ICE Agents will then process the new candidates
according to the rules described in [I-D.ietf-ice-trickle]. according to the rules described in [I-D.ietf-ice-trickle].
Receiving an "a=end-of-candidates" attribute in a 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 of the peer agent that it current ICE generation - is an indication of 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 pseudo "m=" line. Handling of such applies only to the corresponding "m=" line. Handling of such end-
end-of-candidate indications is defined in [I-D.ietf-ice-trickle]. of-candidate indications is defined in [I-D.ietf-ice-trickle].
Note: At the time of writing this specification there were ongoing Note: At the time of writing this specification there were ongoing
discussions if a functionality for removing already exchanged discussions if a functionality for removing already exchanged
candidates would be useful. Such a functionality is out of the scope 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 this specification and most likely needs to be signaled by means
of a yet to be defined ICE extension, although it could in principle of a yet to be defined ICE extension, although it could in principle
be achieved quite easily, e.g. without anticipating any solution by be achieved quite easily, e.g. without anticipating any solution by
simply omitting a previously sent candidate from a subsequent INFO simply omitting a previously sent candidate from a subsequent INFO
message. However, if an implementation according to this request. However, if an implementation according to this
specification receives such an INFO message with a missing candidate specification receives such an INFO request with a missing candidate
it MAY treat that as an exceptional case. Implementing appropriate it MAY treat that as an exceptional case. Implementing appropriate
recovery procedures at the receiving side is RECOMMENDED for this recovery procedures at the receiving side is RECOMMENDED for this
situation. Ignoring that a candidate was missing might be a sensible situation. Ignoring that a candidate was missing might be a sensible
strategy. strategy.
The following example shows the content of one sample candidate The following example shows the content of one sample candidate
delivering INFO request: delivering INFO request:
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/sdp Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: ... Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:1 a=mid:1
a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host a=candidate:1 1 UDP 2130706431 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 2130706431 2001:db8:a0b:12f0::1 5001 typ host
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
skipping to change at page 18, line 33 skipping to change at page 19, line 33
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:2 a=mid:2
a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host
a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 9998 raddr 2001:db8:a0b:12f0::1 rport 9998
a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 9998 raddr 2001:db8:a0b:12f0::1 rport 9998
a=end-of-candidates a=end-of-candidates
Figure 9: 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 following attribute: "a=ice-options:trickle". and Answers using the following attribute: "a=ice-options:trickle".
This makes discovery fairly straightforward for Answerers or for This makes discovery fairly straightforward for Answerers or for
cases where Offers need to be generated within existing dialogs cases where Offers need to be generated within existing dialogs
(i.e., when sending re-INVITE requests). In both scenarios prior SDP (i.e., when sending re-INVITE requests). In both scenarios prior SDP
would have provided the necessary information. would have provided the necessary information.
Obviously, prior SDP is not available at the time a first Offer is Obviously, prior SDP is not available at the time a first Offer is
being constructed and it is therefore impossible for ICE agents to being constructed and it is therefore impossible for ICE Agents to
determine support for incremental provisioning that way. The determine support for incremental provisioning that way. The
following options are suggested as ways of addressing this issue. 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 likely from within the deployment will support Trickle ICE. This is likely
to be the case, for example, for WebRTC clients that will always be to be the case, for example, for WebRTC clients that will always be
communicating with other WebRTC clients or known Session Border communicating with other WebRTC clients or known Session Border
Controllers (SBC) with support for this specification. Controllers (SBC) with support for this specification.
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 GRUU 5.2. Trickle ICE discovery with 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. GRUU specific capabilities using, among others, OPTIONS requests. GRUU
support on the other hand allows SIP requests to be addressed to support on the other hand allows SIP requests to be addressed to
specific UAs (as opposed to arbitrary instances of an address of specific UAs (as opposed to arbitrary instances of an address of
record). Combining the two and using the "trickle-ice" option tag record). Combining the two and using the "trickle-ice" option tag
defined in Section 10.6 provides SIP UAs with a way of learning the defined in Section 10.6 provides SIP UAs with a way of learning the
capabilities of specific US instances and then addressing them capabilities of specific US instances and then addressing them
directly with INVITE requests that require SIP support. directly with INVITE requests that require SIP support.
Such targeted trickling may happen in different ways. One option Such targeted trickling may happen in different ways. One option
would be for a SIP UA to learn the GRUU instance ID of a peer through would be for a SIP UA to learn the GRUU instance ID of a peer through
presence and to then query its capabilities direction with an OPTIONS presence and to then query its capabilities direction with an OPTIONS
request. Alternately, it can also just send an OPTIONS request to request. Alternately, it can also just send an OPTIONS request to
the AOR it intends to contact and then inspect the returned the AOR it intends to contact and then inspect the returned
response(s) for support of both GRUU and Trickle ICE (Figure 9). response(s) for support of both GRUU and Trickle ICE (Figure 10).
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 20, line 26 skipping to change at page 21, line 26
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 183 (Answer) | | 183 (Answer) |
|<--------------------------------------------------| |<--------------------------------------------------|
| INFO/OK (Trickling) | | INFO/OK (Trickling) |
|<------------------------------------------------->| |<------------------------------------------------->|
| | | |
| ... | | ... |
| | | |
Figure 9: Trickle ICE support discovery with OPTIONS and GRUU Figure 10: 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. Trickle ICE discovery through other protocols 5.3. Trickle ICE discovery through other protocols
Protocols like XMPP [RFC6120] define advanced discovery mechanisms Protocols like XMPP [RFC6120] define advanced discovery mechanisms
that allow specific features to be queried priory to actually that allow specific features to be queried priory to actually
attempting to use them. Solutions like [RFC7081] define ways of attempting to use them. Solutions like [RFC7081] define ways of
using SIP and XMPP together which also provides a way for dual stack using SIP and XMPP together which also provides a way for dual stack
SIP+XMPP endpoints to make use of such features and verify Trickle SIP+XMPP endpoints to make use of such features and verify Trickle
ICE support for a specific SIP endpoint through XMPP. [TODO expand ICE support for a specific SIP endpoint through XMPP. However, such
on a specific way to do this or declare as out of scope] discovery mechanisms are out of the scope of this document.
5.4. Fall-back to Half Trickle 5.4. 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
the same way they would when using Vanilla ICE for SIP the same way they would when using ICE for SIP
[I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually
sending an Offer, agents would first gather ICE candidates in a sending an Offer, agents would first gather ICE candidates in a
blocking way and then send them all in that Offer. The blocking blocking way and then send them all in that Offer. The blocking
nature of the process would likely imply that some amount of latency nature of the process would likely imply that some amount of latency
will be accumulated and it is advised that agents try to anticipate will be accumulated and it is advised that agents try to anticipate
it where possible, like for example, when user actions indicate a it where possible, like for example, when user actions indicate a
high likelihood for an imminent call (e.g., activity on a keypad or a high likelihood for an imminent call (e.g., activity on a keypad or a
phone going off-hook). phone going off-hook).
Using Half Trickle would result in Offers that are compatible with Using Half Trickle would result in Offers that are compatible with
both Vanilla ICE SIP endpoints and legacy [RFC3264] endpoints. both ICE SIP endpoints and legacy [RFC3264] endpoints.
STUN/Turn STUN/TURN STUN/Turn STUN/TURN
Servers Alice Bob Servers Servers Alice Bob Servers
| | | | | | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
| | | | | | | |
| Candidate | | | | Candidate | | |
| | | | | | | |
| | | | | | | |
skipping to change at page 22, line 36 skipping to change at page 22, line 43
| | Connectivity Checks | | | | Connectivity Checks | |
| |<===========================>| Discovery | | |<===========================>| Discovery |
| | INFO (more candidates) | | | | INFO (more candidates) | |
| |<----------------------------| | | |<----------------------------| |
| | Connectivity Checks |<--------------| | | Connectivity Checks |<--------------|
| |<===========================>| | | |<===========================>| |
| | | | | | | |
| | 200 OK | | | | 200 OK | |
| |<----------------------------| | | |<----------------------------| |
| | | | | | | |
| | 5245 SIP re-INVITE | |
| |---------------------------->| |
| | 200 OK | |
| |<----------------------------| |
| | | |
| | | |
| |<======= MEDIA FLOWS =======>| | | |<======= MEDIA FLOWS =======>| |
| | | | | | | |
Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP Figure 11: 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 23, line 30 skipping to change at page 23, line 33
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 would have to send an offer compliant to While a Half Trickle Offerer would have 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, this flexibility allows a Full Trickle Offerer to all components, this flexibility allows a Full Trickle Offerer to
initially send only RTP candidates (component 1) if it assumes that initially send only RTP candidates (component 1) if it assumes that
RTCP multiplexing is supported by the Answerer. A Full Trickle RTCP multiplexing is supported by the Answerer. A Full Trickle
Offerer would need to start gathering and trickling RTCP candidates Offerer would need to start gathering and trickling RTCP candidates
(component 2) only after having received an indication in the answer (component 2) only after having received an indication in the answer
that the answerer unexpectedly does not support RTCP multiplexing. that the Answerer unexpectedly does not support RTCP multiplexing.
A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in
the application/trickle-ice-sdpfrag body it supports and uses RTP and the application/trickle-ice-sdpfrag body if it supports and uses RTP
RTCP multiplexing. Trickle answerer MUST follow the guidance on the and RTCP multiplexing. The Trickle Answerer MUST follow the guidance
usage of the "a=rtcp" attribute as given in on the usage of the "a=rtcp" attribute as given in
[I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the
Offerer in an INFO request prior to the Answer indicates that the Offerer in an INFO request prior to the Answer indicates that the
Answerer supports and uses RTP and RTCP multiplexing. The Offerer Answerer supports and uses RTP and RTCP multiplexing. The Offerer
can use this information e.g. for stopping gathering of RTCP can use this information e.g. for stopping gathering of RTCP
candidates and/or for freeing corresponding resources. candidates and/or for freeing corresponding resources.
This behavior is illustrated by the following example offer that This behavior is illustrated by the following example offer that
indicates support for RTP and RTCP multiplexing. indicates support for RTP and RTCP multiplexing.
v=0 v=0
skipping to change at page 24, line 17 skipping to change at page 24, line 17
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
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:1 a=mid:1
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
Once the dialog is established as described in section Section 4.1 Once the dialog is established as described in section Section 4.2
the Answerer sends the following INFO message. the Answerer sends the following INFO request.
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/sdp Content-type: application/sdp
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: ... Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:1 a=mid:1
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
This INFO message indicates that the Answerer supports and uses RTP This INFO request indicates that the Answerer supports and uses RTP
and RTCP multiplexing as well. This 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 message did not contain the a=rtcp-mux candidates. If the INFO request did not contain the a=rtcp-mux
attribute, the Offerer would have to gather RTCP candidates unless it attribute, the Offerer would have to gather RTCP candidates unless it
wants to wait until receipt of an Answer that eventually confirms wants to wait until receipt of an Answer that eventually confirms
support or non-support for RTP and RTCP multiplexing. support or non-support for RTP and RTCP multiplexing.
7. Considerations for Media Multiplexing 7. Considerations for Media Multiplexing
The following consideration describe options for Trickle-ICE in order The following considerations describe options for Trickle-ICE in
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].
ICE candidate exchange is already considered in section 11 of ICE candidate exchange is already considered in section 11 of
[I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are
still valid for Trickle ICE, however, trickling provides more still valid for Trickle ICE, however, trickling provides more
flexibility for the sequence of candidate exchange, especially in flexibility for the sequence of candidate exchange, especially in
Full Trickle mode. Full Trickle mode.
Except for bundle-only m-lines, a Half Trickle Offerer would have to Except for bundle-only "m=" lines, a Half Trickle Offerer would have
send an offer with candidates for all bundled m-lines. The to send an offer with candidates for all bundled "m=" lines. The
additional flexibility, however, allows a Full Trickle Offerer to additional flexibility, however, allows a Full Trickle Offerer to
initially send only candidates for the m-line with the suggested initially send only candidates for the "m=" line with the suggested
Offerer BUNDLE address. Offerer BUNDLE address.
Latest on receipt of the answer, the Offerer will detect if BUNDLE is Latest on receipt of the answer, the Offerer will detect if BUNDLE is
supported and if the suggested Offerer BUNDLE address was selected. supported by the Answerer and if the suggested Offerer BUNDLE address
In this case the Offerer does not need to trickle further candidates was selected. In this case, the Offerer does not need to trickle
for the remaining m-lines in a bundle. However, if BUNDLE is not further candidates for the remaining "m=" lines in a bundle.
supported, the Full Trickle Offerer needs to gather and trickle However, if BUNDLE is not supported, the Full Trickle Offerer needs
candidates for the remaining m-lines as necessary. If the answerer to gather and trickle candidates for the remaining "m=" lines as
selects a Offerer BUNDLE address different from suggested Offerer necessary. If the Answerer selects an Offerer BUNDLE address
BUNDLE address, the Full Trickle Offerer needs to gather and trickle different from the suggested Offerer BUNDLE address, the Full Trickle
candidates for the m-line that carries the selected Offerer BUNDLE Offerer needs to gather and trickle candidates for the "m=" line that
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] in the application/trickle-
ice-sdpfrag body if it supports and uses bundling. When doing so, ice-sdpfrag body if it supports and uses bundling. When doing so,
the Answerer MUST include all identification-tags in the same order the Answerer MUST include all identification-tags in the same order
that is used or will be used in the Answer. 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.
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
skipping to change at page 26, line 22 skipping to change at page 26, line 22
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=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
m=video 10002 RTP/AVP 31 m=video 10002 RTP/AVP 31
a=mid:bar a=mid:bar
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
Once the dialog is established as described in section Section 4.1 Once the dialog is established as described in section Section 4.2
the Answerer sends the following INFO message. the Answerer sends the following INFO request.
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/sdp Content-type: application/sdp
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: ... Content-length: ...
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
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:foo
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
m=audio 9 RTP/AVP 0 m=audio 9 RTP/AVP 0
a=mid:bar a=mid:bar
This INFO message indicates that the Answerer supports and uses Media This INFO request indicates that the Answerer supports and uses Media
Multiplexing as well. Note, that the second m-line shows the default Multiplexing as well. Note, that the second "m=" line shows the
values as specified in section Section 4.2, e.g. media set 'audio' default values as specified in section Section 4.3, e.g. media set
although 'video' was offered. The receiving ICE agents needs to 'audio' although 'video' was offered. The receiving ICE Agents MUST
ignore these default values in the pseudo m-lines. ignore these default values in the pseudo "m=" lines.
The INFO message also indicates that the Answerer accepted the The INFO request also indicates that the Answerer accepted the
suggested Offerer Bundle Address. This allows the Offerer to omit suggested Offerer Bundle Address. This allows the Offerer to omit
gathering of RTP and RTCP candidates for the other m-lines or gathering of RTP and RTCP candidates for the other "m=" lines or
releasing already gathered candidates. If the INFO message did not releasing already gathered candidates. If the INFO request did not
contain the a=group:BUNDLE attribute, the Offerer would have to contain the a=group:BUNDLE attribute, the Offerer would have to
gather RTP and RTCP candidates for the other m-lines unless it wants gather RTP and RTCP candidates for the other "m=" lines unless it
to wait until receipt of an Answer that eventually confirms support wants to wait until receipt of an Answer that eventually confirms
or non-support for Media Multiplexing. support or non-support for Media Multiplexing.
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 in the application/trickle-ice- Answerer, when putting attributes as specified in Section 9.2 in the
sdpfrag body. application/trickle-ice-sdpfrag body.
8. SDP 'end-of-candidate' Attribute 8. SDP 'end-of-candidate' Attribute
8.1. Defintion 8.1. Defintion
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-candidate'. 'end-of-candidate' is a attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' 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
skipping to change at page 28, line 7 skipping to change at page 28, line 7
The Offerer or Answerer MAY include an "a=end-of-candidates" The Offerer or Answerer MAY include an "a=end-of-candidates"
attribute in case candidate discovery has ended and no further attribute in case candidate discovery has ended and no further
candidates are to be trickled. The Offerer or Answerer MUST provide candidates are to be trickled. The Offerer or Answerer MUST provide
the "a=end-of-candidates" attribute together with the "a=ice-ufrag" the "a=end-of-candidates" attribute together with the "a=ice-ufrag"
and "a=ice-pwd" attributes of the current ICE generation as required and "a=ice-pwd" attributes of the current ICE generation as required
by [I-D.ietf-ice-trickle]. When included at session level this by [I-D.ietf-ice-trickle]. When included at session level this
indication applies to the whole session; when included at media level indication applies to the whole session; when included at media level
the indication applies only to the corresponding media description. the indication applies only to the corresponding media description.
Receipt of an "a=end-of-candidates attribute at an Offerer or Anwerer Receipt of an "a=end-of-candidates" attribute at an Offerer or
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the Anwerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching
current ICE generation - indicates that gathering of candidates has the current ICE generation - indicates that gathering of candidates
ended at the peer, either for the session or only for the has ended at the peer, either for the session or only for the
corresponding media description as specified above. The receiving corresponding media description as specified above. The receiving
agent forwards an end-of-candidates indication to the ICE Agent, agent forwards an end-of-candidates indication to the ICE Agent,
which in turn acts as specified in [I-D.ietf-ice-trickle]. which in turn acts as specified in [I-D.ietf-ice-trickle].
9. Content Type 'application/trickle-ice-sdpfrag' 9. Content Type 'application/trickle-ice-sdpfrag'
9.1. Overall Description 9.1. Overall Description
A application/trickle-ice-sdpfrag body is used by the Trickle-ICE A application/trickle-ice-sdpfrag body is used by the 'trickle-ice'
Info Package. It uses a subset of the possible SDP lines as defined Info Package. It uses a subset of the possible SDP lines as defined
by the grammar defined in [RFC4566]. A valid body uses only media by the grammar defined in [RFC4566]. A valid body uses only pseudo
descriptions and certain attributes that are needed and/or useful for "m=" lines and certain attributes that are needed and/or useful for
trickling candidates. The content adheres to the following grammar. trickling candidates. The content adheres to the following grammar.
9.2. Grammar 9.2. Grammar
The grammar of an 'application/trickle-ice-sdpfrag' body is based the The grammar of an 'application/trickle-ice-sdpfrag' body is based on
following ABNF [RFC5234]. It specifies the subset of existing SDP the following ABNF [RFC5234]. It specifies the subset of existing
attributes, that are needed or useful for trickling candidates. SDP attributes, that are needed or useful for trickling candidates.
The grammar uses the indicator for case-sensitivity %s is defined in
[RFC7405], but also imports grammars for other SDP attributes that
precede the production of that RFC. A sender SHOULD stick to lower-
case for such grammars, but a receiver SHOULD treat them case-
insensitive.
; 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 = [bundle-group-attribute CRLF]
[ice-lite-attribute CRLF] [ice-lite-attribute CRLF]
ice-pwd-attribute CRLF ice-pwd-attribute CRLF
ice-ufrag-attribute CRLF ice-ufrag-attribute CRLF
[ice-options-attribute CRLF] [ice-options-attribute CRLF]
[ice-pacing-attribute CRLF] [ice-pacing-attribute CRLF]
[end-of-candidates-attribute CRLF] [end-of-candidates-attribute CRLF]
extension-attribute-fields extension-attribute-fields
; for future extensions ; for future extensions
ice-lite-attribute = %s"a" "=" ice-lite ice-lite-attribute = %s"a" "=" ice-lite
ice-pwd-attribute = %s"a" "=" ice-pwd-att ice-pwd-attribute = %s"a" "=" ice-pwd-att
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
ice-pacing-attribute = %s"a" "=" ice-pacing-att ice-pacing-attribute = %s"a" "=" ice-pacing-att
ice-options-attribute = %s"a" "=" ice-options ice-options-attribute = %s"a" "=" ice-options
bundle-group-attribute = %s"a" "=" "group:" bundle-semantics bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
*(SP identification-tag) *(SP identification-tag)
bundle-semantics = "BUNDLE" bundle-semantics = "BUNDLE"
end-of-candidates-attribute = %s"a" "=" end-of-candidates end-of-candidates-attribute = %s"a" "=" end-of-candidates
end-of-candidates = "end-of-candidates" end-of-candidates = %s"end-of-candidates"
extension-attribute-fields = attribute-fields extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields trickle-ice-attribute-fields
[extension-attribute-fields] ) [extension-attribute-fields] )
; for future extensions ; for future extensions
trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF
[%s"a" "=" "rtcp-mux" CRLF] [%s"a" "=" %s"rtcp" CRLF]
[%s"a" "=" "rtcp-mux-only" CRLF] [%s"a" "=" %s"rtcp-mux" CRLF]
[%s"a" "=" %s"rtcp-mux-only" CRLF]
*(candidate-attributes CRLF) *(candidate-attributes CRLF)
[ice-pwd-attribute CRLF] [ice-pwd-attribute CRLF]
[ice-ufrag-attribute CRLF] [ice-ufrag-attribute CRLF]
[remote-candidate-attribute CRLF] [remote-candidate-attribute CRLF]
[end-of-candidates-attribute CRLF] [end-of-candidates-attribute CRLF]
remote-candidate-attribute = %s"a" "=" remote-candidate-att remote-candidate-attribute = %s"a" "=" remote-candidate-att
candidate-attributes = %s"a" "=" candidate-attribute candidate-attributes = %s"a" "=" candidate-attribute
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 indicator for case-sensitivity
%s is defined in [RFC7405]. [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal
grammar in their corresponding RFC and are reproduced here.
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 messages can be exchanged both ways with no been established, INFO messages can be exchanged both ways with no
skipping to change at page 30, line 39 skipping to change at page 30, line 42
Elevated risk of glare: The sequential nature of Offer/Answer also Elevated risk of glare: The sequential nature of Offer/Answer also
makes it impossible for both sides to send Offers simultaneously. makes it impossible for both sides to send Offers simultaneously.
What's worse is that there are no mechanisms in SIP to actually What's worse is that there are no mechanisms in SIP to actually
prevent that. [RFC3261], where the situation of Offers crossing prevent that. [RFC3261], where the situation of Offers crossing
on the wire is described as "glare", only defines a procedure for on the wire is described as "glare", only defines a procedure for
addressing the issue after it has occurred. According to that addressing the issue after it has occurred. According to that
procedure both Offers are invalidated and both sides need to retry procedure both Offers are invalidated and both sides need to retry
the negotiation after a period between 0 and 4 seconds. The high the negotiation after a period between 0 and 4 seconds. The high
likelihood for glare to occur and the average two second back-off likelihood for glare to occur and the average two second back-off
intervals would imply Trickle ICE processing duration would not intervals would imply Trickle ICE processing duration would not
only fail to improve but actually exceed those of Vanilla ICE. only fail to improve but actually exceed those of regular ICE.
INFO messages decouple the exchange of candidates from the Offer/ INFO messages decouple the exchange of candidates from the Offer/
Answer negotiation and are subject to none of the glare issues Answer negotiation and are subject to none of the glare issues
described above, which makes them a very convenient and lightweight described above, which makes them a very convenient and lightweight
mechanism for asynchronous delivery of candidates. mechanism for asynchronous delivery of candidates.
Using in-dialog INFO messages also provides a way of guaranteeing Using in-dialog INFO messages also provides a way of guaranteeing
that candidates are delivered end-to-end, between the same entities that candidates are delivered end-to-end, between the same entities
that are actually in the process of initiating a session. Out-of- that are actually in the process of initiating a session. Out-of-
dialog alternatives would have implied requiring support for Globally dialog alternatives would have implied requiring support for Globally
Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low
adoption levels, would have constituted too strong of constraint to adoption levels, would have constituted too strong of a constraint to
the adoption of Trickle ICE. the adoption of Trickle ICE.
10.2. Overall Description 10.2. Overall Description
This specification defines an Info Package for use by SIP user agents This specification defines an Info Package for use by SIP User Agents
implementing Trickle ICE. INFO requests carry ICE candidates implementing Trickle ICE. INFO requests carry ICE candidates
discovered after the peer user agents have confirmed mutual support discovered after the peer user agents have confirmed mutual support
for Trickle ICE. for Trickle ICE.
10.3. Applicability 10.3. Applicability
The purpose of the ICE protocol is to establish a media path in the The purpose of the ICE protocol is to establish a media path in the
presence of NAT and firewalls. The candidates are transported in presence of NAT and firewalls. The candidates are transported in
INFO requests and are part of this establishment. INFO requests and are part of this establishment.
Candidates sent by a Trickle ICE agent after the Offer, follow the Candidates sent by a Trickle ICE Agent after the Offer, follow the
same signaling path and reach the same entity as the Offer itself. same signaling path and reach the same entity as the Offer itself.
While it is true that GRUUs can be used to achieve this, one of the While it is true that GRUUs can be used to achieve this, one of the
goals of this specification is to allow operation of Trickle ICE in goals of this specification is to allow operation of Trickle ICE in
as many environments as possible including those without GRUU as many environments as possible including those without GRUU
support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
satisfy this goal. satisfy this goal.
10.4. Info Package Name 10.4. Info Package Name
This document defines a SIP Info Package as per [RFC6086]. The Info This document defines a SIP Info Package as per [RFC6086]. The Info
skipping to change at page 32, line 20 skipping to change at page 32, line 24
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
A Trickle ICE Agent with many network interfaces might create a high A Trickle ICE Agent with many network interfaces might create a high
rate of INFO requests if every newly detected candidate is trickled rate of INFO requests if every newly detected candidate is trickled
individually without aggregation. Implementor that are concerned individually without aggregation. Implementors that are concerned
about loss of packets in such a case might consider aggregating ICE about loss of packets in such a case might consider aggregating ICE
candidates and sending INFOS only at some configurable intervals. candidates and sending INFOs only at some configurable intervals.
10.10. Info Package Security Considerations 10.10. Info Package Security Considerations
See Section 12 See Section 12
11. IANA Considerations 11. 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. ]
skipping to change at page 33, line 28 skipping to change at page 33, line 28
the 'end-of-candidate' attribute. the 'end-of-candidate' attribute.
Mux Category: IDENTICAL Mux Category: IDENTICAL
Reference: RFCXXXX Reference: RFCXXXX
Example: Example:
a=end-of-candidate a=end-of-candidate
11.2. application/trickle-ice-sdpfrag MIME Type 11.2. application/trickle-ice-sdpfrag Media Type
Type name: application Type name: application
Subtype name: trickle-ice-sdpfrag Subtype name: trickle-ice-sdpfrag
Required parameters: None. Required parameters: None.
Optional parameters: None. Optional parameters: None.
Encoding considerations: Encoding considerations:
skipping to change at page 34, line 15 skipping to change at page 34, line 15
See [RFC4566]) and RFCXXXX See [RFC4566]) and RFCXXXX
Interoperability considerations: Interoperability considerations:
See RFCXXXX See RFCXXXX
Published specification: Published specification:
See RFCXXXX See RFCXXXX
Applications which use this media type: Applications which use this Media Type:
Voice over IP, video teleconferencing, streaming media, instant Voice over IP, video teleconferencing, streaming media, instant
messaging, Trickle-ICE among others. messaging, Trickle-ICE among others.
Fragment identifier considerations: N/A
Additional information: Additional information:
Magic number(s): none Magic number(s): N/A
File extension(s): none File extension(s): N/A
Macintosh File Type Code(s): none Macintosh File Type Code(s): N/A
Person and email address to contact for further information: Person and email address to contact for further information:
IETF MMUSIC working group mmusic@ietf.org IETF MMUSIC working group mmusic@ietf.org
Intended usage: Intended usage:
Trickle-ICE for SIP as specified in RFCXXXX. Trickle-ICE for SIP as specified in RFCXXXX.
Restrictions on usage: N/A
Author/Change controller: Author/Change controller:
IETF MMUSIC working group mmusic@ietf.org IETF MMUSIC working group mmusic@ietf.org
Provisional registration? (standards tree only): N/A
11.3. SIP Info Package 'trickle-ice' 11.3. SIP Info Package 'trickle-ice'
This document defines a new SIP Info Package named 'trickle-ice' and This document defines a new SIP Info Package named 'trickle-ice' and
updates the Info Packages Registry with the following entry. updates the Info Packages Registry with the following entry.
+-------------+-----------+ +-------------+-----------+
| Name | Reference | | Name | Reference |
+-------------+-----------+ +-------------+-----------+
| trickle-ice | [RFCXXXX] | | trickle-ice | [RFCXXXX] |
| | | | | |
skipping to change at page 35, line 35 skipping to change at page 35, line 39
| 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. | |
+-------------+-------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
12. Security Considerations 12. Security Considerations
The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp],
[RFC6086], [I-D.ietf-ice-trickle] apply. This document clarifies how [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies
the above specifications are used together for trickling candidates how the above specifications are used together for trickling
and does not create addtitional security risks. candidates and does not create addtitional security risks.
13. Acknowledgements 13. Acknowledgements
The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan The authors would like to thank Flemming Andreasen, Ayush Jain, Paul
Lennox, Simon Perreault and Martin Thomson for reviewing and/or Kyzivat, Jonathan Lennox, Simon Perreault and Martin Thomson for
making various suggestions for improvements and optimizations. reviewing and/or making various suggestions for improvements and
optimizations.
14. Change Log 14. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing]. [RFC EDITOR NOTE: Please remove this section when publishing].
Changes from draft-ietf-mmusic-trickle-ice-sip-01 Changes from draft-ietf-mmusic-trickle-ice-sip-01
o Editorial Clean up o Editorial Clean up
o IANA Consideration added o IANA Consideration added
skipping to change at page 38, line 17 skipping to change at page 38, line 17
o clarification on ordering of candidates for alignment with draft- o clarification on ordering of candidates for alignment with draft-
ietf-ice-trickle-12 ietf-ice-trickle-12
o O/A procedures for end-of-candidates attribute described here o O/A procedures for end-of-candidates attribute described here
after corresponding procedures have been removed from draft-ietf- after corresponding procedures have been removed from draft-ietf-
ice-trickle-11 ice-trickle-11
o using IPv6 addresses in examples o using IPv6 addresses in examples
Changes from draft-ietf-mmusic-trickle-ice-sip-08
o editorial fixes/clarification based on Flemmings review
o Description of Trickle specifics in O/A procedures for initial O/A
exchange and specification of ICE mismatch exception
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-13 (work in progress), Protocol", draft-ietf-ice-trickle-14 (work in progress),
July 2017. September 2017.
[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., Keranen, A., and S. Nandakumar,
"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-13 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-14 (work in
progress), June 2017. progress), October 2017.
[I-D.ietf-mmusic-mux-exclusive] [I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux- Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-12 (work in progress), May 2017. exclusive-12 (work in progress), May 2017.
[I-D.ietf-mmusic-rfc5245bis] [I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-mmusic- Translator (NAT) Traversal", draft-ietf-mmusic-
rfc5245bis-05 (work in progress), September 2015. rfc5245bis-05 (work in progress), September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-38 (work in progress), April 2017. negotiation-39 (work in progress), August 2017.
[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-16
(work in progress), December 2016. (work in progress), December 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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,
<http://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<http://www.rfc-editor.org/info/rfc3262>. <https://www.rfc-editor.org/info/rfc3262>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <https://www.rfc-editor.org/info/rfc3264>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003, DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>. <https://www.rfc-editor.org/info/rfc3605>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <https://www.rfc-editor.org/info/rfc5761>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <https://www.rfc-editor.org/info/rfc5888>.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
<http://www.rfc-editor.org/info/rfc6086>. <https://www.rfc-editor.org/info/rfc6086>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<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,
<http://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
15.2. Informative References 15.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, <http://www.rfc-editor.org/info/rfc3311>. 2002, <https://www.rfc-editor.org/info/rfc3311>.
[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,
<http://www.rfc-editor.org/info/rfc3840>. <https://www.rfc-editor.org/info/rfc3840>.
[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,
<http://www.rfc-editor.org/info/rfc5627>. <https://www.rfc-editor.org/info/rfc5627>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <http://www.rfc-editor.org/info/rfc6120>. March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX:
Combined Use of the Session Initiation Protocol (SIP) and Combined Use of the Session Initiation Protocol (SIP) and
the Extensible Messaging and Presence Protocol (XMPP)", the Extensible Messaging and Presence Protocol (XMPP)",
RFC 7081, DOI 10.17487/RFC7081, November 2013, RFC 7081, DOI 10.17487/RFC7081, November 2013,
<http://www.rfc-editor.org/info/rfc7081>. <https://www.rfc-editor.org/info/rfc7081>.
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
 End of changes. 142 change blocks. 
248 lines changed or deleted 336 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/