Twilio Changelog

To correctly end an Execution for an inbound Voice call, Studio needs the “hangup” event from the Voice status callback. When that event is not received, the Execution may be left open (or “stuck”) indefinitely.

To address this, Studio now automatically configures the status callback shortly after configuring your phone number for Studio. This ensures the final “hangup” event is always received. With this release, manually setting the status callback is no longer necessary and helps avoid “stuck” Executions for inbound calls.

To learn more, review our knowledge base article.

Twilio Elastic SIP Trunking now perform SHAKEN/STIR verification on incoming calls to your Twilio local phone numbers. It can be used to display a trust indicator or to make a routing decision, such as bypassing a voice captcha or IVR and directing the call to an end user.

A verified call that has been given the highest attestation under SHAKEN/STIR means that the carrier that originated the call both (1) knows the identity of the caller, and (2) knows the caller has the right to use the phone number as the caller ID.

There is a new header called X-Twilio-VerStat with the verification result. The new header is only present for incoming calls with SHAKEN PASSporT identity headers. Today, the United States is the only country where carriers instrument a call authentication framework like SHAKEN/STIR.

Twilio Programmable Voice now perform SHAKEN/STIR verification on incoming calls to your Twilio local phone numbers. It can be used to display a trust indicator or to make a routing decision, such as bypassing a voice captcha or IVR and directing the call to an end user.

A verified call that has been given the highest attestation under SHAKEN/STIR means that the carrier that originated the call both (1) knows the identity of the caller, and (2) knows the caller has the right to use the phone number as the caller ID.

The request webhook presents the StirVerstat parameter with the verification result. The new parameter is only present for incoming calls with SHAKEN PASSporT identity headers. Today, the United States is the only country where carriers instrument a call authentication framework like SHAKEN/STIR.

The following Programmable Video SDK versions will End of Life on September 8th, 2021 for all customers:

• Android - 4.x and below
• iOS - 2.x and below
• Javascript - 1.x

TThe above versions of the Video SDKs utilize infrastructure that is no longer considered reliable for customers. Therefore, they are currently not supported, and as of 5:00pm PT on September 8th, 2021, they will cease to function for all customers.

We are consistently updating the Twilio Video SDKs in order to provide the best possible experience for you. Upgrading to the latest SDK version will not only ensure you benefit from various performance enhancements and bug fixes, but will also allow you to take advantage of new capabilities such as the Track Priority API, Network Bandwidth API, and much more.

If you are still using one of these SDK versions and wish to continue using Twilio Programmable Video, you must upgrade your SDK to a supported version. If you are using a mobile SDK, please ensure your apps have been released and your end-users have updated before the End of Life date.

When upgrading your SDK, please refer to the following migration guides:

• Android - 1.x to 2.x, 2.x to 3.x, 3.x to 4.x, 4.x to 5.x, 5.x to 6
• iOS - 1.x to 2.x, 2.x to 3.x, 3.x to 4.x
• JS - 1.x to 2.x

All Flex applications are now required to register their external domains when flex.twilio.com is loaded within an iframe. This restriction is now enforced for new applications. Existing Flex applications have until May 3, 2021 to confirm their registered domains.

To prevent potential phishing attacks or abuse by malicious third parties, we are applying a Content Security Policy to flex.twilio.com that restricts Flex from being rendered in an iframe by untrusted domains. To continue using Flex within an iframe, including through Salesforce and Zendesk integrations, admins must register their external domains on the Flex Settings page. We have pre-populated this list based on your current application activity.

Refer to our documentation for more details.

The Call Log for Elastic SIP Trunking is now customizable and can be altered to show and hide information more or less pertinent to customers' needs. Call SID, Cost, and Parent Call SID have all been added to the available columns, and many existing columns can be removed for a more concise view. The table can be configured using the new Configure Columns button located on the right side of the Filter pane. Additionally, the CSV file download includes new information and a preview of what data is available to be downloaded. View our documentation for more information about the Elastic SIP Trunking Call Log and how to troubleshoot your calls.

We have introduced a solution that enables Microsoft Teams Direct Routing and/or Cisco Unified Communication Manager (CUCM) to gain PSTN access using the Ribbon Communications SBC and Twilio Elastic SIP Trunking. This combination enables any organization using Microsoft Teams Direct Routing or Cisco UCM to connect to the PSTN via Twilio Elastic SIP Trunking. You can learn more about this solution in our blog and by referencing Twilio Elastic SIP Trunking Solution Blueprints.

This release of Flex UI introduces an improved troubleshooting experience for Flex UI users. Troubleshooting and fixing any issues starts with understanding their cause and getting additional context about the issues. Users of Flex UI will now be able to get error notifications via a Debugger UI and will be able to download a report with full error descriptions and logs.

We are keeping your runtime up to date with industry standards. In accordance with OpenJS Foundation’s support schedule, Node v10 will no longer be supported after April 30, 2021.A new deployment will be required to make Functions run against the new Node version.

Your currently deployed functions will continue to execute on the existing Node v10 runtime if no changes are made.

Follow theseinstructions to upgrade, test and deploy your codeand ensure a safe transition to Node v12

We recommend that you upgrade to Node v12 even if you’re not planning on making other changes. Test and re-deploy your code with Node v12

If you don’t specify a runtime, we’ll use Node v12 by default if there are no previous builds deployed in the service. If you already have a build deployed in the service, the same runtime will be used to deploy as the last successful deployment until April 30th.

If a Build contains only Assets, then the default Runtime(regardless of the Runtime passed in the Build request or even if Runtime is not passed) will be used automatically for the Build. The default Runtime is Node12 after April 30th.

After April 30th, if you have not deployed using Node v12 already, you would have to deploy using Node v12 at least once to move your code to Node v12.

Currently, the Node version will only change if you explicitly set the Node version via either the UI dropdown in the dependencies tab, by passing runtime using serverless toolkit or by explicitly setting the runtime parameter when creating a Build.

Over the next few weeks, we are gradually rolling out MMS capabilities across our US Toll-Free numbers.

Starting this week, you will see numbers with MMS capabilities appear when you search for US(+1) Toll-Free phone numbers using Advanced Search. If you already own Toll-Free numbers, they will be enabled with MMS capabilities by the end of March as well.

You can send an MMS message on a Toll-Free number by including the MediaUrl parameter in your API request. Pricing information can be found here.

We will share another update once all Toll-Free numbers are generally available for sending and receiving MMS messages from recipients in US and Canada.