[OPEN-ILS-DEV] Christmas vacation and EG add-ons
Bill Ott
bott at grpl.org
Sat Dec 22 13:09:03 EST 2007
> We may've talked also about re-vamping the whole notification system
> to allow easy "plugin" development as new communication media comes
> along (although, this may've been just me dreaming again... I don't
> remember). I mean, current notification media might include E-Mail
> (already in place), Voice Phone, VoIP, IM, SMS, pager, etc. Even in
> just the IM category, we have several protocols (OSCAR [AOL], MSN,
> Yahoo, Jabber, SILC, IRC...).
>
There are some notes on the wiki (scratchpad: notification) but it's
just some brain storming if I recall correctly.
SMS and pager providers often have email interfaces for these services,
so I would think that could be a short trip. IM presents some similar
issues as telephony in regard to verification of message delivery.
As the ultimate quick-n-dirty, I could have something working today
based on a Windows application that will dial based on data from an .xls
sheet. A quick trip to reporter will give me that, but it doesn't help
on the customer service end when you go looking to see if a notice was
delivered.
Telephony offers some issues not found with email. For instance, an
early bird checking in items and triggering an email hold at 7:00AM is a
good thing. A phone call at that time probably isn't. So, you're
dealing with batch data. Then there's the call result. RFPs spell out
pretty well how an SMTP server deals with delivery failures, retries,
etc. In telephony we're talking busy signals, no answers, fast busy,
error tones (e.g. Da-Do-Da "I'm sorry, your number can not be completed
as dialed..."). How long should we wait between calls if busy? How
many times should we retry?
Then there's LATA issues with calling. Let's take PINES. One telephony
server would make how many calls? Between how many different LATAs?
Our current telephony server makes 300-500 calls a day for only our
system. Toll charges can add up quick... So, distributed servers
calling for specific regions are useful.
You are correct that dial-in service for renewals, etc. is also
popular. This requires much tighter integration with the ILS, as you're
dealing with authentication and real-time data. This is also where
Asterisk comes to mind, as it has the pieces available for phone
tree/application type service. I'm not familiar with it, but it also
has some kind of Jabber interface, not sure if that could be useful.
I agree that notification overall has a lot of possibilities, but I have
some selfish motives in regard to telephony, as I'm seeking to replace
something existing, and that would be quickly missed if not available.
A notification API using the previously discussed interface, was it
OpenSRF over HTTP (?), might fit the bill well. Again, I'm just
starting to poke at possibilities. I've operated 2 different telephony
servers for ILS notifications, and have seen some good and bad with each.
...back to vacation.
More information about the Open-ils-dev
mailing list