Phone shows a missed call, customer claims it didn't ring

[Mike Hammett]

In what world does this make sense?

The customer is claiming that their phones aren't ringing... sometimes. Sometimes they ring, sometimes they don't.

Their phone shows a missed call, so clearly, the call is making it to the phone.

How could all phones in an office ring, but not make any sound and do so intermittently?

 

[JohnS_3CX]

Hi Mike,

Since the local call log exists solely on the device, then it's pretty clear that the device received the call.

Can you give some more info? Version? Phone models? Firmware edition? Call flow for detecting the source?

 

[Mike Hammett]

3CX version 16.0.493
The phones are all Yealink SIP-T41S on firmware 66.84.0.95.

The inbound rule points to a ring group.
The ring group is set to Ring All for 10 seconds.
If no answer, the call is forwarded to an outside number.

 

[Clément Rousseau]

What is the context ? Is it possible that when call have been made, user was on the phone ? How are the calls logs in 3cx ?

 

[Alphabetic]

Are phones LAN / SBC / STUN

 

[Mike Hammett]

What is the context ? Is it possible that when call have been made, user was on the phone ? How are the calls logs in 3cx ?

There are five office phones. It seems unlikely that they'd all be on the phone each time it happened. I'm currently looking at an export of the call log to see if any of the occurrences match up with already being on a call.

Are phones LAN / SBC / STUN

STUN

 

[Alphabetic]

Have you given each phone a static IP and specified their local SIP/RTP Ports and are port forwarding to each?

1) In the Management Console each Remote STUN Extensions must have a unique Local SIP Port and Unique RTP Port range and the RTP Port range must be 10 ports (for Yealink phones 12 ports, you do not currently have it this way) per remote site. This means that if we only had Yealink phones that would be e.g.:


- Ext A should have Local SIP Port: 5065 and RTP Port Range: 14000-14011 (12 ports)

- Ext B should have Local SIP Port: 5066 and RTP Port Range: 14012-14023 (12 ports)

- Ext C should have Local SIP Port: 5067 and RTP Port Range: 14024-14035 (12 ports)

- Ext D should have Local SIP Port: 5068 and RTP Port Range: 14036-14047 (12 ports)

- etc...

You may benefit from an SBC on a Pi

 

[Mike Hammett]

Have you given each phone a static IP and specified their port local SIP/RTP Ports and are port forwarding to each?

Typically the phones are given DHCP reservations. It looks like there's something causing the phones to not be in the right VLAN, so they're not getting the right IPs, but they are getting AN IP and it's unlikely those IPs are changing.

No, I'm not defining ports for phones. I have a couple dozen PBXes with an aggregate of probably 100 phones. Admittedly, it's only about half 3CX at the moment. I've never had to screw around with ports.

 

[cobaltit]

Typically the phones are given DHCP reservations. It looks like there's something causing the phones to not be in the right VLAN, so they're not getting the right IPs, but they are getting AN IP and it's unlikely those IPs are changing.

No, I'm not defining ports for phones. I have a couple dozen PBXes with an aggregate of probably 100 phones. Admittedly, it's only about half 3CX at the moment. I've never had to screw around with ports.

The only 3CX supported scenario with STUN is to have port forwarding per the notes at the end of this document:

https://www.3cx.com/docs/manual/configuring-ip-phones/#h.ul2fzupi6t22/

The recommendation for more than a couple phones (we do SBC for almost all remote phones) is to use a SBC. Depending on your firewall of choice you may get lucky with STUN just working with no port forwarding but sooner or later it comes back to bite you. In this particular 3CX will tell you to follow the recommendation before further troubleshooting.

That being said, this doesn't sound like an issue caused by STUN with no portforwarding. Usually that manifests itself as either no inbound calls unless an an outbound call is made first or one-way audio issues. I'm wondering if this is a new customer and possibly a training issue? It will still show as a missed call on any phones in the ring group that didn't answer the call even thought it was answered by a ring group member. Is there any evidence of a call being completely missed such as going to the ring group no answer destination?

 

[Mike Hammett]

The only 3CX supported scenario with STUN is to have port forwarding per the notes at the end of this document:

