CTRLK

Shared components

Get started with RTC SDK

|

View as Markdown

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

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 [#declare-a-webrtc-application-getstartedwith-rtc-sdk]

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 Firebase Cloud Messaging (FCM), wheras iOS requires APNS certificates.

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

  1. Create a new application container using the Infobip platform application methods.
  2. Create WebRTC push configuration resources using the WebRTC push configuration API methods, specifying the applicationId from step 1. The Infobip 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.
Application creation

From SDK versions 2.2.3 (iOS) and 2.2.1 (Android), the creation of an application, and association of push configurations to that application, are no longer needed. Push configurations are required when your mobile users want to receive calls on their mobile app but do not need that resource association anymore.

For JavaScript SDK users, from version 2.1.17, application creation is not required at any point.

Google FCM Server Key deprecation

Google is deprecating the usage of FCM Server Keys by June 2024. Make sure that you use your Private Key JSON file for any WebRTC push configuration creation.

For existing users with push configurations based on the FCM Server Key, ensure that you have updated the configuration. Updating your WebRTC push configurations can be done via API as well as over the web interface.

Set up the RTC SDK [#set-up-the-rtc-sdk-getstartedwith-rtc-sdk]

You can find the (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

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

WebRTC reconnects

The Infobip RTC SDK can automatically reconnect any active call when a connection loss occurs, preventing calls from being prematurely terminated due to temporary network disruptions.

To use this feature, you must enable it in the SDK's callOptions. By default, auto-reconnect is disabled. When this feature is enabled, the default reconnection timeout is 60 seconds, after which the call is considered terminated if reconnection is not successful.

A set of SDK events—RECONNECTING, RECONNECTED, REMOTE_DISCONNECTED, REMOTE_RECONNECTED, PARTICIPANT_DISCONNECTED, and PARTICIPANT_RECONNECTED—allows you to detect when you or another participant becomes disconnected or reconnected. You can use these events to update your user interface, ensuring end users are informed about disconnection or reconnection status.

Media actions while being disconnected

While the call is disconnected, any action requiring an active Infobip connection (for example, enabling screen sharing, turning the camera on or off, muting, or unmuting) will be rejected and result in a media error.

For more information about WebRTC reconnects, see the tutorial section in the wiki of the Infobip SDK repositories.

WebRTC reconnects with Calls API

When using WebRTC with the Calls API, consider the following additional elements related to the WebRTC reconnect feature:

  • Two new Calls API events are introduced, to relate the state of auto-reconnects: CALL_DISCONNECTED and CALL_RECONNECTED
  • CALL_DISCONNECTED and CALL_RECONNECTED events only apply to call legs in ESTABLISHED state.
  • The call state will remain as ESTABLISHED until reconnection succeeds, or report the relevant final state in case of reconnection timeout expiry
  • All call actions, which would usually be received by a connected WebRTC call leg, are rejected asynchronously through the ERROR Calls event:

Showcase and demo [#showcase-and-demo-getstartedwith-rtc-sdk]

A developer showcase of the Infobip SDKs is available on Infobip GitHub:: Infobip-rtc-showcase. This repository implements a basic application demonstrating how to place and receive calls. It supports JavaScript with angular/jquery/angular, iOS, and Android.

A WebRTC demo application is available as a web, iOS, and Android application. Use your Infobip web interface credentials to log into these applications.

To use the WebRTC demo, ensure that your Infobip web interface user has:

WebRTC Diagnostic tool

Use the Infobip WebRTC Diagnostic tool to quickly verify your WebRTC environment without requiring any credentials or account setup. By running a series of tests, this tool helps ensure that the user experience is smooth and issue-free when using WebRTC-based communication services.

What does the Diagnostic tool verify?

The Diagnostic tool performs a range of automated tests to verify:

  • Browser's ability to access local audio and video devices: Confirms that the browser can properly interact with the user's microphone and camera.

  • Reachability to the Infobip WebRTC infrastructure (including the API layer): Ensures that the user's network allows stable communication with Infobip servers.

  • Available bandwidth between the WebRTC client and Infobip media servers: Measures the network conditions to confirm sufficient bandwidth for audio and video calls.

  • Ability to support and process audio calls: Checks that the user's setup can handle sending and receiving audio streams without issues.

  • Ability to support and process audio calls through TURN infrastructure: Ensures that audio communication can still function under restricted network conditions by routing media through TURN servers.

  • Ability to support and process video calls: Confirms the user's environment is capable of handling two-way video communication.

Diagnostic tool test results

Each test provides a clear pass or fail result, simplifying the identification of potential issues. For audio-related checks, the tool records a brief audio sample and plays it back through the WebRTC infrastructure to validate both input and output quality.

Bandwidth test failure:

  • Insufficient Internet connectivity: Verify that the user's internet connection is adequate outside of WebRTC. A standard speed test is sufficient.
  • Physical distance: If the external bandwidth test indicates sufficient bandwidth but our bandwidth test fails, consider the physical distance between the user and the selected Infobip data center. If the distance is significant (for example, intercontinental), retest with a closer Infobip data center.
  • Limited bandwidth: If the external bandwidth test indicates low bandwidth, advise the end-user to consult their local IT department for potential connectivity improvements.

Connectivity test failure:

  • Device or environment issues: Connectivity test failures typically indicate problems with the end-user's device or network environment (for example, corporate network restrictions).
  • Firewall restrictions: Instruct the end-user to review their firewall settings, ensuring that Infobip hosts are not blocked. See the list of IP addresses and ports used by Infobip WebRTC.
  • Corporate network restrictions: For users within a corporate network, consult with the IT department to add the necessary IP addresses and ports to the safelist. See the list of IP addresses and ports.

Session identification

Every test session is associated with a unique session ID, which is displayed at the top of the page. If further assistance or troubleshooting is required, you can provide this session ID to Infobip Support to help diagnose and resolve specific issues efficiently.

Advanced scenarios and WebRTC call manipulation

When you build a WebRTC use case using only the Infobip WebRTC SDK, you are limited to the capabilities provided by the SDK. If your use case requires more advanced call control, such as sending or receiving DTMF tones, playing media (audio files or text-to-speech), listing active calls, hanging up calls, modifying participant roles in Rooms or Conferences, or connecting to specific endpoint types, such as SIP endpoints, Viber or WhatsApp users, or a WebSocket server, you need to integrate both the WebRTC SDK and the Calls API.

In such cases, you must use a backend application that leverages the Calls API to orchestrate and manage call behavior. Without a Calls API-based back-end managing the calls, you cannot use API methods to control WebRTC calls or retrieve their live state.

Read more about Calls API and using Calls API with WebRTC

Was this page helpful?