LiveSwitch SDK Simple Calling Workflow

Discover an efficient approach to handle call workflows using the LiveSwitch SDK. This blog post presents a guide along with visual representations to help you streamline the calling process in your application. Experience the power of LiveSwitch for real-time communication and elevate your app with seamless voice and video calling capabilities.

Workflow

Step 1: Registering to LiveSwitch with a Signalling Channel

1. Request a token from your app server for the signalling channel.
2. Obtain the registration token from the app server, containing a dedicated signalling channel.
3. Register the user to the signalling channel in LiveSwitch, marking them as online.

Note: The signalling channel must be the same for every user who is able to see each other. For instance, an organization can share a common signalling channel, while each organization will have a different one.

Use Join/Leave events to update users' online and offline statuses. Upon registration, a list of users within the channel will be returned to set their current status.

Step 2: Initiating a Call between User A and User B

1. User A sends a call request to User B via the App Server.
2. The App Server verifies the request and checks User B's availability.
3. Using the LiveSwitch REST API, the App Server sends "join" tokens to both User A and User B.
4. User A and User B receive the "join" tokens and utilize them to connect to a new channel.
5. Once both users are connected, a basic conference workflow is established using WebRTC.

Note: Join tokens can have any channel ID, preferably a randomly generated GUID. The App Server will be in charge of updating users' availability.

Channels are dynamic and created on-the-fly, and exist only as long as there is a user inside them. Adding additional users, such as User C, to an ongoing call simply requires sending them a join token with the same channel ID as User A and User B.

Optional Improvements

1. The App Server can store a temporary channel for User A and User B, monitoring webhook events on channel client-join/client-leave to update user availability.
2. Monitoring webhook events on the primary signalling channel (client-join and client-leave) or using client-register/unregister webhooks can help maintain accurate online/offline status for users.

Basic Idea Behind the Workflow

Users connect to a main signalling channel solely responsible for distributing tokens. They listen for tokens on this channel and utilize them to join other channels within LiveSwitch. The SFU upstream and downstream connections are automatically established when joining channels other than the primary signalling channel. By keeping the logic on the backend server, the client application remains simple, minimizing complexity and reducing potential issues. This approach streamlines the call workflow and ensures a smooth user experience.

Security

When creating initial tokens for users in the primary channel, it is advisable to restrict their messaging capabilities. This can be achieved by setting the DisableSendMessage property on the ChannelClaim of their JWT token. Disabling SendData, SendVideo, and SendAudio on the channel further strengthen security. For more information, refer to the ChannelClaim documentation.

Need assistance in architecting the perfect WebRTC application? Let our team help out! Get in touch with us today!