Technical Helpweb

Dialogic® PowerMedia™ Extended Media Server (PowerMedia XMS) - more articles

Using rfc5766-turn-server with Dialogic PowerMedia XMS and WebRTC


This article describes how to use the open source rfc5766-turn-server with Dialogic® PowerMedia™ XMS 2.1 or later.  As of October 2014. the rfc5766-turnserver website is located at  

For SIP and WebRTC access, running the rfc5766-turnserver on a PowerMedia XMS installation provides additional media flexibility:

  • A single port may be used for all media sessions, allowing easier firewall traversal.
  • UDP media transport can be translated into TCP to be more easily passed through firewalls.
  • XMS is currently restricted to a single Ethernet NIC for all RTP media traffic. This may cause issues when public access to the system is on a different NIC than LAN access.  It may be desirable, for example, to bridge a public WebRTC session with a local SIP agent. With TURN, multiple NICs and networks can successfully be used for media.
  • While using an external TURN server on a system’s media path can add considerable latency, integrating the service with the XMS system will not do so.

The diagram below shows the PowerMedia XMS system co-resident with the TURN server:


The connections show only media paths, not SIP or WebRTC (websocket) signaling. The WebRTC client is behind a NAT firewall; its media reaches the TURN interface on the XMS/TURN system though the TURN server’s transport address on the Public Internet. There, media is routed from the TURN server’s relayed transport address to the transport address of XMS on the private LAN interface. SIP calls on the same segment of the private LAN use the XMS transport address for media.

The remaining sections below cover the configuration of the various XMS and rfc5766-turn-server components.

Configuring the XMS System

Start with a “standard” XMS setup/configuration; a link to the trial version can be found here. This article assumes that XMS is on an IP address that is reachable from the public internet and has a legitimate host and domain name.

  • The system must have an unused Ethernet NIC. The new NIC can be most easily configured using the XMS WebGUI: Go to the Network Page, Interface Configuration tab. Click on the Interface Name to assign the NIC an appropriate internal static LAN address, then Enable the interface.
  • Restart XMS from the System/Services Restart screen.
  • From the Protocol/RTP screen, choose the new Ethernet device and Apply.
  • Restart XMS services.
  • Open the TCP port in the iptables firewall that will be used for STUN/TURN messages. The default port is 3478. Other TCP ports can be used, as long as they don’t conflict with default XMS port usage. Iptables configuration can be done most easily using the Firewall configuration option in the CentOS “setup” command line utility.
  • SIP calls – The SIP listen address and port for XMS can be specified in the Protocol/SIP XMS screen. Apply changes and restart XMS. Either Ethernet interface can be used, depending on the expected source.  SIP can also listen to, in which case both public and local LAN can accept/initiate SIP calls.

Configuring the rfc5766-turn-server

A “standard” installation of the rfc5766-turn-server is also assumed. For the rfc5766-turn-server, there are a number of configuration parameters in /etc/turnserver/turnserver.conf that must be modified or given on the command line when the server is started:

  • listening-device=ethX – where X is the device number of the public IP interface.
  • listening-port=X – where X is the port number that will be used for STUN/TURN messages. 3478 is the default port number for the protocols. Note that this TCP or UDP port must be opened in the iptables firewall. While it would often be desirable to use a common port such as 80 or 443 to alleviate firewall problems on the client side, these ports are already in use as part of various XMS web services, and would need to be reconfigured. An alternate approach would be to set up the rfc5766-turnserver on a separate system.
  • listening-ip=X – where X is the IP address of the public IP interface.
  • min-port=62000 - Lower bound of UDP relay endpoints. This is outside the ranges used by XMS. (49152-53152 and 57344-61344)
  • max-port=64000 - Upper bound of UDP relay endpoints. This is outside the ranges used by XMS. (49152-53152 and 57344-61344)
  • user=username:password – static user account name/password for TURN authentication via WebRTC.  If a more dynamic (changeable without turnserver restart) user database is needed, a database file or SQL database connection can be used. In addition, a secure key can be generated and used in place of the clear text password.
  • – the domain name used on the system must be specified to avoid authentication errors.
  • no-udp, no-tls, no-dtls – determines whether a listener is opened on the protocol. Disallowing a protocol may help avoid port conflicts with XMS. TCP is the allowed media transport protocol in this example.
  • ne=2 - If the rfc5766-turn-server CentOS 6.5 binaries are used, ne=2 must be set. If the server is built on the XMS system, this should not be necessary.

WebRTC ICE Server Configuration

Establishing a WebRTC peer-peer connection using TURN requires a modification in the iceServer configuration used with WebRTC API call RTCPeerConnection(). 

The WebRTC demos delivered with an XMS system use Dialogic’s Javascript API to initiate a WebRTC call. In the file /var/www/html/rtcweb/html/js/webrtc.js, the TURN server configuration is done in the function Dialogic.prototype.createPeerConnection(). Here is an example:

var pc_config = {"iceServers": [{“url”: "", “credential”: "mypw",”username”: "myusername"}]};

This is interpreted as follows:

  • is the public IP address of the XMS and TURN server.
  • The TURN server is listening on port 3478.
  • TCP will be used for media transport.
  • myusername is set as the username in the turnserver config file.
  • mypw is set as the password for myusername in the turnserver config file.

Product List:

Dialogic® PowerMedia™ XMS 2.1 or later

Legal Note

This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to use open source in connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic responsible for any present or future effects such usage might have, including without limitation effects on your products, your business, or your intellectual property rights.


Please rate the usefulness of this page:  
0 - not useful at all
1 - potentially useful
2 - quite useful
3 - very useful
4 - exactly the information I needed     

Please enter a comment about this page:

First published: 03-Oct-2014
Open access: Product rule: open; Page rule: Auto