Product changelog and announcements

Two new video room timeout parameters, empty_room_timeout and unused_room_timeout, have been added to the video rooms REST API to allow you to better manage the lifecycle of a video room.

The empty room timeout specifies how long a room will remain active after the last participant leaves, while the unused room timeout specifies how long a room will remain active if no one joins. Both values are set upon room creation and operate independently. The new maximum value for both parameters is 60 minutes and the default value remains five minutes.

These values are only configurable for rooms created with the REST API and can be applied to WebRTC Go, Peer-to-Peer, and Group Rooms. For rooms created via the Ad-hoc method, these values are zero by default and cannot be changed.

For more information on configuring room timeouts, view the Video Rooms REST API documentation.

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.

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.

We’re thrilled to announce that Video Insights is now available in Public Beta.

Video Insights brings self-service tooling to the Twilio console to help you observe application usage and quality, discover trends across all your rooms and participants, and troubleshoot issues with ease, leading to higher quality video experiences for your customers, reduced churn, and increased confidence in scaling rapidly.

Get started now by visiting the Video Insights Dashboard in the Twilio Console, or check out our blog post or the documentation to learn more.

Twilio Live is now Generally Available

With Twilio Live, developers have access to a low-latency, secure interactive live streaming platform that allows speakers to reach millions while providing an intuitive end-to-end developer experience, including flexible server-side API primitives, and player SDKs for iOS, Android, and JavaScript.

Twilio Live gives developers the tools to build immersive live experiences that can be directly embedded into their applications such as marketing conferences, next-generation social podcasts, shopping experiences, concerts, fitness classes, education sessions, and more.

For additional information on this release, check out our blog post and get started with our developer documentation.

One year after launch, we are excited to announce quota increases for WebRTC Go to allow you to build, launch, and run 1:1 video applications for free, for longer. The changes are as follows:

1. WebRTC Go now comes with unlimited TURN usage, removing the previous 25 GB/month limit.
2. You can now scale up to 500 concurrent participants or rooms, up 500% from the previous limit of 100.

To learn more about the quota increases and some of the key improvements we made for WebRTC Go developers over the last year, refer to the One year of WebRTC Go blog post.

We are excited to announce the release of the Twilio Video Room Monitor, a browser-based tool providing javascript developers visibility into the inner workings of their Twilio Video application. It displays real-time information and metrics from the Room object and can be added to any Twilio Video javascript application with just a few lines of code.

The Video Room Monitor can be used as a tool during all phases of development or can be customized and provided to end-users as an in-call troubleshooting view.

For more information on the Video Room Monitor, see our blog post or visit the README.

We have released significant updates for our mobile SDKs and added Chrome on iOS support to our JavaScript SDK.

The Chromium WebRTC engine in the iOS & Android SDKs has been upgraded from m83 to m88. In addition to the security and performance improvements, these mobile SDKs now use the newer “unified plan” WebRTC signaling protocol, which provides improved browser compatibility in P2P and Go Rooms. The iOS SDK has added support for running the iOS Simulator on Apple Silicon ARM64 Macs. There is a major version increment for the Android SDK to 7.0 and the minimum Android API level has been increased from 16 to 21.

The 2.17 JavaScript SDK now supports the Google Chrome browser on iOS versions 14.3 and above.

For a full description of all the changes, see the Android SDK 7.0 changelog, iOS SDK 4.6 changelog and JavaScript SDK 2.17.

We are excited to announce the release of the Video Diagnostics Web App, an open source ReactJS application demonstrating how to test a participant’s ability to have a high-quality video call with the Twilio platform - now available in Public Beta for WebRTC Go, P2P, and Group Room developers.

The application is built using diagnostics and call-readiness features in Twilio’s RTC Diagnostics SDK and Twilio’s Video Javascript SDK, including the recently released Preflight API Public Beta.

It can be customized, embedded into your application, and used as part of onboarding to ensure a successful first video call or for diagnosing issues that relate to the device, software, or network conditions of the end-user.

For more information on the Video Diagnostics application, see our blog post or visit the README.

This release contains a significant update to the Network Bandwidth Profile API for multi-party applications. It provides two new settings to manage video track switch on/off and video resolution selection. The update is available on JavaScript, iOS and Android SDKs.

This enhancement allows for more efficient use of bandwidth and CPU in multi-party applications, which translates into a higher quality video experience for end users. It can dynamically tailor the incoming video tracks to match the active UI layout. In addition, it provides developers with more fine grained control over the video tracks to allow developers to create unique user interfaces while still being efficient with bandwidth and CPU.

For more information on this update, see our blog post here or review the documentation here.