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

[Steve Totaro]

John Todd wrote:
> At 2:53 PM -0600 2006/10/31, Matthew Fredrickson wrote:
>> On Oct 31, 2006, at 1:03 PM, John Todd wrote:
>>
>>> 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?
>>
>> Yeah, we talked about it this last week.  Sorry this thread has been 
>> going so long since I replied, but I have been working on a lot of 
>> other things.  Last week at Astricon I got the initial framework 
>> finished in chan_zap for supporting blocking and unblocking 
>> operations on channels.  The only protocol it works for right now is 
>> SS7.  Mark Vince at AT&T is supposed to get me a spec on how it's 
>> supposed to work on AT&T 4E/5ESS.  There will be a pair of CLI 
>> commands, zap block channel and zap unblock channel, as well as 
>> modifications to zap show channels to display blocking status 
>> (locally blocked, remotely blocked, inservice, out of service, etc).
>>
>> Matthew Fredrickson
>
>
> There was some interest in being able to have other methods of 
> achieving the same result:
>
>  - Manager command for busying out channels (fairly important)
>  - Dialplan command for busying out channels (less important)
>  - Visible indicators as to what channels were administratively
>      deactivated, via a "zap list" or even (gasp) SNMP
>
> While anything would be welcome, it might be good to start making 
> commands for this type of system maintenance reachable through several 
> methods for large-scale deployments.
>
> JT

Maybe someone mentioned it, but I would like to see it also included as 
a "Stop" option such as "Stop gracefully" which would do what it 
currently does but also take each channel and make it "busy" if not in 
use or when it becomes not in use.

Thanks,
Steve Totaro