WebRTC

Infobip WebRTC offers a secure way of establishing real-time communication over the web and within mobile or web applications. This helps you focus on user experience and business logic within your app.

It is powered by Web Real-Time Communication (WebRTC) technology, the leading real-time communication standard built into more than a billion devices.

You can use WebRTC as follows:

• As an embedded technology in your web or mobile application - WebRTC is implemented in applications using the RTC SDKs. We currently support native SDKs for JavaScript, iOS, and Android. You can use these SDKs as standalone or combine them with our Calls API platform to cover even more scenarios.
• As an easy link to share with end users - Infobip Call Link makes it easy to share links over email, messaging, or websites for users to get instantly connected to your support agents without the need for you to create an end-user application.
• As an embedded technology in Conversations, our Contact Center as a Service solution - you do not need to care about SDKs, webRTC is part of the web interface used by Conversations agents.

WebRTC supports multiple connectivity scenarios:

To enable WebRTC, contact your dedicated Account Manager or our Sales team.

WebRTC calls and Rooms can be recorded. Recordings are available as an add-on. Contact your dedicated Account Manager to set it up. Learn more about Recording.

Here's how WebRTC works:

Features

Supported features depending on platform

The table below depicts the webRTC SDK features available on different supported platforms.

Network events

Inform your end users about network quality or networking issues during their WebRTC calls. Offer a better user experience using our network quality events feature.

If network problems occur during a call between two users, the platform will inform the user experiencing this issue that their network is too slow to support a high-quality call.

At the same time, the other user will be informed about their peer's network quality issues, so they are aware the problem lies on the other side of the call.

Depending on the platform where you'll incorporate this feature, see the "Network quality" section on the wiki of our RTC SDKs:

• JavaScript SDK for browsers

• iOS SDK

• Android SDK

Record WebRTC calls

You can record video and audio calls with WebRTC calls. Recording is available as an add-on so please contact your dedicated Account Manager if you need this feature.

Recordings for webRTC are controlled by the combination of three elements:

1. The recording preferences you set under Channels & Numbers > WebRTC > Recording. You can choose no recording, audio only, and audio + video. You can also choose to enable video composition, in which case you will receive one single mixed media file for one-to-one and Rooms recordings. Preparing the downloadable version of video recordings might take some time depending on the load on our platform.
2. The optional recording preference you set in the webRTC token for your users. Recording options can be "DISABLED", "ALWAYS" or "ON_DEMAND".

• DISABLED: Recording is not performed, even if the settings are set to record.
• ALWAYS: Ignores whatever settings are defined in the callOptions SDK methods, and use the main recording setting from the web interface.
• ON_DEMAND: Uses whatever recording options you define in the callOptions SDK methods.

3. The recording setting applied at call creation time with the SDK calling methods, when using callOptions.

The outcome of the combination of these three elements is depicted in the table below:

From a webRTC token recording option point of view, if at least one webRTC participant has their token resulting in triggering the recording, all participants will be recorded even if one of the participant's token has the recording option to DISABLED.

After the recorded audio or video call has ended, recorded files are available to you. You can search, download and/or delete them over API or over the web interface. Single-party webRTC calls (i.e., between webRTC user and application, such as Calls API application) are listed under Calls recording, whereas you can find two parties and multi-party calls under Conference recordings.

Screen capture

The Java SDK allows to expose a screen capture facility to end users. Two modes of operation are available for WebRTC Screen Capture:

• Client side: when a capture is triggered, the resulting image file is directly downloaded in the browser session to the end user's device
• Server side: when a capture is triggered, the resulting image file is uploaded to our servers. Listing and retrieving screen capture images is performed by API with the webRTC file methods.

With our server side screen capture, you can ensure that the end capture can trigger this function while ensuring privacy and security - in case for instance where your user or agent needs to capture ID cards, passports or credit cards while preventing this user from storing this files locally on his own workstation.

The capture is always performed on a single designated video stream.

Screen captured files that are stored on our server are part of computing your recording storage charges.

Technical requirements 

Here are the technical details you need to know before you start using WebRTC.

