<div>Howdy,</div><div><br></div><div>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.</div>
<div><br></div><div>Applications requiring to write to the channel can be executed but won't work simply because anything that is written is dropped.</div><div><br></div><div>I created 2 issues in the asterisk bug tracker for this feature:</div>
<div><br></div><div><a href="https://issues.asterisk.org/view.php?id=15971" target="_blank">https://issues.asterisk.org/view.php?id=15971</a></div><div><a href="https://issues.asterisk.org/view.php?id=15970" target="_blank">https://issues.asterisk.org/view.php?id=15970</a></div>
<div><br></div><div>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). </div>
<div><br></div><div>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 (<a href="http://svnview.digium.com/svn/asterisk/team/moy/dahdi-tap-1.6.2/" target="_blank">http://svnview.digium.com/svn/asterisk/team/moy/dahdi-tap-1.6.2/</a>), 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.</div>
<div><br></div><div>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".</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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. </div>
<div><br></div><div>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).</div>
<div><br></div><div>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)?</div>
<div><br></div><div>Thoughts are very welcomed,</div><br clear="all">Moises Silva<br>Senior Software Engineer<br>Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada<br>t. 1 905 474 1990 x 128 | e. <a href="mailto:moy@sangoma.com" target="_blank">moy@sangoma.com</a><br>