Troubleshooting

This section covers known problems around some specific corner cases.

WebRTC version

We advise to update if you have version older than 1.12.1, because in earlier versions calls won’t work in the Chrome 68 (to be released around 24/7/2018).

You can determine source version in several ways:

  • when logged in: in settings / about / show extended version info
  • in the dev tools (press F12 on windows, or right click on page - inspect on any platform), tab Console: the first line contains version info

PBX issues with ssrc attributes

Some PBXs are filtering out a=ssrc lines out of SDPs. This causes issues for Chrome, as it needs those attributes to recognize different streams. Therefore video (including screen sharing) is not supported (and we advise to disable it) for such PBXs.

No audio / helicopter sound

When you hear repetitive sound with no trace of actual voice / words, please check that you have configured encryption properly (e.g. that en/decryption is done on both ends), or try to turn it off entirely.

Failing cross-origin requests

Modern browsers follow the same-origin security policy. The purpose of this policy is to restrict how a document or script from one origin can interact with a resource from another origin - this is protecting the user from various potential attacks as malicious code in one browser tab making requests to another site (e.g. internet banking) opened it another tab (see https://en.wikipedia.org/wiki/Same-origin_policy#Security_Applications).

Under the same-origin policy, a document hosted on one server can only interact with other documents, that have the same origin (protocol, host and port number). Requests to cross-origin are restricted to “simple requests”. Non-simple cross-origin requests can be allowed by setting the right CORS (Cross-Origin Resource Sharing) headers on the server side.

This is also the case of the browser WEBRTC: any cross-origin endpoints that are to be the target of WEBRTC’s non-simple cross-origin requests must use the right CORS headers or else the WEBRTC app will not work properly.

When a browser is about to make a non-simple request, it sends a “preflight request”. The preflight request uses the OPTIONS method. In response to it, the server can respond with the information whether it is acceptable to send the original request. Only if the serves approves it the original request is executed by the browser.

There are several ways for setting the CORS headers to the responses to OPTIONS requests. The simplest and sufficient one to make the WEBRTC browser app working properly is to add the Access-Control-Allow-Origin header to the response. This header defines, which origins are allowed to make non-simple cross-origin requests. If set to ‘*’ (asterisk) then any origin meets the criteria. Eventually, a specific origin(s) can be set - but then the app will work only if run from the specified origin(s).

While there are some theoretical workarounds e.g. disabling the browser’s web security (like running Chrome with the disable-web-security option), they generally present a huge security hole and cannot be recommended for any production use. Handling CORS is a much better way to deal with the same-origin policy.

For additional info about simple/preflight requests, response headers, etc. see https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.