No audio for incoming calls on Chrome Extension

[Willvdl]

This is a topic that gets reported and written about a lot yet strangely none of the suggestions seem to apply here.

We have a hosted PBX running latest 16.0.6.655
All agents use Chromebooks with latest Chrome version and Chrome Extension.
Firewall has SIP ALG off, has forwarding rules for all suggested ports and even priority queues for VOIP traffic. Firewall test on PBX all pass.
PBX Delivers Audio set for extensions.
Audio/Mic settings on the Chrome devices work properly with other services (Youtube, Zoom etc.)

Two things go wrong:

• Incoming calls don't ring on the client, as in there is no ringing sound even though the chrome extension shows an incoming call
• Once the call is accepted, there is no audio. If we call the number back, there is audio.

We are presuming it is a networking related issue since we can't reproduce the behaviour on home internet (away from the office). However, what the problem is eludes us. We've followed the Mikrotik setup steps etc.

 

[JohnS_3CX]

Hi Will,

You said that from a remote location like home (he same devices presumably do not face such issues.

So does this only happen in a single location ie. your office?

Is the PBX hosted in the cloud or does it live on your office network?

 

[Willvdl]

Hi,
The PBX is hosted in the cloud and we reach it over our public WAN.

I've managed to almost isolate it down to our specific firewall. When I bypass it, audio works.

What is interesting is we don't see any traffic on ports 5060,5061 or 5090. We only see port 5001 traffic.

 

[JohnS_3CX]

What you see is indeed correct, you should be seeing traffic over 5001, and over the RTP range (normally).

You assessment rightly seems to point that it is a firewall issue. Does it have any other types of ALG running on it, or does it have multiple WAN connections in use (splitting traffic over 2 public IPs?). Or Does it block UDP traffic for any reason? These are some things I would look at.

 

[Willvdl]

It is a super boring FW setup. No ALG, single WAN, single route/src-nat, disabled all fancy forward filter rules.

We are now looking at the specific codecs no the extensions...

 

[JohnS_3CX]

Don't worry about the codecs, that will not change the issue with the firewall (and webclient codecs are not user configurable)

Try to see if the PCs attempt to send UDP traffic in the 9000-10999 range (capture on PC) and also check simultaneously on the firewall WAN interface (capture from the firewall).

I expect you should see traffic leaving the PC interface, but won't see it leaving the firewall WAN interface.

In outgoing calls (which are successful) I'm speculating that the firewall allows the call because it is an outgoing connection and hence considered "legit" traffic.

 

[Willvdl]

It is a very strange thing. Listen to this:

Yesterday, we ran with the full suite of codecs. Testing in the office - no audio. Testing at home - audio.

Today we ran tests, saw that G729 works but Opus doesn't work we stripped extensions down to only G729 and now audio works everywhere.

I think the network is a Red Herring - meaning intermittent errors owing to one cause "masquerade" as a nother thing and it is hard to isolate.

That said we are going to exhaustively test with specific codecs because the firewall looks perfect (it works with an cloud asterix based PBX fine)

 

[JohnS_3CX]

Ah that is interesting. What tests did you run with G729 exactly? Extension to extension calls will by default use Opus if you use the webclient between both of them (and recordings are disabled). Trunk to webclient will most likely use your trunk's codec (so it can get a bit confusing depending on who is calling who, and what direction, and what client is being used) but I'm not so sure that Opus is the problem here.

As for the asterisk example, it's running SIP for the calls but the webclient does not use SIP, it uses WebRTC which is encrypted and not visible as SIP traffic to the firewall. It sounds like UDP is being blocked as a bare minimum.

 

[Willvdl]

Well, what we do know is the system now has audio on every network when only G729 is enabled on the extension. That counts for ext-ext and trunk-ext.

UDP is not being blocked on the firewall as far as I can tell (I'll concede it is possible) because we do see other UDP traffic including the RTP traffic. There was just no sound when the call was incoming. When the call was outbound there was sound.

Hence, I am interested to hear more about which codecs get chosen in which conditions..

 

[Willvdl]

I think we can categorically conclude that this issue is related to codec choices and not network.

It is interesting because it is a topic raised quite regularly in the forums and is usually associated with major Chrome updates which can cloud the underlying issue.

We know its not network because the call session actually establishes and RTP packets fly, there is just no sound in one direction which lends itself to the idea that negotiation of the codec to use is important, especially on a chrome device.

Let's hope this information helps people in the future.

 

[Willvdl]

It sounds like UDP is being blocked as a bare minimum.

I guess another way of looking at this is that UDP "connection" state is being lost, so although the firewall is allowing the traffic through, the NAT could be failing somehow?