Change between v1.11.0 and v1.11.1 in webrtc handling using WHIP/WHEP on restricted network

[SixK]

Question

Not sure this is a bug in mediamtx, but I can notice a change between v1.11.0 and v1.11.1.
On my enterprise Network, when trying to view a RTSP stream using mediamtx as webrtc server, stream is not working anymore in v1.11.1
With v1.11.0 everything is ok.

If connected directly to internet, everything is ok with v1.11.1.

When comparing logs I see no real differences on how WHIP/WHEP and webrtc is handle.

I have no clue of what's could be wrong.
In mediamtx logs, with v1.11.1 there is no candidate connexion attemp.
In firefox about:webrtc logs, I seen no particular difference. Just no candidate connexion attemp.

It could be the migration from pion/webrtc and pion/ice from v2 to v4 ?
It could be special filtering rules on my enterprise network ? (I don't think so, but some packets with different signature with pion libs from v2 to v4 migration could be filtered)
A bug in our application ? (we don't use mediamtx webrtc demo page)

Rooms are created with commands like this one:
curl -vvv -d '{"source": "rtsp://192.168.10.21:1028/cam/realmonitor?channel=1&subtype=1"}' http://localhost:9997/v3/config/paths/add/473944042

And created path is visible if running such command:
curl -vvv http://localhost:9997/v3/config/paths/list

Sorry, if I don't publish logs, as said, I'm not sure this is a mediamtx source code problem and anyway I see not real difference (comparing line to line in Meld) when stream is working or not.

Just verify and report if you encounter the same problem.

[SixK]

Ok, finaly I found a difference in about:webrtc logs between mediamtx v1.11.0 and v1.11.1.
V 1.11.1 miss this line in candidates:
succeeded true true (redacted):5019/tcp(prflx) [non-proxied] 95.64.103.123:8190/tcp(host)

Other lines are mostly UDP (and the same between v1.11.0 and v1.11.1) and can't connect due to our networks restrictions.
So v1.11.1 may have lost some tcp candidates ?

[SixK]

To be more precise,
redacted seem's to be for our load balancers ( private ?) ip (102.110.4.6 and 102.110.4.7 depending of which load-balancer server has been used).
So v1.11.1 don't see this servers as ice candidate anymore.

In mediamtx.yml platform public IP is set to webrtcAdditionalHosts

we are in a complex infrastructure and network, so problem may be hard to reproduce in another place.
We have public IP, load-balancers, VM and restricting rules on ports and protocols.

[SixK]

We pushed tests further, we disabled udp port in mediamtx config putting this variable empty: webrtcLocalUDPAddress
v1.11.1 still don't work, v1.10.0 work.
difference is still this ice candidate:
succeeded true true (redacted):5019/tcp(prflx) [non-proxied] 95.64.103.123:8190/tcp(host)

when udp port was not closed, v1.11.1 was working on udp connecting directly on internet.
when udp closed, stream is not working anymore when connected directly on internet (with v1.11.1)

Can we conclude finding tcp candidates are broken in some cases in v1.11.1 ?

[aler9]

moved in #4161