As we will add bonus features to WebRTC app, we will list them (and their usage) here.
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
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
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
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.
We support most of dial actions, but functionality is often limited to pure audio / video calls or simple transitions to contact’s page:
transition to contact’s call history
transition to contact’s call history
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).
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
http: ones. It should also provide
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.
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.