Twilio Changelog

Runtime Handler version 1.2.1 introduces access to headers and cookies for incoming requests to Twilio Functions through the new event.request object. Visit our documentation to learn more about this feature.

You can use this version today by setting @twilio/runtime-handler to use version 1.2.1.

For new projects and those that don't specify a specific Runtime Handler version, we'll be rolling out version 1.2.1 over the coming weeks as the new default version.

Check out our docs to learn more about specifying which Runtime Handler version to use.

We are excited to announce the availability of 24 hour participant durations for video rooms.

You can now configure the Maximum Participant Duration for any Twilio Video room type. This value is set at the time of room creation, and upon reaching the limit, a participant will be disconnected from the room.

The default value for maximum participant duration is 4 hours. You can change this value either through the Console under Rooms Settings to make it the default for Ad-hoc rooms or as a configurable parameter via the REST API upon room creation.

For more information on configuring the maximum participant duration, view the participant duration documentation. If you are composing room recordings of participants with long durations, you may want to review the composition size limitations.

IP Commands for Super SIM® is now in Public Beta. IP Commands are a secure and lightweight solution to send UDP messages from your cloud to your Super SIM enabled devices. A cellular network typically has firewalls that block incoming connections from the Internet to the devices attached to it. This means that if your IoT device is using a cellular connection to connect to the Internet or your cloud, you can’t reach the device until the device sets up an outbound connection to your cloud. IP Commands provides a solution for this by allowing you to send the message to Twilio via the IP Commands API, which we then convert into an IP/UDP datagram and forward to the device.

IP Commands work in both directions. We also support Mobile Originated (MO) IP Commands from the device to the cloud. MO IP Commands can either be sent as a response to an IP Command received by the device or even as an unsolicited message originated by the device.

IP Commands are already enabled for your devices using Super SIM. To use IP Commands, please refer to the API documentation and a tutorial on using IP Commands.

We continue to invest in infrastructure improvements to provide scale and high reliability for our customers, and today we are excited to increase both the default maximum concurrent Room limit to 10,000 as well as the maximum concurrent Participant limit to 10,000 for Group and Peer-to-Peer Rooms.

The maximum concurrent Room threshold limits the number of Rooms that can be in-flight at the same time while the max concurrent Participant threshold limits the number of Participants that can be connected to your rooms at the same time. Both limits operate independently at the account level.

You can view your account room limit and participant limit in the Console under Room Settings. If a limit is reached, an error code (53119, 53206) is returned and it is also displayed in the Console Debugger. If your account limits were previously above 10,000, they will remain unchanged.

The default limits are designed to give developers ample room to grow while ensuring runaway issues get caught quickly. If you need to increase your account limits beyond the default maximum concurrent Room or maximum concurrent Participant limit, please contact Sales.

With Verify’s TOTP (Soft Token) channel you can support authentication through software-based authenticator apps like Authy or Google Authenticator. It’s great for businesses looking for a more secure and lower-cost option compared to SMS OTP that works offline and doesn’t require a phone number. With this release, the API is publicly available and supports production-scale workloads. Learn more here.

We have rolled back our release to Public Beta for the new Calls resource property, CallToken, back to Private Beta due to unexpected behavior on a small number of accounts. We are working on a fix and will re-release as soon as possible.

If you were already part of the Private Beta, everything will continue to work as it has been. For more information see original changelog here.

A new Calls resource property, CallToken, has been added to the Programmable Voice API. CallToken is an optional parameter that customers can use to forward their calls. A CallToken is generated when an incoming call is received on Twilio. Customers can now populate the CallToken parameter with the CallToken from the incoming call to forward their calls and maintain the same caller-id from the inbound call on the outbound call.

In the future in the United States, when SHAKEN/STIR DIV PASSporT is supported by carriers, end to end call authentication will be possible by using the CallToken.

TaskRouter now offers dedicated properties in the Workflow filter target to improve support for use cases where the agent is already known, e.g., because the customer previously spoke to that agent (‘last agent routing’) or has an existing relationship with that agent / advisor (‘preferred agent routing’).

Developers can utilize properties for either the agent’s Worker SID or Worker friendly name in a Workflow filter target and specify the respective value on the Task.

Utilizing this feature will yield significant performance improvements over the general evaluation logic and prevent latencies during routing and assignment of such Tasks.

To learn more about the TaskRouter Known Agent Routing feature, please refer to our documentation on Known Agent Routing.

As previously communicated, Twilio is adding functionality to the Programmable Voice <Dial> verb. Although the new features are specific to SIP Connectivity via <Dial><Sip>, the new functionality may affect your existing applications using <Dial>, <Dial><Client>, and <Dial><Number>. <Dial><Conference> and <Dial><Queue> are not impacted.The deadline to account for these changes in your application code is 16 November 2021.

In most cases, your existing code will continue to function; however, there are some functional improvements and behavioral changes which could possibly impact your application. We recommend testing your existing application code in dev or staging environments before 16 November 2021 to identify any potential impacts.

The new features can be enabled on the Programmable Voice Settings page by clicking the Enable Advanced Programmable SIP Features setting. This will activate the new features on an account-wide level.

Twilio initially communicated that these features will be applied to all accounts after 31 July 2021, but following customer feedback we extended the testing period to 16 November 2021.

We are keeping your runtime up to date in accordance with industry standards. Based on the Node.js support schedule, Node.js v12 will no longer be in Maintenance long-term support (LTS) status after April 30, 2022. Production applications should only use releases of Node.js that are Active LTS or Maintenance LTS.

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

Follow these instructions to upgrade, test, and deploy your code and ensure a safe transition to Node.js v14.