Reboot Vvx1500 through XML API

Polycom Employee

Reboot Vvx1500 through XML API

One of our customer request to reboot the Vvx 1500 remotely without using the administrative web page, they want to reboot more than one phone at one time.


Is there any key action combination XML API to do that? 





Message 1 of 3
Polycom Employee & Community Manager

Re: Reboot Vvx1500 through XML API

Hello wenya,

welcome to the Polycom Community.

Please contact myself internally as I do not feel comfortable to post such solution in the public as it could probably be used for something similar like a DDoS attack.

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services


If official support is required please check how to phone or open a case here

The title Poly Employee & Community Manager is a community setting and does not reflect my role. I am just a simple volunteer in the community like everybody else. All posts and words are my own & do not represent the views of Employer.


Notice: This community forum is not an official Poly support resource, thus responses from Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge. If you need immediate and/or official assistance please open a service ticket through your proper support channels.
Please also ensure you always check the VoIP , Video Endpoint , Skype for Business , PSTN or RPM FAQ's
Message 2 of 3
Valued Contributor

Re: Reboot Vvx1500 through XML API

I'm wondering why it needs to be via the XML API?  Is that because you think that might be the only way to automate such a thing?


There is a publicly-documented way of accomplishing what you want through a configuration option combined with a specially-crafted SIP NOTIFY packet that includes "Event: check-sync" in the headers.  Normally a check-sync NOTIFY will merely cause the phone to check and see if its configuration file(s) on the provisioning server has changed.  If it hasn't changed, the phone does nothing.  If it has changed, the phone will apply the new configuration and then reboot if any of the parameters that changed require a reboot to be applied.  This use of a check-sync NOTIFY is actually pretty common with most hardware SIP endpoints.


However, if you include...


voIpProt.SIP.specialEvent.checkSync.alwaysReboot="1" your configuration, the phone will reboot whenever it receives a check-sync NOTIFY, regardless of whether the configuration file has changed on the provisioning server or not.  As long as you include this option in your provisioning for all of your phones, you should be able to devise an automated/scriptable means of sending check-sync NOTIFYs en-masse to all of the endpoints of yours that you want to reboot simultaneously.


As Steffen suggested, implementing such a solution could be compromising security-wise and lead to denial-of-service exploitation of your Polycom endpoints if sufficient attempts at protecting yourself from this are not made.  By default, Polycom UC software does not try to validate check-sync NOTIFYs in any way, which means that any Polycom endpoints you have on public IP addresses not protected by a firewall can be rebooted by anybody.  You could address this problem by ensuring that all phones are behind a firewall or NAT, and then have your mass-reboot tool communicate with the phones over a VPN.  If that is not an option, another thing you can do is add the following parameters to your phone configuration:




With this in place, the phones will challenge and validate each incoming check-sync NOTIFY request using digest authentication.  If you use this, though, your tool or script will not be able to just blindly send check-sync NOTIFYs to phones...the phones will challenge the initial request and your script must be ready to answer their challenge.  You will also need to know the credentials (SIP username and password) that each phone is using to register to your SIP registrar in order to be able to properly compute the response.


Another option would be to set the method to "source" instead of "digest", which will cause the phones to validate the request by source IP address.  If you use this method, though, you must run your script from the same server that the phones are registering to.


Hope this helps,


-- Nathan

Message 3 of 3