So on v16 I had a custom add-ins feed page. Displaying all registered SIP extensions. With helpful details, such as phone make, IP address, firmware revision, etc. For support it made it simpler to remote into a phone’s web admin based on a user reporting trouble, seeing about any phones with older firmware that could be updated, etc. Screen shot of that below.
Keep in mind we do not use EPM. Hence how this custom page is helpful. Anyway, after updating to v17 the custom page only displays all extensions from top to bottom, as unregistered. Which is bogus.
Can anyone suggest the best approach for updating my PHP to account for any changes in v17? Either in PHP itself or how it can communicate with the system, or both perhaps. I tried my hand at some LLM-fu but it didn’t work out.
Hi Greg, I have been working on this for the last few days. What a coincidence! It will be getting a name change and wasn’t quite ready to be announced. Hopefully it will help you find the answer though. It’s all there for v17, including all the things your table is currently showing.
Sweet! This was my last loose end from the v16 → v17 migration. Had a fair amount of deprecated Macro lines in my extensions_override*.conf files and whatnot for custom mods. After those got ironed out this was the final thing I needed to tweak. I will keep an eye out on this GitHub project.
1.1.1 is tested and ready to use now. Current thinking is that “endpoint” clashes too much with EPM. It will be renamed but good to go as is. There is also no persistent/repeating alerting, which will be coming in 1.2.0. Please let me know if you think it needs anything else, I had no idea you’d already built something. Good to see what I have included, e.g. firmware, is indeed useful.
@kierknoby is there a way to back port this to v16? I have a few v16 in a highly restricted, regulated environment where upgrading to v17 requires multiple levels of approvals and I’m not ready for that dance.
Possibly, yes. But not in 1.2.0, which should be available this week for v17 and renamed Registration Watch. Once I have got that done, I will look into it. It’s a question of the ongoing maintenance and how much there might be.
While this dev branch exists, you can watch my progress here:
If you just want a quick page to display registered endpoints with most of their details, feel free to borrow my example that I linked. This worked fine on v16. While it wasn’t a formal FreePBX module, it allowed the logged-on dashboard user to pull up extensionstatus.php to display this. No interactive functionality, but just a quick listing of what appears in the screen shot. I will say after installing Kieran’s module this week on v17 it is fantastic. Much, much appreciated!
Is there a reason a monitor for chan_pjsip is using chan_sip logic of 1 endpoint = 1 contact? I’m testing this, looks great but I have multiple contacts on a single endpoint and this only cares about one, looks like the oldest registered one but it only shows one. When I take the other contacts offline it doesn’t show they went offline or if they are online.
So at this point it’s not really monitoring contacts it’s just monitoring to see if an endpoint has at least one contact registered. If you have 4 contacts that should always be registered to an endpoint then as long as only one is registered this thinks everything is A-OK. It didn’t even pick up when new contacts registered.
If this is to watch/monitor chan_pjsip registrations then it needs to have proper 1:many logic as right now it’s 1:1. A single endpoint with 5 contacts will only have one contact monitored and the other 4 registrations unwatched. Or one the flip side, it’s focused on one contact and when that contact goes offline it ignores the fact the other 4 contacts are registered.
Extension XXX78 = one watched extension
Zoiper registered to XXX78 on PC1 = contact 1
MicroSIP registered to XXX78 on PC1 = contact 2
2nd MicroSIP registered to XXX78 on PC2 = contact 3
Even on the same PC and IP, Asterisk sees Zoiper and MicroSIP as separate PJSIP contacts. Registration Watch groups them under one extension, while avoiding duplicate rows and re-registration flapping.
Anyway, after updating to v17 the custom page only displays all extensions from top to bottom, as unregistered. Which is bogus.
