IceTransport Extensions for WebRTC

W3C Editor's Draft

This version:
https://w3c.github.io/webrtc-ice/
Latest published version:
https://www.w3.org/TR/webrtc-ice/
Latest editor's draft:
https://w3c.github.io/webrtc-ice/
Editors:
Peter Thatcher (Google)
Bernard Aboba (Microsoft Corporation)
Author:
Participate:
Mailing list
Browse open issues
IETF ICE Working Group

Abstract

This document defines a set of ECMAScript APIs in WebIDL to allow construction of an RTCIceTransport object in situations where this would not otherwise be available, such as in a data exchange-only application. This specification is being developed in conjunction with protocol specifications developed by the IETF ICE Working Group.

Status of This Document

This is a preview

Do not attempt to implement this version of the specification. Do not reference this version as authoritative in any way. Instead, see https://w3c.github.io/webrtc-ice/ for the Editor's draft.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

The API is based on preliminary work done in the W3C ORTC Community Group.

This document was published by the Web Real-Time Communications Working Group as an Editor's Draft.

Comments regarding this document are welcome. Please send them to public-webrtc@w3.org (archives).

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

1. Introduction

This section is non-normative.

This specification extends the WebRTC specification [WEBRTC] to allow construction of an RTCIceTransport object in situations where this would not otherwise be available, such as in a data exchange-only application that does not construct an RTCPeerConnection object (e.g. RTCDataChannel in workers, WebRTC-QUIC, etc.).

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, and MUST NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

Implementations that use ECMAScript to implement the APIs defined in this specification MUST implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL-1], as this specification uses that specification and terminology.

3. Terminology

The EventHandler interface, representing a callback used for event handlers, and the ErrorEvent interface are defined in [HTML51].

The concepts queue a task, fires a simple event and networking task source are defined in [HTML51].

The terms event, event handlers and event handler event types are defined in [HTML51].

When referring to exceptions, the terms throw and create are defined in [WEBIDL-1].

The terms fulfilled, rejected, resolved, pending and settled used in the context of Promises are defined in [ECMASCRIPT-6.0].

The RTCDtlsTransport is defined in [WEBRTC] Section 5.5. The RTCIceTransport interface, the getLocalParameters method, the icecandidate, icecandidateerror, RTCPeerConnectionIceEvent and RTCPeerConnectionIceErrorEvent events, the RTCIceCandidate interface, RTCIceCandidateInit, RTCIceCandidatePair and RTCIceServer dictionaries, the RTCIceTransportPolicy, RTCIceTransportState and RTCIceRole enums and the [[IceRole]], [[IceTransportState]], [[IceGathererState]] and [[SelectedCandidatePair]] internal slots are defined in [WEBRTC] Section 5.6.

4. RTCIceTransport Extensions

The RTCIceTransport extensions allow construction of an RTCIceTransport without offer/answer. This specification differs from the approach taken in [ORTC] in that it does not define a distinct RTCIceGatherer object, instead adding methods for control of ICE candidate gathering to RTCIceTransport. As a result, an application can test for support of this specification by checking for the RTCIceTransport.start() method, and the absence of an RTCIceGatherer object.

4.1 RTCIceParameters Dictionary

The RTCIceParameters dictionary includes the ICE username fragment and password and other ICE-related parameters.

WebIDLdictionary RTCIceParameters {
             required DOMString usernameFragment;
             required DOMString password;
             boolean   iceLite;
};

Dictionary RTCIceParameters Members

usernameFragment of type DOMString, required

ICE username fragment.

password of type DOMString, required

ICE password.

iceLite of type boolean

If only ICE-lite is supported (true) or not (false or unset). Since [RTCWEB-TRANSPORT] Section 3.4 requires browser support for full ICE, iceLite will only be true for a remote peer such as a gateway. getLocalParameters().iceLite MUST NOT be set.

4.2 RTCIceGatherOptions Dictionary

RTCIceGatherOptions provides options relating to the gathering of ICE candidates.

WebIDLdictionary RTCIceGatherOptions {
             RTCIceTransportPolicy     gatherPolicy = "all";
             sequence<RTCIceServer> iceServers;
             sequence<DOMString>? networkIds;
};

Dictionary RTCIceGatherOptions Members

gatherPolicy of type RTCIceTransportPolicy

The ICE gather policy.

iceServers of type sequence<RTCIceServer>

Additional ICE servers to be configured. Since implementations MAY provide default ICE servers, and applications can desire to restrict communications to the local LAN, iceServers need not be set.

networkIds of type sequence<DOMString>

