ztloop with CAS support

During some time I had the idea that it should be possible to test the user space software that deals with E1/T1 lines (Asterisk, FreeSwitch, OpenR2) without any hardware at all, that way I could work off-line in my laptop (when I am on-line I usually have access to some server with an E1 card on it). Yesterday I googled a bit about it and found the ztloop kernel module, developed by the company DruidSoftware. It’s a very simple module, based on the ztdummy module, but is not part of the zaptel package, so you have to download it, and patch the Makefile to compile it.

The module works by registering 4 zaptel spans. The first 2 are connected, by software, in loop. Which means anything you write to channel 1 (span 1) it will be available for reading in channel 32 (span 2). It does this by soft-wiring the tx and rx buffers of each span channel and registering a timer callback with the kernel, which will call it at a 1024Hz rate (just like ztdummy) and calling zt_transmit() and zt_receive() from within this callback (since there is no E1/T1 hardware interrupts, this timer is required).

The other 2 spans are for line tapping. All channels in span 3 tap span 1 and span 4 taps span 2. If you open a channel in span 3 you will be able to eavesdrop the data over the corresponding channel in span 1 (this tapping functionality can also be accomplished by zaptel pseudo devices, that is the way ztmonitor works).

The number of loop and tapping spans is configurable passing parameters to the kernel module.

Even though this module works fine for PRI lines, until today, it did not work for MFC/R2 lines, because it was lacking CAS support. After reading for some time Zaptel drivers code it started to make sense and I added a few lines of code required to loop R2 lines.

I basically added the span handler (a function pointer in the zt_span structure) to handle the transmission of CAS bits. This handler is called each time some process from user space calls ioclt(fd, ZT_SETTXBITS), most drivers would talk to the E1/T1 hardware to ask it to change the bits position, but, what I did is to call zt_rbsbits() function in the span that I know this span is looped to, that way the other span will “see” the bits and wake up any user space process that is waiting on bits changes.

It’s kind of cool that now I can test my Asterisk MFC/R2 development in my laptop w/o needing any hardware at all 🙂

The source code for this modified ztloop kernel module can be found here: http://www.moythreads.com/ztloop.c. I will send the patch to the DruidSoftware guys to see if they include it in their next release.