Asterisk is a phenomenal open source phone system I have used and managed for many years. Recently I was presented with two issues a few weeks apart that had the same cause, but different symptoms.
Problem
In the first, a phone would simply ring directly to voicemail. In the second, a series of strange behaviours would occur, causing the overall system to misbehave. Calls would be picked up before a human could answer and would present the caller with music, but ultimately would go nowhere, frustrationg everyone. The linux box would begin to show signs of high load averages, leading to new issues.
When using the Asterisk CLI to show the current calls, I noticed a lot of phantom calls that I had not seen before, nor could I find answers via google.
The cause of both were a few mistyped keys turning on call forwarding. In both situations, you could not tell by looking at the SIP phone (Polycom 501 and 601). It's forwarding display showed no forwarding was enabled and I made certain that there was no forwarding destination typed in regardless.
The cause was dicovered through studying the logs. I found this:
Feb 3 09:25:03 VERBOSE[27828] logger.c: dialparties.agi: Extension 200 has call forward on busy set to 0
Meaning that in this case, extension 200 was forwarding to a number/extension 0 when it was busy. That extension is nonexistent.
The logs were filled with phantom calls to
Local/0@from-internal....
When suspicious that this (forwarding) could be occuring, search the logs for the phrase has call forward on.
There are two ways to turn call forwarding on:
- Using the phone function keys.
- Using the phone system feature codes.
In this case, the phone has a function/button called "Forward" that starts the process, but my phones were all clear here...adding to the difficulty in troubleshooting the problem.
Solved
The solution to the issue was to use the phone system "Feature Codes":
*72 — Call Forward activate
*73 — Call Forward deactivate
*90 — Call Forward on Busy activate
*91 — Call Forward on Busy deactivate
I needed to have someone use the deactivate codes on the phone itself to end this behaviour. Since the phone itself reported that no forwarding was enabled, this was the only other option...then test.
One thing to note is that if a loop develops ( where a phone is called and the phone then forwards the call to a ringroup where the same phone is a member and is now called again .... the loop starts ), that the cycle will sap the resources of the best systems.