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 any of the following methods:

1. During Sign-in

Supported on: Desktop Apps and Browser

You can sign into Testing Mode from the sign-in screen of the app by appending * to your username. This will restart the app in Testing Mode and will use the test provisioning from the portal. To exit Testing Mode, click the link on the Testing Mode banner at the bottom.


If your app uses the SMS Sign-in Wizard, you can append the * at the end of the phone number. For apps using Web Registration Wizard, the * character can be appended either at the end of the username or CloudID part of the provisioning URI.


This process automatically logs you into WebRTC after restarting the app by passing your account credentials as query parameters in the URL. For security reasons, only use this feature with test accounts since the username and password would be visible in the address bar of the browser, as well as in the logs of the HTTP server.

2. Via URL Parameters

Supported on: Browser

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:


3. From Settings

Supported on: Desktop Apps and Browser

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 Test 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.


You can hide the Restart in Test Mode button from the app UI by setting the showRestartInTestingModeOption prefKey to false from the Cloud Softphone Portal.

4. Keyboard Shortcut

Supported on: Desktop Apps

Starting with version 4.0 of Desktop Apps, you can restart in Testing Mode at any time by pressing CTRL+ALT+T on Windows or ⌘+⌥+T (Command+Alt+T) on macOS. To exit the Testing Mode, just click the link in the banner at the bottom.


When you press the key combination, the app will immediately restart in Testing Mode so you’ll lose any unsent messages or calls in progress.

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

Keyboard Shortcuts

WebRTC supports keyboard shortcuts for various actions. Most of the shortcuts are listed in the Settings page under the Keyboard shortcuts tab. These shortcuts cannot be edited by the user, however they can be set with the keyboardShortcuts prefKey.

There are also a few shortcuts that cannot be changed — e.g. Enter on the Keypad screen. Such shortcuts are not listed in Settings.

List of supported shortcuts

Following shortcut actions are available on the Conversations screen:

Action Default Shortcut Description
Alt + C
Starts a voice call.
Alt + H
Hangs up the current call in progress.
Alt + V
Starts a video call if possible or switches video on/off.
Alt + O
Toggles hold/unhold in a call.
Alt + M
Toggles mute/unmute in a call.
Alt + E
Toggles call recording on/off in a call.
Alt + T
Shows the transfer options.
Alt + A
Shows the attended transfer options.

Following shortcut actions are available on the Incoming Call dialog:

Action Default Shortcut Description
Alt + Enter
Accepts the incoming call.
Alt + R
Rejects the incoming call.

Following shortcut actions are available on the Transfer dialog:

Action Default Shortcut Description
Alt + Shift + Enter
Accepts the transfer.
Alt + Shift + R
Rejects the transfer.

Following shortcut actions are available anywhere in the app:

Action Default Shortcut Description
Alt + K
Redirects to keypad screen and focuses on the keypad input field.

Provisioning the shortcuts

Shortcuts mentioned above can be changed by the keyboardShortcuts prefKey, which must have the following structure:

    "keyboardShortcuts": {
        "shortcut1Action": "shortcut1Value",
        "shortcut2Action": "shortcut2Value"
  • shortcutAction should be one of the actions listed above for which you are defining a shortcut.
  • shortcutValue should be the actual shortcut for the action. The shortcut is represented by a string.

Shortcut value

A shortcut value is represented by a string, containing individual keys used for the shortcut connected by the + sign. The shortcut also must contain at least one of these keys: Alt, Ctrl, Shift, Mod. Other allowed keys are all the single-character keys from A to Z and special keys - Esc, Enter, Tab, Backspace, Escape, Space, Pageup, Pagedown, End, Home, Ins, Del.


Alt is mapped to the Alt key on Windows and Option key on the Mac keyboards.

Mod is mapped to the Ctrl key on Windows and Command key on the Mac keyboards, while Ctrl is mapped to the Ctrl key on both.

The string is not case sensitive. Any empty spaces in the strings are ignored.

The following example assigns the Control + Shift + C shortcut to the call button in the conversation:

"callAction": "ctrl+shift+c"


In Chrome, there are quite a lot of shortcuts that are already bound to the Ctrl key and a large number of reserved shortcuts contain this key. For this reason, we strongly recommend using the Alt key, or a combination of Ctrl and one other special key instead.


Not all keyboards have the same key layout, and some keyboard formats have a minimal set of keys available. For this reason, key bindings should be carefully considered to ensure maximum compatibility.

Reserved shortcuts

There are some shortcuts, that would normally pass the shortcut validation rules, but are already used by the browser or OS. Some of these shortcuts can be overridden, but some, e.g. Ctrl + W, can’t. Avoid using any common web browser or operating system specific shortcuts.


While WebRTC checks for the most common reserved shortcuts and if it detects one it skips it and uses a default shortcut instead, its’ list of reserved shortcuts is not complete. We strongly advise testing any changes in the shortcuts before deploying them into production.

Invalid shortcuts

Shortcut values must follow these rules:

  • must have at least two keys
  • must contain at least one Alt, Shift, Ctrl or Mod key
  • must contain only allowed keys mentioned above
  • each key in one shortcut must be used only once
  • must not be a reserved shortcut

If a shortcut that does not follow the rules is detected, it is skipped and a default shortcut is used instead. The rest of the provisioned shortcuts might still apply.

Duplicate handling

If two actions should have the same shortcut assigned to them, then all shortcut changes are discarded and the app will switch to default shortcuts automatically.