[Asterisk-Dev] Request for comments on CTI integration
Sunrise Ltd
stsltdtyo at yahoo.co.jp
Wed Jul 14 17:28:29 MST 2004
Nicolas Gudino wrote:
>Check the Flash Operator Panel, its not exactly the same
kind of
>program, but very similar. There is a server, writen in
perl, that
>connects to the manager port to catch up events, and it
also
>listens to clients (in this case swf flash movies) that
displays
>information about channel status and also can trigger
actions
>like transfers and hangups.
Thanks. I had a look at your demo and read through the
documentation. It really looks like a nice *operator* app,
just as it is intended. But I wouldn't want to recommend
it to clients for ordinary staff. It would seem overkill.
Keep in mind we are only looking to get information, not
to exercise control.
Also, Flash is a definite no go here. None of the
applications we need to integrate with are web based.
Also, we want to reduce the required infrastructure to an
absolute minimum. It has to be ultra-feather-light-weight.
Running a web server is not always what customers want to
do on their telephony servers for security and other
reasons.
Also, we will eventually be looking at running the client
on cell phones. Japanese cell phones have a technology
called iAppli which is Java based but minimalistic, like
16KB maximum size per applet. I would expect the client to
fit into 2-4 KB if not less.
The notification messages should also be
ultra-feather-light. All that is needed should be no more
than ...
1) event code
2) event reference number (unique)
3) origin of call (network name and caller's number)
4) transferred via (if TRANSFER event)
5) destination (if client subscribed to notifications for
multiple destinations)
If the event and its reference number is binary coded, 3
bytes should be plenty. Reserving 16 chars for the network
name should be plenty, too. The phone numbers could be
packed BCDs plus one stop byte. All in all we'd be looking
at about 40 bytes per notification message.
A simple event like PICKUP, HANGUP, TIMEOUT or
TRANSFERRED-TO-VOICEMAIL would consist only of
1) event code
2) reference number linking to previously sent
notification
which should be 3 or 4 bytes per message.
>The panel can popup webpages whith the callerid for
>certain channels also, just like your intended
>application.
The applications I need to integrate with are not ours.
What I need is an easily accessible information source
that any kind of application can tap into.
>It does not keep a log, but displays timers for ongoing
calls.
Never mind. Keeping logs and generating time stamps/timers
would be up to the application program.
>Not needed for the op_server as it catchs all manager
>events and tries to understand and guess the status
>of the channels. But its limited to the events displayed
>in the manager port. I think that the manager is enough
>no need to modify other applications or the asterisk
core.
OK, using astman might be a good way to get the
information *out* of Asterisk, but web and flash is not a
good and efficient way to send it to clients for the
purpose of showing call information on a single extension
or perhaps two.
I'd envisage that a client will typically subscribe to
notifications for no more than three destinations, for
example ...
1) the user's internal extension
2) the user's group or departmental extension
3) the mobile phone number to which Asterisk forwards when
the user is out of the office
>Take a look at the op_server.pl, much of the work you are
>trying to do is already done there.
I will try to understand how you talk to astman to get
info out of Asterisk. However, I'm not good at reading
Perl. I use Python ;-)
thanks again
regards
benjamin
__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/
More information about the asterisk-dev
mailing list