Bandwidth requirements

The approximate data rate for each stream of WebRTC:

Codecs

Platform compatibility

For supported Android versions, see the supported list.

For supported iOS versions, see iOS system requirements.

For supported browsers and OS, see browser compatibility list.

Get started with RTC SDK

To start using WebRTC, you need to have an Infobip account and WebRTC enabled as a service on that account. Log in or create an account to continue.

WebRTC is enabled by default for all self-sign-up customers. In case you have a managed account and wish to start using any webRTC service, reach out to your dedicated Account Manager or contact our Sales team.

Next, follow these steps:

1. Declare your application, define, and associate your mobile push configurations.
2. Set up SDKs for your application project.

Declare a webRTC application

If you intend to integrate our webRTC SDKs into mobile applications (iOS/Android) and your mobile users are expected to receive inbound calls over webRTC, you need to declare the push notification configurations for these mobile operating systems. These configurations will be used to wake up your webRTC-based mobile application on new inbound calls.

This application creation and webRTC push configuration declaration are NOT required if:

• You plan to use only our Javascript SDK.
• Your mobile users (with our mobile RTC SDK) will only place outbound calls and are not expected to receive inbound calls.

Android push notifications rely on Google FCM, while iOS requires APNS certificates.

You can only perform the declaration of push notification channels via API. These are the steps you need to take in this instance:

1. Create a new application container using Infobip platform application methods
2. Create webRTC push configuration resources using the webRTC push configuration API methods, specifying the applicationId from step 1. Our system will automatically create the resource association with your newly defined application. You can update these resource associations manually via the Resource associated methods under Application and entity management.

Set up the RTC SDK

You can find our (web) RTC SDK on Infobip GitHub, and the following repositories are available:

• infobip-rtc-js: The JavaScript RTC SDK
• infobip-rtc-extensions-js: Extensions for the JavaScript SDK - mainly local audio and video filters
• infobip-rtc-ios: The native iOS SDK
• infobip-rtc-android: The native Android SDK
• Infobip-rtc-showcase: A basic application implementing our RTC SDK (JavaScript with angular/jquery/angular, iOS & Android)

Each repository includes usage and guidelines on its main readme page and associated wiki.

Call link

The call link feature enables efficient support scenario implementations without the need to be physically present in the same room. Call link allows end users to be connected with a predefined destination without the need to develop an end-user application.

You can have a video or audio chat with your end users in just a few clicks. From the Infobip portal or with a simple API call, you generate a short URL that you share with your end users over messaging sessions, emails, or even on your website. Once the end user clicks this URL, a browser window opens and connects the end user to the predetermined destination. This browser window can be branded by leveraging templates that include elements such as text messages, colors, and logos to be displayed on the web page.

Supported destinations

When you create a link to share with the end user, you need to predefine the destination that will be contacted once the end user starts the call.

The following destinations are available:

Call link domain and subdomains

All generated call links are created by default under the domain name "call-link.com". A call link looks like this: "https://call-link.com/r9wpIY". 

You may request up to a maximum of 3 subdomains for Call Link, such as "support.call-link.com", "sales.call-link.com", "mycompany.call-link.com". Subdomains can be requested and managed from the Infobip Portal or via API. Subdomain's availability when requesting for a new one can't be guaranteed.

To use a subdomain when generating call links, follow these simple steps:

1. Request a Call Link subdomain via the Infobip Portal (Call Link application, under the WebRTC channel application)
2. Create a Call Link configuration and include the subdomain ID in that configuration
3. Any call link that is generated based on that configuration will be generated under the associated subdomain

Supported webRTC features

The following webRTC features are available to the Call link end user based on features enabled from the Call link configuration:

Managing Call link configurations

Before generating shareable links, we strongly advise you to create at least one Call link configuration. Configurations can be created on the Infobip Portal under the webRTC channel application or using the Call link configuration API methods. In case you do not create any Call link configuration, a default system one is used.

You can use the following elements to configure the call link:

• InitialOptions
  These are the options available to the end user when they open the call link page right after initiating the call. Here you can define whether all calls generated using this configuration can use audio and video, as well as which preferences would be activated for the camera (front/back) on mobile devices.
