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

Mon Oct 30 15:56:58 MST 2006

Disclaimer: I am not an expert on ISDN, nor do I play one on TV. 

That said, I do know this: Most (if not all) traditional Big-Iron
systems do have a mechanism for "Busying-out" individual B channels,
which seems to be honored by the switch side in terms of hunting / etc. 

In addition it looks like some work (incomplete) has been done on this
in the form of implementing Q.931 SERVice / SERVice ACK messages.
http://bugs.digium.com/view.php?id=3450

I too would love to see this working. I manage a pool of IVR servers
that get hammered pretty hard... if * had this ability, I could write a
script that would start busying out channels if load averages got too
high, allowing calls to hunt to another server.

Josh McAllister

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-
> bounces at lists.digium.com] On Behalf Of Imran Ahmed
> Sent: Friday, October 27, 2006 9:42 AM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] Re: How to busy out PRI channels?
> 
> Freddi,
> I was thinking of a solution on similar lines. In your scenario, after
> 180 seconds were you able to reset the channel back to normal
> dynamically, without having to reset the whole pri line?
> 
> Thanks,
> Imran
> 
> On 10/27/06, Freddi Hansen <fh at danovation.dk> wrote:
> > >
> > > 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
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev