TURN In Few Words

.

TURN is abbreviation for Traversal Using Relays around NAT. It is a control protocol that allows the host behind a NAT to exchange packets with its peers using the relay.  It is specified in the RFC [5766]. The following are few words about this protocol:

  • TURN is part of the ICE (Interactive Connectivity Establishment) but it can be used without ICE.
  • TURN is designed to solve the communication problem when both the client and its peer are behind respective NAT where the hole punching techniques (discovering direct communication path) may fail. In other words TURN is used when a direct communication path between the client and the pair can NOT be found.
  • The public TURN server sits between the two hosts that are behind NAT and relays the packets between them.
  • TURN is client-server protocol. The client is called TURN client and the server is called TURN server.
  • The TURN client obtains (using the TURN protocol -Allocate transaction) on the TURN server what is called relayed transport address (IP address and port).
  • The client sends CreatePermissions request to the TURN server to create permissions (permissions to validate the peer-server communication).
  • The TURN server sees the messages coming from the client as it is coming from a transport address on NAT. This address is called client’s server-reflexive transport address.
  • The NAT forwards packets coming to the client’s server-reflexive transport to the client’s host transport address (private address).
  • The TURN server receives the application data from the client, make the relayed transport address as the source of the packets and relays them to the peer using UDP datagrams.
  • The peer sends the application data in UDP packets to the client’s relayed transport address on the relay server. Then the server checks the permissions and on validation it relays the data to the client.
  • A way to communicate the relayed transport address and peers addresses (server-reflexive transport addresses) is needed (out of scope of the TURN protocol).

TURN

  • In VOIP, if TURN is used with ICE, then the client puts its obtained relayed transport address as an ICE candidate (among other candidates) in the SDP carried by the rendezvous protocol like SIP. When the other peers receives the SIP request, they will know how to reach the client.
  • The TURN messages (encapsulation of the application data) contains an indication of the peer the client is communicating with so the client can use a single relayed transport address to communicate with multiple peers. This is when the the rendezvous protocol (e.g. SIP) supports forking.
  • Using TURN is expensive so when TURN is used with ICE, the ICE uses hole punching techniques first to discover the direct path. If the direct path is not found, then TURN is used.
  • Using TURN makes the communication no longer peer to peer communication.

More Information


 

Advertisements

WebSocket as a Transport for SIP

.

Here I just want to write a few words that summarize the RFC 7118:

globe

  • The WebSocket protocol enables message exchange between clients and servers on top of a persistent TCP connection

  • The connection is optionally secured with TLS

  • The WebSocket handshake is based on HTTP and uses the HTTP GET method with an Upgrade request → HTTP 101 response on success .

  • During the connection handshake, the client and server agree on the application-level protocol on top of Websocket transport (Websocket subprotocol) -In this document it is SIP

  • Websocket messages can be sent in either UTF-8 text frames or binary frames. SIP allows both. UTF-8 is recommended for Javascript and WebSocket API

  • Each SIP message must be carried in a single WebSocket message and the WebSocket message contains only one SIP message → simplifies the SIP message parsing – no need for message boundaries (Content-Length header)

  • “ws” is used for plain websocket connections and “wss” for secure Websocket connections. These are for “via” transport parameter and SIP URI transport parameter

  • The SIP WebSocket server may decide not to add the parameter “received” in the top via header. The Client must accept the responses without this parameter

  • The SIP webSocket client is not manadated to implement support of UDP and TCP.

  • “SIP+D2W” DNS NAPTR service value for plain Websocket connections and “SIPS+D2W” for secure websocket connections.

  • The authentication can be on SIP level or Web level (token/cookie is used) – Appendix A

  • Using GRUU is valuable here (must be implemented on the client and server)

  • The Contact URI provided by SIP UAs is not used for routing requests to those UAs.

  • When SIP WebSocket server behaves as edge outbound proxy (Outbound + Path support), the proxy performs loose routing and remains in the path.


More Information