Skip to main content

Telnyx Other APIs: Video — Full Documentation

Complete page content for Video (Other APIs section) of the Telnyx developer docs (https://developers.telnyx.com). Root index: https://developers.telnyx.com/llms.txt · Lightweight index for this subsection: https://developers.telnyx.com/development/llms/other-apis-video-llms-txt.md

Getting Started

Source: https://developers.telnyx.com/docs/video/get-started.md
Telnyx Video Rooms are enabled using the Rooms API. You can create as many rooms as needed using this API. To access a Telnyx Video Room, a Client Join Token will first need to be generated in JWT form. You can use our HTTPS API and authenticate using the API Key associated with your Mission Control account under API Keys. Find out more about authenticating with API V2 here. Adding Telnyx Rooms functionality to your app can be done using our JS SDK (mobile SDKs coming soon). To gain access to a live Video Rooms sample app, reach out to our sales team today! Check out the full API reference today!

Glossary

Room Resource representing a virtual place where multiple endpoints using one of Telnyx’s Programmable Video SDKs can connect. Room Session Resource representing a moment where multiple Room Participants were communicating within a given Room. Room Participant Resource representing an endpoint using one of Telnyx’s Programmable Video SDKs to connect to a given Room. JWT JSON Web Token. A standard method for representing claims. Client Join Token (JWT) A JWT token which contains grants allowing in the Room usecase to join a Room. Refresh Token (JWT) A JWT token which permits to obtain a new Client Token with same grants. API Key Secret API Key generated via Portal and used to authenticate Telnyx API calls. Video SDK A library used to provide Video features to your application using Telnyx Video platform. Configuration and usage Telnyx Video is enabled using Video Rooms. A Video Room represents communications session among multiple endpoints using one of Telnyx’s Programmable Video SDKs. Connected users (Participants) can share video and audio Tracks with the Room, and receive video and audio Tracks from other Participants in the Room. You can as many Rooms as you want. For example you could create a long lived Room such as “Daily Standup”, or Rooms that you would delete after it’s been used like “1-1 with X”. To create a Video Room you can use the REST API V2 documented{” ”} here. A Video Room can only be joined if the client owns a Client Join Token, you can create it using the REST API V2 documented{” ”} here. The Client Join Token is short lived and you will be able to refresh it using the{” ”} Refresh Token provided with it when you request for a Client Join Token. Once you have a Video Room and an Client Join Token for it, you can then use our Video SDK on your client side to connect your client to the Room you just created.

Concepts

Architecture

Video Rooms is a platform that enables developers to add audio and video capability to Web, Android, and iOS applications. The platform consists of REST APIs, Client SDKs, and our mission control portal that makes it really easily to capture, stream, record, and render live audio and video. A video application built with Video Rooms has to parts:
  • Client: Our client side Javascript, iOS, and Android SDKs used to interact with a Room instance
  • Server: Our REST APIs and portal to create/manage room and session, configuring recording, or leverage our Participants API to moderator participants in a Room.

Terms

Understanding the basic concepts of the video SDK will help you understand how it works. These concepts apply in general across all of our platforms.
  • A Room represents a real time audio/video/screen share session with other people or participants. It is fundamental to building a video application.
  • Room State tracks the state of the room as it changes making it extremely easy to understand what’s happened to a Room.
    • For example: Room State could change due to a Local Participant has started publishing a stream or because a Remote Participant left. A Stream represents the audio/video media streams that are shared by Participants in a Room
  • A Participant represents a person inside a Room. Each Room has one Local Participant and one or more Remote Participants.
  • A Stream represents the audio/video media streams that are shared by Participants in a Room
    • A Stream is indentified by it’s participantId and streamKey
  • A Subscription is used to subscribe to a Stream belonging to a Remote Participant

Dive a bit deeper

Dive a little bit deeper into our Video Rooms platform to get a better understand of what its capable of, and what you can buid. Learn more about our Client SDKs and Server APIs.

Client SDKs

Our Javascript SDK API reference which details the API of our SDK including behaviors of the Room class and the Events that triggers and how they function.

Server APIs

  • Rooms - manage Rooms
  • Client Access Tokens - manage client access tokens needed to interact with a Room
  • Sessions - manage room sessions, end a session, and mute/unmute/kick all participants in a given session.
  • Participants - search for participants based on a number of filters like session id
  • Recordings - manage recordings, including bulk delete.
  • Compositions - create and manage compositions.

SDKs

Getting Started

Source: https://developers.telnyx.com/docs/video/javascript-sdk.md
The Telnyx Video Client SDK provides all the functionality you need to join and interact with a video room from a browser. npm

Adding Telnyx to your JavaScript client application

Include the @telnyx/video npm module as a dependency: npm install @telnyx/video --save After pasting the above content, Kindly check and remove any new line added Then, import @telnyx/video in your application code.
After pasting the above content, Kindly check and remove any new line added Now you are ready to connect to a video room that you created. In order to connect to a video room you will require a client token that has the necessary grants to join the room.
After pasting the above content, Kindly check and remove any new line added

Understanding the state of the video room

The state_changed event callback contains the state of the SDK at that point in time. This is an immutable object that you can use in most modern UI libraries like React and Vue. The Typescript definition of the State is helpful in understanding the structure of this object.
After pasting the above content, Kindly check and remove any new line added Everytime the state of the SDK changes the state_changed callback is invoked with a new immutable state that represents the current state of the SDK. Since most modern UI libraries are able to compare the two immutable states and render only the components that changed it makes it easier to integrate the SDK with them rather than depending on multiple event callbacks. For e.g., based on how we initialized it in the above code example the initial state of the SDK would result in an object give below. Note that the ID of the local participant is unique and are generated based on UUID v4 standard when you create the local participant.
After pasting the above content, Kindly check and remove any new line added At this point there are no streams being published by the local participant. We will come to that shortly. The participant object follows the TypeScript interface given below.
After pasting the above content, Kindly check and remove any new line added When we called the room.connect() method in the example code the state of the SDK will change to the following …
After pasting the above content, Kindly check and remove any new line added This new state will be available to your application via the state_changed callback. Since state is immutable the only difference between the initial state and the new state is the status property. If you are using a modern UI library like React you can easily rerender the components to show that the application is connecting to the room. When successfully connected the state changes to …
After pasting the above content, Kindly check and remove any new line added Now we are ready to start publishing streams on behalf of the local participant.

Publishing your local camera and mic stream

In order to publish a stream you need to define the constraints of the media. The simplest form of the constraints is …
After pasting the above content, Kindly check and remove any new line added With these constraints the SDK will try to obtain both audio and video from the local participant. In order to publish the stream as the local participant you have to use the publish method available to you via the room object.
After pasting the above content, Kindly check and remove any new line added The first argument to publish is a string that acts as the key that you can use to refer to this specific stream. You can use any valid string for this as long as you are consistent in your application. For e.g. here we’re using ‘self’ for the camera/mic stream but you could use ‘presentation’ as the key for when you publish video of the screen. We will get to how you can publish your screen in a short while. When you make the request to publish a stream, the browser will ask for the necessary permissions required to access the camera and mic. Once the permissions are acquired the SDK will configure and publish the stream to the room you are connected to. At this point you will receive the new state to the state_changed event callback with the newly created stream.
After pasting the above content, Kindly check and remove any new line added The stream object is the most complex object in the state of the SDK. However you don’t have to worry about all of these properties at the moment. As you can see the isPublishing property of the stream is true now. This means that the stream is being published, which involves creating the SDP (Session Description Protocol) and establishing the WebRTC connection. You can’t publish another stream of the same key (“self” in our case) until this stream is published or removed (by unpublishing). Once the SDK acquires the media tracks from the camera and mic of the local participant a new state will be returned using the state_changed callback. This state will contain the audio and video track from the local media devices. The streams object at this point will look like this
After pasting the above content, Kindly check and remove any new line added As you can see at this point you can use the source or the media tracks individually from audioTrack and videoTrack to show the media in your UI. You can also see that the audioActive and videoActive flags are now true indicating the stream is publishing audio and video respectively. Another property that was updated in the new state is the isConfiguring flag. You can ignore this in most use-cases as this indicates if the WebRTC connection is being negotiated. Once the WebRTC connection is negotiated and the stream is successfully published the stream state would look like this
After pasting the above content, Kindly check and remove any new line added At this point the stream will be available to be subscribed by other clients connected to the same room.

Knowing when a new participant joins the room

A video room can have multiple participants and you can get a list of all the participants connected to the room at the time by using the participants property in the state. If the participant is not publishing any streams the streams property of that participant will be an empty object. Let’s imagine that another participant joins the same room from a different browser session with the following context
After pasting the above content, Kindly check and remove any new line added Since the room already contains a participant who is publishing a stream the state once this session is connected would look something like …
After pasting the above content, Kindly check and remove any new line added As you can see there is already a participant in the participants object that maps to the remote particpant from the previous browser session. This remote participant also has a stream with the key “self”. The stream object for “self” has the structure very similar to the one we saw before but has a few new properties. The ones that are particularly interesting are subscription, videoCodec, and audioCodec. The properties for video and audio codec can be used to decide if the browser has the capabilities to decode the video and audio tracks. Then there is subscription.status, which is unpublished at the moment.

Subscribing to a remote stream

At this point we are ready to subscribe to the remote stream published by the participant. In order to do that we use the subscribe method from the room object.
After pasting the above content, Kindly check and remove any new line added This will start the WebRTC negotiation to receive the remote stream. Once successful the subscription.status will change to subscribed. You can use the source property, which is an instance of MediaStream to render the media on the browser. If the remote participant unpublishes this stream the SDK will automatically unsubscibe from the stream and the stream will disappear from the state.

Room and Events

Source: https://developers.telnyx.com/docs/video/javascript-sdk/room-events.md
Telnyx’s video JavaScript SDK lets you manage room events and join/leave notifications. We’ve made it much easier to add video capability to your web application using our Javascript SDK. The Room object and the Events that occur in a Room is the API you will use to build your video application. We’ve extensively documented the interface for the Room and Events objects, below.

Room

Room events


Tutorial

Source: https://developers.telnyx.com/docs/video/javascript-sdk/javascript-video-tutorial.md

In 10 minutes we’ll build

A simple web app in vanilla javascript to make a video with audio from a caller to a callee.

Get an API Key

You need a Telnx account to create an API key so you can interact with our Rooms API
  • If you don’t have one please: Sign up for a free account
  • Navigate to API Keys section and create an API Key by clicking Create API Key button.
  • Copy your API key

Create a Room

Let’s use our Rooms API to create a room. Request Don’t forget to update YOUR_API_KEY here.
Response
Great, grab the response has an id field, this is the id for your newly created Room.

Generate a client token

You’ll need a client access token to join the room. To create one use our REST API rooms/create endpoint. You’ll need to replace ROOM_ID in in the url of the command with your room id, above. As well as YOUR_API_KEY as you have in previous steps. Request
Response
The token field in the response is the client access token you’ll use to join the room.

🏁 Checkpoint - run the app

At this point you should have the following:
  • An API Key
  • A room ID
  • A room client access token
Let’s run the app in a sandbox There’s a README with instructions inside the sandbox. We can use this sandbox as a template to build out the rest of our application.

Let’s write some code

Basic concepts of the video SDK Here are some basic concepts of the SDK that will help you better understand how it works.
  • A Room represents a real time audio/video/screen share session with other people or participants. It is fundamental to building a video application.
  • A Participant represents a person inside a Room. Each Room has one Local Participant and one or more Remote Participants.
  • A Stream represents the audio/video media streams that are shared by Participants in a Room
    • A Stream is indentified by it’s participantId and streamKey
  • A Participant can have one or more Stream’s associated with it.
  • A Subscription is used to subscribe to a Stream belonging to a Remote Participant
Room Events There are a few events trigger on a Room instance that we’ll need to finish building this app that makes a video call.
  • connected - triggers when a room instance has connected to the server
  • participant_joined - triggers when a remote participant joins the room
  • stream_published - triggers when a stream has started being published to the room
  • subscription_started - triggers when subscription to remote stream has started
Handling an event looks like this:

🏁 Checkpoint

It might be helpful to take a look at the full list of Events available on a Room instance.

Connect to the room and get local media

NOTE: We can start implementing our code after the room.initialize block inside the sandbox above. Let’s connect to the room and use the standard WebRTC API to get the audio and video tracks from the device.

Publish the stream and render it

We want to a add/publish a stream the room which consists of the audio and video track we received from the user’s device, above. We’ll give the stream a key of “caller”, which is how the stream is identified.
Render the stream to the DOM Now, that we have the caller’s stream we want to render it to the DOM. The entire room.connected block looks like this:
Great, we’re now publishing the local partipants’/caller’s stream, to the room which the callee can subscribe to.

Subscribe to the callee’s remote stream

As a caller, how do we know when the callee has joined the room or has started publishing a stream? That’s where the participant_joined and the stream_published events that we went over earlier, come into play. We need to listen for teh stream_published event like this:
Understanding how subscriptions work __The stream_published event is triggered for both local and remote streams. __ In our case, we want to know when the callee’s remote stream starts publishing so we can subscribe to it. We already know that the caller has published a “caller” stream so we can ignore that event. Subscribing to a stream When a stream is published in a room it doesn’t mean it’s audio and video tracks are accessible, yet. In order to access a remote stream’s track we must explicitly subscribe to that stream and wait for the subscription_started event.

Render the callee’s remote stream

We’re almost there! Now, we can listen to the subscription_started event and use args from that handler to get the callee’s remote stream and render it to the DOM.

Run the app

To run the app:
  • Open the sandbox, the browser here represents the caller’s app
  • Open the app in another tab, this represents the callee’s application which you’ll need to interact with.
From the caller app
  • Click the call button
  • You should be prompted by the browser for camera/micrphone access please allow.
  • You should also see video from your device’s camera and hear audio from the microphone
  • You should see some console log, if things are working property
From the callee’s app
  • Click the call button
  • Notice in the caller’s app a stream subscription was logged
  • The callee’s video/audio stream is rendered.

Android SDK

Source: https://developers.telnyx.com/docs/video/android-client-sdk.md
The Telnyx Video Android SDK is simple to use and makes it easy to get started with video calling. With this SDK, you can easily add video calling to your app with just a few lines of code. It provides all the functionality you need to join and interact with a Telnyx Room from an Android application. Android SDK

Project structure

  • SDK project: sdk module, containing all Telnyx SDK components as well as tests.
  • Demo application: app module, containing a sample demo application utilizing the sdk module.

Adding the SDK to your Android client application

Add Jitpack.io as a repository within your root level build file:
Add the dependency within the app level build file:
Tag should be replaced with the release version. Then, import the TelnyxVideo SDK into your application code at the top of the class:
The ’*’ symbol will import the whole SDK which will then be available for use within that class. Remember to add and handle INTERNET, RECORD_AUDIO and ACCESS_NETWORK_STATE permissions in order to properly use the SDK.

Before connecting to a Room

Get an API Key

You’ll need an API key which is associated with your Mission Control Portal account under API Keys. You can learn how to do that here. An API key is your credential to access our API. It allows you to:
  • to authenicate to the Rest API
  • to manage your access tokens

Create a Room to join (if it doesn’t exist)

In order to join a room you must create it, if it doesn’t already exist. See our Room Rest API to create one. There’s also additional resources on other endpoints available to perform basic operations on a Room.

Generate an a client token to join a room

In order to join a room you must have a client token for that Room. The client token is short lived and you will be able to refresh it using the refresh token provided with it when you request a client token. Please see the docs here to learn how to create a client token. Now you are ready to connect to a video room that you previously created using the REST API.

Connect to Room

To connect, you’ll need to provide a participantName that will identify your user in that room. You’ll also need to provide an instance of ExternalData that will contain a username of type String and an Integer id. You will also provide your Android application’s context in context

Publish video/audio stream

To publish as video or audio stream, we will need an instance of PublishConfigHelper with the application context, camera direction, streamKey (unique for each stream published), and streamId (unique for each stream published)
New streams can be created via the PublishConfigHelper class for both audio and video. They can be created together or added later independently.
Since stream is already created, it is only necessary to add the video track to PublishConfigHelper, and “update” the stream.

Remove video/audio track

To remove a video or audio track, publishConfigHelper has to be modified in order to remove the unwanted track

Remove stream

By removing the stream, we will remove all tracks added to it.

Video/Audio Observables

The Telnyx Video SDK for android works with mutable live data, and all the information you need to build your UI is provided through observables that will contain the most up to date information of the state of the room, such as current participant list, talking events, stream information, participants added, participants leaving, etc

State Observable

This observable will provide the current state of a room at any given moment. We will receive a State object that will contain:
action -> “val action: String` is the cause of the latest change of State
status -> val status: String is the status of the Room session, when that action happened
participants -> val participants: List is the list of participants present in a room. A Participant is a UI representation in variables, for an attendee to the room session.
streams -> val streams: HashMap this hash map, contains a track of the currently available streams and the id of the publisher streaming them. A stream, will contain tracks for video, audio or both.
publishers -> val publishers: List This will track all publishers in the room. A Publisher is an instance of an attendee or participant sharing some stream content in the room. A single Participant, sharing multiple streams can be also linked to multiple Publisher ids.
subscriptions -> val subscriptions: List Each time a publisher starts streaming information, we will have the option of subscribe/unsubscribe to/from it. This list will track all the subscriptions.

Event observables

Some observables will have a MutableLiveData of Event. Event is a wrapper of LiveData, and provide the means to ensure we only handle an observable once, no matter how many times we’re set to observe it. If the contents have already been handled, we won’t get that content again, unless we peekContent() instead.

Participants Observable

This mutable list will be received as soon as we join a Room session, and contains a list of the participants already present in the room, including yourself. The SDK will keep this list updated but won’t post the changes, so this observer won’t be fired again. See Participant By receiving this list we can initialize a recycler adapter in order to show participants:

Joined Room Observable

This mutable will fire an event as soon as we have connected to a room, and we have retrieved an initial list of Participants It is useful when we want to update UI as soon as we have joined the room sucessfully. This will be different to Status-CONNECTED that will be issued when we have successfully joined our plugins to handle session audio. See Status.

Joined Participant Observable

We receive the participant that has joined the room after client has already joined. We can add the this reference to the list used in our adapter as:

Leaving participant id Observable

We receive the publisherId that has leaved the room, and a reason for its exit (“Left” or “Kicked”).

Connected to room Observable

Receive true when we have opened a webSocket and connected to the room

Participant stream changed Observable

We will receive here an event with the participant that has recently changed its video and/or audio stream status. Mutable list of participants will also be updated with this change, but here the specific individual is received.

Stream status

These status apply for audio, video and shared screen: UNKNOWN : initial status. We don’t have information on whether this participant is sharing audio/video/screen ENABLED : the participant is sharing audio/video/screen and we can subscribe to a stream for it like: DISABLED : the participant is not sharing audio/video/screen. If we were subscribed to that participant audio/video/screen we can unsubscribe from it.

Subscribe to a video stream

In order to subscribe to a video stream, there are 3 actions that needs to be performed:
1 Provide the SDK with the same instance of SurfaceViewRenderer you want to init:
This will use the proper WebRTC Connection to provide an EglContext for the surface to be init 2 Use method addSink() to add a SurfaceViewRenderer instance to the videoTrack provided for a Participant, and set that track to enable videoTrack?.setEnabled(true) 3 Subscribe to the stream a participant is providing
participantId is the participant id that uniquely identifies a single participant in the room streamKey i.e: “SharingSubscriptions” “CameraSubscriptions” streamConfig whether we want to subscribe to audio/video or both. By default we will attempt both.

Remove subscription to a *video stream

To remove a subscription we need to issue
A good practice when handling surfaces is to make sure you remove this surface properly from the rendering context before eliminating or removing the surface from the UI:

Participant Talking Observable

We will receive the participant that has updated its talking status, and the stream key. This information is also modified in the Participants list

Stats

We provide the method getWebRTCStatsForStream() to retrieve WebRTC stats This request brings stats one time only, so if you want to keep receiving stats, you will need to use some sort of runnable or coroutine to recursively request for them such as:
We have to provide participantId, streamKey that is the key that identifies the stream we need the stats from, and callback that is an RTCStatsCollectorCallback we provide to the WebRTC peer connection in order to retrieve the stats. In Kotlin, method call will look like this
We can later parse the information retrieved to obtain the specific information we go after. In our sample app, you will see the models we use for audio and video, both local and remote

Remote Video stats

WEBRTC’s RTCStatsReport can be parsed and mapped to RemoteVideoStreamStats

Local Video stats

WEBRTC’s RTCStatsReport can be parsed and mapped to LocalVideoStreamStats

Remote audio stats

WEBRTC’s RTCStatsReport can be parsed and mapped to RemoteAudioStreamStats

Local audio stats

WEBRTC’s RTCStatsReport can be parsed and mapped to LocalAudioStreamStats

iOS SDK

Source: https://developers.telnyx.com/docs/video/ios-client-sdk.md
The Telnyx Video iOS SDK provides the functionality you need to join and interact with a video room from an iOS application. iOS SDK

If you prefer to jump right in

Have a look at our demo app: Telnyx Meet.

An overview of the Video API

These are important concepts to understand.
  • A Room represents a real time audio/video/screen share session with other people or participants. It is fundamental to building a video application.
  • A Participant represents a person inside a Room. Each Room has one Local Participant and one or more Remote Participants.
  • Room State tracks the state of the room as it changes making it extremely easy to understand what’s happened to a Room.
    • Room State could change due to a Local Participant has started publishing a stream or because a Remote Participantleft.
  • A Stream represents the audio/video media streams that are shared by Participants in a Room
    • A Stream is indentified by it’s participantId and streamKey
  • A Participant can have one or more Stream’s associated with it.
  • A Subscription is used to subscribe to a Stream belonging to a Remote Participant

API of a Room

This should give you high level overview of the Room API and it’s functionality.
After pasting the above content, Kindly check and remove any new line added

Events that are triggered in a Room

Here’s a list of events that will fire as you make API calls.
After pasting the above content, Kindly check and remove any new line added

Understanding the state of the Room

Everything in the SDK centers around the Room object. When the state of the Room changes (e.g. a new participant joins or a remote participant starts publishing a stream) the onStateChanged event is triggered. The event is invoked with a state parameter which contains the current of the state of the Room.
After pasting the above content, Kindly check and remove any new line added

Before getting started

Install the SDK

Currently, the Telnyx iOS Video SDK can be installed using CocoaPods. For instructions on that check out our releases repo for iOS

Get an API Key

You’ll need an API key which is associated with your Mission Control Portal account under API Keys. You can learn how to do that here. An API key is your credential to access our API. It allows you to:
  • to authenicate to the Rest API
  • to manage your access tokens

Create a Room to join (if it doesn’t exist)

In order to join a room you must create it, if it doesn’t already exist. See our Room Rest API to create one. There’s also additional resources on other endpoints available to perform basic operations on a Room.

Generate an a client token to join a room

In order to join a room you must have a client token for that Room. The client token is short lived and you will be able to refresh it using the refresh token provided with it when you request a client token. Please see the docs here to learn how to create a client token.

Code Examples

Enough already let’s get to the code. Here are some code examples to get your wet feet on how to start building something with the iOS video SDK.

Participating in a Room

Connect to a room

First, you’ll need to create a Room instance and then connect to it. Once you’re connected to a room, you can start sharing audio/video streams with other participant in the rooms. Important Note: This simply creates an instance of a Room in code it does not use the Rooms Rest API to create a room, mentioned above in “Create a Room to join”*
After pasting the above content, Kindly check and remove any new line added Once the room is connected you’ve joined the room as it’s local participant. You can see this more clearly by, after connecting, get the local participant. Important Note: Room only has one Local Participant but can have multiple Remote Participants.
After pasting the above content, Kindly check and remove any new line added

What is Room context?

Context is any details you want to include about the LocalParticipant of the Room. For instance, let’s say you want to use context to identify a Participant with fields from an external system. You could pass a userId and username as context, like the code snippet above. These details will be available to all RemoteParticipants in the Room, when they are notified about your presence in the Room.

Working with local media

Publishing audio and/or video from your camera or microphone works by using MediaDevices. MediaDevices is a helper class that we provide for you to make it easy to grab local media from your device.
After pasting the above content, Kindly check and remove any new line added

Setting the quality of the local video

You can set the camera resolution and fps using MediaDevices.
After pasting the above content, Kindly check and remove any new line added Note: If you choose highest resolution and fps, the local video stream will lag if you have poor internet / bandwith

Publishing a stream

Once you have tracks from say, a local media device like video from a camera and/our audio from your micrphone you can use those to create a Stream and publish it in the Room.
After pasting the above content, Kindly check and remove any new line added

Unpublishing a stream

If you can longer want to continue publishing a stream you can unpublish it. Naturally the stream you want to unpublish must be added already.
After pasting the above content, Kindly check and remove any new line added

Working with Remote Participants and Streams

A remote participant who joins or leaves the room

When a remote participant joins a a room you will be notified with the Room.onParticipantJoined event. And similiarly with Room.onParticipantLeaving when a remote participant leaves. You can use these events to keep track of participants in the room.
After pasting the above content, Kindly check and remove any new line added

Remote participants already in the room

When you connect to a Room there may already be remote participants in the Room. To understand who is in the Room after you connect use the onParticipantJoined event.
After pasting the above content, Kindly check and remove any new line added

Display a remote participant’s media

In order to understand how to display a remote participants’ media let’s review on subscriptions work in the API. It might be helpful to review the Video API overview to get a better understanding of how a Room is modeled, especially Stream and Subscription. Major 🔑 about Subscriptions In order to display media from a remote stream you need to subscribe to it. It’s important to understand that your Room doesn’t automatically subscribe to a remote stream being published. It’s your choice to decide whether to subscribe to a given stream.

Subscribing to a stream

So let’s say the app your building has two users - let’s them call them Alice and Bob. First, Alice joins the Room and starts publishing a stream with audio from her microhone and video from her camera like this: NOTE: The app on Alice’s device runs the following code…
After pasting the above content, Kindly check and remove any new line added Bob wants to get Alice’s stream so he can display it. In order to do so he needs to subscribe to Alice’s stream. NOTE: The app on Bob’s device runs the following code…
After pasting the above content, Kindly check and remove any new line added

Handling remote streams that are already publishing in the Room

After you connect to a Room there may be remote participants already in the Room who are publishing streams in the Room. To deal with that use the onStreamPublished event:
After pasting the above content, Kindly check and remove any new line added

Disconnecting from a Room

To disconect from a room do:
After pasting the above content, Kindly check and remove any new line added When you disconnect from a Room all Remote Participant’s will be notified that you’ve left the Room because the Room.onParticipantLeft event will fire on their Room instance.

API Reference (Video)

Room Compositions

Room Participants

Room Recordings

Room Sessions

Rooms

Rooms Client Tokens

  • Create Client Token to join a room.: Synchronously create an Client Token to join a Room. Client Token is necessary to join a Telnyx Room. Client Token will expire after token_ttl_secs, a Refres…
  • Refresh Client Token to join a room.: Synchronously refresh an Client Token to join a Room. Client Token is necessary to join a Telnyx Room. Client Token will expire after token_ttl_secs.