Extensions can not receive incoming calls

[stephenbaugh]

Hello

We have a number (2 or 3) extensions that over the last week have some how become "locked", for want of a better word, and can not receive incoming calls.

Any incoming calls do not ring the extension, they go direct to voice mail. This is internal or external calls

The extensions are "available"

Out going calls work correctly

Configuration on these extensions is not set to send to voice mail when available.

My extension for example has worked perfectly for incoming and out going calls, but yesterday disconnected mid call and now can not receive incoming calls. It is as if the system sees me as busy, even though through the client I am "available" and not on a call.

I have tried sending new welcome messages and re-provisioning the phones, clients have been restarted and even reinstalled.

Has anyone else seen this behaviour and can you provide a solution?

Product: 3CX Phone System Professional Edition
Version Number: 15.5.5

Thanks
Stephen

 

[Vali_3CX]

I encountered this behavior in the following case:

- extension is NOT configured to accept multiple calls (this is default configuration for an extension) but it has two (or more) devices, of which one is set on DND (very important: do not mistake extension's DND with device's DND).

In this case, the incoming call to the extension "rings" both devices, the one on DND automatically drops it with 486 and call is directed to the voicemail (extension's default configuration) and the other device stops ringing because extension allows only one call.

My suggestion is to see if extension is configured to accept multiple calls - if not, enable it, then try again. If it works, then try to find the device on DND.

Hope it helps.

 

[stephenbaugh]

Thanks Vali

It wasn't this problem, but on reviewing I noticed that the setting "Use 3CX Tunnel for remote connections (3CX Client only)" had re-enabled. Not sure how as we had this disabled previously for similar issue.

Anyway, our 3cx server is in the data centre on subnet 192.168.10.x, vpn connections 192.168.20.x and local (client user) network 192.168.1.x

We would like tunnelling enabled so that users outside of the network can use 3cx without VPN, but when this is enabled it seems that v15 gets confused. We've never been able to get to the bottom of why this config issue exists but it maybe related to the fact that the provider has a secondary interface on the 3cx server providing access to their SIP gateway.

Hopefully I've made myself clear, do you have any thoughts on this?

Thanks
Stephen

 

[leejor]

What type of sets are you using, that are having this issue? The tunnel options is not used by any phone other than 3CX devices (softphones/Apps). Only they,( or an SBC) are capable of using the 3CX Tunnel.

 

[stephenbaugh]

We are only using 3cx soft phones, Mac, Windows and iOS.

It seems to be the Mac, but possibly also the iOS devices that have the issue when on the the 192.168.1.x, macs connected my ethernet, iOS by wireless.

Thanks

BTW I remember the original issue with this setting was that the devices would not register at all when on the 192.168.1.x network if "Use 3CX Tunnel for remote connections (3CX Client only)" is enabled. It seems they now register but incoming calls to the client go straight to voice mail.

 

[Vali_3CX]

If is for MAC, then it's OK, because there I can assist you.

However, before that, my advice is to have a look in the PBX Management Console/Activity Log (best to set it to Verbose) when the call is made - there should be the best place to view why the call is directed to the voicemail.

Apart from this, from the MAC, try to call the "Call Back service" (*888) to see if it's - obviously - called back by the PBX.

Yesterday I was thinking - there is another normal "anormal" case for this behavior: when there is a contact registered to that extension, but no physical device present. Take a registered hardphone - which usually has a registration timeout of 30 minutes - and unplug its network cable, then make a call to it: the caller will be redirected to voicemail. However, there is a significant difference in behavior compared to the DND case I mentioned earlier: in the DND case, the caller is redirected to voicemail immediately, because it was dropped with 486; in this case, the caller will be redirected to voicemail after 20sec - 1 min of ringing (the "No answer timeout" extension parameter).