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

[Kevin P. Fleming]

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.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org