WebRTC to Phone calls migration guide

Note

Before you start with the migration, you need to upgrade the InfobipRTC dependency to version 2.1.0 or newer. As before, we publish it on CocoaPods and Carthage.

callPhone(_ callPhoneRequest: CallPhoneRequest, _ phoneCallOptions: PhoneCallOptions) throws -> PhoneCall

If you previously used the callPhoneNumber method, start by migrating to the newly added callPhone method. Same as 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.

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

let token = obtainToken()
let callRequest = CallRequest(token, destination: "41793026727", callDelegate: self)
let callPhoneNumberOptions = CallPhoneNumberOptions(from: "33712345678")
let call = InfobipRTC.callPhoneNumber(callRequest, callPhoneNumberOptions)

• Initiate a phone call in SDK 2.0

let token = obtainToken()
let infobipRTC: InfobipRTC = getInfobipRTCInstance()

let callPhoneRequest = CallPhoneRequest(token, destination: "41793026727", phoneCallEventListener: self)
let phoneCallOptions = PhoneCallOptions(from: "33712345678")
let call = 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 yet not supported 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 instead of previous RTCUser
• delegate field was renamed to phoneCallEventListener and it configures PhoneCallEventListener instead of previous CallDelegate.
• A new counterpart method has been introduced to make accessing the remote endpoint easier in your own application. It returns an Endpoint object.
• correlationId method has been removed from the new PhoneCall
• recordingOptions method has been removed from the new PhoneCall

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 it's 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

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 errorCode instead of the previous reason property. Note that the type of these fields 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.