Programmable Video now Generally Available, new REST API and more

video_p2p_ga_header

Programmable Video now generally available
New REST API for configuring Rooms and receiving webhook status callbacks
New Room-based access control

We’re excited to announce the general availability of release 1.0.0 of our Programmable Video SDKs for Android, iOS, and JavaScript. Along with the 1.0.0 SDK release comes a shiny new REST API, a simplified approach to Room configuration, Room access control, and an improved Console interface for historical Room logs.

Want to know how to get started with Video? Dive into our sample applications for Android, iOS (Swift, Objective-C), and JavaScript.

Dropping the “Beta” identifier

You’ve built thousands of apps with Programmable Video. If you’ve worked with our Video SDKs, you know that until today, each release of our Android, iOS, and JavaScript SDKs included a beta identifier in its version number.

Although we always try to minimize the impact of changes in our products and provide the highest quality support experience possible, the beta identifier indicated we were still refining the API and service behavior, and users should expect a sometimes significant evolution of the APIs and supporting services from release to release.

Today, we’re dropping the “beta” label: Programmable Video’s Peer-to-Peer Rooms API is generally available. You’re encouraged to join hundreds of others in using Video in your production applications—we’ll provide the same top-notch support we provide for all generally available Twilio products.

Using Video to help the sick get healthy

As just one example, the team at Doctor on Demand uses Programmable Video to help millions of users see a doctor at a moment’s notice. Patients initiate a video appointment with a doctor using the Doctor on Demand app for iOS or Android. The doctor uses Doctor on Demand’s web application to take the call and consult with the patient.

Doctor on Demand originally used AddLive to power their video calling experience, but began looking for another vendor after Snapchat acquired AddLive. After they compared Twilio Video with the alternatives, it just made sense to go with Twilio.

“We were already using Twilio for SMS appointment reminders, and we were really impressed once we tried out the Video SDKs,” said Kent Griffin, VP of Product at Doctor On Demand. “Video is a critical component in delivering a positive patient experience, and our customers are really enjoying the superior video quality we’re able to provide with Twilio.

Hello REST API and webhook status callbacks

Today, we’re also announcing a new REST API that allows you to create and configure Programmable Video Rooms from your server-side code.

Through this API you can create and complete Rooms, configure a Room’s TURN settings, set a URL to receive webhook status callbacks, control the maximum number of Room Participants, and more.

For example, to create a Video Room called “DailyStandup” and receive webhook status callbacks at your server at http://example.org, you could make the following API request:

curl -XPOST 'https://video.twilio.com/v1/Rooms' \
 -u '{API Key SID}:{API Secret}' \
 -d 'UniqueName=DailyStandup' \
 -d 'StatusCallback=http://example.org'

Once created, use one of our client-side Video SDKs for iOS, Android, or JavaScript to connect to DailyStandup and get your users talking.

Check out the REST API documentation to get started with the new Rooms REST API.

Default Room Settings

The new REST API is great when you want to dynamically control Room configuration. Many applications, however, use the same settings for every Room. And sometimes, you want to be able to experiment with different options during development without having to make a REST API request each time.

The new Default Room Settings page in the Video Console makes it easy to manage default Room behavior so you don’t have to make a REST API request every time.

We’ll use the defaults you configure here whenever a new Room is created in your Twilio account, unless you override the defaults when creating a Room through the REST API.

Room-based access control

Another new feature, Room-based access control, gives you more control over the security of Programmable Video Rooms. Now, when you generate a client’s Access Token, you can add an optional room grant. The client that uses this token to connect to Programmable Video will only be allowed to connect to the exact Room you’ve specified in the grant.

For example, to generate an Access Token that lets the client connect to the room DailyStandup using our JavaScript helper library, you’d do the following:

const AccessToken = require('twilio').jwt.AccessToken;
const VideoGrant = AccessToken.VideoGrant;

// Used when generating any kind of Access Token
const twilioAccountSid = 'ACxxxxxxxxxx';
const twilioApiKey = 'SKxxxxxxxxxx';
const twilioApiSecret = 'xxxxxxxxxxxx';

// Create an access token which we will sign and return to the client,
// containing the grant we just created
const token = new AccessToken(twilioAccountSid, twilioApiKey, twilioApiSecret);
token.identity = 'alice';

// Create a Video grant which enables a client to use Video 
// and limits access to the specified Room (DailyStandup)
const videoGrant = new VideoGrant({
    room: 'DailyStandup'
});

// Add the grant to the token
token.addGrant(videoGrant);

// Serialize the token to a JWT string
console.log(token.toJwt());

