Any Way to Remote Factory Reset & Configure Digium D Series phonesh

If I can get a remote desktop connection to windows machine on a private network in another state, is there any way to do a factory reset and reconfigure of the phone without physically being there? (i.e. models D40, D50, D65)

No there is not.
I have requested this feature over and over as we have customers with sites all over the country.
You cannot access the web GUI like you can with other manufacture phones and even Sangoma S-series phones.
Sangoma’s arguemnet todate has been that is a security risk.
My response back has been:

  1. Sangoma assumes that the customers network is a security risk?
  2. Customers on site can factory reset any phone. No password needed.
  3. We have customers complain because they pay us to maintain their system but anytime a factory reset is needed an employee has to be involved onsite to make this happen.
    The more people who request this the more likely this will happen.
    Add your opinion here.
    allow us access to the GUI and have it password protected like Yealink, Polycom, s-series etc.
1 Like

Uh, Cisco phones are exactly the same way.

The solution to remotely rebooting, fortunately, is simple. If you have an enterprise - and I define an enterprise as multiple sites - you use enterprise level switches.

My go-to to reach for in this instance is a used Catalyst 2950 PoE switch. These are very cheap off Ebay and the 24 and 48 port models are highly reliable and last -decades- Even if you don’t own the sites in the enterprise, surely your customers won’t object to paying $50 for a managed switch that is 100 times better than a cheap unmanaged switch barely suitable for someone’s game room.

Under CatOS the command to turn off PoE power on a port (for example fastethernet0/1) would be:

(do a show run and copy the config for the port)

config t
default interface fastethernet0/1
power-inline never
exit
exit

To turn it back on you have to copy the config of the port and then do

config t
default interface fastethernet0/1
(then paste the config for the interface back)
exit
exit

The default thing and copy and paste is needed since some Catalysts have a bug where they “leak” power even when PoE is turned off on the port. Resetting the port fixes that. Of course, your phone may work normally (turn off then back on) with just the power-inline never/no power-inline never commands.

Or you can just reboot the switch. (obviously do that after hours)

I believe you’re the only one. There is no clear definition of enterprise in the US but other countries and regions of the world have defined it. Having more then one office isn’t one of the criteria. I have had real estate and other companies that have had multiple offices around a city or area but only had less than 50 employees. None of them considered themselves enterprise.

Just so I’m understanding right, you’re recommending 15+ year old switches that no one supports (including the vendor) as a solution for an enterprise entity in 2024? That’s not very enterprisey at all.

You can build a network with an eye to following enterprise standards even if it is not large enough to meet some Cisco salesman’s snobby definition of “Enterprise” and use enterprise-quality gear doing it. And you can do it on a SOHO budget by using older gear which in the case of gigabit Ethernet switches is perfectly good.

The unmanaged junk that is sold with weird Chinese names on it through Amazon is just as unsupported. In fact, WORSE.

Current Cisco Catalyst switches are all smartlicensed which means they shut down if you stop paying the yearly Cisco fee. Apparently, Cisco believes they still own the gear even after you have bought it and installed it in your network. I don’t use their new gear that is like this. If I use new ethernet switchgear I use other vendor’s gear. But the older Catalyst gear is very solid, and last forever, and is cheap.

If you wish to drop $1000 on a new 48 port ethernet switch that will pull $250 a year in fees out of your budget for absolutely nothing, and works exactly the same as a 15 year old switch that costs very little and does not have such ridiculous fees, you are welcome to do so.

I prefer to spend the budget on new servers and things that are a better use of the money.

And I don’t need Cisco TAC to support it.

It was all Cisco gear because we were a Cisco shop back then. They even had the exact switches you recommended in this thread. Granted that was over 15 years ago so the switches were still being made and supported. We supplied MPLS between all their locations and even had a version of SD-WAN 15 years before SD-WAN was a marketing thing.

Again, having more than one office location doesn’t make you enterprise. If that was the case My little shop now with a couple of offices and under 8 employees is Enterprise.

You have no idea what I’ve done or know about. I’ve used Cisco, Juniper, Broadsoft, Genband, Meta Switches, Ribbon SBCs and others. I was part of the engineering team in charge of the three data centers the CLEC I was at owned. A CLEC with 200+ employees and 20M+ in annual revenue. Now that is enterprise.

Switches of that class I installed 15 years ago are still functioning today doing exactly the same thing that brand new switches would do. Ethernet frames have not changed over that time. Just because it’s older does not mean it’s no longer up to the task, and it does not make it bad.

There’s TONS of automobiles on the road today that are 15 years old - or older. I drive a 2003 Buick that has a coat of paint as shiny as the day it rolled off the assembly line. It takes me where I want to go including periodic 4 hours trips that go hundreds of miles.

Ah no. That is just big. What made it Enterprise wasn’t the size. What made it Enterprise was HOW YOU VIEWED IT. If you had bought SOHO residential grade junk to put it together with - non managed switches and other crappy infrastructure - you could have certainly kept it running. For a little while. But it WOULDN’T have been managed like an Enterprise because technically, from that POV - it wouldn’t BE an enterprise. It would just have been a collection of crappy unmanaged uncontrolled connections plugged into each other.

The ONLY people who think like this age=garbage nonsense are salespeople. They will HAPPILY sell you brand new stuff to replace your old stuff, telling you how much better it is than your old stuff, even though it does EXACTLY THE SAME THING your old stuff did.

