[asterisk-users] ISDN PRIs and taking a server down formaintenance - blocking issue

Fri Feb 15 08:42:40 CST 2008

Yes the 'stop gracefully' is what effectively blocks the calls as the telco
seems to take it as we are answering the calls instead of seeing them as
busy.

I will look at implementing some sort of way of busying out all the zaptel
channels, so that we eventually busy out all 120 channels (4x E1) and then
can cleanly take the server offline while our telco presents the calls to
the next Asterisk servers correctly.

This would be a great way of busying out the server for maintenance while
still allowing our inbound calls.

Many thanks,
Andrew

  _____  

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Brent Davidson
Sent: 15 February 2008 00:30
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] ISDN PRIs and taking a server down
formaintenance - blocking issue

Correct me if I'm wrong, but as I understand it your issue is that when you
give Asterisk the "stop gracefully" command it waits until all active calls
have finished before it takes the ISDN down but gives busy signals to new
incoming calls on idle channels.  If this is the case then it would seem
that Asterisk is actually answering the call on the incoming channel and
playing a busy signal.  From reading a couple of threads on another list it
appears this is the case (Google: Asterisk "busy out" PRI to find the
discussion).  There also appears to be some interest in making a function do
what you need in the future.

For the time being, however, a simple solution would be to create a
temporary dial-plan that follows each outgoing hangup with a "dial" command
to either a test number or some other service that will just keep playing
audio down the line and not hangup.  (You'd probably need to set some
variable to know which channels had been "busied") When you need to take
down a server, load this dial plan and wait for all channels to call the
"busy" number, then hang them all up and issue a "stop now".

It's a messy solution, but it's all I can think of without hacking code.
The only other way I'd know would be to hack the code for the dial or answer
command and build another command that simply takes the channel off-hook and
leaves it there.

Good luck,
Brent Davidson

Lyle Giese wrote: 

If you take Asterisk down, the PRI should go down as the D channel is down.
Then the telco should KNOW that there is trouble with the PRI and those
channels are in trouble busy and not availible.  If the telco still tries to
push a call to a channel on a PRI that is down, then the telco is at fault.

Lyle

Matt wrote: 

That does sound like what is happening.. Telco knows channel 1-23 are not
busy (so far as they are concerned), however.. so far as you are concerned,
they are busy.. so telco sends the call down... but the equipment doesn't
take it.

I would *think* the Telco could keep trying channels down the hunt group,
but maybe not?  We have, in the past, seen this issue with our dial-up modem
banks.. especially if I would take one offline.   However, it is not a big
enough issue (i.e. we don't take things down that often) for me to look into
it fully.

On Thu, Feb 14, 2008 at 4:07 PM, Don Kelly <dk at donkelly.biz> wrote:

I think the problem is that the telco presents the call on a specific
channel, then zaptel tells it that the channel is busy.

We need to be able to tell the telco that each unused channel on a given
span is unavailable, and it will determine that the others are in use and
will present the call on a channel on another span.

A rather ugly work-around (since Andrew seems to have lots of channels
available, and one would assume that maintenance of this nature would occur
during slow periods) would be to make calls to a DID in the same trunk group
on all "idle" channels on the span shutting down then, when all channels on
the span are "in use" and none of them are doing anything useful, take the
span down hard so the telco will divert all calls to another span.

  --Don

Don Kelly
PCF Corp
Real Support for your Virtual Office TM
651 842-1000
888 Don Kell(y)
651 842-1001 fax

  _____  

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Matt
Sent: Thursday, February 14, 2008 2:28 PM 

To: Asterisk Users Mailing List - Non-Commercial Discussion

Subject: Re: [asterisk-users] ISDN PRIs and taking a server down
formaintenance - blocking issue

Honestly.. this sounds like a telco issue.    I understand what the other
person is saying about the PRI still being technically up... BUT... if the
channel is BUSY/BLOCKED/WHATEVER, the Telco should be forwarding the call to
the next available channel, which they clearly are not doing.

On Thu, Feb 14, 2008 at 8:29 AM, Andrew Smith <andrews at meadeplc.com> wrote:

Hi Tim,

Imagine the scenario where we had 10x Asterisk servers, with calls
presenting sequentially starting from the first server, then server two,
etc.

If we took down the first server for maintenance with 'asterisk -rx stop
gracefully' we then will block all incoming calls to all servers as our
telco will simply relay the BUSY back to the caller. If there are a number
of calls on the first server that continue for another 20 minutes, then all
inbounds are blocked for that period of time.

We are finding at present we have to look at the calls on the server and
make a decision if we are busy to simply reboot the server and hence lose
calls. Not ideal but then we don't end up blocking our inbounds.

What I was hoping to do was find a way to cause the telco to present the
call to the next ISDN30 and therefore would allow us to cleanly take down an
Asterisk server for maintenance without causing this issue. In a sense to
put the ISDN30 into alarm mode while still continuing the active calls.

Do you know if this is at all possible, even if we considered patching
zaptel to add this functionality or does the telco rely on the entire PRI
being in alarm before it presents the call to the next ISDN30 ? This would
allow us to run maintenance on our servers during busy periods without
causing disruption, and would be an excellent feature.

Many thanks,

Andrew

  _____  

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Tim Nelson
Sent: 13 February 2008 18:12
To: Asterisk Users Mailing List - Non-Commercial Discussion
Cc: asterisk-users at lists.digium.com
Subject: Re: [asterisk-users] ISDN PRIs and taking a server down for
maintenance - blocking issue

Even if * is shutdown, zaptel is still running and your ISDN channels are
still technically up. Shutting down zaptel should close the channels and put
those circuits into alarm mode.

Tim Nelson
Systems/Network Support
Rockbochs Inc.
(218)727-4332

----- Original Message -----
From: "Andrew Smith" <andrews at meadeplc.com>
To: asterisk-users at lists.digium.com
Sent: Wednesday, February 13, 2008 12:03:51 PM (GMT-0600) America/Chicago
Subject: [asterisk-users] ISDN PRIs and taking a server down for maintenance
- blocking issue

Hi there,

I currently have multiple Asterisk servers using Sangoma A104d Quad ISDN
E1s.

Basically our telco is presenting calls in order of the ISDNs on our
servers.

SERVER1=1,2,3,4
SERVER2=5,6,7,8

We have redundancy in that if SERVER1 is shutdown then each ISDN PRI is in
alarm and the calls will then presented to PRIs 5,6,7,8 on SERVER2.

If I have to take SERVER1 offline for maintenance (asterisk -rx shutdown
gracefully) any incoming calls receive a BUSY tone.

What I would like to know is if there is anyway to get around this and not
send a BUSY back to our callers and somehow allow our telco to present calls
immediately to SERVER2.

Anyone have any ideas or are we stuck with this behaviour until the calls
drop to 0 and Asterisk shuts down ?

Thanks,
Andrew

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

  _____  

_______________________________________________

-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list

To UNSUBSCRIBE or update options visit:

   http://lists.digium.com/mailman/listinfo/asterisk-users

  _____  

_______________________________________________

-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-users mailing list

To UNSUBSCRIBE or update options visit:

   http://lists.digium.com/mailman/listinfo/asterisk-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080215/9089fede/attachment-0001.htm 