[Home]

Summary:ASTERISK-10567: Calls Looping back into call groups cause confusion or overload.
Reporter:Russell Brown (ruffle)Labels:
Date Opened:2007-10-18 08:11:52Date Closed:2007-12-05 17:04:47.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/PBX
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If one has a call or ringing group implemented by a Dial command:

exten => 140,1,Dial(SIP/112&SIP/113&SIP/116)

and one of the SIP phones in that Dial command sets call forwarding to the group exten (ie SIP/113 sets call forward always to 140), then any calls to the group (140) results in multiple calls taking place that (with enough phones involved) can bring the entire Asterisk system to its knees.

There are similar problems with queues getting deluged by these looping calls.


****** ADDITIONAL INFORMATION ******

I keep telling my clients users not to do this but they used to do it with their old Avaya system and in some circumstances they do have a need for it.

If it's of interest the circumstances are:

Each User in the ringing group or queue has a DDI.
When the user is off for the day, they want to direct their calls into
the ringing group or queue so that incoming calls will be handled by others
in their team.
Comments:By: Mark Michelson (mmichelson) 2007-10-25 17:42:25

Hi, I have set up a development branch which has a fix for this problem. The branch is located here:

http://svn.digium.com/svn/asterisk/team/mmichelson/forward-loop/

This branch was made off of 1.4, and has a solution in place for preventing call-forwards from looping as you have described in your report. Please test and see if this fixes your problem. If you have any problems while running it, please post them here!

Edit: I've fixed the link to the branch for Mark :) /blitzrage


By: Leif Madsen (lmadsen) 2007-10-29 15:21:27

I've tested this and it works for me as expected based on the input from the original bug poster.

I haven't tried this with a Queue.
By: Leif Madsen (lmadsen) 2007-10-29 15:24:40

Ideally, if someone can test this in their production environment to make sure this doesn't cause bad things in a complex dialplan, that would be ideal.

Thanks!
By: Leif Madsen (lmadsen) 2007-10-29 15:25:35

This is ready for testing in a more complex environment. This has been confirmed to work in a simple setup which isolates this issue.
By: Russell Brown (ruffle) 2007-10-30 07:53:23

Well it's kind of an improvement :-)   I've been testing on a smallish system before I unleash things on a 100 user site - kind of glad I did :-;

Here's a simplified Dialplan.

exten => 202,1,Dial("Sip/116&Sip/112&Sip/114",20,wkt)
exten => 202,n,NoOp(DIALSTATUS was ${DIALSTATUS})
exten => 202,n,Playback(why-no-answer-mystery)
exten => 202,n,Hangup

With no SIP forwarding set, dialing 202 from a.n.other phone rings Sip Phones 116, 112 & 114 as expected for 20 seconds then the caller hears the "why-no-answer-mystery" recording. Great; that's as expected.

Setting SIP/116 to "Call Forward Always" to 202 and calling 202 from a.n.other phone, causes the Dial to generate 'half' a ring on the phones, the DIALSTATUS of the original call returns "CHANUNAVAIL" and the caller immediately gets the "why-no-answer-mystery" announcement.

That's not good :-(

Here's the console output from such a call (Sip/116 forwarding to 202):


asterisk*CLI> set verbose 10
Verbosity was 0 and is now 10
   -- Executing [202@from-sip:1] Dial("SIP/117-b4c32fd0", ""Sip/116&Sip/112&Sip/114"|20|wkt") in new stack
Extension Changed 116 new state Ringing for Notify User 112
   -- Called 116
   -- Called 112
Extension Changed 114 new state Ringing for Notify User 113
Extension Changed 114 new state Ringing for Notify User 112
   -- Called 114
   -- Got SIP response 302 "Moved Temporarily" back from 192.168.1.23
   -- Now forwarding SIP/117-b4c32fd0 to 'Local/202@from-sip' (thanks to SIP/116-00719fd0)
