10-18-2012 01:56 AM - edited 03-17-2019 11:59 PM
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
10-18-2012 03:22 AM
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?
10-18-2012 03:28 AM
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
10-18-2012 04:52 AM
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.
10-18-2012 05:11 AM
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
10-18-2012 11:41 AM
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.
10-19-2012 04:06 AM
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.
10-19-2012 06:06 AM
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.
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.
10-19-2012 06:14 AM
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
10-20-2012 03:20 PM
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
10-20-2012 04:05 PM
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
10-20-2012 06:47 PM
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
10-21-2012 10:05 PM
Our client CTS is on 1.9. All TP end points and 5300 are on latest revisions
Sent from Cisco Technical Support iPad App
10-21-2012 10:12 PM
Hi Tina
We´re running 1.8.4 and 1.8.0. Same results with both versions.
Thank you
Tino
10-22-2012 01:34 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide