Rust port of mediasoup TypeScript library!
For general information go to readme in repository.
If you were using mediasoup in TypeScript before, most of the API should be familiar to you. However, this is not one-to-one port, API was adjusted to more idiomatic Rust style leveraging powerful type system and ownership system to make API more robust and more misuse-resistant.
So you will find specific types in most places where plain strings were used, instead of
close() you will see
Drop implementation for major entities that will close everything
gracefully when it goes out of scope.
This is very low-level library. Which means it doesn’t come with a ready to use signaling mechanism or easy to customize app scaffold (see design goals).
It is recommended to visit mediasoup website and read design overview first.
There are some requirements for building underlying C++
mediasoup-worker, please find them in
There are some examples in
examples-frontend directories (for server- and
client-side respectively), you may want to look at those to get a general idea of what API looks
like and what needs to be done in what order (check WebSocket messages in browser DevTools for
better understanding of what is happening under the hood).
With that in mind, you want start with creating
instance and then 1 or more workers. Workers a responsible for low-level job of sending media
and data back and forth. Each worker is backed by single-core C++ worker thread. On each worker
you create one or more routers that enable injection, selection and forwarding of media and data
transport instances. There are a few different transports available, but most likely
you’ll want to use
WebRtcTransport most often. With
transport created you can start creating
Producers to send data to
Consumer instances to extract data from
Some of the more advanced cases involve multiple routers and even workers that can user more than one core on the machine or even scale beyond single host. Check scalability page of the official documentation.
Please check integration and unit tests for usage examples, they cover all major functionality and are a good place to start until we have demo apps built in Rust).
An audio level observer monitors the volume of the selected audio producers.
A consumer represents an audio or video source being forwarded from a mediasoup router to an endpoint. It’s created on top of a transport that defines how the media packets are carried.
A data consumer represents an endpoint capable of receiving data messages from a mediasoup
A data producer represents an endpoint capable of injecting data messages into a mediasoup
Miscellaneous data structures.
A direct transport represents a direct connection between the mediasoup Rust process and a
A pipe transport represents a network path through which RTP, RTCP (optionally secured with
SRTP) and SCTP (DataChannel) is transmitted. Pipe transports are intended to intercommunicate
A plain transport represents a network path through which RTP, RTCP (optionally secured with SRTP) and SCTP (DataChannel) is transmitted.
A producer represents an audio or video source being injected into a mediasoup router. It’s created on top of a transport that defines how the media packets are carried.
A router enables injection, selection and forwarding of media streams through
An RTP observer inspects the media received by a set of selected producers.
Collection of RTP-related data structures that are used to specify codec parameters and capabilities of various endpoints.
Collection of SCTP-related data structures that are used to specify SCTP association parameters.
Collection of SRTP-related data structures that are used to specify SRTP encryption/decryption parameters.
RTP capabilities supported by mediasoup.
A WebRTC transport represents a network path negotiated by both, a WebRTC endpoint and mediasoup, via ICE and DTLS procedures. A WebRTC transport may be used to receive media, to send media or to both receive and send. There is no limitation in mediasoup. However, due to their design, mediasoup-client and libmediasoupclient require separate WebRTC transports for sending and receiving.
A worker represents a mediasoup C++ thread that runs on a single CPU core and handles
Container that creates