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

[Freddi Hansen]

>
> From: "Imran Ahmed" <codentest at gmail.com>
> Subject: Re: [asterisk-dev] Re: How to busy out PRI channels?
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Message-ID:
> 	<f929a6640610261959q7863f681ob728668478e7f90e at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 10/26/06, Tony Mountifield <tony at softins.clara.co.uk> wrote:
>   
>> > In article <p06240505c166811e91a3 at loligo.com>,
>> > John Todd <jtodd at loligo.com> wrote:
>>     
>>> > > At 2:30 PM +0000 2006/10/26, Tony Mountifield wrote:
>>>       
>>>> > > >
>>>> > > >Anyway, that's two replies approving of the feature, but none yet from
>>>> > > >anyone with any hints about accomplishing it. Perhaps when folks have
>>>> > > >finished at Astricon....
>>>>         
>>> > >
>>> > > Actualy, there has been sidebar discussion here at Astricon (was it
>>> > > in session or in the hall or at dinner?  I have no idea.) about what
>>> > > to do for this.  Mark Vince and I have noted that this is is for some
>>> > > reason on everyone's midn, and possibly with the appropriate bribes
>>> > > or caffeine in the CodeZone it may get done, or at least discussed in
>>> > > more detail.  I would suggest that if anyone on the list who is not
>>> > > at Astricon has any code to contribute that this would be a great
>>> > > time to throw some ingredients in while the chefs are looking at this
>>> > > particular pot.
>>> > >
>>> > > 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?
>>> > >    - how do you display the status of channels?
>>> > >    - how do you distinguish if the other side has busied a channel out?
>>>       
>> >
>> > John, thanks for the reply - good to know the issue is being talked
>> > about over there! I'd love to contribute code, but currently don't know
>> > enough about libpri etc. to come up with any. I'd be interested to hear
>> > the thoughts of someone like Matt Frederickson on this issue.
>>     
>
> Matthew Frederickson is probably the right person to answer these question:
> Is it possible to not acknowledge new setup requests (letting the
> request time out) and still be able to continue existing calls on a
> pri, without the pri line going into an alarm.
> If so, will the telco switch re route the new calls to another pri on
> the trunk group or indicate busy? Also does this behavior change with
> switch type?
>
> If the pri does not go into alarm, then libpri code can be changed to
> accomodate such requests, which will allow us to bring down a pri line
> without disrupting a calls during peak usage time, any comments?
>
> Regards,
> Imran.
ok i'll try again - hopefully without html!!

We had the same issue a few years ago on a callingcard platform. C7 and 
R2 signalling allowed us to open/backbusy channels but we found no 
direct support for this in ISDN.
Our workaround was to dial a non-existing number on the channels that 
should be busy. The CO would then try to release the channels after the 
call reject - we did then delay the ack of the release  to keep the 
channel busy. It was possible to hang-on the the release for approx 180 
seconds without any problems. The fake backbusy then had to redial the 
number again to keep the line busy. If we were holding the ack for more 
than 180 seconds then the channel went in to some error state which 
sometimes required a link reset to get it operational again. All other 
calls on the same trunk were  always un-affected  by  our fake backbusy. 
This was implemented on a platform using Aculab linecards.
Just my 2 cents and experience on this issue.
Freddi