rfc8840v3.txt   rfc8840.txt 
Internet Engineering Task Force (IETF) E. Ivov Internet Engineering Task Force (IETF) E. Ivov
Request for Comments: 8840 Jitsi Request for Comments: 8840 Jitsi
Category: Standards Track T. Stach Category: Standards Track T. Stach
ISSN: 2070-1721 Unaffiliated ISSN: 2070-1721 Unaffiliated
E. Marocco E. Marocco
Telecom Italia Telecom Italia
C. Holmberg C. Holmberg
Ericsson Ericsson
November 2020 January 2021
A Session Initiation Protocol (SIP) Usage for Incremental Provisioning A Session Initiation Protocol (SIP) Usage for Incremental Provisioning
of Candidates for the Interactive Connectivity Establishment (Trickle of Candidates for the Interactive Connectivity Establishment (Trickle
ICE) ICE)
Abstract Abstract
The Interactive Connectivity Establishment (ICE) protocol describes a The Interactive Connectivity Establishment (ICE) protocol describes a
Network Address Translator (NAT) traversal mechanism for UDP-based Network Address Translator (NAT) traversal mechanism for UDP-based
multimedia sessions established with the Offer/Answer model. The ICE multimedia sessions established with the Offer/Answer model. The ICE
extension for Incremental Provisioning of Candidates (Trickle ICE) extension for Incremental Provisioning of Candidates (Trickle ICE)
defines a mechanism that allows ICE Agents to shorten session defines a mechanism that allows ICE Agents to shorten session
establishment delays by making the candidate gathering and establishment delays by making the candidate gathering and
connectivity checking phases of ICE non-blocking and by executing connectivity checking phases of ICE non-blocking and by executing
them in parallel. them in parallel.
This document defines usage semantics for Trickle ICE with the This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP). The document also defines a new Session Initiation Protocol (SIP). The document also defines a new
SIP Info Package to support this usage together with the SIP Info Package to support this usage together with the
corresponding media type. Additionally, a new Session Description corresponding media type. Additionally, a new Session Description
Protocol (SDP) "end-of-candidates" attribute and a new SIP Option Tag Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag
"trickle-ice" are defined. "trickle-ice" are defined.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8840. https://www.rfc-editor.org/info/rfc8840.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at line 221 skipping to change at line 221
| |<===== MEDIA FLOWS =====>| | | |<===== MEDIA FLOWS =====>| |
| | | | | | | |
Note: "SRFLX" denotes server-reflexive candidates Note: "SRFLX" denotes server-reflexive candidates
Figure 1: Sample Trickle ICE Scenario with SIP Figure 1: Sample Trickle ICE Scenario with SIP
3.1. Discovery Issues 3.1. Discovery Issues
In order to benefit from Trickle ICE's full potential and reduce In order to benefit from Trickle ICE's full potential and reduce
session establishment latency to a minimum, Trickle ICE agents need session establishment latency to a minimum, Trickle ICE Agents need
to generate SDP Offers and Answers that contain incomplete and to generate SDP Offers and Answers that contain incomplete and
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 using it. such support before using it.
Contrary to other protocols, where "in advance" capability discovery Contrary to other protocols, where "in advance" capability discovery
is widely implemented, the mechanisms that allow this for SIP (i.e., is widely implemented, the mechanisms that allow this for SIP (i.e.,
a combination of UA capabilities [RFC3840] and Globally Routable User a combination of UA capabilities [RFC3840] and Globally Routable User
Agent URIs (GRUUs) [RFC5627]) have only seen low levels of adoption. Agent URIs (GRUUs) [RFC5627]) have only seen low levels of adoption.
skipping to change at line 354 skipping to change at line 354
encode these candidates as specified in [RFC8839]. encode these candidates as specified in [RFC8839].
If the Offerer wants to send its initial Offer before knowing any If the Offerer wants to send its initial Offer before knowing any
candidate for one or more media descriptions, it MUST set the port to candidate for one or more media descriptions, it MUST set the port to
the default value '9' for these media descriptions. If the Offerer the default value '9' for these media descriptions. If the Offerer
does not want to include the host IP address in the corresponding does not want to include the host IP address in the corresponding
"c="line, e.g., due to privacy reasons, it SHOULD include a default "c="line, e.g., due to privacy reasons, it SHOULD include a default
address in the "c="line, which is set to the IPv4 address 0.0.0.0 or address in the "c="line, which is set to the IPv4 address 0.0.0.0 or
to the IPv6 equivalent ::. to the IPv6 equivalent ::.
In this case, the Offerer obviously cannot know the RTCP transport In this case, the Offerer obviously cannot know the RTP Control
address; thus, it MUST NOT include the "rtcp" attribute [RFC3605]. Protocol (RTCP) transport address; thus, it MUST NOT include the
This avoids potential ICE mismatch (see [RFC8839]) for the RTCP "rtcp" attribute [RFC3605]. This avoids potential ICE mismatch (see
transport address. [RFC8839]) for the RTCP transport address.
If the Offerer wants to use RTCP multiplexing [RFC5761] and/or If the Offerer wants to use RTCP multiplexing [RFC5761] and/or
exclusive RTCP multiplexing [RFC8858], it still will include the exclusive RTCP multiplexing [RFC8858], it still will include the
"rtcp-mux" and/or "rctp-mux-only" attribute in the initial Offer. "rtcp-mux" and/or "rctp-mux-only" attribute in the initial Offer.
In any case, the Offerer MUST include the "ice-options:trickle" In any case, the Offerer MUST include the "ice-options:trickle"
attribute in accordance to [RFC8838] and MUST include in each "m=" attribute in accordance to [RFC8838] and MUST include in each "m="
line a "mid" attribute in accordance to [RFC5888]. The "mid" line a "mid" attribute in accordance to [RFC5888]. The "mid"
attribute identifies the "m=" line to which a candidate belongs and attribute identifies the "m=" line to which a candidate belongs and
helps in case of multiple "m=" lines, when candidate gathering could helps in case of multiple "m=" lines, when candidate gathering could
skipping to change at line 423 skipping to change at line 423
In case of a "m/c=" line with default values, none of the eventually In case of a "m/c=" line with default values, none of the eventually
trickled candidates will match the default destination. This trickled candidates will match the default destination. This
situation MUST NOT cause an ICE mismatch (see [RFC8839]). situation MUST NOT cause an ICE mismatch (see [RFC8839]).
4.2. Subsequent Offer/Answer Exchanges 4.2. Subsequent Offer/Answer Exchanges
Subsequent Offer/Answer exchanges are handled the same as regular ICE Subsequent Offer/Answer exchanges are handled the same as regular ICE
(see Section 4.4 of [RFC8839]). (see Section 4.4 of [RFC8839]).
If an Offer or Answer needs to be sent while the ICE agents are in If an Offer or Answer needs to be sent while the ICE Agents are in
the middle of trickling, Section 4.4 of [RFC8839] applies. This the middle of trickling, Section 4.4 of [RFC8839] applies. This
means that an ICE agent includes candidate attributes for all local means that an ICE Agent includes candidate attributes for all local
candidates it had trickled previously for a specific media stream. candidates it had trickled previously for a specific media stream.
4.3. Establishing the Dialog 4.3. Establishing the Dialog
In order to be able to start trickling, the following two conditions In order to be able to start trickling, the following two conditions
need to be satisfied at the SIP UAs: need to be satisfied at the SIP UAs:
* Trickle ICE support at the peer agent MUST be confirmed. * Trickle ICE support at the peer agent MUST be confirmed.
* A dialog MUST have been created between the peers. * A dialog MUST have been created between the peers.
skipping to change at line 514 skipping to change at line 514
Figure 4: A SIP UA that sent an Answer in an unreliable Figure 4: A SIP UA that sent an Answer in an unreliable
provisional response does not know if it was received or if the provisional response does not know if it was received or if the
dialog at the side of the Offerer has entered the early state dialog at the side of the Offerer has entered the early state
In order to clear this ambiguity as soon as possible, the Answerer In order to clear this ambiguity as soon as possible, the Answerer
needs to retransmit the provisional response with the exponential needs to retransmit the provisional response with the exponential
backoff timers described in [RFC3262]. These retransmissions MUST backoff timers described in [RFC3262]. These retransmissions MUST
cease on receipt of an INFO request carrying a "trickle-ice" Info cease on receipt of an INFO request carrying a "trickle-ice" Info
Package body, on receipt of any other in-dialog request from the 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, or on transmission of the Answer in a 2xx response. The
offerer cannot send in-dialog requests until it receives a response, Offerer cannot send in-dialog requests until it receives a response,
so the arrival of such a request proves that the response has so the arrival of such a request proves that the response has
arrived. Using the INFO request for dialog confirmation is similar arrived. Using the INFO request for dialog confirmation is similar
to the procedure described in Section 7.1.1 of [RFC8839], except that to the procedure described in Section 7.1.1 of [RFC8839], except that
the STUN binding Request is replaced by the INFO request. the STUN binding request is replaced by the INFO request.
The Offerer MUST send a Trickle ICE INFO request as soon as it The Offerer MUST send a Trickle ICE INFO request as soon as it
receives an SDP Answer in an unreliable provisional response. This receives an SDP Answer in an unreliable provisional response. This
INFO request MUST repeat the candidates that were already provided in INFO request MUST repeat the candidates that were already provided in
the Offer (as would be the case when Half Trickle is performed or the Offer (as would be the case when Half Trickle is performed or
when new candidates have not been learned since then). The first when new candidates have not been learned since then). The first
case could happen when Half Trickle is used and all candidates are case could happen when Half Trickle is used and all candidates are
already in the initial offer. The second case could happen when Full already in the initial offer. The second case could happen when Full
Trickle is used and the offerer is currently gathering additional Trickle is used and the Offerer is currently gathering additional
candidates but did not yet get them. Also, if the initial Offer did candidates but did not yet get them. Also, if the initial Offer did
not contain any candidates, depending on how the Offerer gathers its not contain any candidates, depending on how the Offerer gathers its
candidates and how long it takes to do so, this INFO could still candidates and how long it takes to do so, this INFO could still
contain no candidates. contain no candidates.
When Full Trickle is used and if newly learned candidates are When Full Trickle is used and if newly learned candidates are
available, the Offerer SHOULD also deliver these candidates in said available, the Offerer SHOULD also deliver these candidates in said
INFO request, unless it wants to hold back some candidates in INFO request, unless it wants to hold back some candidates in
reserve, e.g., in case these candidates are expensive to use and reserve, e.g., in case these candidates are expensive to use and
would only be trickled if all other candidates failed. would only be trickled if all other candidates failed.
skipping to change at line 597 skipping to change at line 597
The ability to convey arbitrary candidates in INFO message bodies The ability to convey arbitrary candidates in INFO message bodies
allows ICE Agents to initiate trickling without actually sending an allows ICE Agents to initiate trickling without actually sending an
Answer. Trickle ICE Agents can therefore respond to an INVITE Answer. Trickle ICE Agents can therefore respond to an INVITE
request with provisional responses without an SDP Answer [RFC3261]. request with provisional responses without an SDP Answer [RFC3261].
Such provisional responses serve for establishing an early dialog. Such provisional responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way MUST Agents that choose to establish the dialog in this way MUST
retransmit these responses with the exponential backoff timers retransmit these responses with the exponential backoff timers
described in [RFC3262]. These retransmissions MUST cease on receipt described in [RFC3262]. These retransmissions MUST cease on receipt
of an INFO request carrying a "trickle-ice" Info Package body, on of an INFO request carrying a "trickle-ice" Info Package body, on
receipt of any in-dialog requests from the offerer, or on receipt of any in-dialog requests from the Offerer, or on
transmission of the Answer in a 2xx response. The offerer cannot transmission of the Answer in a 2xx response. The Offerer cannot
send in-dialog requests until it receives a response, so the arrival send in-dialog requests until it receives a response, so the arrival
of such a request proves that the response has arrived. This is of such a request proves that the response has arrived. This is
again similar to the procedure described in Section 6.1.1 of again similar to the procedure described in Section 6.1.1 of
[RFC8839], except that an Answer is not yet provided. [RFC8839], except that an Answer is not yet provided.
Note: The "+SRFLX" in Figure 6 indicates that additional newly Note: The "+SRFLX" in Figure 6 indicates that additional newly
learned server-reflexive candidates are included. learned server-reflexive candidates are included.
Alice Bob Alice Bob
| | | |
skipping to change at line 694 skipping to change at line 694
* The proto value is set to 'RTP/AVP'. * The proto value is set to 'RTP/AVP'.
* The fmt field MUST appear only once and is set to '0'. * The fmt field MUST appear only once and is set to '0'.
Agents MUST include a pseudo "m=" line and an identification tag in a Agents MUST include a pseudo "m=" line and an identification tag in a
"mid" attribute for every "m=" line whose candidate list they intend "mid" attribute for every "m=" line whose candidate list they intend
to update. Such "mid" attributes MUST immediately precede the list to update. Such "mid" attributes MUST immediately precede the list
of candidates for that specific "m=" line. of candidates for that specific "m=" line.
All "candidate" or "end-of-candidates" attributes following an "mid" All "candidate" or "end-of-candidates" attributes following a "mid"
attribute, up until (and excluding) the next occurrence of a pseudo attribute, up until (and excluding) the next occurrence of a pseudo
"m=" line, pertain to the "m=" line identified by that identification "m=" line, pertain to the "m=" line identified by that identification
tag. tag.
Note, that there is no requirement that the INFO request body Note, that there is no requirement that the INFO request body
contains as many pseudo "m=" lines as the Offer/Answer contains "m=" 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 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 "m=" lines that they pertain to. The correspondence can be made via
the "mid" attributes since candidates are grouped in sections headed the "mid" attributes since candidates are grouped in sections headed
by "pseudo" "m=" lines. These sections contain "mid" attribute by "pseudo" "m=" lines. These sections contain "mid" attribute
skipping to change at line 760 skipping to change at line 760
previously sent under the same combination of "ice-pwd" and "ice- previously sent under the same combination of "ice-pwd" and "ice-
ufrag" in the same order as they were sent before. In other words, 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 the sequence of a previously sent list of candidates MUST NOT change
in subsequent INFO requests, and newly gathered candidates MUST be in subsequent INFO requests, and newly gathered candidates MUST be
added at the end of that list. Although repeating all candidates added at the end of that list. Although repeating all candidates
creates some overhead, it also allows easier handling of problems creates some overhead, it also allows easier handling of problems
that could arise from unreliable transports like, e.g., loss of that could arise from unreliable transports like, e.g., loss of
messages and reordering, which can be detected through the CSeq: messages and reordering, which can be detected through the CSeq:
header field in the INFO request. header field in the INFO request.
In addition, an ICE agent needs to adhere to Section 17 of [RFC8838] In addition, an ICE Agent needs to adhere to Section 17 of [RFC8838]
on preserving candidate order while trickling. on preserving candidate order while trickling.
When receiving INFO requests carrying any candidates, agents MUST When receiving INFO requests carrying any candidates, agents MUST
first identify and discard the attribute lines containing candidates first identify and discard the attribute lines containing candidates
they have already received in previous INFO requests or in the Offer/ they have already received in previous INFO requests or in the Offer/
Answer exchange preceding them. Answer exchange preceding them.
Such candidates are considered to be equal if their IP address port, Such candidates are considered to be equal if their IP address port,
transport, and component ID are the same. After identifying and transport, and component ID are the same. After identifying and
discarding the known candidates, the agents MUST forward the actual discarding the known candidates, the agents MUST forward the actual
skipping to change at line 1085 skipping to change at line 1085
supported by the Answerer and if the suggested Offerer BUNDLE address supported by the Answerer and if the suggested Offerer BUNDLE address
was selected. In this case, the Offerer does not need to trickle was selected. In this case, the Offerer does not need to trickle
further candidates for the remaining "m=" lines in a bundle. further candidates for the remaining "m=" lines in a bundle.
However, if BUNDLE is not supported, the Full Trickle Offerer needs However, if BUNDLE is not supported, the Full Trickle Offerer needs
to gather and trickle candidates for the remaining "m=" lines as to gather and trickle candidates for the remaining "m=" lines as
necessary. If the Answerer selects an Offerer BUNDLE address that is necessary. If the Answerer selects an Offerer BUNDLE address that is
different from the suggested Offerer BUNDLE address, the Full Trickle different from the suggested Offerer BUNDLE address, the Full Trickle
Offerer needs to gather and trickle candidates for the "m=" line that Offerer needs to gather and trickle candidates for the "m=" line that
carries the selected Offerer BUNDLE address. carries the selected Offerer BUNDLE address.
A Trickle Answerer SHOULD include an "group:BUNDLE" attribute A Trickle Answerer SHOULD include a "group:BUNDLE" attribute
[RFC8843] at session level in the "application/trickle-ice-sdpfrag" [RFC8843] at session level in the "application/trickle-ice-sdpfrag"
body if it supports and uses bundling. When doing so, the Answerer body if it supports and uses bundling. When doing so, the Answerer
MUST include all identification-tags in the same order that is used MUST include all identification-tags in the same order that is used
or will be used in the Answer. 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 The Offerer can use this information, e.g., for stopping the
gathering of candidates for the remaining "m=" lines in a bundle and/ gathering of candidates for the remaining "m=" lines in a bundle and/
or for freeing corresponding resources. or for freeing corresponding resources.
skipping to change at line 1127 skipping to change at line 1127
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host
m=video 10002 RTP/AVP 31 m=video 10002 RTP/AVP 31
a=mid:bar a=mid:bar
a=rtcp-mux a=rtcp-mux
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
The example Offer indicates support for RTP and RTCP multiplexing and The example Offer indicates support for RTP and RTCP multiplexing and
contains an "candidate" attribute only for the "m=" line with the contains a "candidate" attribute only for the "m=" line with the
suggested Offerer bundle address. Once the dialog is established as suggested Offerer BUNDLE address. Once the dialog is established as
described in Section 4.3, the Answerer sends the following INFO described in Section 4.3, the Answerer sends the following INFO
request. request.
INFO sip:alice@example.com SIP/2.0 INFO sip:alice@example.com SIP/2.0
... ...
Info-Package: trickle-ice Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package Content-Disposition: Info-Package
Content-length: 219 Content-length: 219
skipping to change at line 1153 skipping to change at line 1153
a=mid:foo a=mid:foo
a=rtcp-mux a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
This INFO request indicates that the Answerer supports and uses Media This INFO request indicates that the Answerer supports and uses Media
Multiplexing as well. Note that the Answerer only includes a single Multiplexing as well. Note that the Answerer only includes a single
pseudo "m=" line since candidates matching those from the second "m=" pseudo "m=" line since candidates matching those from the second "m="
line in the offer are not needed from the Answerer. line in the offer are not needed from the Answerer.
The INFO request also indicates that the Answerer accepted the The INFO request also indicates that the Answerer accepted the
suggested Offerer Bundle Address. This allows the Offerer to omit suggested Offerer BUNDLE address. This allows the Offerer to omit
gathering RTP and RTCP candidates for the other "m=" lines or gathering RTP and RTCP candidates for the other "m=" lines or
releasing already gathered candidates. If the INFO request did not releasing already gathered candidates. If the INFO request did not
contain the "group:BUNDLE" attribute, the Offerer has to gather RTP contain the "group:BUNDLE" attribute, the Offerer has to gather RTP
and RTCP candidates for the other "m=" lines unless it wants to wait and RTCP candidates for the other "m=" lines unless it wants to wait
until receipt of an Answer that eventually confirms support or non- until receipt of an Answer that eventually confirms support or non-
support for Media Multiplexing. support for Media Multiplexing.
Independent of using Full Trickle or Half Trickle mode, the rules Independent of using Full Trickle or Half Trickle mode, the rules
from [RFC8859] apply to both, Offerer and Answerer, when putting from [RFC8859] apply to both, Offerer and Answerer, when putting
attributes as specified in Section 9.2 in the "application/trickle- attributes as specified in Section 9.2 in the "application/trickle-
skipping to change at line 1320 skipping to change at line 1320
A critical fact is that the sending of Trickle ICE candidates in one A critical fact is that the sending of Trickle ICE candidates in one
direction is entirely uncoupled from sending candidates in the other direction is entirely uncoupled from sending candidates in the other
direction. Thus, the sending of candidates in each direction can be direction. Thus, the sending of candidates in each direction can be
done by a stream of INFO requests that is not correlated with the 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 stream of INFO requests in the other direction. And since each INFO
request cumulatively includes the contents of all previous INFO request cumulatively includes the contents of all previous INFO
requests in that direction, the ordering between INFO requests need requests in that direction, the ordering between INFO requests need
not be preserved. All of this permits using largely independent INFO not be preserved. All of this permits using largely independent INFO
requests. requests.
Contrarily, UPDATE or other offer/answer mechanisms assume that the Contrarily, UPDATE or other Offer/Answer mechanisms assume that the
messages in each direction are tightly coupled with messages in the messages in each direction are tightly coupled with messages in the
other direction. Using Offer/Answer and UPDATE requests [RFC3311] other direction. Using Offer/Answer and UPDATE requests [RFC3311]
would introduce the following complications: would introduce the following complications:
Blocking of messages: Offer/Answer is defined as a strictly Blocking of messages: Offer/Answer is defined as a strictly
sequential mechanism in [RFC3264]. There can only be a maximum of sequential mechanism in [RFC3264]. There can only be a maximum of
one active exchange at any point of time. Both sides cannot one active exchange at any point of time. Both sides cannot
simultaneously send Offers nor can they generate multiple Offers simultaneously send Offers nor can they generate multiple Offers
prior to receiving an Answer. Using UPDATE requests for candidate prior to receiving an Answer. Using UPDATE requests for candidate
transport would therefore imply the implementation of a candidate transport would therefore imply the implementation of a candidate
skipping to change at line 1426 skipping to change at line 1426
This document does not define any Info Package Usage Restrictions. This document does not define any Info Package Usage Restrictions.
10.9. Rate of INFO Requests 10.9. Rate of INFO Requests
Given that IP addresses may be gathered rapidly, a Trickle ICE Agent Given that IP addresses may be gathered rapidly, a Trickle ICE Agent
with many network interfaces might create a high rate of INFO with many network interfaces might create a high rate of INFO
requests if every newly detected candidate is trickled individually requests if every newly detected candidate is trickled individually
without aggregation. An implementation MUST aggregate ICE candidates without aggregation. An implementation MUST aggregate ICE candidates
in case an unreliable transport protocol such as UDP is used. A in case an unreliable transport protocol such as UDP is used. A
Trickle ICE agent MUST NOT have more than one INFO request pending at Trickle ICE Agent MUST NOT have more than one INFO request pending at
any one time. When INFO messages are sent over an unreliable any one time. When INFO messages are sent over an unreliable
transport, they are retransmitted according to the rules specified in transport, they are retransmitted according to the rules specified in
[RFC3261], Section 17.1.2.1. [RFC3261], Section 17.1.2.1.
If the INFO requests are sent on top of TCP, which is probably the If the INFO requests are sent on top of TCP, which is probably the
standard way, it is not an issue for the network anymore, but it can standard way, it is not an issue for the network anymore, but it can
remain one for SIP proxies and other intermediaries forwarding the remain one for SIP proxies and other intermediaries forwarding the
SIP INFO messages. Also, an endpoint may not be able to tell that it SIP INFO messages. Also, an endpoint may not be able to tell that it
has congestion controlled transport all the way. has congestion controlled transport all the way.
skipping to change at line 1486 skipping to change at line 1486
Reference: RFC 8840 Reference: RFC 8840
Example: a=end-of-candidates Example: a=end-of-candidates
12.2. Media Type "application/trickle-ice-sdpfrag" 12.2. Media Type "application/trickle-ice-sdpfrag"
This document defines the new media type "application/trickle-ice- This document defines the new media type "application/trickle-ice-
sdpfrag" in accordance with [RFC6838]. sdpfrag" in accordance with [RFC6838].
Type name: application Type name: application
Subtype name: trickle-ice-sdpfrag
Required parameters: None.
Optional parameters: None.
Encoding considerations: The media contents follow the same rules Subtype name: trickle-ice-sdpfrag
as SDP, except as noted in this document. The media contents
are text, with the grammar specified in Section 9.2.
Although the initially defined content of a trickle-ice-sdpfrag Required parameters: None.
body does only include ASCII characters, UTF-8-encoded content
might be introduced via extension attributes. The "charset"
attribute may be used to signal the presence of other character
sets in certain parts of a trickle-ice-sdpfrag body (see
[RFC4566]). Arbitrary binary content cannot be directly
represented in SDP or a trickle-ice-sdpfrag body.
Security considerations: See [RFC4566] and RFC 8840 Optional parameters: None.
Interoperability considerations: See RFC 8840 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 Section 9.2.
Published specification: See RFC 8840 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 "charset"
attribute may be used to signal the presence of other character
sets in certain parts of a trickle-ice-sdpfrag body (see
[RFC4566]). Arbitrary binary content cannot be directly
represented in SDP or a trickle-ice-sdpfrag body.
Applications which use this Media Type: Trickle ICE Security considerations: See [RFC4566] and RFC 8840
Fragment identifier considerations: N/A Interoperability considerations: See RFC 8840
Additional information: Published specification: See RFC 8840
Deprecated alias names for this type: N/A Applications that use this media type: Trickle ICE
Magic number(s): N/A Fragment identifier considerations: N/A
File extension(s): N/A Additional information:
Macintosh File Type Code(s): N/A 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 Person and email address to contact for further information: The
IESG (iesg@ietf.org) IESG (iesg@ietf.org)
Intended usage: Trickle ICE for SIP as specified in RFC 8840. Intended usage: Trickle ICE for SIP as specified in RFC 8840.
Restrictions on usage: N/A Restrictions on usage: N/A
Author/Change controller: The IESG (iesg@ietf.org) Author/Change controller: The IESG (iesg@ietf.org)
Provisional registration? (standards tree only): N/A Provisional registration? (standards tree only): N/A
12.3. SIP Info Package "trickle-ice" 12.3. 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.
+=============+===========+ +=============+===========+
| Name | Reference | | Name | Reference |
+=============+===========+ +=============+===========+
| trickle-ice | RFC 8840 | | trickle-ice | RFC 8840 |
skipping to change at line 1657 skipping to change at line 1654
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", RFC 8838, Connectivity Establishment (ICE) Protocol", RFC 8838,
DOI 10.17487/RFC8838, November 2020, DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/info/rfc8838>. <https://www.rfc-editor.org/info/rfc8838>.
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
A., and R. Shpount, "Session Description Protocol (SDP) A., and R. Shpount, "Session Description Protocol (SDP)
Offer/Answer Procedures for Interactive Connectivity Offer/Answer Procedures for Interactive Connectivity
Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
November 2020, <https://www.rfc-editor.org/info/rfc8839>. January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 8843, Description Protocol (SDP)", RFC 8843,
DOI 10.17487/RFC8843, November 2020, DOI 10.17487/RFC8843, January 2021,
<https://www.rfc-editor.org/info/rfc8843>. <https://www.rfc-editor.org/info/rfc8843>.
[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP
Control Protocol (RTCP) Multiplexing Using the Session Control Protocol (RTCP) Multiplexing Using the Session
Description Protocol (SDP)", RFC 8858, Description Protocol (SDP)", RFC 8858,
DOI 10.17487/RFC8858, November 2020, DOI 10.17487/RFC8858, January 2021,
<https://www.rfc-editor.org/info/rfc8858>. <https://www.rfc-editor.org/info/rfc8858>.
[RFC8859] Nandakumar, S., "A Framework for Session Description [RFC8859] Nandakumar, S., "A Framework for Session Description
Protocol (SDP) Attributes When Multiplexing", Protocol (SDP) Attributes When Multiplexing", RFC 8859,
DOI 10.17487/RFC8859, RFC 8859, November 2020, DOI 10.17487/RFC8859, January 2021,
<https://www.rfc-editor.org/info/rfc8859>. <https://www.rfc-editor.org/info/rfc8859>.
14.2. Informative References 14.2. Informative References
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
2002, <https://www.rfc-editor.org/info/rfc3311>. 2002, <https://www.rfc-editor.org/info/rfc3311>.
[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
 End of changes. 41 change blocks. 
63 lines changed or deleted 60 lines changed or added

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