[asterisk-dev] chan_zap questions

Klaus Darilion klaus.mailinglists at pernau.at
Thu Jul 13 06:21:01 MST 2006


Armin Schindler wrote:
> On Thu, 13 Jul 2006, Klaus Darilion wrote:
>> Armin Schindler wrote:
>>> On Wed, 12 Jul 2006, Klaus Darilion wrote:
>>>>> Maybe an additional subclass
>>>>> AST_CONTROL_AOC
>>>>> should be introduced.
>>>> Thats what I did and it works fine. But ast_indicate_data requires a
>>>> ast_channel as first parameter. If FACILITY is received on leg2, I
>>>> have to
>>>> find out the ast_channel of leg 1 to indicate on the proper channel.
>>>> Fur this
>>>> purpose I still use ast_bridged_call. Any other suggestion?
>>> No, don't use ast_indicate*() directly, just use the normal *read
>>> function to give this CONTROL frame to asterisk. The asterisk code
>>> (bridge or dial-before-bridge) will forward this CONTROL frame to the
>>> other leg. 
>> Hi Armin!
>>
>> How are the frames handled in Asterisk - synchron or asynchron? For example,
>> in chap_zap I allocate a buffer, and queue a control frame whose data member
>> points to the buffer. Once chan_zap receives the control_frame, it will read
>> data from this buffer. Is this safe?
> 
> The data of such an control frame is placed like the voice data to
> f->data and f->datalen (f->data must point to the buffer).
> You should assume asynchron, because on certian parts there are queues and 
> pipes used, so it's not synchron.
> The f->data pointer must be valid until the other leg has read it.
> So maybe an malloc'ed space should be used.

I've just checked ast_queue_frame - looks like the whole frame including 
the data buffer will be copied in ast_frdup 
(http://www.asterisk.org/doxygen/frame_8c.html#a22)

So there shouldn't be a problem. I just hadd to extend dial.c to 
recognize the AOC control frames.

regards
klaus



More information about the asterisk-dev mailing list