One document matched: draft-ivov-mmusic-trickle-ice-sip-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category='std' ipr='trust200902'
docName='draft-ivov-mmusic-trickle-ice-sip-00'>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<?rfc compact='yes' ?>
<front>
<title abbrev='Trickle ICE for SIP'>
A Session Initiation Protocol (SIP) usage for Trickle ICE
</title>
<author initials='E.' surname='Ivov'
fullname='Emil Ivov'>
<organization abbrev='Jitsi'>Jitsi</organization>
<address>
<postal>
<street></street>
<city>Strasbourg</city>
<code>67000</code>
<country>France</country>
</postal>
<phone>+33 6 72 81 15 55</phone>
<email>emcho@jitsi.org</email>
</address>
</author>
<author initials='E.' surname='Marocco' fullname='Enrico Marocco'>
<organization>Telecom Italia</organization>
<address>
<postal>
<street>Via G. Reiss Romoli, 274</street>
<city>Turin</city>
<code>10148</code>
<country>Italy</country>
</postal>
<email>enrico.marocco@telecomitalia.it</email>
</address>
</author>
<author initials="C.H." surname="Holmberg"
fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date />
<abstract>
<t>
The Interactive Connectivity Establishment (ICE) protocol
describes a Network Address Translator (NAT) traversal for
UDP-based multimedia sessions established with the offer/answer
model. The ICE extension for Incremental Provisioning of
Candidates (Trickle ICE) defines a mechanism that allows ICE
agents to shorten session establishment delays by making the
candidate gathering and connectivity checking phases of ICE
non-blocking.
</t>
<t>
This document defines usage semantics for Trickle ICE with SIP.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
The vanilla specification of the Interactive Connectivity
Establishment (vanilla ICE) protocol <xref target="RFC5245"/>
describes a mechanism for NAT traversal that consists of three
main phases: a phase where an agent gathers a set of candidate
5-tuples (source IP address and port, destination IP address and
port and a transport protocol), a second phase where these
candidates are sent to a remote agent and this gathering is
repeated and then a third phase where connectivity between all
candidates in both sets is checked (connectivity checks). Only
then can both agents begin communication, provided of course
that ICE processing has successfully completed. According to
that specification the three phases above happen consecutively,
in a blocking way, which may lead to undesirable latency during
session establishment.
</t>
<t>
The trickle ICE extension defined in
<xref target="I-D.ivov-mmusic-trickle-ice"/> defines generic
semantics required for these ICE phases to happen
simultaneously, in a non-blocking way and hence speed up session
establishment.
</t>
<t>
This specification defines a usage of trickle ICE with the
Session Initiation Protocol (SIP). In describes how and when
SIP agents use the full and half trickle modes of operation, how
they encode additional candidates and how they exchange them
through use of SIP INFO requests.
</t>
<t>
This document also defines a new Info Package for use with
Trickle ICE.
</t>
</section>
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/>.
</t>
<t>
This specification makes use of all terminology defined by the
protocol for Interactive Connectivity Establishment in
<xref target="RFC5245"/> and its Trickle ICE extension
<xref target="I-D.ivov-mmusic-trickle-ice"/>. It is assumed that
the reader will be familiar with the terminology from both of
them.
</t>
</section>
<section title='Half vs Full Trickle'
anchor='half-full-trickle'>
<t>
Trickle ICE defines a mode of operation called "half trickle".
With half trickle the first offer in a session contains all
candidates and subsequent trickling occurs from the offerer in
this first offer/answer negotiation. Half trickle offers can
hence be processed by both vanilla and trickle ICE agents, which
offers an interesting advantage in cases where support for
trickle cannot be verified prior to sending an offer.
</t>
<t>
Unless agents are running within controlled environments or
using GRUU, this would be the case with SIP. In spite of
mechanisms such as the one defined in <xref target="RFC3840"/>,
a SIP UA cannot rely on consecutive requests reaching the same
destination. An OPTIONS request querying capabilities can hence
be routed to and answered by one entity and a subsequent INVITE
by a completely different one.
</t>
<t>
For all these reasons SIP UAs implementing trickle ICE SHOULD
always perform half trickle, unless that behaviour is
specifically overridden by configuration (which could be the
case in controlled environments where every agent supports
trickle ICE).
</t>
<t>
[TODO maybe define a way for GRUU supporting agents to do full
trickle]
</t>
</section>
<section title="Encoding and Sending Candidate Information"
anchor="info-sdp">
<t>
Trickled candidates and end-of-candidates indications sent by
trickle ICE SIP UAs are transported as payload in SIP INFO
requests sent within the already established dialog. Such
payloads are encoded in an SDP format as specified in
<xref target="I-D.ivov-mmusic-trickle-ice"/>.
</t>
<t>
Since neither the "a=candidate" nor the "a=end-of-candidates"
lines contain information matching them to a stream, this is
handled through the use of MID <xref target="RFC3388"/> as
follows:
<figure>
<artwork>
<![CDATA[
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/sdp
Content-Disposition: Info-Package
Content-length: ...
a=mid:1
a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
a=candidate:2 1 UDP 1658497328 96.1.2.3 5000 typ srflx
a=m-line-id:2
a=candidate:2 1 UDP 1658497328 96.1.2.3 5002 typ srflx
a=end-of-candidates
]]>
</artwork>
</figure>
</t>
</section>
<section title="Info Package">
<section title="Overall Description">
<t>
This specification defines an INFO package meant for use by
SIP user agents implementing Trickle ICE. Typically INFO
requests would carry ICE candidates discovered after the user
agent has sent or received a trickle-ice offer.
</t>
</section>
<section title="Applicability">
<t>
The purpose of the ICE protocol is to establish a media path.
The candidates that this specification transports in INFO
requests are part of this establishment. There is hence no way
for them to be transported through the not yet existing media
path.
</t>
<t>
Candidates sent by a trickle ICE agent after the offer, are
meant to follow the same signalling path and reach the same
entity as the offer itself. While it is true that GRUUs can
be used to achieve this, one of the goals of this
specification is to allow operation of trickle ICE in as many
environments as possible including those with no GRUU support.
Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
satisfy this goal.
</t>
</section>
<section title="INFO Package Name">
<t>
This document defines a SIP INFO Package as per
<xref target="RFC6086"/>. The INFO Package token name for this
package is "trickle-ice"
</t>
</section>
<section title="INFO Package Parameters">
<t>
This document does not define any INFO package parameters.
</t>
</section>
<section title="SIP Option-Tags">
<t>
<xref target="RFC6086"/> allows Info Package specifications to
define SIP option-tags. This document therefore stipulates
that SIP entities that support trickle ICE and this
specification MUST place the 'trickle-ice' option-tag in a SIP
Supported header field.
</t>
<t>
When responding to, or generating a SIP OPTIONS request a SIP
entity MUST also include the 'trickle-ice' option-tag in a SIP
Supported header field.
</t>
</section>
<section title="INFO Message Body Parts">
<t>
Entities implementing this specification MUST include SDP
encoded ICE candidates in all SIP INFO requests. The MIME type
for the payload MUST be of type 'application/sdp' as defined
in <xref target="info-sdp"/> and
<xref target="I-D.ivov-mmusic-trickle-ice"/>.
</t>
</section>
</section>
<section title='Example Flows'>
<t>
A typical successful (half) trickle ICE exchange with SIP would
look this way:
<figure title="Example " anchor="fig-example">
<artwork>
<![CDATA[
STUN/Turn STUN/TURN
Servers Alice Bob Servers
| | | |
|<--------------| | |
| | | |
| | | |
| Candidate | | |
| | | |
| | | |
| Discovery | | |
| | | |
| | | |
|-------------->| INVITE (Offer) | |
| |------------------------>| |
| | 180 (Answer) |-------------->|
| |<------------------------| |
| | | |
| | INFO (more candidates) | Candidate |
| |<------------------------| |
| | Connectivity Checks | |
| |<=======================>| Discovery |
| | INFO (more candidates) | |
| |<------------------------| |
| | Connectivity Checks |<--------------|
| |<=======================>| |
| | | |
| | 200 OK | |
| |<------------------------| |
| | | |
| | 5245 SIP re-INVITE | |
| |------------------------>| |
| | 200 OK | |
| |<------------------------| |
| | | |
| | | |
| |<===== MEDIA FLOWS =====>| |
| | | |
]]>
</artwork>
</figure>
</t>
</section>
<section title='Security Considerations'>
<t>
[TODO]
</t>
</section>
<section title='Acknowledgements'>
<t>
[TODO]
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.6086"?>
<?rfc include="reference.I-D.ivov-mmusic-trickle-ice"?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.1918"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3388"?>
<?rfc include="reference.RFC.3840"?>
<?rfc include="reference.RFC.4787"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.I-D.keranen-mmusic-ice-address-selection"?>
</references>
<section title='Open issues'>
<t>
At the time of writing of this document the authors have no
clear view on how and if the following list of issues should
be address here:
<list style='numbers'>
<t>
Should we allow for full trickle if support can be verified
automatically and confirmed for a gruu with
<xref target="RFC3840"/>.
</t>
<t>
Can we pick between MID and stream indices for stream
identification.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:57:56 |