[asterisk-dev] How to pass a parameter to the DAHDI kernel driver ?

[Pavel Troller]

> On 09/14/2011 01:06 PM, Pavel Troller wrote:
>>> On 09/14/2011 02:02 AM, Pavel Troller wrote:
>>>> Hi!
>>>>     I'm writing a customization for the DAHDI driver - a possibility to transmit
>>>> periodical charging pulses to the line for incoming calls.
>>>>     I've done most of changes on the driver level (dahdi-base.c and corresponding
>>>> include files) and the pulses are now happily being transmitted in the answered
>>>> state of the channel, but with a hardcoded pace (3 secs for now).
>>>>     I've also done a high-level (dialplan) part - according to the called number
>>>> analysis, a variable is available in the time of the answer signal coming to the
>>>> caller, containing the required charging pulses timing.
>>>>     What I need to do to finish my work, is to pass the contents of the variable
>>>> to the driver during signalling the answer. Any suggestions, how to pass a
>>>> numeric parameter to the driver during the signalling process ?
>>>
>>> You will have to implement an ioctl() operation that chan_dahdi can use to
>>> read/write the value on the channel in DAHDI.
>>>
>> Hi Kevin,
>>    thank you for your reply. I'm already on this way. However, I have a small
>> supplementary question.
>>    In include/dahdi/user.h, there are definitions like this:
>> #define DAHDI_SETCADENCE    _IOW(DAHDI_CODE, 42, struct dahdi_ring_cadence)
>>    I'm about to implement my DAHDI_SETCHAPULSE, but I don't know policy of
>> assigning the function numbers. These are just raw constants, which seem to be
>> incrementing, but there are some duplicates (for example, DAHDI_LOOPBACK and
>> DAHDI_RADIO_[SG]ETPARAM are both using number 58). So, which number can I
>> assign for my function without danger of collision with current or future
>> status of DAHDI development ? In my proof-of-concept code I'm using 111, which
>> doesnt' seem to be used yet.
>
> Just choose a number that is 50 or 100 higher than anything currently 
> assigned, and it's quite unlikely that it will collide. If you ever submit 
> the code for inclusion, the number could get changed, but that's a minor 
> point.
>
Hi!
  So, I've did it, it seems. It does exactly what was required, and it doesn't
have any visible side-effects.
  Of course, to use it, you need a hardware capable of sending the pulses to
the phones. In my case, it's using a kind of "channel bank" or "E1
multiplexer", utilizing a standard Asterisk E1 card with a special type of
DAHDI signalling on it (a variant of european CAS with DTMF or pulse dialling),
which I've written formerly as a closed project. The multiplexer contains FXS
cards, which are able to generate 16 kHz or polarity reversal pulses according
to their strapping. I don't know, whether any Digium or other native Asterisk
FXS cards can generate 16kHz, but they probably can generate polarity reversal
pulses. However, I don't have any of these cards, so implementation of the
lowest layer of sending the pulses to the hardware for such a card has to be
done by someone else.
  I can submit a patch, residing in chan_dahdi.c, sig_analog.c, dahdi-base.c
and corresponding include files, but it's based on 1.8 branch. Currently
I don't have a running 1.10/trunk installation, so I cannot adapt the patch
for it. Is anybody interested in adapting this change to the Asterisk trunk ?

With regards,
  Pavel