ConnectyCube solutions for video calling and difference in approaches

ConnectyCube Video Calling API is built on top of WebRTC technology and allows adding audio and video calling features into your native iOS, Android and hybrid mobile and web JS applications.

There are two approaches for WebRTC audio/video calls implementation in ConnectyCube:

Client-side (P2P (Mesh) scheme) 

WebRTC technology sets peer-to-peer connection between all callers, which completely excludes ConnectyCube server from participating in passing media streams during the call.

In multi-person conversation, WebRTC sets so called “full-mesh connection” with multiple P2P connections set simultaneously.
The only role ConnectyCube server plays in this case is establishing the connection between the participants before the call (signaling).

Multiparty Video calls (SFU) server-side implementation.

This solution relies on the same WebRTC standards, but it implies deploying a separate media server called SFU (Selective Forwarding Unit) to realize stable conversation with more participants.
SFU server processes media stream during video calls.

Pros and Cons

Signaling

Signaling takes place before audio/video call is established between the users.

There is a difference in approach used by video solutions to give a call:

Standard WebRTC solution

Standard WebRTC solution uses signaling messages to initiate, accept, reject and hang up a call.
All video chat signaling messages have type="headline" and an extra parameter <moduleIdentifier>...</moduleIdentifier>. So you can detect the video chat signaling message by these two parameters.
Check this guide for more details.

SFU solution

With SFU solution all users are joining the room for the call and a notification about incoming call is not sent by default.
However, you can use system messages to give a call with SFU solution similarly to the standard WebRTC solution as follows:

a) On UI you need to set system notifications to be sent for incoming calls. For example, Android system notifications can be sent as follows:

ConnectycubeChatMessage systemMessage = new ConnectycubeChatMessage();
systemMessage.setRecipientId(58672);
systemMessage.setProperty("param1", "value1");
systemMessage.setProperty("param2", "value2");
systemMessage.setBody("some text");
try {
systemMessagesManager.sendSystemMessage(systemMessage);
} catch (SmackException.NotConnectedException e) {
e.printStackTrace();
}

b) You need also to set a listener to listen to such notifications on recipient’s side. Here is an example from Android documentation:

SystemMessagesManager systemMessagesManager = ConnectycubeChatService.getInstance().getSystemMessagesManager();
SystemMessageListener systemMessageListener = new SystemMessageListener() {
@Override
public void processMessage(ConnectycubeChatMessage message) {
}
@Override
public void processError(ChatException exception, ConnectycubeChatMessage message) {
}
};
systemMessagesManager.addSystemMessageListener(systemMessageListener);

c) Upon receiving such system notification you can set a pop-up window about incoming call to appear with accept/reject buttons.

d) Once Accept button is clicked the user should join video room. Check the following example from Android documentation:

ConferenceRole conferenceRole = asListenerRole ? ConferenceRole.LISTENER : ConferenceRole.PUBLISHER;
currentSession.joinDialog(dialogID, conferenceRole, new ConferenceEntityCallback<ArrayList> {
...
});

Note:
If you subscribe as listener, you’ll get audio/video streams from publishers, but will not publish your own video and audio streams.

e) For rejecting a call you can set the pop-up window to be closed on UI without joining the room.
If you need, you can add a system notification to be sent to the call initiator notifying him that the incoming call was rejected.

Other differences

Adding participants:

Standard WebRTC solution

Standard WebRTC peer-to-peer solution allows adding participants at the call initiation only due to limitations of WebRTC mesh scheme. Once the call connection is established, there is no possibility to add/remove participants without interrupting the call.

SFU solution

SFU solution allows adding/removing participants during ongoing call. In order to join the call a user should be listed in the Occupants_ID list of a room/chat. Here you can find an example for joining video room on Android.

Re-joining an ongoing call:

Standard WebRTC solution

Standard WebRTC peer-to-peer solution does not allow re-joining due to limitations of this approach. In case one of the users disconnects, the call stops and it is necessary to establish the call again.

SFU solution

SFU solution allows re-joining the ongoing call in case the user has lost connection due to temporary internet connectivity issues or reloaded the page, for example. You can implement this function as follows (example from Web):

Option 1:

a) Check that the call is still in progress:

client.listOnlineParticipants(chatDialogId, {
success: function(participants){
},
error: function(error){
}
});


b) Then check that you are not in the call:

client.currentDialogId

Note:
If it returns null, then there is no dialog.
Such check should work well if we have re-loaded the page.

c) If the call is on and the user is not in that call, you can show re-join button on UI.

Note:
After losing connection UserID exists on server about 30 sec, so after a while you can join the room successfully again.

Option 2:

Also you can set re-join button to be shown if error about internet connection being lost is triggered in the app.

Such case you can try handling via iceState callback and if state is closed for all users and you, this means that everything is disconnected.

In that case you need to close the call and initialize it again programmatically.

And you need to show Re-join button in such case.

Audio/video recording:

Standard WebRTC solution

Standard WebRTC approach does not allow using server-side recording since server does not participate in passing media streams. So, the only way is to use client-side recording (recording is saved on the local device only). Here is an example for iOS client-side audio/video recording.

SFU solution

SFU solution allows using server-side recording. ConnectyCube provides this option together with SFU solution. In this case the recordings are saved on the server.

Have any questions?

Feel free to contact us.