[asterisk-dev] chan_zap questions

[Klaus Darilion]

Armin Schindler wrote:
> On Thu, 13 Jul 2006, Klaus Darilion wrote:
>> Armin Schindler wrote:
>>> On Thu, 13 Jul 2006, Klaus Darilion wrote:
>>>> 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.
>>> That's right. If you use ast_queue_frame(), it's no problem.
>>> (don't forget the free the frame afterwards ;-)
>>>
>> Uuups. Thanks for the tip.
>>
>>>> I just hadd to extend dial.c to recognize the
>>>> AOC control frames.
>>> I think you mean apps/app_dial.c !?
>>> But it is at least ast_generic_bridge() in channel.c too.
>> Basically, my changes in app_dial.c were wrong, ast_generic_bridge is correct.
> 
> Since the bridge-code might not be active when AOC* arrives, app_dial.c
> my need this too?
> Too bad, that there is no common place for this.

Maybe this is necessary for AOC-S, but I think it is not necessary for 
AOC-D and AOC-E. AOC-D will be sent after CONNECT/CONNECT_ACK. Thus, 
app_dial should be already in bridged mode.

klaus