The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the steps to configure and troubleshoot Cisco Meeting Server (CMS) WebRTC over Expressway.
Cisco recommends that you have knowledge of these topics:
Configuration prerequisites:
Note: Expressway pair which is used for Jabber Guest services cannot be used for CMS WebRTC proxy services.
This document is not restricted to specific software and hardware versions, however the minimum software version requirements must be met.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
WebRTC proxy support has been added to Expressway from Version X8.9.2, which enables off-premises users to browse to a Cisco Meeting Server Web Bridge.
External clients and Guests can manage or join spaces without the need of any software other than a supported browser. Click here for a list of supported browsers.
As of February 5, 2021, these are the supported browsers for CMS 3.1.1:
This image provides an example of connections flow of Web Proxy for CMS WebRTC: (from Exp IP port Usage configuration guide)
Note: When running X12.5.2 or earlier you must configure your external firewall to allow NAT reflection for the Expressway-E& public IP address (firewalls typically mistrust packets which have the same source and destination IP address). As of X12.5.3 this is no longer needed for a standalone Expressway.
a. Navigate to Configuration > Unified Communication > Cisco Meeting Server.
b. Enable Meeting Server Web Proxy.
c. Enter the Join URL in the Guest account client URI field.
d. Click Save.
e. Add the CMS Join URL onto the Expressway-E server certificate as a Subject Alternative Name (SAN). See the Cisco VCS Certificate Creation and Use Deployment Guide.
a. Navigate to Configuration > Traversal > TURN.
b. Enable TURN services, from off to on.
c. Choose Configure TURN client credentials on local database and add the credentials (username and password).
Note: If you have a cluster of Expressway-Es and they are all to be used as TURN servers, then ensure that you enable it on all the nodes. You must configure two separate turnServer instances over API, and point them to each of the Expressway-E servers in the cluster (as per the configurational process shown in Step 4, which shows the process for one Expressway-E server; the second turnServer's configuration would be similar, only using the respective IP addresses and turn credentials for the other Expressway-E server).
Note: You can use a network load balancer in front of your expressways for TCP/HTTPS traffic, but TURN media must still go from client to TURN servers public IP. TURN media must not pass through the network load balancer
This step is required since webrtc connections come in on TCP 443, but Exp 12.7 introduced a new Dedicated Management Interface (DMI) that can be used for 443.
a. Navigate to System > Administration.
b. Under Web server configuration, change the Web administrator port to 445 from the drop-down options, then click Save
c. Repeat steps 3a to 3b on all Expressway-Es used for WebRTC proxy services
Note: Cisco recommends the administration port be changed because WebRTC clients use 443. If the WebRTC browser tries to access port 80, the Expressway-E redirects the connection to 443.
In CMS 2.9.x onward, use the Configuration --> API menu to add turn servers:
d. Repeat step 4c for every Expressway-E server to be used for TURN
This image provide examples of the configurational steps:
Use this section in order to confirm that your configuration works properly.
a. Navigate to Configuration > Unified Communication > Cisco Meeting Server, and you must see the IP address of the WB:
b. Navigate to Configuration > Unified Communication > HTTP allow list > Automatically added rules, check that this has been added to the rules:
Meeting Server web bridges https 443 Prefix / GET, POST, PUT, HEAD, DELETE Meeting Server web bridges wss 443 Prefix / GET, POST, PUT, HEAD, DELETE
Note: It is not expected to find the WB in the Discovered nodes because the rules are simply to allow for the proxy of HTTPS traffic to the WB, and not necessarily for unified communication.
c. Check that the Secure Shell (SSH) tunnel for the WB FQDN has been built on the Expressway-C to the Expressway-E and that it is active. Navigate to Status > Unified Communications > Unified Communications SSH tunnels status, you must see the FQDN of the WB and the target must be the Expressway-E:
In the CMS API menu, look up the turn servers, and click on each one. Within each object, there is a link to check the status:
The output displays information which includes the Round-trip time (RTT) in milliseconds (Ms) associated the TURN server. This information is important to the CB selection of the best TURN server to use.
At the time that a live call that is made with the use of the WebRTC client, you can view the TURN media Relay status on the Expressway. Navigate to Status > TURN relay usage, then choose view.
Useful tools:
In this scenario, the RTC client is able to resolve the Call ID to jalero.space, but when you enter your name and select Join call, the client displays Connecting, as shown in this image:
After about 30 seconds, it is redirected to the initial WB page.
In order to troubleshoot, complete these steps:
Navigate to Logs > Event logs on the CMS WebAdmin
In the Wireshark traces, you see that the client sends Allocate Request with the credentials configured, to the Expressway-E TURN server on port 3478:
1329 2017-04-15 10:26:42.108282 10.55.157.229 10.48.36.248 STUN 186
Allocate Request UDP user: expturncreds realm: TANDBERG with nonce
The server replies with Allocate Error:
1363 2017-04-15 10:26:42.214119 10.48.36.248 10.55.157.229 STUN 254
Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 431
(*Unknown error code*) Integrity Check Failure
or
3965 2017-04-15 10:34:54.277477 10.48.36.248 10.55.157.229 STUN 218
Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 401
(Unauthorized) Unauthorized
In the CMS logs, this log message is shown:
2017-04-15 10:34:56.536 Warning call 7: ICE failure 4 (unauthorized - check credentials)
Solution:
Check the TURN credentials configured on the CMS and ensure that it matches that which is configured on the Expressway-E local authentication database.
On the Callbridge Status > General page, this is displayed:
2017-04-15 12:09:06.647 Web bridge connection to "webbridge.alero.aca" failed (DNS failure) 2017-04-15 12:10:11.634 Warning web bridge link 2: name resolution for "webbridge.alero.aca" failed 2017-04-15 11:55:50.835 Info failed to establish connection to web bridge link 2 (unknown error)
Solution:
Solution:
Navigate to Maintenance > Diagnostics > Diagnostic logging and ensure that Take tcpdump while logging is checked, as shown in this image, before you select Start new log:
Note: Ensure that the Wireshark capture on the client's device and the logging on the Expressway-E are started before reproducing the failing call. When the failing call has been reproduced, stop and download the logging on the Expressway-E and the capture on the client.
In this scenario, the RTC client is able to resolve the Call ID to jalero.space, but when you enter your name and select Join call, the warning Unable to connect - try again later is displayed immediately:
Solution:
Check that CMS, on the internal network, is able to always resolve the _xmpp-client SRV record for the CB domain.