Occasional Call failure report from Vitelity on Hosted PBX
-
@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.
-
@FiyaFly said:
@thanksaj Correct. Then Vitelity sends the call failure notification because they could not forward the call.
This sounds like a Vitelity issue. Doesn't sound like an issue with the PBX.
-
Well, they send the notification as though they are getting a channel unavailable response from the PBX. I'm looking to call them tomorrow but wanted to see if anyone had seen this before. I do not think it is the PBX either.
-
@FiyaFly said:
Well, they send the notification as though they are getting a channel unavailable response from the PBX. I'm looking to call them tomorrow but wanted to see if anyone had seen this before. I do not think it is the PBX either.
Everything about this screams "hiccup in Vitelity" but of course, they'll pass it off as a PBX problem unless you can prove definitively otherwise.
