Solved Unable to auto-provision phones behind SBC

[VoIPQZ]

Hello,

I'm having an issue where I cannot auto-provision new phones behind a SBC.

From my understanding, I would only have to plug the phone in the SBC's network and see it in 3cx Phone page, but I do not.

If I add it manually under it's extension, it still doesnt work (phone asks for credentials, and when entering them, says Update skipped).

If I use STUN provisioning, it also still doesnt work (it worked with STUN when I didnt have the SBC on the network)

The only way found to provision the phone was to manually set the provisioning link in the phone, which I'd like to avoid doing since that's not very efficient when deploying multiple phones at a remote location.

I've tried reading about this issue, but everything I find talks about some DHCP Option 66, which people says does not matter/work for behind SBC.

Any idea what's going on?

 

[Evolute IT]

Hello,

I'm having an issue where I cannot auto-provision new phones behind a SBC.

From my understanding, I would only have to plug the phone in the SBC's network and see it in 3cx Phone page, but I do not.

If I add it manually under it's extension, it still doesnt work (phone asks for credentials, and when entering them, says Update skipped).

If I use STUN provisioning, it also still doesnt work (it worked with STUN when I didnt have the SBC on the network)

The only way found to provision the phone was to manually set the provisioning link in the phone, which I'd like to avoid doing since that's not very efficient when deploying multiple phones at a remote location.

I've tried reading about this issue, but everything I find talks about some DHCP Option 66, which people says does not matter/work for behind SBC.

Any idea what's going on?

Your local firewall might block Multicast (used to discover phones).

Entering the link and rebooting the phone should force it to provision.

What do you use as config? FQDN? IP?

 

[eddv123]

The provisioning request comes down to the phone redundant to the 5090 tunnel port, chances are your local firewall is blocking HTTPS 443/5001 whichever you are using.

See slide 10:
https://www.3cx.com/3cxacademy/videos/intermediate/configuring-remote-extensions/

 

[CentrexJ]

Is the sbc on a different vlan than the phones? The sbc has to be able to see the multicast traffic from the phones to send the info to 3cx. If the sbc runs windows it could be like others said a local firewall issue as well.

 

[VoIPQZ]

Currently checking with my NOC team as to the settings on our new firewalls recently installed to make sure.

The full setup is a Cloud hosted PBX, with a Raspbian SBC on the same VLAN as the phones.

Phones are Yealink (1x T23G and 2x CP920). The first CP920 and T23G have no issue, but I provisioned those through STUN before the SBC was installed. The second CP920 is the first phone I try to provision with the SBC and our new firewalls and have been having issue (and as I said, also does not work by STUN anymore).

Manually inputting the Provisioning link in the phone's config worked, but is not the optimal route to go as we are preparing to install phones at remote locations and would much rather it to be auto-provisioned as it's supposed to be.

Will update once my NOC team gets back to me on our new FW configuration.

 

[eddv123]

The fact that manual insertion of the provisioning link into the phone works backs up my earlier point.

You need to allow HTTPS through, at the very least just for the auto provisioning process.

 

[cobaltit]

The fact that manual insertion of the provisioning link into the phone works backs up my earlier point.

You need to allow HTTPS through, at the very least just for the auto provisioning process.

Actually it doesn't backup your point. Manual provisioning would still require 443 or 5001 to be open to download the configuration file so it's not likely those ports are blocked. PnP is done via SIP messaging which would travel via the tunnel traffic, again not depending on the HTTPS port.

@MaxQz

Please confirm you are on the latest version of 3CX (v16 Update 4) as well as the latest version of the SBC (16.0.390). Then confirm you've followed this guide:

https://www.3cx.com/sip-phones/yealink-t20p-t22p-t26p-t28p/

If you have the phones on the correct firmware version and then factory reset them they should show up. If they don't, then you likely have a switch issue blocking multicast:

https://www.3cx.com/docs/plug-and-play-ip-phone/

If you are unable to change the switch configuration then I would recommend DHCP Option 66.

 

[VoIPQZ]

HTTPS Port have been open, but still facing the issue. Looking at Multicast next...

For DHCP Option 66, I thought that was only valid for Local PBX? I've read that it causes issue with SBC/Cloud hosted.

 

[cobaltit]

Weird,, was just replying to @eddv123 post and it disappeared.

HTTPS Port have been open, but still facing the issue. Looking at Multicast next...

For DHCP Option 66, I thought that was only valid for Local PBX? I've read that it causes issue with SBC/Cloud hosted.

Where did you read Option 66 would cause issues? At the end of the day the goal is just to get the provisioning URL into the phone. I wasn't aware of this being an issue. Now if you have an Option 66 set that you aren't expecting and it conflicts with what you are trying to do that can be an issue, but otherwise it shouldn't be a problem. It just requires you to enter the MAC addresses into 3CX per extension vs PnP where you can assign them to the extension as they show up in the console. Saves a few keystrokes. But for larger deployments, Option 66 with bulk import is definitely the way to go.

 

[VoIPQZ]

Weird,, was just replying to @eddv123 post and it disappeared.



Where did you read Option 66 would cause issues? At the end of the day the goal is just to get the provisioning URL into the phone. I wasn't aware of this being an issue. Now if you have an Option 66 set that you aren't expecting and it conflicts with what you are trying to do that can be an issue, but otherwise it shouldn't be a problem. It just requires you to enter the MAC addresses into 3CX per extension vs PnP where you can assign them to the extension as they show up in the console. Saves a few keystrokes. But for larger deployments, Option 66 with bulk import is definitely the way to go.

https://www.3cx.com/community/threads/auto-provisioning-of-yealink-phones-after-factory-reset.53553/

This post indicates issue with re-provisioning and updating firmwares with Option 66 on SBC.

 

[cobaltit]

Gotcha, thank you for that. Not sure if that is still the case (it was a while ago) so I'll have to test that at some point. But definitely sounds like multicast as @Frederick Marcoux mentioned earlier and I missed.

 

[JohnS_3CX]

@MaxQz

The way it works is

1. Phone boots up and sends a multicast message
2. SBC sees it and informs PBX
3. PBX shows the new phone in the "Phones" section so you can autoprovision it
4. Once you do, PBX informs SBC
5. SBC informs phone to go provision itself from the URL

You are having a failure at step 2 so focus on finding out why the multicast is not working

PS: you are getting the login screen on the phones because you have previously set them to STUN. The phone contacts the RPS server which gives it the provisioning URL of your PBX (after providing extension and PIN of course)

 

[VoIPQZ]

Issue resolved, was indeed multicast related.

Thanks everyone for the help.

 

[JohnS_3CX]

Glad to hear it was resolved