[asterisk-dev] DAHDI documentation
Torrey Searle
tsearle at gmail.com
Wed Oct 2 03:22:24 CDT 2013
Here is my experience:
1) dahdi takes care of hdlc framing for you
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
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
5) dahdi cards do support hardware dtmf detection
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?
>
> Thanks in advance,
> Gary
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131002/0f933860/attachment-0001.html>
More information about the asterisk-dev
mailing list