Using default port numbers, Boundary clients (cli, Desktop) require that egress ports 9200/TCP towards Boundary Controllers and 9202/TCP towards Boundary Workers are open.
However, for various reasons, enterprise networks, or some ISPs upstream, or even at country level block egress connections to any ports other than a few selected, well-known ports, such as 53/UDP (DNS), 80/TCP (HTTP), 443/TCP (HTTPS). If very unlucky, they won’t
even allow egress ICMP, flows to 53/TCP, 443/UDP for QUIC/HTTP/2, and might start to block TLS 1.3, out of ignorance, by error, or on purpose.
Users of the popular Open Source software “Jitsi-Meet” for example must be able to open connections towards port 10’000/UDP in addition to 443/TCP of the conference server(s) in order to participate in Video Conferences. This turns out to be often a show-stopper and prevent users’ clients to connect to the Videobridge servers.
Therefore, over the past year or so, Devs of Jitsi have implemented at least two solutions which allow to “multiplex” also the audio/video streams through the single port 443/TCP which must be open for egress flows (using TCP streams, WebSockets, or WebRTC for ex.), in order to avoid port 10’000/UDP.
Is it already possible to coerce the Boundary clients so they “multiplex” the TCP flows to both Controllers and Workers over a single port 443/TCP, for example by using session multiplexing of HTTP/2, SNI, or looking at HTTP headers etc. to “demultiplex” them at
the server-side? Or is this a new feature which would require development?