Hi - I am still trying to get Asterisk 22.5.0 with webrtc on AWS working (well).
So Everything works on a local network…. however moving to AWS I had some issues.
The last one was fixed by setting the ice_host_candidates in rtp.conf - So now Video shows - however it freezes all the time. The error I get on the CLI is:
If you are prepared to turn off security checks, why are you using SRTP. I think it is unlikely that there would be mechanisms to partially disable it.
Either you are under active attack, or there is a bug in the implementation of SRTP, probably with the remote side.
The index is calculated from the RTP sequence number, which is transmitted in clear, although covered by the packet signature, so should be visible on a tcpdump/wireshark trace. Look for any behaviour other than simple incrementing by 1, modulo 2^16.
I came across the same behaviour. In low latency environments, the video appears to work fine.
Background: The replay check error appeared a few years ago, and i have just not had the time to dig into this and submit my findings.
I recall it started to happen when browsers started to support a new feature in WebRTC.. i just wish i could remember the name… anay way, i remember the article and the concept. It goes something like this: If a packet gets “lost”, and there is sufficient time/buffer, the protocol can “ask for it again”, it’s in an attempt to close all the gaps, so:
[packet:1]
[packet:2]
[packet:3]
oops…
[packet:5]
If this is in its buffer, it can ask for packet 4… This all sounds good and well, in low latency, but when the latency get higher, this “replay” takes to long, or can’t work or whatever….
Anyway.. so what… right.. the problem is while peer-to-peer browser calls appear to work fine with this, re-asking for missing packets, or even failing to do so… the result is a simple dropped frame or two… however the problem is the when Asterisk is in the middle between two browsers, the media flows “through” Asterisk, and this is when the problems start.
So, interesting observations:
This does not do this with audio. In an audio & video call, video will get stuck, while audio will work fine.
The video will play fine for a few seconds, then as soon as the replay check errors come, the video stops… but it dont recover again… I think this is probably the most annoying thing… we expect that video can be problematic, but the fact that that it doesn’t recover again makes it problematic
The last time I checked this it was fine in Firefox, and Safari, but failed in Chrome…. Maybe it was that Chrome often lead with “all the fancy stuff”… but in this case it was causing more trouble than good.
I have since moved off using Asterisk for Video… and am exclusively doing peer-to-peer video, and this doesnt have the same problem.
As Josh mentioned in a previous post about this srtpreplayprotection=nois for your outgoing RTP packets. It’s up to the UAC to not perform this “replay check thiny”. In my case (and yourse) the UAC is the Chrome browser.
I didn’t find any solution.
I noticed that Samgoma offer the Sangoma Meet application, much like Google’s Meet, and it’s probably using Asterisk with conf_bridge (would be funny if thy where not). Anyway check it out: https://meet.sangoma.com/
If you get a clean video stream that is able to recover after a bit of sticky video, then the chaps there have some special magic going on.
If you have only been testing 1:1 calls, it’s’ probably also a good idea to test video in a conference on your own kit, maybe it recovers better after the packet loss when you are in a conference.