TURN stands for Traversal Using Relays around NAT. Basically, it’s a device that is publically accessible from the Internet and can send and receive multimedia. To function properly, it must be accessible for external devices on the Internet as well as for internal devices (such as CMS), so audio and video traffic can come in and out the organization. In such case, the TURN server acts as an anchor point for the media that is trusted by the firewall.
By the way, 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, it seems reasonable to configure it in Expressway instead of creating extra CMS servers or increasing the load on the existing CMS server. 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 a set of authentication credentials on the Expressway-E to use for TURN.
Create a “Traversal…” user account.
Configure the Expressway-E TURN server.
TURN in CMS
If there’s no cluster, you can simply specify the TURN CMA and TURN CMS addresses in CMS web interface.
Port 5222 or port 5223
It’s better to use the secure port 5223 in ServerAddress field. However, in this case we are using port 5222 because we have a wildcard certificate in CMS, and it can only have a domain and “*.domain” in CN and SAN. So, the actual address of CMS web portal doesn’t coincide with CN and SAN in the certificate, which means we can’t use 5223, only 5222.
TURN CMS (serverAddress) — The IP address that CMS should expect to get traffic from when clients connect to a conference.
TURN CMA (clientAddress) — The address that clients (both internal and external ones) should send traffic to in order to take part in a conference.
TURN CMA (clientAddress) and TURN CMS (serverAddress) can be one and the same address if Expressway-E has a public IP address and is not located behind any NAT. If Expressway-E is behind a NAT device, then TURN CMA is the public IP address that Expressway is being translated into. TURN CMS (serverAddress) is a local IP address in the corporate network. For the same reason port 3478 should be open from Cisco Meeting Server towards Expressway-E.
If Expressway-E is located behind a NAT, then you should configure NAT Reflection on your firewall. Basically, it makes it possible for internal clients and/or devices to be rerouted to Cisco Meeting Server address as they connect to a conference using TURN CMA (clientAddress).
NAT Reflection is also needed for MRA, because if Expressway-C initiates connection with Expressway-E by “knocking” on the private IP address of Expressway-E, then Expressway-C will require an RMS license for calls from/to a jabber device that is outside the corporate network (i.e. calls will be treated as B2B). To avoid this, you should create an A record in your internal DNS pointing at the public address of Expressway-E, and NAT Reflection will reroute the traffic towards Expressway-E to the private IP address.
Working with NAT
For a cluster, use Postman to configure TURN on any of CMS cluster nodes, and these settings will be applied to other nodes automatically.
Create TURN servers and fill in the following parameter values:
We have already discussed the first and second parameters. Third and fourth are the login and password for the user account we have created in Expressway-E. The last parameter is the type of TURN server (in our case that’s Expressway, but it could be CMS as well).
For a cluster, two or more TURN servers should be created (the number equals the number of Expressway servers in a cluster).
In status, we can see if TURN is available for CMS and so on, see below.
In order for Expressway-C to see CMS cluster, you should configure your internal DNS server. In the external domain zone (if you have a Dual Domain scenario), create a join directory with a _tls subdirectory. Inside the _tls subdirectory, create three DNS SRV records named _cms-web with corresponding priorities, pointing at DNS A records: cms01.internal-domain.com, cms02.internal-domain.com, cms03.internal-domain.com.
Enter “join.[external]-example.com”, so Expressway will see all servers in a CMS cluster:
Now turn on MRA (Mobile and Remote Access).
Turn On MRA
It’s recommended to change the default Expressway-E port from 443 (for example, to 445). If Expressway-E is clustered, perform this action for each of them. If you leave the port number unmodified, your external users will connect to Expressway-E Web Admin instead of CMS.
Note that your firewalls must have the following ports open:
Follow your URL: join.example.com to check if the web portal is available from outside.
There are different ways to configure call routing:
- Route calls to Cisco UCM;
- Route calls to Cisco Expressway-C (preferable).
The difference is what acts as the central call routing node. You can also perform a flexible configuration using CMS and Expressway priorities.
In our case, it will be the second option. See the picture below (it was taken from the Deployment guide, so please disregard everything that’s outside the firewall).
Routing on CMS
You can set CUCM as a SIP proxy (as a first option), but it requires the CUCM itself being properly configured (trunks, SIP Rout Patterns, Route Lists, etc).
Business to Business calls
Business to Business (B2B) calls are the major feature of Expressway. B2B enables performing video calls, calls from/to organizations, external video services and clients on Internet, while safely bypassing corporate firewalls.
B2B calls are based on a possibility of call routing through Expressway. This can also be achieved through domains, CUCM and most of the other SIP call management objects, but Expressway also has the concept of a DNS zone. You don’t have to identify the remote destination of a call explicitly. Instead, Expressway DNS finds the call destination outside the organization network. Our DNS zone is already configured.
Create a search rule for incoming calls on Expressway-E
In our company, you can only perform an incoming call to a special conference with the following SIP-URI: firstname.lastname@example.org
We’ll create a regular expression: meeting@example\.com\.*
You can read more about these parameters in the documentation or use the tips in Expressway.
To put it simply, an incoming SIP call from DefaultZone, that has email@example.com in its destination address, will be routed to UC Traversal zone.
Create a search rule for outgoing calls on Expressway-E
We’ll create a regular expression: "(?!.*@%localdomains%.*$).*"
An incoming SIP call (coming from Expressway-C side) from UC Traversal zone that has a non-local domain(s) after @ in its destination address will be routed to the DNS zone for a destination lookup (matching the value after @ with its IP address on the Internet) and a successful call.
If you have Dual Domain, then the external domain must be transformed into internal. The following regular expressions can be used: "(.*)external.com((:|;).*)?" and "1\@internal.com"
Create a search rule on Expressway-C
You should also add transformations for correct call routing.
Let’s make test calls. Call a conference with Cisco RoomKit Mini from inside the organization, from outside (using a B2B call with Cisco RomKit Plus), and connect through the web as well.
Connect to the conference through web:
Call from outside:
Call from inside:
The conference has been gathered.
For the record, firstname.lastname@example.org and email@example.com are registered on their CUCMs.
What was it like for Expressway and CMS:
Incoming call on Expressway-E:
Details of the call passing through Expressway-E:
Incoming call on Expressway-C:
Details of the call passing through Expressway-C:
Incoming call on CMS:
- Part 1 - Cisco Expressway 12.5.5. Remote Videoconferencing without VPN
- Part 2 - Cisco Expressway 12.5.5. Remote Videoconferencing without VPN
- Part 3 - Cisco Expressway 12.5.5. Remote Videoconferencing without VPN