2

Looking for suggestions to see, is it possible to implement a "call waiting" feature using the Agora WebSDK? We have a live cast where the host receives audience call in during the show. We would like to:

  1. When an audience calls, the call should be put to a queue.
  2. When a caller is on-hold (in the queue) we might send a "hold" music to the caller (but this might not be strictly necessary).
  3. The host can dequeue one caller at a time and answer the call.

I can think of two possible ways we can implement this during the live cast.

  1. One is to have the calling audience re-join the channel as a host once the host accepts the call. But there would be lots of 'hand waiving' in terms of queue management.
  2. The other approach is to use an out-of-band solution such as Twillio. In this case the calling would need to have a separate WebRTC connection.

Any suggestion?

Hermes
  • 2,828
  • 2
  • 14
  • 34
Joe Lin
  • 450
  • 7
  • 20

2 Answers2

2

The "call waiting" feature you are describing is not something that is available out of the box using Agora's Video Web SDK, it is very much possible using Agora's Video SDK along with Agora's RTM Web SDK.

You need to use Agora's Real Time Messaging SDK to provide the signaling layer.

Using RTM Channel Events, can implement the callbacks for every time a user joins or leaves the RTM channel as well as the "channel message" callback.

An audience member can send a channel message "call-in" to all participants and thus appears in the queue on all their screens. Or you can choose to run the queue logic through the admin (to add a layer of moderation).

In this instance once the "call-in" message is received, the Admin user's client can add the user to the queue (or reject if needed). Using channel messages the admin client can send a channel message to the "general channel" with the updated queue details.

The admin user could send a channel message to let all the clients know when a "caller" is chosen to switch roles from audience (on hold) to a broadcaster. This will minimize the "hand waiving" since the admin user sends a single message and all the remote clients can react appropriately.

Hermes
  • 2,828
  • 2
  • 14
  • 34
0

We built something like this for our "backstage" audience connection. We have producers receiving the calls initially, (multiple queues, one for each producer) to qualify the caller in terms of content and quality of audio/video. Those that could proceed, we provide a new channel where they wait until their turn to be promoted to host. Each new queue was for a different location within the show's backstage (again multiple producers/hosts, one at each station, who conducts the interview then moves to the next caller) We made a number of backend services to help protext the queues.

gwhiz
  • 135
  • 9