draft-ietf-mmusic-trickle-ice-sip-03.txt   draft-ietf-mmusic-trickle-ice-sip-04.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: April 4, 2016 Unaffiliated Expires: November 18, 2016 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
October 2, 2015 May 17, 2016
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-03 draft-ietf-mmusic-trickle-ice-sip-04
Abstract Abstract
The Interactive Connectivity Establishment (ICE) protocol describes a The Interactive Connectivity Establishment (ICE) protocol describes a
Network Address Translator (NAT) traversal mechanism for UDP-based Network Address Translator (NAT) traversal mechanism for UDP-based
multimedia sessions established with the Offer/Answer model. The ICE multimedia sessions established with the Offer/Answer model. The ICE
extension for Incremental Provisioning of Candidates (Trickle ICE) extension for Incremental Provisioning of Candidates (Trickle ICE)
defines a mechanism that allows ICE agents to shorten session defines a mechanism that allows ICE agents to shorten session
establishment delays by making the candidate gathering and establishment delays by making the candidate gathering and
connectivity checking phases of ICE non-blocking and by executing connectivity checking phases of ICE non-blocking and by executing
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2016. This Internet-Draft will expire on November 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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. Rationale. Why INFO . . . . . . . . . . . . . . . . . . . 5 3.1. Rationale - Why INFO? . . . . . . . . . . . . . . . . . . 5
3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 6 3.2. Discovery issues . . . . . . . . . . . . . . . . . . . . 6
3.3. Relationship with the Offer/Answer Model . . . . . . . . 7 3.3. Relationship with the Offer/Answer Model . . . . . . . . 7
4. Incremental Signalling of ICE candidates . . . . . . . . . . 9 4. Incremental Signalling of ICE candidates . . . . . . . . . . 9
4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 9 4.1. Establishing the dialog . . . . . . . . . . . . . . . . . 9
4.1.1. Asserting dialog state through reliable Offer/Answer 4.1.1. Asserting dialog state through reliable Offer/Answer
delivery . . . . . . . . . . . . . . . . . . . . . . 9 delivery . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Asserting dialog state through unreliable 4.1.2. Asserting dialog state through unreliable
Offer/Answer delivery . . . . . . . . . . . . . . . . 10 Offer/Answer delivery . . . . . . . . . . . . . . . . 10
4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 12 4.1.3. Initiating Trickle ICE without an SDP Answer . . . . 12
4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 13 4.1.4. Considerations for 3PCC . . . . . . . . . . . . . . . 13
4.2. Delivering candidates in INFO messages . . . . . . . . . 15 4.2. Delivering candidates in INFO messages . . . . . . . . . 15
5. Initial discovery of Trickle ICE support . . . . . . . . . . 18 5. Initial discovery of Trickle ICE support . . . . . . . . . . 18
5.1. Provisioning support for Trickle ICE . . . . . . . . . . 18 5.1. Provisioning support for Trickle ICE . . . . . . . . . . 18
5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19 5.2. Trickle ICE discovery with GRUU . . . . . . . . . . . . . 19
5.3. Trickle ICE discovery through other protocols . . . . . . 20 5.3. Trickle ICE discovery through other protocols . . . . . . 20
5.4. Fallback to Half Trickle . . . . . . . . . . . . . . . . 20 5.4. Fall-back to Half Trickle . . . . . . . . . . . . . . . . 20
6. Considerations for RTP and RTCP multiplexing . . . . . . . . 22 6. Considerations for RTP and RTCP multiplexing . . . . . . . . 22
7. Considerations for Media Multiplexing . . . . . . . . . . . . 23 7. Considerations for Media Multiplexing . . . . . . . . . . . . 23
8. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 25 8. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 26
8.1. Overall Description . . . . . . . . . . . . . . . . . . . 25 8.1. Overall Description . . . . . . . . . . . . . . . . . . . 26
8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 27 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 28
9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 28
9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 27 9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 28
9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 27 9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 28
9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 27 9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 28
9.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 28 9.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 29
9.7. Info Package Usage Restrictions . . . . . . . . . . . . . 28 9.7. Info Package Usage Restrictions . . . . . . . . . . . . . 29
9.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 28 9.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 29
9.9. Info Package Security Considerations . . . . . . . . . . 28 9.9. Info Package Security Considerations . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10.1. application/trickle-ice-sdpfrag MIME Type . . . . . . . 28 10.1. application/trickle-ice-sdpfrag MIME Type . . . . . . . 29
10.2. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 30 10.2. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 31
10.3. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 30 10.3. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 31
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 33 14.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The Interactive Connectivity Establishment protocol [RFC5245] (a.k.a. The Interactive Connectivity Establishment protocol
Vanilla ICE) describes a mechanism for NAT traversal that consists of [I-D.ietf-mmusic-rfc5245bis] (a.k.a. Vanilla ICE) describes a
three main phases: a phase where an agent gathers a set of candidate mechanism for NAT traversal that consists of three main phases: a
transport addresses (source IP address, port and transport protocol), phase where an agent gathers a set of candidate transport addresses
a second phase where these candidates are sent to a remote agent and (source IP address, port and transport protocol), a second phase
this gathering procedure is repeated and, finally, a third phase where these candidates are sent to a remote agent and this gathering
where connectivity between all candidates in both sets is checked procedure is repeated and, finally, a third phase where connectivity
(connectivity checks). Once these phases have been completed, and between all candidates in both sets is checked (connectivity checks).
only then, can both agents begin communication. According to the Once these phases have been completed, and only then, can both agents
Vanilla ICE specification the three phases above happen begin communication. According to the Vanilla ICE specification the
consecutively, in a blocking way, which can introduce undesirable three phases above happen consecutively, in a blocking way, which can
latency during session establishment. introduce undesirable latency during session establishment.
The Trickle ICE extension defined in [I-D.ietf-mmusic-trickle-ice] The Trickle ICE extension defined in [I-D.ietf-mmusic-trickle-ice]
defines generic semantics required for these ICE phases to happen defines generic semantics required for these ICE phases to happen
simultaneously, in a non-blocking way and hence speed up session simultaneously, in a non-blocking way and hence speed up session
establishment. establishment.
This specification defines a usage of Trickle ICE with the Session This specification defines a usage of Trickle ICE with the Session
Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates
are to be incrementally exchanged with SIP INFO requests and how the are to be incrementally exchanged with SIP INFO requests and how the
Half Trickle and Full Trickle modes defined in Half Trickle and Full Trickle modes defined in
skipping to change at page 4, line 12 skipping to change at page 4, line 12
This document defines a new Info Package as specified in [RFC6086] This document defines a new Info Package as specified in [RFC6086]
for use with Trickle ICE. for use with Trickle ICE.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification makes use of all terminology defined by the This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in [RFC5245] and protocol for Interactive Connectivity Establishment in
its Trickle ICE extension [I-D.ietf-mmusic-trickle-ice]. It is [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension
assumed that the reader will be familiar with the terminology from [I-D.ietf-mmusic-trickle-ice]. It is assumed that the reader will be
both of them. familiar with the terminology from both of them.
3. Protocol Overview 3. Protocol Overview
The semantics that Vanilla ICE [RFC5245] defines for exchanging ICE The semantics that Vanilla ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]
candidates are exclusively based on use of Offers and Answers as per defines for exchanging ICE candidates are exclusively based on use of
[RFC3264] over the Session Description Protocol (SDP) [RFC4566]. Offers and Answers as per [RFC3264] over the Session Description
This specification extends these mechanism by allowing ICE candidates Protocol (SDP) [RFC4566]. This specification extends these mechanism
to also be sent in parallel to the Offer/Answer negotiation or after by allowing ICE candidates to also be sent in parallel to the Offer/
the completion of Offer/Answer negotiation. This extension is done Answer negotiation or after the completion of Offer/Answer
through the use of SIP INFO messages and a newly defined Info Package negotiation. This extension is done through the use of SIP INFO
[RFC6086]. messages and a newly defined Info Package [RFC6086].
Typically, in cases where Trickle ICE is fully supported, a candidate Typically, in cases where Trickle ICE is fully supported, a candidate
exchange would happen along the following lines: The Offerer would exchange would happen along the following lines: The Offerer would
send an INVITE containing a subset of candidates and then wait for an send an INVITE containing a subset of candidates and then wait for an
early dialog to be established. Once that happens, it will be able early dialog to be established. Once that happens, it will be able
to continue sending candidates through in INFO requests and within to continue sending candidates through in INFO requests and within
the same dialog. the same dialog.
Similarly, an Answerer can start or continue "trickling" ICE Similarly, an Answerer can start or continue "trickling" ICE
candidates using INFO messages within the dialog established by its candidates using INFO messages within the dialog established by its
skipping to change at page 5, line 37 skipping to change at page 5, line 37
| | 200 OK | | | | 200 OK | |
| |<------------------------| | | |<------------------------| |
| | ACK | | | | ACK | |
| |------------------------>| | | |------------------------>| |
| | | | | | | |
| |<===== MEDIA FLOWS =====>| | | |<===== MEDIA FLOWS =====>| |
| | | | | | | |
Figure 1: Sample Trickle ICE scenario with SIP Figure 1: Sample Trickle ICE scenario with SIP
3.1. Rationale. Why INFO 3.1. Rationale - Why INFO?
The decision to use SIP INFO requests as a candidate transport method The decision to use SIP INFO requests as a candidate transport method
is based primarily on their lightweight nature. Once a dialog has is based primarily on their lightweight nature. Once a dialog has
been established, INFO messages can be exchanged both ways with no been established, INFO messages can be exchanged both ways with no
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, which from On the other hand, using Offer/Answer and UPDATE requests, which from
an [RFC5245] perspective is the traditional way of transporting ICE an [I-D.ietf-mmusic-ice-sip-sdp] perspective is the traditional way
candidates, introduces the following complications: of transporting ICE candidates, introduces the following
complications:
Need for a non-blocking mechanism: [RFC3264] defines Offer/Answer Need for a non-blocking mechanism: [RFC3264] defines Offer/Answer
as a strictly sequential mechanism. There can only be a maximum as a strictly sequential mechanism. There can only be a maximum
of one exchange at any point of time. Both sides cannot of one exchange at any point of time. Both sides cannot
simultaneously send Offers nor can they generate multiple Offers simultaneously send Offers nor can they generate multiple Offers
prior to receiving an Answer. Using UPDATEs for candidate prior to receiving an Answer. Using UPDATEs 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.
Such an approach would introduce non-negligible complexity for no Such an approach would introduce non-negligible complexity for no
additional value. additional value.
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 backoff likelihood for glare to occur and the average two second back-off
intervals would imply Trickle ICE processing duration would not intervals would imply Trickle ICE processing duration would not
only fail to improve but actually exceed those of Vanilla ICE. only fail to improve but actually exceed those of Vanilla 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
skipping to change at page 7, line 27 skipping to change at page 7, line 29
anticipatory discovery for implementations that actually do support anticipatory discovery for implementations that actually do support
GRUU and UA Capabilities and Section 5.4 discusses the implementation GRUU and UA Capabilities and Section 5.4 discusses the implementation
and use of Half Trickle by SIP UAs where none of the above are an and use of Half Trickle by SIP UAs where none of the above are an
option. option.
3.3. Relationship with the Offer/Answer Model 3.3. Relationship with the Offer/Answer Model
It is important to note that this specification does not require, It is important to note that this specification does not require,
define, or even assume any mechanisms that would have an impact on define, or even assume any mechanisms that would have an impact on
the Offer/Answer model beyond the way it is already used by Vanilla the Offer/Answer model beyond the way it is already used by Vanilla
ICE [RFC5245]. From the perspective of all SIP middle boxes and ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. From the perspective of
proxies, and with the exception of the actual INFO messages, all SIP middle boxes and proxies, and with the exception of the
signalling in general and Offer/Answer exchanges in particular would actual INFO messages, signalling in general and Offer/Answer
look the same way for Trickle ICE as they would for Vanilla ICE. exchanges in particular would look the same way for Trickle ICE as
they would for Vanilla ICE for SIP.
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob | | Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | | | | Offer/Answer | |
| +-------+ | Module | | | | Module | +-------+ | | +-------+ | Module | | | | Module | +-------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | | | | ICE | +--------------+ | | +--------------+ | ICE | |
| | Agent | | | | | | Agent | | | | Agent | | | | | | Agent | |
| +-------+ | | | | +-------+ | | +-------+ | | | | +-------+ |
+-------------------------------+ +-------------------------------+ +-------------------------------+ +-------------------------------+
| | | | | | | |
skipping to change at page 10, line 19 skipping to change at page 10, line 19
|<------------------------| |<------------------------|
| PRACK/OK | | PRACK/OK |
|------------------------>| |------------------------>|
| | | |
+----------------------------------------+ +----------------------------------------+
|Alice and Bob know that both can trickle| |Alice and Bob know that both can trickle|
|and know that the dialog is in the early| |and know that the dialog is in the early|
|state. Send INFO! | |state. Send INFO! |
+----------------------------------------+ +----------------------------------------+
| | | |
| INFO/OK (SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|------------------------>| |------------------------>|
| INFO/OK (SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|<------------------------| |<------------------------|
| | | |
Figure 3: SIP Offerer can freely trickle as soon as it receives an Figure 3: SIP Offerer can freely trickle as soon as it receives an
Answer. Answer.
Satisfying both conditions is also relatively trivial for ICE agents Satisfying both conditions is also relatively trivial for ICE agents
that have sent an Offer in an INVITE and that have received an Answer that have sent an Offer in an INVITE and that have received an Answer
in a reliable provisional response. It is guaranteed to have in a reliable provisional response. It is guaranteed to have
confirmed support for Trickle ICE within the Answerer (or lack confirmed support for Trickle ICE within the Answerer (or lack
skipping to change at page 11, line 27 skipping to change at page 11, line 27
| | Can I send INFO??? | | | Can I send INFO??? |
| +----------------------+ | +----------------------+
| | | |
Figure 4: A SIP UA that sent an Answer in an unreliable provisional Figure 4: A SIP UA that sent an Answer in an unreliable provisional
response does not know if it was received and if the dialog at the response does not know if it was received and if the dialog at the
side of the Offerer has entered the early state side of the Offerer has entered the early state
In order to clear this ambiguity as soon as possible, the answerer In order to clear this ambiguity as soon as possible, the answerer
needs to retransmit the provisional response with the exponential needs to retransmit the provisional response with the exponential
backoff timers described in [RFC3262]. Retransmits MUST cease on back-off timers described in [RFC3262]. Retransmits MUST cease on
receipt of a INFO request or on transmission of the answer in a 2xx receipt of a INFO request or on transmission of the answer in a 2xx
response. This is similar to the procedure described in section response. This is similar to the procedure described in section
12.1.1 of [RFC5245] except that the STUN binding Request is replaced 13.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding
by the INFO request. Request is replaced by the INFO request.
The Offerer MUST send a Trickle ICE INFO request as soon as they The Offerer MUST send a Trickle ICE INFO request as soon as it
receive an SDP Answer in an unreliable provisional response. This receives an SDP Answer in an unreliable provisional response. This
INFO message can repeat the candidates that were already provided in INFO message MUST repeat the candidates that were already provided in
the Offer (as would be the case when Half Trickle is performed or the Offer (as would be the case when Half Trickle is performed or
when new candidates have not been learned since then) and/or they MAY when new candidates have not been learned since then) and/or they MAY
also deliver new candidates (if available). An end-of-candidates also deliver new candidates (if available). An end-of-candidates
indication MAY be included in case candidate discovery has ended in indication MAY be included in case candidate discovery has ended in
the mean time. the mean time.
As soon as an Answerer has received such an INFO request, the As soon as an Answerer has received such an INFO request, the
Answerer has an indication that a dialog is well established at both Answerer has an indication that a dialog is well established at both
ends and MAY begin trickling (Figure 5). ends and MAY begin trickling (Figure 5). Note: The +SRFLX in
Figure 5 indicates that additionally newly learned server-reflexive
candidates are includes.
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (Answer) | | 183 (Answer) |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|------------------------>| |------------------------>|
| | | |
| +----------------------+ | +----------------------+
| |Bob: Now I know Alice| | |Bob: Now I know Alice|
| | is ready. Send INFO! | | | is ready. Send INFO! |
| +----------------------+ | +----------------------+
| INFO/OK (SRFLX Cand.) | | INFO/OK (+SRFLX Cand.) |
|<------------------------| |<------------------------|
| | | |
| 200/ACK (Answer) | | 200/ACK (Answer) |
|<------------------------| |<------------------------|
Figure 5: A SIP UA that received an INFO request after sending an Figure 5: A SIP UA that received an INFO request after sending an
unreliable provisional response knows that the dialog at the side of unreliable provisional response knows that the dialog at the side of
the receiver has entered the early state the receiver has entered the early state
When sending the Answer in the 200 OK response, the Answerer MUST When sending the Answer in the 200 OK response, the Answerer MUST
skipping to change at page 12, line 44 skipping to change at page 12, line 44
4.1.3. Initiating Trickle ICE without an SDP Answer 4.1.3. Initiating Trickle ICE without an SDP Answer
The possibility to convey arbitrary candidates in INFO message bodies The possibility to convey arbitrary candidates in INFO message bodies
allows ICE agents to initiate trickling without actually sending an allows ICE agents to initiate trickling without actually sending an
Answer. Trickle ICE Agents MAY therefore respond to INVITEs with Answer. Trickle ICE Agents MAY therefore respond to INVITEs with
provisional responses without an SDP Answer. Such provisional provisional responses without an SDP Answer. Such provisional
responses serve for establishing an early dialog. 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 backoff timers retransmit these responses 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. This is request or on transmission of the answer in a 2xx response. This is
again similar to the procedure described in section 12.1.1 of again similar to the procedure described in section 12.1.1 of
[RFC5245] except that an Answer is not yet provided. [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet
provided.
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
|<------------------------| |<------------------------|
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|------------------------>| |------------------------>|
| | | |
skipping to change at page 14, line 39 skipping to change at page 14, line 39
Figure 7: A SIP Offerer in a 3PCC scenario can also freely start Figure 7: A SIP Offerer in a 3PCC scenario can also freely start
trickling as soon as it receives an Answer. trickling as soon as it receives an Answer.
Trickle Agents that send an Offer in a 200 OK and receive an Answer Trickle Agents that send an Offer in a 200 OK and receive an Answer
in an ACK can still create a dialog and confirm support for Trickle in an ACK can still create a dialog and confirm support for Trickle
ICE by sending an unreliable provisional response similar to ICE by sending an unreliable provisional response similar to
Section 4.1.3. According to [RFC3261], this unreliable response MUST Section 4.1.3. According to [RFC3261], this unreliable response MUST
NOT contain an Offer. NOT contain an Offer.
The Trickle Agent (at the UAS) retransmits the provisional response The Trickle Agent (at the UAS) retransmits the provisional response
with the exponential backoff timers described in [RFC3262]. with the exponential back-off timers described in [RFC3262].
Retransmits MUST cease on receipt of a INFO request or on Retransmits MUST cease on receipt of a INFO request or on
transmission of the answer in a 2xx response. The peer Trickle Agent transmission of the answer in a 2xx response. The peer Trickle Agent
(at the UAC) MUST send a Trickle ICE INFO request as soon as they (at the UAC) MUST send a Trickle ICE INFO request as soon as they
receive an unreliable provisional response (see Figure 8). receive an unreliable provisional response (see Figure 8).
Alice Bob Alice Bob
| | | |
| INVITE | | INVITE |
|------------------------>| |------------------------>|
| 183 (-) | | 183 (-) |
skipping to change at page 17, line 8 skipping to change at page 17, line 8
from [RFC5888], it does not define any grouping semantics. from [RFC5888], it does not define any grouping semantics.
Consequently, using the "a=group:" attribute from that same Consequently, using the "a=group:" attribute from that same
specification is neither needed nor used in Trickle ICE for SIP. specification is neither needed nor used in Trickle ICE for SIP.
All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:"
attributes that would allow mapping them to a specific ICE attributes that would allow mapping them to a specific ICE
generation. INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" generation. INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:"
attributes that do not match those of the current ICE processing attributes that do not match those of the current ICE processing
session MUST be discarded. The "a=ice-pwd:" and "a=ice-ufrag:" session MUST be discarded. The "a=ice-pwd:" and "a=ice-ufrag:"
attributes MUST appear at the same level as the ones in the Offer/ attributes MUST appear at the same level as the ones in the Offer/
Answer exchange. In other words, if they were present as sesssion- Answer exchange. In other words, if they were present as session-
level attributes there, they will also appear at the beginning of all level attributes there, they will also appear at the beginning of all
INFO message payloads, preceding all "a=mid:" attributes. If they INFO message payloads, preceding all "a=mid:" attributes. If they
were originally exchanged as media level attributes, potentially were originally exchanged as media level attributes, potentially
overriding session-level values, then they will also be included in overriding session-level values, then they will also be included in
INFO message payloads, following the corresponding "a=mid:" INFO message payloads, following the corresponding "a=mid:"
attribute. attribute.
In every INFO request agents MUST include all local candidates they In every INFO request agents MUST include all local candidates they
have previously signalled. This is necessary in order to more easily have previously signaled. This is necessary in order to more easily
avoid problems that would arise from unreliability. Misordering can avoid problems that would arise from unreliability. Mis-ordering can
be detected through the CSeq: header field in the INFO request. be detected through the CSeq: header field in the INFO request.
When receiving INFO requests carrying any candidates, agents will When receiving INFO requests carrying any candidates, agents will
therefore first identify and discard the SDP lines containing therefore first identify and discard the SDP lines containing
candidates they have already received in previous INFO requests or in candidates they have already received in previous INFO requests or in
the Offer/Answer exchange preceding them. Two candidates are the Offer/Answer exchange preceding them. Two candidates are
considered to be equal if their IP address port, transport and considered to be equal if their IP address port, transport and
component ID are the same. After identifying and discarding known component ID are the same. After identifying and discarding known
candidates, agents will then process the remaining, actually new candidates, agents will then process the remaining, actually new
candidates according to the rules described in candidates according to the rules described in
skipping to change at page 20, line 19 skipping to change at page 20, line 19
5.3. Trickle ICE discovery through other protocols 5.3. Trickle ICE discovery through other protocols
Protocols like XMPP [RFC6120] define advanced discovery mechanisms Protocols like XMPP [RFC6120] define advanced discovery mechanisms
that allow specific features to be queried priory to actually that allow specific features to be queried priory to actually
attempting to use them. Solutions like [RFC7081] define ways of attempting to use them. Solutions like [RFC7081] define ways of
using SIP and XMPP together which also provides a way for dual stack using SIP and XMPP together which also provides a way for dual stack
SIP+XMPP endpoints to make use of such features and verify Trickle SIP+XMPP endpoints to make use of such features and verify Trickle
ICE support for a specific SIP endpoint through XMPP. [TODO expand ICE support for a specific SIP endpoint through XMPP. [TODO expand
on a specific way to do this or declare as out of scope] on a specific way to do this or declare as out of scope]
5.4. Fallback to Half Trickle 5.4. Fall-back to Half Trickle
In cases where none of the other mechanisms in this section are In cases where none of the other mechanisms in this section are
acceptable, SIP UAs should use the Half Trickle mode defined in acceptable, SIP UAs should use the Half Trickle mode defined in
[I-D.ietf-mmusic-trickle-ice]. With Half Trickle, agents initiate [I-D.ietf-mmusic-trickle-ice]. With Half Trickle, agents initiate
sessions the same way they would when using Vanilla ICE [RFC5245]. sessions the same way they would when using Vanilla ICE for SIP
This means that, prior to actually sending an Offer, agents would [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually
first gather ICE candidates in a blocking way and then send them all sending an Offer, agents would first gather ICE candidates in a
in that Offer. The blocking nature of the process would likely imply blocking way and then send them all in that Offer. The blocking
that some amount of latency will be accumulated and it is advised nature of the process would likely imply that some amount of latency
that agents try to anticipate it where possible, like for example, will be accumulated and it is advised that agents try to anticipate
when user actions indicate a high likelyhood for an imminent call it where possible, like for example, when user actions indicate a
(e.g., activity on a keypad or a phone going offhook). high likelihood for an imminent call (e.g., activity on a keypad or a
phone going off-hook).
Using Half Trickle would result in Offers that are compatible with Using Half Trickle would result in Offers that are compatible with
both Vanilla ICE and legacy [RFC3264] endpoints. both Vanilla 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 | | |
| | | | | | | |
| | | | | | | |
| Discovery | | | | Discovery | | |
| | | | | | | |
| | | | | | | |
|-------------->| INVITE (Offer) | | |-------------->| INVITE (Offer) | |
| |------------------------>| | | |---------------------------->| |
| | 183 (Answer) |-------------->| | | 183 (Answer) |-------------->|
| |<------------------------| | | |<----------------------------| |
| | | | | | INFO (repeated candidates) | |
| | INFO (more candidates) | Candidate | | |---------------------------->| |
| |<------------------------| | | | | |
| | Connectivity Checks | | | | INFO (more candidates) | Candidate |
| |<=======================>| Discovery | | |<----------------------------| |
| | INFO (more candidates) | | | | Connectivity Checks | |
| |<------------------------| | | |<===========================>| Discovery |
| | Connectivity Checks |<--------------| | | INFO (more candidates) | |
| |<=======================>| | | |<----------------------------| |
| | | | | | Connectivity Checks |<--------------|
| | 200 OK | | | |<===========================>| |
| |<------------------------| | | | | |
| | | | | | 200 OK | |
| | 5245 SIP re-INVITE | | | |<----------------------------| |
| |------------------------>| | | | | |
| | 200 OK | | | | 5245 SIP re-INVITE | |
| |<------------------------| | | |---------------------------->| |
| | | | | | 200 OK | |
| | | | | |<----------------------------| |
| |<===== MEDIA FLOWS =====>| | | | | |
| | | | | | | |
| |<======= MEDIA FLOWS =======>| |
| | | |
Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP Figure 10: 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 RTP and RTCP multiplexing [RFC5761] is already considered Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux"
in sections 4.1.1.1, 4.3, and 5.7.1 of [RFC5245], respectively, as attribute for RTP/RTCP multiplexing [RFC5761] is already considered
in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as
well in [RFC5761] itself. These considerations are still valid for well in [RFC5761] itself. These considerations are still valid for
Trickle ICE, however, trickling provides more flexibility for the Trickle ICE, however, trickling provides more flexibility for the
sequence of candidate exchange in case of RTCP multiplexing. sequence of candidate exchange in case of RTCP multiplexing.
If the Offerer supports RTP/RTCP multiplexing exclusively as
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"
and the "a=rtcp-mux" attributes.
While a Half Trickle Offerer would have to send an offer compliant to While a Half Trickle Offerer would have to send an offer compliant to
[RFC5245] and [RFC5761] including candidates for all components, this [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for
flexibility allows a Full Trickle Offerer to initially send only RTP all components, this flexibility allows a Full Trickle Offerer to
candidates (component 1) if it assumes that RTCP multiplexing is initially send only RTP candidates (component 1) if it assumes that
supported by the Answerer. A Full Trickle Offerer would need to RTCP multiplexing is supported by the Answerer. A Full Trickle
start gathering and trickling RTCP candidates (component 2) only Offerer would need to start gathering and trickling RTCP candidates
after having received an indication in the answer that the answerer (component 2) only after having received an indication in the answer
unexpectedly does not support RTCP multiplexing. that the answerer unexpectedly does not support RTCP multiplexing.
A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in
the application/trickle-ice-sdpfrag body if it supports and uses RTP the application/trickle-ice-sdpfrag body it supports and uses RTP and
and RTCP multiplexing. Receipt of this attribute at the Offerer in RTCP multiplexing. Trickle answerer MUST follow the guidance on the
an INFO request prior to the Answer indicates that the Answerer usage of the "a=rtcp" attribute as given in
supports and uses RTP and RTCP multiplexing. The Offerer can use [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the
this information e.g. for stopping gathering of RTCP candidates and/ Offerer in an INFO request prior to the Answer indicates that the
or for freeing corresponding resources. Answerer supports and uses RTP and RTCP multiplexing. The Offerer
can use this information e.g. for stopping gathering of RTCP
candidates and/or for freeing corresponding resources.
This behaviour is illustrated by the following example offer that This behavior is illustrated by the following example offer that
indicates support for RTP and RTCP multiplexing. indicates support for RTP and RTCP multiplexing.
v=0 v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s= s=
c=IN IP4 atlanta.example.com c=IN IP4 atlanta.example.com
t=0 0 t=0 0
a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8 a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0 m=audio 10000 RTP/AVP 0
skipping to change at page 25, line 37 skipping to change at page 26, line 14
The INFO message also indicates that the Answerer accepted the The INFO message also indicates that the Answerer accepted the
Suggested Bundle Address from the Offerer. This allows the Offerer Suggested Bundle Address from the Offerer. This allows the Offerer
to omit gathering of RTP and RTCP candidates for the other m-lines or to omit gathering of RTP and RTCP candidates for the other m-lines or
releasing already gathered candidates. If the INFO message did not releasing already gathered candidates. If the INFO message did not
contain the a=group:BUNDLE attribute, the Offerer would have to contain the a=group:BUNDLE attribute, the Offerer would have to
gather RTP and RTCP candidates for the other m-lines unless it wants gather RTP and RTCP candidates for the other m-lines unless it wants
to wait until receipt of an Answer that eventually confirms support to wait until receipt of an Answer that eventually confirms support
or non-support for Media Multiplexing. or non-support for Media Multiplexing.
Independent of using Full Trickle or Half Trickle mode, the rules
from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offer and
Answerer, when putting attributes in the application/trickle-ice-
sdpfrag body.
8. Content Type 'application/trickle-ice-sdpfrag' 8. Content Type 'application/trickle-ice-sdpfrag'
8.1. Overall Description 8.1. Overall Description
A application/trickle-ice-sdpfrag body is used by the Trickle-ICE A application/trickle-ice-sdpfrag body is used by the Trickle-ICE
Info Package. It uses a subset of the possible SDP lines that are Info Package. It uses a subset of the possible SDP lines that are
allowed based on the grammar defined in [RFC4566]. A valid body uses allowed based on the grammar defined in [RFC4566]. A valid body uses
only media descriptions and certain attributes that are needed and/or only media descriptions and certain attributes that are needed and/or
useful for trickling candidates. The content adheres to the useful for trickling candidates. The content adheres to the
following grammar. following grammar.
skipping to change at page 26, line 38 skipping to change at page 27, line 33
bundle-semantics = "BUNDLE" bundle-semantics = "BUNDLE"
end-of-candidates-attribute = %s"a=" end-of-candidates-att end-of-candidates-attribute = %s"a=" end-of-candidates-att
extension-attribute-fields = attribute-fields extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields trickle-ice-attribute-fields
[extension-attribute-fields] ) [extension-attribute-fields] )
; for future extensions ; for future extensions
trickle-ice-attribute-fields = mid-attribute CRLF trickle-ice-attribute-fields = mid-attribute CRLF
["a=rtcp-mux" CRLF] ["a=rtcp-mux" CRLF]
["a=rtcp-mux-only" CRLF]
*(candidate-attributes CRLF) *(candidate-attributes CRLF)
[remote-candidate-attribute CRLF] [remote-candidate-attribute CRLF]
[end-of-candidates-attribute CRLF] [end-of-candidates-attribute CRLF]
remote-candidate-attribute = %s"a=" remote-candidate-att remote-candidate-attribute = %s"a=" remote-candidate-att
candidate-attributes = %s"a=" candidate-attribute candidate-attributes = %s"a=" candidate-attribute
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice- with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
options, candidate-attribute remote-candidate-att from [RFC5245], options, candidate-attribute remote-candidate-att from
identification-tag, mid-attribute ; from [RFC5888], media-field, [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute ;
attribute-fields from [RFC4566] and end-of-candidates-att from from [RFC5888], media-field, attribute-fields from [RFC4566] and end-
[I-D.ietf-mmusic-trickle-ice]. The indicator for case-sensitivity %s of-candidates-att from [I-D.ietf-mmusic-trickle-ice]. The indicator
is defined in [RFC7405]. for case-sensitivity %s is defined in [RFC7405].
[NOTE: end-of-candidates-att currently lacks a formal definition in [NOTE: end-of-candidates-att currently lacks a formal definition in
[I-D.ietf-mmusic-trickle-ice]] [I-D.ietf-mmusic-trickle-ice]]
9. Info Package 9. Info Package
9.1. Overall Description 9.1. Overall Description
This specification defines an Info Package for use by SIP user agents This specification defines an Info Package for use by SIP user agents
implementing Trickle ICE. INFO requests carry ICE candidates implementing Trickle ICE. INFO requests carry ICE candidates
skipping to change at page 30, line 38 skipping to change at page 31, line 38
+-------------+---------------------------------------+-----------+ +-------------+---------------------------------------+-----------+
| 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. | |
+-------------+---------------------------------------+-----------+ +-------------+---------------------------------------+-----------+
11. Security Considerations 11. Security Considerations
The Security Considerations of [RFC5245], [RFC6086], The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp],
[I-D.ietf-mmusic-trickle-ice] apply. This document clarifies how the [RFC6086], [I-D.ietf-mmusic-trickle-ice] apply. This document
above specifications are used together for trickling candidates and clarifies how the above specifications are used together for
does not create addtitional security risks. trickling candidates and does not create addtitional security risks.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Paul Kyzivat, Jonathan Lennox, Simon The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan
Perreault and Martin Thomson for reviewing and/or making various Lennox, Simon Perreault and Martin Thomson for reviewing and/or
suggestions for improvements and optimisations. making various suggestions for improvements and optimizations.
13. Change Log 13. 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 32, line 9 skipping to change at page 33, line 9
o RTCP and BUNDLE Consideration enhanced with some examples o RTCP and BUNDLE Consideration enhanced with some examples
o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to
normative reference normative reference
o Removed reference to 4566bis o Removed reference to 4566bis
o Addressed review comment from Simon Perreault o Addressed review comment from Simon Perreault
Changes from draft-ietf-mmusic-trickle-ice-sip-03
o replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis
and draft-ietf-mmusic-ice-sip-sdp
o Corrected Figure 10, credits to Ayush Jain for finding the bug
o Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-
ice-sip-sdp
o Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-
mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive
o Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for
the application/trickle-ice-sdpfrag body
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar, "Using
Interactive Connectivity Establishment (ICE) with Session
Description Protocol (SDP) offer/answer and Session
Initiation Protocol (SIP)", draft-ietf-mmusic-ice-sip-
sdp-08 (work in progress), March 2016.
[I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-04 (work in progress), April 2016.
[I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-mmusic-
rfc5245bis-05 (work in progress), September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015. negotiation-29 (work in progress), April 2016.
[I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), January 2016.
[I-D.ietf-mmusic-trickle-ice] [I-D.ietf-mmusic-trickle-ice]
Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", draft-ietf- Connectivity Establishment (ICE) Protocol", draft-ietf-
mmusic-trickle-ice-02 (work in progress), January 2015. mmusic-trickle-ice-02 (work in progress), January 2015.
[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,
skipping to change at page 32, line 46 skipping to change at page 34, line 37
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<http://www.rfc-editor.org/info/rfc3262>. <http://www.rfc-editor.org/info/rfc3262>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
DOI 10.17487/RFC3605, October 2003,
<http://www.rfc-editor.org/info/rfc3605>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010, DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>. <http://www.rfc-editor.org/info/rfc5761>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010, DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>. <http://www.rfc-editor.org/info/rfc5888>.
 End of changes. 48 change blocks. 
161 lines changed or deleted 221 lines changed or added

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