Port in transport options

mediasoup libraries
21

Thanks for the code. So you are using STUN for identifying the transport and associate it to a remote host:port. But what happens when the same remote host:port is re-used in another transport?
Do you have tested it in case of remote participants under NAT or using TURN servers?
Can you send us the articles you are using as reference?

22

the author of the patch is not me.

The articles are in Chinese
https://blog.csdn.net/The_Old_man_and_sea/article/details/114500381
http://yunxin.163.com/blog/webrtc-1/

Not test the patch of mediasoup.

I’m not sure if it will work in case of remote participants using TURN servers。

23

Inaki, did you have something specific in mind for v4 already?

24

Allowing port range or port in createXxxxTransport(). But this requires a complete refactor of PortManager so that’s why I wouldn’t like to introduce it in v3.

25

Using a single binded port for all WebRTC transports is the way Jitsi works. Incoming ICE packets are matched by ICE user/pwd and then the source IP:port added to a map so DTLS, RTP and RTCP packets are matched by source IP:port.

Problem if this is that this just works when there is ICE so this would require a huge refactor of mediasoup internals.

26

We could use the actual mechanism for plain/pipe transports, and the single port approach for WebRTC transports. I suspect that using the single port approach we could avoid completely TURN servers, because we can listen on a public accessible port (443 or 3478).

27

True.

28

I implemented single port override in Support fixed ports in transports by nazar-pc · Pull Request #593 · versatica/mediasoup · GitHub, hopefully that is not very invasive and non-controversial enough to get accepted.

1 Like
29

Thanks @nazar-pc
Looking at the patch implementing the single port solution (mediasoup/WebRtcTransport.cpp at cbe5e5713b202c40b009536213845856064a91d8 · UniverseParticle/mediasoup · GitHub), it will be simple to add another option to WebRTC transports for using the single port approach.

One thing that in my opinion should be changed is that the users should be mapped using both username and password instead of the username only (mediasoup/SingleUdpSocket.cpp at cbe5e5713b202c40b009536213845856064a91d8 · UniverseParticle/mediasoup · GitHub).

30

I’ve modified the @nazar-pc branch, allowing to listen to the same UDP port and use the STUN username to map the incoming UDP packets to the right WebRTC transport (taking some parts from Webrtc sfu UDP single port solution design · UniverseParticle/mediasoup@cbe5e57 · GitHub). More work is required to allow the cleanup of the listening socket objects when no more transports are using them.
To try it, you have only to modify the mediasoup-demo config.js adding the webRtcTransportOptions.port option. As it is, only a single worker configuration is supported (set numWorkers = 1).

The main modifications are here:

and here:

31

I see that the document supports fixed ports, but I make mistakes when using them, mediasoup V3.8.4

mediasoup:Channel request() [method:router.createWebRtcTransport, id:8] +59ms
mediasoup:ERROR:Channel [pid:1341388 RTC::PortManager::Bind() | throwing MediaSoupError: uv_udp_bind() failed [transport:udp, ip:‘192.168.0.111’, port:42001: address already in use +0ms
mediasoup:ERROR:Channel [pid:1341388 Worker::OnChannelRequest() | throwing MediaSoupError: uv_udp_bind() failed [transport:udp, ip:‘192.168.0.111’, port:42001: address already in use [method:router.createWebRtcTransport]

32

So such a IP and port is already in use as the error clearly says. There are tons of ways in Linux and any OS to see which ports are in use and by which processes. Please do your homework.