• CallOptions
  The options that the end user has during the active call, such as the ability to switch cameras, mute/unmute themselves or start a screen-sharing session.
• Theme
  You can also define your own branding, i.e., how the webpage will look to the end user.
  A theme consists of 3 types of elements:
  • Images: The image that you use as a logo in the top left corner of the Call link, plus a background image for the whole window. These 2 elements are optional, and the default icon and background are applied if you do not add your own. You must use the Call link images API method to upload these images. When you upload an image, the request returns an id for that file, which is the reference used in the theming definition of your Call link configuration.
  • Messages: The text shown to the end user when they open the Call link URL. You can define 3 different messages and these are presented based on the status of the link (active, inactive, or expired). See the following ''Generate a Call link'' section for more information about allowed time windows and one-time usage.
    • The inactiveText is shown to the end user when they click on the link. The link is considered inactive because the allowed startTime is not reached yet, thus the end user cannot start the call.
    • The expirationText is shown when the call link has expired, either because it is a one-time link that has already been used or because the allowed endTime has already passed.
• Colors: Whether you choose to use a background image or not, you may also state your preferred color for various elements in the UI.

See the following illustration for guidance. Colors are defined as hexadecimal values

Default Call link configuration

You can set a default call link configuration, which means that this specific configuration is used when generating a call link URL when no specific configuration is defined. Note that you can set only one default configuration. Usually, the first configuration you created is considered the default.

Subdomains

If you don't specify any specific subdomain during the creation of a Call Link Configuration, all Call Links generated out of this configuration will be under the main domain "call-link.com".

To leverage the ability to generate links under your desired subdomain, refer to the section "Call link domain and subdomains" above.

Generate a Call link

A call link URL can be created from the Infobip Portal under the webRTC channel application or via API with the related Call links methods.

When generating a new call link URL over API, you have to specify:

• The webRTC identity and display name (ie. full human-readable name) for the end user who will use the call link.
  • This identity does not need to be declared in advance with the webRTC token generation method, the call link platform will create this token for you. By defining this, you ensure that whoever is receiving this call (Conversations agent, or your webRTC user in your webRTC application) is able to correctly recognize and identify the calling party.
  • If you omit these values, the end user will have to fill in his name before the call can be started. This is especially recommended when using ROOM as the destination type. 
• The destination type and associated characteristics.
• The validity window for the generated URL. Here you can define whether this generated call link can only be used once, or multiple times. You can also define a start and end date/time between which this link can be used, as well as valid days and time slots within that validity period.
  For one-time usage, note that:
  • The usage counts from the moment that a call has effectively started. Opening the received URL without starting the call does not count as usage.
  • The one-time parameter does not apply when the destination is set to ROOMS. 
• The call link configuration that you wish to use to create the link.

You can omit the specification of a validity window when creating a new Call Link URL, in which case:

• the created link is immediately active
• the created link will automatically expire 24 hours after its creation time.

Display name override

When the destination of the link is either WEBRTC, CONVERSATIONS or PHONE, you have the ability to define a display name (ie. name of the correspondent as shown in the Call Link UI of the end user) that must override the defined destination name. This feature can be useful is scenarios where you want to enhance the privacy of the correspondent or give it a less technical name. For instance:

• with PHONE destination, by default the phone number of the called party will be shown as participant name to the Call Link UI end user. For privacy reason, you may prefer to hide this phone number or show an alternate name, such as "John Doe"
• with WEBRTC destination, by default the technical identity (as defined when creating the webRTC token for that user) will be shown as participant name to the Call Link UI end user. You may prefer to display a more generic name to the end user, such as "Company XYZ Contact Center".

Understanding the video layout

With Call Link, 2 different layouts can be applied: grid and spotlight layouts.

Grid layout

The video grid layout tries to fit as many call participants on the screen. Participants with an active camera are placed in the top rows of the grid, as well as participants who have recently talked.

Participants tend to keep their position in the grid so as little reordering as possible occurs. Typically a maximum of 4 camera streams are displayed to the end user in the grid layout, even if more participants would have enabled their camera.