Check out our docs to learn more about Access Tokens and Room Access Control.

Client-side Room creation

In earlier releases of our Video SDK, your client-side code determined when a Room was created. But in some applications it makes sense to control the Room lifecycle from your server-side code. If this is the case in your application, you can now disable Client-side Room Creation in the Room Settings page in the Console.

When Client-side Room creation is enabled, it’s easy to get up and running without writing any back-end code:

Any SDK client that holds a valid Access Token can create a new Video Room without you needing to first call the REST API.
The client can specify the Room’s name, and if the Room doesn’t exist it will be created on-the-fly.

When you’re done prototyping and ready to move your app to production, you can disable client-side Room creation, which will mean:

A client’s Access Token must contain a video grant for a specific Room in order to connect.
The Room must be pre-created with the REST API.

Read the updated docs on User Identity & Access Control for more details.

Goodbye Configuration Profiles

Before the REST API and Default Room Settings, Room configuration was governed by the Configuration Profile you set in your Video client’s Access Token. The Rooms REST API and Default Room Settings are simpler solutions, so we are deprecating support for multiple Configuration Profiles in favor of this REST API.

This means the following:

Effective today, you can still view your existing Configuration Profiles, but you won’t be able to edit them or create new ones.
Apps that use Configuration Profiles will continue working exactly as they do today until August 1, 2017.
On August 1, 2017 we’ll remove Configuration Profile support from the Video product. On this date, the Default Room Settings configured in your account will be used for any Rooms that are not created through the REST API.

Using an older release of the Video SDKs?

If you’re using an earlier release of our Video SDKs, you’re likely wondering “How do these changes affect my app?”.

If you’re using 1.0.0-beta1 or 1.0.0-preview1 or greater of our Video SDK, your application will continue to function without modification. All of the changes mentioned above are backwards compatible with earlier releases of our Video SDKs, and your app will continue working exactly as it does today. You only need to take note of the deprecation of Configuration Profiles on August 1, 2017 and make sure you have your Default Room Settings configured correctly.

If you’re using a release of our Video Conversations SDK (releases older than 1.0.0-beta1 or 1.0.0-preview1), back-end support for these SDKs will be terminated on August 1, 2017. There are only a very small number of applications still using these early releases of our Video SDKs, so chances are you don’t need to worry.

The Video Conversations SDK releases impacted by this change are the following:

Conversations Android 0.12.2 and earlier
Conversations iOS 0.25.1 and earlier
Conversations JavaScript 0.13.10 and earlier

If you have any questions about any of these changes, don’t hesitate to reach out to our team at support@twilio.com. We’d be happy to give you a hand with any of your Programmable Video questions.

SDK versioning and distribution

And as a reminder, our Programmable Video SDKs follow standard semantic versioning. In summary, this means that given a version number MAJOR.MINOR.PATCH, we will increment the:

MAJOR version when we make incompatible API changes.
MINOR version when we add functionality in a backwards-compatible manner.
PATCH version when we make backwards-compatible bug fixes.

Additionally, we denote Developer Preview or Beta releases by appending -preview or -beta metadata to future releases.

If you’re an iOS developer using CocoaPods, this also means you should now consume iOS SDK releases directly from the CocoaPods Master Spec Repository. Make sure you update your Podfile in order to keep up to date with future iOS releases.

To start receiving updates from the CocoaPods directory, modify your Podfile as follows:

source 'https://github.com/CocoaPods/Specs'
# Consume patch level releases starting with 1.0.0
target 'TARGET_NAME' do
    pod 'TwilioVideo', '~> 1.0.0'
end

Video everywhere

We believe that technical and consumer trends are making embedded, in-app voice & video a must-have capability for many applications.

The global adoption of mobile devices means that we’re all carrying an incredible camera, microphone, and CPU in our pocket. Widespread support for WebRTC means that billions of people now use a video-capable browser to access the internet every single day. And increasing wireless network bandwidth and reliability makes it possible to bring high quality video to all kinds of environments that were previously unreachable.

Every day, we see your applications validate these beliefs—and we’d love to see them in-person. Join us on May 24 and 25 in San Francisco at SIGNAL, Twilio’s annual developer conference, to network, learn, and meet the Programmable Video product and engineering team. Sign up here to receive 20% off SIGNAL registration (use the code Video20).

We can’t thank you enough for participating in the Programmable Video Beta. We look forward to meeting you face-to-face, hearing your feedback, helping you with your app development, and sharing our roadmap.

We can’t wait to see you what you’ll build with Programmable Video!

Authors

Rob Brazier