Does it work with MediaMTX (Whip) and can I choose the destination server with an API?

[romain63110]

I have several MediaMtx Server (Whip). I would like to know if I can use Stunner and how to forward Whip requests to the POD that I want by an API call Which chooses the POD according to the parameters of the URL of the WHIP request.

Exemple:
Url: http://media-srv:8889/mystream/whip?token=zdH67g8Gj

By calling the API with the token we receive the POD id to which the request must be forward

[rg0now]

I'm afraid there's small misunderstanding here as per the workings of WHIP: the HTTP URL is just for signaling, so that the client and the WHIP server can negotiate the parameters of the subsequent WebRTC media connection phase, including, among many other things, the ICE server configuration for the PeerConnection. This is where you have to inject STUNner's TURN URI and credentials and everything will just work.

That being said, we have been pondering for a long time about putting together a WHIP demo with STUNner. Your question will be a good motivation to do that.

[dbason]

One thing to note is that with the way Mediamtx has implemented its signalling there is no way to configure asymmetric ICE. If you add a TURN server to the configuration it will use it for both the client and the server.

Mediamtx integrates the signalling in the server itself so to direct to the correct pod you will need an HTTP reverse proxy that forward the signalling plane requests to the correct pod. Then through the magic of TURN the data stream will be set up to that pod.

[rg0now]

No problem, just set STUNner at both the media server and the clients and things will just work fine. Asymmetric ICE is simpler, faster and generally more robust, that's why we recommend it, but symmetric ICE is always there for you as a safe fallback when asymmetric ICE is not available.

[rg0now]

Mediamtx integrates the signalling in the server itself so to direct to the correct pod you will need an HTTP reverse proxy that forward the signalling plane requests to the correct pod. Then through the magic of TURN the data stream will be set up to that pod.

That's a good point. In LiveKit this reverse proxy function is built into the signaling function itself, which is likewise embedded in the media server, so you don't need the reverse proxy.

Anyway, if you have a functional MediaMTX setup and you're willing to share your YAMLs with us, we'd be happy to turn that into a fully fledged STUNner tutorial. Just send us a note or submit a PR, the more tutorials we have the more we can support our users!

[dbason]

We have an inhouse system that records the instance of mediamtx a particular path is on and then a custom proxy that will forward WebRTC signalling to that server. We're currently testing stunner with a bog standard headless setup. If that works out I'll share the stunner configuration along with mediamtx config.

[dbason]

We did get this working. For the Stunner config we just used the same config as in the direct call tutorial (a standard headless set up I believe)

The config to add in to mediamtx is as follows:

webrtcICEServers2:
- url: turn:<stunner-loadbalancer-ip>:3478
  username: <user>
  password: <password>

If you want to use ephemeral auth it will be the following

webrtcICEServers2:
- url: turn:<stunner-loadbalancer-ip>:3478
  username: AUTH_SECRET
  password: <password>

Mediamtx will automatically generate a username/password pair based on the shared secret and provide those to the client.

[rg0now]

Thanks a lot for sharing your setup. Once I find some free time slot I'll try to turn that into a nice MediaMTX tutorial (need to find a sample app first).

Closing this for now, feel free to reopen if anything interesting comes up.

[dbason]

FYI bluenviron/mediamtx#3164 has been merged to mediamtx. Once this is released mediamtx will support asymmetric ICE.