Replies: 1 comment
-
There are several ways to solve the issue, but first let me explain why this problem happens. WebRTC needs two separate connections: the first one is needed to perform the handshake, and the second one is needed to exchange packets. MediaMTX by default uses a passive way of establishing the second connection: during the handshake, the address of the server is sent to the client, and the client tries to connect to this address to establish this second connection. If there's a reverse proxy in front of MediaMTX, there's the risk of this second connection being redirected to another replica. You can switch to the active way, by disabling local listeners and enabling ICE servers inside the configuration: webrtcLocalUDPAddress: ''
webrtcLocalTCPAddress: ''
webrtcICEServers2:
- url: stun:stun.l.google.com:19302 In this way, the replica that is in charge of the first connection will try to connect to the client and vice-versa, avoiding the involvement of other replicas. Otherwise, use sticky sessions. |
Beta Was this translation helpful? Give feedback.
-
Question
I would like to read a stream from two webrtc servers that are being published to via RTSP by the same device on another remote machine. This is to help spread the load across the two web servers serving the webrtc stream.
If I try using
roundrobin
I get stuck in a refresh loop because the request is trying to find the feed. I can get it working if I use a sticky session in haproxy, but the moment it tries to roundrobin with a pool it gets weird.What configuration is needed so that I can use haproxy across two webrtc servers?
Thanks in advance
Beta Was this translation helpful? Give feedback.
All reactions