I’ve searched the forums as thoroughly as I can and am hoping this particular question has not been answered before
I’m currently trying to port an existing media server backend to mediasoup and the existing system runs in multiple regions. When a client connects to one of my existing media servers, it starts by generating an sdp offer, it sends the offer to my matcher service via an HTTPS request, which identifies the ideal region for the client’s room, asks the region directly to create a room and supply an sdp answer, and then responds to the client’s request with that answer. The client can then use the answer to open its webrtc connection directly with the media server and any future signaling for audio/video is done via a data channel.
This works great, but is incompatible with how mediasoup’s client libraries require the client to be the answerer for receive transports. I’d have to put in multiple requests to our matcher service which would be too expensive and is not designed for continuous signaling.
My original idea was to use the matcher signaling to establish a data channel via mediasoup, and then use that data channel for all signaling for the video send/receive transports. However, it looks like those also use separate DataConsumer / DataProducers.
So my question is: can I use a DataConsumer/DataProducer on the same transport with mediasoup-client in order to establish my signaling data channel?
I imagine the answer to that question will be “No.” - My follow-up question would be, would you recommend using vanilla webrtc for this data channel connection (as it seems the server doesn’t have this limitation), or should I just use a web socket and essentially create my own offer/answer protocol to establish the web socket connection securely and ensure only entitled clients can connect to room servers.
I prefer the webrtc datachannel approach because it uses the same protocol and I know that if the connection is established that future transports will also be able to connect, but I understand it might not be worth fighting to keep.
I did have an app that was originally connected with single HTTP request and was then using data channels for all communication, but with migration to mediasoup I switched to WebSocket, which is easier to handle (both send/receive buffering and handling disconnections).
Not in current v3 due to its design. We may change this in v4.
If you do that you should also implement your own logic to extract ICE and DTLS info from your local PeerConnection to provide mediasoup’s WebRtcTransport with it, and you should also generate a remote SDP for your PeerConnection based on the mediasoup’s WebRtcTransport information (which is basically what mediasoup-client does out of the box).
Nothing prevents you (other than your already existing code) from using mediasoup-client to create a DataProducer and DataConsumer, and then use them to signal audio/video Producers and Consumers. However, before you even create the DataProducer you need to provide your mediasoup-client with the Router’s rtpCapabilities and then must create a send and recv Transport with the information of server side WebRtcTransports.
The more time I spend on it the more I think the websocket approach is going to be the most straight-forward and ideal for future-proofing. Thanks for the info!
There is something nice about signaling going over the same transport as the media streams - for example some adaptive firewalls do silly stuff with the RTP but let websocket traffic through unscathed, which can be confusing. Or they will drop a websocket, but the DTLS transport will be fine.
At the same time sometimes it’s nice to have out of band communication with the server.
In recent times I’ve been leaning toward REST for bootstrapping the transports and out of band communications, and data channels for media signaling.
REST for bootstrapping and data channels from then on out was my original approach. It works well in our existing systems and I really like it, but one reason I opt’d for websockets for signaling is that I think it will help me diagnose clients that block UDP / webrtc traffic. I can then display a more informative error on the client side if the web socket can connect, but the webrtc transport can’t.
In my experience the really nasty firewalls don’t block the media stream transport creation, they let the connection establish (and maybe even let media flow for a little bit) before doing their shenanigans. But that’s probably a topic for another day.
I wonder, though, if there might be a section of a wiki somewhere, or a thread on here where we could pool our collective knowledge of bad acting firewalls. I’d be interested in contributing what I could, there.
I’d love that. At some point way down the road, I’d love to build analytics into our applications that can report connection issues in the wild. Would be interesting to see what affects different people’s applications and how they solved it.
