[asterisk-dev] chan_zap questions

Armin Schindler armin at melware.de
Thu Jul 13 08:59:37 MST 2006


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.

Armin



More information about the asterisk-dev mailing list