I'd like to throw this out and just see if anyone has any thoughts on this. In the past, I have set things up so that whenever I get an incoming call, I get a popup on my computer screen. The popup looks something like this (imagine it in a notification balloon on your computer):
John Smith
234-555-2368
for 789-555-2222
11:57 AM on Friday, February 18, 2011
The first line is the Caller ID name, the second is the Caller ID number. The third is an indication of the line called - here I show an 10 digit number but it could be any kind of text string that identifies the line. The fourth is self-explanatory - a human-friendly timestamp.
There are two different ways I could generate this notification. If the call was coming from Asterisk, I could use
a Perl script running on the server, whereas if the call was coming in on a Linksys/Sipura adapter, I could use
a script to poll the adapter's web page once per second, detect when the state of a line changed to "ringing", and then grab the data I needed from that page to generate a notification.
Neither of those approaches are particularly elegant and besides, if you're not getting calls from an Asterisk server you control, the first method is out. And the OBi devices don't presently have a single screen that displays all the necessary information, so the second method won't work either. So I have a few possible ideas for ways that the OBi designers could make notifications possible, just to get people thinking about this:
1) The poll page. This would be a specially constructed page in the adapter's web portal, for example
http://obi-ip-address/notifications. It would contain all the necessary information to construct a notification:
A section for each "provider" and port on the device, headed sp1, sp2, pp1, li, ph, etc.
Under each section, the current status of the line or device, e.g. ringing, onhook, etc., and the current (if ringing or connected) or previous (if idle) Caller ID Name and Number (on separate lines, or if presented in XML format, under separate tags).
The idea is you have a very simplistic, very minimal page that's designed to be accessed once per second by some other program which then grabs the necessary information on any line or service (that you are interested in) that has just gone into "ringing" state (since the last time you polled it), and formats it into a notification. The page itself should be extremely minimal - no graphics, no extraneous text, just the bare information necessary, or else in XML format. If you're polling something once per second if would be better if you didn't have to grab several thousand characters of text just to extract the couple of hundred or so bytes of information you might be interested in.
Obviously the poll page would not generate the notifications - some external program would do that. This would just give the external program the information it needs. It's very simple, although not very efficient.
EDIT: Since originally posting this, I have discovered that all the necessary information is available on the device's Status - Call Status page, however it's not exactly in the best format for this purpose and as far as I can see, it's not available at all until you authenticate (login) with the device, which means you couldn't use something like a simple wget (on a unix/linux type system) to fetch the information. Even trying to view the page's source doesn't yield the required information because apparently it's using some form of Javascript. And if you attempt to refresh the page, it throws you back to the main "System Status" page.
2) Poll page + broadcast - same idea as above, except that in addition to the poll page, a network "broadcast" message would be sent to the entire LAN whenever something goes into "ringing" status. Interested clients would look for this message, then come to the device to grab the details (so a properly constructed client would only poll the adapter when a broadcast message is received, not once per second).
3) Full network Growl support. Growl is a notification system that first appeared on the Mac, but a windows version (Growl for Windows) has gained considerable acceptance. In addition,
Linux users can use a program called Mumbles to receive and display network Growl notifications. So the idea is that you'd have a new page on the OBi, possibly under User Settings, where you could set the addresses of computer(s) that you wanted to send Growl notifications to. For each computer you'd need to be able to specify an IP address, Growl network password, and then select which lines or devices you wanted to receive notifications on (probably using checkboxes). You might also want to give people a way to change the formatting of their actual notification message, using substitution variables for the Caller Name, Caller Number, and standard Unix-style time-date variables.
Number 3 is more work to implement (although there are Growl modules available for several languages that do all the hard work for you) but it supports a notification system that's pretty standard in the Mac and Windows worlds (well, as standard as anything not explicitly blessed by Microsoft).
4) The http request. If you don't want to implement Growl support, another approach is a simple HTTP request. In this case you'd simply need to have a way that the user could execute specific HTTP requests whenever a selected service or device went into the ringing state (so again you'd need checkboxes to specify which services to monitor). In Asterisk, for example, I can do something like this:
TrySystem(wget -b -O /dev/null -o /dev/null "http://192.168.0.123:8080/xbmcCmds/xbmcHttp?command=ExecBuiltIn¶meter=XBMC.Notification(Call%20from%20%22${URIENCODE(${CALLERID(name)})}%22%2C${CALLERID(number)}%20calling%20251%2C15000%2C%2Fhome%2Fuser%2Fphone.png)")Where 192.168.0.123 is the destination machine to receive a notification, ${CALLERID(name)} and ${CALLERID(number)} contain the substitution variables we need, and home%2Fuser%2Fphone.png points to an icon on the destination machine. This is just an example to show how complicated some of these types of calls can get — the one shown here would throw up a call notification on a PC running either the XBMC or Boxee home theater software, assuming the software was properly configured to receive notifications. The problem with this approach is that while it works well for a machine running a web server (even a minimal one), it's not so great for notifications to normal user machines that don't usually have a web server in operation.
5) Jabber IM. Another method is to simply use the Jabber client that may already be present to enable Google Voice, and send notification messages via that channel (specifically, via Google Talk).
In Asterisk I have used this to send a Jabber notification:
JABBERSend(googletalkuser,localgvaccount@gmail.com,Call from ${CALLERID(name)} at ${CALLERID(number)} for extension 234 received: ${STRFTIME(${EPOCH},,%l:%M:%S %p %Z on %A %B %e)})
googletalkuser is the screen name of the Google Talk user you want to send the notification to. localgvaccount was in this case the Gmail address associated with the particular Google Voice account for which I was sending the notification. 234 is the extension I was sending the calls to - again, this is just an identifier string so you have some idea where the calls came from or where they are going. The drawbacks to this is that the OBi device would have to be registered with Google (which now may only be the case if you are actually using a Google Voice number on SP1 or SP2) and the user receiving the notifications would have to be running a Google Talk or other IM client that could receive the messages. The advantage is that you can send notifications to a user anywhere, not just on the local network.
6) Something I haven't considered.
Personally, as a user I would prefer #3, because Growl is pretty easy to set up and can be useful for a lot more than just call notifications (on the Mac in particular, a large number of programs use it, and on Windows it's becoming fairly well supported also). But failing that, #2 or #1 would probably provide the most flexibility because essentially it gives the necessary information in the simplest form and lets you write an external client to massage it into whatever form you need or want, plus it would probably be easiest for the Obihai guys to implement.
I'm just wondering if anyone else thinks this would be worthwhile and if they might favor any particular approach — or alternately, if something like this already exists and I'm just not aware of it.
