Raspberry PI SBC PNP Provisioning Bugs?

[netelligence]

I've been impressed with the Windows SBC. It seems to pretty much do what it is supposed to do and lets you do PNP provisioning of phones, reprovision phones, reboot the phones from the 3CX console.

Not so with the Raspberry PI Version. New phones don't show up in the 3CX console and when I manually provision them, the console won't reprovision the phones nor reboot the phones. Calling features work fine and even the 3CXPhone CTI functions will work fine.

When I use TCPDump on the PI to watch broadcast traffic, I can see the phone broadcast when it starts up, but the PI makes no response back. When I watch the Windows SBC in wireshark, I can see the phone broadcast and the Windows SBC respond.

Any known issues on this? Could this be a bug? Seems odd that all other functions operate except provisioning with the PI. It definitely behaves differently than the Windows version.

Thanks for your time.

Netelligence.

 

[lneblett]

I observed what I think is the same issue, but have not delved into it as deeply as you.

In my case, I have a client with a remote office some 30 miles away using Cisco SPA-504g phones. They had been using the tunnel, but the PC was an issue for them so I was able to manually configure and run the phones without the tunnel as there are only 4 phones involved. This has been working fairly well from a voice perspective, but the BLF keys would occasionally quit working or fail to monitor and show Orange.

I thought this might be a case for a PI to come to the rescue. In any event, I set up a test in the office where I took another 504g and provided the provisioning path. The phone picked up various parts. By this I mean that it picked up and executed the Background logo I installed, it also picked up the firmware path and made an effort to upgrade, but the latest was already installed.It also picked up the phonebook path and changed the settings for NAT and all correctly however, it did not pick up the BLF keys. It installed all the keys as the primary registered extension. I left it overnight and when I came in the next morning, it had picked up the BLF keys. Like you a manual command from 3CX to reboot did not seem to work. I do not know what phone make/model you were using so I assume that could be a variable as while similar, our results are not exactly the same.

I then checked the config file to ensure that the file was correct and it was. I then deleted the config file and changed the BLF keys to another set of extensions as a test. The config file was re-generated with the new info. I then did a manual change to the phone whereupon it came back up with the keys all being set to the registered extension again (no clue why as I did not touch this area). I then proceeded to execute a re-provision from 3CX to see if the phone would take. After waiting for some 3 to 4 hours, I had to go on some calls, but it had not re-provisioned as of my leaving. I will be back in the office shortly and will advise.

I may need to take the test to a "sterile" site as I suppose it possible that my office has too much going on with firewalls and the like to really represent the environment in which I intend to install. I certainly do not want to take it to the client and for whatever reason have the phones reboot and lose the BLF keys.

 

[lneblett]

The 504g did re-provision last night at around 2AM which is a pre-programmed time in the phone interface.

I then took away the power to force a reboot. Upon rebooting the phone restarted and tried to upgrade firmware again, but it does appear as though the BLF key programming remained. However, when it finished re-booting it took it a couple of minutes to synchronize the BLF keys to what was the actual status. Once the sync occurred it appeared to function fine afterwards.

 

[new15]

I am seeing the same issue with reprovision and/or rebooting - neither work. I'm using v12 with SP6 and Yealink T48G phones with the 35.72.0.225 firmware. If the phones are factory reset, they show up in 3CX and can be assigned to an extension and provisioned as expected, but that's it. As soon as that happens, the ability to control those phones from the management console ends. They can't be rebooted or reprovisioned. If I make a change to the provisioning template and need to apply it to those phones, I have to factory reset the phone again and start over.

 

[realmarshall]

I have exactly the same issue - V12 with Yealink T46/48 and PI SBC. Everthing works as it should (once you figure out what was missing from the setup documents for 3cxsbc), but after a phone is provisioned, there is no way of controlling it from the server management interface (reboot/reprovision/reset and reprovision). That makes managing a remote site very tough.

Although I've set things up to allow SSH into the PI for troubleshooting and updates, there's no way to reset & reprovision a phone without physical manual interverntion at the remote site.

 

[NickD_3CX]

Hi,

I have tested a T46 running firmware v28.71.0.224 provisioned though a Windows SBC v12.035707.33 to a V12 Cloud on Tenant 1 and both "Reprovision Phones" and "Reset & Reprovision Phones" options are working, sometimes though it might take as long as 4-5 minutes to get the settings. Only the "Reboot" option doesn't work.

If you run a Wireshark capture while pressing the "Reset & Reprovision Phones" option you should be able to see a SIPNOTIFY the contains the provisioning link going from the PBX to the SBC and then a GET from the SBC trying to retrieve the configuration file for that phone from the provisioning link previously received.

Can you advise us what you are seeing?

 

[realmarshall]

This specifically relates to Raspberry PI SBC (for me at least), so to reproduce you would need to

1) Use a PI SBC (as opposed to Windows)
2) Have the phone and SBC on a physically remote network that transits NAT

I will try and free some lab time up to pcap this.

Also worth mentioning that BLF's don't appear to work behind the PI SBC either, so I'm guessing there may be some issue with SUBSCRIBE & NOTIFY.

 

[realmarshall]

I just ran a pcap on the 3CX server. When the 'reset and reprovision' link is clicked for an extension behind a Pi SBC, the NOTIFY is sent to the Pi SBC with the provisioning link, but no GET (or anything else) is received by the server from the Pi. This is consistent with the issue that provisioning only takes place if initiated by the phone itself.

All other signalling works correctly, with the exception of this and BLF's, so I don't believe this can be attributed to the network topology or NAT.

 

[mdages]

I've been impressed with the Windows SBC. It seems to pretty much do what it is supposed to do and lets you do PNP provisioning of phones, reprovision phones, reboot the phones from the 3CX console.
Not so with the Raspberry PI Version. New phones don't show up in the 3CX console

Same problem here. RasPI SBC, new phones don't show up. Replace the RasPI by Windows-SBC, it works. So it's definitely not a network or 3cx server problem. It seems RasPI SBC don't handle autoprovisioning plug and play requests.
In my opionion, a bug in 3cx SBC software for Raspberry PI.

-Markus

 

[expernet]

Just an FYI. I a have experienced many of the problems listed above with the Windows SBC. They include:
1. Not being able to re provision the phones from the console.
2. Sporadic loss of provisioning files. (some phone provision fine, others need multiple manual reboots)
3. The upgrade firmware menu selection is not functional on the Phones screen for SBC phones.
4. When the extension is reassigned to an SBC phone, the previous phone will not let go of the extension. IE the person will have 2 phones assigned to their extension which both ring. The only way to remove the dual phones is to factory reset the unwanted phone.
Probably not the right thread but this is for those who are contemplating switching from Raspberry PI to windows SBC.

 

[chris.moses]

I'm seeing similar behavior in my test environment on v14. Phones using a Raspberry Pi SBC seem to work fine (including displaying correct BLF status) but I cannot reboot or make any changes to the DSS keys (using Yealink T48G and T26). Going to test a STUN configured phone from the same network, but I prefer to come in through an SBC.

EDIT: I'm seeing different behavior when configured with STUN. I can reboot the phones remotely but changes to DSS keys still don't work on remote phones, even after a reboot.