search

bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
11.9k stars 1.5k forks source link

WebRTC closing connection when It's still able to recover #3820

Open Clemens-E opened 3 days ago

Clemens-E commented 3 days ago

Which version are you using?

1.9.1

Which operating system are you using?

Linux arm64 standard

Describe how to replicate the issue

I'm streaming 6 Cameras using WebRTC over a TURN server. Every 1-2 Minutes, each stream displays "peer connection closed", then it loads for 5 Seconds until it has been reconnected. The connection was running over LTE so I expected some connection issues, but not this frequent.

My observation: The Javascript in read_index.html terminates a connection when its state changes to "disconnected".

However RTCPeerConnection/iceConnectionState#disconnected says:

This is a less stringent test than failed and may trigger intermittently and resolve just as spontaneously on less reliable networks, or during temporary disconnections. When the problem resolves, the connection may return to the connected state.

I removed the above-mentioned code that triggers a full reconnect when the state changes to "disconnected", and instead added a console.log with Date.now and the iceConnectionState. After waiting for a bit, I got following log:

1727778552340 disconnected
1727778552394 connected

Showing it took about 54ms before the connection resumed My proposal would be using the "failed" state, or re-checking if the connection returns to "connected" within a certain time frame.

Steps to reproduce:

  1. configure any camera & enable WebRTC
  2. start server
  3. open ip:8889/camera_xyz
  4. wait until peer is disconnected

Server logs

No response

Network dump

No response

Clemens-E commented 2 days ago

I had good results with this logic: If the connection has not recovered within 2 seconds I issue a full reconnect.

In most cases the connection recovers in less than 100ms, this handles the rare cases where it does not.

alexunderboots commented 4 hours ago

same problem

alexunderboots commented 3 hours ago

2024/10/04 07:52:23 DEB [path 26.cam] [RTSP source] [c->s] TEARDOWN rtsp://10.104.11.26/1 RTSP/1.0 Authorization: Digest username="admin", realm="Surveillance Server", nonce="35909642", uri="rtsp://10.104.11.26/1", response="e05ac445e464c48ff7e563023655ce33" CSeq: 6 Session: 50360028 User-Agent: gortsplib

2024/10/04 07:52:23 DEB [WebRTC] [conn 172.30.0.19:62711] [s->c] HTTP/1.1 204 No Content Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Authorization, Content-Type, If-Match Access-Control-Allow-Methods: OPTIONS, GET, POST, PATCH, DELETE Access-Control-Allow-Origin: * Access-Control-Expose-Headers: Link Server: mediamtx

2024/10/04 07:52:23 DEB [path 26.cam] [RTSP source] [c->s] OPTIONS rtsp://26.cam.resp204k7.itstroy.pro:554/1 RTSP/1.0 CSeq: 1 User-Agent: gortsplib

2024/10/04 07:52:23 DEB [WebRTC] [conn 172.30.0.19:62711] [c->s] OPTIONS /6.cam/whep HTTP/1.1 Host: resp204k7.itstroy.pro:8889 Accept: / Accept-Encoding: gzip, deflate Accept-Language: ru-RU,ru;q=0.9,en-GB;q=0.8,en;q=0.7,en-US;q=0.6 Connection: keep-alive Dnt: 1 Origin: http://resp204k7.itstroy.pro:8889 Referer: http://resp204k7.itstroy.pro:8889/6.cam/ User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36

2024/10/04 07:52:23 DEB [WebRTC] [conn 172.30.0.19:62711] [s->c] HTTP/1.1 204 No Content Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Authorization, Content-Type, If-Match Access-Control-Allow-Methods: OPTIONS, GET, POST, PATCH, DELETE Access-Control-Allow-Origin: * Access-Control-Expose-Headers: Link Server: mediamtx