[asterisk-dev] channel on hold

[Clod Patry]

can we go on the way I proposed for knowing which chans are on hold?
when a new way will be implemented, we could just change my new command, no?

Since 99% of my installations use MOH, that will solve all my issues and
many issues out there.

Is my change to res_musiconhold.c is viable ? do you see any impact?

On 8/22/07, Russell Bryant <russell at digium.com> wrote:
>
> Clod Patry wrote:
> > i'd like to know if there's a much cleaner way to know if a specific
> chan is
> > on hold.
> > The goal behind is simpler: make a new CLI command to list all the
> channels
> > that are currently on hold.
> >
> > Based on that, i could use the ast_channel struct with music_state,
> since
> > all on hold starts it, right (if res_musiconhold.so is loaded) ?
> > Something like:
> > if ( chan->music_state) {
> >    //the call is onhold
> > }
>
> That won't work, because MOH is not always in use when channels are on
> hold.
> Channel drivers choose how to handle being put on hold.  The most common
> thing
> to do is just play MOH to the channel.  However, there are some channels
> that
> can pass this information as signalling across the network.  For example,
> this
> can be signalled over PRI in chan_zap, and in chan_iax2.  In theory, we
> could
> add support for signalling HOLD in chan_sip, but it's not that way yet.
>
> --
> Russell Bryant
> Software Engineer
> Digium, Inc.
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
Clod Patry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070823/2dd6c541/attachment.htm