If set and non-null, ICE gathering will be limited to the network interfaces specfied by the network IDs (obtained by calling getLocalCandidates().

4.3 Interface Definition

WebIDL[Exposed=Window]
partial interface RTCIceTransport {
    constructor();
    void                      gather (optional RTCIceGatherOptions options = {});
    void                      start (RTCIceParameters remoteParameters, optional RTCIceRole role = "controlled");
    void                      stop ();
    void                      addRemoteCandidate (RTCIceCandidateInit remoteCandidate);
    void                      retainLocalCandidate (RTCIceCandidateInit localCandidate);
    void                      removeLocalCandidate (RTCIceCandidateInit localCandidate);
    sequence<RTCIceCandidatePair> getCandidatePairs();
                    attribute EventHandler        onerror;
                    attribute EventHandler        onlocalcandidate;
                    attribute EventHandler        onchecksent;
};

Constructors

RTCIceTransport

When the constructor is invoked, the user agent MUST run the following steps:

  1. Create an RTCIceTransport transport.
  2. Initialize transport's [[IceTransportState]], [[IceGathererState]], [[SelectedCandidatePair]] and [[IceRole]] internal slots as specified in [WEBRTC] Section 5.6.
  3. Initialize transport's local ICE parameters.
  4. Return transport.
No parameters.

Attributes

onerror of type EventHandler

This event handler, of event handler event type icecandidateerror, MUST be fired if an error occurs in the gathering of ICE candidates (such as if TURN credentials are invalid).

onlocalcandidate of type EventHandler

This event handler utilizes the event handler event type icecandidate.

onchecksent of type EventHandler

This event handler utilizes the event handler event type icecheck.

Methods

gather

Gather ICE candidates. If state is closed, throw an InvalidStateError.

To validate the options argument, implementations MUST run the following steps:

  1. Let options be the first argument.

  2. Let servers be the value of options.iceServers.

  3. Let validatedServers be an empty list.

  4. Run the following steps for each element in servers:

    1. Let server be the current list element.

    2. If server.urls is a string, let server.urls be a list consisting of just that string.

    3. For each url in server.urls run the following steps:

      1. Parse the url using the generic URI syntax defined in [RFC3986] and obtain the scheme name. If the parsing based on the syntax defined in [RFC3986] fails, throw a SyntaxError. If the scheme name is not implemented by the browser throw a NotSupportedError. If scheme name is turn or turns, and parsing the url using the syntax defined in [RFC7064] fails, throw a SyntaxError. If scheme name is stun or stuns, and parsing the url using the syntax defined in [RFC7065] fails, throw a SyntaxError.

      2. If scheme name is turn or turns, and either of server.username or server.credential are omitted, then throw an InvalidAccessError.

      3. If scheme name is turn or turns, and server.credentialType is "password", and server.credential is not a DOMString, then throw an InvalidAccessError and abort these steps.

    4. Append server to validatedServers.

  5. Let validatedServers be the ICE servers list.

Parameter Type Nullable Optional Description
options RTCIceGatherOptions
Return type: void
start

As noted in [RFC5245] Section 7.1.2.3, an incoming connectivity check utilizes the local/remote username fragment and the local password, whereas an outgoing connectivity check utilizes the local/remote username fragment and the remote password. Since start() provides role information, as well as the remote username fragment and password, once start() is called an RTCIceTransport object can respond to incoming connectivity checks based on its configured role. Since start() enables candidate pairs to be formed, it also enables initiating connectivity checks. When start() is called, the following steps MUST be run:

  1. If state is closed, throw an InvalidStateError.
  2. If remoteParameters.usernameFragment or remoteParameters.password is unset, throw an TypeError.
  3. If remoteParameters.usernameFragment or remoteParameters.password does not conform to the syntax described in [ICE-SDP] Section 5.4, throw a SyntaxError.
  4. If start() is called again and role is changed, throw an InvalidStateError.
  5. If start() is called again with the same value of remoteParameters, this has no effect.
  6. If start() is called for the first time, if there are remote candidates, set state to checking and start connectivity checks. If there are no remote candidates, state remains new.
  7. If start() is called again but the value of remoteParameters has changed, local candidates are kept, remote candidates are flushed, candidate pairs are flushed and state transitions to new.
  8. If start() is called again but the value of remoteParameters is unchanged, local candidates are flushed, candidate pairs are flushed, new candidate pairs are formed with existing remote candidates, and state transitions to checking.
  9. If start() is called again with new values of remoteParameters, local candidates are flushed, remote candidates are flushed, candidate pairs are flushed and state transitions to new.
Parameter Type Nullable Optional Description
remoteParameters RTCIceParameters
role RTCIceRole = controlled
Return type: void
stop

Irreversibly stops the RTCIceTransport. When stop is called, the following steps MUST be run:

  1. Let iceTransport be the RTCIceTransport object on which the stop method is invoked.
  2. If iceTransport.state is closed, abort these steps.
  3. Set iceTransport.state to closed.
  4. Fire a simple event statechange at iceTransport.
No parameters.
Return type: void
addRemoteCandidate

Add a remote candidate associated with the remote RTCIceTransport. If state is closed, throw an InvalidStateError. If remoteCandidate is malformed, throw an OperationError. When the remote RTCIceTransport emits its end-of-candidates indication (as described in [WEBRTC] Section 4.8.2), addRemoteCandidate() should be called with the end-of-candidates indication as an argument, so that the local RTCIceTransport can know there are no more remote candidates expected, and can enter the completed state.

Parameter Type Nullable Optional Description
remoteCandidate RTCIceCandidateInit
Return type: void
removeLocalCandidate

Removes the given local candidate. This will trigger the removal of all candidate pairs with the given local candidate, the prevention of pairing with the given local candidate, and prevention of any network activity using the given local candidate.

Parameter Type Nullable Optional Description
localCandidate RTCIceCandidate
Return type: void
retainLocalCandidate

Cause the RTCIceTransport to not automatically remove the local candidate due to ICE pruning (such as when a candidate pair with a different local candidate is selected). However, the local candidate may be removed if it completely fails (such as a network interface going down).

Parameter Type Nullable Optional Description
localCandidate RTCIceCandidate
Return type: void
getCandidatePairs()

Return all the candidate pairs.

Return type: sequence<RTCIceCandidatePair>

Interface Definition

[Exposed=Window]
partial dictionary RTCIceCandidateInit {
    attribute DOMString? networkId;
    // TODO: Add reference to https://wicg.github.io/netinfo/#dom-networkinformation
    attribute NetworkInformation? networkInfo;
};
Attributes
networkId of type DOMString
An ID of the network interface for use in gathering options. It needs to be unique enough to fulfill that purpose, but otherwise the value is not significant.
networkInfo of type NetworkInformation
Information about the network interface.

Interface Definition

[Exposed=Window]
partial interface RTCIceCandidatePairInt {
    void setMinCheckInterval(double seconds);
    void setFrozen(boolean frozen);
    void select();
    Promise nominate();
    Promise waitForReceiveTimeout(double seconds);	    
};
Methods
setMinCheckInterval

Causes the RTCIceTransport to send ICE checks using this candidate pair no more frequently than indicated by the given interval (given in seconds). The RTCIceTransport may always send less frequently than specified.

Parameter Type Nullable Optional Description
seconds double
Return type: void
setFrozen

Freezes or unfreezes the candidate pair. When frozen, no ICE checks will be sent over it.

Parameter Type Nullable Optional Description
frozen boolean
Return type: void
select

Selects the candidate pair. Once this is called once, the RTCIceTransport will no longer automatically select candidate pairs and the only way to change the selected candidate pair will be calling select() again will change the selected candidate pair again.

Return type: void
nominate

Nominates the candidate pair by sending a nomination to the remote side. Resolves the returned promise once the nomination has been sent or once it has been determined that it is impossible to nominate (for example, if aggressive nomination and renomination are both unavailable due to the ICE options and a nomination has already been sent.

Return type: Promise<boolean>
waitForReceiveTimeout

Wait until no network pacekts have been received for more than the given timeout. This allows the detection of network outage. If called a second time on the same RTCIceTransport, the previous call's promise is rejected immediately. Thus only one pending wait per RTCIceTransport is allowed at a time.

Parameter Type Nullable Optional Description
seconds double
Return type: void

Interface Definition

[Exposed=Window]
interface RTCIceCheck {
    readonly        attribute Promise response;
};
Attributes
response of type boolean

A promise that resolves when the RTCIceTransport receives a response to the check. Resolves with a true value if the response is successful and false if the response was an error.

4.4 Privacy and Security Considerations

This section is non-normative; it specifies no new behaviour, but instead summarizes information already present in other parts of the specification. The overall security considerations of the APIs and protocols used in WebRTC are described in [RTCWEB-SECURITY-ARCH].

4.4.1 Impact on same origin policy

This API, along with the QUIC API enables data to be communicated between browsers and other devices, including other browsers.

This means that data can be shared between applications running in different browsers, or between an application running in the same browser and something that is not a browser. This is an extension to the Web model which has had barriers against sending data between entities with different origins.

This specification provides no user prompts or chrome indicators for communication; it assumes that once the Web page has been allowed to access data, it is free to share that data with other entities as it chooses. Peer-to-peer exchanges of data can therefore occur without any user explicit consent or involvement.

4.4.2 Impact on local network

Since the browser is an active platform executing in a trusted network environment (inside the firewall), it is important to limit the damage that the browser can do to other elements on the local network, and it is important to protect data from interception, manipulation and modification by untrusted participants.

Mitigations include:

  • An UA will always request permission from the correspondent UA to communicate using ICE. This ensures that the UA can only send to partners who you have shared credentials with.
  • An UA will always request ongoing permission to continue sending using ICE consent [RFC7675]. This enables a receiver to withdraw consent to receive.
  • An UA will always encrypt data, with strong per-session keying.
  • An UA will always use congestion control. This ensures that QUIC cannot be used to flood the network.

These measures are specified in the relevant IETF documents.

4.4.3 Confidentiality of Communications

The fact that communication is taking place cannot be hidden from adversaries that can observe the network, so this has to be regarded as public information.

Since the SRTP, DTLS and QUIC protocols utilize a cryptographic negotiation in order to encrypt communications, confidentiality is provided.

4.5 Event summary

This section is non-normative.

The following events fire on RTCIceTransport objects:

Event name Interface Fired when...
icecandidateerror RTCPeerConnectionIceErrorEvent The RTCIceTransport object has experienced an ICE gathering failure (such as an authentication failure with TURN credentials).
icecandidate RTCPeerConnectionIceEvent A new RTCIceCandidate is made available to the script.
icecheck RTCIceCheckEvent A new RTCIceCheck is made available to the script.

4.6 Examples

This section is non-normative.

4.7 Change Log

This section will be removed before publication.

4.8 Acknowledgements

The editors wish to thank the Working Group chairs and Team Contact, Harald Alvestrand, Jan-Ivar Bruaroey, Stefan Håkansson and Dominique Hazaël-Massieux, for their support. Contributions to this specification were provided by Robin Raymond.

The RTCIceTransport object was initially described in the W3C ORTC CG, and has been adapted for use in this specification.

A. References

A.1 Normative references

[ECMASCRIPT-6.0]
ECMA-262 6th Edition, The ECMAScript 2015 Language Specification. Allen Wirfs-Brock. Ecma International. June 2015. Standard. URL: http://www.ecma-international.org/ecma-262/6.0/index.html
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML51]
HTML 5.1 2nd Edition. Steve Faulkner; Arron Eicholz; Travis Leithead; Alex Danilo. W3C. 28 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/html51/
[ICE-SDP]
Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE). M. Petit-Huguenin; S. Nandakumar; C. Holmberg; A. Keranen; R. Shpount. IETF. 13 August 2019. Internet Draft (work in progress). URL: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp
[ORTC]
Object RTC (ORTC) API for WebRTC. Robin Raymond; Bernard Aboba; Justin Uberti. W3C. 03 October 2018 (work in progress). URL: http://draft.ortc.org/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC5245]
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. J. Rosenberg. IETF. April 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5245
[RFC7064]
URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol. S. Nandakumar; G. Salgueiro; P. Jones; M. Petit-Huguenin. IETF. November 2013. RFC. URL: https://tools.ietf.org/html/rfc7064
[RFC7065]
Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers. M. Petit-Huguenin; S. Nandakumar; G. Salgueiro; P. Jones. IETF. November 2013. RFC. URL: https://tools.ietf.org/html/rfc7065
[RFC7675]
Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness. M. Perumal; D. Wing; R. Ravindranath; T. Reddy; M. Thomson. IETF. October 2015. RFC. URL: https://tools.ietf.org/html/rfc7675
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[RTCWEB-SECURITY-ARCH]
WebRTC Security Architecture. E. Rescorla. IETF. 21 July 2019. Internet Draft (work in progress). URL: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch
[RTCWEB-TRANSPORT]
Transports for RTCWEB. H. Alvestrand. IETF. 31 October 2016. Active Internet-Draft. URL: https://tools.ietf.org/html/draft-ietf-rtcweb-transports
[WebIDL]
Web IDL. Boris Zbarsky. W3C. 15 December 2016. W3C Editor's Draft. URL: https://heycam.github.io/webidl/
[WEBIDL-1]
WebIDL Level 1. Cameron McCormack. W3C. 15 December 2016. W3C Recommendation. URL: https://www.w3.org/TR/2016/REC-WebIDL-1-20161215/
[WEBRTC]
WebRTC 1.0: Real-Time Communication Between Browsers. Cullen Jennings; Henrik Boström; Jan-Ivar Bruaroey. W3C. 26 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/webrtc/