Sometimes no sound since SBC

[David_K]

Hello

I have a customer that had an old 3CX PBX v16 on premise server (installed on a Windows10 computer)

I did move the server to the Cloud, to the latest v18 version.
Then removed all the 3CX PBX services on the Windows10 PC and installed SBC instead. (so we reset all the phones to connect to SBC instead of direct LAN)

The customer now tells me that since we did the move, they have sometimes blank conversations problems.
Did some tests and indeed when I call them, during the conversation, sometimes there are 1-2 seconds with no sound, then comes back, again no sound, comes back... like random.

Restarted the SBC, did not solve.
Restarted the router, did not solve (which by the way is the same router we have when it was onpremise, I've just deleted all incoming firewall rules)

The SIP trunk is the same than before so I don't think there's an issue there.

Any clue where to look?

 

[ChrisC_3CX]

Then removed all the 3CX PBX services on the Windows10 PC and installed SBC instead. (so we reset all the phones to connect to SBC instead of direct LAN)

First off, by "removed all 3CX PBX services" you mean you uninstalled the PBX using via the Windows uninstaller correct?

First thing I'd recommend is confirm the issue is between the PBX and the SBC.

• Enable "PBX Delivers audio" on two extensions that are provisioned behind the SBC
• Make a call between those to extensions, do you get the same problem?
• If yes, disable "PBX Delivers audio" for these to extensions and also disable "Record Calls" for both.
• Make another call between those two extensions. Audio should not be routed directly from one IP Phone to the other locally. Does the problem go away?

 

[David_K]

Thanks @ChrisC_3CX

PBX Delivers Audio is unchecked by default. (like it was with the PBX on premise I suppose)

So what do I want to know when checking them? What does the option exactly do and if the problem goes away, does it mean I should check this option for all the extensions?

What is strange (but I have doubt about it to be true) is that a user told me she also have the problem when she's calling from the iOS app (not sure if she's using the app when she's on the same site or work from home)

 

[ChrisC_3CX]

So what do I want to know when checking them? What does the option exactly do and if the problem goes away, does it mean I should check this option for all the extensions?

This is so that we can hopefully determine if the issue lies between the 3CX PBX and the SBC. Enabling "PBX Delivers Audio" will force audio from the IP Phones to be proxied by the PBX. If "Record Calls" is enabled then audio is sent via the PBX anyway. Since you already have it off, check if "Record Calls" is off for these extensions, if not, just make a call between two of them and see if the issue persists, if it does, it may mean that the problem lies within the remote network where the SBC resides, as audio in this scenario will be sent from one IP Phone directly to the other.

 

[David_K]

This is so that we can hopefully determine if the issue lies between the 3CX PBX and the SBC. Enabling "PBX Delivers Audio" will force audio from the IP Phones to be proxied by the PBX. If "Record Calls" is enabled then audio is sent via the PBX anyway. Since you already have it off, check if "Record Calls" is off for these extensions, if not, just make a call between two of them and see if the issue persists, if it does, it may mean that the problem lies within the remote network where the SBC resides, as audio in this scenario will be sent from one IP Phone directly to the other.

Record Call is turned off (default) on all extensions, same for PBX Delivers Audio

So what you're telling me is :

- let PBX deliver audio unchecked
- make calls between 2 internal extensions and see if they have the problem
- if they have it try to check PBX deliver audio
- see if better?

Is there no log somewhere to see what could happen?

 

[ChrisC_3CX]

So what you're telling me is :

- let PBX deliver audio unchecked
- make calls between 2 internal extensions and see if they have the problem
- if they have it try to check PBX deliver audio
- see if better?

Essentially yes, but this is more to help narrow down where the problem might be, not to solve the issue.

Is there no log somewhere to see what could happen?

For audio issues you would have to perform packet captures and analyze the RTP stream if you really want to see what's going on.

 

[Saqqara]

Check the host file on the windows pc, and remove any reference to fqdn

 

[David_K]

It's getting more complicated.

I get a user caling from an iOS 3CX app. (so no SBC)

She called me while connected to the office Wifi, and I had some blanks in the conversation, every 1 or 2 minutes. She had no blanks on her side.

Then I asked her to disconnect from Wifi and use 4G instead (strange that the conservation did not hangup at this moment) and I had no blanks anymore, but now she had some blanks on her side plus a "biiiiiip" just before the blanks on her Smartphone.

I don't know what those biiiiip could be/mean.

And I don't understand that this does occur even when she's on 4G (so no router nor SBC nor FQDN or whatsoever issues)
Then she added that she also having the "biiiip" when she's on her private Wifi at home.

I don't think the biiiip are related to the blank problem

 

[David_K]

It's getting more complicated.

I get a user caling from an iOS 3CX app. (so no SBC)

She called me while connected to the office Wifi, and I had some blanks in the conversation, every 1 or 2 minutes. She had no blanks on her side.

Then I asked her to disconnect from Wifi and use 4G instead (strange that the conservation did not hangup at this moment) and I had no blanks anymore, but now she had some blanks on her side plus a "biiiiiip" just before the blanks on her Smartphone.

I don't know what those biiiiip could be/mean.

And I don't understand that this does occur even when she's on 4G (so no router nor SBC nor FQDN or whatsoever issues)
Then she added that she also having the "biiiip" when she's on her private Wifi at home.

I don't think the biiiip are related to the blank problem

So since they have the problem also outside (4G) I don't think a local packet capture from the SBC network card would help

 

[ChrisC_3CX]

Then I asked her to disconnect from Wifi and use 4G instead (strange that the conservation did not hangup at this moment) and I had no blanks anymore, but now she had some blanks on her side plus a "biiiiiip" just before the blanks on her Smartphone.

The beep sound will occur when the Mobile app switched from Wifi to LTE connection so that was expected since you asked the user to do this.

The fact that the user gets them at home too probably means that they are walking out of wifi range while on a call forcing the device to switch to LTE.

In any case, I recommend focusing on the IP Phones behind the SBC for now because anything involving mobile apps is completely other territory with more factors that come into play such as wifi signal, 4G networks, etc.

So, as @Saqqara mentioned, do check the PC's host file and remove the PBX FQDN from in it if it exists and then give the steps I recommended a try so that we can start eliminating possible scenarios.

 

[David_K]

OK is this "biiiip" a new feature of the v18 on iOS?
Nice feature that allows to roam automatically between Wifi and 4G but in the case the WFH user has a bad Wifi/4G, switching automatically every 30 seconds from 4G to Wifi and vice-versa is worse than loosing the connexion. There should be an option to unactivate this roaming feature.

But so for my "real" problem, for le local host FQDN, you mean on the SBC computer?
Already did check that, the host file is empty
(and if there is an host file somewhere else in the hundreds of computers they have, I won't know but I also do not see how it could interact with deskphones)

Asked the users to place a call between 2 local extensions
I'm waiting for the result.

But I'm wondering : maybe they had SIP alg issues on their router and we never had then when it was local PBX connected to the TRUNK but we have them now the PBX is hosted?

They have a SonicWall router, we never had issues before and the SIP transformation is unchecked, but after that their ISP routers could have SIP alg, I really don't know since this those routers have really basic configurations interfaces.

 

[David_K]

Users told me that she did try between 2 local desktphone and that she has no issues

I get crazy with that !

So it could be the communication between the SBC and the hosted PBX?
Maybe the router? SIP alg issue?

 

[ChrisC_3CX]

OK is this "biiiip" a new feature of the v18 on iOS?
Nice feature that allows to roam automatically between Wifi and 4G but in the case the WFH user has a bad Wifi/4G, switching automatically every 30 seconds from 4G to Wifi and vice-versa is worse than loosing the connexion. There should be an option to unactivate this roaming feature.

The roaming feature is what allows the call to stay active even if there was a hand off from Wifi to LTE. The beep sound is just to notify the user that the connection has temporarily been interrupted due to this so this way the user knows that no audio is being sent to the other side.

But so for my "real" problem, for le local host FQDN, you mean on the SBC computer?

Yes exactly, only that PC not the rest.

So it could be the communication between the SBC and the hosted PBX?

If calls between two SBC extensions without "PBX Delivers audio" and no recordings work fine then likely yes.

Maybe the router? SIP alg issue?

No impossible however I doubt it as the 3CX SBC connects to the 3CX PBX via the 3CX Tunnel meaning all traffic is encapsulated within the tunnel and therefore not clear SIP.

Now, since it seems the issue is indeed between SBC and PBX I think next thing to do is determine whether it's only this SBC site having the issue only. That way you'll know if you'll have to investigate on the PBX end or on the SBC site. This is where the iOS comes into play. The 3CX mobile apps also use the 3CX tunnel, so the fact that you had the issue there as well may mean the problem is on the PBX end. However, due to the nature of mobile devices, I'd recommend confirming this with more than one device. Better yet, you could use the legacy 3CX Windows App on maybe one of your networks, provision an Extension to it from this PBX and do a few test calls. The 3CX Legacy Windows App also uses the 3CX Tunnel. You can download it from the Welcome email:



So try:

1. Create a test extension.

2. Send a welcome email for that extension to yourself and download/install the 3CX App for Windows, then provision the test extension to it. Use the 3CX App for Windows on a separate network than that of the SBC. Preferably on one of yours you know has no issues.

3. Enable Call Recording for this extension (may prove useful later)

4. Make a few Outbound calls and test, do you still get the same behavior? Is it the same as the one reported by the users behind the SBC? If yes, what is the exact problem, listen to the recording and check if you can hear the same thing there too.

 

[David_K]

The roaming feature is what allows the call to stay active even if there was a hand off from Wifi to LTE. The beep sound is just to notify the user that the connection has temporarily been interrupted due to this so this way the user knows that no audio is being sent to the other side.


Yes exactly, only that PC not the rest.


If calls between two SBC extensions without "PBX Delivers audio" and no recordings work fine then likely yes.


No impossible however I doubt it as the 3CX SBC connects to the 3CX PBX via the 3CX Tunnel meaning all traffic is encapsulated within the tunnel and therefore not clear SIP.

Now, since it seems the issue is indeed between SBC and PBX I think next thing to do is determine whether it's only this SBC site having the issue only. That way you'll know if you'll have to investigate on the PBX end or on the SBC site. This is where the iOS comes into play. The 3CX mobile apps also use the 3CX tunnel, so the fact that you had the issue there as well may mean the problem is on the PBX end. However, due to the nature of mobile devices, I'd recommend confirming this with more than one device. Better yet, you could use the legacy 3CX Windows App on maybe one of your networks, provision an Extension to it from this PBX and do a few test calls. The 3CX Legacy Windows App also uses the 3CX Tunnel. You can download it from the Welcome email:
View attachment 28119


So try:

1. Create a test extension.

2. Send a welcome email for that extension to yourself and download/install the 3CX App for Windows, then provision the test extension to it. Use the 3CX App for Windows on a separate network than that of the SBC. Preferably on one of yours you know has no issues.

3. Enable Call Recording for this extension (may prove useful later)

4. Make a few Outbound calls and test, do you still get the same behavior? Is it the same as the one reported by the users behind the SBC? If yes, what is the exact problem, listen to the recording and check if you can hear the same thing there too.

Thanks @ChrisC_3CX

I'll try that.

About the mobile app, to me it seemed that they had the issue when she was connected to the corporate Wifi but not having the problem when connected to LTE (I mean the real "blank sound" issue, not the beep)
So that made me think it was a something related to their router/network, since that's the only difference I see when she uses the mobile on the Wifi or LTE.

Another guy told me the issue is because the deskphones are not on a separate VLAN (yes it's tue they are on the same IP range as the computers) but again I don't see the link since they have the issue with the mobile app also (can't tell about Windows app since no one is using it)

I'll do more investigations

 

[ChrisC_3CX]

she was connected to the corporate Wifi but not having the problem when connected to LTE (I mean the real "blank sound" issue, not the beep)
So that made me think it was a something related to their router/network, since that's the only difference I see when she uses the mobile on the Wifi or LTE.

Is this the same network the SBC is on? If yes, this may very well be the case, especially if you've confirmed it to be a ok on LTE.

Another guy told me the issue is because the deskphones are not on a separate VLAN (yes it's tue they are on the same IP range as the computers) but again I don't see the link since they have the issue with the mobile app also (can't tell about Windows app since no one is using it)

This is not necessarily an issue, provided of course everything is ok with the network in general.

 

[David_K]

Is this the same network the SBC is on? If yes, this may very well be the case, especially if you've confirmed it to be a ok on LTE.


This is not necessarily an issue, provided of course everything is ok with the network in general.

Yes when on Wifi, she was connected to the same network than the SBC is on.

And yes I think their network is saturated, and already working on that issue also that is a more general issue.
But about 3CX, they told me that problem occured the day after we moved to the PBX to cloud. So the network was the same the day before and after and we did not add a single deskphone. It sees even maybe even less trafic with just an SBC rather than the PBX onsite?
So to me this is not the issue.

 

[ChrisC_3CX]

And yes I think their network is saturated, and already working on that issue also that is a more general issue.
But about 3CX, they told me that problem occured the day after we moved to the PBX to cloud. So the network was the same the day before and after and we did not add a single deskphone. It sees even maybe even less trafic with just an SBC rather than the PBX onsite?
So to me this is not the issue.

Well if the IP Phones were local before but are now remote it means the remote site's WAN is now also in the equation and from what you're telling me it seems it is likely related to the issue. This is further confirmed by the fact that the iOS client on that network has the same issues, but works fine when you connect to 3CX via a different network (LTE).

You could maybe run packet captures on the 3CX PBX and on the 3CX SBC while a problematic call takes place and then compare the traffic on port TCP and UDP 5090, compare it on both captures and check if you can detect anything that seems out of place.