Call Quality Loss

[Biscuits87]

System Details:
3300 MCD 5 SP2 PR1
CX-II
Six BRI trunks.
One trunk group


I have a customer which has reported a worsening issue with their lines.
Apparently when customers make calls in the line sounds very garbled, customer has reported that over time the issue is happening more and more often. It's now up to about 90% of the incoming calls, whereas before it was about 50%..ish. He has said that if they take the callers number and make a call back to them the line is fine every time. This is happening across all callers into the building.

I've checked DTST, no slips at all. Only 1 Netsync source. No alarms on the system. BT have checked the lines and they've found no issues. I've looked a the logs, they're full of the following error:

[tt]Software 917 Error 2013/May/23 10:45:41 SYS_TimeCalls pingTimeServerS_sntpcLib_INVALID_ADDRESS Main SYS_TimeCalls.cpp;403[/tt]

I'm not sure what invalid address the system is referring to, or even if this is the cause of the issue.. it's all I have to go on right now though. Any help would be greatly appreciated.

 

[LoopyLou]

Any difference in the trunks that incoming call come in versus outgoing ( since outgoing calls seem to be fine )? As for the error. not sure if "pingTimeServer" means it can't reach the time server you have programmed in the system. Can I assume not problem on internal calls?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[Biscuits87]

No difference in incoming or outgoing trunks, Lou. The system isn't part of a cluster so there's no IP networking either.

I've grabbed some voice quality logs, as far as I can tell there's no packet loss, delay or jitter being recorded. The only variable with a value against it is: "Jitter Buffer Avg. Depth", which seems to range from about 10 to 39. I'm going to suggest a reboot tonight (Cheap, I know), if it's still a problem in the morning I'll ask the line provider to take another look.

 

[wireman50]

Seen something similar once or twice before. usual problem is BT only test the first BRI and then assume the rest are OK. We tested out last time and the first BRI was OK ish (showing some BERT errors ) but thye other 4 circuits were rubbish being crackly and horrible. It was also causing the switch to reset itself because of the number of errors.It jujst so ahppened that the number of users versus the number of lines coincided enough that most outgoing calls went out over the good circuits.

 

[Biscuits87]

Ok, thanks Wireman. I'll keep that in mind tomorrow when checking the system!

 

[LoopyLou]

Wireman50 might have something. Typically systems are setup to have the incoming calls come in on the first circuit/trunk and go out on the last circuit/trunk to avoid any chance of "glare". If that is your setup then the successful outgoing potentially will be on the last circuit but incoming will be on the first.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[Biscuits87]

Reboot 'seems' to have lessened the issue.. but we all know that's probably not the case as end user is still experiencing the problem. Have reported it back to the line provider. Will see what that turns up. Thanks for all the help so far!

 

[AlphaMann]

Is the Telco detecting any slip or framing loss? I have had a system before that had no errors or framing loss on the controller but the Telco reported issues on their end. The Telco tested their equipment with no errors. In the end I replaced the controller but I think it was a bad MMC slot on the board. Mitel said it could be some sort of Time Controller.

As for your time server issue it is an error that is generated when your time server is not able to connect to the NTP server in the Date and Time form.

 

[Biscuits87]

Ah.. cheers for that info Alpha. Goes hand in hand with the errors saying it can't contact the AMC, looks like site have done some network changes too. I'll update when I have more info.

 

[LoopyLou]

Network changes, voice quality issues. Hmmmmm

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[Rockza]

Why not select the trunks directly and test to see if each line is clear?
Go through each one individualy and make a note of lines giving issues.

Ian

 

[Biscuits87]

BT have carried out extensive testing over the weekend and have detected problems with the lines... surprise surprise.


It should be known that I am not a fan of BT.

Thanks for all your help team!

 

[LoopyLou]

No kidding.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[wireman50]

wonder why......