Occasional Call failure report from Vitelity on Hosted PBX
-
@FiyaFly said:
@thanksaj said:
@FiyaFly said:
Here's an interesting one. Every now and again a client sends us an email from Vitelity detailing a call failure. It only ever is one at a time and happens once every couple weeks. Nothing changes in the configuration. This is how the email reads:
"A call to your DID <removed> from <removed> has failed at 11:02am on 11/05/2014 MDT. We received 'CHANUNAVAIL' when attempting to route the call to your server or device. This number is configured to route to the peer<removed> on the account <removed>
This error usually means your server or device is not currently registered to our servers. Please make sure you are registered to the correct inbound server for your account as per the configuration samples found on the support page within the user portal and that you have selected the correct routing method for your DID(s) on the DIDs page.
"Any ideas?
Is the client in Mountain time?
The PBX is hosted. DFW data center.
Why is the time zone in mountain time?
-
@thanksaj said:
@FiyaFly said:
@thanksaj said:
@FiyaFly said:
Here's an interesting one. Every now and again a client sends us an email from Vitelity detailing a call failure. It only ever is one at a time and happens once every couple weeks. Nothing changes in the configuration. This is how the email reads:
"A call to your DID <removed> from <removed> has failed at 11:02am on 11/05/2014 MDT. We received 'CHANUNAVAIL' when attempting to route the call to your server or device. This number is configured to route to the peer<removed> on the account <removed>
This error usually means your server or device is not currently registered to our servers. Please make sure you are registered to the correct inbound server for your account as per the configuration samples found on the support page within the user portal and that you have selected the correct routing method for your DID(s) on the DIDs page.
"Any ideas?
Is the client in Mountain time?
The PBX is hosted. DFW data center.
Why is the time zone in mountain time?
Not entirely sure. The client is either Central or Eastern time, and the server, just double checked, is set to Central. That is how the email was sent.
-
@FiyaFly said:
@thanksaj said:
@FiyaFly said:
@thanksaj said:
@FiyaFly said:
Here's an interesting one. Every now and again a client sends us an email from Vitelity detailing a call failure. It only ever is one at a time and happens once every couple weeks. Nothing changes in the configuration. This is how the email reads:
"A call to your DID <removed> from <removed> has failed at 11:02am on 11/05/2014 MDT. We received 'CHANUNAVAIL' when attempting to route the call to your server or device. This number is configured to route to the peer<removed> on the account <removed>
This error usually means your server or device is not currently registered to our servers. Please make sure you are registered to the correct inbound server for your account as per the configuration samples found on the support page within the user portal and that you have selected the correct routing method for your DID(s) on the DIDs page.
"Any ideas?
Is the client in Mountain time?
The PBX is hosted. DFW data center.
Why is the time zone in mountain time?
Not entirely sure. The client is either Central or Eastern time, and the server, just double checked, is set to Central. That is how the email was sent.
Aha. MDT=CST
-
@FiyaFly said:
@FiyaFly said:
@thanksaj said:
@FiyaFly said:
@thanksaj said:
@FiyaFly said:
Here's an interesting one. Every now and again a client sends us an email from Vitelity detailing a call failure. It only ever is one at a time and happens once every couple weeks. Nothing changes in the configuration. This is how the email reads:
"A call to your DID <removed> from <removed> has failed at 11:02am on 11/05/2014 MDT. We received 'CHANUNAVAIL' when attempting to route the call to your server or device. This number is configured to route to the peer<removed> on the account <removed>
This error usually means your server or device is not currently registered to our servers. Please make sure you are registered to the correct inbound server for your account as per the configuration samples found on the support page within the user portal and that you have selected the correct routing method for your DID(s) on the DIDs page.
"Any ideas?
Is the client in Mountain time?
The PBX is hosted. DFW data center.
Why is the time zone in mountain time?
Not entirely sure. The client is either Central or Eastern time, and the server, just double checked, is set to Central. That is how the email was sent.
Aha. MDT=CST
Oh, well that's interesting...
-
-
@scottalanmiller said:
@FiyaFly said:
Aha. MDT=CST
Um, no, that's not what it means. They are unique things.
I think that they would technically be the same time, but they definitely aren't equivalent in the setting of a time.
-
@thanksaj said:
@scottalanmiller said:
@FiyaFly said:
Aha. MDT=CST
Um, no, that's not what it means. They are unique things.
I think that they would technically be the same time, but they definitely aren't equivalent in the setting of a time.
Right. They would be the same time, but not the same zone. Is this significantly pertinent to the issue?
-
@FiyaFly said:
@thanksaj said:
@scottalanmiller said:
@FiyaFly said:
Aha. MDT=CST
Um, no, that's not what it means. They are unique things.
I think that they would technically be the same time, but they definitely aren't equivalent in the setting of a time.
Right. They would be the same time, but not the same zone. Is this significantly pertinent to the issue?
I'm just thinking it's a possibility. Think about what happens if the system time is off on Windows. If it was a major issue, it would probably happen more frequently or all the time, but I'd fix the time zone if it's wrong server-side.
-
Question: is it always the same DID? Does it always happen around the same time? Can you get a few examples together and compare notes?
-
Is SAR setup on that PBX? If it is, you could run it and check server resource load around the time of the call to see if there was an issue there. But I would not think that would be it since we're talking one call failure.
-
This post is deleted! -
@NetworkNerd said:
Is SAR setup on that PBX? If it is, you could run it and check server resource load around the time of the call to see if there was an issue there. But I would not think that would be it since we're talking one call failure.
The fact it's just one call is what makes me wonder if there is a common DID that is the problem child.
-
Are there other clients you know of who use Vitelity and have this problem now and then or just the one you mention here? I wonder if it has something to do with the way Vitelity does trunk authentication.
-
We have at least one other client with Vitelity and we use it ourselves with no similar issues.
-
I also want to clarify: when you say call failure, failure to dial or call drops in the middle?
-
This client has either 1 or 2 DID's. There are two in the system but I am unsure if they use both of them. I have two emails, one from today and one from 10/15. Both to the same DID, at two different times of the day.
Call failure meaning the report from Vitelity in the original post.
-
Part of the SAR report:
Time-CPU - %user- %nice- %system- %iowait- %steal- %idle
10:50:01 AM- all - 0.32 - 0.00 - 0.22 - 0.07 - 0.17 - 99.22
11:00:01 AM - all - 0.79 - 0.00 - 0.28 - 0.09 - 0.16 - 98.68
11:10:01 AM - all - 0.70 -0.00 - 0.28 - 0.09 - 0.15 - 98.79
11:20:01 AM - all - 0.56 -0.00- 0.25 - 0.07 - 0.12 - 99.00 -
@thanksaj said:
I also want to clarify: when you say call failure, failure to dial or call drops in the middle?
I think what was meant is call failure for an inbound call made to one of their DIDs.
-
@NetworkNerd said:
@thanksaj said:
I also want to clarify: when you say call failure, failure to dial or call drops in the middle?
I think what was meant is call failure for an inbound call made to one of their DIDs.
So it is someone else calling the client and the number doesn't work?
-
@thanksaj Correct. Then Vitelity sends the call failure notification because they could not forward the call.
