Dropped Calls

[gregarican]

We are running a Merlin Magix r2 and MLX endusers are reporting incidents where both private tandem calls and outside CO calls are being dropped. The CO calls get routed out through the other switch that has PSTN access (Merlin Legend r6.1). The green line light on their phones drops off and the remote end isn't necessarily something unpredictable like a cell phone. The calls don't drop to a busy tone or anything. Just dead air.

I have busied out the MLX cards and tested using both Board Controller and Internal Loopback options. The tests consistently pass. There are no errors indicated in the logs in regard to extensions, CO trunks, tandem trunks, etc. The problem happens at multiple extensions across multiple cards.

Is this a known issue with Magix r2? Since there are no errors coinciding with the problem I'm at a bit of a loss.

 

[ken07734]

two things:

1) check to see if any trunks are dead in the pool groups on the pstn Legend. if you have pots lines in the legend then use the trunl access code *03 craftr4 01-80 to test the trunk and see if you have dialtone. 9/10 times its dead lines in the pool group that you are hitting and when you are in a private network the system will hang a bit before it detects no dialtone/loop current the drop you. You could also have a bad trunk or channel on the tandem T1 that you are hitting, if this has worked in the past check those things, if this is a new set up then it could any number of things like UDP tables or Switch ID's not correct.



2) in the SMDR reports any call dropped on the far end will place an asterik next to the call data. try hooking up a printer or hyperterminal and captureing the data while making test calls to see if the call is being dropped from the far end or from your equipment.




hope that helps......

 

[gregarican]

I have tested out the trunks in this tandem pool and they are fine. I have also tested out the PSTN trunks that are involved when the remote Merlin site is dialing outside calls that drop. They are fine as well. There are no "dead" trunks assigned to the pools and the pools aren't being maxed out.

What we see about 2-3 times per day is that an MLX phone will be on a call (1-2 minutes or longer sometimes) and the call will drop to dead air. No dialtone or fast busy. The SA button no longer shows the green line light active and the MLX display screen will be blank. Other MLX phones on the same card will still be on active outside calls at the same time. And the tandem PRI itself doesn't drop nor have any slip/misframe events coincident. Same goes for error events seen on the PSTN PRI.

This phenomenon occurs on different MLX phones on either MLX card I have in place at the remote site. All board and extension tests come out fine. I know that sometimes it's hard to grab UDP routes when dialing out really fast from the remote site. I experience that when dialing out from the remote site and get dead air rather than a ringback tone. I just redial a bit slower, ensuring I got a good dialtone and whatnot. Those calls weren't originally connected, but the real issue involves calls that drop after already being connected for awhile.

SMDR indicates one of the more recent dropped calls was disconnected on the local end (i.e. - no asterisk next to the Called Party phone number).

Are there known issues with buggy 408 GLM-U MLX cards, 100R-U INA cards, or Magix r2? Just curious since I haven't seen this happen outside of telco issues that would show up at the PRI level. Since this issue doesn't involve frame slips, loss of D channel, etc. I'm still at a loss...

 

[gregarican]

I got another report of a dropped call and checked the Magix INA board's CSU error log. Sure enough for the 15 minute interval there were 2 FS, 1 SLP, 1 ES, 2 BS. I know what frame slips, errored seconds, and bursty errored seconds indicate, but what about failed seconds? Is this analogous to unavailable seconds?

Would this type of error situation lead to active calls dropping from the circuit? I didn't see any B- or D-Channel errors in the main system error log.

 

[ken07734]

Slips and misframes are normal ( low occurance of them that is ) If you know how to use monitor mode you can watch the d channel to see if it is the PRI. If not You can have your service provider watch the circuit whle you make test calls to see where the calls are being dropped. I'm not sure if there is any known problems/bugs, you can goto Avaya.com and search the elmo archives or the qccpn in the magix section. Wish I could be more help.

 

[gregarican]

Occasional slips and misframes are definitely part of having a circuit. Agreed there. But what about the Failed Seconds? I'm not aware of this nomenclature, but if it's similar to Unavailable Seconds then that means the circuit is totally out of service.

I do know of the Monitor option in SPM, but I do not know the passcode to access it. Any ideas?

 

[gregarican]

I think I have finally resolved this issue. Here are the steps I took:

1) Telco provider tested line and verified point to point T1 QoS within acceptable range. PROBLEMS PERSISTED
2) Upgraded Merlin Legend on the CVM end of tandem PRI to r7.0 v14.2 (per Avaya's QPPCN 1291). PROBLEMS PERSISTED
3) Verified the Legend's 100D card was 617S15 (per Avaya's QPPCN 1290B). PROBLEMS PERSISTED
4) Upgraded the Merlin Magix at remote end of tandem PRI so that the firmware on its INA board was Application Vintage 20 (per Avaya's QPPCN 1226D). NO PROBLEMS IN A WEEK

Seeing that the tandem PRI added a layer of complexity to troubleshooting this situation (and the dropped calls were sporadic at best) it took about 2 months to hopefully cross this one off the list. We'll see.

Just wanted to update this for the benefit of anyone out there who is running tandem switching with a Magix INA board.