[asterisk-dev] Re: How to busy out PRI channels?

[John Todd]

At 12:04 PM -0400 2006/10/26, Andrew Kohlsmith wrote:
>On Thursday 26 October 2006 11:19, John Todd wrote:
>>  The problem set seems to be:
>>     - how do you [busy,un-busy] channels out from a "live" system without
>>         re-loading zaptel?  Should it be CLI only, or should there also be
>>         something that is possible from within the dialplan and/or AMI?
>
>CLI+Dialplan.
>
>How is it "difficult" to do live?  You don't remove the lines from zaptel, you
>simply force their state.  normal Zaptel calls would then return that the
>line is busy or offhook, and additional checks in chan_zap would have to
>catch this and note that it's maintenance offhook and NOT call the normal PBX
>code for an offhook channel.
>
>This is (in my opinion) a critical feature of any kind of digital service, and
>if Zaptel does not have hooks in place now to force channel state, it should
>have the appropriate IOCTLs registered.  Something to be able to say "this
>channel's state is forced to be state 'x'" where (at present time) x would
>either be "in service" or "out of service", and to remove the forced state
>you'd just zero the forced state.  The other IOCTL would just return the
>forced state.
>
>>     - how do you display the status of channels?
>
>"zap show channels" -- an additonal column should be added for "state", and
>perhaps get rid of the next-to-useless MOH column.
>
>>     - how do you distinguish if the other side has busied a channel out?
>
>You don't; with CAS T1s you simply see the line as off-hook.  with CCS
>circuits I believe there are two specific states "busied out" and
>"maintenance" which could be used.
>
>-A.

I think this is all on track for what is being discussed on or around 
the CodeZone room.  (Sorry, I haven't been sitting in on those 
conversations myself.)  It does sound like much of the problem set I 
described is being considered; Matt Frederickson and Mark Vince would 
be best to comment since they're closer to the problem and may have a 
chance to comment if they're not busy actually writing code.  Matt, 
Mark?

JT