Available/NoAnsw Forwarded to 999

Status
Not open for further replies.

grinchprime

Customer
Joined
Mar 1, 2021
Messages
10
Reaction score
5
Not always but sometimes when someone calls ext. 107 and the person is on the phone, the call is being forwarded to our general VM 999. In 107 forwarding rules, there's not rules other than forward to VM.. And the VM is working fine and is not full. Why Am I getting this behaviour ?
Thank you,

Code:
06/03/2021 11:59:06 AM - [CM503025]: Call(C:3242): Calling T:VMail:999@[Dev:sip:[email protected]:5483;rinstance=6da633c51618a1e1] for L:3242.1[Line:10002<<5555555555]
06/03/2021 11:59:06 AM - L:3242.1[Line:10002<<5555555555] forwards call from Extn:107 to VMail:999 based on rule Fwd[Available/NoAnsw]
06/03/2021 11:59:06 AM - L:3242.1[Line:10002<<5555555555] failed to reach Extn:107, reason No Answer

2021-06-03 14_00_41-.png
 
the call is being forwarded to our general VM 999.
So, I assume that 999 is the number of the VM system, and that is where any call would forward when sent to voicemail. Are you saying that it is not going to the mailbox of the correct extension? If not, which mailbox (extension number) is it going to?
 
So, I assume that 999 is the number of the VM system, and that is where any call would forward when sent to voicemail. Are you saying that it is not going to the mailbox of the correct extension? If not, which mailbox (extension number) is it going to?
The call was supposed to go to user 107 VM but i don't know why it got transfered to another VM (in this case 999).
And the user 999 does not exist ..
 
999 is the number of the voicemail system, that is why it shows the call going there. Any call going to voicemail will go to the same destination. Which mailbox did the call actually go to, whose message did the caller receive?
 
Last edited:
To the operator mailbox (000) and it was supposed to go in 107.
The Operator is configured in the general settings as the "Operator Extension".

But I don't see any action that would redirect this VM to the operator..
 
Same thing just happened with user 125. His VM is working he got 3 VM today but this one got "lost"

Code:
06/07/2021 9:11:40 AM - L:5039.6[VMail:999] has joined to L:5039.1[Line:10002<<5555555555]
06/07/2021 9:11:40 AM - [CM503025]: Call(C:5039): Calling T:VMail:999@[Dev:sip:[email protected]:5483;rinstance=6da633c51618a1e2] for L:5039.1[Line:10002<<5555555555]
06/07/2021 9:11:40 AM - L:5039.1[Line:10002<<5555555555] forwards call from Extn:000 to VMail:999 based on rule Fwd[Available/NotReg]
06/07/2021 9:11:40 AM - L:5039.1[Line:10002<<5555555555] failed to reach Extn:000, reason Not Registered
06/07/2021 9:11:40 AM - [Flow] Call(C:5039): has built target endpoint: Extn:000 for call from L:5039.1[Line:10002<<5555555555]
06/07/2021 9:11:40 AM - [CM503010]: Call(C:5039): Making route(s) from Line:10002<<5555555555 to <sip:[email protected]:5060/UDP>
06/07/2021 9:11:40 AM - [Flow] Refer: RefTo=<sip:[email protected]:5060>; was call from=<sip:[email protected]:5060> to="7777777777" <sip:[email protected]:5060>
06/07/2021 9:11:23 AM - L:5039.5[VMail:999] has joined to L:5039.1[Line:10002<<5555555555]
06/07/2021 9:11:23 AM - [CM503025]: Call(C:5039): Calling T:VMail:999@[Dev:sip:[email protected]:5483;rinstance=6da633c51618a1e2] for L:5039.1[Line:10002<<5555555555]
06/07/2021 9:11:23 AM - L:5039.1[Line:10002<<5555555555] forwards call from Extn:125 to VMail:999 based on rule Fwd[Available/NoAnsw]
06/07/2021 9:11:23 AM - L:5039.1[Line:10002<<5555555555] failed to reach Extn:125, reason No Answer
 
The operator extension (or mailbox, if the extension is not registered), is the destination if someone presses *, thinking that action will take to someone who is actually at their phone. Perhaps that is what is happening.

If the operator extension is not actually used, you could consider having these calls route to a digital receptionist, allowing caller so choose another destination.
 
Last edited:
The operator extension (or mailbox, if the extension is not registered), is the destination if someone presses *, thinking that action will take to someone who is actually at their phone. Perhaps that is what is happening.
Great suggestion Leejor! I'll bet that is what is happening. I promptly recorded the DEFAULT VM message so that it would not read out " transfer to the operator, press *. Of course, the underlying call routing is there but at least the prompt has been modified.

As we start to migrate away from Cisco, I'm finding a few things, like this, that are not enterprise class. Another one that is very obvious to me is the lack of multi-line support, within 3CX, for our Yealink phones.

All in all however, this platform is a much more cost effective and easy to manage IPT platform.
 
Unfortunately, when people reach a voicemail, but are hoping to reach a person, they will try, what has worked on other systems, be this a 0, or *. Some systems will actually take you to another person, in the same department.
 
Really good suggestion ! Thank you very much ! :)
 
The operator extension (or mailbox, if the extension is not registered), is the destination if someone presses *, thinking that action will take to someone who is actually at their phone. Perhaps that is what is happening.

If the operator extension is not actually used, you could consider having these calls route to a digital receptionist, allowing caller so choose another destination.
Hmm, in General settings > Operator Extension, I can only choose a user extension and not an IVR extension.
 
Hmm, in General settings > Operator Extension, I can only choose a user extension and not an IVR extension.
Ah don't mind i've transfered my 000 user to an IVR. It's working now ! :) Thanks again
 
  • Like
Reactions: amir_
Status
Not open for further replies.