200ICP Packet Loss Over Frame Relay 1

[MitelInMyBlood]

I have several 200-ICP systems networked over a private WAN running across dedicated leased T1s and a terrestrial microwave system all behaving quite well and successfully sharing bandwidth with the data apps.

I have a few more 200-ICP systems running not-so-well across some SPRINT Frame-Relay circuits.
The problem is customer complaints about intermittently choppy receive audio TOWARD the 200ICP (the other end isn't complaining).
Bandwidth pipe size on the frame circuits is 512k and the CCIR is 0
Even when there is no other data contending for this bandwidth we're experiencing intermittent jitter on the order of 100 ms and occasionally approaching 200 ms.
No, no a lot of it, but enough that it's really hammering the voice quality and we're getting too many user complaints.

From what sketchy documentation I can find, the jitter buffers must be individually enabled on each phone and then can only compensate for only 60 ms.

That seems an awfully small amount to compensate for.

If I'm hearing this right, the CISCO CM is configurable and can compensate for up to 200 ms - why can't the Mitel?

Short of yanking the 200 ICPs in favor of CME, what are my options?

 

[MitelInMyBlood]

Additional information.

The problem seems confined to the IP phones on the 3 affected systems.
However, on two of those systems where I have a peripheral bay w/attached TDM phones, there are no complaints from users with the TDM phones, only complaints with the IP phones and only then on IP-trunked calls.

Since TDM phones are not having trouble I'm interpreting that to mean the problem is not with IP trunking or else the 200ICP controller can handle the jitter.
However, once a call is established to the IP phones, the ICP is no longer in the circuit and that's when the IP phone users are complaining.
I do have trunking set up to use the 2nd port on the phones but we're not using it/them.
Yes, we are using separate voice & data VLANs with QOS.
This is working correctly because it's working fine over leased T1s and terrestrial microwave circuite; only frame relay circuits are having trouble.

All ideas and suggestions welcome!

So what if anything do any of y'all know about the jitter buffers?
It would seem that if there are jitter buffers in the ICP (and there surely must be) that they're enabled by default and able to compensate.
It would also be nice if there was a maintenance command to enable the jitter buffer on the IP phones without having to go to each phone, reboot it and manually configure to enable them.
That seems unintuitive.

 

[mitelman]

As an experiment why not setting a couple of phones up in teleworker mode just using the ICP as the destination. That should increasse the jitter buffer up to 150 ms and you can see if that makes any difference. Also the new 5212 and 5224 supposedly have a huge jitter buffer up to 800ms. This could help you narrow the problem down.

 

[MitelInMyBlood]

Thanks for the tip mitelman!

Where exactly does this information appear in the DOCs?
In browsing through everything I could find, there was precious little out there on the subject of jitter buffers.

Also how do jitter buffers come into play with IP over FR trunking and TDM sets working off of Per bays?
The success with TDM sets strongly suggests there's got to be some JB taking place in the controller because clients using ss4025s, etc. over the same FR circuits aren't complaining; it's only the IP set users - and they're about ready to toss the whole (expletive deleted) thing in the trash.
As you can probably tell, I've been taking kind of a beating over this.

 

[mitelman]

I believe the jitter buffer stuff is listed in the teleworker docs and/or engineering guide. The bit about the 5212/5244's having up to 800 ms is in the SX200ICP advanced training doc. So, it doesn't really appear in any of the docs that it SHOULD be in!

As fas as I know there is no jitter buffers when it comes to IP trunking. We have never been able to get a straight answer out of design and have no idea whether they have implemented anything in the last two years. If they have they are sure keeping quiet about it.

 

[MitelInMyBlood]

Well, I'm 200ICP Level-2 certified at rls 3 and I honestly don't remember anything about the jitter buffer size in any recent upgrade training - perhaps I missed it.
At my age that's entirely possible ;-)

And yes, I agree Mitel all too often obscures invaluable little tidbits of info in the least likely places, case in point, critical AMC info buried in a dang Product Bulletin of all places (Grrrrrr.....) - Yeah, it's documented, but the search engine on MOL sure won't find it.

As for Jitter Buffers in IP trunking (On the ICP) there just has to be.
How else can we explain that TDM sets off the 200ICP do not experience audio dropouts across crappy frame relay IP trunk circuits that otherwise wreak havoc with IP sets (sans jitter buffers enabled)?

Too much of this is being hidden in internal documents.
Example; Look how many years it took to finally get CCS Trace documentation released into general distribution (now built into the help file on the 3300).
4 Years ago I had a Mitel Prof Svcs tech in my shop one afternoon who happened to notice I had a 3-ring binder on the shelf labelled "CCS Trace Training" - asked where I got it and then begged me to photocopy it for him.
I guess I really don't have a valid complaint when you folks don't even share some of this stuff w/your own people.
How the heck are those of us on the front lines supposed to keep customers happy when critical support info is being witheld?

DCR time? Sure, why not.
Default them off if you must, but we need jitter buffers to be a set class of service element instead of something that we have to dispatch a tech to a site 30 miles away to enable instrument by instrument.

And while I'm on my soapbox, DCR #2
Fix the set hardware to be able to recover from a corrupted flash download without having to send the set back to O'burg for repair.