+
+
Overview
+
The TVOCall
class represents a signaling and media session between the host device and Twilio infrastructure.
+ Calls can represent an outbound call initiated from the SDK via [TwilioVoiceSDK connectWithAccessToken:delegate:]
+ or an incoming call accepted via a [TVOCallInvite acceptWithDelegate:]
. Devices that initiate an outbound
+ call represent the caller and devices that receive a TVOCallInvite
represent the callee.
+
+
The lifecycle of a call differs for the caller and the callee. Making or accepting a call requires a TVOCallDelegate
+ which receives call state changes defined in TVOCallState
. The TVOCallState
can be obtained at any time from
+ the state
property of TVOCall
.
+
+
The caller callback behavior is affected by the answerOnBridge
flag provided in the Dial
verb of your TwiML application
+ associated with this client. If the answerOnBridge
flag is false
, which is the default, the [TVOCallDelegate callDidConnect:]
+ callback will be emitted immediately after [TVOCallDelegate callDidStartRinging:]
. If the answerOnBridge
flag
+ is true
this will cause the call to emit the [TVOCallDelegate callDidConnect:]
callback only until the call
+ is answered.
+ See Answer on Bridge documentation for
+ more details on how to use it with the Dial
TwiML verb.
+
+
The following table provides expected call sequences for common scenarios from the perspective of the caller:
+
+
+
+
The following table provides expected call sequences for common scenarios from the callee perspective:
+
+
+
+
It is important to call the [TVOCall disconnect]
method to terminate the call. Not calling [TVOCall disconnect]
+ results in leaked native resources and may lead to an out-of-memory crash. If the call is disconnected by the
+ caller, callee, or Twilio, the SDK will automatically free native resources. However, [TVOCall disconnect]
is
+ an idempotent operation so it is best to call this method when you are certain your application no longer needs
+ the object.
+
+
It is strongly recommended that <TVOCall>
instances are created and accessed from a single dispatch queue.
+ Accessing a <TVOCall>
instance from multiple queues may cause synchronization problems. TVOCallDelegate
methods
+ are called on the main dispatch queue by default or on the delegateQueue
provided to TVOConnectOptions
+ or TVOAcceptOptions
upon initiating or accepting a call.
+
+
An ongoing call will automatically switch to a more preferred network type if one becomes available.
+ The following are the network types listed in preferred order: ETHERNET
, LOOPBACK
, WIFI
, VPN
, and CELLULAR
.
+ For example, if a WIFI
network becomes available whilst in a call that is using CELLULAR
data, the call will automatically
+ switch to using the WIFI
network.
+
+
Media and signaling reconnections are handled independently. As a result, it is possible that a single network change
+ event produces consecutive [TVOCallDelegate call:isReconnectingWithError:]
and [TVOCallDelegate callDidReconnect:]
+ callbacks. For example, a network change may result in the following callback sequence.
+
+
+-
[TVOCallDelegate call:isReconnectingWithError:]
with error.code
TVOErrorSignalingConnectionDisconnectedError
.
+-
[TVOCallDelegate callDidReconnect:]
.
+-
[TVOCallDelegate call:isReconnectingWithError:]
with error.code
TVOErrorMediaConnectionError
.
+-
[TVOCallDelegate callDidReconnect:]
.
+
+
+
+
Note that the SDK will always raise a [TVOCallDelegate call:isReconnectingWithError:]
callback followed by a
+ [TVOCallDelegate callDidReconnect:]
callback when reconnection is successful.
+
+
During the reconnecting state operations such as [TVOCall setOnHold:]
, [TVOCall setMuted:]
, [TVOCall sendDigits:]
will result in
+ undefined behavior. When building applications, the recommended practice is to show a UI update when the Call enters reconnecting
+ regardless of the cause, and then clear the UI update once the call has reconnected or disconnected.
+
+
Insights
+
+
The following connection events are reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ connection | muted | Audio input of the call is muted by calling [TVOCall setMuted:] with YES . | 3.0.0-beta2 |
+
+
+ connection | unmuted | Audio input of the call is unmuted by calling [TVOCall setMuted:] with NO . | 3.0.0-beta2 |
+
+
+ connection | accepted-by-remote | Server returns an answer to the Client’s offer over the signaling channel. | 3.0.0-beta2 |
+
+
+ connection | ringing | Call state transitions to TVOCallStateRinging . | 3.0.0-beta2 |
+
+
+ connection | connected | Call state transitions to TVOCallStateConnected . | 3.0.0-beta2 |
+
+
+ connection | disconnect-called | [TVOCall disconnect] is called. | 3.0.0-beta2 |
+
+
+ connection | disconnected-by-local | Call disconnected as a result of calling [TVOCall disconnect] . Call transitions to TVOCallStateDisconnected . | 3.0.0-beta2 |
+
+
+ connection | disconnected-by-remote | Call is disconnected by the remote. Call transitions to TVOCallStateDisconnected . | 3.0.0-beta2 |
+
+
+ connection | hold | Call is on hold by calling [TVOCall setOnHold:] with YES . | 3.0.0-beta2 |
+
+
+ connection | unhold | Call is on unhold by calling [TVOCall setOnHold:] with NO . | 3.0.0-beta2 |
+
+
+ connection | error | Error description. Call state transitions to TVOCallStateDisconnected . | 3.0.0-beta2 |
+
+
+ connection | reconnecting | The Call is attempting to recover from a signaling or media connection interruption | 3.0.0-beta3 |
+
+
+ connection | reconnected | The Call has recovered from a signaling or media connection interruption | 3.0.0-beta3 |
+
+
+
+
The following peer connection state events are reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ pc-connection-state | new | The PeerConnection ice connection state changed to “new”. | 6.0.0 |
+
+
+ pc-connection-state | connecting | The PeerConnection state changed to “connecting”. | 6.0.0 |
+
+
+ pc-connection-state | connected | The PeerConnection state changed to “connected”. | 6.0.0 |
+
+
+ pc-connection-state | disconnected | The PeerConnection state changed to “disconnected”. | 6.0.0 |
+
+
+ pc-connection-state | failed | The PeerConnection state changed to “failed”. | 6.0.0 |
+
+
+ pc-connection-state | closed | The PeerConnection state changed to “closed”. | 6.0.0 |
+
+
+
+
The following ICE candidate event is reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ ice-candidate | ice-candidate | ICE candidate events are raised when OnIceCandidate is called on the PeerConnection | 4.1.0 |
+
+
+ ice-candidate | selected-ice-candidate-pair | The active local ICE candidate and remote ICE candidate | 6.0.0 |
+
+
+
+
The following ICE connection state events are reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ ice-connection-state | new | The PeerConnection ice connection state changed to “new”. | 3.0.0-beta3 |
+
+
+ ice-connection-state | checking | The PeerConnection ice connection state changed to “checking”. | 3.0.0-beta3 |
+
+
+ ice-connection-state | connected | The PeerConnection ice connection state changed to “connected”. | 3.0.0-beta3 |
+
+
+ ice-connection-state | completed | The PeerConnection ice connection state changed to “completed”. | 3.0.0-beta3 |
+
+
+ ice-connection-state | closed | The PeerConnection ice connection state changed to “closed”. | 3.0.0-beta3 |
+
+
+ ice-connection-state | disconnected | The PeerConnection ice connection state changed to “disconnected”. | 3.0.0-beta3 |
+
+
+ ice-connection-state | failed | The PeerConnection ice connection state changed to “failed”. | 3.0.0-beta3 |
+
+
+
+
The following ICE gathering state events are reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ ice-gathering-state | new | The PeerConnection ice gathering state changed to “new”. | 3.0.0-beta3 |
+
+
+ ice-gathering-state | gathering | The PeerConnection ice gathering state changed to “checking”. | 3.0.0-beta3 |
+
+
+ ice-gathering-state | complete | The PeerConnection ice gathering state changed to “connected”. | 3.0.0-beta3 |
+
+
+
+
The following signaling state events are reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ signaling-state | stable | The PeerConnection signaling state changed to “stable”. | 3.0.0-beta3 |
+
+
+ signaling-state | have-local-offer | The PeerConnection signaling state changed to “have-local-offer”. | 3.0.0-beta3 |
+
+
+ signaling-state | have-remote-offers | The PeerConnection signaling state changed to “have-remote-offers”. | 3.0.0-beta3 |
+
+
+ signaling-state | have-local-pranswer | The PeerConnection signaling state changed to “have-local-pranswer”. | 3.0.0-beta3 |
+
+
+ signaling-state | have-remote-pranswer | The PeerConnection signaling state changed to “have-remote-pranswer”. | 3.0.0-beta3 |
+
+
+ signaling-state | closed | The PeerConnection signaling state changed to “closed”. | 3.0.0-beta3 |
+
+
+
+
The following network quality warning and network quality warning cleared events are reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ network-quality-warning-raised | high-jitter | Three out of last five jitter samples exceed 30 ms. | 3.0.0-beta3 |
+
+
+ network-quality-warning-cleared | high-jitter | high-jitter warning cleared if last five jitter samples are less than 30 ms. | 3.0.0-beta3 |
+
+
+ network-quality-warning-raised | low-mos | Three out of last five mos samples are lower than 3.5. | 3.0.0-beta3 |
+
+
+ network-quality-warning-cleared | low-mos | low-mos cleared if last five mos samples are higher than 3.5. | 3.0.0-beta3 |
+
+
+ network-quality-warning-raised | high-packets-lost-fraction | The average packet loss > 3% in last 7 samples. | 3.0.0-beta3 |
+
+
+ network-quality-warning-cleared | high-packets-lost-fraction | high-packets-lost-fraction cleared if average packet loss <= 1% in last 7 samples. | 3.0.0-beta3 |
+
+
+ network-quality-warning-raised | high-rtt | Three out of last five RTT samples show greater than 400 ms. | 3.0.0-beta3 |
+
+
+ network-quality-warning-cleared | high-rtt | high-rtt warning cleared if last five RTT samples are lower than 400 ms. | 3.0.0-beta3 |
+
+
+
+
The following audio level warning and audio level warning cleared events are reported to Insights during a call
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ audio-level-warning-raised | constant-audio-input-level | The standard deviation of audio input levels for last 10 samples is less than or equals 1% of the maximum possible audio input level (32767) i.e. 327.67 and the call is not in the muted state | 3.0.0-beta3 |
+
+
+ audio-level-warning-cleared | constant-audio-input-level | constant-audio-input-level warning cleared if the standard deviation of audio input levels for last 10 samples is greater than 3% of the maximum possible audio input level. | 3.0.0-beta3 |
+
+
+
+
The following feedback events are reported to Insights during a call:
+
+
+
+ Group Name | Event Name | Description | Since version |
+
+
+ feedback | received | [TVOCall postFeedback:issue:] is called if the score is not TVOCallFeedbackScoreNotReported or the issue type is not TVOCallFeedbackIssueNotReported . | 3.0.0-beta3 |
+
+
+ feedback | received-none | [TVOCall postFeedback:issue:] is called if the score is TVOCallFeedbackScoreNotReported and the issue type is TVOCallFeedbackIssueNotReported . | 3.0.0-beta3 |
+
+
+
+
+
+
+
+
+