To start off, here’s the basics about my system:
OS: CentOS release 5.7 (Final)
Asterisk: 1.8.11.0
FreePBX: 2.11.0.24
Phones: 1x Polycom SPIP650 running 4.0.2, many Cisco 7940G on SIP 8.12
I have two issues which are basically the same problem happening in different places.
First, and more importantly as far as the PBX users are concerned, calls coming in to our queues are sometimes ringing agents for only 1-2 seconds before the PBX decides to send a SIP CANCEL message. It doesn’t go on to ring other phones at that point, the call just floats in limbo until the queue retry timeout.
Here is a small snippet of the log for an example of this, unfortunately this PBX has a decent amount of volume so sanitizing a larger piece of it for public viewing is tricky.
Here’s the timeline though:
11:25:53 - Call comes in on main line, rings receptionist
11:25:59 - Receptionist answers
11:26:12 - Receptionist transfers call to queue, queue begins ringing x2459.
11:26:42 - x2459 times out as expected after 30 seconds, queue begins ringing x6106
11:26:44 - For whatever reason, the PBX decides it’s already been 30 seconds (see line 9 of paste), sends CANCEL to x6106.
11:27:31 - Queue retry timer expires after 45 seconds, call starts over at x2459.
11:28:01 - x2459 times out after 30 seconds, queue rings x6106
11:28:03 - Again, queue decides two seconds and 30 seconds are the same thing, inappropriately CANCELs x6106.
Repeat until x2459 answered the call five minutes later.
This happens with both leastrecent and fewestcalls ring strategies so far, not sure about others. Agent timeout is set to 30 seconds, retry is 45 seconds, skip busy agents is Yes, everything else is default.
The second issue is similar, but does not involve a queue. For some reason random direct calls will only ring at the phone for a fraction of a second, then they ring back through a bit later. This happened when I was calling one of the users at this location, and the full log from that call is in this paste:
Line 132 is where it starts ringing and then immediately fails out with a “non-zero” error that isn’t really helpful to me. Our trunk provider then retries the call since it wasn’t answered properly and the second time it goes through fine as you can see.
I have full SIP captures of both of these events as well, but obviously I can’t post those publicly. I will provide them to any FreePBX staff privately if desired.