Busy tone + Call logs - Best Practice

[Grant Moxom]

Hey Guys,
I've been searching through the forums on this but I just want to know what best practice here is.
The problem:
When users call and there is an issue with the call the call simply hangs up with no sound which confuses them as they are used to an engaged sound or various other things.
3CX has loads of super useful error messages that they never see and they have to ask me and I have to try and figure it out.
If I enable " Play Busy prompt when extension is busy" then it works however as is well known by now this stuffs up our statistics as the call doesn't register as "failed" or "Unanswered".
Does anyone have any clever ideas on letting the users see what is wrong with a call (or hear it) withotu ruining the staistics (which we pull from CDR)
Thanks!

 

[ChrisC_3CX]

If you are using the 3CX Webclient then you are right to say that there is no feedback for SIP codes such as "486 Busy here" unless of course "Play busy prompt" is enabled in which case the user will hear an audio message.

What you could do is use the the 3CX Windows App instead which does provide an error message in such cases. So do the 3CX Mobile clients that play a busy tone.

 

[Grant Moxom]

If you are using the 3CX Webclient then you are right to say that there is no feedback for SIP codes such as "486 Busy here" unless of course "Play busy prompt" is enabled in which case the user will hear an audio message.

What you could do is use the the 3CX Windows App instead which does provide an error message in such cases. So do the 3CX Mobile clients that play a busy tone.

Ah thanks that's interesting. I really was hoping to use the webclient for everyone. Do you know if this is in the feature roll-out // in v18?
I need to decide if I'm going to keep with webclient as we roll-out or move to windows phone and this makes a difference.
Alternatively is there any way to see the error codes from the webclient log or anything? Just to let the user know that the call was blocked/whatevver

 

[ChrisC_3CX]

Ah thanks that's interesting. I really was hoping to use the webclient for everyone. Do you know if this is in the feature roll-out // in v18?

The behavior of the 3CX Webclient on this matter is the same in v18 also.

Alternatively is there any way to see the error codes from the webclient log or anything? Just to let the user know that the call was blocked/whatevver

Not in a log that would be available to the user I'm afraid. The Call Reports will show the entry but the reason will be shown as "Failed".

 

[Grant Moxom]

The behavior of the 3CX Webclient on this matter is the same in v18 also.



Not in a log that would be available to the user I'm afraid. The Call Reports will show the entry but the reason will be shown as "Failed".

So to clarify, for the end user there's no way to tell the difference between someone blocking a call, the call never ringing and just failing or anything like this? Is there ANY way to get that info to the user? I am getting a lot of complaints that people don't know when there is an issue with the call, or the person just blocked it

 

[ChrisC_3CX]

The difference with the 3CX Webclient is essentially that there is no SIP error code or reason for call failure in the form of text. The fact that a tone is not heard does not really make a difference as that same tone would've been heard for all failed calls meaning that determining the reason the call failed would still not be possible. Instead of having to hear for a tone the call gets automatically ended meaning the information to the user still remains the same.

Regarding knowing if a call never rang, I think, not ever hearing it ring in the first place is proof enough.

 

[Grant Moxom]

The difference with the 3CX Webclient is essentially that there is no SIP error code or reason for call failure in the form of text. The fact that a tone is not heard does not really make a difference as that same tone would've been heard for all failed calls meaning that determining the reason the call failed would still not be possible. Instead of having to hear for a tone the call gets automatically ended meaning the information to the user still remains the same.

Regarding knowing if a call never rang, I think, not ever hearing it ring in the first place is proof enough.

This is what I thought at first but for the users it's different. For example - the person rings, it dies immediately with 1 half ring - they don't know if the number is wrong, the phoone blocked them, they have no reception etc. each of these would have a different result. If they were blocked they wouldn't call again and would text instead, if it was bad reception they'd try again later, if it didn't work at all they might raise a support ticket. The problem is currently they just don't know and they have to ask me.
I can then check the logs, read the error code and tell them "yoru call was blocked" or whatever.
If the data is there then the user should be able to see it themselves. They don't need to see the codes necessarily - but at least to know if there was an issue on our side or on the client side