Interface Options

By default, the SDK will use the unified-plan SDP format if the browser supports it. Unexpected behavior may happen if the RTCPeerConnection parameter uses an SDP format that is different than what the SDK uses.

For example, if the browser supports unified-plan and the RTCPeerConnection parameter uses plan-b by default, the SDK will use unified-plan which will cause conflicts with the usage of the RTCPeerConnection.

In order to avoid this issue, you need to explicitly set the SDP format that you want the SDK to use with the RTCPeerConnection via Device.ConnectOptions.rtcConfiguration for outgoing calls. Or Call.AcceptOptions.rtcConfiguration for incoming calls.

See the example below. Assuming the RTCPeerConnection you provided uses plan-b by default, the following code sets the SDP format to unified-plan instead.

// Outgoing calls
const call = await device.connect({
  rtcConfiguration: {
    sdpSemantics: 'unified-plan'
  }
  // Other options
});

// Incoming calls
device.on('incoming', call => {
  call.accept({
    rtcConfiguration: {
      sdpSemantics: 'unified-plan'
    }
    // Other options
  });
});

The default value of this option is false.

When this flag is enabled, some errors that would have been described with a generic error code, namely 53000 and 31005, are now described with a more precise error code. With this feature, the following errors now have their own error codes. Please see this page for more details about each error.

• Device Error Changes

example

const device = new Device(token, {
  enableImprovedSignalingErrorPrecision: true,
});
device.on('error', (deviceError) => {
  // the following table describes how deviceError will change with this feature flag
});

Device Error Name	Device Error Code with Feature Flag Enabled	Device Error Code with Feature Flag Disabled
GeneralErrors.ApplicationNotFoundError	31001	53000
GeneralErrors.ConnectionDeclinedError	31002	53000
GeneralErrors.ConnectionTimeoutError	31003	53000
MalformedRequestErrors.MissingParameterArrayError	31101	53000
MalformedRequestErrors.AuthorizationTokenMissingError	31102	53000
MalformedRequestErrors.MaxParameterLengthExceededError	31103	53000
MalformedRequestErrors.InvalidBridgeTokenError	31104	53000
MalformedRequestErrors.InvalidClientNameError	31105	53000
MalformedRequestErrors.ReconnectParameterInvalidError	31107	53000
SignatureValidationErrors.AccessTokenSignatureValidationFailed	31202	53000
AuthorizationErrors.NoValidAccountError	31203	53000
AuthorizationErrors.JWTTokenExpirationTooLongError	31207	53000
ClientErrors.NotFound	31404	53000
ClientErrors.TemporarilyUnavilable	31480	53000
ClientErrors.BusyHere	31486	53000
SIPServerErrors.Decline	31603	53000

• Call Error Changes

example

const device = new Device(token, {
  enableImprovedSignalingErrorPrecision: true,
});
const call = device.connect(...);
call.on('error', (callError) => {
  // the following table describes how callError will change with this feature flag
});

Call Error Name	Call Error Code with Feature Flag Enabled	Call Error Code with Feature Flag Disabled
GeneralErrors.ConnectionDeclinedError	31002	31005
AuthorizationErrors.InvalidJWTTokenError	31204	31005
AuthorizationErrors.JWTTokenExpiredError	31205	31005

Possible values include any of the following numbers:
0 = trace, 1 = debug, 2 = info, 3 = warn, 4 = error, 5 = silent

Or any of the following strings:
'trace', 'debug', 'info', 'warn', 'error', 'silent'
'TRACE', 'DEBUG', 'INFO', 'WARN', 'ERROR', 'SILENT'

Using a value of 30000 as an example: while a call exists, the Device will attempt to reconnect to the edge that the call was established on for approximately 30 seconds. After the next failure to connect, the Device will use edge-fallback.

This feature is opt-in, and will not work until a number greater than 0 is explicitly specified within the Device options.

Read more about edge fallback and signaling reconnection on the Edge Locations page.

Note: Setting this option to a value greater than zero means Twilio will not terminate the call until the timeout has expired. Please take this into consideration if your application contains webhooks that relies on call status callbacks.