There is something I don’t understand with the current API. A lot of work remains in the hand of the user to implement mediasoup. It also require a very good understanding of all the elements of mediasoup (Transport, Consumer, Provider, Room, Peer…). But I think that we could make things a lot easier without making mediasoup more dependant of the signaling method. We would just have to provide mediasoup with a function to contact the peers or the server.
Here is what the client-side API could look like:
// Provide mediasoup with our signaling protocol
const mediasoup = new Mediasoup({
sendToServer(data => {/* the code that sends data to the server */},
sendToPeer((peerId, data) => {/* the code that sends data to the peer peerId */})
})
// Receive the messages from the signaling protocol
// Here we expect mediasoup to receive messages from mediasoup server or from other peers and handle them.
whateverSignalMethod.on('whatever event name', mediasoup.receiveMessage) // Here we transfer to mediasoup any message that we received from the signaling process.
Now, Mediasoup is able to communicate with the server and with the peers. There is no more needs for the user to handle all the exchange of information by himself.
We can now provide a much easier API that don’t require the user to understand everything about Transports, Peers, Rooms, Consumers, Providers and such. For instance:
mediasoup.createRoom: (id: roomId) => Room; // This create a room and fail if it exists
mediasoup.joinRoom: (id: roomId) => Room; // This join a room and fail if it doesn't exist
mediasoup.joinOrCreate: (id: roomId) => Room; // This should join a room or create it if it doesn't exist
room.on('newPeer', peer => void) // Handle new peer joining the room
room.on('newTrack', ({type: 'audio' | 'video', track: MediaStreamTrack}) => void) // Handle newly available track
room.addTrack(track: MediaStreamTrack) // Share a track with the room
room.removeTrack(track: MediaStreamTrack) // Stop sharing a track with the room
You are basically imitating the “mediasoup protocol” of mediasoup v2 which was removed in v3 for good reasons.
mediasoup v3 is low level. The user needs to understand everything about Transports, Producers and Consumers. That’s intended. And BTW there are no Peers, Rooms or Providers in mediasoup architecture.
In short: this is not gonna happen. Feel free to design your signaling mechanism and message format for your app, but you need to understand the low level API exposed by mediasoup.
It is just that I don’t understand why. Madiasoup protocols requires exchanging data between different instances on different machines. If I do it myself, it means that every little bit of change within mediasoup protocol will break all the apps using it. If I just provide a method for the instances to communicate with eachother, you can change the protocol as much as you want, as long as the instances are sharing the same version, they will still understand eachother.
So if a web client sends 8000 messages to create 8000 WebRtcTransports in mediasoup server side (which will allocate at least 8000 ports in the server) should mediasoup just honor them without the user Node app in the server being aware of it?
Anyway I’m afraid this is not gonna happen. It was already like that in mediasoup v2 and we removed it for many reasons based on the experience.
Yes, you must read the documentation and make your signaling mechanism send proper data. However the API is stable and new additions do not break apps.
The node app would be aware of it using usual event based mechanism. Anyway, low level API are always the first step, followed by higher level API with higher level of abstraction. My issue right now is that the changes between v2 and v3 are so huge that I’m worried that v3 and v4 might have the same issue, but if you are 100% sure that the API won’t change and won’t break existing apps like v2 to v3 did, then I guess that I can start creating a wrapper for mediasoup to make it more user-friendly.
I never said that the signaling protocol should be provided BY mediasoup. I said it should be provided TO mediasoup. Meaning that Mediasoup should receive the signaling protocol as a parameter. I totally agree that Mediasoup should stay agnostic.
Having a super low level API has its advantages and disadvantages. It looks like the designers have chosen this path for their good reasons. But it is important that the design principles should not keep changing drastically, unless the intent is to limit the expertise to a small group.
@Sharcoux, I will be interested looking at your wrapper. It looks like most of the v2 “mediasoup protocol” was moved out to protoo, but if you can could you please try using socket.io. Look at the other demo that is posted on the mediasoup page. Please post on github if you get it done.
What I mean is that no changes have been made to protoo for mediasoup v3, both are completely unrelated projects. protoo is used by the mediasoup-demo v3 in a similar way as it was used in the mediasoup-demo v2.
Ok, thanks for the clarification. In that case maybe the concept of "room and “peers” was redundant in mediasoup v2. Not having this concept directly tied to mediasoup v3 also means that v3 can be used in many more contexts. Also I have nothing against protoo, just slightly more familiar with socket.io.
I appreciate the depth of the v3 API documentation. Could I suggest making a diagram to illustrate the client-server communication process?
Always important to point out. I work with both mediasoup and Twilio, and while Twilio is 100 times easier to implement, you are at the mercy of the devs a lot of the time if you want to get something special/fancy done. At least on the Android-side you are also still stuck with classes and concepts of WebRTC that have been deprecated for almost two years already, probably due to the very reason we see here (users getting mad for API changes). It’s definitely true that mediasoup is more of an “enthusiast”-library that requires some actual knowledge, but in the WebRTC world it’s imho very advisable to have at least a basic understanding of what you are using, otherwise you cannot even make your bug reports informative enough and blame libraries for every tiny network issue you stumble upon or browers behaving weird.
There is a “Communication between client and server” section in the docs. Honestly we are not good ad making diagrams and personally I don’t have much time to do it for now.
There is no a single/unique way to communicate mediasoup client and server. Understanding that is a good starting point. Other than that, there are simple rules:
you create the transports in the server and replicate them in the client.
you create the producers in the client and replicate them in the server
you create the consumers in the server and replicate them in the client