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.

This entry was posted in asterisk, freeswitch. Bookmark the permalink.

7 Responses to ztloop with CAS support

  1. moy says:

    I think I did not include the dahdi_loop.h because is the same one distributed by DruidSoftware. In any case, I created a tar you can try: http://www.moythreads.com/dahdi-linux-loop-

  2. virvir says:

    Hi Moy.
    long time since the last time we spoke, i hope you are fine.
    there is my problem, (like you was a dra heart)
    i tried the dahdi_loop.c whitout luck, it sems there is a one file missing
    a dahdi_loop.h and therefore the module does not compile
    whith errors like:
    /root/dahdi-linux- In function âdahdi_loop_hr_intâ:
    /root/dahdi-linux- error: dereferencing pointer to incomplete type
    /root/dahdi-linux- error: dereferencing pointer to incomplete type
    /root/dahdi-linux- In function âdahdi_loop_rbsâ:

    and so on.
    any hints about? some tar do you want to share? 🙂

  3. lr says:

    Thank you Moy, this is awesome 🙂 I will try to test it over the weekend and report back.

  4. moy says:

    Btw, once in a while I get strange cas results in some channels, I have not had time to debug it yet, if you ever find out about it and fix it, let me know

  5. moy says:

    Well I decided to just upload the file in the meantime: http://www.moythreads.com/dahdi_loop.c

  6. moy says:

    Hello Lukas, I already did 🙂

    I just have not posted it, I will post it on the weekend. The invalid argument thingy is usually because system.conf is trying to configure an span in an invalid mode (of course it may also be a bug somewhere)

  7. lr says:

    Hi Moy,

    I wonder if you plan to upgrade ztloop to dahdi_loop? There is already one attempt by Joerg Zissel – see http://translate.google.com/translate?hl=en&sl=de&u=http://www.ip-phone-forum.de/showthread.php%3Ft%3D188983&ei=-k8eSrj-C6OQjAfUv-yJDQ&sa=X&oi=translate&resnum=7&ct=result&prev=/search%3Fq%3Dztloop%26hl%3Den but this one does not include CAS support most likely. I was unable to verify it because I am still getting quite confusing error: DAHDI_CHANCONFIG failed on channel 1: Invalid argument (22) Did you forget that FXS interfaces are configured with FXO signalling and that FXO interfaces use FXS signalling?


Leave a Reply

Your email address will not be published. Required fields are marked *