Extension Changed 116 new state Idle for Notify User 112
   -- Executing [202@from-sip:1] Dial("Local/202@from-sip-dc77,2", ""Sip/116&Sip/112&Sip/114"|20|wkt") in new stack
 == Everyone is busy/congested at this time (0:0/0/0)
   -- Executing [202@from-sip:2] NoOp("Local/202@from-sip-dc77,2", "DIALSTATUS was CHANUNAVAIL") in new stack
   -- Executing [202@from-sip:3] Playback("Local/202@from-sip-dc77,2", "why-no-answer-mystery") in new stack
   -- Local/202@from-sip-dc77,1 answered SIP/117-b4c32fd0
   -- <Local/202@from-sip-dc77,2> Playing 'why-no-answer-mystery' (language 'en')
Extension Changed 114 new state InUse for Notify User 113
Extension Changed 114 new state InUse for Notify User 112
   -- Executing [202@from-sip:4] Hangup("Local/202@from-sip-dc77,2", "") in new stack
 == Spawn extension (from-sip, 202, 4) exited non-zero on 'Local/202@from-sip-dc77,2'
 == Spawn extension (from-sip, 202, 1) exited non-zero on 'SIP/117-b4c32fd0'
asterisk*CLI> set verbose 0
Verbosity is now OFF

(the subscription notifications got upset as you can see; 114 was not InUse)


I also did some playing with Queues with this forwarding in place and noticed that each time the queue made it's periodic announcement, the "calls taken" count for SIP/116 (as shown by CLI> show queues) incremented by one. I guess that was caused by each iteration through the forwarding loop.

So, even though these changes stop the 'call storms' it's not a fix. Sorry :-(


By: Mark Michelson (mmichelson) 2007-10-30 15:48:22

ruffle and blitzrage:

Thanks for testing this. I will look further into why this causing an issue and try to have a resolution as soon as I can.
By: Digium Subversion (svnbot) 2007-10-30 18:08:00

Repository: asterisk
Revision: 87741

U   team/mmichelson/forward-loop/apps/app_dial.c

------------------------------------------------------------------------
r87741 | mmichelson | 2007-10-30 18:07:59 -0500 (Tue, 30 Oct 2007) | 6 lines

To prevent subsequent priorities from being attempted after a Dial that attempts
to only ring already dialed interfaces, we need to return -1.

(related to issue ASTERISK-10567, reported by ruffle)


------------------------------------------------------------------------
By: Mark Michelson (mmichelson) 2007-10-30 18:10:29

Thanks to some great help from qwell, I was able to fix the "half ring" problem you experienced (revision 87741). Next I will deal with the queue problem you mentioned.
By: Mark Michelson (mmichelson) 2007-10-30 18:32:05

ruffle:

I'm not 100% sure of it, but I think the fix for the half-ring also fixed the queue problem you mentioned (assuming you still have the same forwarding rule applied to SIP/116 as you do in your first test). I tried to reproduce and could not successfully. If it is still a problem, could you post your sample dialplan that you use for testing queues? Thanks.
By: Russell Brown (ruffle) 2007-10-31 08:31:53

Initial testing looks good (both the Dial and Queue seem to work well) - thanks for your effort.

I'll roll it into a live (albeit modestly sized) system and report back in a few days.

Are you planning on producing a patch for 1.4.13 or will this make it into 1.4.14?


By: Mark Michelson (mmichelson) 2007-10-31 09:21:19

Thank you very much for the testing!

Assuming that there are no large problems encountered, this change will be merged into 1.4 SVN and would be in the next release after merging. If it is merged before 1.4.14 is released, then the fix will be in 1.4.14.
By: Olle Johansson (oej) 2007-11-13 02:25:26.000-0600

Why not catch the forward in the FORWARD_CONTEXT and handle it in the dialplan?

We do handle things like transfers and forwards in these contexts.
By: Mark Michelson (mmichelson) 2007-12-05 17:04:40.000-0600

I forgot to close this issue when I committed the fix on Monday. The fix is in revision 90735 of 1.4 and in 90873 of trunk.