| Network Working Group | E. Ivov |
| Internet-Draft | Jitsi |
| Intended status: Standards Track | T. Stach |
| Expires: May 17, 2018 | Unaffiliated |
| E. Marocco | |
| Telecom Italia | |
| C. Holmberg | |
| Ericsson | |
| November 13, 2017 |
A Session Initiation Protocol (SIP) usage for Trickle ICE
draft-ietf-mmusic-trickle-ice-sip-11
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) and defines a new SIP Info Package.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2018.
Copyright (c) 2017 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.
The Interactive Connectivity Establishment protocol [I-D.ietf-mmusic-rfc5245bis] describes a mechanism for NAT traversal that consists of three main phases: a phase where an agent gathers a set of candidate transport addresses (source IP address, port and transport protocol), a second phase where these candidates are sent to a remote agent. There, this gathering procedure is repeated and, finally, a third phase starts 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 [I-D.ietf-mmusic-rfc5245bis] the three phases above happen consecutively, in a blocking way, which can introduce undesirable latency during session establishment.
The Trickle ICE extension [I-D.ietf-ice-trickle] defines generic semantics required for these ICE phases to happen simultaneously, in a non-blocking way and hence speed up session establishment.
This specification defines a usage of Trickle ICE with the Session Initiation Protocol (SIP)[RFC3261]. It describes how ICE candidates are to be exchanged incrementally with SIP INFO requests [RFC6086] and how the Half Trickle and Full Trickle modes defined in [I-D.ietf-ice-trickle] 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 [RFC6086] for use with Trickle ICE.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This specification makes use of all terminology defined by the protocol for Interactive Connectivity Establishment in [I-D.ietf-mmusic-rfc5245bis] and its Trickle ICE extension [I-D.ietf-ice-trickle]. It is assumed that the reader will be familiar with the terminology from both documents.
When using ICE for SIP according to [I-D.ietf-mmusic-ice-sip-sdp] the ICE candidates are exchanged solely via SDP Offer/Answer as per [RFC3264]. This specification defines an additional mechanism where candidates can be exchanged using SIP INFO messages and a newly defined Info Package [RFC6086]. This allows ICE candidates also to be sent in parallel to an ongoing Offer/Answer negotiation and/or after the completion of the Offer/Answer negotiation.
Typically, in cases where Trickle ICE is fully supported, the Offerer would send 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 =====>| |
| | | |
Figure 1: Sample Trickle ICE scenario with SIP
In order to benefit from Trickle ICE's full potential and reduce session establishment latency to a minimum, Trickle ICE agents need to generate SDP Offers and Answers that contain incomplete, potentially empty sets of candidates. Such Offers and Answers can only be handled meaningfully by agents that actually support incremental candidate provisioning, which implies the need to confirm such support before actually using it.
Contrary to other protocols, like XMPP [RFC6120], where "in advance" capability discovery is widely implemented, the mechanisms that allow this for SIP (i.e., a combination of UA Capabilities [RFC3840] and GRUU [RFC5627]) 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 [I-D.ietf-ice-trickle] provides one way around this, by requiring the first Offer to contain a complete set of local ICE candidates and only using incremental provisioning of remote candidates for the rest of the session.
While using Half Trickle does provide a working solution it also comes at the price of increased latency. Section 5 therefore 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 on-line provisioning as a means of allowing 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.4 discusses the implementation and use of Half Trickle by SIP UAs where none of the above are an option.
From the perspective of all SIP middle boxes and proxies, and with the exception of the actual INFO messages, signaling in general and Offer/Answer exchanges in particular would look the same way for Trickle ICE as they would for ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp].
+-------------------------------+ +-------------------------------+
| Alice +--------------+ | | +--------------+ Bob |
| | Offer/Answer | | | | Offer/Answer | |
| +-------+ | Module | | | | Module | +-------+ |
| | ICE | +--------------+ | | +--------------+ | ICE | |
| | Agent | | | | | | Agent | |
| +-------+ | | | | +-------+ |
+-------------------------------+ +-------------------------------+
| | | |
| | INVITE (Offer) | |
| |--------------------->| |
| | 183 (Answer) | |
| |<---------------------| |
| | | |
| |
| SIP INFO (more candidates) |
|----------------------------------------------------->|
| SIP INFO (more candidates) |
|<-----------------------------------------------------|
| |
| STUN Binding Requests/Responses |
|----------------------------------------------------->|
| STUN Binding Requests/Responses |
|<-----------------------------------------------------|
| |
Figure 2: Distinguishing between Trickle ICE and traditional signaling.
From an architectural viewpoint, as displayed in Figure 2, exchanging candidates through SIP INFO requests could be represented as signaling between ICE Agents and not between Offer/Answer modules of SIP User Agents. Then, such INFO requests do not impact the state of the Offer/Answer transaction other than providing additional candidates. Consequently, INFO requests are not considered Offers or Answers. Nevertheless, candidates that have been exchanged using INFO SHALL be included in subsequent Offers or Answers. The version number in the "o=" line of that subsequent offer would need to be incremented by 1 per the rules in [RFC3264].
Trickle ICE Agents will construct Offers and Answers with ICE descriptions compliant to [I-D.ietf-ice-trickle] and the following additional SIP-specific additions:
The following sections provide further details on how Trickle ICE Agents perform the initial Offers/Answers exchange and establish the INVITE dialog usage such that they can trickle candidates.
If the Offerer includes candidates in its initial Offer, it MUST encode these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp].
If the Offerer wants to send its initial Offer before knowing any candidate of one or more media descriptions, it MUST include the following default values in the corresponding "m=" line.
In this case, the Offerer obviously cannot know the RTCP transport address and, thus, MUST NOT include the "a=rtcp" attribute [RFC6086]. This avoids potential ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]) for the RTCP transport address.
If the Offerer wants to use RTCP multiplexing [RFC5761] and/or exclusive RTCP multiplexing [I-D.ietf-mmusic-mux-exclusive], it still MUST include the "a=rtcp-mux" and/or "a=rctp-mux-only" attribute in the initial Offer.
In any case, the Offerer MUST include the attribute a=ice-options:trickle in accordance to [I-D.ietf-ice-trickle].
If the initial Offer included candidates, the Answerer MUST treat these candidates as specified in [I-D.ietf-mmusic-ice-sip-sdp].
If the initial Offer included the attribute a=ice-options:trickle, the Answerer MUST be prepared for receiving trickled candidates later on.
In case of a "m=" lines with default values neither of the eventually trickled candidates will match the default destination. This situation MUST NOT cause an ICE mismatch (see [I-D.ietf-mmusic-ice-sip-sdp]).
Section Section 4.1.1 applies to the Answerer with the roles of Offerer and Answer being swapped.
Section Section 4.1.2 applies to the Answerer with the roles of Offerer and Answer being swapped.
In order to be able to start trickling, the following two conditions need to be satisfied at the SIP UAs:
Section 5 discusses in detail the various options for satisfying the first of the above conditions. Regardless of those mechanisms, however, agents are certain to have a clear understanding of whether their peers support trickle ICE once an Offer and an Answer have been exchanged, which also allows for ICE processing to commence (see Figure 3).
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.) |
|<------------------------|
| |
Figure 3: SIP Offerer can freely trickle as soon as it receives an Answer.
As shown in Figure 3 satisfying both conditions is relatively trivial for ICE Agents that have sent an Offer in an INVITE and that have received an Answer in a reliable provisional response. It is guaranteed to have confirmed support for Trickle ICE at the Answerer (or lack thereof) and to have fully initialized the SIP dialog at both ends. Offerers and Answerers (after receipt of the PRACK request) in the above situation can therefore freely commence trickling within the newly established dialog.
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).
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??? |
| +----------------------+
| |
Figure 4: A SIP UA that sent an Answer in an unreliable provisional response does not know if it was received and if the dialog at the side of the Offerer has entered the early state
In order to clear this ambiguity as soon as possible, the Answerer needs to retransmit the provisional response with the exponential back-off timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request or on transmission of the Answer in a 2xx response. This is similar to the procedure described in section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that the STUN binding Request is replaced by the INFO request.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for version 14 of said I-D. Please cross-check since it could have have changed in the meantime.]
The Offerer MUST send a Trickle ICE INFO request as soon as it receives an SDP Answer in an unreliable provisional response. This INFO request MUST repeat the candidates that were already provided in the Offer (as would be the case when Half Trickle is performed or when new candidates have not been learned since then) and/or they MAY also deliver newly learned candidates (if available). The Offerer MAY include an end-of-candidates attribute in case candidate discovery has ended in the mean time.
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 MAY begin trickling (Figure 5).
Note: The +SRFLX in Figure 5 indicates that additionally newly learned server-reflexive candidates are included.
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) |
|<------------------------|
Figure 5: A SIP UA that received an INFO request after sending an unreliable provisional response knows that the dialog at the side of the receiver has entered the early state
When sending the Answer in the 200 OK response to the INVITE request, the Answerer MUST repeat exactly the same Answer that was previously sent in the unreliable provisional response in order to fulfill the corresponding requirements in [RFC3264]. 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.
The possibility to convey arbitrary candidates in INFO message bodies allows ICE Agents to initiate trickling without actually sending an Answer. Trickle ICE Agents MAY therefore respond to an INVITE request with provisional responses without an SDP Answer. Such provisional responses serve for establishing an early dialog.
Agents that choose to establish the dialog in this way, MUST retransmit these responses with the exponential back-off timers described in [RFC3262]. These retransmissions MUST cease on receipt of an INFO request or on transmission of the Answer in a 2xx response. This is again similar to the procedure described in section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer is not yet provided.
[RFC EDITOR NOTE: The section 8.1.1 in above sentence is correct for version 14 of said I-D. Please cross-check since it could have have changed in the meantime.]
Note: The +SRFLX in Figure 6 indicates that additionally newly learned server-reflexive candidates are included.
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) |
|<------------------------|
Figure 6: A SIP UA sends an unreliable provisional response without an Answer for establishing an early dialog
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. If that Answer was sent in a unreliable provisional response, the Answerers MUST repeat exactly the same Answer in the 200 OK response to the INVITE request in order to fulfill the corresponding requirements in [RFC3264]. 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.
Agents that have sent an Offer in a reliable provisional response and that receive an Answer in a PRACK are also in a situation where support for Trickle ICE is confirmed and the SIP dialog is guaranteed to be in a state that would allow in-dialog INFO requests (see Figure 7).
Alice Bob
| |
| INVITE |
|------------------------>|
| 183 (Offer) |
|<------------------------|
| PRACK (Answer) |
|------------------------>|
| |
| +----------------------+
| |Bob: I know Alice can|
| |trickle and I know her|
| |dialog is in the early|
| |state. Send INFO! |
| +----------------------+
| |
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| |
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| 200 OK/ACK |
|<------------------------|
Figure 7: A SIP Offerer in a 3PCC scenario can also freely start trickling as soon as it receives an Answer.
Trickle Agents that send an Offer in a 200 OK and receive an Answer in an ACK can still create a dialog and confirm support for Trickle ICE by sending an unreliable provisional response similar to Section 4.2.3. According to [RFC3261], this unreliable response MUST NOT contain an Offer.
The Trickle Agent (at the UAS) retransmits the provisional response with the exponential back-off timers described in [RFC3262]. Retransmits MUST cease on receipt of an INFO request or on transmission of the Answer in a 2xx response. The peer Trickle Agent (at the UAC) MUST send a Trickle ICE INFO request as soon as they receive an unreliable provisional response (see Figure 8).
Alice Bob
| |
| INVITE |
|------------------------>|
| 183 (-) |
|<------------------------|
| INFO/OK (SRFLX Cand.) |
|------------------------>|
| |
| +-----------------------+
| |Bob: I know Alice can |
| |trickle and I know her |
| |dialog is in the early |
| |state. |
| |INFO can be sent. |
| +-----------------------+
| |
| INFO/OK (SRFLX Cand.) |
|<------------------------|
| |
| 200 (Offer) |
|<------------------------|
| ACK (Answer) |
|------------------------>|
| |
Figure 8: A SIP UAC in a 3PCC scenario can also freely start trickling as soon as it receives an unreliable provisional response.
Whenever new ICE candidates become available for sending, agents would encode them in "a=candidate" lines as described by [I-D.ietf-mmusic-ice-sip-sdp]. For example:
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 8998
The use of SIP INFO requests happens within the context of the Info Package as defined Section 10. The Media Type [RFC6838] for their payload MUST be set to 'application/trickle-ice-sdpfrag' as defined in Section 9.
Since neither the "a=candidate" nor the "a=end-of-candidates" attributes contain information that would allow correlating them to a specific "m=" line, this is handled through the use of pseudo "m=" lines and identification tags in "a=mid:" attributes as defined in [RFC5888]. Pseudo "m=" lines follow the SDP syntax for "m=" lines as defined in [RFC4566], but provide no 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 [RFC3264].
When sending the INFO request, the agent MAY, if already known to the agent, include the same content into the pseudo "m=" line as for the "m=" line in the corresponding Offer or Answer. However, since Trickle-ICE might be decoupled from the Offer/Answer negotiation this content might be unknown to the agent. In this case, the agent MUST include the following default values.
Agents MUST include a pseudo "m=" line and an identification tag in a "a=mid:" attribute for every "m=" line whose candidate list they intend to update. Such "a=mid:" attributes MUST immediately precede the list of candidates for that specific "m=" line. All "a=candidate" or "a=end-of-candidates" attributes following an "a=mid:" attribute, up until (and excluding) the next occurrence of a pseudo "m=" line, pertain to the "m=" line identified by that identification tag. An "a=end-of-candidates" attribute, preceding any pseudo "m=" line, indicates the end of all trickling from that agent, as opposed to end of trickling for a specific "m=" line, which would be indicated by a media level "a=end-of-candidates" attribute.
Refer to Figure 9 for an example of the INFO request content.
The use of pseudo "m=" lines allows for a structure similar to the one in SDP Offers and Answers where separate media-level and session-level sections can be distinguished. In the current case, lines preceding any pseudo "m=" line are considered to be session-level. Lines appearing in between or after pseudo "m=" lines will be interpreted as media-level.
All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" attributes that would allow mapping them to a specific ICE generation. An agent MUST discard any received INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not match those of the current ICE Negotiation Session.
The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the same level as the ones in the Offer/Answer exchange. In other words, if they were present as session-level attributes, they will also appear at the beginning of all INFO request payloads, i.e. preceding 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.
Note that [I-D.ietf-ice-trickle] requires that when candidates are trickled, each candidate MUST be delivered to the receiving Trickle ICE implementation not more than once and in the same order as it was conveyed. If the signaling protocol provides any candidate retransmissions, they need to be hidden from the ICE implementation. This requirement is fulfilled as follows.
Since the agent is not fully aware of the state of the ICE Negotiation Session at its peer it MUST include all currently known and used local candidates in every INFO request. I.e. the agent MUST repeat in the INFO request body all candidates that were previously sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in the same order as they were gathered. In other words, the sequence of a previously sent list of candidates MUST NOT change in subsequent INFO requests and newly gathered candidates MUST be added at the end of that list. Although repeating all candidates creates some overhead, it also allows easier handling of problems that could arise from unreliable transports, like e.g. loss of messages and reordering, which can be detected through the CSeq: header field in the INFO request.
When receiving INFO requests carrying any candidates, agents will therefore first identify and discard the attribute lines containing candidates they have already received in previous INFO requests or in the Offer/Answer exchange preceding them. Two candidates are considered to be equal if their IP address port, transport and component ID are the same. After identifying and discarding known candidates, the agents MUST forward the actually new candidates to the ICE Agents in the same order as they were received in the INFO request body. The ICE Agents will then process the new candidates according to the rules described in [I-D.ietf-ice-trickle].
Receiving an "a=end-of-candidates" attribute in an INFO request body - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - is an indication of the peer agent that it will not send any further candidates. When included at session level, i.e. before any pseudo "m=" line, this indication applies to the whole session; when included at media level the indication applies only to the corresponding "m=" line. Handling of such end-of-candidate indications is defined in [I-D.ietf-ice-trickle].
Note: At the time of writing this specification there were ongoing discussions if a functionality for removing already exchanged candidates would be useful. Such a functionality is out of the scope of this specification and most likely needs to be signaled by means of a yet to be defined ICE extension, although it could in principle be achieved quite easily, e.g. without anticipating any solution by simply omitting a previously sent candidate from a subsequent INFO request. However, if an implementation according to this specification receives such an INFO request with a missing candidate it MAY treat that as an exceptional case. Implementing appropriate recovery procedures at the receiving side is RECOMMENDED for this situation. Ignoring that a candidate was missing might be a sensible strategy.
The following example shows the content of one sample candidate delivering INFO request:
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/trickle-ice-sdpfrag
Content-Disposition: Info-Package
Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host
a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 8998
a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 8998
a=end-of-candidates
m=audio 9 RTP/AVP 0
a=mid:2
a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host
a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host
a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 9998
a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx
raddr 2001:db8:a0b:12f0::1 rport 9998
a=end-of-candidates
Figure 9: An Example for the Content of an INFO Request
SIP User Agents (UAs) that support and intend to use trickle ICE are REQUIRED by [I-D.ietf-ice-trickle] to indicate that in their Offers and Answers using the following attribute: "a=ice-options:trickle". This makes discovery fairly straightforward for Answerers or for cases where Offers need to be generated within existing dialogs (i.e., when sending re-INVITE requests). In both scenarios prior SDP would have provided the necessary information.
Obviously, prior SDP 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.
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 likely to be the case, for example, for WebRTC clients that will always be communicating with other WebRTC clients or known Session Border Controllers (SBC) with support for this specification.
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.
[RFC3840] provides a way for SIP User Agents to query for support of specific capabilities using, among others, OPTIONS requests. GRUU support on the other hand allows SIP requests to be addressed to specific UAs (as opposed to arbitrary instances of an address of record). Combining the two and using the "trickle-ice" option tag defined in Section 10.6 provides SIP UAs with a way of learning the capabilities of specific US instances and then addressing them directly with INVITE requests that require SIP support.
Such targeted trickling may happen in different ways. One option would be for a SIP UA to learn the GRUU instance ID of a peer through presence and to then query its capabilities direction with an OPTIONS request. Alternately, it can also just send an OPTIONS request to the AOR it intends to contact and then inspect the returned response(s) for support of both GRUU and Trickle ICE (Figure 10).
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 |
|-------------------------------------------------->|
| |
| 183 (Answer) |
|<--------------------------------------------------|
| INFO/OK (Trickling) |
|<------------------------------------------------->|
| |
| ... |
| |
Figure 10: Trickle ICE support discovery with OPTIONS and GRUU
Confirming support for Trickle ICE through [RFC3840] gives SIP UAs the options to engage in Full Trickle negotiation (as opposed to the more lengthy Half Trickle) from the very first Offer they send.
Protocols like XMPP [RFC6120] define advanced discovery mechanisms that allow specific features to be queried priory to actually attempting to use them. Solutions like [RFC7081] define ways of using SIP and XMPP together which also provides a way for dual stack SIP+XMPP endpoints to make use of such features and verify Trickle ICE support for a specific SIP endpoint through XMPP. However, such discovery mechanisms are out of the scope of this document.
In cases where none of the other mechanisms in this section are acceptable, SIP UAs should use the Half Trickle mode defined in [I-D.ietf-ice-trickle]. With Half Trickle, agents initiate sessions the same way they would when using ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp]. This means that, prior to actually sending an Offer, agents would first gather ICE candidates in a blocking way and then send them all in that Offer. The blocking nature of the process would likely imply that some amount of latency will be accumulated and it is advised that agents try to anticipate it where possible, like 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 would result in Offers that are compatible with both ICE SIP endpoints and legacy [RFC3264] endpoints.
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 =======>| |
| | | |
Figure 11: Example - A typical (Half) Trickle ICE exchange with SIP
It is worth reminding that once a single Offer or Answer had been exchanged within a specific dialog, support for Trickle ICE will have been determined. No further use of Half Trickle will therefore be necessary within that same dialog and all subsequent exchanges can use the Full Trickle mode of operation.
The following consideration describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing RTCP candidates.
Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing [RFC5761] is already considered in section 5.6.1. of [I-D.ietf-mmusic-rfc5245bis] and as well in [RFC5761] itself. These considerations are still valid for Trickle ICE, however, trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing.
[RFC EDITOR NOTE: The section 5.6.1 in above sentence is correct for version 05 of said I-D. Please cross-check since it could have have changed in the meantime.]
If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" and the "a=rtcp-mux" attributes.
While a Half Trickle Offerer would have to send an offer compliant to [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for all components, this flexibility allows a Full Trickle Offerer to send only RTP candidates (component 1) in the initial Offer if it assumes that RTCP multiplexing is supported by the Answerer. A Full Trickle Offerer would need to start gathering and trickling RTCP candidates (component 2) only after having received an indication in the Answer that the Answerer unexpectedly does not support RTCP multiplexing.
A Trickle Answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in the application/trickle-ice-sdpfrag body if it supports and uses RTP and RTCP multiplexing. The Trickle Answerer MUST follow the guidance on the usage of the "a=rtcp" attribute as given in [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]. Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses RTP and RTCP multiplexing. The Offerer can use this information e.g. for stopping gathering of RTCP candidates and/or for freeing corresponding resources.
This behavior is illustrated by the following example offer that indicates support for RTP and RTCP multiplexing.
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
Once the dialog is established as described in section Section 4.2 the Answerer sends the following INFO request.
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/sdp
Content-Disposition: Info-Package
Content-length: ...
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:1
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
This INFO request indicates that the Answerer supports and uses RTP and RTCP multiplexing as well. It allows the Offerer to omit gathering of RTCP candidates or releasing already gathered RTCP candidates. If the INFO request did not contain the a=rtcp-mux attribute, the Offerer would have to gather RTCP candidates unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for RTP and RTCP multiplexing.
The following considerations describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing candidates in case of Media Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed that the reader is familiar with [I-D.ietf-mmusic-sdp-bundle-negotiation].
ICE candidate exchange is already considered in section 11 of [I-D.ietf-mmusic-sdp-bundle-negotiation]. 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 would have 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.
Latest on receipt of the Answer, the Offerer will detect if BUNDLE is supported by the Answerer and if the suggested Offerer BUNDLE address was selected. In this case, the Offerer does not need to trickle further candidates for the remaining "m=" lines in a bundle. However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates for the remaining "m=" lines as necessary. If the Answerer selects an Offerer BUNDLE address different from the suggested Offerer BUNDLE address, the Full Trickle Offerer needs to gather and trickle candidates for the "m=" line that carries the selected Offerer BUNDLE address.
A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle-ice-sdpfrag body if it supports and uses bundling. When doing so, the Answerer MUST include all identification-tags in the same order that is used or will be used in the Answer.
Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses bundling. The Offerer can use this information e.g. for stopping the gathering of candidates for the remaining "m=" lines in a bundle and/or for freeing corresponding resources.
This behaviour is illustrated by the following example offer that indicates support for Media Multiplexing.
v=0
o=alice 2890844526 2890844526 IN IP6 atlanta.example.com
s=
c=IN IP6 atlanta.example.com
t=0 0
a=group:BUNDLE foo bar
a=ice-pwd:777uzjYhagZgasd88fgpdd
a=ice-ufrag:Yhh8
m=audio 10000 RTP/AVP 0
a=mid:foo
a=rtpmap:0 PCMU/8000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31
a=mid:bar
a=rtpmap:31 H261/90000
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
Once the dialog is established as described in section Section 4.2 the Answerer sends the following INFO request.
INFO sip:alice@example.com SIP/2.0
...
Info-Package: trickle-ice
Content-type: application/sdp
Content-Disposition: Info-Package
Content-length: ...
a=group:BUNDLE foo bar
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 9 RTP/AVP 0
a=mid:foo
a=rtcp-mux
a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
m=audio 9 RTP/AVP 0
a=mid:bar
This INFO request indicates that the Answerer supports and uses Media Multiplexing as well. Note, that the second "m=" line shows the default values as specified in section Section 4.3, e.g. media set 'audio' although 'video' was offered. The receiving ICE Agents MUST ignore these default values in the pseudo "m=" lines.
The INFO request also indicates that the Answerer accepted the suggested Offerer Bundle Address. This allows the Offerer to omit gathering of RTP and RTCP candidates for the other "m=" lines or releasing already gathered candidates. If the INFO request did not contain the a=group:BUNDLE attribute, the Offerer would have to gather RTP and RTCP candidates for the other "m=" lines unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for Media Multiplexing.
Independent of using Full Trickle or Half Trickle mode, the rules from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and Answerer, when putting attributes as specified in Section 9.2 in the application/trickle-ice-sdpfrag body.
This section defines a new SDP media-level and session-level attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a property attribute [RFC4566], and hence has no value. By including this attribute in an Offer or Answer the sending agent indicates that it will not trickle further candidates. When included at session level this indication applies to the whole session, when included at media level the indication applies only to the corresponding media desciption.
The Offerer or Answerer MAY include an "a=end-of-candidates" attribute in case candidate discovery has ended and no further candidates are to be trickled. The Offerer or Answerer MUST provide the "a=end-of-candidates" attribute together with the "a=ice-ufrag" and "a=ice-pwd" attributes of the current ICE generation as required by [I-D.ietf-ice-trickle]. When included at session level this indication applies to the whole session; when included at media level the indication applies only to the corresponding media description.
Receipt of an "a=end-of-candidates" attribute at an Offerer or Anwerer - with the "a=ice-ufrag" and "a=ice-pwd" attributes matching the current ICE generation - indicates that gathering of candidates has ended at the peer, either for the session or only for the corresponding media description as specified above. The receiving agent forwards an end-of-candidates indication to the ICE Agent, which in turn acts as specified in [I-D.ietf-ice-trickle].
A application/trickle-ice-sdpfrag body is used by the 'trickle-ice' Info Package. It uses a subset of the possible SDP lines as defined by the grammar defined in [RFC4566]. 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.
The grammar of an 'application/trickle-ice-sdpfrag' body is based on the following ABNF [RFC5234]. It specifies the subset of existing SDP attributes, that are needed or useful for trickling candidates. The grammar uses the indicator for case-sensitivity %s is defined in [RFC7405], but also imports grammars for other SDP attributes that precede the production of that RFC. A sender SHOULD stick to lower-case for such grammars, but a receiver SHOULD treat them case-insensitive.
; Syntax
trickle-ice-sdpfrag = session-level-fields
pseudo-media-descriptions
session-level-fields = [bundle-group-attribute CRLF]
[ice-lite-attribute CRLF]
ice-pwd-attribute CRLF
ice-ufrag-attribute CRLF
[ice-options-attribute CRLF]
[ice-pacing-attribute CRLF]
[end-of-candidates-attribute CRLF]
extension-attribute-fields
; for future extensions
ice-lite-attribute = %s"a" "=" ice-lite
ice-pwd-attribute = %s"a" "=" ice-pwd-att
ice-ufrag-attribute = %s"a" "=" ice-ufrag-att
ice-pacing-attribute = %s"a" "=" ice-pacing-att
ice-options-attribute = %s"a" "=" ice-options
bundle-group-attribute = %s"a" "=" %s"group:" bundle-semantics
*(SP identification-tag)
bundle-semantics = "BUNDLE"
end-of-candidates-attribute = %s"a" "=" end-of-candidates
end-of-candidates = %s"end-of-candidates"
extension-attribute-fields = attribute-fields
pseudo-media-descriptions = *( media-field
trickle-ice-attribute-fields
[extension-attribute-fields] )
; for future extensions
trickle-ice-attribute-fields = %s"a" "=" mid-attribute CRLF
[%s"a" "=" %s"rtcp" CRLF]
[%s"a" "=" %s"rtcp-mux" CRLF]
[%s"a" "=" %s"rtcp-mux-only" CRLF]
*(candidate-attributes CRLF)
[ice-pwd-attribute CRLF]
[ice-ufrag-attribute CRLF]
[remote-candidate-attribute CRLF]
[end-of-candidates-attribute CRLF]
remote-candidate-attribute = %s"a" "=" remote-candidate-att
candidate-attributes = %s"a" "=" candidate-attribute
with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att, ice-options, candidate-attribute remote-candidate-att from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The "a=rtcp" attribute is defined in [RFC3605], the "a=rtcp-mux" attribute in [RFC5761] and the "a=rtcp-mux-only" attribute in [I-D.ietf-mmusic-mux-exclusive]. The latter attributes lack a formal grammar in their corresponding RFC and are reproduced here.
An Agent MUST ignore any received unknown extension-attribute-fields.
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 messages can be exchanged both ways with no restrictions on timing and frequency and no risk of collision.
On the other hand, using Offer/Answer and UPDATE requests [RFC3311] introduces the following complications:
INFO messages decouple the exchange of candidates from the Offer/Answer negotiation and are subject to none of the glare issues described above, which makes them a very convenient and lightweight mechanism for asynchronous delivery of candidates.
Using in-dialog INFO messages also provides a way of guaranteeing that candidates are delivered end-to-end, between the same entities that are actually in the process of initiating a session. Out-of-dialog alternatives would have implied requiring support for Globally Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low adoption levels, would have constituted too strong of a constraint to the adoption of Trickle ICE.
This specification defines an Info Package for use by SIP User Agents implementing Trickle ICE. INFO requests carry ICE candidates discovered after the peer user agents have confirmed mutual support for Trickle ICE.
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.
This document defines a SIP Info Package as per [RFC6086]. The Info Package token name for this package is "trickle-ice"
This document does not define any Info Package parameters.
[RFC6086] allows Info Package specifications to define SIP option-tags. This specification extends the option-tag construct of the SIP grammar as follows:
option-tag /= "trickle-ice"
SIP entities that support this specification MUST place the 'trickle-ice' option-tag in a SIP Supported: 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: header field.
Entities implementing this specification MUST include a payload of type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all SIP INFO requests. The payload is used to convey SDP encoded ICE candidates.
This document does not define any Info Package Usage Restrictions.
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. Implementors that are concerned about loss of packets in such a case might consider aggregating ICE candidates and sending INFOs only at some configurable intervals.
See Section 12
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. ]
This section defines a new SDP media-level and session-level attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a property attribute [RFC4566] , and hence has no value.
Name: end-of-candidate
Value: N/A
Usage Level: media and session
Charset Dependent: no
Purpose: The sender indicates that it will not trickle
further candidates.
O/A Procedures: RFCXXX defines the detailed
SDP Offer/Answer procedures for
the 'end-of-candidate' attribute.
Mux Category: IDENTICAL
Reference: RFCXXXX
Example:
a=end-of-candidate
This document defines a new SIP Info Package named 'trickle-ice' and updates the Info Packages Registry with the following entry.
+-------------+-----------+
| Name | Reference |
+-------------+-----------+
| trickle-ice | [RFCXXXX] |
| | |
+-------------+-----------+
This specification registers a new SIP option tag 'trickle-ice' as per the guidelines in Section 27.1 of [RFC3261] and updates the "Option Tags" section of the SIP Parameter Registry with the following entry:
+-------------+-------------------------------------+-----------+
| Name | Description | Reference |
+-------------+-------------------------------------+-----------+
| trickle-ice | This option tag is used to indicate | [RFCXXXX] |
| | that a UA supports and understands | |
| | Trickle-ICE. | |
+-------------+-------------------------------------+-----------+
The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], [RFC6086] and [I-D.ietf-ice-trickle] apply. This document clarifies how the above specifications are used together for trickling candidates and does not create addtitional security risks.
The authors would 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.
[RFC EDITOR NOTE: Please remove this section when publishing].
Changes from draft-ietf-mmusic-trickle-ice-sip-01
Changes from draft-ietf-mmusic-trickle-ice-sip-02
Changes from draft-ietf-mmusic-trickle-ice-sip-03
Changes from draft-ietf-mmusic-trickle-ice-sip-04
Changes from draft-ietf-mmusic-trickle-ice-sip-05
Changes from draft-ietf-mmusic-trickle-ice-sip-06
Changes from draft-ietf-mmusic-trickle-ice-sip-07
Changes from draft-ietf-mmusic-trickle-ice-sip-08
Changes from draft-ietf-mmusic-trickle-ice-sip-09
Changes from draft-ietf-mmusic-trickle-ice-sip-10
| [RFC3311] | Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002. |
| [RFC3840] | Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004. |
| [RFC5627] | Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009. |
| [RFC6120] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011. |
| [RFC7081] | Ivov, E., Saint-Andre, P. and E. Marocco, "CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)", RFC 7081, DOI 10.17487/RFC7081, November 2013. |