RFC 8840
A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
Pages: ~34
IETF/art/mmusic/draft-ietf-mmusic-trickle-ice-sip-18
Proposed Standard
A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
Abstract
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 Session Description Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag "trickle-ice" are defined.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8840 .
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info ) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
- 1. Introduction
- 2. Terminology
- 3. Protocol Overview
- 4. Incremental Signaling of ICE Candidates
- 5. Initial Discovery of Trickle ICE Support
- 6. Considerations for RTP and RTCP Multiplexing
- 7. Considerations for Media Multiplexing
- 8. SDP "end-of-candidates" Attribute
- 9. Content Type "application/trickle-ice-sdpfrag"
- 10. Info Package
- 11. Deployment Considerations
- 12. IANA Considerations
- 13. Security Considerations
- 14. References
- Acknowledgements
- Authors' Addresses
1. Introduction
The Interactive Connectivity Establishment (ICE) protocol [RFC 8445] 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, 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 [RFC 8445], the three phases above happen consecutively, in a blocking way, which can introduce undesirable setup delay during session establishment. The Trickle ICE extension [RFC 8838] defines generic semantics required for these ICE phases to happen in a parallel, non-blocking way and hence speeds up session establishment.
This specification defines a usage of Trickle ICE with the Session Initiation Protocol (SIP)[RFC 3261]. It describes how ICE candidates are to be exchanged incrementally using SIP INFO requests [RFC 6086] and how the Half Trickle and Full Trickle modes defined in [RFC 8838] 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 [RFC 6086] for use with Trickle ICE together with the corresponding media type, SDP attribute, and SIP option tag.
2. 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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.
This specification makes use of terminology defined by the ICE protocol in [RFC 8445] and by its Trickle ICE extension in [RFC 8838]. It is assumed that the reader is familiar with the terminology from both documents.
[RFC 8445] also describes how ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol [RFC 5389] and its extension Traversal Using Relays around NAT (TURN) [RFC 5766].
3. Protocol Overview
When using ICE for SIP according to [RFC 8839], the ICE candidates are exchanged solely via SDP Offer/Answer as per [RFC 3264]. This specification defines an additional mechanism where candidates can be exchanged using SIP INFO messages and a newly defined Info Package [RFC 6086]. This also allows ICE candidates 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. Figure 1 shows such a sample exchange:
STUN/TURN STUN/TURN
Servers Alice Bob Servers
| | | |
| STUN Bi.Req. | INVITE (Offer) | |
|<--------------|------------------------>| |
| | 183 (Answer) | TURN Alloc Req |
| STUN Bi.Resp. |<------------------------|--------------->|
|-------------->| INFO/OK (SRFLX Cand.) | |
| |------------------------>| TURN Alloc Resp|
| | INFO/OK (Relay Cand.) |<---------------|
| |<------------------------| |
| | | |
| | More Cands & ConnChecks| |
| |<=======================>| |
| | | |
| | 200 OK | |
| |<------------------------| |
| | ACK | |
| |------------------------>| |
| | | |
| |<===== MEDIA FLOWS =====>| |
| | | |
Note: "SRFLX" denotes server-reflexive candidates
3.1. 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 and 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 [RFC 3840] and Globally Routable User Agent URIs (GRUUs) [RFC 5627]) 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 [RFC 8838] provides one way around this, by requiring the first Offer to contain a complete set of local ICE candidates and using only 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, Section 5 makes several alternative suggestions that enable SIP UAs to engage in Full Trickle right from their first Offer: Section 5.1 discusses the use of online provisioning as a means of allowing the use of Trickle ICE for all endpoints in controlled environments. Section 5.2 describes anticipatory discovery for implementations that actually do support GRUU and UA capabilities, and Section 5.3 discusses the implementation and use of Half Trickle by SIP UAs where none of the above are an option.
3.2. Relationship with the Offer/Answer Model
From the perspective of SIP middleboxes and proxies, the Offer/Answer exchange for Trickle ICE looks partly similar to the Offer/Answer exchange for regular ICE for SIP [RFC 8839]. 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 Figure 2, exchanging candidates through SIP INFO requests could be represented as signaling between ICE modules and not between Offer/Answer modules of SIP UAs. 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 [RFC 3264].
+-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | |
| +--------+ | Module | | | | Module | +--------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | |
| | Module | | | | | | Module | |
| +--------+ | | | | +--------+ |
+-------------------------------+ +-------------------------------+
| | | |
| | INVITE (Offer) | |
| |--------------------->| |
| | 183 (Answer) | |
| |<---------------------| |
| | | |
| |
| SIP INFO (more candidates) |
|----------------------------------------------------->|
| SIP INFO (more candidates) |
|<-----------------------------------------------------|
| |
| STUN Binding Requests/Responses |
|----------------------------------------------------->|
| STUN Binding Requests/Responses |
|<-----------------------------------------------------|
| |
4. Incremental Signaling of ICE Candidates
Trickle ICE Agents will exchange ICE descriptions compliant to [RFC 8838] 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 [RFC 8838].
- 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 already included in the initial Offer, it 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 [RFC 6086]. 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.
4.1. Initial Offer/Answer Exchange
4.1.1. Sending the Initial Offer
If the Offerer includes candidates in its initial Offer, it MUST encode these candidates as specified in [RFC 8839].
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 RTP Control Protocol (RTCP) transport address; thus, it MUST NOT include the "rtcp" attribute [RFC 3605]. This avoids potential ICE mismatch (see [RFC 8839]) for the RTCP transport address.
If the Offerer wants to use RTCP multiplexing [RFC 5761] and/or exclusive RTCP multiplexing [RFC 8858], it still will include the "rtcp-mux" and/or "rctp-mux-only" attribute in the initial Offer.
In any case, the Offerer MUST include the "ice-options:trickle" attribute in accordance to [RFC 8838] and MUST include in each "m=" line a "mid" attribute in accordance to [RFC 5888]. The "mid" attribute identifies the "m=" line to which a candidate belongs and helps in case of multiple "m=" lines, when candidate gathering could occur in an order different from the order of the "m=" lines.
4.1.2. Receiving the Initial Offer
If the initial Offer included candidates, the Answerer uses these candidates to start ICE processing as specified in [RFC 8838].
If the initial Offer included the "ice-options:trickle" attribute, 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 [RFC 8839]).
4.1.3. Sending the Initial Answer
If the Answerer includes candidates in its initial Answer, it MUST encode these candidates as specified in [RFC 8839].
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; thus, it MUST NOT include the "rtcp" attribute [RFC 6086]. This avoids potential ICE mismatch (see [RFC 8839]) for the RTCP transport address.
If the Answerer accepts the use of RTCP multiplexing [RFC 5761] and/or exclusive RTCP multiplexing [RFC 8858], it will include the "rtcp-mux" attribute in the initial Answer.
In any case, the Answerer MUST include the "ice-options:trickle" attribute in accordance to [RFC 8838] and MUST include in each "m=" line a "mid" attribute in accordance to [RFC 5888].
4.1.4. Receiving the Initial Answer
If the initial Answer included candidates, the Offerer uses these candidates to start ICE processing as specified in [RFC 8838].
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 [RFC 8839]).
4.2. Subsequent Offer/Answer Exchanges
Subsequent Offer/Answer exchanges are handled the same as regular ICE (see Section 4.4 of RFC 8839).
If an Offer or Answer needs to be sent while the ICE Agents are in the middle of trickling, Section 4.4 of RFC 8839 applies. This means that an ICE Agent includes candidate attributes for all local candidates it had trickled previously for a specific media stream.
4.3. 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.
4.3.1. Establishing Dialog State through Reliable Offer/Answer Delivery
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| PRACK/OK |
|------------------------>|
| |
+----------------------------------------+
|Alice and Bob know that both can trickle|
|and know that the dialog is in the early|
|state. Send INFO! |
+----------------------------------------+
| |
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
Note: "SRFLX" denotes server-reflexive candidates
4.3.2. 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 (Figure 4).
In order to clear this ambiguity as soon as possible, the Answerer needs to retransmit the provisional response with the exponential backoff timers described in [RFC 3262]. 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 7.1.1 of RFC 8839, except that the STUN binding request is replaced by the INFO request.
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 candidates 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 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 meantime 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 trickling can begin (Figure 5).
Note: The "+SRFLX" in Figure 5 indicates that additional 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 [RFC 3264]. 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.
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| |
| +----------------------+
| |Bob: I don't know if |
| |Alice got my 183 or if|
| |her dialog is already |
| |in the early state. |
| | Can I send INFO??? |
| +----------------------+
| |
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (Answer) |
|<------------------------|
| INFO/OK (+SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know Alice|
| | is ready. Send INFO! |
| +----------------------+
| INFO/OK (+SRFLX Cand.) |
|<------------------------|
| |
| 200/ACK (Answer) |
|<------------------------|
Note: "SRFLX" denotes server-reflexive candidates
4.3.3. 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 [RFC 3261]. 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 backoff timers described in [RFC 3262]. These retransmissions MUST cease on receipt of an INFO request carrying a "trickle-ice" Info Package body, on receipt of any in-dialog requests 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 RFC 8839, except that an Answer is not yet provided.
Note: The "+SRFLX" in Figure 6 indicates that additional 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 an 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 [RFC 3264]. 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.
Alice Bob
| |
| INVITE (Offer) |
|------------------------>|
| 183 (-) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +----------------------+
| |Bob: Now I know again|
| | that Alice is ready. |
| | Send INFO! |
| +----------------------+
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 183 (Answer) opt. |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| 200/ACK (Answer) |
|<------------------------|
Note: "SRFLX" denotes server-reflexive candidates
4.4. Delivering Candidates in INFO Requests
Whenever new ICE candidates become available for sending, agents encode them in "candidate" attributes as described by [RFC 8839]. For example:
The use of SIP INFO requests happens within the context of the Info Package as defined in Section 10. The media type [RFC 6838] for their payload MUST be set to "application/trickle-ice-sdpfrag" as defined in Section 9. The INFO request body adheres to the grammar as specified in Section 9.2.
Since neither the "candidate" nor the "end-of-candidates" attributes contain information that would allow correlating them to a specific "m=" line, it is handled through the use of pseudo "m=" lines.
Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in [RFC 4566] and are linked to the corresponding "m=" line in the SDP Offer or Answer via the identification tag in a "mid" attribute [RFC 5888]. 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 [RFC 3264].
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, the content might be unknown to the agent. In this case, the agent MUST include the following default values:
a=candidate:1 1 UDP 2130706432 200a0b:12f0::1 5000 typ host
- 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'.
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: 862
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 5000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 5001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 5010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 5011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5010 typ srflx
raddr 192.0.2.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5011 typ srflx
raddr 192.0.2.1 rport 8998
a=end-of-candidates
m=audio 9 RTP/AVP 0
a=mid:2
a=candidate:1 1 UDP 2130706432 2001:db8:a0b:12f0::1 6000 typ host
a=candidate:1 2 UDP 2130706432 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:1 1 UDP 2130706431 192.0.2.1 6010 typ host
a=candidate:1 2 UDP 2130706431 192.0.2.1 6011 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 6010 typ srflx
raddr 192.0.2.1 rport 9998
a=candidate:2 2 UDP 1694498815 192.0.2.3 6011 typ srflx
raddr 192.0.2.1 rport 9998
a=end-of-candidates
Note: In a real INFO request, there will be no line breaks
in the "candidate" attributes
5. Initial Discovery of Trickle ICE Support
SIP UAs are required by [RFC 8838] to indicate their support of and intent to use Trickle ICE in their Offers and Answers by using the "ice-options:trickle" attribute, and they 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.
5.1. 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 (SBCs) 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 resend the request without the SIP Require: header field and without the assumption of Trickle ICE support.
5.2. Trickle ICE Discovery with Globally Routable User Agent URIs (GRUUs)
[RFC 3840] provides a way for SIP UAs to query for support of specific capabilities using, among others, OPTIONS requests. On the other hand, support for GRUU according to [RFC 5627] 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 Section 10.6 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 (Figure 8). 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 [RFC 3840] gives SIP UAs the option to engage in Full Trickle negotiation (as opposed to the more lengthy Half Trickle) from the very first Offer they send.
Alice Bob
| |
| OPTIONS sip:b1@example.com SIP/2.0 |
|-------------------------------------------------->|
| |
| 200 OK |
| Contact: sip:b1@example.com;gr=hha9s8d-999a |
| ;audio;video|;trickle-ice;... |
|<--------------------------------------------------|
| |
| INVITE sip:b1@example.com;gr=hha9s8d-999a SIP/2.0 |
| Supported: trickle-ice |
| (Offer) |
|-------------------------------------------------->|
| |
| 183 (Answer) |
|<--------------------------------------------------|
| INFO/OK (Trickling) |
|<------------------------------------------------->|
| |
| ... |
| |
5.3. 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 [RFC 8838]. With Half Trickle, agents initiate sessions the same way they would when using ICE for SIP [RFC 8839]. 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 [RFC 8839] and legacy endpoints [RFC 3264].
As a reminder, once a single Offer or Answer has 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.
STUN/TURN STUN/TURN Servers Alice Bob Servers | | | | |<--------------| | | | | | | | | | | | Candidate | | | | | | | | | | | | Discovery | | | | | | | | | | | |-------------->| INVITE (Offer) | | | |---------------------------->| | | | 183 (Answer) |-------------->| | |<----------------------------| | | | INFO (repeated candidates) | | | |---------------------------->| | | | | | | | INFO (more candidates) | Candidate | | |<----------------------------| | | | Connectivity Checks | | | |<===========================>| Discovery | | | INFO (more candidates) | | | |<----------------------------| | | | Connectivity Checks |<--------------| | |<===========================>| | | | | | | | 200 OK | | | |<----------------------------| | | | | | | |<======= MEDIA FLOWS =======>| | | | | |
6. Considerations for RTP and RTCP Multiplexing
The following consideration describes options for Trickle ICE in order to give some guidance to implementers on how trickling can be optimized with respect to providing RTCP candidates.
Handling of the "rtcp" attribute [RFC 3605] and the "rtcp-mux" attribute for RTP/RTCP multiplexing [RFC 5761] is already considered in Section 5.1.1.1 of RFC 8445 and in [RFC 5761]. These considerations are still valid for Trickle ICE; however, trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing.
If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [RFC 8858], the procedures in that document apply for the handling of the "rtcp-mux-only", "rtcp", and "rtcp-mux" attributes.
While a Half Trickle Offerer has to send an Offer compliant to [RFC 8839] and [RFC 5761] including candidates for all components, the flexibility of a Full Trickle Offerer allows the sending of 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 "rtcp-mux" attribute [RFC 5761] 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 "rtcp" attribute as given in [RFC 8839] and [RFC 3605]. 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 the 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 4.3, 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 RTCP candidates or releasing already gathered RTCP candidates. If the INFO request did not contain the "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 already sent RTCP candidates in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even when that support for RTCP multiplexing was confirmed by the Answerer and the Offerer has released its RTCP candidates.
v=0 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com s= c=IN IP6 2001:db8:a0b:12f0::3 t=0 0 a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-ufrag:Yhh8 m=audio 5000 RTP/AVP 0 a=mid:1 a=rtcp-mux a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 161 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:1 a=rtcp-mux a=candidate:1 1 UDP 1658497382 2001:db8:a0b:12f0::4 6000 typ host
7. Considerations for Media Multiplexing
The following considerations describe options for Trickle ICE in order to give some guidance to implementers on how trickling can be optimized with respect to providing candidates in case of Media Multiplexing [RFC 8843]. It is assumed that the reader is familiar with [RFC 8843].
ICE candidate exchange is already considered in Section 10 of RFC 8843. 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 that is 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 a "group:BUNDLE" attribute [RFC 8843] 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 behavior is illustrated by the following example Offer that indicates support for Media Multiplexing.
If the Offerer already sent candidates for "m=" lines in a bundle in a previous INFO request, it still needs to repeat them in subsequent INFO requests, even when that support for bundling was confirmed by the Answerer and the Offerer has released candidates that are no longer needed.
The example Offer indicates support for RTP and RTCP multiplexing and contains a "candidate" attribute only for the "m=" line with the suggested Offerer BUNDLE address. Once the dialog is established as described in Section 4.3, 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 RTP and RTCP candidates for the other "m=" lines or releasing already gathered candidates. If the INFO request did not contain the "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 [RFC 8859] apply to both, Offerer and Answerer, when putting attributes as specified in Section 9.2 in the "application/trickle-ice-sdpfrag" body.
v=0 o=alice 2890844526 2890844526 IN IP6 atlanta.example.com s= c=IN IP6 2001:db8:a0b:12f0::3 t=0 0 a=group:BUNDLE foo bar a=ice-pwd:777uzjYhagZgasd88fgpdd a=ice-ufrag:Yhh8 m=audio 10000 RTP/AVP 0 a=mid:foo a=rtcp-mux a=rtpmap:0 PCMU/8000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 10000 typ host m=video 10002 RTP/AVP 31 a=mid:bar a=rtcp-mux a=rtpmap:31 H261/90000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/trickle-ice-sdpfrag Content-Disposition: Info-Package Content-length: 219 a=group:BUNDLE foo bar a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 9 RTP/AVP 0 a=mid:foo a=rtcp-mux a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
8. SDP "end-of-candidates" Attribute
8.1. Definition
This section defines the new SDP media-level and session-level [RFC 4566] "end-of-candidates" attribute. "end-of-candidates" is a property attribute [RFC 4566]; hence, it 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 the session level, this indication applies to the whole session; when included at the 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
8.2. Offer/Answer Procedures
The Offerer or Answerer MAY include an "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 "end-of-candidates" attribute together with the "ice-ufrag" and "ice-pwd" attributes of the current ICE generation as required by [RFC 8838]. When included at the session level, this indication applies to the whole session; when included at the media level, the indication applies only to the corresponding media description.
Receipt of an "end-of-candidates" attribute at an Offerer or Answerer -- with the "ice-ufrag" and "ice-pwd" attributes matching the current ICE generation -- indicates that the gathering of candidates has ended at the peer, for either the session or only 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 [RFC 8838].
9. Content Type "application/trickle-ice-sdpfrag"
9.1. Overall Description
An "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 in [RFC 4566]. 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.
9.2. Grammar
The grammar of an "application/trickle-ice-sdpfrag" body is based on the following ABNF [RFC 5234]. It specifies the subset of existing SDP attributes that is needed or useful for trickling candidates. The grammar uses the indicator for case-sensitive %s, as defined in [RFC 7405], but it also imports grammar for other SDP attributes that precede the production of [RFC 7405]. A sender SHOULD use lower case for attributes from such earlier grammar, but a receiver MUST treat them as case insensitive.
ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att, ice-options, candidate-attribute, and remote-candidate-att are from [RFC 8839]; identification-tag and mid-attribute are from [RFC 5888]; and media-field and attribute-fields are from [RFC 4566]. The "rtcp" attribute is defined in [RFC 3605], the "rtcp-mux" attribute is defined in [RFC 5761], and the "rtcp-mux-only" attribute is defined in [RFC 8858]. The latter attributes lack formal grammar in their corresponding RFCs and are reproduced here.
The "ice-pwd" and "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.
; Syntax
trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions
session-level-fields = *(session-level-field CRLF)
session-level-field = ice-lite-attribute /
ice-pwd-attribute /
ice-ufrag-attribute /
ice-options-attribute /
ice-pacing-attribute /
end-of-candidates-attribute /
bundle-group-attribute /
extension-attribute-fields
; for future extensions
ice-lite-attribute = %s"a" "=" ice-lite
ice-pwd-attribute = %s"a" "=" ice-pwd-att
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
ice-pacing-attribute = %s"a" "=" ice-pacing-att
ice-options-attribute = %s"a" "=" ice-options
end-of-candidates-attribute = %s"a" "=" end-of-candidates
end-of-candidates = %s"end-of-candidates"
bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
*(SP identification-tag)
bundle-semantics = "BUNDLE"
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields )
trickle-ice-attribute-fields = *(trickle-ice-attribute-field CRLF)
trickle-ice-attribute-field = mid-attribute /
candidate-attributes /
ice-pwd-attribute /
ice-ufrag-attribute /
remote-candidate-attribute /
end-of-candidates-attribute /
rtcp-attribute /
rtcp-mux-attribute /
rtcp-mux-only-attribute /
extension-attribute-fields
; for future extensions
rtcp-attribute = %s"a" "=" %s"rtcp"
rtcp-mux-attribute = %s"a" "=" %s"rtcp-mux"
rtcp-mux-only-attribute = %s"a" "=" %s"rtcp-mux-only"
candidate-attributes = %s"a" "=" candidate-attribute
remote-candidate-attribute = %s"a" "=" remote-candidate-att
10. Info Package
10.1. Rationale -- 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, the 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 [RFC 3311] would introduce the following complications:
- Blocking of messages:
- Offer/Answer is defined as a strictly sequential mechanism in [RFC 3264]. 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. [RFC 3261], 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 and the average two-second backoff intervals to occur implies that the duration of Trickle ICE processing would not only fail to improve but actually exceed those of regular ICE.
10.2. Overall Description
This specification defines an Info Package for use by SIP UAs implementing Trickle ICE. INFO requests carry ICE candidates discovered after the peer UAs have confirmed mutual support for Trickle ICE.
10.3. 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.
10.4. Info Package Name
This document defines a SIP Info Package as per [RFC 6086]. The Info Package token name for this package is "trickle-ice".
10.5. Info Package Parameters
This document does not define any Info Package parameters.
10.6. SIP Option Tags
[RFC 6086] 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.
option-tag /= "trickle-ice"
10.7. INFO Request Body Parts
Entities implementing this specification MUST include a payload of type "application/trickle-ice-sdpfrag" in SIP INFO requests as defined in Section 9.2. The payload is used to convey SDP-encoded ICE candidates.
10.8. Info Package Usage Restrictions
This document does not define any Info Package Usage Restrictions.
10.9. 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 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 RFC 3261, Section 17.1.2.1.
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 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.
10.10. Info Package Security Considerations
See Section 13.
11. Deployment Considerations
Trickle ICE uses two mechanisms for the 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 understand the INFO request body.
12. IANA Considerations
12.1. SDP "end-of-candidates" Attribute
This section defines a new SDP media-level and session-level [RFC 4566] "end-of-candidates" attribute, which is a property attribute [RFC 4566] and hence has no value.
-
- Name:
- end-of-candidates
- Value:
- N/A
- Usage Level:
- media and session
- Charset Dependent:
- no
- Purpose:
- The sender indicates that it will not trickle further ICE candidates.
- O/A Procedures:
- RFC 8840 defines the detailed SDP Offer/Answer procedures for the "end-of-candidates" attribute.
- Mux Category:
- IDENTICAL
- Reference:
- RFC 8840
- Example:
- a=end-of-candidates
12.2. Media Type "application/trickle-ice-sdpfrag"
This document defines the new media type "application/trickle-ice-sdpfrag" in accordance with [RFC 6838].
- 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 Section 9.2. 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 [RFC 4566]). Arbitrary binary content cannot be directly represented in SDP or a trickle-ice-sdpfrag body.
- Security considerations:
- See [RFC 4566] and RFC 8840
- Interoperability considerations:
- See RFC 8840
- Published specification:
- See RFC 8840
- Applications that 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 RFC 8840.
- Restrictions on usage:
- N/A
- Author/Change controller:
- The IESG (iesg@ietf.org)
- Provisional registration? (standards tree only):
- N/A
12.3. 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.
Table 1
| Name | Reference |
|---|---|
| trickle-ice | RFC 8840 |
12.4. SIP Option Tag "trickle-ice"
This specification registers a new SIP option tag "trickle-ice" as per the guidelines in Section 27.1 of RFC 3261 and updates the "Option Tags" subregistry of the SIP Parameters registry with the following entry:
Table 2
| Name | Description | Reference |
|---|---|---|
| trickle-ice | This option tag is used to indicate that a UA supports and understands Trickle ICE. | RFC 8840 |
13. Security Considerations
The Security Considerations of [RFC 6086], [RFC 8838], and [RFC 8839] 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
14. References
14.1. Normative References
- [RFC2119]
-
S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/ >.rfc2119 - [RFC3261]
-
J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/ >.rfc3261 - [RFC3262]
-
J. Rosenberg, and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<https://www.rfc-editor.org/info/ >.rfc3262 - [RFC3264]
-
J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/ >.rfc3264 - [RFC3605]
-
C. Huitema, "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003,
<https://www.rfc-editor.org/info/ >.rfc3605 - [RFC4566]
-
M. Handley, V. Jacobson, and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006,
<https://www.rfc-editor.org/info/ >.rfc4566 - [RFC5234]
-
D. Crocker, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/ >.rfc5234 - [RFC5761]
-
C. Perkins, and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010,
<https://www.rfc-editor.org/info/ >.rfc5761 - [RFC5888]
-
G. Camarillo, and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010,
<https://www.rfc-editor.org/info/ >.rfc5888 - [RFC6086]
-
C. Holmberg, E. Burger, and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011,
<https://www.rfc-editor.org/info/ >.rfc6086 - [RFC6838]
-
N. Freed, J. Klensin, and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/ >.rfc6838 - [RFC7405]
-
P. Kyzivat, "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/ >.rfc7405 - [RFC8174]
-
B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/ >.rfc8174 - [RFC8445]
-
A. Keranen, C. Holmberg, and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/ >.rfc8445 - [RFC8838]
-
E Ivov, J Uberti, and P Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", RFC 8838, DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/info/ >.rfc8838 - [RFC8839]
-
M Petit-Huguenin, S Nandakumar, C Holmberg, A Keränen, and R Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021,
<https://www.rfc-editor.org/info/ >.rfc8839 - [RFC8843]
-
C Holmberg, H Alvestrand, and C Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021,
<https://www.rfc-editor.org/info/ >.rfc8843 - [RFC8858]
-
C. Holmberg, "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI 10.17487/RFC8858, January 2021,
<https://www.rfc-editor.org/info/ >.rfc8858 - [RFC8859]
-
S Nandakumar, "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021,
<https://www.rfc-editor.org/info/ >.rfc8859
14.2. Informative References
- [RFC3311]
-
J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002,
<https://www.rfc-editor.org/info/ >.rfc3311 - [RFC3840]
-
J. Rosenberg, H. Schulzrinne, and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004,
<https://www.rfc-editor.org/info/ >.rfc3840 - [RFC5389]
-
J. Rosenberg, R. Mahy, P. Matthews, and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/ >.rfc5389 - [RFC5627]
-
J. Rosenberg, "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
<https://www.rfc-editor.org/info/ >.rfc5627 - [RFC5766]
-
R. Mahy, P. Matthews, and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/ >.rfc5766
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 authors thank Benjamin Kaduk, Adam Roach, Mirja Kühlewind, and Eric Rescorla for their comments and/or text proposals for improving the document during IESG review.
Many thanks to Dale Worley for the Gen-Art review and proposed enhancements for several sections.
Many thanks to Joerg Ott for the TSV-Art review and suggested improvements.
The authors thank Shawn Emery for the Security Directorate review.
Authors' Addresses
Emil Ivov
Jitsi
Strasbourg 67000
France
Phone: +33 6 72 81 15 55
Email: emcho@jitsi.org
Thomas Stach
Unaffiliated
Vienna 1130
Austria
Email: thomass.stach@gmail.com
Enrico Marocco
Telecom Italia
Via G. Reiss Romoli, 274
Turin 10148
Italy
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
