News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Support for notification popups on computers

Started by MichiganTelephone, February 18, 2011, 10:49:02 AM

Previous topic - Next topic

MichiganTelephone

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&parameter=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.


Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

gerry

Michigan,
The Google Mail incoming notification is not bad. Very similar to your version of the popup, and you can answer, screen, or ignore calls, as well as (in theory) switching to any of your other GV phones by hitting "*". The downside is that you need to have Gmail running, although perhaps OBi could provide a PC equivalent?
Gerry

QBZappy

I understand that the Obiapp is going to behave more like a softphone. Every softphone I have ever used pops up the CID info of the incoming call. That would be an obvious client to use for the CID pop ups. Some other more flexible method would allow someone to ingrate these pop ups into contact management software or MS Outlook. Something similar as Outcall for Asterisk. Since a pop up implies that the computer is running, perhaps the Obiapp can offer all the info necessary in a format that can be accessed by 3rd party applications.

Perhaps another approach to consider. There are pros and cons of every technique that might be considered.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

MichiganTelephone

Appreciate the discussion, this is good.

Unfortunately, actually leaving Gmail open would not be a workable a solution because that can kill incoming Google Voice calls.  Also, it's not really a popup, and also I'm looking for a solution that would work with all varieties of incoming calls no matter how they arrive — I don't want it to be limited to Google Voice calls.

As for OBiAPP, I don't know if there's any way it would serve this purpose, but right now the biggest problem I personally have with that is that I'm not running a Windows-based system, and the OBiAPP software will not run under Mac OS X (I even tried running it under Codeweavers Crossover, which you can think of as a commercial version of WINE, but it will run more Windows-based software than Wine — but in this case the installer failed so I could never get it to work).  That's why I tried to make my suggestions fairly non-platform-specific — something that only runs under Windows isn't going to work for me.

However, I remember reading somewhere that the OBi devices allow SIP-based subscriptions to pull certain information.  But i have no idea if that would work to pull the required information for the popups, and also I have really no idea how to use those at all (not even in Asterisk/FreePBX).  And I doubt there's any SIP-based notification scripts or software out there (though I'd be happy to be proven wrong).
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

QBZappy

If you are thinking of taking the SIP route, what you are implying is approach using a network protocol analyzer (i.e. wireshark) set up with a filter set to identify SIP. Then you can have the info sent into a text file and manipulate the data into any shape you need it. I have come across call recording software based on this concept. Then you can look for "200 OK" messages in the text file.

What do you think?
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

MichiganTelephone

QBZappy, I think you'd have to know a lot more about networking than I do to make that work!

I don't know that much about wireshark, but in order to use that don't you have to have the traffic from the device you want to monitor flow through the computer that is running wireshark?

My thought there was that the SIP subscription was something that MAYBE could be accessed by a piece of software not involved in the actual call.  But either way, that would be far down the list of my preferred ways to generate notifications, unless perhaps I had a much better understanding of how it works.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

MichiganTelephone

For anyone following this thread I added a paragraph to my original post.  I got to looking around the device's web portal tonight and noticed something I hadn't previously:

QuoteEDIT:  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.

