draft-ietf-mmusic-trickle-ice-sip-02.txt   draft-ietf-mmusic-trickle-ice-sip-03.txt 
Network Working Group E. Ivov Network Working Group E. Ivov
Internet-Draft Jitsi Internet-Draft Jitsi
Intended status: Standards Track T. Stach Intended status: Standards Track T. Stach
Expires: January 7, 2016 Unaffiliated Expires: April 4, 2016 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
July 6, 2015 October 2, 2015
A Session Initiation Protocol (SIP) usage for Trickle ICE A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-02 draft-ietf-mmusic-trickle-ice-sip-03
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 January 7, 2016. This Internet-Draft will expire on April 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
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. Fallback 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 . . . . . . . . . . . . 22 7. Considerations for Media Multiplexing . . . . . . . . . . . . 23
8. Content Type 'application/sdpfrag' . . . . . . . . . . . . . 23 8. Content Type 'application/trickle-ice-sdpfrag' . . . . . . . 25
8.1. Overall Description . . . . . . . . . . . . . . . . . . . 23 8.1. Overall Description . . . . . . . . . . . . . . . . . . . 25
8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Info Package . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Overall Description . . . . . . . . . . . . . . . . . . . 24 9.1. Overall Description . . . . . . . . . . . . . . . . . . . 27
9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 24 9.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 27
9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 25 9.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 27
9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 25 9.4. Info Package Parameters . . . . . . . . . . . . . . . . . 27
9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 25 9.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 27
9.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 25 9.6. Info Message Body Parts . . . . . . . . . . . . . . . . . 28
9.7. Info Package Usage Restrictions . . . . . . . . . . . . . 26 9.7. Info Package Usage Restrictions . . . . . . . . . . . . . 28
9.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 27 9.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 28
9.9. Info Package Security Considerations . . . . . . . . . . 27 9.9. Info Package Security Considerations . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10.1. application/sdpfrag MIME Type . . . . . . . . . . . . . 27 10.1. application/trickle-ice-sdpfrag MIME Type . . . . . . . 28
10.2. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 28 10.2. SIP Info Package 'trickle-ice' . . . . . . . . . . . . . 30
10.3. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 29 10.3. SIP Option Tag 'trickle-ice' . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 29 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
The Interactive Connectivity Establishment protocol [RFC5245] (a.k.a. The Interactive Connectivity Establishment protocol [RFC5245] (a.k.a.
Vanilla ICE) describes a mechanism for NAT traversal that consists of Vanilla ICE) describes a mechanism for NAT traversal that consists of
three main phases: a phase where an agent gathers a set of candidate three main phases: a phase where an agent gathers a set of candidate
transport addresses (source IP address, port and transport protocol), transport addresses (source IP address, port and transport protocol),
a second phase where these candidates are sent to a remote agent and a second phase where these candidates are sent to a remote agent and
this gathering procedure is repeated and, finally, a third phase this gathering procedure is repeated and, finally, a third phase
where connectivity between all candidates in both sets is checked where connectivity between all candidates in both sets is checked
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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. The that are actually in the process of initiating a session. The
alternative would have implied requiring support for Globally alternative would have implied requiring support for Globally
Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low
adoption levels, would have constituted too strong of constraint to adoption levels, would have constituted too strong of constraint to
the adoption of Trickle ICE. the adoption of Trickle ICE.
3.2. Discovery issues 3.2. Discovery issues
In order for 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 actually using it.
Contrary to other protocols, like XMPP [RFC6120], where "in advance" Contrary to other protocols, like XMPP [RFC6120], where "in advance"
capability discovery is widely implemented, the mechanisms that allow capability discovery is widely implemented, the mechanisms that allow
this for SIP (i.e., a combination of UA Capabilities [RFC3840] and this for SIP (i.e., a combination of UA Capabilities [RFC3840] and
skipping to change at page 9, line 39 skipping to change at page 9, line 39
agents establish the INVITE dialog usage such that they can trickle agents establish the INVITE dialog usage such that they can trickle
candidates. candidates.
4.1. Establishing the dialog 4.1. Establishing the dialog
In order for SIP UAs to be able to start trickling, the following two In order for SIP UAs to be able to start trickling, the following two
conditions need to be satisfied: conditions need to be satisfied:
o Trickle ICE support in the peer agent MUST be confirmed. o Trickle ICE support in the peer agent MUST be confirmed.
o The SIP dialog at both sides MUST be at least in the early state. o The dialog at both sides MUST be in early or confirmed state.
Section 5 discusses in detail the various options for satisfying the Section 5 discusses in detail the various options for satisfying the
first of the above conditions. Regardless of those mechanisms first of the above conditions. Regardless of those mechanisms
however, agents are certain to have a clear understanding of whether however, agents are certain to have a clear understanding of whether
their peers support trickle ICE once an Offer and an Answer have been their peers support trickle ICE once an Offer and an Answer have been
exchanged, which also allows for ICE processing to commence (see exchanged, which also allows for ICE processing to commence (see
Figure 3). Figure 3).
4.1.1. Asserting dialog state through reliable Offer/Answer delivery 4.1.1. Asserting dialog state through reliable Offer/Answer delivery
Alice Bob Alice Bob
skipping to change at page 10, line 30 skipping to change at page 10, line 30
|------------------------>| |------------------------>|
| 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 provisioanl 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
thereof) and to have fully initialized the SIP dialog at both ends. thereof) and to have fully initialized the SIP dialog at both ends.
Offerers and Answerers in the above situation can therefore freely Offerers and Answerers in the above situation can therefore freely
commence trickling within the newly established dialog. commence trickling within the newly established dialog.
4.1.2. Asserting dialog state through unreliable Offer/Answer delivery 4.1.2. Asserting dialog state through unreliable Offer/Answer delivery
The situation is a bit more delicate for agents that have received an The situation is a bit more delicate for agents that have received an
Offer in an INVITE request and have sent an Answer in an unreliable Offer in an INVITE request and have sent an Answer in an unreliable
provisional response because, once the response has been sent, the provisional response because, once the response has been sent, the
skipping to change at page 11, line 37 skipping to change at page 11, line 37
backoff timers described in [RFC3262]. Retransmits MUST cease on backoff 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 12.1.1 of [RFC5245] except that the STUN binding Request is replaced
by the INFO request. 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 they
receive an SDP Answer in an unreliable provisional response. This receive an SDP Answer in an unreliable provisional response. This
INFO message can repeat the candidates that were already provided in INFO message can 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) or they can when new candidates have not been learned since then) and/or they MAY
also deliver new 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).
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
skipping to change at page 12, line 28 skipping to change at page 12, line 28
| INFO/OK (SRFLX Cand.) | | INFO/OK (SRFLX Cand.) |
|<------------------------| |<------------------------|
| | | |
| 200/ACK (Answer) | | 200/ACK (Answer) |
|<------------------------| |<------------------------|
Figure 5: A SIP UA that received an INFO request after sending an Figure 5: A SIP UA that received an INFO request after sending an
unreliable provisional response knows that the dialog at the side of unreliable provisional response knows that the dialog at the side of
the receiver has entered the early state the receiver has entered the early state
When sending the Answer in the 200 OK response, the Answerers MUST When sending the Answer in the 200 OK response, the Answerer MUST
repeat exactly the same Answer that was previously sent in the repeat exactly the same Answer that was previously sent in the
unreliable provisional response in order to fulfill the corresponding unreliable provisional response in order to fulfill the corresponding
requirements in [RFC3264]. In other words, that Offerer needs to be requirements in [RFC3264]. In other words, that Offerer needs to be
prepared to receive less candidates in that repeated Answer than prepared to receive fewer candidates in that repeated Answer than
previously exchanged via trickling. previously exchanged via trickling.
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 SDP fragments in SIPfrag message The possibility to convey arbitrary candidates in INFO message bodies
bodies [I-D.ivov-mmusic-sdpfrag] allows ICE agents to initiate allows ICE agents to initiate trickling without actually sending an
trickling without actually sending an Answer. Trickle ICE Agents MAY Answer. Trickle ICE Agents MAY therefore respond to INVITEs with
therefore respond to INVITEs with provisional responses without an provisional responses without an SDP Answer. Such provisional
Answer that only serve for establishing an early dialog. responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way, M UST 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 backoff 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. [RFC5245] except that an Answer is not yet provided.
Alice Bob Alice Bob
| | | |
| INVITE (Offer) | | INVITE (Offer) |
|------------------------>| |------------------------>|
skipping to change at page 13, line 37 skipping to change at page 13, line 37
Figure 6: A SIP UA sends an unreliable provisional response without Figure 6: A SIP UA sends an unreliable provisional response without
an Answer for establishing an early dialog an Answer for establishing an early dialog
When sending the Answer the agent MUST repeat all previously sent When sending the Answer the agent MUST repeat all previously sent
candidates, if any, and MAY include all newly gathered candidates candidates, if any, and MAY include all newly gathered candidates
since the last INFO request was sent. If that answer was sent in a since the last INFO request was sent. If that answer was sent in a
unreliable provisional response, the Answerers MUST repeat exactly unreliable provisional response, the Answerers MUST repeat exactly
the same Answer in the 200 OK response in order to fulfill the the same Answer in the 200 OK response in order to fulfill the
corresponding requirements in [RFC3264]. In other words, an Offerer corresponding requirements in [RFC3264]. In other words, an Offerer
needs to be prepared to receive less candidates in that repeated needs to be prepared to receive fewer candidates in that repeated
Answer than previously exchanged via trickling. Answer than previously exchanged via trickling.
4.1.4. Considerations for 3PCC 4.1.4. Considerations for 3PCC
Agents that have sent an Offer in a reliable provisional response and Agents that have sent an Offer in a reliable provisional response and
that receive an Answer in a PRACK are also in a situation where that receive an Answer in a PRACK are also in a situation where
support for Trickle ICE is confirmed and the SIP dialog is guaranteed support for Trickle ICE is confirmed and the SIP dialog is guaranteed
to be in a state that would allow in-dialog INFO requests (see to be in a state that would allow in-dialog INFO requests (see
Figure 7). Figure 7).
skipping to change at page 15, line 45 skipping to change at page 15, line 45
Whenever new ICE candidates become available for sending, agents Whenever new ICE candidates become available for sending, agents
would encode them in "a=candidate" lines as described by would encode them in "a=candidate" lines as described by
[I-D.ietf-mmusic-trickle-ice]. For example: [I-D.ietf-mmusic-trickle-ice]. For example:
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
raddr 10.0.1.1 rport 8998 raddr 10.0.1.1 rport 8998
The use of SIP INFO requests happens within the context of the Info The use of SIP INFO requests happens within the context of the Info
Package as defined Section 9. The MIME type for their payload MUST Package as defined Section 9. The MIME type for their payload MUST
be set to 'application/sdpfrag' as defined in Section 8. be set to 'application/trickle-ice-sdpfrag' as defined in Section 8.
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 [I-D.ietf-mmusic-rfc4566bis], but provide no semantics defined in [RFC4566], but provide no semantics other than indicating
other than indicating to which "m=" line a candidate belongs. to which "m=" line a candidate belongs. Consequently, the receiving
Consequently, the receiving agent MUST ignore the remaining content agent MUST ignore the remaining content of the pseudo m-line. This
of the pseudo m-line. This guarantees that the 'application/sdpfrag' guarantees that the 'application/trickle-ice-sdpfrag' bodies do not
bodies do not interfere with the Offer/Answer procedures as specified interfere with the Offer/Answer procedures as specified in [RFC3264].
in [RFC3264].
When sending the INFO request, the agent MAY, if already known to the When sending the INFO request, the agent MAY, if already known to the
agent, include the same content into the pseudo m-line as for the agent, include the same content into the pseudo m-line as for the
corresponding Offer or Answer. However, since Trickle-ICE might be corresponding Offer or Answer. However, since Trickle-ICE might be
decoupled from the Offer/Answer negotiation this content might be decoupled from the Offer/Answer negotiation this content might be
unknown to the agent. In this case, the agent MUST include the unknown to the agent. In this case, the agent MUST include the
following default values. following default values.
o The media is set to 'audio'. o The media is set to 'audio'.
skipping to change at page 22, line 7 skipping to change at page 22, line 7
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
[OPEN ISSUE: These considerations are of general relevance
and might be better suited for draft-ietf-mmusic-trickle-ice.]
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. However, these optimized with respect to providing RTCP candidates.
considerations are neither meant to be exhaustive nor guaranteed to
be suitable for all sorts of deployments.
Handling of RTP and RCTP multiplexing [RFC5761] is already considered Handling of RTP and RTCP multiplexing [RFC5761] is already considered
in sections 4.1.1.1, 4.3, and 5.7.1 of [RFC5245], respectively. in sections 4.1.1.1, 4.3, and 5.7.1 of [RFC5245], respectively, as
These considerations are still valid for Trickle ICE, however, well in [RFC5761] itself. These considerations are still valid for
trickling provides more flexibility for the sequence of candidate Trickle ICE, however, trickling provides more flexibility for the
exchange, e.g. in case of RTCP multiplexing. sequence of candidate exchange in case of RTCP multiplexing.
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] including candidates for all components, this flexibility [RFC5245] and [RFC5761] including candidates for all components, this
allows a Full Trickle Offerer to initially send only RTP candidates flexibility allows a Full Trickle Offerer to initially send only RTP
(component 1) if it assumes that RTCP multiplexing is supported by candidates (component 1) if it assumes that RTCP multiplexing is
the Answerer. A Full Trickle Offerer would need to start gathering supported by the Answerer. A Full Trickle Offerer would need to
and trickling RTCP candidates (component 2) only after having start gathering and trickling RTCP candidates (component 2) only
received an indication in the answer that the answerer unexpectedly after having received an indication in the answer that the answerer
does not support RTCP multiplexing. 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/sdp-frag body if it supports and uses RTP and RCTP the application/trickle-ice-sdpfrag body if it supports and uses RTP
multiplexing. Receipt of this attribute at the Offerer in an INFO and RTCP multiplexing. Receipt of this attribute at the Offerer in
request prior to the Answer indicates that the Answerer supports and an INFO request prior to the Answer indicates that the Answerer
uses RTP and RCTP multiplexing. The Offerer can use this information supports and uses RTP and RTCP multiplexing. The Offerer can use
e.g. for stopping gathering of RTCP candidates and/or for freeing this information e.g. for stopping gathering of RTCP candidates and/
corresponding resources. or for freeing corresponding resources.
7. Considerations for Media Multiplexing This behaviour is illustrated by the following example offer that
indicates support for RTP and RTCP multiplexing.
[OPEN ISSUE: These considerations are of general relevance v=0
and might be better suited for draft-ietf-mmusic-trickle-ice.] o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
Once the dialog is established as described in section Section 4.1
the Answerer sends the following INFO message.
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/sdp
Content-Disposition: Info-Package
Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
This INFO message indicates that the Answerer supports and uses RTP
and RTCP multiplexing as well. This allows the Offerer to omit
gathering of RTCP candidates or releasing already gathered RTCP
candidates. If the INFO message did not contain the a=rtcp-mux
attribute, the Offerer would have to gather RTCP candidates unless it
wants to wait until receipt of an Answer that eventually confirms
support or non-support for RTP and RTCP multiplexing.
7. Considerations for Media 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 candidates in case of Media optimized with respect to providing candidates in case of Media
Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed
these considerations are neither meant to be exhaustive nor that the reader is familiar with
guaranteed to be suitable for all sorts of deployments. [I-D.ietf-mmusic-sdp-bundle-negotiation].
ICE candidate exchange is already considered in section 11 of ICE candidate exchange is already considered in section 11 of
[I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are
still valid for Trickle ICE, however, trickling provides more still valid for Trickle ICE, however, trickling provides more
flexibility for the sequence of candidate exchange, especially in flexibility for the sequence of candidate exchange, especially in
Full Trickle mode. Full Trickle mode.
Except for bundle-only m-lines, a Half Trickle Offerer would have to Except for bundle-only m-lines, a Half Trickle Offerer would have to
send an offer with candidates for all bundled m-lines. The send an offer with candidates for all bundled m-lines. The
additional flexibility, however, allows a Full Trickle Offerer to additional flexibility, however, allows a Full Trickle Offerer to
skipping to change at page 23, line 26 skipping to change at page 24, line 12
In this case the Offerer does need to trickle further candidates for In this case the Offerer does need to trickle further candidates for
the remaining m-lines in a bundle. However, if BUNDLE is not the remaining m-lines in a bundle. However, if BUNDLE is not
supported, the Full Trickle Offerer needs to gather and trickle supported, the Full Trickle Offerer needs to gather and trickle
candidates for the remaining m-lines as necessary. If the answerer candidates for the remaining m-lines as necessary. If the answerer
selects a Offerer BUNDLE address different from suggested Offerer selects a Offerer BUNDLE address different from suggested Offerer
BUNDLE address, the Full Trickle Offerer needs to gather and trickle BUNDLE address, the Full Trickle Offerer needs to gather and trickle
candidates for the m-line that carries the selected Offerer BUNDLE candidates for the m-line that carries the selected Offerer BUNDLE
address. address.
A Trickle answerer MAY include an "a=group: BUNDLE" attribute A Trickle answerer MAY include an "a=group: BUNDLE" attribute
[I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/sdp-frag [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle-
body if it supports and uses bundling. When doing so, the Answerer ice-sdpfrag body if it supports and uses bundling. When doing so,
MUST include all identification-tags in the same order that is used the Answerer MUST include all identification-tags in the same order
or will be used in the Answer. that is used or will be used in the Answer.
Receipt of this attribute at the Offerer in an INFO request prior to Receipt of this attribute at the Offerer in an INFO request prior to
the Answer indicates that the Answerer supports and uses bundling. the Answer indicates that the Answerer supports and uses bundling.
The Offerer can use this information e.g. for stopping the gathering The Offerer can use this information e.g. for stopping the gathering
of candidates for the remaining m-lines in a bundle and/or for of candidates for the remaining m-lines in a bundle and/or for
freeing corresponding resources. freeing corresponding resources.
8. Content Type 'application/sdpfrag' This behaviour is illustrated by the following example offer that
indicates support for Media Multiplexing.
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0
a=mid:foo
a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31
a=mid:bar
a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
Once the dialog is established as described in section Section 4.1
the Answerer sends the following INFO message.
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/sdp
Content-Disposition: Info-Package
Content-length: ...
a=group:BUNDLE foo bar
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
m=audio 9 RTP/AVP 0
a=mid:bar
This INFO message indicates that the Answerer supports and uses Media
Multiplexing as well. Note, that the second m-line shows the default
values as specified in section Section 4.2, e.g. media set 'audio'
although 'video' was offered. The receiving ICE agents needs to
ignore these default values in the pseudo m-lines.
The INFO message also indicates that the Answerer accepted the
Suggested Bundle Address from the Offerer. This allows the Offerer
to omit gathering of RTP and RTCP candidates for the other m-lines or
releasing already gathered candidates. If the INFO message did not
contain the a=group:BUNDLE attribute, the Offerer would have to
gather RTP and RTCP candidates for the other m-lines unless it wants
to wait until receipt of an Answer that eventually confirms support
or non-support for Media Multiplexing.
8. Content Type 'application/trickle-ice-sdpfrag'
8.1. Overall Description 8.1. Overall Description
A valid application/sdpfrag part could be obtained by starting with A application/trickle-ice-sdpfrag body is used by the Trickle-ICE
some valid SDP session description [I-D.ietf-mmusic-rfc4566bis] and Info Package. It uses a subset of the possible SDP lines that are
deleting any number of lines. allowed based on the grammar defined in [RFC4566]. A valid body uses
only media descriptions and certain attributes that are needed and/or
useful for trickling candidates. The content adheres to the
following grammar.
The exact content of an 'application/sdpfrag' body MUST be specified Like ordinary SDP
the using protocol. This document specifies the content for usage
with Trickle ICE.
8.2. Grammar 8.2. Grammar
This section provides an Augmented BNF grammar for SDP. ABNF is The grammar of an 'application/trickle-ice-sdpfrag' body is based the
defined in [RFC5234]. following ABNF [RFC5234].
The ABNF of an 'application/sdpfrag' body is based on ; Syntax
[I-D.ietf-mmusic-rfc4566bis] with the following modification trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions
session-level-fields = [bundle-group-attribute CRLF]
[ice-lite-attribute CRLF]
ice-pwd-attribute CRLF
ice-ufrag-attribute CRLF
[ice-options-attribute CRLF]
[end-of-candidates-attribute CRLF]
extension-attribute-fields
; for future extensions
; SDPfrag Syntax ice-lite-attribute = %s"a=" ice-lite
sdp-frag = *1proto-version ice-pwd-attribute = %s"a=" ice-pwd-att
*1origin-field ice-ufrag-attribute = %s"a=" ice-ufrag-att
*1session-name-field ice-options-attribute = %s"a=" ice-options
*1information-field bundle-group-attribute = "a=group:" bundle-semantics
*1uri-field *(SP identification-tag)
*1email-fields bundle-semantics = "BUNDLE"
*1phone-fields end-of-candidates-attribute = %s"a=" end-of-candidates-att
*1connection-field extension-attribute-fields = attribute-fields
*1bandwidth-fields
*1time-fields pseudo-media-descriptions = *( media-field
*1key-field trickle-ice-attribute-fields
*1attribute-fields [extension-attribute-fields] )
*1media-descriptions ; for future extensions
trickle-ice-attribute-fields = mid-attribute CRLF
["a=rtcp-mux" CRLF]
*(candidate-attributes CRLF)
[remote-candidate-attribute CRLF]
[end-of-candidates-attribute CRLF]
remote-candidate-attribute = %s"a=" remote-candidate-att
candidate-attributes = %s"a=" candidate-attribute
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
options, candidate-attribute remote-candidate-att from [RFC5245],
identification-tag, mid-attribute ; from [RFC5888], media-field,
attribute-fields from [RFC4566] and end-of-candidates-att from
[I-D.ietf-mmusic-trickle-ice]. The indicator for case-sensitivity %s
is defined in [RFC7405].
[NOTE: end-of-candidates-att currently lacks a formal definition in
[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
discovered after the peer user agents have confirmed mutual support discovered after the peer user agents have confirmed mutual support
for Trickle ICE. for Trickle ICE.
skipping to change at page 25, line 32 skipping to change at page 28, line 7
SIP entities that support this specification MUST place the 'trickle- SIP entities that support this specification MUST place the 'trickle-
ice' option-tag in a SIP Supported: header field within all SIP ice' option-tag in a SIP Supported: header field within all SIP
INVITE requests and responses. INVITE requests and responses.
When responding to, or generating a SIP OPTIONS request a SIP entity When responding to, or generating a SIP OPTIONS request a SIP entity
MUST also include the 'trickle-ice' option-tag in a SIP Supported: MUST also include the 'trickle-ice' option-tag in a SIP Supported:
header field. header field.
9.6. Info Message Body Parts 9.6. Info Message Body Parts
Entities implementing this specification MUST include SDP encoded ICE Entities implementing this specification MUST include a payload of
candidates in all SIP INFO requests. The MIME type for the payload type 'application/trickle-ice-sdpfrag' as defined in Section 8.2 all
MUST be of type 'application/sdpfrag' as defined in Section 4.2 and SIP INFO requests. The payload is used to convey SDP encoded ICE
[I-D.ietf-mmusic-trickle-ice]. candidates.
The Trickle-ICE Info Package uses only a subset of the possible SDP
Fragments that are allowed based on the grammar defined in
Section 8.2. The package uses only media descriptions and certain
attributes that are needed or useful for trickling candidates. This
subset adheres to the following grammar.
; Syntax
trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions
session-level-fields = [bundle-group-attribute CRLF]
[ice-lite-attribute CRLF]
ice-pwd-attribute CRLF
ice-ufrag-attribute CRLF
[ice-options-attribute CRLF]
[end-of-candidates-attribute CRLF]
extension-attribute-fields ; for future extensions
ice-lite-attribute = %s"a=" ice-lite
ice-pwd-attribute = %s"a=" ice-pwd-att
ice-ufrag-attribute = %s"a=" ice-ufrag-att
ice-options-attribute = %s"a=" ice-options
bundle-group-attribute = "a=group:" bundle-semantics
*(SP identification-tag)
bundle-semantics = "BUNDLE"
end-of-candidates-attribute = %s"a=" end-of-candidates-att
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields
[extension-attribute-fields] ) ; for future extensions
trickle-ice-attribute-fields = mid-attribute CRLF
["a=rtcp-mux" CRLF]
*(candidate-attributes CRLF)
[remote-candidate-attribute CRLF]
[end-of-candidates-attribute CRLF]
remote-candidate-attribute = %s"a=" remote-candidate-att
candidate-attributes = %s"a=" candidate-attribute
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-
options, candidate-attribute remote-candidate-att from [RFC5245],
identification-tag, mid-attribute ; from [RFC5888], media-field,
attribute-fields from [I-D.ietf-mmusic-rfc4566bis] and end-of-
candidates-att from [I-D.ietf-mmusic-trickle-ice]. The indicator for
case-sensitivity %s is defined in [RFC7405].
[NOTE: end-of-candidates-att currently lacks a formal definition in
[I-D.ietf-mmusic-trickle-ice]]
9.7. Info Package Usage Restrictions 9.7. Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions. This document does not define any Info Package Usage Restrictions.
9.8. Rate of INFO Requests 9.8. Rate of INFO Requests
A Trickle ICE Agent with many network interfaces might create an A Trickle ICE Agent with many network interfaces might create a high
excessive rate of INFO requests if every newly detected candidate is rate of INFO requests if every newly detected candidate is trickled
trickled individually without aggregation. Therefore, Trickle ICE individually without aggregation. Implementor that are concerned
Agent SHOULD wait for XXX ms or longer after the latest INFO request about loss of packets in such a case might consider aggregating ICE
was sent before for sending newly detected candidates in a subsequent candidates and sending INFOS only at some configurable intervals.
INFO request.
[OPEN ISSUE: What rate will give a good trade-off? 100ms, 200ms?]
9.9. Info Package Security Considerations 9.9. Info Package Security Considerations
See section Section 11 See section Section 11
10. IANA Considerations 10. 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.]
10.1. application/sdpfrag MIME Type 10.1. application/trickle-ice-sdpfrag MIME Type
Type name: application Type name: application
Subtype name: 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. The "a=charset:" SDP files are primarily UTF-8 format text. 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 an SDP file (see sets in certain parts of a trickle-ice-sdpfrag body (see
[I-D.ietf-mmusic-rfc4566bis]). Arbitrary binary content cannot
be directly represented in SDP. [RFC4566]). Arbitrary binary content cannot be directly
represented in SDP or a trickle-ice-sdpfrag body.
Security considerations: Security considerations:
See [I-D.ietf-mmusic-rfc4566bis]) and RFCXXXX See [RFC4566]) and RFCXXXX
Interoperability considerations: Interoperability considerations:
See RFCXXXX See RFCXXXX
Published specification: Published specification:
See RFCXXXX See RFCXXXX
Applications which use this media type: Applications which use this media type:
skipping to change at page 28, line 30 skipping to change at page 29, line 39
File extension(s): none File extension(s): none
Macintosh File Type Code(s): none Macintosh File Type Code(s): none
Person and email address to contact for further information: Person and email address to contact for further information:
IETF MMUSIC working group mmusic@ietf.org IETF MMUSIC working group mmusic@ietf.org
Intended usage: Intended usage:
Trickle-ICE for SIP as specified in RFCXXXX. Further usages Trickle-ICE for SIP as specified in RFCXXXX.
need a specification on the exact content of an 'application/
sdpfrag' body in the using protocol.
Author/Change controller: Author/Change controller:
IETF MMUSIC working group mmusic@ietf.org IETF MMUSIC working group mmusic@ietf.org
10.2. SIP Info Package 'trickle-ice' 10.2. SIP Info Package 'trickle-ice'
This document defines a new SIP Info Package named 'trickle-ice' and This document defines a new SIP Info Package named 'trickle-ice' and
updates the Info Packages Registry with the following entry. updates the Info Packages Registry with the following entry.
skipping to change at page 29, line 19 skipping to change at page 30, line 28
| | | | | |
+-------------+-----------+ +-------------+-----------+
10.3. SIP Option Tag 'trickle-ice' 10.3. 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 that | [RFCXXXX] | | trickle-ice | This option tag is used to indicate | [RFCXXXX] |
| | a UA supports and understands Trickle-ICE | | | | that a UA supports and understands | |
+-------------+-------------------------------------------+-----------+ | | Trickle-ICE. | |
+-------------+---------------------------------------+-----------+
11. Security Considerations 11. Security Considerations
The Security Considerations of [RFC5245], [RFC6086], The Security Considerations of [RFC5245], [RFC6086],
[I-D.ietf-mmusic-trickle-ice] apply. This document clarifies how the [I-D.ietf-mmusic-trickle-ice] apply. This document clarifies how the
above specifications are used together for trickling candidates and above specifications are used together for trickling candidates and
does not create addtitional security risks. does not create addtitional security risks.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Paul Kyzivat and Jonathan Lennox and The authors would like to thank Paul Kyzivat, Jonathan Lennox, Simon
Martin Thomson for making various suggestions for improvements and Perreault and Martin Thomson for reviewing and/or making various
optimisations. Adam Roach was co-author of [I-D.ivov-mmusic-sdpfrag] suggestions for improvements and optimisations.
which was merged into this document.
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 30, line 4 skipping to change at page 31, line 20
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
o Security Consideration added o Security Consideration added
o RTCP and BUNDLE Consideration added with rules for including o RTCP and BUNDLE Consideration added with rules for including
"a=rtcp-mux" and ""a=group: BUNDLLE" attributes "a=rtcp-mux" and "a=group: BUNDLLE" attributes
o 3PCC Consideration added o 3PCC Consideration added
o Clarified that 18x w/o answer is sufficient to create a dialog o Clarified that 18x w/o answer is sufficient to create a dialog
that allows for trickling to start that allows for trickling to start
o Added remaining Info Package definition sections as outlined in o Added remaining Info Package definition sections as outlined in
section 10 of [RFC6086] section 10 of [RFC6086]
o Added definition of application/sdpfrag making draft-ivov-mmusic- o Added definition of application/sdpfrag making draft-ivov-mmusic-
sdpfrag obsolete sdpfrag obsolete
o Added pseudo m-lines as additional separator in sdpfrag bodies for o Added pseudo m-lines as additional separator in sdpfrag bodies for
Trickle ICE Trickle ICE
o Added ABNF for sdp-frag bodies and Trickle-ICE package o Added ABNF for sdp-frag bodies and Trickle-ICE package
Changes from draft-ietf-mmusic-trickle-ice-sip-02
o Removed definition of application/sdpfrag
o Replaced with new type application/trickle-ice-sdpfrag
o RTCP and BUNDLE Consideration enhanced with some examples
o draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to
normative reference
o Removed reference to 4566bis
o Addressed review comment from Simon Perreault
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-mmusic-rfc4566bis] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Handley, M., Jacobson, V., Perkins, C., and A. Begen, Holmberg, C., Alvestrand, H., and C. Jennings,
"SDP: Session Description Protocol", draft-ietf-mmusic- "Negotiating Media Multiplexing Using the Session
rfc4566bis-15 (work in progress), May 2015. Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<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, June with Session Description Protocol (SDP)", RFC 3264,
2002. DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<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, June 2010. Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>.
[RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session
Initiation Protocol (SIP) INFO Method and Package Initiation Protocol (SIP) INFO Method and Package
Framework", RFC 6086, January 2011. Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
<http://www.rfc-editor.org/info/rfc6086>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
7405, December 2014. RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-22 (work in progress), June 2015.
[I-D.ivov-mmusic-sdpfrag]
Ivov, E. and A. Roach, "Internet Media Type application/
sdpfrag", draft-ivov-mmusic-sdpfrag-00 (work in progress),
February 2015.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
<http://www.rfc-editor.org/info/rfc5627>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX: [RFC7081] Ivov, E., Saint-Andre, P., and E. Marocco, "CUSAX:
Combined Use of the Session Initiation Protocol (SIP) and Combined Use of the Session Initiation Protocol (SIP) and
the Extensible Messaging and Presence Protocol (XMPP)", the Extensible Messaging and Presence Protocol (XMPP)",
RFC 7081, November 2013. RFC 7081, DOI 10.17487/RFC7081, November 2013,
<http://www.rfc-editor.org/info/rfc7081>.
Authors' Addresses Authors' Addresses
Emil Ivov Emil Ivov
Jitsi Jitsi
Strasbourg 67000 Strasbourg 67000
France France
Phone: +33 6 72 81 15 55 Phone: +33 6 72 81 15 55
Email: emcho@jitsi.org Email: emcho@jitsi.org
 End of changes. 60 change blocks. 
225 lines changed or deleted 316 lines changed or added

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