Get help with Cisco Meeting Server and Cisco Meeting Apps

Find answers quickly with these FAQs.

» »

Troubleshooting Web Bridge connectivity issues

To troubleshoot Web Bridge connectivity issues:

  1. Check that users can log in using the PC or Mac Meeting Apps - if this does not work then there is a problem with the XMPP configuration that needs to be resolved before the Web Bridge will work.
  2. Try to sign in to the Web Bridge using the credentials of a user on the Meeting Server that works, using the PC/Mac App.

    If this fails with the error message “Unable to connect to the Meeting Server - try again later”, this suggests that there is a problem in the connectivity between the Web Bridge and the XMPP server. When a user tries to log in to the Web Bridge with a user name of the form, the Web Bridge performs a DNS SRV lookup of in order to discover the IP address of the XMPP server. If the Web Bridge cannot resolve this DNS record, the login fails with the error message above.

    SSH to the server running the Web Bridge and issue the following command on an Acano Server:

    dns app lookup SRV 

    or on a virtualized deployment

    dns lookup SRV 

    This command should return the IP address of your XMPP server. If this is not the case, then the DNS configuration needs to be changed so that this can be resolved correctly.

  3. If the user can log in but not make calls, then this suggests that there may be a problem with the TURN server not being configured or accessable. Use of the PC client from the same network should produce the same result in step 1 if this is the case.
  4. If a user can log in and join a call but a guest cannot, this suggests that there is a problem with the HTTPS connection between the Call Bridge and Web Bridge. If this is the case, you see an error when trying to join as guest saying that the WebRTC client is unable to connect to server. In this case:
    1. Log in to the Call Bridge Web Admin Interface and go to Configuration >General.
    2. In the Web Bridge Settings section, check that the Guest Account Client URI is the same address that which users put in their browser to when logging in (accessing the Web Bridge). Check that the callbridge can resolve any DNS names in this address, and that the network path to the webbridge permits connections to the TCP port used (the default is 443 for HTTPS connections).
      • If this all correct, then verify that the Web Bridge has been set up to trust the Call Bridge’s SSL certificate by entering the callbridge command in the MMP of the server it is running on.


      • If this is not the case issue the command:
        webbridge trust <cert.crt>

        where cert.crt is replaced by the name of the Call Bridge certificate. 

        If you are using a split deployment, SSH to the Core and Edge servers separately, to ensure that the Certificate file for the Call Bridge is listed as the trust bundle for the Web Bridge.
        If this is not trusted, copy the Call Bridge certificate to the Edge server and then configure the Web Bridge to trust the Call Bridge using the command above.