-
Notifications
You must be signed in to change notification settings - Fork 18
Home
SMB performs a number of expected and necessary tasks of an SFU and to some extent MCU. But there are a few things that deserve some attention.
- Hybrid meetings with both SFU and MCU participants
- Very large meeting support without repeated signalling to already connected users.
- Extremely large meeting support over several SMBs using barbell connections, aka cascading.
- Integrated accurate bandwidth estimation for both directions. This enables people on limited networks to participate in meeting without saturating the network.
- Neighbour support where participants in the same acoustic group will not hear each other. Avoids acoustic double talk.
- Geo routing support to find the closest SFU.
- Highly efficient internal load balancing using a few wait-free concurrent data structures.
Allocating and configuring resources on Symphony Media Bridge (SMB) is done through a HTTP api on localhost port 8080. The port used is configurable.
The two main resources that can be allocated on SMB are conferences and endpoints. A conference consists of a group of endpoints (clients) that will forward media to the conference and receive media from the conference. Empty conferences will be removed automatically after a certain timeout. Endpoints can be removed explicitly or be deleted after a certain time of inactivity.
SMB is typically used in conjunction with a conference signalling server. The signalling server will be responsible for SMB resource allocation and configuration. Clients only communicate with SMB directly by sending and receiving media. Configuration of SMB should be done by the signalling server only.
When setting up a new conference with the first client, the flow of operations on SMB is typically
-
Allocate a conference.
-
Allocate an endpoint for the client. SMB responds with transport information that can be used to create and SDP offer to the client.
-
Configure the endpoint using information from the clients SDP answer.
The conferencing system (signalling server + SMB) is typically always the one sending the initial SDP offer.
After setup, a client can reconfigure its endpoint (enabling or disabling audio or video).
When media is flowing between a client and an SMB endpoint, the client and SMB can communicate using data channel messages. Data channel messages are sent in a JSON format. The different types of messages are:
An array of endpoint ids, notifying the client about the endpoint ids of the video streams currently being forwarded.
The endpoint id of the audio stream currently considered as the most dominant speaker.
SMB can forward data channel messages from clients, and also broadcast message from a client. This is used to support intra-conference messaging.
This is used to communicate which video stream endpoint id the client wants to "pin". Pinning means the video stream for that endpoint id will be forwarded as high quality when simulcast is used.
SMB supports incoming Simulcast video streams from clients. The highest available quality layer will be forwarded for the pinned endpoint, and a lower quality layer will be forwarded for all other endpoints. Currently, only Simulcast with locally modified SDP and a SIM SSRC group is supported (SDP munging).