Desktop Client/Web Client Wont Deliver Audio on External Calls After ISP Change

[TaylorStevens23]

This morning we experienced an Outage with our ISP. We switched over 3CX to our backup ISP provider and contacted our SIP provider and updated our new IP. The dashboard information is showing the new IP in green and set to Static in the management console. We cycled the services and we can get calls to connect if calling externally into the PBX. We can also call out of the PBX and connect to callers and audio works for the desk phones, smartphone app, and desktop client when on the local network. But when we try to call an extension that goes to our remote workers they can see the call come thru but there is no audio on either end. Does this desktop app, like the phone need the DNS to propagate? I can pass audio through if I use the app on the local network. Or is there something I am missing? I have tried to toggle PBX delivers audio on and off but no difference was noticed.

We have a pro license and I see online it can take up to 6 hours to propagate. We made this change around 2-3 hours ago and still are having the same issues. Is there anything I am missing or is there a way to speed up this process?

• 3CX Version, Professional Annual 16.0.8.16
• Server OS, Debian 10
• Is the 3CX Server Hosted and where? On Prem
• Provisioning Method: Local
• Trunk Provider or Gateway Make/Mode: 123net
• Are custom Phone Templates being used: YES

 

[NickD_3CX]

But when we try to call an extension that goes to our remote workers they can see the call come thru but there is no audio on either end.

Just to make sure we understand the issue correctly. Extension that are on the same LAN as the 3CX Server (softclients and IP Phones) work fine, but remote workes using the Desktop Client or the WebClient can make/receive calls, but have no audio after they answer.

Is this correct?

A few questions to get started:

• Could you please re-verify what version of 3CX you are using? Access the Management Console --> Dashboard and check on the right section under "Version"
• In the Dashboard --> Firewall, please run it and make sure all ports pass.
• Is it ALL remote workers having the issue or only some?
• If one of the remote workers dials *777 and speaks into the Mic, do they hear their voice back (this is a test echo extension)

 

[TaylorStevens23]

Just to make sure we understand the issue correctly. Extension that are on the same LAN as the 3CX Server (softclients and IP Phones) work fine, but remote workes using the Desktop Client or the WebClient can make/receive calls, but have no audio after they answer.

Is this correct?

A few questions to get started:

• Could you please re-verify what version of 3CX you are using? Access the Management Console --> Dashboard and check on the right section under "Version"
• In the Dashboard --> Firewall, please run it and make sure all ports pass.
• Is it ALL remote workers having the issue or only some?
• If one of the remote workers dials *777 and speaks into the Mic, do they hear their voice back (this is a test echo extension)

Your understanding is correct, only correction is that the web client is working for most remote workers on the VPN. Remote users do receive the calls but there is no audio when using the desktop app. Some remote users can send audio back to the caller but they do not receive audio back. I have had the most success from the browser extension while on VPN for the remote workers. I can get audio back and forth from the chrome extension but the users must be on VPN because our IP change still has not propagated after nearly 24hrs.

Version: Professional Annual 16.0.8.16

Firewall: Cant test until later, employees in office are using phones and firewall test will take services down

Remote Workers: Some remote users can send audio back to the caller but they do not receive audio back. I have had the most success from the browser extension while on VPN for the remote workers. I can get audio back and forth from the chrome extension but the users must be on VPN because our IP change still has not propagated after nearly 24hrs.

Dial *777: I could hear voice back remotely using the web client and browser extension but not on the desktop app

 

[NickD_3CX]

Thanks for the information. By the time that you are indeed on V16, the softclient you are using must be the 'legacy' Windows Client.

As a first suggestion, you should consider upgrading to V18 and using the new Desktop App that is available only with V18.
The back-end of it works exactly as the WebClient does (WebClient also still exists of course...), so this would most likely work for you.

Now for troubleshooting, do the remote users launch the 3CX Windows Client before they establish the VPN connection, of after they establish it. If it is before, please instruct them the completely exit the client by right-clicking on the Notification area icon, establishing the VPN connection and letting it complete the process, then re-launch the app again. Then try *777 again.

 

[TaylorStevens23]

Thanks for the information. By the time that you are indeed on V16, the softclient you are using must be the 'legacy' Windows Client.

As a first suggestion, you should consider upgrading to V18 and using the new Desktop App that is available only with V18.
The back-end of it works exactly as the WebClient does (WebClient also still exists of course...), so this would most likely work for you.

Now for troubleshooting, do the remote users launch the 3CX Windows Client before they establish the VPN connection, of after they establish it. If it is before, please instruct them the completely exit the client by right-clicking on the Notification area icon, establishing the VPN connection and letting it complete the process, then re-launch the app again. Then try *777 again.

I tried the *777 test again in the order you recommended and got the same results.

 

[NickD_3CX]

I tried the *777 test again in the order you recommended and got the same results.

Then the next step I would suggest is to install Wireshark on the PC where the 3CX Windows Client is installed on, start a capture, make another call to *777, hangup, stop the capture and check specifically the SDP part of the SIP message, if the client is sending the right IP Address.

I would also check the SDP in the 200 OK from the server to check whether the server is 'telling' the clients to send the audio to the wrong IP.