WebRTC,.. the bane of my existence

[gebus]

I’m having issues with outgoing WebRTC calls to take a full 15 seconds to receive incoming audio.

I have tried a number of things I found on this forum. No STUN/Turn Servers, NAT on, NAT off, etc. Nothing worked.

I went through my own extension and tried turning on and off every option one at a time, making a call afterwards. Nothing worked.

I have taken PCAPs, checked the asterisks logs to no avail. I’m seeing STUN packets in the PCAP despite no STUN server being listed.

Any ideas of where I’m going wrong is greatly appreciated.

[gebus]

I guess it should be noted that once the audio streams do finally connect after 15 seconds the call is flawless.

[gebus]

I’m veering into this being an ICE candidate gathering issues while on VPN.

If I use the Trickle ICE testing site off VPN it takes less than a second to gather ICE Candidates. If I’m on my VPN it takes 12-30 seconds.

The really weird thing is that the issue with the delay in calls is intermittent. The delay only happens when I call certain number. My cell phone connects instantly, a call to the number in the log above causes a 15 second delay.

The only thing I have come up with so far is that the VPN is causing the delay. I’m just not sure why.

[dwsiemens (Dan S)]

wow that is a long time. are you doing split tunneling or all trafic inside vpn?

[billsimon]

You can control the ICE candidates offered by the PBX in Asterisk SIP Settings:

this may help reduce the negotiation time.

[gebus]

All traffic inside of VPN.

[gebus]

I’ll give this a try. If I understand what is needed here it is the internal IP of the FreePBX server in the first box, and my external IP in the second box, correct?

[MAWalker (United Kingdom)]

Yes, ‘[Internal PBX IP] => [External Static IP]’ for ICE Host Candidates when PBX is behind a NAT Router to the Internet.

I’m not sure if/how this affects traffic that is through a VPN tunnel to the PBX.

[dwsiemens (Dan S)]

I think that would mean the traffic has to go through he vpn and then out your vpn edge. But the IP on the host is a local IP and that likely is breaking ice. Try routing your phone traffic outside the vpn profile.

.

[gebus]

Does anyone know of a way to reduce the amount of time for the ICE candidate gathering timeout? I eliminated the VPN from my testing, and am still getting a 15 second delay on calls to specific numbers.

Since I can successfully make calls without the delay in most cases I’m stumped why these few numbers are getting a delay.

[gebus]

I ended up paying Sangoma for support, and after a week of troubleshooting with their techs and sending numerous logs and pcaps I still have 15 seconds of audio delay on specific outgoing calls.

So,. I have that going for me.

[gebus]

FINALLY. I figured it out.

This issue was resolved by re-configuration of the DTLS settings on the extension.

Previously I had auto generate certificate set to no, DTLS Verify set to fingerprint, and DTLS Setup to act/pass

I might mess around with the verify setting a bit more. Setting DTLS Setup to passive seemed to be the one that did the most to resolve the issue.

But, the specific calls are now connecting without issue. PROBLEM SOLVED. I live to fight another day.