-
Notifications
You must be signed in to change notification settings - Fork 50
VideoCall plugin documentation
This is a plugin to set up a media server cluster for video call (VOIP), based on Janus-gateway server. It keeps the same API with the videocall plugin of the orginal Janus-gateway except that only the websockets transport is supported by Janus-cloud. The video calls between the caller and callee, are distributed to the backend different Janus-gateway servers by this plugin, so that much more video calls can be processing at the same time.
The following diagram shows how the videcall plugin works in single proxy mode
+----------------+ +----------------+
| | | |
+------->+ JanusA +<---------+ | JanusB |
| | | | | |
| +--------+-------+ | +----------------+
| ^ |
| | |
| | |
| |WS |
| | |
| PeerConnection | | PeerConnection
| | |
| +--------+--------+ |
| | | |
| | Janus-proxy | |
| | | |
| +----+--------+---+ |
| ^ ^ |
| | | |
| WS| |WS |
+-------+-------+ | | +--------+------+
| Alice +-----+ +----+ Bob |
+---------------+ +---------------+
Alice(from browser) make the WS connction with janus-proxy, attaches a videocall handle and register himself. Bob also make the WS connction with janus-proxy, attaches a videocall handle and register himself too. At a moment, Alice make a call to Bob by sending a call request to janus-proxy. Janux-proxy firstly select one of the valid backend Janus server (e.g. JanusA) to deal with this call according its selection algorithm. Before relay the call request to JanusA, Janux-porxy attach a new videocall handle for JanusA on behave of Alice and register Alice for this handle. On the other hand, Janus-proxy attach another videocall handle for JanusA on behave of Bob and register Bob for that handle. After that, Janux-proxy relay the call request to JanusA on behave of Alice, which results in Alice makes the peerconnection with JanusA , Bob makes the peerconnection with JanusA, and they change their media through JanusA at the end.
Janus-proxy can dipatch different video calls to the different backend Janus server, so it has been scaled out.
In single Janus-proxy mode, thousands of calls can take effects concurrently, but how if more calls are required, e.g. millions of calls? The following diagram shows how muliti Janus-proxy mode works.
+--------------------------------------------------+ +--------------------------------------------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| +------------------+ +--v--------v----+ +------------------+ |
| | | | | | | |
| | JanusB | +-------------->+ JanusA +<-------------+ | JanusC | |
| | | | | | | | | |
| +------------------+ | +----------------+ | +------------------+ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | +----------------+ | |
| |WS | Redis cluster | |WS |
| | +---^-------^----+ | |
| Peer | | | | Peer |
| Connection | | | | Connection|
| +--------+--------+ | | +--------+---------+ |
| | +----------+ +----------+ | |
| | Janus-proxyA | | Janus-proxyB | |
| | +-----------------------------> | |
| +----+------------+ Rest API +----------+-------+ |
| ^ ^ |
| WS| |WS |
| | | |
| +-----+---------+ +-----+---------+ |
+---------------------+ Alice | | Bob +------------------+
+---------------+ +---------------+
Alice(from browser) make the WS connction with janus-proxyA, attaches a videocall handle and register himself. Bob make the WS connction with the other janus-proxyB, attaches a videocall handle and register himself. At a moment, Alice makes a call to Bob by sending a call request to janus-proxyA. Janux-proxyA firstly select one of the valid backend Janus server (e.g. JanusA) to deal with this call according its selection algorithm. Before relay the call request to JanusA, Janux-porxy attach a new videocall handle for JanusA on behave of Alice and register Alice for this handle.On the other hand, Janus-proxyA find out Bob has registerd at Janus-proxyB through Redis, so Janus-proxyA invoke Janus-proxyB's RESTful API to instruct it to attach a videocall handle for JanusA on behave of Bob and register Bob for this handle. After that, Janux-proxy relay the call request to JanusA on behave of Alice, which results in Alice makes the peerconnection with JanusA , Bob makes the peerconnection with JanusA, and they change their media through JanusA in the end.
Different user could register himself on different Janus-proxy (by loadbalance or business), which makes Janus-proxy scalable and processing much more video call.
this APIs is compatible with the videoroom plugin of Janus-gateway util v0.10.7(2020-10-30)
This chapter would describe some features of this Videocall plugin, about What, Why, How.
Different from Janus-gateway videocall plugin, user info is stored in memory or a redis DB in Janus-proxy to support the cluster application, which need to deal with millions of user registration. For this Videocall plugin, Memory DB is used for single proxy mode as well as redis DB is used for multi proxy mode.
DB url format which is set in the plugin's configuration file：
For memory db:
memory
For Redis,
redis://{user}:{secret}@{hostname}:{port}/{db_id}
For the orginal videocall plugin of Janus-gateway, if some username has been registered for a handle, it cannot be registered (for the other handle) anymore. But this mechanism cannot work on the real internet environment in which connections often break for various reasons. If username re-registration is forbidden, the user must wait for a long time(until the old handle is automatically detached because of session timeout) before he can re-register his username (and wait/make for a call) again. It is absolutely not a good experience for the real-world voip user so that username re-registration is allowed for the this videocall plugin. In this plugin, username can be registered for any handle at any time even though it has been registered for the other handle in which case the new handle owns this username as well as the orginal handle give it up. This strategy makes the user restore online more quickly even in the unreliable network environment.
In constrast to the original videocall plugin of Janus-gateway, this plugin support a new asynchronous request "exists", which is used to check some username is registered or not. The "list" request is not suitable for the case of massive videocall users which would block the whole database. If the user want to check some username is online, he should use this "exists" request instead of "list".
The exists request has to be formatted as follows:
{
"request" : "exists",
"username" : "<username to check>"
}
If successul, a result would return to indicate the username is registerd or not.
{
"videocall" : "event",
"result" : {
"username" : "<username to check>",
"registered": <true|false>
}
}
In this chaper, some shortages about the this plugin would be listed.
For the "list" request, the plugin need to traverse the whole user database where the db and the proxy would be hang if there are a huge number of registered username. So for the case that redis db is used, only one thousand username at most can be returned. Remember, never use "list" request in the real application.