kendalldever15 complained about a problem that DOES NOT EXIST with high quality gear. The ONLY reason he is complaining about it is…drumroll… because he thought SMALL. He figured, oh I have this tiny little 20 phone customer. They don’t have much money. I’ll tell them that their brand new “generic Chinese Ying Tau” Ethernet switch that’s unmanaged they bought off Amazon is perfectly fine. He wasn’t thinking of his 100 customers that size all bundled together constitutes an Enterprise - even though it absolutely is. If he had told every single small 20 phone customer he brought on “Dudes, our minimum configuration is a remotely managed switch. Your Ying Tau thing, even though it’s shiny new, does not meet the criteria. I know you spent $250 on it a year ago. So here’s our deal. Your choice is you buy a brand new Cisco or we trade in your Ying Tau switch for a perfectly serviceable older model Catalyst or Aruba or whatever that we will warranty for a year. Or a Netgear or something else that’s remotely rebootable. And you run a firewall that allows us to remote in. I know you have a single dynamic IP from your ISP because it’s cheap. We have dynamic DNS that takes care of that. But our minimum requirements are you do this or we don’t take you on.”

Volia, problem solved. Customer doesn’t know a switch from a hole in the ground or they wouldn’t have the Ying Tau thing in the first place. Customer will have forgotten they were required to have a switch change 2 weeks after everything comes online.

I’m telling him “you can solve your problem by your approach” Instead of his approach just bugging Sangoma repeatedly, and getting nowhere, he could have had the problem solved. All by an attitude shift.

I’m out here trying to get people to THINK. You don’t have to accept the new cheap junk just because it’s new when we have Ebay that’s flooded with old cheap Cadillac gear that runs rings around the new cheap junk, and gives you all the functionality you need instead of you beating your head against the limits of new cheap junk.

I’ll stack my system that’s made with older Enterprise gear up against any comparable sized system that’s made with new Enterprise gear any day. It will work the same, be as reliable, for a 10th of the cost. If one of my network devices has a power supply and dies I just pull another Ebay device off a shelf, plug it in and I’m back online in an hour. Meantime the “New Enterprise Gear” admin is still going through the TAC phone tree trying to get their 4 hour replacement warranty covered.

The ONLY difference is my setup makes the Cisco sales rep cry. The “New Enterprise Gear” admin makes him happy because he is spending his bonus on a fishing trip.

Sangoma just released FPBX 17. And Asterisk 22. Are those junk today? No. So what is going to make them junk 15 years from today.

Not a single thing.

You state kendalldever15 complained about a problem that DOES NOT EXIST with high quality gear.
That is not what I said. The question was, can you factory reset (Not reboot) a D-Series phone remotely after it is installed. The answer is still no.
There are ocassions when a D/P series phone will not accept configs pushed to it from "Save, Rebuild Config(s) and update phones.
This requires a factory reset to get the phones to pull the new configs. To do this it requires a person on-site to go to the phone and do the factory reset it.

I would call that a bug, then, and file a report with Sangoma. It’s not a bug that you can’t remotely factory reset the phone - as I mentioned a number of Enterprise phones seem to have disabled this capability nowadays - Cisco enterprise phones USED to allow it but now they don’t. The bug is that when an Enterprise phone boots it absolutely should ALWAYS overwrite it’s internal config with whatever config it fetches via TFTP/HTTP/FTP.

Phones in my experience (and I’ve tested many) seem to fall into 2 categories, SOHO and Enterprise. SOHO typically have webinterfaces that allow admin level - Polycoms are this way for example. Often those phones either cannot be fully TFTP configed or they retain portions of their config on a TFTP config. But they can always be remotely factory reset.

Enterprise on the other hand, are designed for large orgs then typically it’s intended to be entirely configed via TFTP or HTTP with no remote reset capability. In that case, it’s internal config should ALWAYS be rewritten on reboot.

I have not tested a Sangoma phone yet so I don’t know their design approach - but if it is as you say, it’s got a bug. It SOUNDS like an Enterprise approach where the phone is fully under the control of the provisioning server with no root access to the phone via ssh or webinterface that would permit a config wipe. In that case, it’s mandatory that on boot a TFTP config from provisioning server WILL wipe the phone’s prior config automatically.

One model of older Cisco phones also had this bug, the model 7941/7961 they would retain fragments of their config, so when installing those phones you ALWAYS had to factory reset them - most annoying. And if you changed a subnet mask on the network or something like that - the phone would stubbornly hold on to the older networking and would fail to register. Those were transition models from the 7940/7960 which WOULD allow remote root access to the individual phone, and the command to do a factory reset. The early firmware for the 7941/7961 also allowed individual remote wiping - then Cisco released newer firmware that disabled this as the phone was SUPPOSED to behave like a true enterprise phone with the newer firmware. It did not - and the uproar from customers was tremendous and Cisco hastily EOLd that phone model - nowadays those are rare, even though the older 40/60 models are still quite common. They never acknowledged it as a bug - but their behavior spoke volumes.

Sounds to me like Sangoma is going through a similar issue with their phones. They clearly have disabled root access to the phone over the network so you can’t just access the phones webinterface or SSH and factory reset it and while it’s rebooting, click the button on the provisioning manager - that’s an enterprise approach - but if they are going to do that - they MUST insure that the phone will ALWAYS overwrite it’s internal config.

It’s undeniably a bug in the phone. It’s not a missing feature, it’s a bug. The “save rebuild configs” is just cotton wool over what’s actually happening - what is actually happening is the config is changed when you hit Save/Rebuild on the TFTP server, a reboot command is sent to the phone, the phone boots and something in the new config is not compatible with the old config which is NOT being overwritten completely, and the phone wedges. You see it as the phone failing to pull the config, of course, because you are dealing with the GUI and isolated from the actual files.

Not sure that is going to help. The support ended for the D60/65 this year and those were the last of the D series to be EOL’d. All of the D series phones are now fully EOL and unsupported. I don’t think releasing new firmware for this is going to be on the table.