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

[Matt]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080214/077365c6/attachment.htm