Use only a single UDP port instead a big port range for media connection

mediasoup libraries
1

Hello all,

I’ve see how some media conferencing systems like Jitsi uses only a single UDP port for RTP traffic from browser to media server. In the Jitsi deployment instructions you can see as 10000 UDP port is enough for video/audio communications.

Using only one port for UDP can be very useful when deploying a media server in Kubernetes (where exposing a big range of ports is not practical) or when using AWS Global Accelerator service with several media servers deployed in an Autoscaling Group (where media servers are added on demand). Using only one UDP port per media server allows to use only one AWS Global Accelerator IP for all media servers. If you have to use a large port rante then you need a Global Accelerator IP per media node.

I do not have a very deep knowledge in WebRTC and the standards where it is based. And maybe this question is very stupid, but I don’t know the response:

It is possible to implement in mediasoup the same strategy used by Jitsi to need only one UDP port (or two) for all media streams? Or is there any fundamental limitation in mediasoup architecture preventing it?

If nothing limits the implementation, are the project maintainers open to accept contributions in this area?

Thank you very much!

1 Like
2
  1. Yes, it is possible if others are already doing and there were talks about this on the forum already
  2. You can actually already do it with TURN server in front of mediasoup, though it will cost you some CPU and a bit of memory usage
  3. I think if you do this, it would be a great contribution, I was already thinking to hack on this in the future among other things
3

Thank you @nazar-pc.

I’ve searched in the forum and I suppose I found the comments you mention:

The comment where single udp port is first mentioned is this one:

Here @vpalmisano proposes a prototype implementation here:

1 Like
4

Listening into a single port would just be valid for WebRTC transports (since ICE is required to identify each flow/connection) and, other than the huge work that it would require, it would also affect some tricks we do in current WebRTC transports in which we allow the client to send from a different IP:port (in case the client’s network eventually changes or things like that) without requiring to wait for a new ICE Binding request. Instead we do the switch immediately after a valid SRTP or DTLS packet has been received.

5

Maybe is better alternative to follow @nazar-pc suggestion of using a turn server carefully configured.

Do you recommend any documentation to learn how to do it?

Thank you in advance!

6

Turn server is a working solution, but it is by no means perfect either. Everything is a tradeoff.

7

I assume turn server consume more computational resources and maybe there is a small increase in the end to end delay, but it can be worth trying today until a more efficient solution is available.

I’ll investigate on how to do it.

Regards

8

Even with a TURN server each WebRTC transport requires its own binding port. However the communication between TURN server and mediasoup could be local so no need to expose mediasoup ports publicly.

2 Likes
9

AWS bandwidth prices are not practical for media-servers, a single core can do multiple terabytes a day in bandwidth (ouch).

The single port is a beautiful idea and could help lots in your specific situation or maybe wanting to pretend TURN it/etc. I don’t know what goes into managing the networks in the library but if it’s easy to convert I’d favor the use.