High Jitter with TC5.1.4 and CTS

t.svatek · ‎10-18-2012

Hi

We´ve added several new SX20 with TC5.1.4 to our existing installation. On these endpoints we found high Jitter rates (up to 1600ms) when calling a Cisco CTS-Device like CTS-3000. It only happens in the direction SX20->CTS. Received Traffic is ok.

I´ve done the same Test with several endpoints running 5.1.2 or 5.1.0 and there, everything works fine.

There is no packet-loss on any endpoint and there are no buffer overflows in the network.

Has anyone had the same issue or can anyone do a test in his environment ot doublecheck this, before I open a TAC-Case?

Thank you!

Tino

Danny De Ridder · ‎10-18-2012

Hello,

where do you check these values? The touch panel?

When I make a call towards my SX20 from an E90, I can check the jitter as follows :

xstatus Diagnostics Call //Jitter

*s Diagnostics Call 4 Channels IncomingAudioChannel 48 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels IncomingVideoChannel 51 Netstat 1 Jitter: 4

*s Diagnostics Call 4 Channels IncomingVideoChannel 54 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels IncomingVideoChannel 58 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels OutgoingAudioChannel 49 Netstat 1 Jitter: 13

*s Diagnostics Call 4 Channels OutgoingVideoChannel 52 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels OutgoingVideoChannel 55 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels OutgoingDataChannel 57 Netstat 1 Jitter: 0

** end

OK

Or you can debug the RTCP packets used to calculate the jitter :

log ctx RtcpPacket debug 9

log output on

This prints the RTCP packets sent/received.

814.01 RtcpPacket PacketDump: Proto: RTP, Name: RTCPRR SDES , Direction: Outgoing, RemoteAddress: 144.254.14.64:2373, GroupEntity: 144.254.14.64, Time: 814005, Content: !!!<

814.01 RtcpPacket

814.01 RtcpPacket Section: Reception Report

814.01 RtcpPacket Packet sender SSRC: 8ccd5a97

814.01 RtcpPacket RR-block for SSRC: ba371c2e

814.01 RtcpPacket Fraction lost: 0

814.01 RtcpPacket Cumulatice lost: 0

814.01 RtcpPacket Last sequence number: 36574

814.01 RtcpPacket Jitter: 213

814.01 RtcpPacket Last SR: 0

814.01 RtcpPacket Delay since last SR: 31853866

814.01 RtcpPacket Section: SDES

814.01 RtcpPacket --------------------

814.01 RtcpPacket Dumping packet in hex, packet length is 84 bytes.

814.01 RtcpPacket 0x81, 0xc9, 0x00, 0x07, 0x8c, 0xcd, 0x5a, 0x97, 0xba, 0x37, 0x1c, 0x2e, 0x00, 0x00, 0x00, 0x00,

814.01 RtcpPacket 0x00, 0x00, 0x8e, 0xde, 0x00, 0x00, 0x00, 0xd5, 0x00, 0x00, 0x00, 0x00, 0x01, 0xe6, 0x0d, 0x2a,

814.01 RtcpPacket 0x81, 0xca, 0x00, 0x0c, 0x8c, 0xcd, 0x5a, 0x97, 0x01, 0x12, 0x64, 0x64, 0x65, 0x72, 0x69, 0x64,

814.01 RtcpPacket 0x64, 0x65, 0x2e, 0x65, 0x78, 0x39, 0x30, 0x2e, 0x68, 0x6f, 0x6d, 0x65, 0x02, 0x12, 0x64, 0x64,

814.01 RtcpPacket 0x65, 0x72, 0x69, 0x64, 0x64, 0x65, 0x2e, 0x65, 0x78, 0x39, 0x30, 0x2e, 0x68, 0x6f, 0x6d, 0x65,

814.01 RtcpPacket 0x00, 0x00, 0x00, 0x00

814.01 RtcpPacket >!!!

And to turn off printing, just do :

log output off

Here I read Jitter:213 ?

Can we check this on the SX20?

t.svatek · ‎10-18-2012

I get this:

xstatus Diagnostics Call //Jitter

*s Diagnostics Call 4 Channels IncomingAudioChannel 44 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels IncomingVideoChannel 47 Netstat 1 Jitter: 1

