FreePBX Distro 15
Asterisk 16.2
D40, D62 series phones
EPM with DPMA
I’ve had this issue crop up in a few sites. It’s worse with the newer D series phones (D62/D65’s). Everything seems fine but after the phone sits unused for a while and the user goes to dial out, by dialing the number then pressing the dial button, the phone display show’s the call is on “hold” and they get a busy tone.
Hang up, dial again and the call goes through.
It seems like the phone loses connection with the PBX but when looking at the dashboard no indication of phones dropping is every shown. Also, the phone rings every time on inbound calls.
Other issues also occur like not being able to retrieve the voicemail list or parked call list randomly.
Interestingly, the D40 phone in the office does NOT have these issues. If it were a network issue I’d expect all phones to display the behavior.
The PBX is on a Vultr VM and there is a site to PBX VPN set up using Strongswan between the office router/firewall and the FreePBX system. Running MTR from the PBX to the public IP of the office Route I see no packet losses and ping times hover around 12ms.
Offhand, no; run the latest firmware, because it’s always got the least bugs; the call control stacks and the phone stacks themselves are the same/so similar that it’s unusual that one model would behave any differently from any other model. I’m not able to investigate/troubleshoot/triage your issue, sorry.
They are already on the latest firmware, I usually do all the obvious stuff before posting.
I get that you aren’t able to investigate/troubleshoot/triage this issue but this isn’t the first site/system I’ve experienced this with and the sites are different network equipment/designs so I doubt it’s a local issue. I’ve opened tickets for this in the past and they’ve just said “sorry, it’s your network…” but I don’t think it is as I’ve experienced it in different locations with different setups. The only constant is D series phones… I would imagine Sagoma would be interested in looking into it no?
I don’t know the specific answer to your problem, but the fact that it fails once then works on the second try leads me in the direction of a spoiled ARP cache or a problem with your NAT configuration losing an association until “something” causes it to fix the problem. If either of those is true, then “your network” might be the problem.
The fact that you aren’t the first person to report this really does lead me in the direction of something in your network is not responding in a timely fashion. If it was me, I’d probably start with some PJ-SIP debugging and see what is happening in the calls as they fail. Also, don’t assume that the problem is with the remotes - you imply that it happens on several legs of (I’m guessing) your VPN setup. If that’s the case, the problem may well be in the central service area, since common mode failures like this aren’t always where they appear.
did you mean “the fact that you ARE the first person???”
otherwise that statement makes no sense…
I would tend to agree that it’s the network EXCEPT for the fact that I’ve had this issue, intermittently, at different unrelated sites…
Those sites have different network equipment, different internet providers etc… So it being a network issue, while certainly not impossible, is unlikely. The common denominators are the D series phones and specifically the D6x level.
Replaced the offending D62 phone with a P315 today. It didn’t display any of the bad behavior that the D62 was for the time I was there testing. I’ll report back after the user has it for a few days to see if it continues to be problem free.