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

[Imran Ahmed]

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
>