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

Thu, 14 Feb 2008 16:38:01 -0800

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 <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> 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:* [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    [mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>] *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
    <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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:* [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>
    [mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>] *On Behalf Of
    *Tim Nelson
    *Sent:* 13 February 2008 18:12
    *To:* Asterisk Users Mailing List - Non-Commercial Discussion
    *Cc:* asterisk-users@lists.digium.com
    <mailto:asterisk-users@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" <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>>
    To: asterisk-users@lists.digium.com
    <mailto:asterisk-users@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

_______________________________________________
-- 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





















					Reply via email to