A Session Initiation Protocol (SIP) Usage for
Incremental Provisioning of Candidates for
the Interactive Connectivity Establishment (Trickle ICE)
JitsiStrasbourg67000France+33 6 72 81 15 55emcho@jitsi.orgUnaffiliatedVienna1130Austriathomass.stach@gmail.comTelecom ItaliaVia G. Reiss Romoli, 274Turin10148Italyenrico.marocco@telecomitalia.itEricssonHirsalantie 1102420JorvasFinlandchrister.holmberg@ericsson.com
The Interactive Connectivity Establishment (ICE) protocol
describes a Network Address Translator (NAT) traversal mechanism
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 and by executing them in parallel.
This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP).
The document also defines
a new SIP Info Package to support this usage
together with the corresponding media type.
Additionally, a new SDP 'end-of-candidates' attribute and
a new SIP Option Tag 'trickle-ice' are defined.
Introduction
The Interactive Connectivity Establishment (ICE) protocol
describes
a mechanism for Network Address Translator (NAT) traversal
that consists of three main phases.
During the first phase an agent gathers a set of candidate
transport addresses (source IP address, port and transport
protocol).
This is followed by a second phase
where these candidates are sent to a
remote agent within
the Session Description Protocol (SDP) body of a SIP message.
At the remote agent the gathering procedure is repeated and
candidates are sent to the first agent.
Once the candidate information is available, a third phase
starts in parallel where connectivity between all candidates
in both sets is checked (connectivity checks).
Once these phases
have been completed, and only then, both agents can begin
communication.
According to
the three phases above happen consecutively, in a blocking way,
which can introduce undesirable setup delay during session
establishment.
The Trickle ICE extension
defines generic
semantics required for these ICE phases to happen
in a parallel, non-blocking way and hence speed up session
establishment.
This specification defines a usage of Trickle ICE with
the Session Initiation Protocol (SIP).
It describes how ICE
candidates are to be exchanged incrementally using SIP INFO
requests
and how the Half Trickle and Full Trickle modes defined in
are to be used by
SIP User Agents (UAs) depending on their expectations for
support of Trickle ICE by a remote agent.
This document defines a new Info Package as specified in
for use with Trickle ICE together
with the corresponding media type,
SDP attribute and SIP option tag.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 ,
when, and only when, they
appear in all capitals, as shown here.
This specification makes use of terminology defined by the
protocol for Interactive Connectivity Establishment in
and its Trickle ICE extension
. It is assumed that
the reader is familiar with the terminology from both documents.
also describes
how ICE makes use of the
Session Traversal Utilities for NAT (STUN) protocol
and its extension
Traversal Using Relay NAT (TURN) .
Protocol Overview
When using ICE for SIP according to
the ICE candidates are exchanged solely via
SDP Offer/Answer as per .
This specification defines an additional mechanism
where candidates can be exchanged using SIP INFO messages
and a newly defined Info Package .
This allows ICE
candidates also to be sent in parallel to an ongoing Offer/Answer
negotiation and/or after the completion of the Offer/Answer
negotiation.
Typically, in cases where Trickle ICE is fully supported,
the Offerer sends an INVITE request
containing a subset of candidates.
Once an early dialog is established
the Offerer can continue sending
candidates in INFO requests within that dialog.
Similarly, an Answerer can send
ICE candidates using INFO requests within
the dialog established by its 18x provisional response.
shows such a sample
exchange:
Discovery issues
In order to benefit from Trickle ICE's full potential and
reduce session establishment latency to a minimum, Trickle ICE
agents need to generate SDP Offers and Answers that contain
incomplete, potentially empty sets of candidates. Such Offers
and Answers can only be handled meaningfully by agents that
actually support incremental candidate provisioning, which
implies the need to confirm such support before using
it.
Contrary to other protocols,
where "in advance" capability
discovery is widely implemented, the mechanisms that allow this
for SIP (i.e., a combination of UA Capabilities
and Globally Routable User Agent URIs (GRUU) )
have only seen low levels of adoption.
This presents an issue
for Trickle ICE implementations as SIP UAs do not have an
obvious means of verifying that their peer will support
incremental candidate provisioning.
The Half Trickle mode of operation defined in the Trickle
ICE specification
provides one way around this, by requiring the first Offer to
contain a complete set of local ICE candidates
and only using
incremental provisioning of remote candidates
for the rest of the session.
While using Half Trickle does provide a working solution it
also comes at the price of increased latency.
therefore makes several alternative
suggestions that enable SIP UAs to engage in Full Trickle
right from their first Offer:
discusses the use of on-line provisioning as a means of
allowing use of Trickle ICE for all endpoints in controlled
environments. describes
anticipatory discovery for implementations that actually do
support GRUU and UA Capabilities and
discusses the implementation
and use of Half Trickle by SIP UAs where none of the above
are an option.
Relationship with the Offer/Answer Model
From the perspective of SIP middle boxes and proxies
the Offer/Answer exchange for
Trickle ICE looks partly similar to the Offer/Answer exchange
for regular ICE for SIP
.
However, in order to have the full picture of the candidate
exchange, the newly introduced INFO messages
need to be considered as well.
From an architectural viewpoint, as displayed in
, exchanging candidates
through SIP INFO requests could be represented as signaling
between ICE modules and not between Offer/Answer modules of
SIP User Agents. Then, such INFO requests
do not impact the state of the Offer/Answer transaction other
than providing additional candidates.
Consequently, INFO requests are not considered Offers or Answers.
Nevertheless, candidates that have been exchanged
using INFO requests
SHALL be included in subsequent Offers or Answers.
The version number in the "o=" line of that subsequent Offer
needs to be incremented by 1 per the rules
in .
Incremental Signaling of ICE candidates
Trickle ICE Agents will exchange
ICE descriptions compliant to
via Offer/Answer procedures and/or INFO request bodies.
This requires the following SIP-specific extensions:
Trickle ICE Agents MUST indicate support for Trickle ICE by
including the SIP option-tag 'trickle-ice' in a SIP Supported: header field
within all SIP INVITE requests and responses.
Trickle ICE Agents MUST indicate support for Trickle ICE by
including the ice-option 'trickle'
within all SDP Offers and Answers in accordance to
.
Trickle ICE Agents MAY include any number of ICE candidates,
i.e. from zero to the complete set of candidates,
in their initial Offer or Answer.
If the complete candidate set is included already
in the initial Offer, this is called Half-Trickle.
Trickle ICE Agents MAY exchange additional ICE candidates using INFO requests
within an existing INVITE dialog usage (including an early dialog)
as specified in .
The INFO requests carry an Info-Package: trickle-ice.
Trickle ICE Agents MUST be prepared to receive INFO requests
within that same dialog usage,
containing additional candidates and/or
an indication that trickling of such candidates has ended.
Trickle ICE Agents MAY exchange additional ICE candidates
before the Answerer has sent the Answer provided that
an invite dialog usage is established at both Trickle ICE Agents.
Note that in case of forking multiple early dialogs may exist.
The following sections provide further details on how
Trickle ICE Agents perform the initial Offer/Answer exchange
(),
perform subsequent Offer/Answer exchanges
()
and establish the INVITE dialog usage
()
such that they can incrementally trickle candidates
().
Initial Offer/Answer ExchangeSending the Initial Offer
If the Offerer includes candidates in its initial Offer,
it MUST encode these candidates as specified in
.
If the Offerer wants to send its initial Offer
before knowing any candidate for one or more media descriptions,
it MUST set the port to the default value '9' for these media descriptions.
If the Offerer does not want to include the
host IP address in the corresponding c-line,
e.g. due to privacy reasons,
it SHOULD include a default address in the c-line,
which is set to the IPv4 address 0.0.0.0 or
to the IPv6 equivalent ::.
In this case, the Offerer obviously cannot know the RTCP transport address and,
thus, MUST NOT include the "a=rtcp" attribute .
This avoids potential ICE mismatch
(see ) for the RTCP transport address.
If the Offerer wants to use RTCP multiplexing
and/or exclusive RTCP multiplexing
,
it still will include the "a=rtcp-mux" and/or
"a=rctp-mux-only" attribute
in the initial Offer.
In any case, the Offerer MUST include
the attribute "a=ice-options:trickle" in accordance to
and
MUST include in each "m="-line a "a=mid:" attribute
in accordance to .
The "a=mid:" attribute identifies the "m="-line
to which a candidate belongs and
helps in case of multiple "m="-lines,
when candidates gathering could occur in a order different
from the order of the "m="-lines.
Receiving the Initial Offer
If the initial Offer included candidates,
the Answerer uses these candidates to start ICE processing
as specified in .
If the initial Offer included the attribute a=ice-options:trickle,
the Answerer MUST be prepared for receiving trickled candidates later on.
In case of a "m/c=" line with default values
none of the eventually trickled candidates
will match the default destination.
This situation MUST NOT cause an ICE mismatch
(see ).
Sending the Initial Answer
If the Answerer includes candidates in its initial Answer,
it MUST encode these candidates as specified in
.
If the Answerer wants to send its initial Answer
before knowing any candidate for one or more media descriptions,
it MUST set the port to the default value '9' for these media descriptions.
If the Answerer does not want to include the
host IP address in the corresponding c-line,
e.g. due to privacy reasons,
it SHOULD include a default address in the c-line,
which is set to the IPv4 address 0.0.0.0 or
to the IPv6 equivalent ::.
In this case, the Answerer obviously cannot know the RTCP transport address and,
thus, MUST NOT include the "a=rtcp" attribute .
This avoids potential ICE mismatch
(see ) for the RTCP transport address.
If the Answerer accepts to use RTCP multiplexing
and/or exclusive RTCP multiplexing
,
it will include the "a=rtcp-mux" attribute
in the initial Answer.
In any case, the Answerer MUST include
the attribute "a=ice-options:trickle" in accordance to
and
MUST include in each "m="-line
a "a=mid:" attribute in accordance to
.
Receiving the Initial Answer
If the initial Answer included candidates,
the Offerer uses these candidates to start ICE processing
as specified in .
In case of a "m/c=" line with default values
none of the eventually trickled candidates
will match the default destination.
This situation MUST NOT cause an ICE mismatch
(see ).
Subsequent Offer/Answer Exchanges
Subsequent Offer/Answer exchanges are handled
as for regular ICE (see section 4.2 of
).
If an Offer or Answer needs to be sent while the ICE agents
are in the middle of trickling
section 3.2 of ) applies.
This means that an ICE agent includes candidate attributes
for all local candidates it had trickled previously
for a specific media stream.
[RFC EDITOR NOTE: The section 3.2 in above sentence is correct for version 20 of said I-D.
Authors need to cross-check during Auth48 since it could have have changed in the meantime.]
Establishing the Dialog
In order to be able to start trickling, the
following two conditions need to be satisfied at the SIP UAs:
Trickle ICE support at the peer agent MUST be confirmed.
A dialog MUST have been created between the peers.
discusses in detail the various options
for satisfying the first of the above conditions. Regardless
of those mechanisms, however, agents are certain to have a
clear understanding of whether their peers support trickle
ICE once an Offer and an Answer have been exchanged,
which also allows for ICE processing to commence
(see ).
Establishing Dialog State through Reliable Offer/Answer Delivery
As shown in
satisfying both conditions is relatively trivial for
ICE Agents that have sent an Offer in an INVITE and that have
received an Answer in a reliable provisional response.
It is guaranteed to have confirmed support for
Trickle ICE at the Answerer (or lack thereof) and to have
fully initialized the SIP dialog at both ends.
Offerers and Answerers (after receipt of the PRACK request)
in the above situation can therefore
freely commence trickling within the newly established dialog.
Establishing Dialog State through Unreliable Offer/Answer Delivery
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 provisional response because, once the
response has been sent, the Answerer does not
know when or if it has been received
().
In order to clear this ambiguity as soon as possible,
the Answerer needs to retransmit the provisional response
with the exponential back-off timers described in
.
These retransmissions MUST cease on receipt
of an INFO request carrying a 'trickle-ice' Info Package body,
on receipt of any other in-dialog request from the offerer or
on transmission of the Answer in a 2xx response.
The offerer cannot send in-dialog requests until it receives
a response, so the arrival of such a request proves that
the response has arrived.
Using the INFO request for dialog confirmation
is similar to the procedure described in section
6.1.1 of except that
the STUN binding Request is replaced by the INFO request.
[RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20 of said I-D.
Authors need to cross-check during Auth48 since it could have have changed in the meantime.]
The Offerer MUST send a Trickle ICE INFO request as soon as
it receives an SDP Answer in an unreliable provisional
response. This INFO request MUST repeat the candidates
that were already provided in the Offer (as would be the case
when Half Trickle is performed or when new candidates have not
been learned since then).
The first case could happen when Half Trickle is used and
all candidate are already in the initial offer.
The second case could happen when Full Trickle is used and
the offerer is currently gathering additional candidates,
but did not yet get them.
Also, if the initial Offer did not contain any candidates,
depending on how the Offerer gathers its candidates and
how long it takes to do so, this INFO could still contain no candidates.
When Full Trickle is used and if newly learned candidates
are available, the Offerer SHOULD also deliver
these candidates in said INFO request,
unless it wants to hold back some candidates in reserve,
e.g. in case that these candidates
are expensive to use and would only be trickled
if all other candidates failed.
The Offerer SHOULD include an end-of-candidates attribute
in case candidate discovery has ended in the mean time
and no further candidates are to be trickled.
As soon as an Answerer has received such an INFO request,
the Answerer has an indication that a dialog is established
at both ends and can begin trickling
().
Note: The +SRFLX in
indicates that additionally newly learned server-reflexive candidates are included.
When sending the Answer in the 200 OK response to the INVITE request,
the Answerer needs to repeat
exactly the same Answer that was previously sent
in the unreliable provisional
response in order to fulfill the corresponding requirements in
.
Thus, the Offerer needs to be prepared
for receiving a different number of candidates
in that repeated Answer than previously exchanged via trickling
and MUST ignore the candidate information
in that 200 OK response.
Initiating Trickle ICE without an SDP Answer
The ability to convey arbitrary candidates in INFO
message bodies allows ICE Agents to initiate trickling
without actually sending an Answer.
Trickle ICE Agents can therefore respond to an INVITE request
with provisional responses without an SDP Answer
.
Such provisional responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way,
MUST retransmit these responses
with the exponential back-off timers described in
.
These retransmissions MUST cease on receipt
of an INFO request carrying a 'trickle-ice' Info Package body,
on receipt any in-dialog request from the offerer or
on transmission of the Answer in a 2xx response.
The offerer cannot send in-dialog requests until it receives
a response, so the arrival of such a request proves that
the response has arrived.
This is again similar to the procedure described in section
6.1.1 of
except that an Answer is not yet provided.
[RFC EDITOR NOTE: The section 6.1.1 in above sentence is correct for version 20 of said I-D.
Authors need to cross-check during Auth48 since it could have have changed in the meantime.]
Note: The +SRFLX in
indicates that additionally newly learned server-reflexive candidates are included.
When sending the Answer, the agent MUST repeat all currently
known and used candidates, if any,
and MAY include all newly gathered candidates since the last INFO request was sent.
However, if that Answer was already sent in a unreliable provisional response,
the Answerers MUST repeat
exactly the same Answer in the 200 OK response to the INVITE request
in order to fulfill the corresponding requirements in
.
In case that trickling continued,
an Offerer needs to be prepared for receiving fewer candidates
in that repeated Answer than previously exchanged via trickling
and MUST ignore the candidate information in that 200 OK response.
Delivering Candidates in INFO Requests
Whenever new ICE candidates become available for sending,
agents encode them in "a=candidate:" attributes as described
by . For example:
The use of SIP INFO requests happens within the context of the
Info Package as defined .
The Media Type
for their payload MUST be set to
'application/trickle-ice-sdpfrag' as defined in
.
The Info request body adheres to the grammar as specified in
.
Since neither the "a=candidate:" nor the "a=end-of-candidates"
attributes contain information that would allow correlating them to
a specific "m=" line,
this is handled through the use of
pseudo "m=" lines.
Pseudo "m=" lines follow the SDP syntax for "m=" lines as
defined in
and are linked to the corresponding "m=" line
in the SDP Offer or Answer via the identification tag
in a "a=mid:" attribute
.
A pseudo "m=" line does not provide semantics other
than indicating to which "m=" line a candidate belongs.
Consequently, the receiving agent MUST ignore any remaining content of the pseudo "m=" line,
which is not defined in this document.
This guarantees that the 'application/trickle-ice-sdpfrag' bodies do not interfere with the Offer/Answer
procedures as specified in .
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 "m=" line in the corresponding Offer or Answer.
However, since Trickle-ICE might be decoupled from the Offer/Answer negotiation this content might
be unknown to the agent. In this case, the agent MUST include the following default values.
The media field is set to 'audio'.
The port value is set to '9'.
The proto value is set to 'RTP/AVP'.
The fmt field MUST appear only once and is set to '0'
Agents MUST include a pseudo "m=" line and an
identification tag in a "a=mid:" attribute for every "m=" line
whose candidate list they intend to update.
Such "a=mid:" attributes MUST
immediately precede the list of candidates for that specific
"m=" line.
All "a=candidate:" or "a=end-of-candidates" attributes
following an "a=mid:" attribute, up until (and excluding) the next
occurrence of a pseudo "m=" line, pertain to the "m=" line
identified by that identification tag.
Note, that there is no requirement that the Info request body
contains as many pseudo m= lines as the Offer/Answer
contains m=lines, nor that the pseudo m= lines be in the same
order as the m=lines that they pertain to.
The correspondence can be made via the "a=mid:" attributes
since candidates are grouped in sections headed
by "pseudo" m=lines.
These sections contain "a=mid:" attribute values which point
back to the true m=line.
An "a=end-of-candidates" attribute, preceding
the first pseudo "m=" line, indicates the end of all trickling
from that agent,
as opposed to end of trickling for a specific "m=" line,
which would be indicated by a media level
"a=end-of-candidates" attribute.
Refer to
for an example of the INFO request content.
The use of pseudo "m=" lines allows for a structure similar to
the one in SDP Offers and Answers where
separate media-level and session-level sections can be distinguished.
In the current case, lines preceding the first
pseudo "m=" line are considered to be session-level.
Lines appearing in between or after
pseudo "m=" lines will be interpreted as media-level.
Note that while this specification uses the "a=mid:"
attribute from , it does not
define any grouping semantics.
All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:"
attributes that allow mapping them to a specific ICE generation.
An agent MUST discard any received INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:"
attributes that do not match those of the current ICE Negotiation Session.
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the same level
as the ones in the Offer/Answer exchange.
In other words, if they were present
as session-level attributes, they will also appear
at the beginning of all INFO request payloads, i.e. preceding
the first pseudo "m=" line.
If they were originally exchanged as media
level attributes, potentially overriding session-level values,
then they will also be included in INFO request payloads
following the corresponding pseudo "m=" lines.
Note that requires that
when candidates are trickled, each candidate must be delivered
to the receiving Trickle ICE implementation not more than once
and in the same order as it was conveyed.
If the signaling protocol provides any candidate retransmissions,
they need to be hidden from the ICE implementation.
This requirement is fulfilled as follows.
Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer
it MUST include all currently known and used local candidates in every INFO request.
I.e. the agent MUST repeat in the INFO request body
all candidates that were previously sent under the same
combination of "a=ice-pwd:" and "a=ice-ufrag:"
in the same order as they were sent before.
In other words, the sequence of a previously sent
list of candidates MUST NOT change in subsequent INFO requests
and newly gathered candidates MUST be added
at the end of that list.
Although repeating all candidates creates some overhead, it also allows easier handling of problems
that could arise from unreliable transports, like e.g. loss of messages and reordering,
which can be detected through the CSeq: header field in the INFO request.
In addition, an ICE agent needs to adhere to
section 17 of
on preserving candidate order while trickling.
When receiving INFO requests carrying any candidates, agents
MUST therefore first identify and discard the attribute lines
containing candidates they have already received in previous
INFO requests or in the Offer/Answer exchange preceding them.
Such candidates are considered to be equal if their IP address
port, transport and component ID are the same.
After identifying and discarding the known candidates,
the agents MUST forward the actually new candidates to the ICE Agents
in the same order as they were received in the INFO request body.
The ICE Agents will then process the new candidates
according to the rules described in .
Receiving an "a=end-of-candidates" attribute in an INFO request body
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation -
is an indication from the peer agent that it will not send any further candidates.
When included at session level, i.e. before any pseudo "m=" line,
this indication applies to the whole session;
when included at media level the indication applies
only to the corresponding "m=" line.
Handling of such end-of-candidates indications is defined in
.
The example in shows the content
of a candidate delivering INFO request. In the example the
"a=end-of-candidates" attributes indicate that
the candidate gathering is finished and
that no further INFO requests follow.
Initial Discovery of Trickle ICE Support
SIP User Agents (UAs) that support and intend to use trickle
ICE are required by
to indicate
that in their Offers and Answers using the attribute
"a=ice-options:trickle"
and MUST include the SIP option-tag "trickle-ice" in
a SIP Supported: or Require: header field.
This makes discovery
fairly straightforward for Answerers or for cases where
Offers need to be generated within existing dialogs (i.e.,
when sending UPDATE or re-INVITE requests).
In both scenarios prior
SDP bodies will have provided the necessary information.
Obviously, such information is not available at the time a first
Offer is being constructed and it is therefore impossible
for ICE Agents to determine support for incremental
provisioning that way. The following options are suggested as
ways of addressing this issue.
Provisioning Support for Trickle ICE
In certain situations it may be possible for integrators
deploying Trickle ICE to know in advance that some or all
endpoints reachable from within the deployment will support
Trickle ICE.
This is the case, for example, if Session Border Controllers
(SBC) with support for this specification are used
to connect to UAs that do not support Trickle ICE.
While the exact mechanism for allowing such provisioning
is out of scope here, this specification encourages trickle
ICE implementations to allow the option in the way they find
most appropriate.
However, an Offerer assuming Trickle ICE support MUST
include a SIP Require: trickle-ice header field.
That way, if the provisioned assumption of Trickle ICE support
ends up being incorrect, the failure is (a) operationally
easy to track down, and (b) recoverable by the client,
i.e., they can re-send the request without the
SIP Require: header field and without
the assumption of Trickle ICE support.
Trickle ICE Discovery with Globally Routable User Agent URIs (GRUU) provides a way for SIP User Agents
to query for support of specific capabilities using, among
others, OPTIONS requests. Support for
GRUU according to
on the other hand
allows SIP requests to be addressed to specific UAs (as
opposed to arbitrary instances of an address of record).
Combining the two and using the "trickle-ice" option tag
defined in provides SIP UAs with
a way of learning the capabilities of specific SIP UA instances
and then addressing them directly with INVITE requests that
require Trickle ICE support.
Such learning of capabilities may happen in different ways.
One option for a SIP UA is to learn the
GRUU instance ID of a peer through presence and then to query
its capabilities with an OPTIONS request.
Alternatively, it can also just send an OPTIONS request to
the Address of Record (AOR) it intends to contact and then inspect the returned
response(s) for support of both GRUU and Trickle ICE
().
It is noted that using the GRUU means that the INVITE request
can go only to that particular device.
This prevents the use of forking for that request.
Confirming support for Trickle ICE through
gives SIP UAs the options to engage
in Full Trickle negotiation (as opposed to the more lengthy
Half Trickle) from the very first Offer they send.
Fall-back to Half Trickle
In cases where none of the other mechanisms in this section
are acceptable, SIP UAs should use the Half Trickle mode
defined in .
With Half Trickle, agents initiate sessions the same way
they would when using ICE for SIP
.
This means that, prior to actually sending an Offer, agents
first gather ICE candidates in a blocking way and then
send them all in that Offer. The blocking nature of the
process implies that some amount of latency will
be accumulated and it is advised that agents try to
anticipate it where possible, for example, when user
actions indicate a high likelihood for an imminent call
(e.g., activity on a keypad or a phone going off-hook).
Using Half Trickle results in Offers that are
compatible with both ICE SIP endpoints and legacy
endpoints.
It is worth reminding that once a single Offer or Answer had
been exchanged within a specific dialog, support for
Trickle ICE will have been determined.
No further use of Half Trickle will therefore be necessary
within that same dialog
and all subsequent exchanges can use the Full Trickle mode
of operation.
Considerations for RTP and RTCP Multiplexing
The following consideration describe options for Trickle-ICE
in order to give some guidance to implementors on how trickling
can be optimized with respect to providing RTCP candidates.
Handling of the "a=rtcp" attribute
and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing
is already considered in section 5.1.1.1.
of and
as well in itself.
These considerations are still valid for Trickle ICE, however,
trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing.
[RFC EDITOR NOTE: The section 5.1.1.1 in above sentence is correct for version 17 of said I-D.
Authors need to cross-check during Auth48 since it could have have changed in the meantime.]
If the Offerer supports RTP/RTCP multiplexing exclusively as specified
in ,
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 has to send an Offer compliant to
and including candidates for all components,
the flexibility of a Full Trickle Offerer allows
to send only RTP candidates (component 1) in the initial Offer
assuming that RTCP multiplexing is supported by the Answerer.
A Full Trickle Offerer would need to start gathering and trickling
RTCP candidates (component 2)
only after having received an indication in the Answer that
the Answerer unexpectedly does not support RTCP multiplexing.
A Trickle Answerer MAY include an "a=rtcp-mux" attribute
in the application/trickle-ice-sdpfrag body
if it supports and uses RTP and RTCP multiplexing.
The Trickle Answerer needs to follow the guidance on the usage of the "a=rtcp" attribute as given in
and
.
Receipt of this attribute at the Offerer in an INFO request prior to the Answer
indicates that the 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 behavior is illustrated by the following example Offer that indicates support for RTP and RTCP multiplexing.
Once the dialog is established as described in section the Answerer
sends the following INFO request.
This INFO request indicates that the Answerer supports and uses
RTP and RTCP multiplexing as well.
It allows the Offerer to omit gathering of RTCP candidates or
releasing already gathered RTCP candidates.
If the INFO request did not contain the a=rtcp-mux attribute,
the Offerer has 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.
In case the Offerer had sent RTCP candidates in a previous INFO request,
it still needs to repeat them in subsequent INFO requests,
even in case that support for RTCP multiplexing was confirmed
by the Answerer and the Offerer has released its RTCP candidates.
Considerations for Media Multiplexing
The following considerations describe options for Trickle-ICE
in order to give some guidance to implementors on how trickling
can be optimized with respect to providing candidates in case of Media Multiplexing
.
It is assumed that the reader is familiar with .
ICE candidate exchange is already considered
in section 11 of
.
These considerations are still valid for Trickle ICE, however,
trickling provides more flexibility for the sequence of candidate exchange,
especially in Full Trickle mode.
Except for bundle-only "m=" lines, a Half Trickle Offerer has to
send an Offer with candidates for all bundled "m=" lines.
The additional flexibility, however, allows a Full Trickle Offerer
to initially send only candidates for the "m=" line with the
suggested Offerer BUNDLE address.
On receipt of the Answer, the Offerer will detect
if BUNDLE is supported by the Answerer and if the suggested Offerer BUNDLE address was selected.
In this case, the Offerer does not need to trickle further candidates for the remaining "m=" lines in a bundle.
However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates
for the remaining "m=" lines as necessary.
If the Answerer selects an Offerer BUNDLE address different from the suggested Offerer BUNDLE address,
the Full Trickle Offerer needs to gather and trickle candidates
for the "m=" line that carries the selected Offerer BUNDLE address.
A Trickle Answerer SHOULD include an "a=group:BUNDLE" attribute
at session level in the application/trickle-ice-sdpfrag body
if it supports and uses bundling.
When doing so, the Answerer MUST include all identification-tags in the same order that is used or will be used in the Answer.
Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer
supports and uses bundling.
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 freeing corresponding resources.
This behaviour is illustrated by the following example Offer that indicates support for Media Multiplexing.
In case the Offerer had sent already candidates for "m="-lines
in a bundle in a previous INFO request,
it still needs to repeat them in subsequent INFO requests,
even in case that support for bundling was confirmed
by the Answerer and the Offerer has released no longer needed candidates.
The example Offer indicates support for RTP and RTCP multiplexing
and contains a "a=candidate:" attribute only for the "m="-line
with the suggested Offerer bundle address.
Once the dialog is established as described in the Answerer
sends the following INFO request.
This INFO request indicates that the Answerer supports and uses Media Multiplexing as well.
Note that the Answerer only includes a single pseudo "m="-line since candidates
matching those from the second "m="-line in the offer are not needed from the Answerer.
The INFO request also indicates that the Answerer accepted the suggested Offerer Bundle Address.
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 request did not contain the a=group:BUNDLE attribute, the Offerer has 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.
Independent of using Full Trickle or Half Trickle mode, the rules from
apply to both, Offerer and Answerer,
when putting attributes as specified in
in the application/trickle-ice-sdpfrag body.
SDP 'end-of-candidates' AttributeDefinition
This section defines a new SDP media-level and session-level attribute
'end-of-candidates'. 'end-of-candidates' is a property attribute
, and hence has no value.
By including this attribute in an Offer or Answer the sending agent indicates
that it will not trickle further candidates.
When included at session level this indication applies to the whole session,
when included at media level the indication applies only to the corresponding media description.
Name: end-of-candidates
Value: N/A
Usage Level: media and session-level
Charset Dependent: no
Mux Category: IDENTICAL
Example: a=end-of-candidates
Offer/Answer ProceduresThe Offerer or Answerer MAY include an "a=end-of-candidates" attribute
in case candidate discovery has ended
and no further candidates are to be trickled.
The Offerer or Answerer MUST provide the "a=end-of-candidates" attribute
together with the "a=ice-ufrag" and "a=ice-pwd" attributes of the current
ICE generation as required by
.
When included at session level
this indication applies to the whole session;
when included at media level the indication applies
only to the corresponding media description.
Receipt of an "a=end-of-candidates" attribute at an
Offerer or Answerer
- with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation -
indicates that gathering of candidates
has ended at the peer, either for the session or only for the
corresponding media description as specified above.
The receiving agent forwards an end-of-candidates indication
to the ICE Agent, which in turn acts as specified in
.
Content Type 'application/trickle-ice-sdpfrag'Overall Description
A application/trickle-ice-sdpfrag body is used exclusively by the 'trickle-ice' Info Package.
Other SDP related applications need to define their own media type.
The INFO request body uses a subset of the possible SDP lines
as defined by the grammar defined in .
A valid body uses only pseudo "m=" lines and certain attributes
that are needed and/or useful for trickling candidates.
The content adheres to the following grammar.
Grammar
The grammar of an 'application/trickle-ice-sdpfrag' body is
based on the following ABNF .
It specifies the subset of existing SDP attributes,
that is needed or useful for trickling candidates.
The grammar uses the indicator for case-sensitivity %s
as defined in ,
but also imports grammars for other SDP attributes that
precede the production of .
A sender SHOULD use lower-case for attributes
from such earlier grammars, but a receiver MUST treat
them case-insensitively.
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att,
ice-pacing-att, ice-options, candidate-attribute remote-candidate-att
from ,
identification-tag, mid-attribute ; from ,
media-field, attribute-fields from .
The "a=rtcp" attribute is defined in ,
the "a=rtcp-mux" attribute in and
the "a=rtcp-mux-only" attribute in .
The latter attributes lack a formal grammar in their corresponding RFC and are reproduced here.
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
same level as the ones in the Offer/Answer exchange. In other words,
if they were present as session-level attributes, they will also
appear at the beginning of all INFO request payloads, i.e. preceding
all pseudo "m=" lines. If they were originally exchanged as media
level attributes, potentially overriding session-level values, then
they will also be included in INFO request payloads following the
corresponding pseudo "m=" lines.
An Agent MUST ignore any received unknown extension-attribute-fields.
Info PackageRationale - Why INFO?
The decision to use SIP INFO requests as a candidate transport
method is based primarily on their lightweight nature. Once a
dialog has been established, INFO requests can be exchanged
both ways with no restrictions on timing and frequency and no
risk of collision.
A critical fact is that the sending of Trickle ICE candidates
in one direction is entirely uncoupled from sending candidates
in the other direction.
Thus, the sending of candidates in each direction can be
done by a stream of INFO requests that is not correlated with
the stream of INFO requests in the other direction.
And since each INFO request cumulatively includes
the contents of all previous INFO requests in that direction,
ordering between INFO requests need not be preserved.
All of this permits using largely-independent INFO requests.
Contrarily, UPDATE or other offer/answer mechanisms assume
that the messages in each direction are tightly coupled
with messages in the other direction.
Using Offer/Answer and UPDATE requests
would introduce the following complications:
Blocking of messages:
defines Offer/Answer as a
strictly sequential mechanism.
There can only be a maximum of one active exchange
at any point of time.
Both sides cannot simultaneously send Offers nor
can they generate multiple Offers prior to
receiving an Answer.
Using UPDATE requests for
candidate transport would therefore imply the
implementation of a candidate 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.
Such an approach would introduce non-negligible
complexity for no additional value.
Elevated risk of glare:
The sequential nature of Offer/Answer also makes it
impossible for both sides to send Offers simultaneously.
What's worse is that there are no mechanisms in SIP to
actually prevent that. , where
the situation of Offers crossing on the wire is described
as "glare", only defines a procedure for addressing the
issue after it has occurred. According to that procedure
both Offers are invalidated and both sides need to retry
the negotiation after a period between 0 and 4 seconds.
The high likelihood for glare to occur and the average two
second back-off intervals implies that the duration of
Trickle ICE processing would not only fail to improve but
actually exceed those of regular ICE.
INFO messages decouple the exchange of candidates from the
Offer/Answer negotiation
and are subject to none of the glare issues described above,
which makes them a very convenient and lightweight mechanism
for asynchronous delivery of candidates.
Using in-dialog INFO messages also provides a way of
guaranteeing that candidates are delivered end-to-end, between
the same entities that are actually in the process of
initiating a session. Out-of-dialog alternatives would have implied
requiring support for Globally Routable UA URI (GRUU)
which, given GRUUs relatively low
adoption levels, would have constituted too strong of a
constraint to the adoption of Trickle ICE.
Overall Description
This specification defines an Info Package for use by
SIP User Agents implementing Trickle ICE.
INFO requests carry ICE candidates discovered after the peer user
agents have confirmed mutual support for Trickle ICE.
Applicability
The purpose of the ICE protocol is to establish a media path
in the presence of NAT and firewalls.
The candidates are transported in INFO requests and are
part of this establishment.
Candidates sent by a Trickle ICE Agent after the Offer,
follow the same signaling path and reach the same
entity as the Offer itself. While it is true that GRUUs can
be used to achieve this, one of the goals of this
specification is to allow operation of Trickle ICE in as many
environments as possible including those without GRUU support.
Using out-of-dialog SUBSCRIBE/NOTIFY requests would not
satisfy this goal.
Info Package Name
This document defines a SIP Info Package as per
. The Info Package token name for this
package is "trickle-ice"
Info Package Parameters
This document does not define any Info Package parameters.
SIP Option Tags allows Info Package specifications to
define SIP option-tags. This specification extends the option-tag
construct of the SIP grammar as follows:
SIP entities that support this
specification MUST place the 'trickle-ice' option-tag in a SIP
Supported: or Require: header field within
all SIP INVITE requests and responses.
When responding to, or generating a SIP OPTIONS request a SIP
entity MUST also include the 'trickle-ice' option-tag in a SIP
Supported: or Require: header field.
Info Request Body Parts
Entities implementing this specification MUST include a
payload of type 'application/trickle-ice-sdpfrag' as defined
in
in SIP INFO requests.
The payload is used to convey SDP-encoded ICE candidates.
Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions.
Rate of INFO Requests
Given that IP addresses may be gathered rapidly a
Trickle ICE Agent with many network interfaces might create a
high rate of INFO requests if every newly
detected candidate is trickled individually without aggregation.
An implementation MUST aggregate ICE candidates in case that an
unreliable transport protocol such as UDP is used.
A Trickle ICE agent MUST NOT have more than one INFO request
pending at any one time.
When INFO messages are sent over an unreliable transport,
they are retransmitted according to the rules specified in
section 17.1.2.1."
If the INFO requests are sent on top of TCP,
which is probably the standard way,
this is not an issue for the network anymore,
but it can remain one for SIP proxies and other intermediaries
forwarding the SIP INFO messages.
Also, an endpoint may not be able to tell that it has congestion
controlled transport all the way.
Info Package Security Considerations
See Deployment Considerations
Trickle ICE uses two mechanisms for exchange of candidate information.
This imposes new requirements to certain middleboxes
that are used in some networks, e.g. for monitoring purposes.
While the first mechanism, SDP Offers and Answers,
is already used by regular ICE and is assumed to be supported,
the second mechanism, INFO request bodies,
needs to be considered by such middleboxes as well when
trickle ICE is used.
Such middleboxes need to make sure that they remain
in the signaling path of the INFO requests and
need to understand the INFO request body.
IANA Considerations
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. ]
SDP 'end-of-candidates' Attribute
This section defines a new SDP media-level and session-level attribute
, 'end-of-candidates'. 'end-of-candidates' is a property attribute
, and hence has no value.
Media Type 'application/trickle-ice-sdpfrag'
This document defines a new Media Type 'application/trickle-ice-sdpfrag'
in accordance with .
Type name: application
Subtype name: trickle-ice-sdpfrag
Required parameters: None.
Optional parameters: None.
Encoding considerations:
The media contents follow the same rules as SDP,
except as noted in this document.
The media contents are text, with the grammar specified
in .
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 sets in certain parts of a trickle-ice-sdpfrag body (see
).
Arbitrary binary content cannot be directly represented
in SDP or a trickle-ice-sdpfrag body.
Security considerations:
See and RFCXXXX
Interoperability considerations:
See RFCXXXX
Published specification:
See RFCXXXX
Applications which use this Media Type:
Trickle-ICE
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh File Type Code(s): N/A
Person and email address to contact for further information:
The IESG (iesg@ietf.org)
Intended usage:
Trickle-ICE for SIP as specified in RFCXXXX.
Restrictions on usage: N/A
Author/Change controller:
The IESG (iesg@ietf.org)
Provisional registration? (standards tree only): N/A
SIP Info Package 'trickle-ice'
This document defines a new SIP Info Package named 'trickle-ice'
and updates the Info Packages Registry with the following entry.
SIP Option Tag 'trickle-ice'
This specification registers a new SIP option tag 'trickle-ice'
as per the guidelines in Section 27.1 of
and updates the "Option Tags" section of the
SIP Parameter Registry with the following entry:
Security Considerations
The Security Considerations of
,
and
apply.
This document clarifies how the above specifications are used together for trickling
candidates and does not create additional security risks.
The new Info Package 'trickle-ice' and
the new Media Type 'application/trickle-ice-sdpfrag'
do not introduce additional security considerations
when used in the context of Trickle ICE.
Both are not intended to be used for other applications,
so any security considerations for its use in other contexts
is out of the scope of this document
Acknowledgements
The authors like to thank
Flemming Andreasen,
Ayush Jain,
Paul Kyzivat,
Jonathan Lennox,
Simon Perreault,
Roman Shpount
and
Martin Thomson
for reviewing and/or making various suggestions for
improvements and optimizations.
The authors also like to thank
Flemming Andreasen for shepherding this document and
Ben Campbell for his AD review and suggestions.
In addition, the author like to thank
Benjamin Kaduk,
Adam Roach,
Mirja Kuehlewind and
Eric Rescorla
for their comments and/or text proposals for improving
the document during IESG review.
Many thanks to Dale Worley for Gen-Art review and proposed
enhancements for several sections.
Many thanks to Joerg Ott for TSV-Art review and suggested improvements.
The authors thank Shawn Emery for Security Directorate review.
Change Log
[RFC EDITOR NOTE: Please remove this section when publishing].
Changes from draft-ietf-mmusic-trickle-ice-sip-01
Editorial Clean up
IANA Consideration added
Security Consideration added
RTCP and BUNDLE Consideration added with rules for including "a=rtcp-mux" and "a=group: BUNDLLE" attributes
3PCC Consideration added
Clarified that 18x w/o answer is sufficient to create a dialog that allows for trickling to start
Added remaining Info Package definition sections as outlined in section 10 of
Added definition of application/sdpfrag making draft-ivov-mmusic-sdpfrag obsolete
Added pseudo m-lines as additional separator in sdpfrag bodies for Trickle ICE
Added ABNF for sdp-frag bodies and Trickle-ICE package
Changes from draft-ietf-mmusic-trickle-ice-sip-02
Removed definition of application/sdpfrag
Replaced with new type application/trickle-ice-sdpfrag
RTCP and BUNDLE Consideration enhanced with some examples
draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to normative reference
Removed reference to 4566bis
Addressed review comment from Simon Perreault
Changes from draft-ietf-mmusic-trickle-ice-sip-03
replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and draft-ietf-mmusic-ice-sip-sdp
Corrected Figure 10, credits to Ayush Jain for finding the bug
Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-ice-sip-sdp
Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive
Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for the application/trickle-ice-sdpfrag body
Changes from draft-ietf-mmusic-trickle-ice-sip-04
considered comments from Christer Holmberg
corrected grammar for INFO package, such that ice-ufrag/pwd are also allowed on media-level as specified in
Added new ice-pacing-attribute fom
Added formal definition for the end-of-candidates attribute
Changes from draft-ietf-mmusic-trickle-ice-sip-05
considered further comments from Christer Holmberg
editorial comments on section 3 addressed
moved section 3.1 to section 10.1 and applied some edits
replaced the term "previously sent candidates" with "currently known and used candidates".
Changes from draft-ietf-mmusic-trickle-ice-sip-06
editorial fixes
additional text on the content of the INFO messages.
recommendation on what to do if a previously sent candidate is unexpectedly missing in a subsequent INFO
terminology alignment with draft-ietf-ice-trickle-07
Changes from draft-ietf-mmusic-trickle-ice-sip-07
editorial fixes
clarification on ordering of candidates for alignment with draft-ietf-ice-trickle-12
O/A procedures for end-of-candidates attribute described here after corresponding procedures
have been removed from draft-ietf-ice-trickle-11
using IPv6 addresses in examples
Changes from draft-ietf-mmusic-trickle-ice-sip-08
editorial fixes/clarification based on Flemmings review
Description of Trickle specifics in O/A procedures for initial O/A exchange and specification of ICE mismatch exception
Changes from draft-ietf-mmusic-trickle-ice-sip-09
editorial fixes/correction of references
adding missing Ref to RFC3605 in section 6, 5th para
replaced remaining IPv4 adresses with IPv6
Added text for handling a=rtcp in case of default RTP address 0.0.0.0:9 based on comment from Roman Shpount.
Changes from draft-ietf-mmusic-trickle-ice-sip-10
editorial fixes due to idnits output
Changes from draft-ietf-mmusic-trickle-ice-sip-11
addressing comments from Ben Campell's AD review and Christer's review
Numerous editorial improvements/corrections
Added [RFC8174] boiler plate and adapted usage of normative language
Clarified terminology ICE modules .vs. ICE agent
Added more detailed OA procedures
Corrected default values in m-line
and usage of "a=mid:" attribute explicitly mentioned for offer/answer
Removed explicit mentioning of XMPP
Added Deployment Considerations section
Fixed ref for rfc5245bis
Changes from draft-ietf-mmusic-trickle-ice-sip-12
addressing comments from Gen-Art review, TSV-Art review and
Security Directorate review
Changes from draft-ietf-mmusic-trickle-ice-sip-14
Addressing comments from IESG review
Clarification/enhancement in section 5 and Fig. 10 based on comments from Benjamin Kaduk
Clarification on sequence for sending candidates,
definition of pseudo m-lines,
usage of a=mid attribute,
usage of INFO as ACK for receipt of 18x based on comments from Eric Rescorla
Removal of 3PCC Section 3.4,
removal of NATted IPv6 addresses,
adding more flexibility to in the grammar,
explicit mentioning of Require: header field,
usage of Require: header field in case of provisioning,
text on repetition of candidates in case of RTCP mux and Bundle,
various other editorial improvements/corrections
based on comments from Adam Roach
Modified text on rate limitation of INFO requests based on
comments of Mirja Kuehlewind, Adam Roach and Roman Shpount