VidyoWorks Client Library to Vidyo.io Migration Guidance

The main purpose of this article is to explain the differences between basic call connect flow if you look to migrate from VidyoWorks Client Library to the Vidyo.io platform.

VidyoWorks sequence to join a call

The diagram below shows a sequence of steps involved in joining a video conference room as a guest using VidyoClient library3.x. Note that in the VidyoWorks solution, to have a video conference you first need to either have an existing virtual “room” already created or you need to create a virtual “room” to connect to.

 

Let’s look at these steps in detail -

1. In step 1, the user clicks some kind of UI button or method to join a call.
2. In the case of a guest user, the application will not have access to create or query the room directly. It will query its backend for the room link
3. The application backend will have to either create a scheduled room or query an existing room link from the VidyoPortal.
4. & .5 Once we have the room link to join, we initialize the VidyoClient, start it and use the InEventRoomLink event to join the room

 

In case of VidyoWorks there is an added concept of “room” objects that the application and the application backend needs to be aware off. Which can further complicate the solution. Apart from that the application also has to deal with VidyoPortal web service to complete the functionality.

  

Vidyo.Io sequence to join a call

Joining a video conference has been simplified on the Vidyo.IO platform. The application only deals with the Vidyo.IO SDK and no longer needs to worry about the VidyoPortal web service. This drastically simplifies the application level code since there are no SOAP messages to deal with and every interaction with the VidyoClient library can be done with simple objects and their methods.

 

1. When the guest user wants to start or join a video conference then first click on a UI element like a call join button.
2. To connect to a Vidyo.IO room we need two key properties, Valid Token & ResourceID, the resource, details of both are described below.
3. The backend application server creates a new token and selects a room name to join to.
4. & 5. Once we know which room to join we create the VidyoConnector object and call the connect method on it to join the video conference.

 

Token

A token is an alphanumeric string used by the vidyo.io platform to authenticate the user. The token is generated using your developer key, app ID and expiry duration. Instead of storing this developer private information on the client code, we always recommend generating the token on the backend. So in this case the VidyoHelper class will call the backend server requesting the token and resourceID. Samples on how to create a token are shared here –

https://github.com/Vidyo

https://developer.vidyo.io/documentation/4-1-12-8/getting-started#Tokens

A token duration can be short lived, just enough to ensure that it is valid when the connect call is being made. If the token expires while the user is still in the call, they will continue to be in the call and will not get kicked out.

ResourceID -

The resourceID is an alphanumeric string, which identifies the videoconference room. To be in the same videoconference room you need to have the same resourceID string value.  If two users, say “userA” and “userB”, want to have a videoconference, we need a common room for them to connect, something like “roomUserA” or “roomUserAUserB”.  You can either create these rooms on the fly, or have predefined room string values associated with your users.

From the vidyo.io perspective these are just string values. The diagram above shows logic where the backend server suggests a resourceID based on the user.