When the Call Link end user is on a desktop computer, around 20 participants can fit in the layout, depending on the screen width. If the number of participants can't form a perfect rectangular N x M grid, the bottom rows will have more elements in it.

A call between 2 participants when the destination is PHONE will always use the grid layout.

Spotlight layout

The grid layout will switch to a spotlight layout when:

• A participant shares his screen
• A participant is selected by the Call Link end user to be in spotlight.

The spotlight view sets a larger view on the top for the screen sharing session or the highlighted participant, and the bottom row includes up to 5 participants.

WebRTC SDK 1.x (deprecated)

With the release of SDK 2.0, a number of elements are changing or are being deprecated. In summary:

• The way you declare webRTC applications is changing. Refer to Get started with webRTC SDK section to see how and when to declare webRTC applications for SDK 2.0. Customers who ned to use SDK 1.x to create or modify webRTC applications for that version can still use the previous methods (see the documentation below).
• Changes to SDK method:
  • Call method names are changing slightly, such as callPhone becoming callPhoneNumber, or calling a webRTC user becomes callWebrtc instead of call.
  • The callSIP method is deprecated. If you need webRTC users to call SIP destinations, you can use our Calls API platform to orchestrate such a scenario. Note that to use Calls API requires running a backend application on your premises or on your own cloud hosting service, making use of the Calls APIs to orchestrate the connection between the webRTC and SIP call legs.
  • webRTC Conferencing methods are renamed to webRTC "Rooms", and thereby the former conferencing methods are renamed accordingly.
• We have updated error codes to be more granular.
• In one-to-one webRTC calls, both call legs are charged.
• Dynamic Destination Resolving is deprecated. See the remainder of this documentation to understand how to re-implement similar capabilities using our Calls API platform.

You can still consult the deprecated SDK 1.x GitHub repositories until the end of the service date under the following names:

• JS: infobip-rtc-js-1.x-deprecated
• Android: infobip-rtc-android-1.x-deprecated
• iOS: infobip-rtc-ios-1.x-deprecated

Migration guides, for users planning to move from RTC SDK 1.x to 2.x, are available in each of the GitHub repositories.

Configure a webRTC application for SDK 1.x

When using webRTC SDK 1.x, you can create, modify or delete webRTC applications via API.

Note that explicitly declaring a webRTC application is only needed when you plan to integrate Infobip SDKs into native mobile applications (iOS/Android) and these mobile users may receive incoming calls over webRTC.

Dynamic Destination Resolving

People's privacy is crucial. Brands need to ensure that they are keeping all personal data safe. This includes but is not limited to, names and phone numbers.

Infobip Dynamic Destination Resolving feature in WebRTC calls enables your end users to talk to each other in full privacy and protect their identities. 

At the same time, you avoid off-platform transactions and have full control of the communication flowing in to allow for advanced routing and cost optimization.

This is what a high-level overview looks like:

Your end user can initiate a call from the application or call the Voice number. When the call reaches the Infobip platform, the platform calls HTTP API endpoint that you have specified when configuring your application. On your platform via API, you decide what you want to do with the call.

To set up Dynamic Destination Resolving, specify the HTTP API URL that the Infobip platform needs to call.

Here's how to set up Dynamic Destination Resolving configuration.

Create Dynamic Destination Resolving configuration

1. Navigate to the Channels and Numbers module located at the bottom left > WebRTC > Dynamic Destinations > ADD NEW.

2. Enter the following parameters and click CREATE DYNAMIC DESTINATION.

• Authorization header (optional) – Enter the Authorization request header as the general HTTP authentication framework. That is, if you want to have it included in the request we send toward your platform. It adds an additional layer of security to intra-platform communication.
• Callback URL (API endpoint) – Define where you would like us to send the request to.
• Status URL (API endpoint) – Define where would you like to receive status reports once the call is finished.

3. You can go back to the WebRTC application and enable App to Dynamic Destination Resolving to use this configuration.

