TURN Server and WebRTC

TURN Service

TURN stands for Traversal Using Relays around NAT. Basically it is a device that sits on the public Internet that sends and receives media. To function correctly, it must be reachable by both the external devices on the Internet and internal devices, such as CMS, so that audio and video traffic can flow into and out of an organization. The TURN server in this case acts as an anchor point for the media that is trusted by the firewall.

The CMS server can be deployed as an edge device and function as a TURN server, but since the Expressway-E has TURN server capabilities as well, that is what you will use for this lab. Regardless of which device is used as a TURN server to anchor media, the TURN server must be configured in the CMS database so that the Call Bridges know where to send media and, since the TURN server is on the public internet, the web client can know where to send its traffic. An Expressway-E, acting as a TURN server, will bridge the traffic received on its internal and external interfaces together so that users can establish two-way communication.

For any device to use a TURN server, authentication is required. You should configure another set of authentication credentials on the Expressway-E to use for TURN. Follow these steps to configure the credentials:

  1. Open the browser to the Expressway-E at https://expe1a.pod2.cms.lab:445
  2. Log in with username admin and password c1sco123
  3. Navigate to Configuration > Authentication > Devices > Local database
  4. Click New
  5. Enter turnuser in the Name field
  6. In the Password field enter c1sco123 - If pasting this value, use Control-V
  7. Click Create credential

Now you can configure the Expressway-E TURN server.

  1. Navigate to Configuration > Traversal > TURN
  2. For TURN services, select On
  3. For TCP 443 TURN service select On.
    This is an Expressway X8.11 and later feature that allows the external clients to use port 443 to access the TURN server. This helps avoid issues where external clients are on networks where traffic to the default TURN port, 3478, is being blocked.
  4. In the Authentication realm line, enter turnuser
  5. Click Save Notice in the TURN server status for the 10.0.132.X external addresses that it is now listening on port 3478 and port 443.
  6. The system warns you that this change requires a restart, click on the restart text (or navigate to Maintenance > Restart options and click Restart
  7. Click OK to confirm the restart.

While the Expressway-E is restarting, you can focus on CMS again. Now that the TURN server is enabled, Cisco Meeting Server needs to be made aware of it. The only way to configure it is via the API. Start by looking at the API reference to see how to set up and modify a TURN server.

api-doc-turn-post.png

Follow these steps to configure the TURN server on CMS:

  1. Launch or switch to the Postman app
  2. Switch to the POST verb.
  3. Put in the following URL: https://cms1a.pod2.cms.lab:8443/api/v1/turnServers
  4. From the Body tab, make sure the x-www-form-urlencoded radio button is selected.
  5. You may enter the parameters either using Key-Value or Bulk Edit mode. Bulk Edit is definitely quicker. In either case, remove any other old parameters.

    Enter each Key / Value pair as noted in the table below. The table outlines the decisions that were made in choosing these values.

    Parameter / Key Value
    serverAddress 10.0.102.71

    Description: The IP address that CMS should expect to get traffic from when invoking this TURN server.
    clientAddress 10.0.132.102

    Description: The address that clients should send traffic to in order to reach this TURN server. This is the external address of the TURN server.
    username turnuser

    Description: The TURN server username configured on the Expressway-E
    password c1sco123

    Description: The password associated with the TURN server user on the Expressway-E
    type expressway
    The following is the same data in the format that can be pasted into the Bulk Edit window.

    serverAddress:10.0.102.71 clientAddress:10.0.132.102 username:turnuser password:c1sco123 type:expressway
  6. Click Send in Postman.

Assuming you received a 200 OK response, use the GET method to examine the configuration.

  1. In Postman switch to the GET verb. Leave the URL unchanged from the POST request you just sent.
  2. Press Send

  3. The results gives you some basic information about the TURN server and also includes the turnServer ID.
  4. Copy the turnServer ID value from the result above and append it to the existing URL to query the object. The resulting URL should look something like https://cms1a.pod2.cms.lab:8443/api/v1/turnServers/abb5ecf5-e2b6-48f4-a60b-0ef3eaa99ec2
  5. Press Send again.

  6. Now you can see all the settings you just configured. If you want to get some runtime status information for the TURN server, append /status to the end of the URL. The URL should look something like https://cms1a.pod2.cms.lab:8443/api/v1/turnServers/abb5ecf5-e2b6-48f4-a60b-0ef3eaa99ec2/status
  7. Press Send again.

  8. This API call provides some useful information. Note that reachable is true, along with the roundTripTimeMs. If your Expressway-E/TURN server is not yet up, then this command will likely show different results, indicating that it is not reachable.

By default, every CMS server maintains its own connection to each TURN server.

Test Web Proxy Access and TURN

Now that TURN is configured and operational, you should be able to join a Space from a WebRTC client on the outside of the network. PC3 has been set up for this purpose. It is on the "outside" in that it has been completely firewalled so that it cannot reach any of the internal devices, except for the Expressway-E's external IP addresses, which is used for Web Proxy, TURN, and SIP signalling. The only way for this PC to reach the CMS server is to go through the Expressway-E and Expressway-C.

To test your TURN configuration, you need to access PC3 via Remote Desktop. Follow these steps to perform the test:

  1. If not already connected, launch a Remote Desktop Protocol session to PC3 by clicking on the PC3 shortcut on your laptop's Desktop. (If necessary, log in with username admin and password c1sco123
  2. On this machine, launch Chrome, which should be a big icon on the Desktop.
  3. Enter the Web Bridge URL, https://join.pod2.cms.lab.
    Note: This may be the default Chrome home page for some clients.
  4. When the page loads you should see both Join call and Sign in options. The fact that you can see this page confirms that Web Proxy is working. To verify that TURN is working, Click Sign in
     
  5. Enter the username pod2user3@conf.pod2.cms.lab and password c1sco123 then click Sign In
  6. Now, with Pod2 User3's Space highlighted, click on the Join meeting button
     
  7. If you are prompted to allow access to the camera and microphone, click Allow.
  8. From Jabber on your laptop, join this same conference. Just place a call to pod2user3.space@conf.pod2.cms.lab
     
  9. With the call up, one way to verify that the TURN server is in use is by looking at the Expressway-E, the TURN server itself.
    Open a browser to the Expressway-E at https://expe1a.pod2.cms.lab:445
  10. Log in with username admin and password c1sco123
  11. Navigate to Status > TURN relay usage
  12. You should see two active TURN clients. These are the session between CMS (which could be either 10.0.102.51, 10.0.102.52, or 10.0.102.53) and the TURN server, and the WebRTC client on PC3, which has the IP address 10.0.132.52.
     

  13. In the web browser on PC3, click the red disconnect button to in the CMA browser, and close the browser. On Expressway, you should see the TURN relay released.
  14. Hang up the call from Jabber, as well.

 

You now have WebRTC and TURN configured. If you like, you can now continue on to add support for Skype for Business/O365 gateway calling. This is especially useful if you don't have an on-premise Lync/Skype for Business deployment. Alternatively, you could take a look at the Microsoft on-premise integration example, where you will configure a dual-home conference with an on-premise Skype for Business deployment. Alternatively, you could take a look at Cisco Meeting Management for white-glove services and easier visibility of meetings in a clustered environment.

 

SECTION COMPLETE!

You've finished this portion of the lab. We have multiple other optional lab sections, depending on your time and interest, to continue on.