As we will add bonus features to WebRTC app, we will list them (and their usage) here.

Custom tab

You can display any page in the optional tab inside the app. This tab contains iframe which loads your page. Due to security measures enforced by browsers, you have to serve the page over https. Your servers should also not return HTTP header X-Frame-Options with values DENY or SAMEORIGIN.

SIP URI Interception

WebRTC can intercept SIP links on the page in the custom tab, as long as they follow rules for call URIs, and you embed our intercept script on your page.

Intercept script can be linked by adding script tag to your page with url <your-webrtc-domain>/assets/intercept.js and id webrtc-intercept. For example - if your app is hosted on your-webrtc-app.com, the script will be linked this way:

<script src="https://your-webrtc-app.com/assets/intercept.js" id="webrtc-intercept"></script>

When you are testing the app in the editable version, you do not need to add testing=1&reprovision=1 parameters at the end of the url, so your link to the script will look like this:

<script src="https://your-webrtc-app.testing.cloudsoftphone.com/assets/intercept.js" id="webrtc-intercept"></script>

There used to be (before version 1.13.2) requirement to link exact domain even for editable versions, which had different domain than live ones (<app>.cloudsoftphone.com vs. <app>.testing.cloudsoftphone.com). Intercept script will now try to use both URLs, so you can link either in both production and testing.

Embedded script detects valid links even after page gets changed by JavaScript.

Dial actions

We support most of dial actions, but functionality is often limited to pure audio / video calls or simple transitions to contact’s page:

WebRTC functionality
audio call
audio call
video call
audio call
no action
no action
transition to contact’s call history
transition to contact’s call history
audio call


On default settings WebRTC intercepts all mentioned schemes (sip, cloudsip, groundwire and asoftphone), but if you have whitelabel app you can specify single scheme for interception in the portal (under whitelabel / URI schemes).

Web Service Messaging

WebRTC can send & receive IMs via web service, as long as it implements the send & fetch API. The web service should have https: endpoints, as browser will (due to security reasons) refuse to contact http: ones. It should also provide Access-Control-Allow-Origin headers, with value either * (to allow every page to make request; this is preferred to allow easy testing), or your WebRTC domain.

WebRTC does not support push notifications (yet) - fetch endpoint is polled. Default interval is 8s (~20s in the background, but that might get longer due to Chrome background tab throttling), but you can modify it with account.xml keys.

WebRTC does not support Media Messaging yet.

Pre-filled username

The WebRTC app can be loaded with the username field on the login screen already populated. Just use the full login url with the parameter username at the end:


This will open the login page with the user-login already typed in the username field.

For WebRTC in the editable copy version, you need to add testing parameters at the end of the url:


If the user opens the link in the tab with WebRTC configured with another username (for example when he receives the link through a message in WebRTC), he will be logged out and taken to the login screen with the pre-filled username. If the user-login is the same as the username of the current user, user will stay logged in and will just be redirected to the keypad.


The username should be valid, i.e. for registration wizard login it needs to be valid number with valid country code.

It also needs to have special characters (like + in the country code) properly url encoded (see Percent-encoding reserved characters).


In WebRTC users can record audio track (of both sides) of calls. Recordings are stored locally in the user’s browser folder and can be copied to user’s download folder by clicking the Export button on the Recordings page.

Please note that the browser may purge some or all recordings from the storage when free space on disk is low. This will also happen in go to browser settings and clear the local storage manually. We recommend to export the important recordings you wish to keep and store them in a safer place.

Account XML

Additional configuration can be done with the SIP profile’s Account XML. You can view all WebRTC-specific options in the WebRTC section in Account XML documentation.

Testing Mode

Testing Mode in the WebRTC app allows you to test the provisioning from Editable version of your application before you make it live. Testing Mode can be enabled by either of the following methods:

Via URL Parameters

You can enable Testing Mode by appending testing=1 parameter to the app’s URL if you are testing it in the browser. For example, open the following URL in a new tab in your browser:


This will restart the application in Testing Mode, indicated by the Testing Mode banner at the bottom of the screen. If you want to exit the Testing Mode, click the link in the Testing Mode banner at the bottom.


You can also append the reprovision=1 parameter to the URL to forcefully invalidate the cache and go through the provisioning process again:


From Settings

You can also enable Testing Mode from the Settings screen in the app after logging in:

  1. Log in to the WebRTC app using your account credentials.
  2. Open the drop-down menu by clicking your name at the top-right of the app, and click Settings.
  3. You should be on the About section by default. If not, click About in the left sidebar to open the About section.
  4. Click Restart in testing mode button below the logo and enter the testing provisioning password (testing-provisioning).
  5. The app will restart in Testing Mode, which is indicated by the Testing Mode banner in the bottom.

To exit the Testing Mode, click the link in the Testing Mode banner at the bottom.

Live vs. Testing source code

Testing Mode described above only enables you to use the Editable version of your app’s provisioning (shown in the right column of the portal). If you also want to test newer version of the WebRTC app’s source code that has been updated, you need to use the .testing subdomain in the cloudsoftphone URI of your app.

For example, if your app is available at yourapp.cloudsoftphone.com, the testing version is deployed at yourapp.testing.cloudsoftphone.com. To run your app with testing sources and provisioning, open the following URL in your browser:


This will launch your app with the testing source code along with the provisioning defined in the Editable version of your app.


Testing build of the WebRTC desktop apps already always use the testing sources served via the .testing subdomain and don’t require any additional configuration.

Silent Installation (WebRTC Desktop app)

Windows’ builds of the WebRTC desktop app support installing the app silently in the background by using the command line, without showing the installation UI to the user. The app will be installed to the default installation directory for the current user.

To install the app silently, pass the /S command line switch to your app’s installer. For example:

C:\Users\john\Downloads> your-app-name.exe /S