Twilio Changelog

This major release of Twilio Voice SDK now uses WebRTC 83. With this release users will hear audio much sooner after the [TVOCallDelegate callDidConnect:] callback than in prior releases. This upgrade ensures that when [TVOCallDelegate callDidConnect:] is raised to the developer the media connection has been fully established. Additionally this release improves the interoperability of the SDK with Swift. Lastly, the MOS calculation algorithm has been updated to make it monotonically decreasing with increasing jitter and packets-lost-fraction values over a range of rtt values.

To migrate from 5.X to 6.X please see the migration guide.

To learn more about this release on our changelog.

Introducing the API for Elastic SIP Trunking Call Transfer (SIP Refer) feature. This feature enables you to move an active call from one endpoint to another. Twilio's Elastic SIP Trunking product supports "blind" call transfers. This allows you to configure SIP Refer on a Trunk using the API.

For details, please check our Elastic SIP Trunking API for Call Transfer via SIP REFER documentation.

As a side note, you can also configure Elastic SIP Trunking Call Transfer (SIP Refer) feature through Twilio console. Details of console configuration can be found here.

With this release developers can pass custom parameters when dialing Twilio Client using Twilio Voice REST API. You can build personalized application experiences for end users by displaying valuable contextual details about the incoming call. For example, you can pass the customer name, type, or product of interest when dialing Twilio Client, and display to the agent.

The custom parameters can be specified as a query string in the ‘To’ parameter of the Create Call Resource and delivered via the Twilio Voice Client.

Learn more about how to share custom information between your applications

For Editions customers, we are introducing a more flexible way to view the Audit Event data in the Twilio Console. This allows viewing by user and filtering the event data.
The list of events now tracked by Audit Events includes new event types, such as console logins. The new event types are only visible in the Twilio console in Audit Event Insights are documented with the other Audit Event data: https://www.twilio.com/docs/usage/monitor-events.
These changes do not impact the Audit Event API. New event types are not available yet in the Audit Event/Monitor Event API

We have updated TaskRouter’s error and warning messages to improve clarity and troubleshooting.

CVE-2020-24655 - A race condition in the Twilio Authy 2-Factor Authentication Application allowed a user to potentially approve/deny an access request prior to unlocking the application with a pin on older Android devices, effectively bypassing the PIN requirement. This issue has been fixed as part of the 24.3.7 Release of the Twilio Authy App. Other operating systems (iOS, MacOS, Linux and Windows) are not affected by this vulnerability.

See 24.3.7 release details here.

A new Deactivations API for US Messaging is now available. This API returns you a file that contains phone numbers that have been removed from the US Carriers on the specified date. This allows you to automatically keep your subscriber lists clean by removing deactivated phone numbers from your campaigns.

For more information, please take a look at our Handling Deactivated Phone Numbers FAQ and our Deactivations API Documentation.

When you send a verification attempt via SMS One-Time-Passcode, you can now view the SMS's Delivery Status & Error Codes in your Twilio Console. Navigate to Verify > Services > Logs as shown in the example screenshot below. This helps you to troubleshoot non-delivery of SMS.

Super SIMs can now be put into a new state called ready. Ready state lets your Super SIMs connect to cellular networks without incurring a monthly subscription fee until one of the following 3 conditions are met:

• The Super SIM has been in ready for 90 days
• The Super SIM has used 250 KB of data
• The Super SIM has sent or received 5 SMS Commands

Use ready state to enable and test your device’s connectivity, without incurring monthly fees, before it’s sent to your customer or deployed into the field.

Once any of those 3 conditions are met, the Super SIM’s status will automatically update to active, at which point, the monthly subscription fee will start being charged.

Super SIM Usage Records can now be filtered to show usage incurred on a single Super SIM, Fleet, Network (e.g. AT&T US, Telstra) or within a single country (e.g. United States, Australia). You can combine those filters with others to do complex filtering such as getting the usage for a single SIM on a single Network, or all SIMs within a Fleet.

You can also now group Usage Records around a resource type (e.g. Super SIMs, Fleets, Networks, or Countries) within the response data. For example, if you group your Usage Records by Super SIM, each record will contain the aggregated usage per Super SIM over the requested period. You can use this to efficiently pull usage for large fleets without having to make separate API calls for each resource. You can combine groupings with different filters to make complex requests like:

• How much data did each of my Super SIMs use within a particular Fleet yesterday?
• How much data did each of my Super SIMs use in France in the last 30 days?
• How much data did my Super SIMs use on each Network in Argentina last week?
• How much data did each of my Fleets use on AT&T in the United States in the last 3 days?