[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