Incoming calls from other office extensions ring once and go directly to VM

[Frank86]

Started happening today with a bunch of our 3CX users.
Any idea of what might cause the issue.
Users are on the latest 3CX version on local W10 PC. Everything has been working great till today.

 

[leejor]

What does the Activity Log show, for the extension status, when a call attempt is made? Do outside callers (DID, IVR, or transfers), also go direct to voicemail?

 

[Frank86]

It only happened with internal extensions called by a 3CX user using a STUN extension.

Activity log shows
[CM503003]: Call(C:361): Call to <sip:{ext}@127.0.0.1:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5483

 

[leejor]

Which sets are using STUN, the ones that are calling, or the ones you are trying to call? The log you posted does not even show an IP of a set, just the loopback IP of the host. How many STUN sets are you using? Are they all at one location?

Check the to see if 3CX even sees them, as currently being registered.

 

[Frank86]

The set using STUN is the one calling and going to VM after one ring.
One STUN set and that's the one reporting the problem.
Yes, 3CX sees it as being registered.

 

[leejor]

So.. one set, that is using STUN , is unable to call any other extension? Is that correct? Are the set(s) they are calling , local to the PBX, or also using STUN? Are they able to place outside calls? Calls to the 3CX echo test, calls direct to Voicemail (999)?

 

[Frank86]

Sorry for the confusion. Yes, one STUN set was sent to VM on three outgoing calls to other extensions inside the org. Two of the called sets are local to the PBX, the third was a 3CX iPhone app. All sets (including the STUN one) are able to call external numbers, VM, and internal extensions as well. The problem happened three times only, all with internal extensions and from the same STUN set.

 

[leejor]

If that set is able to place outgoing calls, with no issue, then I would suspect that it has something to do with the status of the extensions they are attempting to call. Either, the destination was not registered at the time, or, had DND enabled, or, were perhaps using call forwarding, that did not succeed. If they can replicate the issue, capture the complete Activity Log from the first Invite, that they sent.

 

[Frank86]

Makes sense. I told the STUN user to let me know as soon as she has the same issue, so I can check the logs.
Thank you for your help.