Remote Mediasoup client
Remote Mediasoup client
This project host a class that allow to connect to servers offering the
Remote Mediasoup
API, like
Remote Mediasoup server,
Mediasoup proxy, and
Mediasoup cluster. Once connected, it
provides the same API that
Mediasoup, but using remote instances instead of a
local one. This allow to use the same code in both cases, and easily migrate
from one to the other, opening the door to scale your Mediasoup
based
application without having to change your code.
Install
npm install --save @mafalda-sfu/remote-mediasoup-client
API
See API documentation.
Usage
If you already have a Mediasoup
based project, to use
Remote Mediasoup client
on it you’ll only need to do two changes in your
project code:
-
Replace the
mediasoup
import forremote-mediasoup-client
:- import mediasoup from 'mediasoup' + import RemoteMediasoupClient from 'remote-mediasoup-client'
-
Create the instance of the
RemoteMediasoupClient
object, wait for itsconnected
event, and access to themediasoup
property:+ const remoteMediasoupClient = new RemoteMediasoupClient('ws://example') + + await once(remoteMediasoupClient, 'connected') + + const {mediasoup} = remoteMediasoupClient
After that, the mediasoup
variable will have an object that’s API compatible
with the Mediasoup API
provided by the Mediasoup
package.
Known bugs (AKA “features”)
- On Mediasoup API,
close()
method (andsend()
method, and also change of content ofappData
properties) fromMediasoup
objects are synchronous, once you call them, they are done. This is not true onRemote Mediasoup client
, since internally they are sending a request to the server, and also it’s possible to have multiple clients connected to the same server calling to them. If you are using only one client, you can assume that the changes will be done, the same as with normalMediasoup
, but if you are using multiple ones (also from the same server application instance), you need to listen to theclose
event of the objects. This will allows you to keep you application state synchronized with the server state, otherwise you could think oneMediasoup
object is alive, without knowing it was closed by another client instance. - Mediasoup
workerBin
and Workerspid
fields are provided directly by the server we are connected. These can have different values of the ones that would be provided by a localMediasoup
instance, for example having hints about the server that’s running the worker by using a “fake” PID beyond the operating system max limit ones or providing an URL with a domain instead of just only a path, so you must not assume they are relative to the server where your application code is running as would happen with a localMediasoup
instance, or that they are valid ones at all without processing them first.