vicidial.org

We encounter this once in a while. Agents are working just fine with webphones for weeks, suddenly all the webphones in that location don't have audio anymore suggesting a network problem.
When doing a test with this page: test.webrtc.org

There is one test result that is different from a working/non-problem location:






Reflexive connectivity does not pass.
Here it is said this is called hairpinning and is not a reason per se why it would not work:
https://support.google.com/googlenest/t ... 9875?hl=en

As far as i can gather the issue must be modem/firewall related, perhaps ports are blocked or symmetric NAT (https://networkengineering.stackexchang ... symmetric#)

Other useful pages i found:
https://blog.addpipe.com/troubleshootin ... on-issues/
https://github.com/webrtc/testrtc/issues/176
https://webrtc.github.io/samples/src/co ... ickle-ice/

Did anyone run into this issue before and have some recommendations how to work around this?

I use webrtc on all of my cluster setups and have helped quite a few people and businesses setup theirs and have not come across an issue where it just drops after weeks at a time. Can you provide the logs from asterisk, the webphone itself and apache for one of the timeframes it happened during.

The reflexive connectivity does make logical sense in your situation because I am assuming the agents are all on the same network, which is where that error would come in play, but I would think it would be all the time and not just periodically if that were truly the issue. Here are the results from my own system:

You are right, what i meant to say was that for this callcenter it worked just fine until last week where it suddenly stopped working until today. So i supposed something changed in their network or at the ISP. Will try to find logs later. For now i have just setup softphones to work around the problem. I've seen this issue a few times before with work-at-home agents.

Usually that comes from poor connectivity, low upload speed it my experience. Or as you have said, deeper at the ISP level with SIp traffic being blocked due to SLP ALG being blocked somewhere along the traceroute. I usually move those individuals to softphones like you've already done and sometimes switch them to IAX2. Too bad the WebRTC doesnt support IAX, heh.

nox