ā02-08-2013 07:49 AM - edited ā03-18-2019 12:34 AM
Hi eveybody.
I've a TPS with release 2.3(1.55). When I call a static conference in TPS from two or more CTS room connected via intranet (over an IP/MPLS backbone), I've good jitter values (from 3 to 20 ms, jitter values are observed on CTSs).
But when I add one or more external endpoints connected via internet, jitter (observed on CTSs) reach very high values (till 600 ms).
This seems an abnormal behavior to me: I thought jitter is calculated from each endpoint to TPS (and vice versa), but on the contrary seems like endpoints and CTS can influence each other.
Is this the normal behavior and I'm wrong or... ?
Thanks in advance
Regards
Fabrizio
ā02-08-2013 11:25 AM
Fabrizio,
Do you see the same high jitter values if the internet based video endpoints call the CTS rooms directly?
rf
ā02-11-2013 01:44 AM
Hi,
unfortunately we can't make a point-to-point call from an internet endpoint to our intranet CTSs: that's because this kind of call are denied for market/business/administrative reasons, and second because internet endpoint are not CTSs (but just SD endpoints, tablets, smartphone and so on...), and our CTSs is TIP, so we need TPS for interoperability.
Regards
ā02-11-2013 03:46 AM
Hello,
What is the maximum jitter values accepted?
ā02-11-2013 04:06 AM
Hi Firdaush,
ss far I know, for Cisco Telepresnce there's not a "maximum jitter values accepted": Cisco raccomends a target value of no more than 10 ms of packet-level jitter and no more than 50 ms of video frame jitter in each direction.
Any packets exceeding the 165 ms jitter are discarded by the receiving telepresence endpoint and those packets are indicated as ālate packetsā in the call statistics.
In my calls, when an internet endpoint is involved, I observe jitter peeks (on period, that is over the last 10 sec.) up to 600ms, and an avarage call jitter of about 80 ms.
.
ā02-11-2013 06:49 AM
Is it the same as on the TPS 8710 ?
ā02-11-2013 07:00 AM
Firdaush,
sorry, I didn't get your question! What do you mean?
ā02-11-2013 02:00 PM
Do you have any network statistics? Having mutliple calls puts load on the TPS which could cause
jitter but sure it also puts load on the network towards the TPS.
I dont have a 2.3 running, but at least with 3.0 it is a bit limited to see the load of the TPS, at least
I did not find a way to get SNMP-stats, CPU-Load-info, ...
Do you only see this in the statistics or do your users complain?
600ms jitter should be clearly noticable :-)
What I would try:
* can you pinpoint it to a specific scenario, like if a specific endpoint,, endpoint type/software version, bandwidth usage is in the jitter starts
* try to trigger the above
* closey monitor your network, monitor your switchports, get stats from your lan/wan/mpls/...
* try to do a (wireshark) trace, is it the TPS "generating" the jitter or is it your network
What kind of software versions do you use? (endpoints and infrastructure)
what type of external endpoints are used, how are they connected (like vcs-e, traversal calls/interworking/...)
Does it make a difference if you run the latest software?
Please remember to rate helpful responses and identify
ā02-13-2013 01:51 AM
Do you have any network statistics? Having mutliple calls puts load on the TPS which could cause
jitter but sure it also puts load on the network towards the TPS.
Hi,
first of all I would like to underline that abnormal jitter values are present only when an internet endpoint is involved. TPS is inside a Data Center architecture, so internet calls or intranet calls converges in the same Data Center network.
Abnormal jitter values are reported only on CTSs logs: TPS call stats are good.
Anyway yes, we took several network statistics via IP SLA: we measured jitter in all network portions we could. The results were quietly good.
Network is configured with QoS, and devices are all Cisco 7600/6500 inside Data Center. All network stats are good (ports and so on).
Do you only see this in the statistics or do your users complain?
600ms jitter should be clearly noticable :-)
Of course video quality is really really bad. All QoS parameters (latency, packet loss) are good: so jitter is the cause of problems.
* can you pinpoint it to a specific scenario, like if a specific endpoint,, endpoint type/software version, bandwidth usage is in the jitter starts
As I told, high jitter values arise when an internet endpoint calls TPS inside Data Center. If only intranet CTSs are connected, jitter is good.
Of course an internet call has worst QoS values compared with an intranet call. But it seems like a single call point to point vith high jitter values from and internet endpoint to TPS affects also all the other calls from intranet CTSs to TPS, "sharing" the jitter with all the endpoints (CTSs and others) connected to TPS. I wonder if this is a normal behaviour or not.
* try to do a (wireshark) trace, is it the TPS "generating" the jitter or is it your network
How can I misure jitter with wireshark? I've never used it for QoS monitoring. Anyway, as I told, I'd exclude network.
What kind of software versions do you use? (endpoints and infrastructure).
Internet endpoints are miscellaneus: from ipads to samsung tablets, from radvision VC240 to Cisco EX90, so is really difficoult to collect all software versions. Anyway, it doesn't matter wich endpoint is... all internet endpoints introduces the same jitter.
VCS-C/E are 7.2, and CTS are 1.6(4). Intranet endpoints are CTSs.
what type of external endpoints are used, how are they connected (like vcs-e, traversal calls/interworking/...)
Internet endpoints with public IP address are really heterogeneous, and connect or in SIP direct access to a VCS-E (to port UDP/TCP 5060), or via Traversal zone between two VCS-E (one vcs-e customer, one vcs-e provider).
Does it make a difference if you run the latest software?
No, we tried TPS 2.2, 2.3 and 3.0 (our target release is 2.3).
Thanks to everyone.
Regards
ā02-13-2013 06:27 AM
Do you have a service contract for the TPS / CTS systems?
As you had posted this some days ago and there is no real good input
(maybe browsing through the bug toolkit is also worth givng a try)
If you do not get a better answer, I woud recomed to escalate this thread as a service request to Cisco Tac.
Regards the wireshark trace, on wireshark you have some RTP analytics
as well, have not tried it with encrypted packats and the TPS but in general
it is quite nice.
Then you could do one trace where everything is fine and check the RTP
and compare it with the RTP of a call which is not ok.
I would capture the packets as close to the TPS as possible.
If you have the cance also caputre the same packets upfront the CTS systems
and then compare.
But this might help you to better understand if its the endpoint having problems
with the packets, the TPS sending out packets with jitter or if its somethign in the network, ...
Good success.
Please remember to rate helpful responses and identify
ā02-13-2013 08:08 AM
Thank you Martin,
I just opened a service request. Anyway I will follow your suggestion with some test using wireshark.
Regards
ā02-13-2013 08:26 AM
Yes, I love wireshark, its a great tool!
Check out:
http://wiki.wireshark.org/RTP_statistics
and google for wireshark rtp jitter
If you do not see the signaling (like you use TLS) you will have to define the UDP pakets manually as RTP.
Anyhow, please update the thread if you have something new to report and how you fixed it at the end!
Please remember to rate helpful responses and identify
ā02-13-2013 08:31 AM
I'll do!
Rgards
ā02-12-2013 02:32 AM
Hello Fabrizio,
How to understand the jitter issue on the TPS? Below a screenshot:
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