*s Diagnostics Call 4 Channels IncomingVideoChannel 50 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels IncomingVideoChannel 54 Netstat 1 Jitter: 0

*s Diagnostics Call 4 Channels OutgoingAudioChannel 45 Netstat 1 Jitter: 259

*s Diagnostics Call 4 Channels OutgoingVideoChannel 48 Netstat 1 Jitter: 169

*s Diagnostics Call 4 Channels OutgoingVideoChannel 51 Netstat 1 Jitter: 0

** end

OK

log ctx RtcpPacket debug 9

OK

log output on

OK

10901.62 RtcpPacket PacketDump: Proto: RTP, Name: RTCPRR SDES PSFB , Direction: Incoming, RemoteAddress: 148.198.47.56:17037, GroupEntity: 148.198.47.56, Time: 10901624, Content: !!!<

10901.62 RtcpPacket

10901.62 RtcpPacket Section: Reception Report

10901.62 RtcpPacket Packet sender SSRC: 05561018

10901.62 RtcpPacket RR-block for SSRC: 4c4f2b8a

10901.62 RtcpPacket Fraction lost: 0

10901.62 RtcpPacket Cumulatice lost: 19

10901.63 RtcpPacket Last sequence number: 37737

10901.63 RtcpPacket Jitter: 24600

10901.63 RtcpPacket Last SR: 31647

10901.63 RtcpPacket Delay since last SR: 131072

10901.63 RtcpPacket Section: SDES

10901.63 RtcpPacket Section: PSFB

10901.63 RtcpPacket --------------------

10901.63 RtcpPacket Dumping packet in hex, packet length is 76 bytes.

10901.63 RtcpPacket 0x81, 0xc9, 0x00, 0x07, 0x18, 0x10, 0x56, 0x05, 0x8a, 0x2b, 0x4f, 0x4c, 0x13, 0x00, 0x00, 0x00,

10901.63 RtcpPacket 0x69, 0x93, 0x00, 0x00, 0x18, 0x60, 0x00, 0x00, 0x9f, 0x7b, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00,

10901.63 RtcpPacket 0x81, 0xca, 0x00, 0x05, 0x05, 0x56, 0x10, 0x18, 0x01, 0x0d, 0x31, 0x34, 0x38, 0x2e, 0x31, 0x39,

10901.63 RtcpPacket 0x38, 0x2e, 0x34, 0x37, 0x2e, 0x35, 0x36, 0x00, 0x84, 0xce, 0x00, 0x04, 0x05, 0x56, 0x10, 0x18,

10901.63 RtcpPacket 0x00, 0x00, 0x00, 0x00, 0x4c, 0x4f, 0x2b, 0x8a, 0xb6, 0x00, 0x00, 0x00

10901.63 RtcpPacket >!!!

10901.63 MC I: RemoteParticipant::generateFastPictureUpdate(p=4,ch=2,mx=49) Remote asked for fast picture update in RTCP

Danny De Ridder · ‎10-18-2012

Hello,

this does not show the values you mentioned in your first post. I see Jitter: 259ms for outgoing audio, not the 1600ms you mentioned. Where did you read that value?

The incoming report from the CTS shows Jitter: 24600. These are "RTP time units".

timestamp: 32 bits

  The timestamp reflects the sampling instant of the first octet in
  the RTP data packet.  The sampling instant MUST be derived from a
  clock that increments monotonically and linearly in time to allow
  synchronization and jitter calculations (see Section 6.4.1).  The
  resolution of the clock MUST be sufficient for the desired
  synchronization accuracy and for measuring packet arrival jitter
  (one tick per video frame is typically not sufficient).  The clock
  frequency is dependent on the format of data carried as payload
  and is specified statically in the profile or payload format
  specification that defines the format, or MAY be specified
  dynamically for payload formats defined through non-RTP means.

Clock frequency would depend on codec being used. PCMA codec has a fixed sample clock of 8kHz. That results in a timetick of 125 µs, for that given codec. I am unsure what your codec is.

Only data I can interpret is the 259ms for outgoing audio, not the 1600ms.

Still, 259 seems to be rather high too.

t.svatek · ‎10-18-2012

Hi Danny

