Web Bridge

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.

Configure Web Bridge on cms1a

The first step is to configure the certificate to use for the Web Bridge service as well as the CA trust certificate. Start with cms1a:

Cisco Meeting Server Name Password
cms1a.pod2.cms.lab c1sco123
cms1a> webbridge certs cms1a.key cms1a.cer cmslab-root-ca.cer

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.

cms1a> webbridge listen a:443

Aside from communicating with web clients, the Web Bridge service must communicate with Call Bridge servers on the backend. To do that securely, it needs to have a trust list of all of the Call Bridge certificates it will allow. Like the XMPP service, use the combined certificate that you created earlier, cms1abc.cer.

cms1a> webbridge trust cms1abc.cer

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.

cms1a> webbridge http-redirect enable

Enable the Web Bridge service and ensure certificates are verified.

cms1a> webbridge enable SUCCESS: Key and certificate pair match SUCCESS: certificate verified against CA bundle SUCCESS: Webbridge enabled

Finally, check the status. The webbridge command indicates that the process is enabled. To see if the process is actually running, use the webbridge status command. The download URLs listed (which appear set to none) are only used for the CMA thick client and are not used for WebRTC-only deployments.

cms1a> webbridge Enabled : true Interface whitelist : a:443 Key file : cms1a.key Certificate file : cms1a.cer CA Bundle file : cmslab-root-ca.cer XMPP Trust bundle : none HTTP Trust bundle : cms1abc.cer HTTP redirect : Enabled HTTP URL redirect : true Clickonce URL : none MSI download URL : none DMG download URL : none iOS download URL : none Beta options : none cms1a> webbridge status Running

Configure Web Bridge on cms1b

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

Cisco Meeting Server Name Password
cms1b.pod2.cms.lab c1sco123

Enter the following commands on cms1b:

webbridge certs cms1b.key cms1b.cer cmslab-root-ca.cer webbridge listen a:443 webbridge trust cms1abc.cer webbridge http-redirect enable webbridge enable

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

Configure Web Bridge on cms1c

Finally, repeat these steps on cms1c.

Cisco Meeting Server Name Password
cms1c.pod2.cms.lab c1sco123

Enter the following commands on cms1c:

webbridge certs cms1c.key cms1c.cer cmslab-root-ca.cer webbridge listen a:443 webbridge trust cms1abc.cer webbridge http-redirect enable webbridge enable

Verify that the certificate verification succeeded and Web 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.pod2.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 WebRTC-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.