WebSocket Protocol as a Transport for Traversal Using Relays around NAT (TURN)

Traversal Using Relays around NAT (TURN) , which assigns a transport address allocation for clients and relays data between the address and the clients, is an extension to the Session Traversal Utilities for NAT protocol. TURN is used for NAT traversal in some complicated types of NAT network by UDP-based media sessions or TCP-based media sessions . It is also used in conjunction with the Interactive Connectivity Establishment (ICE) technique. In some particularly restrictive networks though, e.g., a web proxy or firewall that only allows HTTP traffic to pass through, TURN UDP-based media sessions and TCP-based media sessions do not work. These types of networks are often deployed in corporations, prisons, hotels, airports and other locations that may need to limit the access, and as such legitimate users trying to set up a real-time multimedia session in such a scenario would find themselves unable to do so. This is a known issue and in fact the RTCWEB specification, which provides the means to realize direct interactive rich communications between two peers by using just their web browsers, has an explicit requirement to allow such peers to use some kind of fallback communication in HTTP-only networks, as specified in (F37). That said, this document is aimed at targeting such scenarios, and as such defines an extension to the standard TURN protocol that allows it to run over a WebSocket channel. The WebSocket protocol enables message exchange between clients and servers on top of a persistent TCP connection. Considering that the initial protocol handshake makes use of HTTP semantics, thus allowing the WebSocket protocol to reuse existing HTTP infrastructure, this means that a client in a restrictive network would be able to exchange media over a WebSocket. Besides solving the HTTP fallback problem, this solution could also be easyly implemented and deployed within the existing RTCWEB framework. For what concerns the impact of such an extensions on the interaction with legacy peers making use of the services provided by a TURN server, the connection between the server and such peers would still be based on UDP as or TCP as in a seamless and transparent fashion.

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 .

Within the context of real-time multimedia communications and considering a scenario that involves two peers, an HTTP fallback mechanism may fall in basically three different network topologies:

In , only one involved peer (Alice) is in a restrained network, which means Alice needs to make use of a WebSocket connection to traverse the firewall and/or proxy. The situation for Bob is better, he could connect to the TURN server by UDP or TCP using the existing mechanisms. When Alice wants to communicate with Bob, she needs to request a UDP or TCP allocation in the WebSocket server for Bob, which is then transferred to the WebSocket channel. The WebSocket server will receive the request and handle it like a TURN server. The processing of TURN messages is exactly the same as TURN UDP and TURN TCP, and the WebSocket server will also allocate a UDP or TCP relay address for Bob. The application data between Alice and Bob will be packaged and relayed to each other by the WebSocket server.

In , both Alice and Bob are in restrictive networks, so both need a fallback mechanism. In this slightly more complex scenario, both Alice and Bob each have been configred to refer to different WebSocket servers. In this scenario, Alice and Bob need to request the TURN allocation in their own WebSocket server using a WebSocket connection. Again, just as before the processing of TURN messages is exactly the same as TURN UDP and TURN TCP. The only difference with previous sceneario is that, in this case, the involved WebSocket server have to relay the application data to each other by either UDP, TCP or other existing ways, using the existing TURN mechanics for the purpose. It is of course suggested that Alice and Bob allocate the same type of transport address, so that their reference WebSocket server could connect to each other by this address directly. The scenario would of course be simpler in case the TURN servers depicted in the figure above happen to be the same TURN server, i.e., if Alice and Bob both referred to the same server. In that case, it may be possible to relay the data internally instead of using an UDP/TCP connection.

However, this is an implementation decision, not affecting the TURN clients interaction with the TURN server and it will not be covered in detail within this specification.

The term WebSocket sub-protocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket TURN sub-protocol for carrying TURN requests and responses through a WebSocket connection.

The TURN Client and TURN Server negotiate usage of the WebSocket TURN sub-protocol during the WebSocket handshake procedure as defined in section 1.3 of . The Client MUST include the value "turn" in the Sec-WebSocket-Protocol header in its handshake request. The 101 reply from the Server MUST contain "turn" in its corresponding Sec-WebSocket-Protocol header. Also, the TURN WebSocket Client shall set the Origin header if the TURN connection is createad in a Web context as defined in . Particularly, for WebRTC, the Origin header shall be set to the value of the URI of the HTML page creating the PeerConnection. Below is an example of a WebSocket handshake in which the Client requests the WebSocket TURN sub-protocol support from the Server:

The handshake response from the Server accepting the WebSocket TURN sub-protocol would look as follows:

Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of TURN requests and responses. The WebSocket messages transmitted over this connection MUST conform to the negotiated WebSocket sub-protocol.

TURN messages shall be transported in unfragmented binary frames (FIN:1,opcode:%x2). The WebSocket frame data shall be a valid TURN packet, so the length of the payload of the WebSocket frame shall be lower than the maximum size allowed (2^16 bytes) for a TURN request or response as defined in . TURN client using TURN over WebSockets should follow the recommendations in section 2.7 of "Avoiding IP Fragmentation" when sending application data on the client-to-server-leg as messages could be relied over a UDP connection to the peer client.

This document extends both (TURN UDP relay) and (TURN TCP relay) with a new type of client-to-server connection, i.e. WebSocket. For TURN allocations, WebSocket is a type of TCP client-to-server connection and is subject to all TURN TCP considerations. This specification strictly follows the allocation definition in section 5 in . In the 5-tuple, the transport address is always TCP, of course, when WebSockets are used. All definitions in the section 5 of are applicable to the WebSockets TURN connections.

The operation of the client, server and peer is the same as TURN UDP and TURN TCP, with the difference consisting in the new connection channel - WebSocket.

This document defines the value "ws" as a transport parameter value for a TURN and TURNS URI to be contacted using the TURN WebSocket sub-protocol as transport. The "turns" URI scheme MUST be used when TURN is run over Secure Websockets (WebSockets over TLS) and the "turn" scheme MUST be used otherwise. The updated augmented BNF (Backus-Naur Form) for this parameter is the following (the original BNF for this parameter can be found in ):

This specification does not have any impact on ICE. In fact, all the related candidates would be allocated at the TURN sever, and as such no modifications are needed in the SDP signaling in order to support the TURN over WebSockets operation.

RFC Editor Note: Please set the RFC number assigned for this document in the sub-sections below and remove this note.

This specification requests IANA to register the WebSocket TURN sub-protocol under the "WebSocket Subprotocol Name" Registry with the following data: turn WebSocket Transport for TURN TBD: this document

TBD.

Note to RFC Editor: Please remove this whole section. The following are the major changes between the 00 and the 01 versions of the draft: Removal of multiplexing and references to BCFP and other non related protocols Websocket TURN sub protocol specification TURN message framing inside Websocket Extension to turn and turns URI Impact analisys on ice candidates SDP negotiation

Paul Kyzivat helped with the formatting of this draft.