WebSocket Protocol as a Transport for Traversal Using Relays around NAT (TURN)
Huaweihangzhou.chenxin@huawei.comMedoozesergio.garcia.murillo@gmail.comYahooolegm@yahoo-inc.comQuobisvictor.pascual@quobis.comMeetecholorenzo@meetecho.com
Transport Area
Behavior Engineering for Hindrance Avoidance
This document defines an extension to the Traversal Using Relays around NAT (TURN)
protocol, in order to allow it to run over a WebSocket channel.
This will allow clients in restrictive networks to traverse them and
effectively exchange and relay media or data over WebSockets.
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:
turnWebSocket Transport for TURNTBD: 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 protocolsWebsocket TURN sub protocol specificationTURN message framing inside WebsocketExtension to turn and turns URIImpact analisys on ice candidates SDP negotiation
Paul Kyzivat helped with the formatting of this draft.