Try accessing that page during an incoming call (before it's answered) and you'll see what I mean - all the information is there, it's just not in a format that could be easily "scraped" by an external script or a notification program.  You'd first have to authenticate with the device, then figure out how to get past the Javascript to get the page data you want, and then parse that data in order to extract the elements you need (keeping in mind that there could be more than one simultaneous connection).  :o

Not exactly a programming challenge that I'd personally be up for!

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

QBZappy

Hi,
You might be interested in the following short video explaining wireshark. Narrator dose not talk about SIP filters, however in a voip application these filters can be setup. It takes some of the mystery out of wireshark. It is a useful tool for troubleshooting voip setups. I believe you can also do what you indent to do using this approach. There might be some learning involved.

I will try to locate the call recording software which monitors sip traffic using this approach. I might get some insight in using this approach.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

QBZappy

Looking at the call history. There is a lot of info there. Might be good to see if that info is available during the call or after the call is finished. You might be able to read that info with your script approach.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

QBZappy

Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

MichiganTelephone

QBZappy - I watched your video but it did not explain how it would show me traffic that's not flowing through the computer that is running Wireshark.  Since the OBi devices communicate directly with the Internet, their traffic would not be available to Wireshark.  The only thing Wireshark might be able to capture is traffic between the user's computer (specifically the Web browser) and the OBi device's web interface.  And that's assuming you know what you're doing with that software!
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

QBZappy

Hi,
I've been thinking of another possible method, but first let me correct you about wireshark (or any other flavor of network packet sniffers), they don't read web pages, they intercept packets that run over the router. Obi is facing the internet however all the packets must go through the router.

The other possible method I was thinking would be to access and parse the data directly from the Obi unit. If the devs would show us how to root the device we could read and parse the data directly. I tried one method to see if I could analyze the file structure without success. I don't really want to risk bricking my Obi. It would be simpler to get the devs to show us the best way to achieve this using this more direct method.

Is you idea to get pop-ups from the Obi only, or from Asterisk in general?
You don't think the call history offers real time info which can be used for this design?
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

MichiganTelephone

Quote from: QBZappy on February 19, 2011, 01:04:27 PM
Hi,
I've been thinking of another possible method, but first let me correct you about wireshark (or any other flavor of network packet sniffers), they don't read web pages, they intercept packets that run over the router. Obi is facing the internet however all the packets must go through the router.

But that would only work if you were running Wireshark on the router.  I'm going to go out on a limb here and say that I think maybe it's you that doesn't fully understand Wireshark's capabilities (or lack thereof).  It would be a serious security risk if ANY user on a local network could run Wireshark and look at any and all traffic on the network.  I just don't believe you can run Wireshark on a computer and look at packets that are not flowing through that computer.  And you can tell me I'm wrong until your fingers are bleeding from typing it, but what you are saying doesn't make sense and therefore I don't believe it.

Quote from: QBZappy on February 19, 2011, 01:04:27 PMThe other possible method I was thinking would be to access and parse the data directly from the Obi unit. If the devs would show us how to root the device we could read and parse the data directly. I tried one method to see if I could analyze the file structure without success. I don't really want to risk bricking my Obi. It would be simpler to get the devs to show us the best way to achieve this using this more direct method.

You know what would be simpler yet?  If they actually give us a way to get the notifications without having to do a bunch of tricky stuff that might break something.  I don't want to root the device!

Quote from: QBZappy on February 19, 2011, 01:04:27 PMIs you idea to get pop-ups from the Obi only, or from Asterisk in general?

Right now I'm looking for a way to get them from the OBi device.  Most OBi users won't be running Asterisk, you know!

Quote from: QBZappy on February 19, 2011, 01:04:27 PMYou don't think the call history offers real time info which can be used for this design?

The Call History is no easier to access than the Call Status page, and the latter would provide much better and more useful information for this purpose.  However, as I explained in an earlier message, it's really beyond my abilities to pull the data off of that, because you first need to authenticate and then somehow run the JavaScript that appears to actually fetch the data.  And I know absolutely zilch about JavaScript (other than that it's a real nuisance at times).

QBZappy, may I just say, it seems to me you're kind of hijacking this thread with a lot of speculation and suggestions that aren't going to help most users, and definitely aren't helping me.  Wireshark is particularly irrelevant to this topic, and I wish you'd never brought it up.  I understand you're trying to be helpful, but at this point I'd really like to hear what others may have to say on the subject.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

jimates

someone mentioned an upcoming softphone, why can't it be that simple. A small program that runs in the system tray and connects to the corresponding Obi. The Obi sends the info to the app with that information.

Perhaps it could be configured with what info we want to show in the ballon. Maybe we just want name and number, but the app could actually save some or all the info that the call staus log has.

NerdUno

#14
Try these links using the correct IP address of your OBi and then scrape away:

http://192.168.0.109/DI_S_.xml

http://192.168.0.109/callstatus.htm

http://192.168.0.109/callhistory.htm

http://192.168.0.109/PI_FXS_1_Stats.xml

