Volunteers sought for coding a PHP registration status monitor for VOIP.MS

VOIP.MS is my preferred service provider for VOIP telephone service.  I am looking for one or two PHP coders to join me in constructing a PHP status monitor for monitoring the registration status of SIP trunks provided by VOIP.MS. 

VOIP.MS has an API (information page) that permits lots of nice functions, including checking the registration status for a particular SIP trunk (what VOIP.MS calls a “subaccount”).

There is an open-source project https://www.phpservermonitor.org/ that uses PHP on a Linux platform to monitor the “up” status of web pages.  It has a web-based user interface that shows the status of web pages that are being monitored, and it has some code that runs on a Linux cron job to do the status checking in a recurring way.

I have made small steps toward understanding the VOIP.MS API, having successfully constructed a proof-of-concept web page that checks the server registation status, in real time, of a SIP trunk on one of my VOIP telephones.  Here is the HTML and PHP code that generates that web page:

<html><head><title>Status of cordless phone</title></head>
<body>This is the status of one SIP trunk on a cordless phone.<br>
$postfields = array(
‘account’ => ‘216378_rubysecondep’,

$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true );
curl_setopt($ch, CURLOPT_POST, true );
curl_setopt($ch, CURLOPT_POSTFIELDS, $postfields);
curl_setopt($ch, CURLOPT_URL, “https://voip.ms/api/v1/rest.php”);
$result = curl_exec($ch);


echo “<pre>”;
echo “</pre>”;

But I am not very experienced with PHP. It would take me a very long time to modify the PHP Server Monitor code so that it monitors VOIP.MS SIP trunk status instead of monitoring web page status.  My guess is that one or two experienced PHP coders could make quick work of this project.  Ideally, this would be one or two experienced PHP coders who are motivated to join me in the descent into this rabbit hole because they themselves also use VOIP.MS for their own telephone service.

Volunteers, anybody?

I imagine three small tables would be a starting point:

    • a first table that lists API usernames and passwords, each list item having a username ID number, and
    • a second table listing groups of email addresses to which change reports would get sent, each list item having an email address group ID number, and
    • a third table that lists “accounts” (SIP trunk identifiers), each list item having a “server POP” (the ID number of the server to which the SIP client is configured to register) and a username ID number, and an email address group ID number defining email addresses to which which status change reports for that SIP trunk would get sent.


Leave a Reply

Your email address will not be published. Required fields are marked *