Raspberry Pi SBC, Option 66 and some wierd auto provisioning

[adamrl]

Hi all
Google and AI is doing my head in, so here I am.
I'll try to be as brief as possible, but in summary:

If I have a Raspberry Pi set up as the SBC, and phones point to that - do I actually need my firewall sending out Option 66 for auto provisioning?

Set up:
3cx hosted V20 using (sorry) Yealink T42 handsets
Two sites linked together via VPN with two Raspberry Pi SBCs in HA mode at each site (one site points to one HA, the other points to it's own)
Network set up for default VLan, then using option 132 to switch to telephony VLan, then option 66 to auto provision.

Now, here is my issue. After a few changes (3cx from on prem to hosted, internet service switched from one provider to another etc etc) we were finally up and going. However, for some reason the address book is missing and when you call someone, it only shows the extension and not the users name. If I reprovision the handset they come back. BUT..the provision takes a stupid amount of time - from 10 minutes to some cases an hour or so.

So my question, as above - do I really need 66? I'm suspecting there is some back and forth going on that is causing the auto provision inconsistency.

Thanks

adamrl

 

[Saky]

Hi,

With SBCs in play you should not need DHCP option 66 at all. The SBC should be doing it's bridging duty and populating the phones as PnP devices in the PBX.
Do note that the phones will need to be able to get to the RPS, so they must be able to access the general internet for this.

 

[paulodagraca]

Hello,

Try to not use VPN, just connect every location to the cloud with the use of an SBC.

Phone -> SBC -> internet -> Cloud 3CX <- internet <- SBC <- Phone

Paulo

 

[Saky]

Hello,

Try to not use VPN, just connect every location to the cloud with the use of an SBC.

Phone -> SBC -> internet -> Cloud 3CX <- internet <- SBC <- Phone

Paulo

Yes, true.

I think the VPN is so that the two SBCs provide HA to each other - but yes it does mean one side will have all it's telephony traffic going via the other all the time and probably end up not having the best call quality.

This probably also means the one SBC might be a bit overloaded...

VPN is probably the weakest link in this setup anyway, and having per-site HA with two SBCs would be the way to go, they don't need all that much hardware after all.

 

[paulodagraca]

Guy's what does HA mean here??

I only know it as Home Assistant server... hope this is not what you mean

 

[Saky]

Guy's what does HA mean here??

I only know it as Home Assistant server... hope this is not what you mean

Quiz time!

1. High Availability
2. Hot Audio
3. High Accuracy

 

[JohnS_3CX]

That's quite the convoluted setup there are you sure all this is needed?

- VPN
- VLANs
- 2 HA SBC setups (totalling 4x Raspberry Pi devices)
- And DHCP Options 66 and 132
- Actual IP phones, each with their own firmware peculiarities no doubt

But first tell us exactly what models your phones are, what firmware version they are running, and if you use custom FQDN and certs. This is more important than the above when it comes to provisioning.

 

[adamrl]

T

That's quite the convoluted setup there are you sure all this is needed?

- VPN
- VLANs
- 2 HA SBC setups (totalling 4x Raspberry Pi devices)
- And DHCP Options 66 and 132
- Actual IP phones, each with their own firmware peculiarities no doubt

But first tell us exactly what models your phones are, what firmware version they are running, and if you use custom FQDN and certs. This is more important than the above when it comes to provisioning.

Thanks for everyone's replies. I agree I think I'll turn of 66. The VPNs are not 3cx based - they are required as there a resources at one site that are required at another site that can only be reached via VPN.
Yes custom FQDN, no certs, T42s at latest (last) firmware. VLANs for, well, VLANs. Better security, easier to manage, reduced network traffic etc.

 

[JohnS_3CX]

Yes custom FQDN, no certs, T42s at latest (last) firmware.

That's probably the failure point right there before we can blame anything else, especially when you said they provision but the phone book will not update afterwards

IP phones have limited Certificate Authorities built into them. So if you use a custom FQDN (which implies custom certificates even though you said no certs) there is probably something wrong in the certificate chain, or you are using a CA that they don't support. This is a common problem for people using custom FQDN and can easily be solved a couple of ways

1. Use a 3CX FQDN instead of a custom one: we provide you with the certs and we know for a fact that they are supported by any phones 3CX currently supports (this is the recommended path)

2. For custom FQDN use certs that are already supported by your phones and if not, upload your own CA into the phones before you provision them. But make absolutely sure the cert chain is complete with any intermediate certs needed. (this is supported by you only, you have to do all the work)

 

[adamrl]

To clarify, sorry it's a 3cx FQDN. That is domainname.3cx.com.au.
Now I provisioned an older handset again and yes, it did provision but it took 10-20 minutes.
I've now tried a T33G (albeit upstairs not downstairs) and it provisioned in around 4 minutes so that's better.
I'll take the T33G downstairs to the same location as the other and see if it provisions there, then take the older T41 up to THIS location and test. If all is the same, I think we are talking older handset model being the issue.

Thanks for all the suggestions and help so far!

 

[adamrl]

The T33G provisioned downstairs no issues, but had to be actually deleted and readded in the console and then factory reset for it work - otherwise it just said redirector skipped and did nothing.
I'm sure these will provision - but I really don't want to wait 15 minutes to find out but I might have to!