Skip to main content
QuickBlox Video Calling API is built on top of WebRTC. It allows adding real-time video communication features into your app similar to Skype using API easily. The communication is happening between peers representing camera devices. There are two peer types: - Local peer is a device running the app right now. - Remote peer is an opponent device. Establishing real-time video communication between two peers involves 3 phases: - Signaling. At this phase, the peers’ local IPs and ports where they can be reached (ICE candidates) are exchanged as well as their media capabilities and session control messages. - Discovery. At this phase, the public IPs and ports at which endpoints can be reached are discovered by STUN/TURN server. - Establishing a connection. At this phase, the data are sent directly to each party of the communication process.
In order to start using Video Calling Module, you need to connect to QuickBlox Chat first. The signaling in the QuickBox WebRTC module is implemented over the XMPP protocol using QuickBlox Chat Module. It acts as a signaling transport for Video Calling API.
Please use this WebRTC Video Calling to make the Group Calls with 4 or fewer users. Because of Mesh architecture we use for multi-point where every participant sends and receives its media to all other participants, the current solution supports group calls with up to 4 people.
Visit Key Concepts page to learn the most important QuickBlox concepts.

Before you begin

  1. Register a QuickBlox account. This is a matter of a few minutes and you will be able to use this account to build your apps.
  2. Configure QuickBlox SDK for your app. Check out Setup page for more details.
  3. Create a user session to be able to use QuickBlox functionality. See Authentication page to learn how to do it.
  4. Connect to the Chat server to provide a signaling mechanism for Video Calling API. Follow our Chat page to learn about chat connection settings and configuration.

Initialize WebRTC

Before any interaction with QuickbloxWebRTC, you need to initialize it using the method below.

Logging

Logging is a powerful tool to see the exact flow of the QuickbloxWebRTC framework and analyze its decisions. By enabling logs you will be able to debug most issues, or perhaps help us analyze your problems. Check Enable logging section to learn how to enable logging.

Background mode

You can use our SDK in the background mode as well, however, this requires you to add a specific app permissions. Under the app build settings, open the Capabilities tab. In this tab, turn on Background Modes and set the Audio, AirPlay and Picture in Picture checkbox to set the audio background mode. add permission for Audio, AirPlay and Picture in Picture of iOS app If everything is correctly configured, iOS provides an indicator that your app is running in the background with an active audio session. This is seen as a red background of the status bar, as well as an additional bar indicating the name of the app holding the active audio session, in this case - your app.

Manage calls

In order to operate and receive calls you need to setup a client delegate. Your class must conform to the QBRTCClientDelegate protocol. Use the method below to subscribe. Learn more details about the event delegate configuration in the Event delegate section.

Initiate a call

To call other users, use QBRTCClient and QBRTCSession methods below.
After this, your opponents will receive one call request per five seconds for a duration of 45 seconds (you can configure these settings with QBRTCConfig).
The self.session refers to the current call session. Each particular audio/video call has a unique sessionID. This allows you to have more than one independent audio/video conference calls. If you want to increase the call timeout, you can increase it up to 60 seconds at maximum.
NoteBy default, setAnswerTimeInterval value is 45 seconds.
In case the opponent did not respond to your call within a specific timeout time, the method listed below will be called.

Accept a call

In order to accept a call, use the acceptCall() method below.
After this your opponent will receive an accept signal:

Reject a call

In order to reject a call, use the rejectCall() method below.
After this, your opponent will receive a reject signal.

End a call

To end a call, use the hangUp() method below.
After this, your opponent will receive a hangup signal.

Local video view

To show your local video track from a camera, you should create UIView on the storyboard and then use the following code.

Remote video view

To show video views with streams that you have received from your opponents, you should create QBRTCRemoteVideoView views on the storyboard and then use the following code.
You can always get remote video tracks for a specific user ID in the call using the below-specified QBCallSession methods (assuming that they are existent).

Event delegate

To process events such as incoming call, call reject, hang up, etc. you need to set up the event listener. The event listener processes various events that happen with the call session or peer connection in your app. Using the callbacks provided by the event delegate, you can implement and execute the event-related processing code. For example, the session(_:acceptedByUser:userInfo:) method of the QBRTCClientDelegate is called when your call has been accepted by the user. This callback receives information about the call session, user ID who accepted the call and additional key-value data about the user. QuickBlox iOS SDK persistently interacts with the server via XMPP connection that works as a signaling transport for establishing a call between two or more peers. It receives the callbacks of the asynchronous events which happen with the call and peer connection. This allows you to track these events and build your own video calling features around them. To track call session events, you should use QBRTCSessionEventsCallback listener. The supported event callbacks for a call session and peer connection are listed in the table below. The following code lists all supported event callbacks for the call session and peer connection along with their parameters as well as shows how to add the listener.
Go to the Resources section to see a sequence diagram for a regular call workflow.

Call session states

Each call session has its own state. You can always access the current state by simply using the QBRTCSession property.
You can also receive a live-time call session state.
The following table lists all supported call session states:

Call reconnection states

NoteSince version 2.8.0 Quickblox-WebRTC SDK supports reconnection functional.
You can receive a live-time call reconnection state.
Doesn’t invoke in conference.
The following table lists all supported call reconnection states: You can also increase disconnect timeout. By default the time is set to 30 seconds. Minimal time is 10 seconds. It’s time while users can have availability to reconnect.

Peer connection states

Each peer connection has its own state. By default, you can access that state by calling this method from QBRTCSession.
You can also receive a real-time connection state.
The following table lists all supported peer connection states:

Resources

A regular call workflow.
iOS SDK Initiate, Accept, Hang Up