draft-ietf-mmusic-trickle-ice-sip-12.txt   draft-ietf-mmusic-trickle-ice-sip-13.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: June 25, 2018 Unaffiliated Expires: August 25, 2018 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
December 22, 2017 February 21, 2018
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) Usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-12 draft-ietf-mmusic-trickle-ice-sip-13
Abstract Abstract
The Interactive Connectivity Establishment (ICE) protocol describes a The Interactive Connectivity Establishment (ICE) protocol describes a
Network Address Translator (NAT) traversal mechanism for UDP-based Network Address Translator (NAT) traversal mechanism for UDP-based
multimedia sessions established with the Offer/Answer model. The ICE multimedia sessions established with the Offer/Answer model. The ICE
extension for Incremental Provisioning of Candidates (Trickle ICE) extension for Incremental Provisioning of Candidates (Trickle ICE)
defines a mechanism that allows ICE Agents to shorten session defines a mechanism that allows ICE Agents to shorten session
establishment delays by making the candidate gathering and establishment delays by making the candidate gathering and
connectivity checking phases of ICE non-blocking and by executing connectivity checking phases of ICE non-blocking and by executing
them in parallel. them in parallel.
This document defines usage semantics for Trickle ICE with the This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP) and defines a new SIP Info Package. Session Initiation Protocol (SIP) and defines a new SIP Info Package
to support this usage.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 25, 2018. This Internet-Draft will expire on August 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . 7 4. Incremental Signaling of ICE candidates . . . . . . . . . . . 7
4.1. Initial Offer/Answer exchange . . . . . . . . . . . . . . 8 4.1. Initial Offer/Answer Exchange . . . . . . . . . . . . . . 8
4.1.1. Sending the initial Offer . . . . . . . . . . . . . . 8 4.1.1. Sending the Initial Offer . . . . . . . . . . . . . . 8
4.1.2. Receiving the initial Offer . . . . . . . . . . . . . 9 4.1.2. Receiving the Initial Offer . . . . . . . . . . . . . 9
4.1.3. Sending the initial Answer . . . . . . . . . . . . . 9 4.1.3. Sending the Initial Answer . . . . . . . . . . . . . 9
4.1.4. Receiving the initial Answer . . . . . . . . . . . . 10 4.1.4. Receiving the Initial Answer . . . . . . . . . . . . 10
4.2. Subsequent Offer/Answer exchanges . . . . . . . . . . . . 10 4.2. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . 10
4.3. Establishing the dialog . . . . . . . . . . . . . . . . . 10 4.3. Establishing the Dialog . . . . . . . . . . . . . . . . . 10
4.3.1. Establishing dialog state through reliable 4.3.1. Establishing Dialog State through Reliable
Offer/Answer delivery . . . . . . . . . . . . . . . . 11 Offer/Answer delivery . . . . . . . . . . . . . . . . 11
4.3.2. Establishing dialog state through unreliable 4.3.2. Establishing Dialog State through Unreliable
Offer/Answer delivery . . . . . . . . . . . . . . . . 12 Offer/Answer Delivery . . . . . . . . . . . . . . . . 12
4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14 4.3.3. Initiating Trickle ICE without an SDP Answer . . . . 14
4.3.4. Considerations for Third Party Call Control . . . . . 15 4.3.4. Considerations for Third Party Call Control . . . . . 15
4.4. Delivering candidates in INFO messages . . . . . . . . . 17 4.4. Delivering Candidates in INFO Requests . . . . . . . . . 17
5. Initial discovery of Trickle ICE support . . . . . . . . . . 21 5. Initial Discovery of Trickle ICE Support . . . . . . . . . . 22
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 22 5.1. Provisioning Support for Trickle ICE . . . . . . . . . . 22
5.2. Trickle ICE discovery with Globally Routable User Agent 5.2. Trickle ICE Discovery with Globally Routable User Agent
URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 23 5.3. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 23
6. Considerations for RTP and RTCP multiplexing . . . . . . . . 24 6. Considerations for RTP and RTCP Multiplexing . . . . . . . . 24
7. Considerations for Media Multiplexing . . . . . . . . . . . . 26 7. Considerations for Media Multiplexing . . . . . . . . . . . . 26
8. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . . . 29 8. SDP 'end-of-candidates' Attribute . . . . . . . . . . . . . . 29
8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 29
8.2. Offer/Answer procedures . . . . . . . . . . . . . . . . . 30 8.2. Offer/Answer Procedures . . . . . . . . . . . . . . . . . 30
9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 30 9. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 30
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 30 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 30
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32 10.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . 32
10.2. Overall Description . . . . . . . . . . . . . . . . . . 33 10.2. Overall Description . . . . . . . . . . . . . . . . . . 33
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . 33
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 33 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . 33
10.5. Info Package Parameters . . . . . . . . . . . . . . . . 33 10.5. Info Package Parameters . . . . . . . . . . . . . . . . 34
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 33 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . 34
10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34 10.7. Info Request Body Parts . . . . . . . . . . . . . . . . 34
10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34 10.8. Info Package Usage Restrictions . . . . . . . . . . . . 34
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . 34
10.10. Info Package Security Considerations . . . . . . . . . . 34 10.10. Info Package Security Considerations . . . . . . . . . . 35
11. Deployment Considerations . . . . . . . . . . . . . . . . . . 34 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 35
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12.1. SDP 'end-of-candidate' Attribute . . . . . . . . . . . . 35 12.1. SDP 'end-of-candidates' Attribute . . . . . . . . . . . 35
12.2. application/trickle-ice-sdpfrag Media Type . . . . . . . 35 12.2. Media Type 'application/trickle-ice-sdpfrag' . . . . . . 36
12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 37 12.3. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 38
12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 37 12.4. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 38
13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
16.1. Normative References . . . . . . . . . . . . . . . . . . 41 16.1. Normative References . . . . . . . . . . . . . . . . . . 43
16.2. Informative References . . . . . . . . . . . . . . . . . 44 16.2. Informative References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
The Interactive Connectivity Establishment (ICE) protocol The Interactive Connectivity Establishment (ICE) protocol
[I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address [I-D.ietf-ice-rfc5245bis] describes a mechanism for Network Address
Translator (NAT) traversal that consists of three main phases. Translator (NAT) traversal that consists of three main phases.
During the first phase an agent gathers a set of candidate transport During the first phase an agent gathers a set of candidate transport
addresses (source IP address, port and transport protocol). This is addresses (source IP address, port and transport protocol). This is
followed by a second phase where these candidates are sent to a followed by a second phase where these candidates are sent to a
remote agent. There, the gathering procedure is repeated and remote agent. There, the gathering procedure is repeated and
candidates are sent to the first agent. Finally, a third phase candidates are sent to the first agent. Finally, a third phase
starts where connectivity between all candidates in both sets is starts where connectivity between all candidates in both sets is
checked (connectivity checks). Once these phases have been checked (connectivity checks). Once these phases have been
completed, and only then, both agents can begin communication. completed, and only then, both agents can begin communication.
According to [I-D.ietf-ice-rfc5245bis] the three phases above happen According to [I-D.ietf-ice-rfc5245bis] the three phases above happen
consecutively, in a blocking way, which can introduce undesirable consecutively, in a blocking way, which can introduce undesirable
setup delay during session establishment. The Trickle ICE extension setup delay during session establishment. The Trickle ICE extension
[I-D.ietf-ice-trickle] defines generic semantics required for these [I-D.ietf-ice-trickle] defines generic semantics required for these
ICE phases to happen in a parallel, non-blocking way and hence speed ICE phases to happen in a parallel, non-blocking way and hence speed
up session establishment. up session establishment.
This specification defines a usage of Trickle ICE with the Session This specification defines a usage of Trickle ICE with the Session
Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates
are to be exchanged incrementally with SIP INFO requests [RFC6086] are to be exchanged incrementally using SIP INFO requests [RFC6086]
and how the Half Trickle and Full Trickle modes defined in and how the Half Trickle and Full Trickle modes defined in
[I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs) [I-D.ietf-ice-trickle] are to be used by SIP User Agents (UAs)
depending on their expectations for support of Trickle ICE by a depending on their expectations for support of Trickle ICE by a
remote agent. remote agent.
This document defines a new Info Package as specified in [RFC6086] This document defines a new Info Package as specified in [RFC6086]
for use with Trickle ICE. for use with Trickle ICE.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119], [RFC8174] when, and only when, they appear in all 14 [RFC2119], [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification makes use of terminology defined by the protocol This specification makes use of terminology defined by the protocol
for Interactive Connectivity Establishment in for Interactive Connectivity Establishment in
[I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension [I-D.ietf-ice-rfc5245bis] and its Trickle ICE extension
[I-D.ietf-ice-trickle]. It is assumed that the reader will be [I-D.ietf-ice-trickle]. It is assumed that the reader is familiar
familiar with the terminology from both documents. with the terminology from both documents.
3. Protocol Overview 3. Protocol Overview
When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp]
ICE candidates are exchanged solely via SDP Offer/Answer as per the ICE candidates are exchanged solely via SDP Offer/Answer as per
[RFC3264]. This specification defines an additional mechanism where [RFC3264]. This specification defines an additional mechanism where
candidates can be exchanged using SIP INFO messages and a newly candidates can be exchanged using SIP INFO messages and a newly
defined Info Package [RFC6086]. This allows ICE candidates also to defined Info Package [RFC6086]. This allows ICE candidates also to
be sent in parallel to an ongoing Offer/Answer negotiation and/or be sent in parallel to an ongoing Offer/Answer negotiation and/or
after the completion of the Offer/Answer negotiation. after the completion of the Offer/Answer negotiation.
Typically, in cases where Trickle ICE is fully supported, the Offerer Typically, in cases where Trickle ICE is fully supported, the Offerer
would send an INVITE request containing a subset of candidates. Once sends an INVITE request containing a subset of candidates. Once an
an early dialog is established the Offerer can continue sending early dialog is established the Offerer can continue sending
candidates in INFO requests within that dialog. candidates in INFO requests within that dialog.
Similarly, an Answerer can send ICE candidates using INFO requests 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) | |
skipping to change at page 5, line 40 skipping to change at page 5, line 40
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,
potentially empty sets of candidates. Such Offers and Answers can potentially empty sets of candidates. Such Offers and Answers can
only be handled meaningfully by agents that actually support only be handled meaningfully by agents that actually support
incremental candidate provisioning, which implies the need to confirm incremental candidate provisioning, which implies the need to confirm
such support before actually using it. such support before using it.
Contrary to other protocols, where "in advance" capability discovery Contrary to other protocols, where "in advance" capability discovery
is widely implemented, the mechanisms that allow this for SIP (i.e., is widely implemented, the mechanisms that allow this for SIP (i.e.,
a combination of UA Capabilities [RFC3840] and GRUU [RFC5627]) have a combination of UA Capabilities [RFC3840] and GRUU [RFC5627]) have
only seen low levels of adoption. This presents an issue for Trickle only seen low levels of adoption. This presents an issue for Trickle
ICE implementations as SIP UAs do not have an obvious means of ICE implementations as SIP UAs do not have an obvious means of
verifying that their peer will support incremental candidate verifying that their peer will support incremental candidate
provisioning. provisioning.
The Half Trickle mode of operation defined in the Trickle ICE The Half Trickle mode of operation defined in the Trickle ICE
specification [I-D.ietf-ice-trickle] provides one way around this, by specification [I-D.ietf-ice-trickle] provides one way around this,
requiring the first Offer to contain a complete set of local ICE by requiring the first Offer to contain a complete set of local ICE
candidates and only using incremental provisioning of remote candidates and only using incremental provisioning of remote
candidates for the rest of the session. candidates for the rest of the session.
While using Half Trickle does provide a working solution it also While using Half Trickle does provide a working solution it also
comes at the price of increased latency. Section 5 therefore makes comes at the price of increased latency. Section 5 therefore makes
several alternative suggestions that enable SIP UAs to engage in Full several alternative suggestions that enable SIP UAs to engage in Full
Trickle right from their first Offer: Section 5.1 discusses the use Trickle right from their first Offer: Section 5.1 discusses the use
of on-line provisioning as a means of allowing use of Trickle ICE for of on-line provisioning as a means of allowing use of Trickle ICE for
all endpoints in controlled environments. Section 5.2 describes all endpoints in controlled environments. Section 5.2 describes
anticipatory discovery for implementations that actually do support anticipatory discovery for implementations that actually do support
GRUU and UA Capabilities and Section 5.3 discusses the implementation GRUU and UA Capabilities and Section 5.3 discusses the implementation
and use of Half Trickle by SIP UAs where none of the above are an and use of Half Trickle by SIP UAs where none of the above are an
option. option.
3.2. Relationship with the Offer/Answer Model 3.2. Relationship with the Offer/Answer Model
From the perspective of SIP middle boxes and proxies the Offer/Answer From the perspective of SIP middle boxes and proxies the Offer/Answer
exchange looks partly similar for Trickle ICE as it would for regular exchange for Trickle ICE looks partly similar to the Offer/Answer
ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. However, in order to have exchange for regular ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp].
the full picture of the candidate exchange, the newly introduced INFO However, in order to have the full picture of the candidate exchange,
messages need to be considered as well. the newly introduced INFO messages need to be considered as well.
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob | | Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | |
| +--------+ | Module | | | | Module | +--------+ | | +--------+ | Module | | | | Module | +--------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | | | | ICE | +--------------+ | | +--------------+ | ICE | |
| | Module | | | | | | Module | | | | Module | | | | | | Module | |
| +--------+ | | | | +--------+ | | +--------+ | | | | +--------+ |
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| | | | | | | |
skipping to change at page 7, line 42 skipping to change at page 7, line 42
signaling. signaling.
From an architectural viewpoint, as displayed in 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 modules and not between Offer/Answer modules of signaling between ICE modules 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 requests SHALL be included in subsequent Offers or Answers. The INFO requests SHALL be included in subsequent Offers or Answers. The
version number in the "o=" line of that subsequent Offer would need version number in the "o=" line of that subsequent Offer needs to be
to be incremented by 1 per the rules in [RFC3264]. incremented by 1 per the rules in [RFC3264].
4. Incremental Signaling of ICE candidates 4. Incremental Signaling of ICE candidates
Trickle ICE Agents will exchange ICE descriptions compliant to Trickle ICE Agents will exchange ICE descriptions compliant to
[I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO [I-D.ietf-ice-trickle] via Offer/Answer procedures and/or INFO
request bodies. This requires the following SIP-specific extensions: request bodies. This requires the following SIP-specific extensions:
1. Trickle ICE Agents MUST indicate support for Trickle ICE by 1. Trickle ICE Agents MUST indicate support for Trickle ICE by
including the SIP option-tag 'trickle-ice' in a SIP Supported: including the SIP option-tag 'trickle-ice' in a SIP Supported:
header field within all SIP INVITE requests and responses. header field within all SIP INVITE requests and responses.
2. Trickle ICE Agents MUST indicate support for Trickle ICE by 2. Trickle ICE Agents MUST indicate support for Trickle ICE by
including the ice-option 'trickle' within all SDP Offers and including the ice-option 'trickle' within all SDP Offers and
Answers in accordance to [I-D.ietf-ice-trickle]. Answers in accordance to [I-D.ietf-ice-trickle].
skipping to change at page 8, line 32 skipping to change at page 8, line 32
prepared to receive INFO requests within that same dialog usage, prepared to receive INFO requests within that same dialog usage,
containing additional candidates and/or an indication that containing additional candidates and/or an indication that
trickling of such candidates has ended. trickling of such candidates has ended.
5. 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 may exist. case of forking multiple early dialogs may exist.
The following sections provide further details on how Trickle ICE The following sections provide further details on how Trickle ICE
Agents perform the initial Offers/Answers exchange (Section 4.1), Agents perform the initial Offer/Answer exchange (Section 4.1),
perform subsequent Offers/Answers exchanges (Section 4.2) and perform subsequent Offer/Answer exchanges (Section 4.2) and establish
establish the INVITE dialog usage (Section 4.3) such that they can the INVITE dialog usage (Section 4.3) such that they can
incrementally trickle candidates (Section 4.4). incrementally trickle candidates (Section 4.4).
4.1. Initial Offer/Answer exchange 4.1. Initial Offer/Answer Exchange
4.1.1. Sending the initial Offer 4.1.1. Sending the Initial Offer
If the Offerer includes candidates in its initial Offer, it MUST If the Offerer includes candidates in its initial Offer, it MUST
encode these candidates as specified in encode these candidates as specified in
[I-D.ietf-mmusic-ice-sip-sdp]. [I-D.ietf-mmusic-ice-sip-sdp].
If the Offerer wants to send its initial Offer before knowing any If the Offerer wants to send its initial Offer before knowing any
candidate for one or more media descriptions, it MUST set the port to candidate for one or more media descriptions, it MUST set the port to
the default value '9' for these media descriptions. If the Offerer the default value '9' for these media descriptions. If the Offerer
does not want to include the host IP address in the corresponding does not want to include the host IP address in the corresponding
c-line, e.g. due to privacy reasons, it SHOULD include a default c-line, e.g. due to privacy reasons, it SHOULD include a default
address in the c-line, which is set to the IPv4 address 0.0.0.0 or to address in the c-line, which is set to the IPv4 address 0.0.0.0 or to
the IPv6 equivalent ::. the IPv6 equivalent ::.
In this case, the Offerer obviously cannot know the RTCP transport In this case, the Offerer obviously cannot know the RTCP transport
address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086].
This avoids potential ICE mismatch (see This avoids potential ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address.
If the Offerer wants to use RTCP multiplexing [RFC5761] and/or If the Offerer wants to use RTCP multiplexing [RFC5761] and/or
exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still
will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in will include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in
the initial Offer. the initial Offer.
In any case, the Offerer MUST include the attribute "a=ice- In any case, the Offerer MUST include the attribute "a=ice-
options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST
include in each "m="-line a "a=mid:" attribute in accordance to include in each "m="-line a "a=mid:" attribute in accordance to
[RFC5888]. [RFC5888].
4.1.2. Receiving the initial Offer 4.1.2. Receiving the Initial Offer
If the initial Offer included candidates, the Answerer uses these If the initial Offer included candidates, the Answerer uses these
candidates to start ICE processing as specified in candidates to start ICE processing as specified in
[I-D.ietf-ice-trickle]. [I-D.ietf-ice-trickle].
If the initial Offer included the attribute a=ice-options:trickle, If the initial Offer included the attribute a=ice-options:trickle,
the Answerer MUST be prepared for receiving trickled candidates later the Answerer MUST be prepared for receiving trickled candidates later
on. on.
In case of a "m/c=" line with default values none of the eventually In case of a "m/c=" line with default values none of the eventually
trickled candidates will match the default destination. This trickled candidates will match the default destination. This
situation MUST NOT cause an ICE mismatch (see situation MUST NOT cause an ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]). [I-D.ietf-mmusic-ice-sip-sdp]).
4.1.3. Sending the initial Answer 4.1.3. Sending the Initial Answer
If the Answerer includes candidates in its initial Answerer, it MUST If the Answerer includes candidates in its initial Answerer, it MUST
encode these candidates as specified in encode these candidates as specified in
[I-D.ietf-mmusic-ice-sip-sdp]. [I-D.ietf-mmusic-ice-sip-sdp].
If the Answerer wants to send its initial Answer before knowing any If the Answerer wants to send its initial Answer before knowing any
candidate for one or more media descriptions, it MUST set the port to candidate for one or more media descriptions, it MUST set the port to
the default value '9' for these media descriptions. If the Answerer the default value '9' for these media descriptions. If the Answerer
does not want to include the host IP address in the corresponding does not want to include the host IP address in the corresponding
c-line, e.g. due to privacy reasons, it SHOULD include a default c-line, e.g. due to privacy reasons, it SHOULD include a default
address in the c-line, which is set to the IPv4 address 0.0.0.0 or to address in the c-line, which is set to the IPv4 address 0.0.0.0 or to
the IPv6 equivalent ::. the IPv6 equivalent ::.
In this case, the Answerer obviously cannot know the RTCP transport In this case, the Answerer obviously cannot know the RTCP transport
address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086].
This avoids potential ICE mismatch (see This avoids potential ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address. [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address.
If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or If the Answerer accepts to use RTCP multiplexing [RFC5761] and/or
exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it will
include the "a=rtcp-mux" attribute in the initial Answer. include the "a=rtcp-mux" attribute in the initial Answer.
In any case, the Answerer MUST include the attribute "a=ice- In any case, the Answerer MUST include the attribute "a=ice-
options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST options:trickle" in accordance to [I-D.ietf-ice-trickle] and MUST
include in each "m="-line a "a=mid:" attribute in accordance to include in each "m="-line a "a=mid:" attribute in accordance to
[RFC5888]. [RFC5888].
4.1.4. Receiving the initial Answer 4.1.4. Receiving the Initial Answer
If the initial Answer included candidates, the Offerer uses these If the initial Answer included candidates, the Offerer uses these
candidates to start ICE processing as specified in candidates to start ICE processing as specified in
[I-D.ietf-ice-trickle]. [I-D.ietf-ice-trickle].
If the initial Answer included the attribute a=ice-options:trickle, If the initial Answer included the attribute a=ice-options:trickle,
the Offerer MUST be prepared for receiving trickled candidates later the Offerer MUST be prepared for receiving trickled candidates later
on. on.
In case of a "m/c=" line with default values none of the eventually In case of a "m/c=" line with default values none of the eventually
trickled candidates will match the default destination. This trickled candidates will match the default destination. This
situation MUST NOT cause an ICE mismatch (see situation MUST NOT cause an ICE mismatch (see
[I-D.ietf-mmusic-ice-sip-sdp]). [I-D.ietf-mmusic-ice-sip-sdp]).
4.2. Subsequent Offer/Answer exchanges 4.2. Subsequent Offer/Answer Exchanges
Subsequent Offer/Answer exchanges are handled as for regular ICE (see Subsequent Offer/Answer exchanges are handled as for regular ICE (see
section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]). section 4.2 of [I-D.ietf-mmusic-ice-sip-sdp]).
If an Offer or Answer needs to be sent while the ICE agents are in If an Offer or Answer needs to be sent while the ICE agents are in
the middle of trickling section 4.2.1.2.1 of the middle of trickling section 4.2.1.2.1 of
[I-D.ietf-mmusic-ice-sip-sdp]) applies. This means that an ICE agent [I-D.ietf-mmusic-ice-sip-sdp]) applies. This means that an ICE agent
includes candidate attributes for all local candidates it had includes candidate attributes for all local candidates it had
trickled previously for a specific media stream. trickled previously for a specific media stream.
[RFC EDITOR NOTE: The section 4.2.1.2.1 in above sentence is correct [RFC EDITOR NOTE: The section 4.2.1.2.1 in above sentence is correct
for version 16 of said I-D. Authors need to cross-check during for version 16 of said I-D. Authors need to cross-check during
Auth48 since it could have have changed in the meantime.] Auth48 since it could have have changed in the meantime.]
4.3. Establishing the dialog 4.3. Establishing the Dialog
In order to be able to start trickling, the following two conditions In order to be able to start trickling, the following two conditions
need to be satisfied at the SIP UAs: need to be satisfied at the SIP UAs:
o Trickle ICE support at the peer agent MUST be confirmed. o Trickle ICE support at the peer agent MUST be confirmed.
o The dialog at both peers MUST be in early or confirmed state. o The dialog at both peers MUST be in early or confirmed state.
Section 5 discusses in detail the various options for satisfying the Section 5 discusses in detail the various options for satisfying the
first of the above conditions. Regardless of those mechanisms, first of the above conditions. Regardless of those mechanisms,
however, agents are certain to have a clear understanding of whether however, agents are certain to have a clear understanding of whether
their peers support trickle ICE once an Offer and an Answer have been their peers support trickle ICE once an Offer and an Answer have been
exchanged, which also allows for ICE processing to commence (see exchanged, which also allows for ICE processing to commence (see
Figure 3). Figure 3).
4.3.1. Establishing dialog state through reliable Offer/Answer delivery 4.3.1. Establishing Dialog State through Reliable Offer/Answer delivery
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| PRACK/OK | | PRACK/OK |
|------------------------>| |------------------------>|
| | | |
skipping to change at page 12, line 5 skipping to change at page 12, line 5
As shown in Figure 3 satisfying both conditions is relatively trivial As shown in Figure 3 satisfying both conditions is relatively trivial
for ICE Agents that have sent an Offer in an INVITE and that have for ICE Agents that have sent an Offer in an INVITE and that have
received an Answer in a reliable provisional response. It is received an Answer in a reliable provisional response. It is
guaranteed to have confirmed support for Trickle ICE at the Answerer guaranteed to have confirmed support for Trickle ICE at the Answerer
(or lack thereof) and to have fully initialized the SIP dialog at (or lack thereof) and to have fully initialized the SIP dialog at
both ends. Offerers and Answerers (after receipt of the PRACK both ends. Offerers and Answerers (after receipt of the PRACK
request) in the above situation can therefore freely commence request) in the above situation can therefore freely commence
trickling within the newly established dialog. trickling within the newly established dialog.
4.3.2. Establishing dialog state through unreliable Offer/Answer 4.3.2. Establishing Dialog State through Unreliable Offer/Answer
delivery 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 12, line 36 skipping to change at page 12, line 36
| +----------------------+ | +----------------------+
| | | |
Figure 4: A SIP UA that sent an Answer in an unreliable provisional Figure 4: A SIP UA that sent an Answer in an unreliable provisional
response does not know if it was received and if the dialog at the response does not know if it was received and if the dialog at the
side of the Offerer has entered the early state side of the Offerer has entered the early state
In order to clear this ambiguity as soon as possible, the Answerer In order to clear this ambiguity as soon as possible, the Answerer
needs to retransmit the provisional response with the exponential needs to retransmit the provisional response with the exponential
back-off timers described in [RFC3262]. These retransmissions MUST back-off timers described in [RFC3262]. These retransmissions MUST
cease on receipt of an INFO request or on transmission of the Answer cease on receipt of an INFO request carrying a 'trickle-ice' Info
in a 2xx response. This is similar to the procedure described in Package body or on transmission of the Answer in a 2xx response.
section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN This is similar to the procedure described in section 8.1.1 of
binding Request is replaced by the INFO request. [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is
replaced by the INFO request.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for
version 16 of said I-D. Authors need to cross-check during Auth48 version 16 of said I-D. Authors need to cross-check during Auth48
since it could have have changed in the meantime.] since it could have have changed in the meantime.]
The Offerer MUST send a Trickle ICE INFO request as soon as it The Offerer MUST send a Trickle ICE INFO request as soon as it
receives an SDP Answer in an unreliable provisional response. This receives an SDP Answer in an unreliable provisional response. This
INFO request MUST repeat the candidates that were already provided in INFO request MUST repeat the candidates that were already provided in
the Offer (as would be the case when Half Trickle is performed or the Offer (as would be the case when Half Trickle is performed or
when new candidates have not been learned since then). when new candidates have not been learned since then).
skipping to change at page 14, line 20 skipping to change at page 14, line 21
allows ICE Agents to initiate trickling without actually sending an allows ICE Agents to initiate trickling without actually sending an
Answer. Trickle ICE Agents can therefore respond to an INVITE Answer. Trickle ICE Agents can therefore respond to an INVITE
request with provisional responses without an SDP Answer [RFC3261]. request with provisional responses without an SDP Answer [RFC3261].
Such provisional responses serve for establishing an early dialog. Such provisional responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way, MUST Agents that choose to establish the dialog in this way, MUST
retransmit these responses with the exponential back-off timers retransmit these responses with the exponential back-off timers
described in [RFC3262]. These retransmissions MUST cease on receipt described in [RFC3262]. These retransmissions MUST cease on receipt
of an INFO request or on transmission of the Answer in a 2xx of an INFO request or on transmission of the Answer in a 2xx
response. This is again similar to the procedure described in response. This is again similar to the procedure described in
section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer
is not yet provided. is not yet provided.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for [RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for
version 16 of said I-D. Authors need to cross-check during Auth48 version 16 of said I-D. Authors need to cross-check during Auth48
since it could have have changed in the meantime.] since it could have have changed in the meantime.]
Note: The +SRFLX in Figure 6 indicates that additionally newly Note: The +SRFLX in Figure 6 indicates that additionally newly
learned server-reflexive candidates are included. learned server-reflexive candidates are included.
Alice Bob Alice Bob
skipping to change at page 15, line 49 skipping to change at page 15, line 49
requirements in [RFC3264]. In case that trickling continued, an requirements in [RFC3264]. In case that trickling continued, an
Offerer needs to be prepared for receiving fewer candidates in that Offerer needs to be prepared for receiving fewer candidates in that
repeated Answer than previously exchanged via trickling and MUST repeated Answer than previously exchanged via trickling and MUST
ignore the candidate information in that 200 OK response. ignore the candidate information in that 200 OK response.
4.3.4. Considerations for Third Party Call Control 4.3.4. Considerations for Third Party Call Control
Third Party Call Control (3PCC) for SIP can be performed using Third Party Call Control (3PCC) for SIP can be performed using
several signaling variants as described in [RFC3725]. We give several signaling variants as described in [RFC3725]. We give
specific consideration for 3PCC that starts with an offerless INVITE specific consideration for 3PCC that starts with an offerless INVITE
request [RFC3261]. Then, a User Agent Client (UAC) has the option to request [RFC3261]. As specified in Section 4 this offerless INVITE
send its Offer in a reliable provisional response [RFC3262] or in the MUST include the SIP option-tag 'trickle-ice' in a SIP Supported:
200 OK response to the INVITE request. header field in order to indicate support for Trickle-ICE to the
Offerer (at the User Agent Server (UAS)). Then, a UAS has the option
to send its Offer in a reliable provisional response [RFC3262] or in
the 200 OK response to the INVITE request.
Agents that had sent an Offer in a reliable provisional response and Agents that had sent an Offer in a reliable provisional response and
that received an Answer in a PRACK request [RFC3262] are also in a that received an Answer in a PRACK request [RFC3262] are also in a
situation where support for Trickle ICE is confirmed and the SIP situation where support for Trickle ICE is confirmed and the SIP
dialog is guaranteed to be in a state that would allow in-dialog INFO dialog is guaranteed to be in a state that allows in-dialog INFO
requests (see Figure 7). requests (see Figure 7).
Alice Bob Alice Bob
| | | |
| INVITE | | INVITE |
|------------------------>| |------------------------>|
| 183 (Offer) | | 183 (Offer) |
|<------------------------| |<------------------------|
| PRACK (Answer) | | PRACK (Answer) |
|------------------------>| |------------------------>|
skipping to change at page 16, line 43 skipping to change at page 16, line 46
|<------------------------| |<------------------------|
Note: SRFLX denotes server-reflexive candidates Note: SRFLX denotes server-reflexive candidates
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 ICE Agents that send an Offer in a 200 OK response and Trickle ICE Agents that send an Offer in a 200 OK response and
receive an Answer in an ACK message can still create a dialog and receive an Answer in an ACK message can still create a dialog and
confirm support for Trickle ICE by sending an unreliable provisional confirm support for Trickle ICE by sending an unreliable provisional
response similar to Section 4.3.3. According to [RFC3261], this response similar to Section 4.3.3. As specified in Section 4 this
unreliable provisional response MUST include the SIP option-tag
'trickle-ice' in a SIP Supported: header field in order to indicate
support for Trickle-ICE to the UAC. According to [RFC3261], this
unreliable response cannot contain an Offer. unreliable response cannot contain an Offer.
The Trickle ICE Agent, i.e. the user Agent server (UAS), retransmits The Trickle ICE Agent, i.e. the user Agent server (UAS), retransmits
the provisional response with the exponential back-off timers the provisional response with the exponential back-off timers
described in [RFC3262]. Retransmits MUST cease on receipt of an INFO described in [RFC3262]. Retransmits MUST cease on receipt of an INFO
request or on transmission of the Answer in a 2xx response. The peer request or on transmission of the Answer in a 2xx response. The peer
Trickle ICE Agent (the UAC) MUST send a Trickle ICE INFO request as Trickle ICE Agent (the UAC) MUST send a Trickle ICE INFO request as
soon as they receive an unreliable provisional response (see soon as it receives an unreliable provisional response (see
Figure 8). Figure 8).
Alice Bob Alice Bob
| | | |
| INVITE | | INVITE |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|------------------------>| |------------------------>|
skipping to change at page 17, line 38 skipping to change at page 17, line 44
|<------------------------| |<------------------------|
| ACK (Answer) | | ACK (Answer) |
|------------------------>| |------------------------>|
| | | |
Note: SRFLX denotes server-reflexive candidates Note: SRFLX denotes server-reflexive candidates
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.4. Delivering candidates in INFO messages 4.4. Delivering Candidates in INFO Requests
Whenever new ICE candidates become available for sending, agents Whenever new ICE candidates become available for sending, agents
would encode them in "a=candidate" attributes as described by encode them in "a=candidate:" attributes as described by
[I-D.ietf-mmusic-ice-sip-sdp]. For example: [I-D.ietf-mmusic-ice-sip-sdp]. For example:
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 8998 raddr 2001:db8:a0b:12f0::1 rport 8998
The use of SIP INFO requests happens within the context of the Info The use of SIP INFO requests happens within the context of the Info
Package as defined Section 10. The Media Type [RFC6838] for their Package as defined Section 10. The Media Type [RFC6838] for their
payload MUST be set to 'application/trickle-ice-sdpfrag' as defined payload MUST be set to 'application/trickle-ice-sdpfrag' as defined
in Section 9. in Section 9. The Info request body adheres to the grammar as
specified in Section 9.2.
Since neither the "a=candidate" nor the "a=end-of-candidates" Since neither the "a=candidate:" nor the "a=end-of-candidates"
attributes contain information that would allow correlating them to a attributes contain information that would allow correlating them to a
specific "m=" line, this is handled through the use of pseudo "m=" specific "m=" line, this is handled through the use of pseudo "m="
lines and identification tags in "a=mid:" attributes as defined in lines and identification tags in "a=mid:" attributes as defined in
[RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in [RFC4566], but provide no semantics other than indicating defined in [RFC4566], but provide no semantics other than indicating
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, agent MUST ignore any remaining content of the pseudo "m=" line,
which 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].
skipping to change at page 18, line 37 skipping to change at page 18, line 44
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 field MUST appear only once and is set to '0' o The fmt field MUST 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.
"a=candidate" or "a=end-of-candidates" attributes following an
All "a=candidate:" or "a=end-of-candidates" attributes following an
"a=mid:" attribute, up until (and excluding) the next occurrence of a "a=mid:" attribute, up until (and excluding) the next occurrence of a
pseudo "m=" line, pertain to the "m=" line identified by that pseudo "m=" line, pertain to the "m=" line identified by that
identification tag. An "a=end-of-candidates" attribute, preceding identification tag.
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 Note, that there is no requirement that the Info request body
would be indicated by a media level "a=end-of-candidates" attribute. contains as many pseudo m= lines as the Offer/Answer contains m=
lines, nor that the pseudo m= lines be in the same order as the
m=lines that they pertain to. The correspondence can be made via the
"a=mid:" attributes.
An "a=end-of-candidates" attribute, preceding 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 would be indicated by a
media level "a=end-of-candidates" attribute.
Refer to Figure 9 for an example of the INFO request content. Refer to Figure 9 for an example of the INFO request content.
The use of pseudo "m=" lines allows for a structure similar to the The use of pseudo "m=" lines allows for a structure similar to the
one in SDP Offers and Answers where separate media-level and session- one in SDP Offers and Answers where separate media-level and session-
level sections can be distinguished. In the current case, lines level sections can be distinguished. In the current case, lines
preceding any pseudo "m=" line are considered to be session-level. preceding any pseudo "m=" line are considered to be session-level.
Lines appearing in between or after pseudo "m=" lines will be Lines appearing in between or after pseudo "m=" lines will be
interpreted as media-level. interpreted as media-level.
Note that while this specification uses the "a=mid:" attribute Note that while this specification uses the "a=mid:" attribute
from [RFC5888], it does not define any grouping semantics. from [RFC5888], it does not define any grouping semantics.
Consequently, the "a=group:" attribute from that same Consequently, the "a=group:" attribute from that same
specification is neither needed nor used in Trickle ICE for SIP. specification is neither needed nor used in Trickle ICE for SIP.
All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:"
attributes that would allow mapping them to a specific ICE attributes that allows mapping them to a specific ICE generation. An
generation. An agent MUST discard any received INFO requests agent MUST discard any received INFO requests containing "a=ice-pwd:"
containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not and "a=ice-ufrag:" attributes that do not match those of the current
match those of the current ICE Negotiation Session. ICE Negotiation Session.
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
same level as the ones in the Offer/Answer exchange. In other words, same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes, they will also if they were present as session-level attributes, they will also
appear at the beginning of all INFO request payloads, i.e. preceding appear at the beginning of all INFO request payloads, i.e. preceding
all pseudo "m=" lines. If they were originally exchanged as media all pseudo "m=" lines. If they were originally exchanged as media
level attributes, potentially overriding session-level values, then level attributes, potentially overriding session-level values, then
they will also be included in INFO request payloads following the they will also be included in INFO request payloads following the
corresponding pseudo "m=" lines. corresponding pseudo "m=" lines.
skipping to change at page 19, line 49 skipping to change at page 20, line 19
sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in
the same order as they were gathered. In other words, the sequence the same order as they were gathered. In other words, the sequence
of a previously sent list of candidates MUST NOT change in subsequent of a previously sent list of candidates MUST NOT change in subsequent
INFO requests and newly gathered candidates MUST be added at the end INFO requests and newly gathered candidates MUST be added at the end
of that list. Although repeating all candidates creates some of that list. Although repeating all candidates creates some
overhead, it also allows easier handling of problems that could arise overhead, it also allows easier handling of problems that could arise
from unreliable transports, like e.g. loss of messages and from unreliable transports, like e.g. loss of messages and
reordering, which can be detected through the CSeq: header field in reordering, which can be detected through the CSeq: header field in
the INFO request. the INFO request.
When receiving INFO requests carrying any candidates, agents will When receiving INFO requests carrying any candidates, agents MUST
therefore first identify and discard the attribute lines containing therefore first identify and discard the attribute lines containing
candidates they have already received in previous INFO requests or in candidates they have already received in previous INFO requests or in
the Offer/Answer exchange preceding them. Two candidates are the Offer/Answer exchange preceding them.
considered to be equal if their IP address port, transport and
component ID are the same. After identifying and discarding known Such candidates are considered to be equal if their IP address port,
candidates, the agents MUST forward the actually new candidates to transport and component ID are the same. After identifying and
the ICE Agents in the same order as they were received in the INFO discarding the known candidates, the agents MUST forward the actually
request body. The ICE Agents will then process the new candidates new candidates to the ICE Agents in the same order as they were
according to the rules described in [I-D.ietf-ice-trickle]. received in the INFO request body. The ICE Agents will then process
the new candidates according to the rules described in
[I-D.ietf-ice-trickle].
Receiving an "a=end-of-candidates" attribute in an INFO request body Receiving an "a=end-of-candidates" attribute in an INFO request body
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the
current ICE generation - is an indication from the peer agent that it current ICE generation - is an indication from the peer agent that it
will not send any further candidates. When included at session will not send any further candidates. When included at session
level, i.e. before any pseudo "m=" line, this indication applies to level, i.e. before any pseudo "m=" line, this indication applies to
the whole session; when included at media level the indication the whole session; when included at media level the indication
applies only to the corresponding "m=" line. Handling of such end- applies only to the corresponding "m=" line. Handling of such end-
of-candidate indications is defined in [I-D.ietf-ice-trickle]. of-candidates indications is defined in [I-D.ietf-ice-trickle].
Note: At the time of writing this specification there were ongoing 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
request. However, if an implementation according to this request. However, if an implementation according to this
specification receives such an INFO request with a missing candidate specification receives such an INFO request with a missing candidate
skipping to change at page 21, line 33 skipping to change at page 21, line 40
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
Note: In a real INFO request there would be no line breaks Note: In a real INFO request there will be no line breaks
in the a=candidate: attributes in the a=candidate: attributes
Figure 9: An Example for the Content of an INFO Request Figure 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 attribute "a=ice-options:trickle" and MUST
This makes discovery fairly straightforward for Answerers or for include the SIP option-tag "trickle-ice" in a SIP Supported: header
cases where Offers need to be generated within existing dialogs field. This makes discovery fairly straightforward for Answerers or
for cases where Offers need to be generated within existing dialogs
(i.e., when sending UPDATE or re-INVITE requests). In both scenarios (i.e., when sending UPDATE or re-INVITE requests). In both scenarios
prior SDP would have provided the necessary information. prior SDP bodies will have provided the necessary information.
Obviously, prior SDP is not available at the time a first Offer is Obviously, such information is not available at the time a first
being constructed and it is therefore impossible for ICE Agents to Offer is being constructed and it is therefore impossible for ICE
determine support for incremental provisioning that way. The Agents to determine support for incremental provisioning that way.
following options are suggested as ways of addressing this issue. The following options are suggested as ways of addressing this issue.
5.1. Provisioning support for Trickle ICE 5.1. Provisioning Support for Trickle ICE
In certain situations it may be possible for integrators deploying In certain situations it may be possible for integrators deploying
Trickle ICE to know in advance that some or all endpoints reachable Trickle ICE to know in advance that some or all endpoints reachable
from within the deployment will support Trickle ICE. This is the from within the deployment will support Trickle ICE. This is the
case, for example, if Session Border Controllers (SBC) with support case, for example, if Session Border Controllers (SBC) with support
for this specification are used to connect to UAs that do not support for this specification are used to connect to UAs that do not support
Trickle ICE. Trickle ICE.
While the exact mechanism for allowing such provisioning is out of While the exact mechanism for allowing such provisioning is out of
scope here, this specification encourages trickle ICE implementations scope here, this specification encourages trickle ICE implementations
to allow the option in the way they find most appropriate. to allow the option in the way they find most appropriate.
5.2. Trickle ICE discovery with Globally Routable User Agent URIs 5.2. Trickle ICE Discovery with Globally Routable User Agent URIs
[RFC3840] provides a way for SIP User Agents to query for support of [RFC3840] provides a way for SIP User Agents to query for support of
specific capabilities using, among others, OPTIONS requests. Support specific capabilities using, among others, OPTIONS requests. Support
for Globally Routable User Agent URIs (GRUU) according to [RFC5627] for Globally Routable User Agent URIs (GRUU) according to [RFC5627]
on the other hand allows SIP requests to be addressed to specific UAs on the other hand allows SIP requests to be addressed to specific UAs
(as opposed to arbitrary instances of an address of record). (as opposed to arbitrary instances of an address of record).
Combining the two and using the "trickle-ice" option tag defined in Combining the two and using the "trickle-ice" option tag defined in
Section 10.6 provides SIP UAs with a way of learning the capabilities Section 10.6 provides SIP UAs with a way of learning the capabilities
of specific SIP UA instances and then addressing them directly with of specific SIP UA instances and then addressing them directly with
INVITE requests that require Trickle ICE support. INVITE requests that require Trickle ICE support.
Such learning of capabilities may happen in different ways. One Such learning of capabilities may happen in different ways. One
option for a SIP UA would be to learn the GRUU instance ID of a peer option for a SIP UA is to learn the GRUU instance ID of a peer
through presence and then to query its capabilities with an OPTIONS through presence and then to query its capabilities with an OPTIONS
request. Alternatively, it can also just send an OPTIONS request to request. Alternatively, it can also just send an OPTIONS request to
the AOR it intends to contact and then inspect the returned the AOR it intends to contact and then inspect the returned
response(s) for support of both GRUU and Trickle ICE (Figure 10). It response(s) for support of both GRUU and Trickle ICE (Figure 10). It
is noted that using the GRUU means that the INVITE request can go is noted that using the GRUU means that the INVITE request can go
only to that particular device. This circumvents to use of forking only to that particular device. This prevents the use of forking for
for that request. that request.
Alice Bob Alice Bob
| | | |
| OPTIONS sip:b1@example.com SIP/2.0 | | OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->| |-------------------------------------------------->|
| | | |
| 200 OK | | 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a | | Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... | | ;audio;video|;trickle-ice;... |
|<--------------------------------------------------| |<--------------------------------------------------|
skipping to change at page 23, line 39 skipping to change at page 23, line 41
the options to engage in Full Trickle negotiation (as opposed to the the options to engage in Full Trickle negotiation (as opposed to the
more lengthy Half Trickle) from the very first Offer they send. more lengthy Half Trickle) from the very first Offer they send.
5.3. Fall-back to Half Trickle 5.3. Fall-back to Half Trickle
In cases where none of the other mechanisms in this section are In cases where none of the other mechanisms in this section are
acceptable, SIP UAs should use the Half Trickle mode defined in acceptable, SIP UAs should use the Half Trickle mode defined in
[I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions
the same way they would when using 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 first gather ICE candidates in a blocking
blocking way and then send them all in that Offer. The blocking way and then send them all in that Offer. The blocking nature of the
nature of the process would likely imply that some amount of latency process implies that some amount of latency will be accumulated and
will be accumulated and it is advised that agents try to anticipate it is advised that agents try to anticipate it where possible, for
it where possible, like for example, when user actions indicate a example, when user actions indicate a high likelihood for an imminent
high likelihood for an imminent call (e.g., activity on a keypad or a 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 results in Offers that are compatible with both
both ICE SIP endpoints and legacy [RFC3264] endpoints. 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 24, line 47 skipping to change at page 24, line 47
| | | | | | | |
Figure 11: 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
to give some guidance to implementors on how trickling can be to give some guidance to implementors on how trickling can be
optimized with respect to providing RTCP candidates. optimized with respect to providing RTCP candidates.
Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux"
attribute for RTP/RTCP multiplexing [RFC5761] is already considered attribute for RTP/RTCP multiplexing [RFC5761] is already considered
in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in in section 5.1.1.1. of [I-D.ietf-ice-rfc5245bis] and as well in
[RFC5761] itself. These considerations are still valid for Trickle [RFC5761] itself. These considerations are still valid for Trickle
ICE, however, trickling provides more flexibility for the sequence of ICE, however, trickling provides more flexibility for the sequence of
candidate exchange in case of RTCP multiplexing. candidate exchange in case of RTCP multiplexing.
[RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct [RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct
for version 15 of said I-D. Authors need to cross-check during for version 15 of said I-D. Authors need to cross-check during
Auth48 since it could have have changed in the meantime.] Auth48 since it could have have changed in the meantime.]
If the Offerer supports RTP/RTCP multiplexing exclusively as If the Offerer supports RTP/RTCP multiplexing exclusively as
specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that
document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" document apply for the handling of the "a=rtcp-mux-only", "a=rtcp"
and the "a=rtcp-mux" attributes. and the "a=rtcp-mux" attributes.
While a Half Trickle Offerer would have to send an Offer compliant to While a Half Trickle Offerer has to send an Offer compliant to
[I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for
all components, this flexibility allows a Full Trickle Offerer to all components, the flexibility of a Full Trickle Offerer allows to
send only RTP candidates (component 1) in the initial Offer if it send only RTP candidates (component 1) in the initial Offer assuming
assumes that RTCP multiplexing is supported by the Answerer. A Full that RTCP multiplexing is supported by the Answerer. A Full Trickle
Trickle Offerer would need to start gathering and trickling RTCP Offerer would need to start gathering and trickling RTCP candidates
candidates (component 2) only after having received an indication in (component 2) only after having received an indication in the Answer
the Answer that the Answerer unexpectedly does not support RTCP that the Answerer unexpectedly does not support RTCP multiplexing.
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 if it supports and uses RTP the application/trickle-ice-sdpfrag body if it supports and uses RTP
and RTCP multiplexing. The Trickle Answerer needs to follow the and RTCP multiplexing. The Trickle Answerer needs to follow the
guidance on the usage of the "a=rtcp" attribute as given in guidance on the usage of the "a=rtcp" attribute as given in
[I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this
attribute at the Offerer in an INFO request prior to the Answer attribute at the Offerer in an INFO request prior to the Answer
indicates that the Answerer supports and uses RTP and RTCP indicates that the Answerer supports and uses RTP and RTCP
multiplexing. The Offerer can use this information e.g. for stopping multiplexing. The Offerer can use this information e.g. for stopping
gathering of RTCP candidates and/or for freeing corresponding gathering of RTCP candidates and/or for freeing corresponding
skipping to change at page 26, line 23 skipping to change at page 26, line 23
a=mid:1 a=mid:1
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
Once the dialog is established as described in section Section 4.3 Once the dialog is established as described in section Section 4.3
the Answerer sends the following INFO request. 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/trickle-ice-sdpfrag
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: 161 Content-length: 161
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 1658497382 2001:db8:a0b:12f0::4 6000 typ host a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host
This INFO request indicates that the Answerer supports and uses RTP This INFO request indicates that the Answerer supports and uses RTP
and RTCP multiplexing as well. It allows the Offerer to omit and RTCP multiplexing as well. It allows the Offerer to omit
gathering of RTCP candidates or releasing already gathered RTCP gathering of RTCP candidates or releasing already gathered RTCP
candidates. If the INFO request did not contain the a=rtcp-mux candidates. If the INFO request did not contain the a=rtcp-mux
attribute, the Offerer would have to gather RTCP candidates unless it attribute, the Offerer has to gather RTCP candidates unless it wants
wants to wait until receipt of an Answer that eventually confirms to wait until receipt of an Answer that eventually confirms support
support or non-support for RTP and RTCP multiplexing. or non-support for RTP and RTCP multiplexing.
7. Considerations for Media Multiplexing 7. Considerations for Media Multiplexing
The following considerations describe options for Trickle-ICE in The following considerations describe options for Trickle-ICE in
order to give some guidance to implementors on how trickling can be order to give some guidance to implementors on how trickling can be
optimized with respect to providing candidates in case of Media optimized with respect to providing candidates in case of Media
Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed
that the reader is familiar with that the reader is familiar with
[I-D.ietf-mmusic-sdp-bundle-negotiation]. [I-D.ietf-mmusic-sdp-bundle-negotiation].
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 Except for bundle-only "m=" lines, a Half Trickle Offerer has to send
to send an Offer with candidates for all bundled "m=" lines. The an Offer with candidates for all bundled "m=" lines. The additional
additional flexibility, however, allows a Full Trickle Offerer to flexibility, however, allows a Full Trickle Offerer to initially send
initially send only candidates for the "m=" line with the suggested only candidates for the "m=" line with the suggested Offerer BUNDLE
Offerer BUNDLE address. address.
On receipt of the Answer, the Offerer will detect if BUNDLE is On receipt of the Answer, the Offerer will detect if BUNDLE is
supported by the Answerer and if the suggested Offerer BUNDLE address supported by the Answerer and if the suggested Offerer BUNDLE address
was selected. In this case, the Offerer does not need to trickle was selected. In this case, the Offerer does not need to trickle
further candidates for the remaining "m=" lines in a bundle. further candidates for the remaining "m=" lines in a bundle.
However, if BUNDLE is not supported, the Full Trickle Offerer needs However, if BUNDLE is not supported, the Full Trickle Offerer needs
to gather and trickle candidates for the remaining "m=" lines as to gather and trickle candidates for the remaining "m=" lines as
necessary. If the Answerer selects an Offerer BUNDLE address necessary. If the Answerer selects an Offerer BUNDLE address
different from the suggested Offerer BUNDLE address, the Full Trickle different from the suggested Offerer BUNDLE address, the Full Trickle
Offerer needs to gather and trickle candidates for the "m=" line that Offerer needs to gather and trickle candidates for the "m=" line that
skipping to change at page 28, line 26 skipping to change at page 28, line 26
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
m=video 10002 RTP/AVP 31 m=video 10002 RTP/AVP 31
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
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
The example Offer indicates support for RTP and RTCP multiplexing and The example Offer indicates support for RTP and RTCP multiplexing and
contains a "a=candidate" attribute only for the m-line with the contains a "a=candidate:" attribute only for the m-line with the
suggested Offerer bundle address. Once the dialog is established as suggested Offerer bundle address. Once the dialog is established as
described in Section 4.3 the Answerer sends the following INFO described in Section 4.3 the Answerer sends the following INFO
request. request.
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/sdp Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: 219 Content-length: 219
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:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
skipping to change at page 29, line 15 skipping to change at page 29, line 15
This INFO request 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 Multiplexing as well. Note, that the second "m=" line shows the
default values as specified in section Section 4.4, e.g. media set default values as specified in section Section 4.4, e.g. media set
'audio' although 'video' was offered. The receiving ICE Agents MUST '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 request 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 request 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 has to gather RTP
gather RTP and RTCP candidates for the other "m=" lines unless it and RTCP candidates for the other "m=" lines unless it wants to wait
wants to wait until receipt of an Answer that eventually confirms until receipt of an Answer that eventually confirms support or non-
support or non-support for Media Multiplexing. 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 as specified in Section 9.2 in the Answerer, when putting attributes as specified in Section 9.2 in the
application/trickle-ice-sdpfrag body. application/trickle-ice-sdpfrag body.
8. SDP 'end-of-candidate' Attribute 8. SDP 'end-of-candidates' Attribute
8.1. Definition 8.1. Definition
This section defines a new SDP media-level and session-level This section defines a new SDP media-level and session-level
attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a attribute [RFC4566] 'end-of-candidates'. 'end-of-candidates' is a
property attribute [RFC4566], and hence has no value. By including property attribute [RFC4566], and hence has no value. By including
this attribute in an Offer or Answer the sending agent indicates that this attribute in an Offer or Answer the sending agent indicates that
it will not trickle further candidates. When included at session it will not trickle further candidates. When included at session
level this indication applies to the whole session, when included at level this indication applies to the whole session, when included at
media level the indication applies only to the corresponding media media level the indication applies only to the corresponding media
description. description.
Name: end-of-candidate Name: end-of-candidates
Value: N/A Value: N/A
Usage Level: media and session-level Usage Level: media and session-level
Charset Dependent: no Charset Dependent: no
Mux Category: IDENTICAL Mux Category: IDENTICAL
Example: a=end-of-candidate Example: a=end-of-candidates
8.2. Offer/Answer procedures 8.2. Offer/Answer Procedures
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.
skipping to change at page 30, line 43 skipping to change at page 30, line 43
attributes that are needed and/or useful for trickling candidates. attributes that are needed and/or useful for trickling candidates.
The content adheres to the following grammar. The content adheres to the following grammar.
9.2. Grammar 9.2. Grammar
The grammar of an 'application/trickle-ice-sdpfrag' body is based on The grammar of an 'application/trickle-ice-sdpfrag' body is based on
the following ABNF [RFC5234]. It specifies the subset of existing the following ABNF [RFC5234]. It specifies the subset of existing
SDP attributes, that is needed or useful for trickling candidates. SDP attributes, that is needed or useful for trickling candidates.
The grammar uses the indicator for case-sensitivity %s as defined in The grammar uses the indicator for case-sensitivity %s as defined in
[RFC7405], but also imports grammars for other SDP attributes that [RFC7405], but also imports grammars for other SDP attributes that
precede the production of [RFC7405]. A sender SHOULD stick to lower- precede the production of [RFC7405]. A sender SHOULD use lower-case
case for such grammars, but a receiver MUST treat them case- for attributes from such earlier grammars, but a receiver MUST treat
insensitive. them case-insensitively.
; Syntax ; Syntax
trickle-ice-sdpfrag = session-level-fields trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions pseudo-media-descriptions
session-level-fields = [bundle-group-attribute CRLF] session-level-fields = [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]
skipping to change at page 32, line 19 skipping to change at page 32, line 19
10. Info Package 10. Info Package
10.1. Rationale - Why INFO? 10.1. Rationale - Why INFO?
The decision to use SIP INFO requests as a candidate transport method The decision to use SIP INFO requests as a candidate transport method
is based primarily on their lightweight nature. Once a dialog has is based primarily on their lightweight nature. Once a dialog has
been established, INFO requests can be exchanged both ways with no been established, INFO requests can be exchanged both ways with no
restrictions on timing and frequency and no risk of collision. restrictions on timing and frequency and no risk of collision.
On the other hand, using Offer/Answer and UPDATE requests [RFC3311] A critical fact is that the sending of Trickle ICE candidates in one
direction is entirely uncoupled from sending candidates in the other
direction. Thus, the sending of candidates in each direction can be
done by a stream of INFO requests that is not correlated with the
stream of INFO requests in the other direction. And since each INFO
request cumulatively includes the contents of all previous INFO
requests in that direction, ordering between INFO requests need not
be preserved. All of this permits using largely-independent INFO
requests.
Contrarily, UPDATE or other offer/answer mechanisms assume that the
messages in each direction are tightly coupled with messages in the
other direction. Using Offer/Answer and UPDATE requests [RFC3311]
would introduce the following complications: would introduce the following complications:
Blocking of messages: [RFC3264] defines Offer/Answer as a strictly Blocking of messages: [RFC3264] defines Offer/Answer as a strictly
sequential mechanism. There can only be a maximum of one active sequential mechanism. There can only be a maximum of one active
exchange at any point of time. Both sides cannot simultaneously exchange at any point of time. Both sides cannot simultaneously
send Offers nor can they generate multiple Offers prior to send Offers nor can they generate multiple Offers prior to
receiving an Answer. Using UPDATE requests for candidate receiving an Answer. Using UPDATE requests for candidate
transport would therefore imply the implementation of a candidate transport would therefore imply the implementation of a candidate
pool at every agent where candidates can be stored until it is pool at every agent where candidates can be stored until it is
once again that agent's "turn" to emit an Answer or a new Offer. once again that agent's "turn" to emit an Answer or a new Offer.
skipping to change at page 32, line 42 skipping to change at page 33, line 5
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 implies that the duration of Trickle ICE processing
only fail to improve but actually exceed those of regular ICE. would not 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
skipping to change at page 34, line 22 skipping to change at page 34, line 38
type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 in
SIP INFO requests. The payload is used to convey SDP-encoded ICE SIP INFO requests. The payload is used to convey SDP-encoded ICE
candidates. candidates.
10.8. Info Package Usage Restrictions 10.8. Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions. This document does not define any Info Package Usage Restrictions.
10.9. Rate of INFO Requests 10.9. Rate of INFO Requests
A Trickle ICE Agent with many network interfaces might create a high Given that IP addresses may be gathered rapidly a Trickle ICE Agent
rate of INFO requests if every newly detected candidate is trickled with many network interfaces might create a high rate of INFO
individually without aggregation. Implementors that are concerned requests if every newly detected candidate is trickled individually
about loss of packets in such a case might consider aggregating ICE without aggregation. Implementors MUST consider aggregating ICE
candidates and sending INFOs only at some configurable intervals. candidates in case that UDP is used as transport protocol and send
INFOs only at some configurable intervals.
If the INFO requests are sent on top of TCP, which is probably the
standard way, this is not an issue for the network anymore, but it
can remain one for SIP proxies and other intermediaries forwarding
the SIP INFO messages. Also, an endpoint may not be able to tell
that it has congestion controlled transport all the way.
10.10. Info Package Security Considerations 10.10. Info Package Security Considerations
See Section 13 See Section 13
11. Deployment Considerations 11. Deployment Considerations
Trickle ICE uses two mechanism for exchange of candidate information. Trickle ICE uses two mechanism for exchange of candidate information.
This imposes new requirements to certain middleboxes that are used in This imposes new requirements to certain middleboxes that are used in
some networks, e.g. for monitoring purposes. While the first some networks, e.g. for monitoring purposes. While the first
skipping to change at page 35, line 5 skipping to change at page 35, line 26
bodies, needs to be considered by such middleboxes as well when bodies, needs to be considered by such middleboxes as well when
trickle ICE is used. Such middleboxes need to make sure that they trickle ICE is used. Such middleboxes need to make sure that they
remain in the signaling path of the INFO requests and need to remain in the signaling path of the INFO requests and need to
understand the INFO request body. understand the INFO request body.
12. IANA Considerations 12. IANA Considerations
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document. ] document. ]
12.1. SDP 'end-of-candidate' Attribute 12.1. SDP 'end-of-candidates' Attribute
This section defines a new SDP media-level and session-level This section defines a new SDP media-level and session-level
attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a attribute [RFC4566] , 'end-of-candidates'. 'end-of-candidates' is a
property attribute [RFC4566] , and hence has no value. property attribute [RFC4566] , and hence has no value.
Name: end-of-candidate Name: end-of-candidates
Value: N/A Value: N/A
Usage Level: media and session Usage Level: media and session
Charset Dependent: no Charset Dependent: no
Purpose: The sender indicates that it will not trickle Purpose: The sender indicates that it will not trickle
further ICE candidates. further ICE candidates.
O/A Procedures: RFCXXX defines the detailed O/A Procedures: RFCXXX defines the detailed
SDP Offer/Answer procedures for SDP Offer/Answer procedures for
the 'end-of-candidate' attribute. the 'end-of-candidates' attribute.
Mux Category: IDENTICAL Mux Category: IDENTICAL
Reference: RFCXXXX Reference: RFCXXXX
Example: Example:
a=end-of-candidate a=end-of-candidates
12.2. application/trickle-ice-sdpfrag Media Type 12.2. Media Type 'application/trickle-ice-sdpfrag'
This section defines a new Media Type 'application/trickle-ice- This document defines a new Media Type 'application/trickle-ice-
sdpfrag' in accordance with [RFC6838]. sdpfrag' in accordance with [RFC6838].
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:
SDP files are primarily UTF-8 format text. Although the The media contents follow the same rules as SDP, except as
initially defined content of a trickle-ice-sdpfrag body does noted in this document. The media contents are text, with the
only include ASCII characters, UTF-8 encoded content might be grammar specified in Section 9.2.
introduced via extension attributes. The "a=charset:"
Although the initially defined content of a trickle-ice-sdpfrag
body does only include ASCII characters, UTF-8 encoded content
might be introduced via extension attributes. The "a=charset:"
attribute may be used to signal the presence of other character attribute may be used to signal the presence of other character
sets in certain parts of a trickle-ice-sdpfrag body (see sets in certain parts of a trickle-ice-sdpfrag body (see
[RFC4566]). Arbitrary binary content cannot be directly [RFC4566]). Arbitrary binary content cannot be directly
represented in SDP or a trickle-ice-sdpfrag body. represented in SDP or a trickle-ice-sdpfrag body.
Security considerations: Security considerations:
See [RFC4566] and RFCXXXX See [RFC4566] and RFCXXXX
Interoperability considerations: Interoperability considerations:
skipping to change at page 37, line 34 skipping to change at page 38, line 32
+-------------+-----------+ +-------------+-----------+
| Name | Reference | | Name | Reference |
+-------------+-----------+ +-------------+-----------+
| trickle-ice | [RFCXXXX] | | trickle-ice | [RFCXXXX] |
| | | | | |
+-------------+-----------+ +-------------+-----------+
12.4. SIP Option Tag 'trickle-ice' 12.4. SIP Option Tag 'trickle-ice'
This specification registers a new SIP option tag 'trickle-ice' as This specification registers a new SIP option tag 'trickle-ice' as
per the guidelines in Section 27.1 of [RFC3261] and updates the per the guidelines in Section 27.1 of [RFC3261] and updates the
"Option Tags" section of the SIP Parameter Registry with the "Option Tags" section of the SIP Parameter Registry with the
following entry: following entry:
+-------------+-------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+-------------+-------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
| trickle-ice | This option tag is used to indicate | [RFCXXXX] | | trickle-ice | This option tag is used to indicate | [RFCXXXX] |
| | that a UA supports and understands | | | | that a UA supports and understands | |
| | Trickle-ICE. | | | | Trickle-ICE. | |
+-------------+-------------------------------------+-----------+ +-------------+-------------------------------------+-----------+
skipping to change at page 38, line 21 skipping to change at page 39, line 16
The new Info Package 'trickle-ice' and the new Media Type The new Info Package 'trickle-ice' and the new Media Type
'application/trickle-ice-sdpfrag' do not introduce additional 'application/trickle-ice-sdpfrag' do not introduce additional
security considerations when used in the context of Trickle ICE. security considerations when used in the context of Trickle ICE.
Both are not intended to be used for other applications, so any Both are not intended to be used for other applications, so any
security considerations for its use in other contexts is out of the security considerations for its use in other contexts is out of the
scope of this document scope of this document
14. Acknowledgements 14. Acknowledgements
The authors would like to thank Flemming Andreasen, Ayush Jain, Paul The authors like to thank Flemming Andreasen, Ayush Jain, Paul
Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin Kyzivat, Jonathan Lennox, Simon Perreault, Roman Shpount and Martin
Thomson for reviewing and/or making various suggestions for Thomson for reviewing and/or making various suggestions for
improvements and optimizations. improvements and optimizations.
The authors would also like to thank Flemming Andreasen for The authors also like to thank Flemming Andreasen for shepherding
shepherding this document and Ben Campbell for his AD review and this document and Ben Campbell for his AD review and suggestions.
suggestions.
Many thanks to Dale Worley for Gen-Art review and proposed
enhancements for several sections.
Many thanks to Joerg Ott for TSV-Art review and suggested
improvements.
The authors thank Shawn Emery for Security Directorate review.
15. Change Log 15. 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 41, line 38 skipping to change at page 42, line 45
o Corrected default values in m-line and usage of "a=mid:" attribute o Corrected default values in m-line and usage of "a=mid:" attribute
explicitly mentioned for offer/answer explicitly mentioned for offer/answer
o Removed explicit mentioning of XMPP o Removed explicit mentioning of XMPP
o Added Deployment Considerations section o Added Deployment Considerations section
o Fixed ref for rfc5245bis o Fixed ref for rfc5245bis
Changes from draft-ietf-mmusic-trickle-ice-sip-12
o addressing comments from Gen-Art review, TSV-Art review and
Security Directorate review
o Numerous editorial improvements/corrections/clarifications
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-15 (work in progress), November 2017. rfc5245bis-17 (work in progress), February 2018.
[I-D.ietf-ice-trickle] [I-D.ietf-ice-trickle]
Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
"Trickle ICE: Incremental Provisioning of Candidates for "Trickle ICE: Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (ICE) the Interactive Connectivity Establishment (ICE)
Protocol", draft-ietf-ice-trickle-15 (work in progress), Protocol", draft-ietf-ice-trickle-16 (work in progress),
November 2017. February 2018.
[I-D.ietf-mmusic-ice-sip-sdp] [I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, Petit-Huguenin, M., 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-16 (work in (ICE)", draft-ietf-mmusic-ice-sip-sdp-16 (work in
progress), November 2017. progress), November 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-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-43 (work in progress), December 2017. negotiation-48 (work in progress), January 2018.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 101 change blocks. 
196 lines changed or deleted 251 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/