D Series Phones Get busy tone on initial dial attempt


FreePBX Distro 15
Asterisk 16.2
D40, D62 series phones

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.


Thanks for the reply.

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.

ARP cache is an interesting theory.

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.

User reported that after a day the P315 started just randomly rebooting itself so she put the D62 back in.

I’ve now replaced the network switch with a dif POE switch to test …

One thing that still bothers me here is in this network there are D40 and D62 phones. ONLY the D62 phones are having issues the busy on dial issues.

pjsip log of a failed attempt to dial:

<--- Received SIP request (1140 bytes) from UDP: --->
INVITE sip:[email protected]:5070 SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPjlo21K4iggxSfSbF8ZUFu8HlJEmarbmzt
Max-Forwards: 70
From: "Susan-202" <sip:[email protected]>;tag=Kj1HiOiQDbHB73jZpb7UZgVkwU5g6Tsi
To: <sip:[email protected]>
Contact: "Susan-202" <sip:[email protected]:5070;ob>
Call-ID: lc72WF-1H3FF7ydFv0nL9zoVUobaY6kn
CSeq: 22470 INVITE
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: Digium D60 2_9_16 000FD30A7A6F
Content-Type: application/sdp
Content-Length:   475

o=- 330281429 330281429 IN IP4
t=0 0
m=audio 4000 RTP/AVP 0 8 9 111 58 118 58 96
c=IN IP4
a=rtcp:4001 IN IP4
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:58 L16/16000
a=rtpmap:118 L16/8000
a=rtpmap:58 L16-256/16000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ssrc:1604741885 cname:5ea46284751eca91

<--- Transmitting SIP response (567 bytes) to UDP: --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP;rport=5070;received=;branch=z9hG4bKPjlo21K4iggxSfSbF8ZUFu8HlJEmarbmzt
Call-ID: lc72WF-1H3FF7ydFv0nL9zoVUobaY6kn
From: "Susan-202" <sip:[email protected]>;tag=Kj1HiOiQDbHB73jZpb7UZgVkwU5g6Tsi
To: <sip:[email protected]>;tag=z9hG4bKPjlo21K4iggxSfSbF8ZUFu8HlJEmarbmzt
CSeq: 22470 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1634910139/faf78b4e3184a483f1726613b858308a",opaque="150b25e406cef3d0",algorithm=md5,qop="auth"
Server: FPBX-
Content-Length:  0

<--- Received SIP request (392 bytes) from UDP: --->
ACK sip:[email protected]:5070 SIP/2.0
Via: SIP/2.0/UDP;rport;branch=z9hG4bKPjlo21K4iggxSfSbF8ZUFu8HlJEmarbmzt
Max-Forwards: 70
From: "Susan-202" <sip:[email protected]>;tag=Kj1HiOiQDbHB73jZpb7UZgVkwU5g6Tsi
To: <sip:[email protected]>;tag=z9hG4bKPjlo21K4iggxSfSbF8ZUFu8HlJEmarbmzt
Call-ID: lc72WF-1H3FF7ydFv0nL9zoVUobaY6kn
CSeq: 22470 ACK
Content-Length:  0

Could this be the issue?

The 401 is normal. Once the phone ACK’s the 401, it should follow with another INVITE including auth headers.

<-- 401 Unauth
ACK -->
INVITE (w/auth) -->
<--- 1xx (progress/ringing etc)
<--  200 OK (answer)
ACK  -->

OK, well that’s the entire PJSIP log from a failed call attempt. Do you see anything in there that would offer a clue?

I can reproduce the issue if I reboot the phone. Every time the initial call fails with a “failed” displayed and a busy tone.

Would a UDP timeout on the firewall potentially cause this issue?

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.