The xstatus i provided was a snapshot. The jitter values for receiving audio and video vary and I recognized also much higher values like 1600ms, but again it varies. Anyway, as you wrote: the values are much to high.

What do you mean exactly by Codec? For Audio it uses G722 with 64 kbps.

Do you have the chance to test a call with TC5.1.4 and CTS?

Thanks

Tino

Danny De Ridder · ‎10-18-2012

Hello,

I tried to call a CTS-500 within Cisco office : to no avail.

If anyobdy has a CTS which I can call from my EX90 on the Cisco network, I can try. Or even a public one.

Let me check whether there are any know issues CTS <-> EX-Series when it comes to audio jitter.

t.svatek · ‎10-19-2012

I tried again with 5.1.3 and 5.1.2 with the same results. Maybe it happens only with SX20. I´ve done several testcalls with C20 and C40 without any high jitter values.

BTW: I get high jitter on audio AND video.

Danny De Ridder · ‎10-19-2012

Hello,

tried a call from my SX20 to a CTS-500 and see large jitter values too.

xstatus Diagnostics //jitter

*s Diagnostics Call 13 Channels IncomingAudioChannel 192 Netstat 1 Jitter: 0

*s Diagnostics Call 13 Channels IncomingVideoChannel 194 Netstat 1 Jitter: 2

*s Diagnostics Call 13 Channels IncomingVideoChannel 196 Netstat 1 Jitter: 0

*s Diagnostics Call 13 Channels IncomingVideoChannel 200 Netstat 1 Jitter: 0

*s Diagnostics Call 13 Channels OutgoingAudioChannel 193 Netstat 1 Jitter: 582

*s Diagnostics Call 13 Channels OutgoingVideoChannel 195 Netstat 1 Jitter: 195

** end

There's a ddts open for this.

CSCtz74111 - Regression: Video jitter statistics received through RTCP are not update

It talks about video, but in the attachments of the ddts I see audio too.

I think the issue is cosmetic in the sense that these values are wrong, because wireshark traces did not show such jitter.

The ddts is marked as candidate for TC6.

t.svatek · ‎10-19-2012

Danny

Many thanks for trying this out.

I don´t think, that the behavior is related to the open ddts, because there is definitly jitter. I´ve seen in the logs, that the CTS tries to increase the jitter buffer till the quality goes down.

I´ve raised a TAC-Case for this issue.

thanks

Tino

shogun2009 · ‎10-20-2012

We have just upgraded a CTS site with VCS and 5300 MCU, and were doing testing to our C60. I was at the C60 end and also experienced the high outgoing jitter - 500+ down to 160 mS. The incoming audio from the CTS was also poor, sounding like it was being gated. The jitter was normal and the sound OK when putting the call through the MCU.
Rod Louey-Gung

Sent from Cisco Technical Support iPad App

Martin Koch · ‎10-20-2012

Danny: btw, how big is the JitterBuffer of the different endpoints (tc, te, mx, sx, ex, mxp) and infrastructure (mcu, isdngw, ipgw, ...)?

Please remember to rate helpful responses and identify

tihopper · ‎10-20-2012

CTS has a dynamic jitter buffer, meaning it can resize between 85 to 245ms depending on network conditions. CTS systems also have much stricter network requirements.

Can you please state what CTS version you are using (is this 1.7, 1.8, or 1.9)? I don't see the CTS version mentioned from anyone just yet.

Tina

shogun2009 · ‎10-21-2012

Our client CTS is on 1.9. All TP end points and 5300 are on latest revisions

Sent from Cisco Technical Support iPad App

t.svatek · ‎10-21-2012

Hi Tina

We´re running 1.8.4 and 1.8.0. Same results with both versions.

Thank you

Tino

Danny De Ridder · ‎10-22-2012

I took a wireshark trace on the SX20 side which was connecting to a CTS-500 running 1.8.1.1(2). On the trace I see the codec sending G711 voice packets at 20ms intervals. No jitter, but the RTCP receiver reports from the CTS show very hig jitter values.

interarrival jitter: 32 bits

An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer.

For G711 the timestamp units are 1/8 of a ms?

So looking at some of these values, I see 24579/8 or 3072 ms or 3 seconds. We will need to get ddts I referred to earlier updated. This is not cosmetic byt real issue.