Do all 3CXphone (softphone) clients go through the SBC?

[Chib@voip]

A client has some audio issues with unsupported IP phones that connect through an SBC. (gigaset N300IP en N510IP)
Looking into the problem I want to know what other phones make use of this exact SBC and if they have problems as well.

Now when I look at the Phones node in the 3CX management console I can see some 3CX phone clients as:
SBC:3CXPhone for windows 8 xxxxxxx and in the IP column I can see 192.168.1.15 via SBC 192.168.1.99

While other 3CXPhones show up as:
3CXPhone for Windows 14xxxxx and in the IP column it shows 192.168.1.19 without any mentioning of the SBC.

Can I conclude that the people that go through the SBC must have configured this by themselves? (We did not install it for them)
Or is it possible that somehow in certain circumstances 3CXphones connect themselves unto the SBC? (as far as I knew they don`t)

And my final question is:
The Tunnel that the SBC will set up is the same (kind of) Tunnel as the 3CXPhone clients use without the SBC?

 

[lneblett]

You have several different questions in the post. So let's start with the first -

Looking at the various forums and posts, there appears to be a number of installs using SBCs and with various makes and models of phones. There should be no difference in how the phone reacts to the use of an SBC, but the 3CX SBC is limited in its capability as to how many phones it can handle at the same time. It is reported by many that the limit is 5, but this is dependent on a number of factors such as how many BLF keys and the amount of transferring, etc. I have been led to understand that the ideal limit should be no more than 3, but I also understand that there is (or may have happened already) an effort to upgrade the unit. The point of the SBC is to overcome firewall issues and ideally keep traffic that is internal to the remote site just that so it is not traversing the internet when not needed.

A site to site VPN, if possible, might eliminate much of the problem.

You may need to take a look at the extensions to see what interface was selected in the provisioning tab. This may answer some of the question about how the phones appear with and without SBC. Also, when the extensions were created, perhaps the welcome email was sent, which has details about how to provision things and includes the provisioning config where all one needs to do, provided the client software is installed, is simply to click on it (attachement) whereupon the softphone will configure itself and connect to the system.

 

[Chib@voip]

Thank you for your reply.
Its not a standalone version, but a hosted 3CX v14.

They currently use about 25 phones of which 10 call through this SBC (hardphones and softphones).That is what I can understand from the Phones node in the 3cx management console.
Their SBC is installed on a local computer (server).
But I just dont know if I can trust the Phones node.

So Id like to know how it is possible that Softphones connect through the SBC. They should have done this by changing the settings in their softphones isnt it?

And if it is a Tunnel problem, do Softphones that do not connect through the SBC use the same Tunnel that the SBC uses.

 

[ian.watts]

Hard to say.. best to look at what the config actually says.

I recently configured an SBC test at home, to close off external SIP to just the trunk/provider.. tunnel in the rest.
I haven't closed it off just yet.

I rigged an rPi 3 on Raspbian.. with the Pixel UI and some ScreenConnect to get a wireless connection established.
From there, I have a Cisco SPA525G2 also on wifi.. I'm also testing how well/poor an rPi SBC on wifi would deal.. where the handset is also wifi.
FYI.. worked fine until wifey started steaming some Hulu.. Need to QoS.. but another story perhaps.

Anyway, I switched users on my desktop PC and fired up the phone. It was happily unconfigured.. but did appear in the Phones. I could identify it by 127.0.0.1 address (the SBC is on the tunnel) and the MAC address matches my PC.

However, though the multicast certainly got tunnelled though.. seems that assigning it to an extension did nothing for me. Sad.

On the other hand.. I then just changed my own softphone config from using an external tunneled connection to a non-tunneled SBC connection.. works fine as expected.

However.. neither the Cisco handset or my softphone report that "via SBC" which I have seen on other setups.. instead it just lists my own LAN addresses.. at home.. which is way different than the ones at the office.

Unless there is a reason a 172.16.47.0/24 subnet doesn't jive.. I'd expect it should have shown me the "via SBC".. but didn't.
The office has that Comcast with the usual 10.1.10.0/24 network.. may have to retry there.

To answer the question specifically.. they can use an SBC.. it's not clear to me that the usual "assign to an extension" option will do the job as far as provisioning it goes.

 

[Chib@voip]

Thanks Ian.

So that basically confirms my suspicion, we can`t rely on what the Phones node tells us whether a phone connects through the SBC or not.
The problem is that the customer uses the 3CX softphone on laptops and cellphones that are not always turned On. So that makes it difficult to check what their configuration looks like.

Anyhow, we sent them a test phone (Yealink) that did not connect through the SBC and they reported they didnt have any audio problems on that phone. So whether the problem lies in the SBC, or the actual Gigaset phones is still unknown.

We asked to change the settings on the Yealink phone to connect through the SBC and see if that causes any problems, but havent heard from them since. If that causes the same problem on the Yealink we have something more specific to look at.

 

[ian.watts]

That view changed from v14 to v15.. that much I can say.

I just configured a new rPi SBC to a v14.. shows that 'via SBC <LAN IP>" as expected.

 

[Chib@voip]

Ouch, so you`re actually saying that V14 does show the correct list?

Anyhow, the customer installed a new firewall and configured the hardphones to connect to our server directly, and not through the SBC, and it seems to work fine now.

 

[ian.watts]

Yeah, 14 seemed more accurate in telling me a phone was registered through a particular SBC than 15. Couldn't say why.