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

Brent Davidson brent at texascountrytitle.com
Fri Feb 15 15:11:34 CST 2008


You got me interested in this topic so I started doing some research.  
There is a discussion on the asterisk-dev list about adding true busy 
support to the Zaptel module.  As it currently stands, when a call comes 
in on a PRI channel while asterisk is shutting down asterisk sends a 
signal back effectively rejecting the call, but the Telco sees it as 
Asterisk answering the call.  What needs to happen is a mechanism needs 
to be implemented that will place the the channel in the off-hook state 
after the active call hangs up until the PRI can be truly taken down.  
I'm not a coder so I have no idea how to begin implementing that, but I 
suspect it would not bee too difficult for a coder to go in and take a 
couple of the pieces of code that answer or dial on channel and make an 
"hook state" function.

-Brent

Andrew Smith wrote:
> 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 
>>> <mailto: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>
>>>     [mailto: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 <mailto: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>
>>>     [mailto: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
>>>     <mailto: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
>>>     <mailto:andrews at meadeplc.com>>
>>>     To: asterisk-users at lists.digium.com
>>>     <mailto: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
> ------------------------------------------------------------------------
>
> _______________________________________________
> -- 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/4d6a6612/attachment.htm 


More information about the asterisk-users mailing list