4. Align your platform with the Infobip platform when receiving incoming calls. To set this up, refer to Incoming Calls with Dynamic Destination Resolving. 

Incoming calls with Dynamic Destination Resolving

Incoming calls can be initiated by:

• WebRTC calls from end users using a mobile or web application,

• Placing a phone call to Voice number.

In both cases, when the call reaches the platform, we will send a POST request to your API endpoint.

Depending on the type of the incoming call, the request will contain different information:

If the call originated from the application, it will contain source and customData fields. 

• Source is the identity (unique identifier) of the user who initiated the call.

• CustomData can be passed through Web, Android and iOS SDKs when calling our callDynamicDestination method.
  CustomData can be used to collect information for routing.

If the incoming call was a phone call it will contain the source and destination fields.

• Source is the phone number of the person who made the call.

• Destination is the DID number that the phone call has been placed to.

Request example:
(call originating from WebRTC calls)

{ 
"source": "Alice", 
"customData": { 
	"myUserId": "myBob" 
} 
}

Request example:
(call originating from an actual phone number)

{ 
"source": "41793026727", 
"destination": "41793026731" 
}

In the response, define where the call will be delivered. Specify the action and destination fields.

• With the action, you define whether the call will terminate as WebRTC call towards the end user in the application or if it will be delivered to a phone number. Set the action field value to call or call_phone_number.  

• With the destination field, you provide the information which end user or phone number to forward the call to. Optional field in the response is source but it is necessary when you want to guarantee anonymity to your customers. If you don't' set it up, the original source that was received with the call will be used.

Response example:
(call terminating to WebRTC calls)

{
"action": "call",
"source": "AnotherAlice",
"destination": "AnotherBob”
}

Response example:
(call terminating to an actual phone number)

{ 
"action": "call_phone_number", 
"source": "41793026728", 
"destination": "41793026732" 
}

If you configured the status URL after the call has been completed, the platform will send another HTTP POST request to that endpoint. It will contain general information regarding the call status.

Request example: 

{ 	
"callId": "000a15f9-187b-425e-8f16-63acb54eeb4c", 
// obtained by calling "id()" method on "Call" object in our SDKs 
"source": "Alice", 
"destination": "Bob", 
"status": "finished", // or "failed" 
"duration": 15 
}

The Infobip platform doesn't expect a response. Your platform needs to return the 200 OK status so we know you have successfully received the information.

Replicate Dynamic Destination Resolving with RTC SDK 2.0 and Calls API

If you were using Dynamic Destination Resolving with Infobip RTC SDK 1.x and are planning to migrate to RTC SDK 2.0, you can replicate the behavior of Dynamic Destination using our Calls API platform together with webRTC.

You can easily implement the following scenarios:

Record WebRTC calls for SDK 1.x

You can record video and audio calls with WebRTC calls, where the Recording feature is available as an add-on. If you do not see it enabled, contact your dedicated Account Manager.

Recordings for webRTC are controlled by the combination of two elements:

1. The recording preferences you set in the web interface, under Channels & Numbers > WebRTC > Recording. You can choose between: no recording, audio only, and audio + video. You can also choose to enable video preparation and composition, in which case you will receive one single mixed media file for one-to-one and conference recordings and the recording file(s) will be made ready for download. Preparing the downloadable version of video recordings might take some time depending on the load on the Infobip platform.
2. The optional recording preference you set in the webRTC token for your users. Available recording options are: "DISABLED", "ALWAYS" or "ON_DEMAND". If you don't set recording options in the token generation, the settings from the web interface will always apply.
   • DISABLED: Recording will not be performed, even if the settings from the web interface are set to record.
   • ALWAYS: Ignores whatever setting is defined in the callOptions SDK methods, and uses the main recording setting from the web interface.
   • ON_DEMAND: Uses whichever recording options you define in the callOptions SDK methods.

From a webRTC token recording option point of view, if at least one webRTC participant has his token resulting in triggering recording, all participants will be recorded even if one of the participant's token has the recording option set to DISABLED.

After the recorded audio or video call has ended, recorded files are available to you. You can search, download and/or delete them over API or over the web interface.