I'm writing an interface in PHP for NCIDD, and having a lot of difficulty with the API. Having the connection always open like in telnet presents it's own issues in creating a web application, and it strikes me that I don't really need all the bells and whistles of NCIDD, just a database of blacklist, whitelist, and alias numbers and the ability to end calls.
I've been bothering John Chmielewski so much about it, and am thinking it might make more sense to find something else that will interact in a more restful way with the web server.
Does anyone out there know of alternatives for NCIDD?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm writing an interface in PHP for NCIDD, and having a lot of difficulty
with the API. Having the connection always open like in telnet presents
it's own issues in creating a web application, and it strikes me that I
don't really need all the bells and whistles of NCIDD, just a database of
blacklist, whitelist, and alias numbers and the ability to end calls.
I've been bothering John Chmielewski so much about it, and am thinking it
might make more sense to find something else that will interact in a more
restful way with the web server.
Does anyone out there know of alternatives for NCIDD?
Let me start by stating I do not use/write PHP, so I can't help with anything relating to PHP.
However, having written multiple NCID clients for different hardware/software combinations (arduino, ESP8266, python, and node.js), being fully comfortable with the data flow of NCID packets was the key to having a stable client. TCP is not 100% reliable, so you have to account for and recover from transient issues on your network. Other than that, a NCID client is just a data manipulator and presenter. John has developed some really great test scripts that have brought some of my hardware/software to its knees during development. However, once a client was able to survive the test scripts, it was in pretty decent shape for being stable.
I have had relatively minor issues maintaining an open TCP socket for months on end without errors. I have setup NCID TCP connections over localhost, wired ethernet and wifi & each has their own nuances. The challenge occurs when a TCP socket is abruptly closed or gets in a half-open condition between NCIDD and a client. To gracefully and automatically recover, a client has to (1) notice the failure (the api has a REQ/ACK protocol that is very robust at finding the half-open condition) and (2) re-open the TCP socket after doing the appropriate clean-up. Once the TCP socket is re-opened, your NCID client is back to square 1 on processing ncidd packets and managing data flow as ncidd is going to dump the entire call log through the newly opened socket.
If you want a restful interface, I see no issues with implementing a restful NCID client that opens a TCP socket to NCIDD, processes all incoming NCID packets and then presents a restful interface to the world. I can see how it would be nice to implement the interface through the typical CRUD operations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My first attempts (being completely new to writing telnet / browser connections) kept the browser spinning forever, and this isn't really acceptable or wanted behaviour for a browser. One gets the sense that the page is never done loading (which it isn't, since it's waiting for the server to close the connection, as a webserver would do when it's done serving text, I guess).
So I've been content with just doing a tab-refresh when the phone rings in the house, to see if I should run and find a phone, or to do a quick Google search for the incoming number. This works fine for my purposes. I load the contents of the log, parse it into something presentable (or searchable) and look at query-string commands for what to do with any data or form submissions.
Having a ncidd server on the main machine that behaved a bit more like a webserver would probably help a lot. I've been playing around tonight with using minicom to try to send commands to the modem, but so far I'm not finding anything simple.
Anyway, I appreciation very much that you took time to answer!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jason,
Thanks for the better description about what you are doing and wanting to do.
To eliminate a browser refresh or leaving a page where it never finishes loading, you need to architect your client code differently.
One way is through the use of AJAX. The gist of this method is to load the html of the page. Once the page is loaded, the webpage will issue a XMLHttpRequest(). The PHP server gets the XHR and waits for a call/message to arrive. When a call arrives, the PHP code formats and sends a XHR response. When the XHR response is received by the webpage, code on your webpage can parse the infomation and update the webpage without a refresh. While the name call includes a reference to XML, you can use XML, JSON or just plain text in your response since you control the formation of the response in your PHP and can use javascript in your webpage to format and update a table/div/etc. There are some issues with what is known as "long polling" that may require error recovery code, but it will be almost real-time updates of your webpage when a call or message arrives with refreshing. If you want to implement whitelisting/blacklisting/etc, you can do this through a XHR as well.
A better way is through the use of websockets IMHO. Rachet is PHP websockets library a quick search turned up that should handle what you need. Similar to the AJAX method above, you have your webpage load and open a websocket back to your PHP server. The websocket is somewhat similar to a TCP socket connection and it allows bi-directional, real-time communication with between your webpage and your PHP server. Similar to the AJAX example, when a message arrives on a websocket, javascript on your webpage can parse it and update a table/div/etc. If you want to implement whitelist/blacklisting/etc, a message from the webpage can be sent from the webpage to the PHP server through the same websocket this is delivering NCID info.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Jason Silver,
Your postings prompted me to clean up and (lightly) comment some node.js code I have been using for the past several months that (mostly) demonstrates my ramblings about the use of websockets for a web client for NCID. The source is available on my GitHub: NCIDwebclient.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm writing an interface in PHP for NCIDD, and having a lot of difficulty with the API. Having the connection always open like in telnet presents it's own issues in creating a web application, and it strikes me that I don't really need all the bells and whistles of NCIDD, just a database of blacklist, whitelist, and alias numbers and the ability to end calls.
I've been bothering John Chmielewski so much about it, and am thinking it might make more sense to find something else that will interact in a more restful way with the web server.
Does anyone out there know of alternatives for NCIDD?
Start by going to sourceforge and search for 'callerid' , 'caller id' and
similar.
On Mon, Jul 18, 2016 at 7:41 PM, Jason Silver jasonsilver@users.sf.net
wrote:
Let me start by stating I do not use/write PHP, so I can't help with anything relating to PHP.
However, having written multiple NCID clients for different hardware/software combinations (arduino, ESP8266, python, and node.js), being fully comfortable with the data flow of NCID packets was the key to having a stable client. TCP is not 100% reliable, so you have to account for and recover from transient issues on your network. Other than that, a NCID client is just a data manipulator and presenter. John has developed some really great test scripts that have brought some of my hardware/software to its knees during development. However, once a client was able to survive the test scripts, it was in pretty decent shape for being stable.
I have had relatively minor issues maintaining an open TCP socket for months on end without errors. I have setup NCID TCP connections over localhost, wired ethernet and wifi & each has their own nuances. The challenge occurs when a TCP socket is abruptly closed or gets in a half-open condition between NCIDD and a client. To gracefully and automatically recover, a client has to (1) notice the failure (the api has a REQ/ACK protocol that is very robust at finding the half-open condition) and (2) re-open the TCP socket after doing the appropriate clean-up. Once the TCP socket is re-opened, your NCID client is back to square 1 on processing ncidd packets and managing data flow as ncidd is going to dump the entire call log through the newly opened socket.
If you want a restful interface, I see no issues with implementing a restful NCID client that opens a TCP socket to NCIDD, processes all incoming NCID packets and then presents a restful interface to the world. I can see how it would be nice to implement the interface through the typical CRUD operations.
Thanks @BTodCox.
My first attempts (being completely new to writing telnet / browser connections) kept the browser spinning forever, and this isn't really acceptable or wanted behaviour for a browser. One gets the sense that the page is never done loading (which it isn't, since it's waiting for the server to close the connection, as a webserver would do when it's done serving text, I guess).
So I've been content with just doing a tab-refresh when the phone rings in the house, to see if I should run and find a phone, or to do a quick Google search for the incoming number. This works fine for my purposes. I load the contents of the log, parse it into something presentable (or searchable) and look at query-string commands for what to do with any data or form submissions.
Having a ncidd server on the main machine that behaved a bit more like a webserver would probably help a lot. I've been playing around tonight with using minicom to try to send commands to the modem, but so far I'm not finding anything simple.
Anyway, I appreciation very much that you took time to answer!
Jason,
Thanks for the better description about what you are doing and wanting to do.
To eliminate a browser refresh or leaving a page where it never finishes loading, you need to architect your client code differently.
One way is through the use of AJAX. The gist of this method is to load the html of the page. Once the page is loaded, the webpage will issue a XMLHttpRequest(). The PHP server gets the XHR and waits for a call/message to arrive. When a call arrives, the PHP code formats and sends a XHR response. When the XHR response is received by the webpage, code on your webpage can parse the infomation and update the webpage without a refresh. While the name call includes a reference to XML, you can use XML, JSON or just plain text in your response since you control the formation of the response in your PHP and can use javascript in your webpage to format and update a table/div/etc. There are some issues with what is known as "long polling" that may require error recovery code, but it will be almost real-time updates of your webpage when a call or message arrives with refreshing. If you want to implement whitelisting/blacklisting/etc, you can do this through a XHR as well.
A better way is through the use of websockets IMHO. Rachet is PHP websockets library a quick search turned up that should handle what you need. Similar to the AJAX method above, you have your webpage load and open a websocket back to your PHP server. The websocket is somewhat similar to a TCP socket connection and it allows bi-directional, real-time communication with between your webpage and your PHP server. Similar to the AJAX example, when a message arrives on a websocket, javascript on your webpage can parse it and update a table/div/etc. If you want to implement whitelist/blacklisting/etc, a message from the webpage can be sent from the webpage to the PHP server through the same websocket this is delivering NCID info.
@Jason Silver,
Your postings prompted me to clean up and (lightly) comment some node.js code I have been using for the past several months that (mostly) demonstrates my ramblings about the use of websockets for a web client for NCID. The source is available on my GitHub: NCIDwebclient.