The wget syntax would look like this:

wget --http-user=admin --http-password=yourpassword -qO- http://192.168.0.109/PI_FXS_1_Stats.xml

jimates

It would also be great if we could link the PC softphone as an extension of the Obi. Instead of forwarding calls to it, it would be great if it would just ring along with the Obi.

That might also get the caller id to the pc.

QBZappy

#16
If anyone is interested here is an open source network caller ID (NCID) which can work with the Obi device. It is based on packet sniffing. Works with Linux, Mac, and Windows (using andlinux). Apparently it is safe to use a packet sniffing strategy on your own network.

http://ncid.sourceforge.net/

http://ncid.sourceforge.net/ncid/ncid.html#Screenshots

NCID is Caller ID (CID) distributed over a network to a variety of devices and computers.

NCID supports messages. Clients can send a one line message to all connected clients.

NCID supports outgoing calls if the information is provided by a SIP gateway.

NCID consists of the ncidd server, the ncid universal client, and various client output modules. It also includes NCID, SIP, and YAC gateways.


Another interesting product based on packet sniffing if you want to record incoming and outgoing calss. This one is commercial. Also captures CID. Not a popup app however.

http://www.miarec.com/products/miarec-solo/how-it-works
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

sundansx

Anyone using ncid in a home network with the obi110?  I presume you would setup routing rules on your router to forward or Tee packets coming to the obi110 from the internet.  I am not sure how to do that on my Tomato firmware based router.  I didnt find any specific instructions on the internet, just conceptual one.  Thanks to all in this thread for the pointers thus far.

QBZappy

#18
sundansx,

Hi,

I have not had a need to set it up, however in this "how to" there is no mention of setting up routing rules. Author says "Run an ethernet cable from it (Hub) to the system running ncidsip and you're good to go!"

http://www.davidlaporte.org/tutorials/sipcallerid.html

I have used andlinux product. It is amazing to see linux running off a windows computer. It is just as intuitive as Windows, as it is GUI based.

I would be interested in knowing your results. Let us know.

PS
I read over the "How do I configure NCID to use a SIP gateway". I believe the ports you need to setup in the software are the:
SIP----> UDP port 5060 (Default setting) and perhaps the
RTP----> UDP port numbers mentioned in your config under Service Providers->ITSP Profile A/B->RTP->LocalPortMin & LocalPortMax

The rest of the discussion regarding using the "T" seems to be for testing for SIP packets using their sip2ncid application. This shouldn't be necessary since we know what ports the Obi is using by looking at the web config page.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

MichiganTelephone

Quote from: QBZappy on March 08, 2011, 08:45:44 PM
sundansx,

Hi,

I have not had a need to set it up, however in this "how to" there is no mention of setting up routing rules. Author says "Run an ethernet cable from it (Hub) to the system running ncidsip and you're good to go!"

http://www.davidlaporte.org/tutorials/sipcallerid.html

QBZappy, with all due respect, this is NOT the solution most of us are looking for.  And the reason is in the paragraph above the one you quoted, which begins:

QuoteOption 2 is even easier, although it will involve an additional piece of equipment. You will need to purchase an ethernet hub and insert it between your cable/DSL modem and your router. If you have an all-in-one model, or are worried about the security implications of connecting a PC outside of your router/firewall, you can also just plug the hub into your router and your VoIP device and sip2ncid box into it. ...
(emphasis added)

For me at least, it's not worth it to have yet another device that costs money, takes up space, consumes power, and requires a fair degree of computer knowledge to set up.  Do you think the average user is going to do this?  Not in a million years!  This is a serious nerd type project.  As far as it goes, many home users won't have a Linux box, won't want to try and install andlinux, and won't want to get involved with packet sniffing (even if they know what that is).  The whole point of these devices is to make VoIP relatively easy to set up and use, which for example is why Obihai gives us tools like the OBiTALK portal and the wizards - if you want to set up the device with one of their "known" providers, you don't even have to touch the configuration of the device.  But what you are suggesting goes way beyond that in terms of difficulty.

