Traversal Using Relays around NAT (TURN) Extensions for Websocket Allocations
Huaweihangzhou.chenxin@huawei.com
Transport Area
Behavior Engineering for Hindrance Avoidance
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 and relay media or data over the websocket.
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
TBS
Paul Kyzivat helped with the formatting of this draft.