[Asterisk-Dev] Specific question about pri_dchannel in channels/chan_zap.c

[Chris Ziomkowski]

Thanks Mark. I get it now. Have a bigger problem because for R2, the 
library requires the ability to read/process the audio stream.

Unfortunately, the Dial application opens the file descriptor as well, and 
so they compete for the data stream and then R2 hangs. Apparently, that is 
why this library was only functional for incoming calls.

Haven't thought of a good way around this one yet.

I'll announce if I have any ideas.

Thanks again,

Chris Ziomkowski
cziom at jsg.co.th

At 08:26 9/7/03 -0500, you wrote:
>In the specific case of zap, you can always count on a channel being read
>quite frequently since one of the file descriptors will point to a channel
>which (on or off hook) will always return some sort of audio periodically.
>on other channels such as "SIP" and "MGCP", we use a pipe to notify (the
>pipe is the only way I could figure out to *guarantee* that there was no
>race.
>
>Mark
>
>On Wed, 9 Jul 2003, Chris Ziomkowski wrote:
>
> > I have a more specific question in my quest to understand the internals of
> > asterisk and implement R2 outbound dialing.
> >
> > Specifically, given a PRI channel dialing out, it appears that the ANSWER
> > message will be read by the function pri_dchannel in channels/chan_zap.c at
> > or around line 5806.
> >
> > My question is, how does an application (such as Dial) which is blocked in
> > an ast_select() on the channel actually get informed of this?
> >
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev