[asterisk-dev] [Code Review] MFC/R2 support for chan_dahdi

[Moises Silva]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/40/
-----------------------------------------------------------

(Updated 2009-02-17 00:03:37.222126)


Review request for Asterisk Developers.


Changes
-------

- Updated to trunk revision 175774.
- Addressed Russell's comments.
- Included a small new feature that helps to be compliant with Brazilian certification by ANATEL. New application DAHDIAcceptR2Call that complements the new feature mfcr2_accept_on_offered. 


Summary
-------

MFC/R2 support for chan_dahdi.

The code for tone detection (main/dsp.c) and generation (DAHDI MF support in chan_dahdi.c) is not actually being used now. In the early stages of development, spandsp was not LGPL and that's why applications can provide a MF interface to generate and detect the tones required for this signaling to work. Now that spandsp is LGPL, openr2 has embedded the R2 MF detector and generator and is the one currently being used. I had issues (tones either not being generated or not being detected properly) in some x86 64 bit, and the detection was 50% slower than the one in spandsp. Unless there is some important reason you can think of to switch back to DAHDI and main/dsp generator and detector, I suggest to get rid of that code, but I wanted to ask first. 

There is an issue with the way I currently handle how many monitor threads I launch. This code will launch as many monitor threads as group of channels are specified in the chan_dahdi.conf file.

channel=1-15,17-31

That would launch 2 monitor threads and use 2 r2link structures. There is maximum of NUM_SPANS r2link structures statically allocated when the module is loaded.

channel=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15

That would launch 15 threads, 15 r2link structures would be used with only 1 channel each. If some user specify the channels this way, a single DAHDI span would consume all the available structures. Not a common scenario though, since most users would just specify 1-15 in such cases. Should I get rid of that mechanism for launching monitor threads?


Diffs (updated)
-----

  /trunk/channels/chan_dahdi.c 176494 
  /trunk/configs/chan_dahdi.conf.sample 176494 
  /trunk/configure.ac 176494 
  /trunk/makeopts.in 176494 

Diff: http://reviewboard.digium.com/r/40/diff


Testing
-------

Lots of users currently using this in 1.2, 1.4 and 1.6 in Brazil, México and Argentina. An unknown number of users (but at least 1) for each of the following countries: colombia, nepal, thailand, venezuela, perú and probably others. The code in chan_dahdi.c is independent of the variants though, which are handled by the OpenR2 library.


Thanks,

Moises