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

[Matthew Fredrickson]

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