[cisco-voip] CMR reports large jitter on gateway side only

[Wes Sisk]

Andre,

Nice analysis and a very good start on a difficult problem.  I cannot 
explain it away but I may be able to offer some insight.

It is not unheard of to get garbage values from gateways.  See:
CSCsd44903 IOS reports obscure jitter values to MGCP call agent
In this case the gateway was returning the value of an uninitialized 
variable for jitter value.  We had to identify a value to use for 
jitter.  IOS, at that time and at that level, actually did not calculate 
anything like a "jitter" value.  The closest we had was the low 
watermark from DSP statistics so that was what we used.  IOS does not 
use the same algorithm as phones as you could argue pretty effectively 
that jitter is a poor indicator of voice quality.  To that end the 
absolute value was not so indicative.  What is indicative is the value 
for calls to this gateway compared to other calls to this gateway or to 
similar gateways.

For your case the jitter numbers from the gateway are high. The number 
isn't particularly valuable but the trend is.  Is there significant 
deviation in the numbers reported by the gateway? If there is 
significant deviation then there is something causing packets to not 
arrive at the gateway in a timely manner. This could be an issue in the 
originator of the RTP streams (for example see CSCea35850    Unity RTP 
stream has inherent jitter) or something in the network path such as 
asymmetrical path between endpoints.

/Wes


On Monday, April 05, 2010 4:00:10 PM, Andre Beck <cisco-voip at ibh.net> wrote:
> Hi,
>
> while debugging certain voice quality issues in a network based on 7925s,
> Unified WLAN (WiSMs and 1142s), CUCM 7.1(3) and 2811 MGCP PRI gateways
> to a local PBX, we activated CDR and CMR recording. After collecting data
> for some days, we see approx. 30% of calls that CAR considers Poor or just
> Acceptable QoS. Looking closer, there's something dubious about these stats:
>
> * They are only matching the jitter trigger, by having jitter way beyond
>   100ms. Other triggers (Packet Loss, Delay) don't seem to match.
>
> * Jitter is *always* bad on the gateway side, never on the phone side.
>   Incoming calls have the poor QoS on the originating side, outgoing
>   calls have it on the destination. I would expect some asymmetry, but
>   not that much.
>
> * Now for the strangest detail: Tandem calls (coming into the gatway
>   on the PRI and leaving it on the same way, due to a call forward
>   no answer or busy) which obviously never even hit the LAN are
>   tracked with high jitter, too! We are seeing jitter values up to 800ms
>   in one of the CMRs in these cases, even though the gateway is talking
>   to itself on the loopback interface (if it does so at all, dunno exactly
>   how tromboned calls are handled exactly, though there is no QSIG path
>   replacement in action).
>
> Now the question is, when it does report obvious nonsense like in the
> tandem call case, are the other CMRs involving actual RTP streams over
> the (W)LAN at all reliable?
>
> Anyone having an explanation for the absurd gateway loopback jitter?
>
> TIA,
> Andre.
>