I personally wish that Obihai would consider including network Growl support.  In addition to the original Growl notification system for Mac OS X, there's also Growl for Windows which is easy to install and becoming more popular (and in some ways more capable than the original Mac version).  Ans as I said in my original post, even Linux users aren't left out of the party, since they can use Mumbles to receive and display network Growl notifications.

To give you an idea of how simple it can be to send Growl notifications, this is how it's done on an Asterisk system in Perl.  The bulk of this code is spent parsing the values passed by Asterisk (caller ID number, caller ID name, called extension number, and target IP address or MAC address of the computer to receive the notification) and then formatting the output.  Only the last few lines are actually used to send the notification:

#!/usr/bin/perl
use strict;
use warnings;
use Net::Growl;
use Asterisk::AGI;
my $agi = new Asterisk::AGI;
my %input = $agi->ReadParse();
my $num = $input{'callerid'};
my $name = $input{'calleridname'};
my $ext = $input{'extension'};
my $ip = $ARGV[0];

if ( $ip =~ /^([0-9a-f]{2}(:|$)){6}$/i ) {
        $ip = $agi->database_get('growlsend',uc($ip));
}

unless ( $ip =~ /^(\d+)\.(\d+)\.(\d+)\.(\d+)$/ ) {
    exit;
}

if ( $ARGV[2] ne "" ) {
        $ext = $ARGV[2];
}

my @months = (
    "January", "February", "March",     "April",   "May",      "June",
    "July",    "August",   "September", "October", "November", "December"
);
my @weekdays = (
    "Sunday",   "Monday", "Tuesday", "Wednesday",
    "Thursday", "Friday", "Saturday"
);
my (
   $sec,  $min,  $hour, $mday, $mon,
   $year, $wday, $yday, $isdst
) = localtime(time);
my $ampm = "AM";
if ( $hour > 12 ) {
    $ampm = "PM";
    $hour = ( $hour - 12 );
}
elsif ( $hour eq 12 ) { $ampm = "PM"; }
elsif ( $hour eq 0 )  { $hour = "12"; }
if ( $min < 10 ) { $min = "0" . $min; }
$year += 1900;
my $fulldate =
"$hour:$min $ampm on $weekdays[$wday], $months[$mon] $mday, $year";

# Next two lines normalize NANP numbers, probably not wanted outside of U.S.A./Canada/other NANP places
$num =~ s/^([2-9])(\d{2})([2-9])(\d{2})(\d{4})$/$1$2-$3$4-$5/;
$num =~ s/^(1)([2-9])(\d{2})([2-9])(\d{2})(\d{4})$/$1-$2$3-$4$5-$6/;

register(host => "$ip",   
    application=>"Incoming Call", 
    password=>"$ARGV[1]", );
notify(host => "$ip",
    application=>"Incoming Call",
    title=>"$name",
    description=>"$num\nfor $ext\n$fulldate",
    priority=>1,
    sticky=>'True',
    password=>"$ARGV[1]",
    );


In addition to the above you do have to use a Perl module for network Growl support (Net::Growl) but I believe there are similar modules for several other languages (you have to be careful, though, to get one that has network support - many Growl modules are intended only for sending notifications to the local machine). I do not know what language the Obihai developers code in, but unless it's a very low level language there's a possibility that there's an existing network Growl module.

According to the Net::Growl source code, it was
# Derived from Rui Carmo's (http://the.taoofmac.com)
# netgrowl.php (http://the.taoofmac.com/space/Projects/netgrowl.php)

So apparently there's also a PHP module, and the author's comment on that code is very interesting:
QuoteThis is the PHP version of netgrowl, which took me all of half an hour to do. With it, you can have your PHP-based web servers notify you instantly of any strange occurrences.
(emphasis added)

My point here is that although I'm not a programmer and therefore not in a position to really judge the difficulty of adding network Growl notifications, I honestly don't think that it would either be very difficult, nor require a huge amount of code.  Whether the Obihai developers would be willing to include it is a whole other matter, but given a preference I'd much rather see something like that than a solution that requires external hardware!

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.