A couple phones will fail the first outbound (internal or external) attempt with a fast busy. If the call is attempted again in a short period of time, it succeeds. There is nothing written to the log for the failed attempt, but the success writes as normal. This was happening with one phone, but after an extension password change, a second phone is also experiencing this.
There are other threads (here, other forums) about having to dial twice, but none of them seemed to match exactly my scenario.
I’ve poked around and can’t seem to find any places where configs differ per phone/extension. Any ideas on where else to try?
OK, there are a couple of things in here that are clues. Up front - I don’t have an answer for you yet, but here’s how I’d start:
You say that you are getting a “fast busy”. I don’t know that the system ever generates a fast busy to an extension. Normally (at least, in my experience), this comes from the remote end of a trunk. If you are getting a 120-busy from the PBX, it would be the first time I’ve ever seen it.
You say that “nothing” gets written to the logs. Tell me more about this “nothing”. If you really mean that the server doesn’t acknowledge the call, it’s an interaction between the phone and the network. If that’s the case, maybe your 120-busy is actually coming from the phone - since it’s Avaya (the old Ma Bell) they might generate the 120-busy when there’s a problem connecting to the server.
The fact that it fails on the first try and succeeds on the second implies something spooky - a bad DNS look-up, a timeout in the network, something like that. The addition of the PIN for the phone IS intriguing - maybe there’s something in the registration when the PIN is used that is jamming you up?
I’m starting to look into it as just the phone itself. After poking at some Avaya specific forums, there’s some tools available to trace from the station/phone, but as I’m not on an Avaya back end, I don’t believe I have access to them.
By “nothing”, I mean the server doesn’t acknowledge the call. Referring to the “full” (/var/log/asterisk/full) Asterisk log.
DNS was one of my initial thoughts when I started looking in to this, but they primary and secondary servers are configured the same as the other/working phones, and I’m referring to the server by IP, not hostname. I’ll see if I can figure anything else out about registration (faliing/dropping?), but from what I can see it’s working properly.
I haven’t looked at this in a bit, but yesterday I had to kick FreePBX since the host machine was in an unhappy state. When everything came back up, I went back to test all of the phones and learned a little more.
None of the Avaya 9608 have the fast busy (120) issue, but all of the 9650C do.
This leads me to believe that something in the config file is off, but since I’ve not changed anything there, it’s a bit weird that this was a sporadic issue that now affects all of the 9650’s.
which password are you removing? the sip secret? try booting the phone, watch it register, as soon as it registers try a call. assuming the call works, hang up and wait 2 minutes and try another call. Do you get a busy?
@bksales – Correct, the SIP (extension) secret. Booting the phone, and dialing just after it registers fails (fast busy). I waited two minutes, and the call (same number) succeeded. I waited another two minutes and the call failed.
did you happen to notice after the second failed attempt whether the phone was still registered? what i suspect is that you have a network issue that is closing udp sessions. are your phones local or remote?
I’m experiencing the same thing after moving older D series phones from FreePBX 15 to 16.
Exact same symptoms as the OP reported. I’m running the PBX on a cloud server and have a PBX to site IPSEC vpn set up between the PBX and the local firewall. Same setup and equipment (except the new pbx vm) as prior when the problem didn’t exist.
I set up a second vpn between the PBX and my office and configured an older D series phone to test. It doesn’t reproduce the issue which leads me to believe it’s a local network issue at the client.
My next step will be to bring this test phone onsite and see if it starts doing the behavior.
I’ve had this at one other site with different network hardware, different ISP. Only thing similar was the mixed use of older (D40) and newer (D62) D series phones. Couldn’t figure it out and lost that client because of it.
Because the only thing that changed in the current situation was the PBX and vpn (connected to new pbx), I suspect it’s a setting on the PBX and not the local network.
Phones never show unregistered, always seem to receive calls fine. Just fail on outbound with a busy on first attempt randomly (nothing shows at all in the asterisk logs for the failed attempts).
UPDATE:
Brought test phone that worked fine in my office to the location, plugged it in and tested. It did NOT display the behavior. Swapped the test phone for an extension that was having the issue in FreePBX. Factory reset it, let it boot and get it’s new extension properties. Now the test phone that was working fine, displays the behavior.
UPDATE2
Brought the phone I replaced with the test phone back to my office. Factor reset it and let it provision. It no does the same behavior in my office.
So I’ve removed the local network from the equation as my office has a completely different setup with different router and ISP. That leaves the VM setup and/or FreePBX as the cause…