Twilio Changelog

Twilio is open sourcing a Voice Notification App built in ReactJS for the Web. This reference app can be deployed to Heroku in minutes and demonstrates how to leverage Programmable Voice and Twilio SDKs to create a voice notification system to make calls to your customers to deliver time-sensitive messages. Whether you are building a voice notifications solution for Emergency Alerts, Appointment Reminders or Sales & Marketing use cases, this reference app can be used as a starting point.

Access to the source code will help customers understand how to use Twilio “building blocks” and Programmable Voice APIs to build an application for their own notification use case and accelerate development.

For additional information on getting started see the source code repo here.

This release of Flex UI and WebChat UI introduces a pilot release of image and file sharing for chat channels in Flex. Agents and webchat users can now share images, documents, and other files during a chat conversation. Visit our web chat documentation for more details and steps to enable this feature.

.We are excited to announce the General Availability of Messaging Insights for all customers in console. Messaging Insights offers unprecedented transparency for customers to monitor, troubleshoot, and optimize message deliverability and engagement on Twilio.

The GA launch enables multidimensional filters, a Message List view and the following four reports.

1. Overview: high-level view of your outgoing and incoming messages
2. Delivery & Errors: deep dive into factors that affect deliverability to help you identify what is causing an issue
3. Responses: visualize and filter the inbound messages that you’re receiving back from your end users
4. OTP Conversion: aggregate and visualizes the information that you have sent to Twilio about successful OTP messages

Messaging Insights is available on the Twilio console for all customers. To learn more see the Messaging Insights docs.

The Programmable Voice Conference REST API and <Conference> TwiML now supports adding custom labels when creating and adding participants into a conference. Prior to this change, developers were required to use Participant’s Call Sid to read or update specific participants in a conference. Developers can now provide a label to a participant at the time of adding them into the conference. The label can then be used to read, update or delete participants. The custom participant label means developers no longer have to use Twilio identifiers, and instead use participant labels that make sense for your specific use case.

For example, if you have access to the Participant’s CallSid, this code snippet shows how to mute a participant using the CallSid. Alternatively, this code snippet demonstrates how to mute a participant that was given the label of Customer at the time of being added into the conference.

The Programmable Voice Conference REST API now supports a new CallerId Parameter with Conference Create Participant REST API. This change allows developers to set the CallerId to a different phone number from the one used for the identity of the call in the From parameter. Prior to this change, the phone number in the From parameter was the Caller Id displayed on the end device, as well as the identifier used by carriers to calculate charges for that call. This change is specifically important for outbound dialing in European destinations where you could take advantage of Origin-Based Pricing for lower rates.

The CallerId parameter is already supported when making an outbound call using the REST API and now also when making outbound calls from a conference using Create Participant REST API.

Click here to learn more about how to reduce your bill with Origin-Based Pricing.

Please note that the phone number used in both the CallerId and From number must be a Twilio verified Phone number

Twilio Conferences use a jitter buffer to smooth out irregularity in voice packet arrival times to conference participants. This results in better audio quality but introduces a fixed delay for each participant.

When a participant's media stream displays extremely high jitter the jitter buffer may swell to compensate, and at sizes of ~250ms the jitter buffer can be perceived by the conference participants as audio latency.

We have added a parameter to conferences that allows the buffer setting to be configured. The buffer size can be explicitly set or the buffer can be disabled outright which will reduce the perceived latency at the expense of potentially introducing degraded audio artifacts. For more information see our blog post.

We are introducing limits for the number of Rooms and Participants that an account can have in flight at the same time. These concurrency limits ensure a smooth consistent operation of the Twilio Video platform and prevent erroneous behavior on any one account from impacting the experience of other accounts.

The limits for all existing accounts have been set to at least double their peak production traffic, which ensures sufficient headroom for growth. These account limits can be increased on request. If a limit is reached an error code (53119, 53206) is returned and it is also displayed in the Console Debugger.

To learn more, visit the Programmable Video Limits page in our developer documentation.

Twilio Media Streams is now bi-directional. Developers can now stream audio from their own or third party apps back to Twilio enabling use cases such as conversational IVR, integrations with a regional provider for custom Text-to-Speech, and a lot more. This builds on existing support for forking the audio stream of your Programmable Voice calls in real-time and sending the stream to the destination of your choosing to build use cases such as real-time transcriptions, voice authentication, sentiment analysis, speech analytics, and more.

Bi-directional streaming with <Connect> <Stream> TwiML is a synchronous API, giving developers full control over the phone call. In addition, the new <Connect><Stream> API supports new event messages such as Mark and Clear allowing you to build barge-in functionality from within your application.

Check out connect-basic for basic use of the bi-directional streaming API. To learn more about building a conversational IVR using Dialogflow and using mark & clear to implement barge-in functionality, please visit Dialogflow integration GitHub code sample.

Twilio Voice Client JS SDK (twilio.js) Connection class now has Connection.callerInfo.isVerified, that can be used to display a trust indicator to the recipient when an incoming call, say from the public telephone network, has been verified under the SHAKEN/STIR framework.

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.

When your application receives a request webhook that has the new StirStatus parameter, all you have to do is <Dial><Client> and Twilio will implicitly pass the StirStatus to the Javascript Client.

Network Bandwidth Profile API is now available in our mobile SDKs starting with Android SDK 5.8 and iOS SDK 3.4. Javascript support has been available since December 2019.

The Network Bandwidth Profile API and associated Track Priority API provide developers with fine grained control over the allocation of bandwidth used by video tracks. Furthermore, the three profiles, “grid”, “collaboration”, and “presentation”, specify when tracks should be switched on or off to conserve bandwidth for the highest priority tracks. Using these controls developers can ensure their end users have the best possible experience.

To learn more visit the documentation on Using the Network Bandwidth Profile API and Using the Track Priority API. To see an example of how to use Network Bandwidth Profile API in a mobile application, visit the Video iOS Collaboration App or the Video Android Collaboration App.