WebRtcServer

[ibc]

Details

So instead of having each WebRtcTransport listening into its own local ports, here we introduce a new WebRtcServer class that listens in given protocol, IPs and ports and we extend the router.createWebRtcTransport() API so now it accepts a webRtcServer as option (if so, listenIps are ignored).

Usage example in mediasoup-demo project: versatica/mediasoup-demo#110

TODO

• Rust layer. Hi @nazar-pc :)

[nazar-pc]

transport has been closed by someone else

Isn't it sufficient to just know that transport has closed, without knowing why exactly? If that is the case, current close event is already sufficient for router to clean its maps.

[ibc]

transport has been closed by someone else

Isn't it sufficient to just know that transport has closed, without knowing why exactly? If that is the case, current close event is already sufficient for router to clean its maps.

There is no "close" event in Transport telling its parent Router that it has been closed. It's never been that way. The router closes the transport so it never needs to listen to any "close" event. Of course I'm talking about C++ side.

[nazar-pc]

There is no "close" event in Transport telling its parent Router that it has been closed. It's never been that way. The router closes the transport so it never needs to listen to any "close" event. Of course I'm talking about C++ side.

Hm, that is strange then. We do have transport.close message, which I would have expected triggers closing of the transport and everything related to it cleans up automatically.

[ibc]

Hm, that is strange then. We do have transport.close message, which I would have expected triggers closing of the transport and everything related to it cleans up automatically.

Of course we have, but it's the Router the one that intercepts it and closes the transport. I insist, in C++ parent closes the child, always :)

[nazar-pc]

Of course we have, but it's the Router the one that intercepts it and closes the transport. I insist, in C++ parent closes the child, always :)

Hm, if it was like that before then I guess it is fine, but I do find C++ less elegant and quite convoluted comparing to TypeScript.

[ibc]

Take into account that we don't expose any public C++ API. If we did then indeed we should do something more similar to what is done in TS.

[fippo]

I wonder if it is possible to measure if recv_mmsg in libuv gets more efficient with this since the chance that you pull multiple packets in a single read increases. Maybe @saghul knows

[ibc]

I wonder if it is possible to measure if recv_mmsg in libuv gets more efficient with this since the chance that you pull multiple packets in a single read increases. Maybe @saghul knows

We already use it for long.

[fippo]

We already use it for long.

I know but if you have more packets coming into the single port you get more efficiency here which would be 🎉

[jmillan]

I know but if you have more packets coming into the single port you get more efficiency here which would be 🎉

That's my understanding too.

[ibc]

MERGING

[nazar-pc]

Working on Rust support for this and wondering if port should be optional in WebRtcServerListenInfo. I think it would make sense to be able to allocate port from the pool of ports available to the worker just like in case of individual transports.

[Robokishan]

This is most amazing thing @ibc Thanks for mediasoup :). This is totally magic. as soon as I saw this and I did bring down my another ec2 workers. and it is very cost effective

[truanguyenvan]

hi @ALL, is there any way we can use webRtcServer in pipeTransport?

[nazar-pc]

Questions on the forum, don't abuse this PR

[truanguyenvan]

oh, so sorry. thank @nazar-pc