Web Bridge Configuration

If you plan to allow users to access their Spaces in Cisco Meeting Server via a browser, then you will need to configure the Web Bridge. It is the server role that enables users to manage and connect to their Spaces as well allow outside participants into conferences using only a WebRTC-enabled browser. New in version 2.9 of the Meeting Server software is a completely new version of Web Bridge which includes a new Meeting Server Web App and relies on a new intra-cluster communication protocol rather than XMPP for user authentication. We will be configuring the new version of Web Bridge (Web Bridge 3) in this lab and using the new Meeting Server Web App for browser-based calling instead of the more traditional WebRTC client which relied on XMPP services.

At this point in time, the legacy Web Bridge (Web Bridge 2) can be configured at the same time as Web Bridge 3. At some point in the future, however, support for XMPP and Web Bridge 2 will be removed from subsequent CMS releases. Boh Web Bridge 2 and Web Bridge 3 use a different protocol for user authentication. Web Bridge 2 relies on XMPP for authentication whereas Web Bridge 3 utilizes a new protocol called Callbridge to Webbridge (C2W). The benefit of the new Web Bridge 3 is that it does not require configuration of XMPP.

Configure Web Bridge on cms1a

The first step is to set the HTTPS certificates. These are the certificates that will be presented to web browsers so they need to be signed by a certification authority and the hostname needs to match. The certificate file required here is the full chain of certificates that starts with the end entity certificate (cms1a.cer) and finishes with the CA root certificate (cmslab-root-ca.cer). We combined these certificates to form our certificate chain (cms1a-fullchain.cer) in the Certificates section of the lab already. Start by configuring cms1a:

Next, enable the listening interface and port. In this case, you will use port 443, the default HTTPS port, on interface a. Remember when you configured the Web Admin service, you used port 8443 to leave port 443 available for the Web Bridge service.

Aside from communicating with web clients, the Web Bridge service must communicate with Call Bridge servers on the backend. To do that securely, we need to configure the Callbridge to Webbridge port to listen on. Remember that Callbridge to Webbridge is a new protocol used solely by Web Bridge for the purpose of user authentication and takes the place of XMPP. The port used can be any unused port, but it's a good idea to make the address/port accessible from the Callbridge(s) only. In this case we will set it to 4443.

Next, configure the C2W connection certificates. You need to configure the SSL Server certificates used for the C2W connection. These are what will allow Web Bridge to communicate with Call Bridge securely using the C2W protocol

The Web Bridge 3 C2W server expects Call Bridges to present a client certificate; Web Bridge 3 will verify whether to trust them using the trust bundle provided by the following command which we need to enter:

The redirect feature redirects connections destined to port 80 on the server to the Web Bridge listening port, 443 in this case. This allows users to enter the name of the CMS server without appending https:// to the URL. Note that if you configured http redirect for Web Admin previously, this would fail as you must decide which service you want port 80 redirected to. As Web Bridge is a user-facing feature, it makes sense to make accessing it as simple as possible.

Enable the Web Bridge service and ensure certificates are verified.

There are a couple additional steps to enabling Web Bridge 3. We need to configure the Call Bridge service to use C2W connections. C2W certificates are used for the connection between Call Bridge and Web Bridge 3. For the Call Bridge to make a C2W connection to a Web Bridge 3, we need to specify a C2W trust store to verify certificates against, so that when the certificates we configured above are presented by the Web Bridge 3, Call Bridge will trust them. We achieve this by configuring the command below:

Now we need to restart the Call Bridge service:

We can check the status of the Call Bridge and verify that the c2w certificate is visible:

Finally, check the status. The webbridge3 command indicates that the process is enabled. To see if the process is actually running, use the webbridge3 status command.

Configure Web Bridge on cms1b

Now that Web Bridge 3 is running on cms1a, configure it on the other two servers. Configure cms1b with the following commands:

Enter the following commands on cms1b:

Now enter these commands for the Call Bridge to Web Bridge trust bundle on cms1b and restart Call Bridge:

Verify that the certificate verification succeeded and Web Bridge is successfully enabled.

Configure Web Bridge on cms1c

Finally, repeat these steps on cms1c.

Enter the following commands on cms1c:

Now enter these commands for the Call Bridge to Web Bridge trust bundle on cms1c and restart Call Bridge:

Verify that the certificate verification succeeded for both services and Web Bridge/Call Bridge is successfully enabled.

Test Web Bridge Connectivity

Now that the Web Bridge service is running, you can point a browser to cms1a (https://cms1a.pod8.cms.lab) or any CMS server running the Web Bridge service and you should get the sign in screen like shown below.

At this point you have not completely configured the Web Bridge, but in order for calls to a Call Bridge to be aware of a Web App-based user, the Call Bridge has to be configured with the details of every Web Bridge. In scalable, redundant deployments, this must be done via the CMS REST API.