[asterisk-dev] DAHDI documentation

[Shaun Ruffell]

I'm respond to Torrey's email but this response is for Gary.

On Wed, Oct 02, 2013 at 10:22:24AM +0200, Torrey Searle wrote:
> Here is my experience:
> 
> 1) dahdi takes care of hdlc framing for you

Just to add a minor clarification:

Some drivers can also do it in hardware versus in dahdi-base.c (this
is the difference between configuring the data channel as "dchan" vs
"hardhdlc") but in some cases the extra register reads and writes to
pull the hdlc frames out of the framer was more time consuming than
allowing the dchannel to be DMAed into host memory and allow
software to frame / decode the HDLC messages.

> 2) ISDN/PRI is not done in the kernel, all layers of the stack are
> implemented in the userspace libarary libpri
> 
> 3) you need to read/write frequently to dahdi for the card to work
> properly, but don't use a timer, use a select() to determine when it's time
> to read and when it is time to write

You can also set the amount of "buffering" available in the kernel
with the DAHDI_[GET|SET]_BUFINFO ioctls [1]. Controlling the policy
is really only useful with FAX and modem signals. Since you do not
want any discontinuities, you would want to make sure you have more
than one packet of audio queued up before you allow the
transmission to start.

[1] http://git.asterisk.org/gitweb/?p=dahdi/linux.git;a=blob;f=include/dahdi/user.h;h=68e72e05c59a7c7536dcb6ee2b5919df3afb78ba;hb=HEAD#l767

> 4) the dahdi driver has the ability to conference audio built in.  I
> suggest using that for your audio mixing needs.  You can look at the code
> for dahdi_monitor as an example of this

Also, if you just want dahdi to return / take signed linear data,
you can use the DAHDI_SETLINEAR ioctl [2]

[2] http://git.asterisk.org/gitweb/?p=dahdi/linux.git;a=blob;f=include/dahdi/user.h;h=68e72e05c59a7c7536dcb6ee2b5919df3afb78ba;hb=HEAD#l872

> 5) dahdi cards do support hardware dtmf detection

I would add that *some* cards do and in my experience (when used
with Asterisk) it can cause problems depending on how Asterisk is
configured.

For this reason, I always found it easier to allow all the DTMF
detection to be done up in userspace where the time of the DTMF
event can be more closely matched with the audio. The DAHDI
interface as it exists now cannot really synchronize events to the
audio.


> for code examples: you can look at dahdi_monitor in dahdi tools.  I don't
> know if libpri library has any test applications, but I do know libss7 has
> an example program ss7linktest which is a very good example of how to use
> the card with ss7 signaling.
> 
> Hope this helps!
> 
> Torrey
> 
> 
> On 1 October 2013 21:47, Gary <garylosangelesca at gmx.com> wrote:
> 
> > Hello,
> >
> >
> >
> > I wanted to switch from using Dialogic/Eicon cards to using Digium's T-1
> > cards. When I purchased a sample card the salesperson assured me there was
> > documentation specific to the DAHDI interface. Now that I'm digging in, I'm
> > finding it's documented a lot like Linux -- one must read the fairly
> > uncommented source code.
> >
> > I don't have a problem with this generally, but here I just don't
> > understand the divisions of labor between Asterisk, DAHDI Hardware, DAHDI
> > kernel modules and Userland (me). (BTW, I do not wish to use Asterisk as we
> > have numerous projects based on Dialogic/Eicon spanning some 20 years. My
> > intent is to write a replacement look-a-like driver which uses Digium's
> > cards instead of Dialogic's.)
> >
> > My specific issues are:
> >
> >  1) HDLC. Does the hardware have an HDLC controller, or is it the user's
> > job to hunt for flags, frame the data and calc the FCS?
> >
> >  2) ISDN/PRI. Does the kernel module load Q.921/931 implementation or is
> > this user's responsibility? I know there's a LIBPRI product, which I may
> > use, but I have my own PRI library which was confirmance tested with ATT
> > years ago. Either way, I'm not sure how the D-channel data is flowing.
> >
> >  3) I got the idea that B-channel data is collected by the kernel module
> > in 8 sample blocks (1 ms). Does this mean I need to be reading it
> > out/writing it in at that rate? I saw some buffering code, but wasn't sure
> > if that was voicefile type playback/record or if all audio is treated
> > without regard to its source/destination. I guess I could lock onto it at
> > 1ms using Linux's HPET timer, although that sounds clumsy.
> >
> >  4) I can certainly convert between ulaw/linear to sum for conferencing,
> > but it seems the kernel module might support that as well? Or at the least
> > it seems the kernel module can support chan-to-chan connections.
> >
> >  5) I found some DTMF (FIR goertzel) code somewhere in DAHDI, but also in
> > Asterisk. While I have such code in own library, am I to understand DTMF
> > can be detected within the kernel module?
> >
> > I guess I really would like to see a doc on the overall concept of DAHDI
> > hardware and its kernel module. I don't care how it's laid out, I'd just
> > like to get my mind around it. Does anyone know of an example telephony C
> > file that might show:
> >
> > 1) initialization of DAHDI spans
> > 2) waiting for inbound events
> > 3) answering a call
> > 4) sending a voice file, recording a voice file
> > 5) disconnection of calls
> > 6) de-initialization
> >
> > And perhaps showing how two channels are connected to create a
> > conversation?

I can create this document for you and throw it up on the wiki [3].
However I won't be able to do it until after Astricon so it may be a
couple of weeks.

[3] https://wiki.asterisk.org/wiki/display/DAHDI/Digium+Asterisk+Hardware+Device+Interface

But I agree it needs to be written and since you have a real need
now seems like a good time. If you're coming to Astricon by any
chance shoot me a private email and we can meet up.

Cheers,
Shaun

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org