WebRTC blocking

[pikachu937]

WebRTC blocking

[aler9]

Hello, i don't think that Websocket is related to this issue.

A WebRTC session between two peers is splitted into two parts that use two separate communication channels: the handshake, in which the peers exchange their IP addresses and tracks, and the Peer Connection, in which video packets are exchanged.

The handshake can happen with any communication channel of choice (even by exchanging text files through mails), in case of MediaMTX it works by making clients send HTTP requests to the server, and making the server reply with a response (this is WHIP / WHEP). This is the part in which we used to have WebSocket in place of HTTP (although WebSocket is still HTTP-based), but by looking at your logs, the handshake works flawlessly, since clients are able to send requests like:

2024/01/24 14:58:04 DEB [WebRTC] [conn 46.47.28.76:52084] [c->s] POST /path1/whep HTTP/2.0

and the server is able to reply:

2024/01/24 14:58:04 DEB [WebRTC] [conn 46.47.28.76:52084] [s->c] HTTP/1.1 201 Created

The difference between the WHIP/WHEP method and the Websocket-based one is that the latter keeps this communication channel open in order to detect communication losses with the server, and resets the session as soon as this happens. The WHIP/WHEP method is still able to detect communication losses by monitoring the Peer Connection, it's slightly slower but it avoids keeping a direct TCP connection between clients and the server, saving RAM, CPU and bandwidth.

The Peer Connection on the other hand happens through a communication channel that is negotiated during the handshake, but is less flexible. It may be

• a UDP connection
• a TCP connection
• a TCP connection routed through an external TCP server (TURN server)

This has nothing to do with WebSockets or WHIP/WHEP. By looking at your logs, this is the part which fails to initialize and it's because clients and server cannot talk to each other through one of those communication channels, that by default is the UDP one.

There is another difference between v1.5.0 and v0.21.1, and is that former tries to use a fixed UDP port in order to receive requests, while the latter uses a random one. Maybe this issue is caused by the fact that the fixed UDP port you chose is not routed correctly from clients to the server.

Anyway, you can restore the old behavior by setting webrtcLocalUDPAddress to a blank string, and you have also to use a STUN server:

webrtcLocalUDPAddress: '' 
webrtcICEServers2:
  - url: stun:stun.l.google.com:19302

If you still have issues, my advice is to follow all steps described in this section of the README:

https://github.com/bluenviron/mediamtx/tree/main?tab=readme-ov-file#connectivity-issues

These describes how to to add IPs, add STUN servers or to try the other two communication methods (TCP and TURN).