[asterisk-dev] Line tapping feature for PRI lines (need of chan_tap?)

[Moises Silva]

Howdy,

Some months ago I wrote a feature for Asterisk/Libpri that allows Asterisk
to receive calls from T1/E1 PRI tapped lines. The obvious dial plan
application to execute for such calls is Record(), but you can really do
whatever you want, like calling Dial() to send the call out to an extension
or use ChanSpy() over the calls being recorded for real-time monitoring.

Applications requiring to write to the channel can be executed but won't
work simply because anything that is written is dropped.

I created 2 issues in the asterisk bug tracker for this feature:

https://issues.asterisk.org/view.php?id=15971
https://issues.asterisk.org/view.php?id=15970

I have someone using it in call center environments with reasonable success
tapping Dialogic predictive dialers. There seems to be some race conditions
that can cause losing a few calls if the calls are being placed too quickly,
which is an issue I am investigating this days. When I get the
PRI_EVENT_HANGUP_REQ event I queue a hangup frame for the channel which
should be hangup in the next read operation. However, if a call is placed in
that channel before the asterisk channel is hung up (the tapped line does
not wait for the ack from us obviously), the new call will not be monitored
because the channel is busy (still has an owner).

The reason for this email is request feedback from other Asterisk
developers, since I am now at a disjunctive. Most of the people using this
have been on my 1.6.2 tapping branch (
http://svnview.digium.com/svn/asterisk/team/moy/dahdi-tap-1.6.2/), and there
is no much plans to test my trunk branch in production as of now. I was
planning may be send a proposal to speak about it at Astricon to promote
this development (not sure if Astricon is accepting proposals still, or yet)
and have more testers.

I've been thinking into move this feature in its own channel driver. I know
it might sound silly, since still involves DAHDI devices, my first
impression is indeed that belongs to chan_dahdi, that's why I code it there.
However, from an adoption and faster integration into Asterisk, it may be
useful to create "chan_tap".

The benefit being that the feature will be (may be?) easier to review and
even maintain (no fears of breaking anything into chan_dahdi.c and/or
sig_pri.c). Also most likely will make easier to maintain a backport for 1.6
users since there will be no patches, just a separate channel driver to make
&& make install.

Eventually it can be added to the same driver tapping for analog and MFC-R2
lines. And who knows, may be even IP network protocols (tapping with
libpcap).

The downside would be that I have to put all the glue for the new module,
parsing configuration, CLI commands etc. However I don't feel this is a huge
task or that there is a big benefit on sharing the code with chan_dahdi.

The other area where I would like to hear suggestions is about the
retrieving of the PRI events. As of now I am using a modified version if
libpri. I had to remove some state checking when receiving events and modify
the destruction of the PRI call structure to be entirely driven by the user
(the user must call a function to destroy the call when is done). Although
this approach seems to work, again, I feel is more like a hack, and that
integrating those changes into libpri may not be desired (even when would be
optional).

May be I should be writing my own lib (using parts of libpri as a base?) to
pull out the information I need from the read Q931 messages? May be I could
take a look at the wireshark dissector code and take some of it to put it in
a library (may be there is licensing issues there though if I want this
integrated into Asterisk)?

Thoughts are very welcomed,

Moises Silva
Senior Software Engineer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3
Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100702/8c9a8cc6/attachment.htm