OPUS and VP9 Bitrates


Current WebRTC implamentations use Opus and VP8 codecs:

.The Opus codec is audio codec developed by IETF (codec IETF working group) to be suitable for interactive audio over the internet. OPUS extended from other two audio codecs: SILK, and CELT. OPUS can adapt seamlessly to high and low bandwidth. OPUS has very low algorithmic delay (26.5 ms – 5 ms). It supports constant and variable bitrate from 6 kbit/s to 510 kbit/s.

The VP8 is video codec developed by Google. It is extended from VP7. The bitrate varies from 100 to 2000+ kbit/s depending on the size and the quality of the video. Then VP9 came to reduce the bitrate by 50% compared with VP8 with same video quality.

Note: If the hardware is able to capture high quality streams, the CPU and the bandwidth must be able to preserve this.

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).


  • 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