Are TCP ports held for the duration of a WebRtcTransport even if UDP is used?

Wondering if someone can confirm this… it appears that when creating a transport with both tcp and udp ice candidates, the tcp candidate port is bound for the lifetime of the transport even if a UDP connection is negotiated.

I confirmed this by attempting to telnet to a specific port. It initially fails. I then established a recv transport and was provided 2 candidates. I verified we utilized the UDP candidate. I am then able to telnet to the port of the TCP candidate and can do so for the entire time I am connected. Once I disconnect I no longer can.

This leads me to believe that a send/recv session actually requires 4 ports out of the given range, not 2 as I would assume, since the unused TCP ports remain bound.

Which 4 ports? It’s you who decides how many and which kind of ports the Transport binds. And yes, they remain open because it’s possible that the remote endpoint to those later. It doesn’t happen usually but may happen.

Thanks that answers my question. I understand I choose the ports. I’m just saying out of my given range (e.g. 40000-49999) I would expect the send transport to use 1, and the recv transport to use 1. But it makes sense that we must also hold open the TCP port if we allow TCP connections, so instead they each are using 2 ports.

I am trying to determine the least amount of ports I can leave open for my load characteristics as we are experimenting with AWS Global Accelerator. There are limits on how many ports the accelerator can forward. The fewer ports we use per-instance the more instances we can scale up to and continue to use the accelerator.

You can use a single UDP port per Transport and then use a TURN server with just TLS 443 port to cover all the cases.