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

[Moises Silva]

> Only thing to consider with spandsp is: which version to use?
No such concern for Asterisk or users. The MF R2 detector and
generator routines were moved into openr2 library. These routines are
not likely to change, if the routines ever change significantly for
users, I will update them directly in openr2.

> NUM_SPANS still defaults to 32, IIRC. We only need such a constant
> because we maintain an array of "struct pri"-s. Now you use this for
> something that is not even a dahdi span.
>
> What does this monitor thread do? Why not use the existing monitor
> thread?
PRI and SS7 signaling use this NUM_SPANS constant indeed. With R2 is
true that is not used for real spans, but just to group channels. I
don't see an issue with this other than the one I mentioned in the
review board. However, the only true need is to group channels of the
same R2 variant, so, I will change the behavior to just create a new
r2link when the mfcr2_variant specified changes.

The R2 monitor thread takes care of the call setup waiting for
DAHDI_EVENT_BITSCHANGED or simply to read and write the MF tones
required for ANI, DNIS and calling party category request information
according to the R2 variant of the channels.

I stayed away from the current monitor thread to avoid messing up with
current working signaling and start in a fresh space without things
that the R2 monitor thread does not need, like mwi.

> Next thing is, what are all of those extra globals, and why are they
> reset when:
> 1. A channel is destroyed (will it break other calls?)
> 2. load_module() (just before setup_dahdi() ).
General signaling values for the configuration of the R2 channels.
They are set only when starting chan_dahdi and on dahdi restart. What
do you mean when a channel is destroyed? dahdi destroy? if so, they
are not reset on such case. Btw, in current trunk, when a user calls
dahdi destroy channel from the CLI, I don't see we're locking iflock,
I think we should.

> They are not, initialised, however, on reload. Thus if you have:
No, because on reload I don't change any R2 signaling value, just on
restart. I will add support for that.

> Please use struct dahdi_chan_conf for your configuration. It is
> initialised explicitly.
Will do. Thanks.

-- 
"I do not agree with what you have to say, but I'll defend to the
death your right to say it." Voltaire