Solved Softphone and SBC and Registration failure, oh my!

[MCHomestar]

Hey folks,

So here's the skinny: I have a 3CX hosted instance of the PBX running fine. The local SBC is connecting to it fine as well and any and all IP phones I provision are working correctly, however...when I try to 'register' my softphones with the system, it fails.

What I've noted is that within the settings for the account being used by the softphone, it is only configured to use the external host (business.my3cx.ca) under the 'out of office' section. If I manually put in the IP of my SBC in the "in office" section of My Location, it works like a charm.

My question is two fold: can I set these in-office/out of office settings within the 3CX management console to default correctly (since my PBX is never 'in-office') and two, is it possible to edit the default softphone template so that it uses the SBC for 'in office' instead of being blank? There is no template management that I can find currently to make these changes.

Thanks in advance everyone!

Cheers

3CX Hosted instance, 16.8.0.9, SBC 16.2.4 (internal network), Softphone 16.3.0.220

 

[Saqqara]

Please note softphones do not use the SBC server, they communicate directly to the 3CX server over the 3cx tunnel.

The softphones should connect, as it sees the device it not connected externally.

Under options for the extension, do you have 'Block Remote Tunnel Connections (3CX App connections with Tunnel enabled & SBC will be blocked)' ticked.

Have you checked the activity log to see any entries relating to the softphones ?

 

[MCHomestar]

Please note softphones do not use the SBC server, they communicate directly to the 3CX server over the 3cx tunnel.

The softphones should connect, as it sees the device it not connected externally.

Under options for the extension, do you have 'Block Remote Tunnel Connections (3CX App connections with Tunnel enabled & SBC will be blocked)' ticked.

Have you checked the activity log to see any entries relating to the softphones ?

That box is not checked. The one for STUN is, but I'm not using that. As for your statement "The softphones should connect, as it sees the devices it not connected externally", they should connect to what? The external hostname? Why would putting in the SBC IP work then (and actually allow phone calls, not just registration)? Currently, softphone provisioning does NOT put anything in the 'in office' box, so I don't know what it would connect to if it saw that it was 'in office' :\

*edit for spelling

 

[Alphabetic]

The fact it works via the SBC could indicate you have a network issue. I would check to see if your firewall is doing any port blocking. Can you use the softphone from another network?

 

[Saqqara]

As above , are you blocking outbound port 5090 (tcp and udp) and https port (443 or 5001)

 

[MCHomestar]

No, there are no ports being blocked outbound at all that would be needed but here's my question: why would testing on another network prove anything? The major issue is that the 'in office' section of settings is blank, therefore the softphone, from within the same network, is trying to register via the FQDN externally! Why on earth should it have to leave my network, hit the web, get redirected to hosted 3CX and then back through my internal SBC just to work!?

Admittedly, this is frustrating and my apologies if I'm coming off as such. This entire thing would work if it just filled in the 'in office' section with the SBC from what I can see. I wish there was a way to either edit the template or force the system to fill it in and keep it.

 

[JohnS_3CX]

No, there are no ports being blocked outbound at all that would be needed but here's my question: why would testing on another network prove anything? The major issue is that the 'in office' section of settings is blank, therefore the softphone, from within the same network, is trying to register via the FQDN externally! Why on earth should it have to leave my network, hit the web, get redirected to hosted 3CX and then back through my internal SBC just to work!?

Admittedly, this is frustrating and my apologies if I'm coming off as such. This entire thing would work if it just filled in the 'in office' section with the SBC from what I can see. I wish there was a way to either edit the template or force the system to fill it in and keep it.

Let's clarify a couple of things since this is a cloud hosted instance:

1. SBC: Only for hardware phones - no softphones period!

2. The In/Out office boxes: What you saw is perfectly correct, there is no back and forth between the SBC because the SBC is ONLY for hardware phones, see point 1.

3. Your 3CX Windows app will reach the PBX using the external host ie. "business.my3cx.ca" only. It does not rely on anything else other than the network you connected the app to. This is why it was recommended that you try connecting the app from elsewhere - so you can compare and see if your office connection was blocking you

4. Do NOT manually configure your app to use the SBC, these two were not designed to work together.

5. The "In-office" field was designed for use on systems that are not in the cloud. This means when the PBX machine is installed at the same office as the users of the app (so it does not apply in your case).



To conclude, your issue is that the app "fails". You should tell us exactly what is meant by "fails" and also in the meanwhile, test it from another network location just to compare. If in doubt, please create a fresh extension, leave everything on defaults and send a welcome email to yourself to provision the app.

 

[MCHomestar]

Let's clarify a couple of things since this is a cloud hosted instance:

1. SBC: Only for hardware phones - no softphones period!

2. The In/Out office boxes: What you saw is perfectly correct, there is no back and forth between the SBC because the SBC is ONLY for hardware phones, see point 1.

3. Your 3CX Windows app will reach the PBX using the external host ie. "business.my3cx.ca" only. It does not rely on anything else other than the network you connected the app to. This is why it was recommended that you try connecting the app from elsewhere - so you can compare and see if your office connection was blocking you

4. Do NOT manually configure your app to use the SBC, these two were not designed to work together.

5. The "In-office" field was designed for use on systems that are not in the cloud. This means when the PBX machine is installed at the same office as the users of the app (so it does not apply in your case).



To conclude, your issue is that the app "fails". You should tell us exactly what is meant by "fails" and also in the meanwhile, test it from another network location just to compare. If in doubt, please create a fresh extension, leave everything on defaults and send a welcome email to yourself to provision the app.

That is helpful, thank you.

I've seemed to find the failure point. There was an option set on the extension 'Use 3cx tunnel for remote connections (3cx app only)'. This was checked, but once unchecked, the app registered and provisioned correctly.

Thank you everyone for the feedback. I'm still fairly new to PBX and 3cx specifically, so this was a good learning experience.

Now to just get the darn CallerID to work when 'ring mobile at the same time' is on! (forwarding works fine)

Thanks everyone!

 

[JohnS_3CX]

By default that option is enabled and it is recommended that you leave it on.

But the fact that it was failing though, would make me suspect that that something on your network blocks tunnel port 5090 (perhaps it is reserved?).

If you find what was blocking it, we highly recommend you re-enable this option because it encrypts the traffic to/from the PBX and the app.

 

[MCHomestar]

Interesting. So you're saying that it's not just the SBC that needs 5090 (as I was previously told) in order to allow Softphone provisioning? Ugh...thanks John.

 

[JohnS_3CX]

Correct. 5090 is actually utilized by:

- The SBC
- The mobile Apps
- The windows App
- Bridges (optionally)

If by chance you've created a port forward for 5090 on your firewall, this may be blocking other endpoints from using it. It is not necessary to port forward 5090 at all.

 

[MCHomestar]

Correct. 5090 is actually utilized by:

- The SBC
- The mobile Apps
- The windows App
- Bridges (optionally)

If by chance you've created a port forward for 5090 on your firewall, this may be blocking other endpoints from using it. It is not necessary to port forward 5090 at all.

That was it. I let 5090 TCP through from all non-WAN ports and away it went. I still find it odd since the Edge extension and Android apps worked, but maybe because I initially had 5090 only allowed from the SBC.

Thanks again John. Most helpful and I'm learning...I hope

 

[JohnS_3CX]

Great news! Glad to hear it has now been resolved, will mark this one as solved then