From: "Imran Ahmed" <[EMAIL PROTECTED]>
Subject: Re: [asterisk-dev] Re: How to busy out PRI channels?
To: "Asterisk Developers Mailing List" <[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/26/06, Tony Mountifield <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> John Todd <[EMAIL PROTECTED]> 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.
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
