T48S refuses to be deleted

[robidog]

This is probably not directly Yealink related but I post here anywhere in hopes of better exposure.

I have a single phone device that I cannot delete from the inventory. Backstory is that this device (T48S) was working fine through an on-prem SBC (Rpi running v18.1.6), until the user decided to move overseas and take the phone with them.

Naturally it didn't work outside the network. So I changed the provisioning mode of the phone from SBC to Direct SIP and instructed the user to reboot. No luck. Factory reset, no luck. I then tried to delete the phone from the extension in order to re-add it as Direct-SIP device.

It was then when I realized the phone did not disappear from the list of devices. On the user list, the number of devices assigned to the extension decreased as expected, but the device itself remained on the list. I can assign a new device with the identical MAC address to the extension, without getting an error message, which is also strange. In any case, the provisioning link (https://corp.3cx.ch:5001/provisioning/0123456789/macaddress.cfg) returns error 404, unlike for all other provisioned phones.

Also notable, the MAC address shown for the undeletable phone is using lowercase characters (i.e. 805ec00abcdef) compared to all other devices, that use uppercase characters. Am I running into a bug with the underlying Linux operating system, either on the SPC or the 3CX server?

Any other ideas on how to get rid of the entry in the phone list?

PS: In the meantime I also managed to updated the firmware on the T48S to the same version as all other phones of that type: 66.86.0.5. No change.

 

[JohnS_3CX]

Kindly start from here and share some information as per the article example:
https://www.3cx.com/community/threads/post-in-relevant-category.115838/

 

[robidog]

Thanks for following up, here's some more info that might be relevant.

3CX server version 18.0 Update 4 (Build 965)
Hosted by a service provider, not exactly sure about OS but most likely Debian on VMware
No custom templates are used
Provisioning is STUN or SBC

I believe the other questions are not as relevant for this particular problem.

 

[JohnS_3CX]

Sometimes they appear not to be, but you would be surprised

A few to the point now:

1. Is the phone factory reset? Please ensure it has been reset now and leave it in that state

2. Is the extension now empty as below? Exit and edit again to ensure the list remains empty


3. In the main "Phones" tab of 3CX, do you still see the device registered with lowercase mac or do you see it appearing in bold ?
(Tip: you should check this page 15 mins after the reset was completed, not before)

 

[robidog]

Thanks for these hints. I had the user do a factory reset again and after a few hours checked their extension. As before it only shows one phone provisioned, whis is the 3CX app. On the phones tab, I still see that user's T48S listed, with the lowercase MAC address, and it is not bold. No change even after several hours waiting.

 

[JohnS_3CX]

In that case, I'm not sure exactly what it is that is registered to your PBX. If the phone remained factory reset, it should not be showing up.

You can restart the 3CX SIP service when convenient (takes a few seconds) and see if the registration drops.

 

[robidog]

I rebooted the VM last night. No change. I will raise the problem with our hosting provider and report back if there's any update.

 

[JohnS_3CX]

Sounds like the reset phone is still registered since it appears under "Phones" with lowercase MAC.
This raises doubt whether it is actually factory reset.

What IP does it report? Is it the public IP of the remote worker than has the phone?

 

[robidog]

It reports with the user's previous public IP, before they moved the device to a new location. This makes me wonder if it's the local SBC that somehow reports the device as still present.

 

[JohnS_3CX]

Hmm doubtful, the SBC only passes on the registration messages to 3CX, but there has to be someone on the other end keeping the registration alive actively. The SBC can't "lie" to you in that sense.

I think there is a legit device or client at that IP that is actually registering with that user's credentials. That's where I would start looking if I were you.

Double-check for VPNs too: a device that VPNs into the the old site will be reporting the old public IP since that's where it exits from.