Traversal Using Relays around NAT (TURN) Extensions for Websocket Allocations

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 with Interactive Connectivity Establishment (ICE) . In some particularly restrictive networks, e.g. a web proxy or firewall that only allows HTTP traffic to pass through, TURN UDP-based media sessions and TURN TCP-based media sessions do not work. These types of network often appear in the prison, the hotel, the airport and other places that need limit the access of network. RTCWeb provides direct interactive rich communication between two peers' web-browser, which has the similar requirement to allow two peers to use fallback communication in the http-only network (F37). Another use case of Turn over websocket is that the turn server could be a generic relay for some protocols over websocket, such as BFCP and MSRP. There are drafts to support BFCP and MSRP transported in the websocket, however in these drafts a special server is needed as the intermediary to receive the protocol data from the client. In the Peer to Peer scene, BFCP and MSRP message is required be exchange by two peers, and additional server is a little complicated to deploy in such scene. The turn over websocket could be used as generic relay server, which could relay these protocol data between two peers. This document defines an extension to TURN that allows it to run over a Websocket channel. This will allow a client in a restrictive network to exchange media over a websocket. This is useful to solve the http fallback problem and is easy to be implemented in the existing rtcweb framework. The connection between the server and the peer is still UDP as or TCP , TLS over TCP as .

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 .

As mentioned 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 the restrained network, so Alice need use websocket connection to traverse the firewall and proxy. The situation for Bob is better, he could connect to TURN server by UDP or TCP using existing mechanism. When Alice wants to communicate with Bob, she need request a UDP or TCP allocation in websocket server for Bob, which is transferred in the websocket channel. The websocket server will receive the request and handle it like a TURN server. The procedure of TURN message is 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 from Alice and Bob will be packaged and relayed to each other by the websocket server.

In , both Alice and Bob are i restrictive networks, so both need a fallback mechanism. One complex scenario is that Alice and Bob each have their own websocket server. In this scenario, Alice and Bob need to request the Turn allocation in their own websocket server using a websocket connection. The procedure of TURN message is the same as TURN UDP and TURN TCP. The websocket server should relay the application data to each other by UDP ,TCP or other existing ways. It is better that Alice and Bob allocate the same type of transport address, so their own websocket server could connect to each other by this address directly.

In , Alice and Bob are both also in the restrictive network as with a slight difference that Alice and Bob share the same websocket server. In this scenario, Alice and Bob need exchange TURN messages as TURN UDP and TCP using websocket connection. The websocket will assign the allocation for both sides and decide how to bind the two allocations together and bridge the TURN application data, which is entirely implementation specific.

Because the UDP and TCP allocation for the peer can satisfy the different scenarios, we just need to extend the connection between the client and the server - websocket connection. Considering websocket connection is based on TCP transport connection, we should add a flag in server's allocation to distinguish these two connections: 'app-connection'. In the application of TURN UDP and TURN TCP, the 5-tuple (client's IP address, client's port, server IP address, server port, transport protocol) is used for stating the connection between the client and the server. However the 5-tuple is hard to state the websocket connection which is an application-level connection. The app-connection is used for stating the application level connection, whose value is 'ws' or'wss' when the client uses websocket or secure websocket to connect TURN server.

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

In restrictive networks, the port resource is limited, so multiplexing the TURN connections on a single port is necessary. A method for websocket multiplexing is proposed in , which describes a multiplexing extension for the WebSocket Protocol. With this extension, one TCP connection can provide multiple virtual WebSocket connections by encapsulating frames tagged with a channel ID. This method could be used in conveying TURN data. One control websocket channel is needed to convey the TURN control message. When allocation request is successful, a new websocket connection should be established for transferring TURN application data. The channel ID for the new websocket connection should be saved in the allocation in server, so that all data in this channel will be bound to this specific allocation.

TBS

Paul Kyzivat helped with the formatting of this draft.