Common Twilio Programmable Voice SDK Error Codes and Debugging Help

Two colleagues debugging software
September 27, 2022
Written by
Twilion
Reviewed by
Twilion
Twilion

Ahoy Builders! When you decide to start building Programmable Voice applications on top of Twilio’s SDKs and begin playing with your own ideas and use cases, there are some more common error codes which I would like to bring to your attention. You will not necessarily encounter all of them, but when developing your application there are various factors at play so being familiar with some of the more common error codes we see in Twilio support, could do you no harm.

In this post, I’ll cover some common Twilio Programmable Voice error codes. We’ll look at the error number, a brief description of the issue, and some hints about how to fix the issue. Then we’ll discuss logging levels and debugging in your application, and how to contact us for more support. Let’s dive in!

Twilio Voice apps: common error codes

Error 52134

More info on Error 52134

This is one of the more common errors we see in support, and relates to the iOS push notification certificate that is supplied by your application to Apple. To send notifications to iOS devices, Twilio will make use of the APN API (Apple) which lets you remotely send notification requests to your devices. APNs then convey notifications to your app on iOS, which is then used to reflect an incoming phone call.

For iOS, there are two types of Apple push notifications to be aware of (APNs): the sandbox type and the production type. You should see these present inside your Apple Developer console.

The sandbox type of push notification is used mainly for testing purposes, and the production type uses a certificate within your live environment. What causes people to run into issues within the SDK, however, is mixing up the two certificates. For example, if you use a production certificate in a sandbox environment you will encounter this error (and vice versa). When creating your certificate, you must be very careful and specify which environment you are using, and then use that certificate only in the appropriate environment.

Usually we will see the following returned from Apple when this occurs:

BadDeviceToken:  Error "The specified device token is either malformed or not valid for the given environment"  

followed by a HTTP 400 status.

According to the Apple Documentation this means: “The specified device token is invalid. Verify that the request contains a valid token and that the token matches the environment.”.

Error 52003

More info on error 52003

Similarly to Error 52134, this is also related to a mismatch – this time of credentials. A Credential resource represents one credential record for a specific push notifications channel.

Twilio supports APNS, FCM, and GCM push notification channels. Each push notification channel vendor issues its own Credentials and they can vary between vendors. This resource allows you to save the Credentials that should be used for push notifications to a specific channel.

You can learn more about provisioning vendor-specific credentials in these  topics.

You can also manage the Credentials in your Twilio Console when you are logged in.

These credentials are bundled together with your voice application SID to form your access token.

Quite often in Support, we see developers who create a credential for an iOS application, and mistakenly include the Android or FCM credentials instead of the APN during token generation. This will not cause issues straight away but when you go to place a call you will notice the iOS device will not ring. Simultaneously, you should also see the Twilio console debugger throw the error above.

The Twilio Programmable Voice iOS SDK requires Apple’s VoIP Service certificate so that Twilio can send VoIP Push Notifications to your mobile client on your behalf. When generating your access token, you should always double check which credential you are supplying. Once the token is generated, this can not be changed.

If you encounter this error within your own custom application, we recommend revising the configuration of your token and credentials. Often enough, following the process again and correcting your credential usually solves the issue.

Support

While developing your application, you may need some further assistance with certain aspects or issues you have encountered. This is where Twilio Support can assist you. We would be more than happy to investigate any issues you have run into, and will always do our best to help.

To begin, Users who are logged into the Twilio Console can request support assistance from the Submit a Ticket page in Console.

Submit a ticket to Twilio support

When logging a ticket with our Support staff, please make sure to always include a detailed description of your issue as well as include any examples you can.

If you are having issues with calls, a call example from within the last 72 hours would be sufficient. You can send us these examples in the form of a Call SID which you can find inside your Twilio accounts call logs. If you could also share any notification SIDs or error codes you experienced, that would also help us debug your issue.

Logging

If you are having issues with how your application is operating, we highly recommend debug level logging and suggest enabling it if you have not already done so.

When using the Twilio Voice JavaScript SDK Quickstart, debugging is enabled by default. To see this in the code, open your file Quickstart.js, and find the text “loglevel: 1”, on Line 68, under the Twilio.Device function.

Your code should look something like this:

 // Instantiate a new Twilio.Device
  function intitializeDevice() {
    logDiv.classList.remove("hide");
    log("Initializing device");
    device = new Twilio.Device(token, {
      logLevel:1,

Once this is enabled, when you run or execute your application, you should see a breakdown of additional logging information about your session within the browser console.

Web console logging for the Twilio Programmable Voice SDK

This can be useful in debugging your application as you can see what is occurring throughout your application, as it occurs. We also have an article on JS logging for your reference.

Furthermore, we offer a Preflight API which represents a test call to Twilio which provides information to help troubleshoot call-related issues when using the Voice JavaScript SDK.

To learn more please see : Twilio PreFlight API

In general, when raising a ticket with Support it is important to always have the most information available. Supplying your Application logs to us will greatly reduce the resolution time of your ticket and allow our agents to investigate faster.

For Android and iOS, you can enable logging as seen below:

Android (Java):

//Set Log level
Voice.setLogLevel(LogLevel.DEBUG); 

iOS (swift):

TwilioVoiceSdk.logLevel = .debug

Please save your log files as .TXT when sending to support. For security reasons, please refrain from sending .ZIP files.

More assistance with Twilio Voice apps

I hope you found this information useful. If you have any further questions or concerns please feel free to contact us, we would be more than happy to assist!


David Dooley is a Developer Support Engineer at Twilio based out of Dublin. He’s very passionate about helping our customers achieve success with Twilio and loves to work on complex problems. He also enjoys educating others, hence this blog post. In his spare time he likes to dabble in crypto and is a strong believer in blockchain technology. He can be reached at ddooley [at] twilio.com.