I've mostly dispensed with that as a red herring. It's kind of like going to the auto parts store to get a light bulb, but the employee at the store needs to know if you have 2-wheel drive or 4-wheel drive to look up the part. I've been doing VoIP at least part-time for >15 years (although mostly on Asterisk) and I have never had a port forwarding\NAT issue that didn't manifest itself as you later described. I am new (1 year) to 3CX, so maybe it's a new shortcoming I need to learn.

I'm wondering if this is a new customer and possibly a training issue? It will still show as a missed call on any phones in the ring group that didn't answer the call even thought it was answered by a ring group member. Is there any evidence of a call being completely missed such as going to the ring group no answer destination?

It is a new customer, but I wouldn't think customer training would need to go down to the "This is what a ringing phone sounds like. When it rings, put this gadget to your face and talk. Then again, some people..." level.

The customer complained of calls going to the no-answer destination, which prompted the investigation. The first thought was that the phones weren't online, but they showed up fine in the management console. I sent someone on-site and they verified that the phones recorded a missed call. I took this to mean that the handset did receive a call, it wasn't answered, and then 3CX moved the call to the no answer destination.

From what I understood in my Googling, RingAll would only display a missed call if no one anywhere answered, but that Hunt Prioritization would display a missed call for every call that you personally missed. I understand the behavior changed in v15 SP1. I couldn't find official documentation that said that, so I could be wrong, but that's what I came up with.

I am assuming that if the phone wasn't connected to the PBX to have received the call in the first place that it also wouldn't have a missed call. Maybe that's some different signaling that I'm not used to. FWIW: E-mail notifications aren't flagging any unregistrations\registrations from this location (only mobile clients), so the connection must be at least that much stable.

 

[cobaltit]

I've mostly dispensed with that as a red herring. It's kind of like going to the auto parts store to get a light bulb, but the employee at the store needs to know if you have 2-wheel drive or 4-wheel drive to look up the part. I've been doing VoIP at least part-time for >15 years (although mostly on Asterisk) and I have never had a port forwarding\NAT issue that didn't manifest itself as you later described. I am new (1 year) to 3CX, so maybe it's a new shortcoming I need to learn.

I'm not saying you need to do it for things to work, Step 1 for 3CX support when something doesn't work and you aren't in a supported configuration, be it network design, custom template, etc is to revert to a 3CX supported configuration and test. I've not run into the issue you describe but we do practically zero STUN and none when there's multiple phones in a site. I'd throw a SBC in there just to see if that resolves the issue.

 

[JohnS_3CX]

Hi Mike,

Doing STUN without the recommended way introduces additional unknown variables, namely how your firewall will handle the requests and how the phone's firmware will react. It might work fine, or it might drive you insane by "appearing" to run fine (which is worse than not working at all if I may add).

A good way to build solid installations is to reduce such variables to a minimum. Just wondering if you will have better results using an SBC here and ensuring that SIP ALG is not active on your network. Grab a Pi 3B+ as an SBC and take it with you to use as a sanity check whenever you have to mess with NAT'd environments, VLANs, and firewalls that you have no control over. It may become best your friend

 

[Mike Hammett]

The problem "went away" when I was really investigating it. Hrm, so once I pointed out that there were missed calls on the handsets, the problem mysteriously disappeared.


I haven't gone much further down the SBC road because the first time I tried it, the phones wouldn't provision. I haven't done sufficient troubleshooting yet to figure out why they wouldn't. The SBC seems to just replace one set of problems for another set of potential problems.

 

[JohnS_3CX]

Strange, sometimes users will misreport the problems, but let's see how it goes.

As for the SBC, I think it would be too soon to judge it this way especially if you haven't spend enough time with it so you can compare. If you decide to use it we will be glad to help though

 

[Mike Hammett]

Regarding the SBC, sure. THat's why I make sure I add that caveat when I say it didn't work.

 

[JohnS_3CX]

Actually, that could be due to an incorrect network setup, ie. multicast is blocked and does not reach the SBC from the phones, or phones cannot reach the PBX on its HTTPS port. Those would be the first things to check.