This application demonstrates a multi-party video application built with Twilio's Programmable Video JS SDK, Twilio's Conversations JS SDK, and Create React App.
- Deploy to Twilio Serverless in just a few minutes
- No other infrastructure is required
- No code changes are required before your first deploy
- There is no cost associated with deploying the app
- Go Rooms usage is free, however standard usage charges apply for Programmable Video when using the app with all other Room types. The chat feature is built using the Conversations API and is free-of-cost up to 200 monthly active users, standard usage charges apply thereafter.
You must have the following installed:
- Node.js v12+
- NPM v6+ (comes installed with newer Node versions)
Run npm install to install all dependencies from NPM.
If you want to use yarn to install dependencies, first run the yarn import command. This will ensure that yarn installs the package versions that are specified in package-lock.json.
The app is deployed to Twilio using the Twilio CLI. Install twilio-cli with:
$ npm install -g twilio-cli
Login to the Twilio CLI. You will be prompted for your Account SID and Auth Token, both of which you can find on the dashboard of your Twilio console.
$ twilio login
This app requires an additional plugin. Install the CLI plugin with:
$ twilio plugins:install @twilio-labs/plugin-rtc
Note: If you have previously installed the @twilio-labs/plugin-rtc plugin, please make sure that you are using the most recent version. You can upgrade the plugin by running twilio plugins:update. The chat feature requires version 0.8.1 or greater of @twilio-labs/plugin-rtc.
Before deploying the app, make sure you are using the correct account on the Twilio CLI (using the command twilio profiles:list to check).
The app is deployed to Twilio with a single command:
$ npm run deploy:twilio-cli
This performs the following steps:
- Builds the React app in the
srcdirectory - Generates a random code used to access the Video app
- Deploys the React app and token server function as a Twilio Serverless service.
- Prints the URL for the app and the passcode.
NOTE: The Twilio Function that provides access tokens via a passcode should NOT be used in a production environment. This token server supports seamlessly getting started with the collaboration app, and while convenient, the passcode is not secure enough for production environments. You should use an authentication provider to securely provide access tokens to your client applications. You can find more information about Programmable Video access tokens in this tutorial. As a precaution, the passcode will expire after one week. To generate a new passcode, redeploy the app:
$ npm run deploy:twilio-cli -- --override
View the URL and passcode for the Video app with
$ twilio rtc:apps:video:view
Delete the app with
$ twilio rtc:apps:video:delete
This removes the Serverless app from Twilio. This will ensure that no further cost are incurred by the app.
If any errors occur after running a Twilio CLI RTC Plugin command, then try the following steps.
- Run
twilio plugins:updateto update the rtc plugin to the latest version. - Run
twilio rtc:apps:video:deleteto delete any existing video apps. - Run
npm run deploy:twilio-clito deploy a new video app.
After running the command to deploy the app to Twilio, the room type will be returned in the command line output. Each room type provides a different video experience. More details about these room types can be found here. The rest of this section explains how these room types affect the behavior of the video app.
Group - The Group room type allows up to fifty participants to join a video room in the app. The Network Quality Level (NQL) indicators, dominant speaker, and start-stop recordings are demonstrated with this room type. Also, the VP8 video codec with simulcast enabled along with a bandwidth profile are set by default in order to provide an optimal group video app experience.
Small Group - The Small Group room type provides an identical group video app experience except for a smaller limit of four participants.
Peer-to-peer - Although up to ten participants can join a room using the Peer-to-peer (P2P) room type, it is ideal for a one to one video experience. The NQL indicators, bandwidth profiles, dominant speaker, and start-stop recordings cannot be used with this room type. Thus, they are not demonstrated in the video app. Also, the VP8 video codec with simulcast disabled and 720p minimum video capturing dimensions are also set by default in order to provide an optimal one to one video app experience. If more than ten participants join a room with this room type, then the video app will present an error.
Go - The Go room type provides a similar Peer-to-peer video app experience except for a smaller limit of two participants. If more than two participants join a room with this room type, then the video app will present an error.
If the max number of participants is exceeded, then the video app will present an error for all room types.
The Video app has the following features:
- Video conferencing with real-time video and audio
- Chat support for textual and file-based messaging
- Enable/disable camera
- Mute/unmute mic
- Screen sharing
- Dominant speaker indicator
- Network quality indicator
- Defines participant bandwidth usage with the Bandwidth Profile API
- Start and stop recording with the Recording Rules API
See browser support table for twilio-video.js SDK.
This application requires an access token to connect to a Room for Video and a Conversation for Chat. The included local token server provides the application with access tokens. This token server can be used to run the app locally, and it is the server that is used when this app is run in development mode with npm start. Perform the following steps to setup the local token server:
- Create an account in the Twilio Console.
- Click on 'Settings' and take note of your Account SID.
- Create a new API Key in the API Keys Section under Programmable Video Tools in the Twilio Console. Take note of the SID and Secret of the new API key.
- Create a new Conversations service in the Services section under the Conversations tab in the Twilio Console. Take note of the SID generated.
- Store your Account SID, API Key SID, API Key Secret, and Conversations Service SID in a new file called
.envin the root level of the application (example below).
TWILIO_ACCOUNT_SID=ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TWILIO_API_KEY_SID=SKxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TWILIO_API_KEY_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
TWILIO_CONVERSATIONS_SERVICE_SID=ISxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Now the local token server (see server/index.ts) can dispense Access Tokens to connect to a Room and a Conversation. See .env.example for information on additional environment variables that can be used.
Note: the use of Twilio Conversations is optional. If you wish to opt out, simply run or build this app with the REACT_APP_DISABLE_TWILIO_CONVERSATIONS environment variable set to true.
Run the app locally with
$ npm start
This will start the local token server and run the app in the development mode. Open http://localhost:3000 to see the application in the browser.
The page will reload if you make changes to the source code in src/.
You will also see any linting errors in the console. Start the token server locally with
$ npm run server
The token server runs on port 8081 and expects a POST request at the /token route with the following JSON parameters:
{
"user_identity": string, // the user's identity
"room_name": string, // the room name
}
The response will be a token that can be used to connect to a room. The server provided with this application uses the same endpoints as the plugin-rtc Twilio CLI plugin that is used to deploy the app. For more detailed information on the server endpoints, please see the plugin-rtc README.
If you want to see how the application behaves with multiple participants, you can simply open localhost:3000 in multiple tabs in your browser and connect to the same room using different user names.
Additionally, if you would like to invite other participants to a room, each participant would need to have their own installation of this application and use the same room name and Account SID (the API Key and Secret can be different).
Build the React app with
$ npm run build
This script will build the static assets for the application in the build/ directory.
This application has unit tests (using Jest) and end-to-end tests (using Cypress). You can run the tests with the following scripts.
Run unit tests with
$ npm test
This will run all unit tests with Jest and output the results to the console.
Run end to end tests with
$ npm run cypress:open
This will open the Cypress test runner. When it's open, select a test file to run.
Note: Be sure to complete the 'Getting Started' section before running these tests. These Cypress tests will connect to real Twilio rooms and real Twilio conversations, so you may be billed for any time that is used.
The state of this application (with a few exceptions) is managed by the room object that is supplied by the SDK. The room object contains all information about the room that the user is connected to. The class hierarchy of the room object can be viewed here.
One great way to learn about the room object is to explore it in the browser console. When you are connected to a room, the application will expose the room object as a window variable: window.twilioRoom.
Since the Twilio Video SDK manages the room object state, it can be used as the source of truth. It isn't necessary to use a tool like Redux to track the room state. The room object and most child properties are event emitters, which means that we can subscribe to these events to update React components as the room state changes.
React hooks can be used to subscribe to events and trigger component re-renders. This application frequently uses the useState and useEffect hooks to subscribe to changes in room state. Here is a simple example:
import { useEffect, useState } from 'react';
export default function useDominantSpeaker(room) {
const [dominantSpeaker, setDominantSpeaker] = useState(room.dominantSpeaker);
useEffect(() => {
room.on('dominantSpeakerChanged', setDominantSpeaker);
return () => {
room.off('dominantSpeakerChanged', setDominantSpeaker);
};
}, [room]);
return dominantSpeaker;
}
In this hook, the useEffect hook is used to subscribe to the dominantSpeakerChanged event emitted by the room object. When this event is emitted, the setDominantSpeaker function is called which will update the dominantSpeaker variable and trigger a re-render of any components that are consuming this hook.
For more information on how React hooks can be used with the Twilio Video SDK, see this tutorial: https://www.twilio.com/blog/video-chat-react-hooks. To see all of the hooks used by this application, look in the src/hooks directory.
The VideoProvider component contains much of the logic that relates to connecting to video rooms and acquiring local input devices. The VideoProvider component exposes many properties and methods to the rest of the application through the useVideoContext hook. Similarly, the ChatProvider contains logic that relates to connecting to a Twilio Conversation, and it exposes properties and methods through the useChatContext hook.
The connect function from the SDK accepts a configuration object. The configuration object for this application can be found in src/utils/useConnectionOptions/useConnectionOptions.ts. In this object, we 1) enable dominant speaker detection, 2) enable the network quality API, and 3) supply various options to configure the bandwidth profile.
This application dynamically changes the priority of remote video tracks to provide an optimal collaboration experience. Any video track that will be displayed in the main video area will have track.setPriority('high') called on it (see the VideoTrack component) when the component is mounted. This higher priority enables the track to be rendered at a high resolution. track.setPriority(null) is called when the component is unmounted so that the track's priority is set to its publish priority (low).
This application can be configured to authenticate users before they use the app. Once users have signed into the app with their Google credentials, their Firebase ID Token will be included in the Authorization header of the HTTP request that is used to obtain an access token. The Firebase ID Token can then be verified by the server that dispenses access tokens for connecting to a room.
See .env.example for an explanation of the environment variables that must be set to enable Google authentication.
See the LICENSE file for details.