sipsorcery-org
WebRTC peer connection keeps closing
I've done my implementation based on FfmpegToWebRTC example using .NET 6 and latest SIPSorcery (6.0.6).
Everything works fine except for the fact that peer connection gets closed after a moment (anywhere from few seconds to few minutes) resulting in video freezing in a browser. I've also tried other video sources, but to no avail, so I suppose the problem lies in WebRTC part.
Interestingly enough downgrading to SIPSorcery 6.0.4 resolves the issue - no unexpected disconnections happen.
I reproduce the pb using this sample
When SIPSorcery 6.0.4 is used it's ok but not with SIPSorcery 6.0.6
Hopefully if I use the master branch of SIPSorcery it's working.
Could you try using it too ?
EDIT: No problem / no disconnection so far after more than 60 minutes with Video streaming
@kamil-spyro try use the Master-branch... i recently fixed a lot of problems related to Ip priority and network quality.
Probably master branch is your better option at the moment.
Got the same issue here, first I thought it was an issue with my H264 encoder or my source but downgraded to an older version and the problem disappeared. Looking at chrome://webrtc-internal confirms that weird behaviour.
The chrome WebRTC diagnostic dump doesn't really show anything interesting, it just ends with a:
{"RtcpPacket":{"incoming":true,"packet_data":"gMgABhaSHv3l/7fQAGPzJQAVj4gAAAmkADbWOYHLAAEWkh79","packets":[{"Packet":{"SSRC":378674941,"NTPTime":16573167257734345509,"RTPTime":1413000,"PacketCount":2468,"OctetCount":3593785,"Reports":null,"ProfileExtensions":null},"Type":"*rtcp.SenderReport"},{"Packet":{"Sources":[378674941],"Reason":""},"Type":"*rtcp.Goodbye"}]}}
which looks normal (?). I'll try to see if I can debug the library locally and open a PR if I can spot the issue.
Stumbled on to the the same/similar issue lately. Tried to implement a h264 encoding, the cpu based one worked, switching to gpu via nvenc broke the stream randomly in the first two minutes. No errors on both sides, just got a RTCP BYE for the video stream. Same behavior on the webrtc internals as already posted here. Did not work with SIPSorcery 6.0.6 & 6.0.7, rolling back to 6.0.4 fixed the issue for me.
I am seeing a similar issue. The bug seems to be in RTCP packet processing. It seems to be getting lost in its packet offset lengths. Eventually hitting a random 203 which gets processed as a RTCP BYE.
One more thing to note is that connection will only close if the stream is video only. For some reason the logic for BYE receipts only match SSRC on connections with audio.
Hi @SimonTheSourcerer , @NoOverflow, @kamil-spyro, @moorecj
Since there is something bad between 6.0.4 and 6.0.6 could you please check after each commit (from 6.0.4 to 6.0.6) which one it the source of the pb ?
Could you also explain more in details how you reproduce the pb ? It seems you are all using WebRTC with only a Video Stream (SendOnly ? SendRrcv ?) (An Audio Stream is present but no data is sent, so SendOnly ? ) A RTCP Bye is received on the Video Stream.
In this resume correct for all of you ?
Hi @ChristopheI,
I'll gladly take a look when I get a bit of free time, looking at the diff between tags 6.0.4 and 6.0.5 there are some minor modifications to src/net/WebRTC/RTCPeerConnection.cs so that is where I'd look first (The rest of the changes being the addition of the G729 codec and some other probably unrelated things). No need to look at 6.0.5-6.0.6 since it is just a version bump.
I can confirm I'm only using a single video stream coming from a camera through OpenH264, I only send video data (using SendVideo()) but never receiving. I personally got no audio stream at all, and I do receive a RTCP bye even though I did not initiate it.
I'll send more logs from chrome's webrtc internal module if you need them.
Update: I think I found the culprit, problem appears on commit a6b16d634e4689984a690776e8b3aaa3a7f84870
Heya! I'm streaming the desktop to the browser, with h264 encoding + Audio in both directions. RTC Bye always happens on the video channel. Just checked and I can confirm that the problem starts with the mentioned commit a6b16d634e4689984a690776e8b3aaa3a7f84870
As far as I remember it worked with different encoder earlier on, but going to confirm this.
@moorecj Opened #728 that addresses the cause of this random "Bye" packet.