WebRTC to Phone calls migration guide

Note

Before you start with the migration, you need to upgrade the infobip-rtc dependency to version 2.1.0 or newer, which can be pulled from the Maven Central repository, and placed inside Your build.gradle file.

---

PhoneCall callPhone(CallPhoneRequest callPhoneRequest, PhoneCallOptions phoneCallOptions)

If you previously used the callPhoneNumber method, start by migrating to the newly added callPhone method. Just like before, this method is used to establish calls between WebRTC and phone endpoints.

Arguments

The first argument changed from CallRequest to the more specific CallPhoneRequest. Also, the second, optional, argument changed from CallPhoneNumberOptions to PhoneCallOptions.

If you do not wish to use PhoneCallOptions argument in callPhone method, you can omit the second argument by using:

PhoneCall callPhone(CallPhoneRequest callPhoneRequest)

Returns

The return type has changed to PhoneCall, and should be used instead of the previously available OutgoingCall. Consult the documentation of the PhoneCall to get familiar with the newly added methods that can be used with it.

Example

• Initiate a Phone call in SDK 1.x

String token = obtainToken();
CallRequest callRequest = new CallRequest(token, getApplicationContext(), "41793026727", new DefaultCallEventListener());
CallPhoneNumberOptions callPhoneNumberOptions = CallPhoneNumberOptions.builder().from("33712345678").build();

OutgoingCall call = InfobipRTC.callPhoneNumber(callRequest, callPhoneNumberOptions);

• Initiate a Phone call in SDK 2.0

String token = obtainToken();
InfobipRTC infobipRTC = InfobipRTC.getInstance();

CallPhoneRequest callPhoneRequest = new CallPhoneRequest(token, getApplicationContext(), "41793026727", new DefaultPhoneCallEventListener());
PhoneCallOptions phoneCallOptions = PhoneCallOptions.builder().from("33712345678").build();

PhoneCall phoneCall = infobipRTC.callPhone(callPhoneRequest, phoneCallOptions);

PhoneCall

Deprecated Call and newly added PhoneCall support a similar set of methods, but there are some notable changes:

• options method now returns the PhoneCallOptions instead of the previous CallPhoneNumberOptions
• If you previously configured RecordingOptions on your individual calls, please note that this not supported yet, when migrating to RTC SDK 2.0 (for more details, consult Recording section of the migration guide),
• source and destination methods now return the Endpoint object.
• setEventListener method's argument type has been changed to PhoneCallEventListener, as opposed to the previous CallEventListener. Also, the getEventListener method now returns PhoneCallEventListener, instead of the previous CallEventListener.
• A new counterpart method has been introduced to make accessing the remote endpoint easier in your own application. It returns an Endpoint object.

PhoneCallEventListener

There are several breaking changes concerning the configuration of the event handlers that respond to the received events. Breaking changes in context to events are caused either by an event or its payload being changed, or a new event being introduced.

CallRingingEvent

There are no changes to the payload of the CallRingingEvent

CallEarlyMediaEvent

There are no changes to the payload of the CallEarlyMediaEvent

CallEstablishedEvent

The payload of the CallEstablishedEvent has changed. Event though the local and remote video media that was previously passed through CallEstablishedEvent was never used in the context of phone calls, it is important to note that this event's payload is now empty.

CallHangupEvent

There are no changes to the payload of the CallHangupEvent

ErrorEvent

ErrorEvent was introduced instead of the previous CallErrorEvent, and you should now use getErrorCode method instead of the previous getReason method. Note that the return type of these methods stayed the same, they both provide you with an appropriate ErrorCode

When using SDK 2.0, you may encounter Calls API error codes and WebRTC error codes.

Note that ErrorEvent event is now emitted only when a call encounters an error which does not hang up the call, unlike the case with receiving error events before.

Recording

If you already have Recording add-on enabled on account level, you can set the recording preferences under Channels & Numbers > WebRTC > Recording or control it via ALWAYS, ON_DEMAND and DISABLED recording flag when generating the token for the session.

When ON_DEMAND flag is used, RecordingOptions should be passed via PhoneCallOptions. Note that RecordingOptions are different from the previously available RecordingOptions (1.x).

To determine the expected behaviour when combining any of these three elements, consult the Outcome of the recording table.

To access recording files, use the available API or Portal, passing call identifier as the callId parameter.