EX90 Packet loss Drop Threshold

[vincent herviou]

Hello,

With CTS endpoints, there is alarm when the packet loss rate exceed 1% and the call is drop when another threshold (10%) is exceed. 

Do we have the same for EX90 or TC endpoint in general ? Can the call be dropped when exceeded a threshold ?

I am asking the question because we had a meeting hosted on a CTMS with 3 CTS endpoints and one EX90. The EX90 had network issue (packet loss and Jitter). The side effect was that the CTS endpoints detected packet loss on received stream and disconnect from the meeting by their own. We would have prefer that the EX90 disconnect itself from the CTMS. Note the the clearpath is activated on the EX90. Does it have any impact ?

Thanks 

Vincent

[Nicholas Thompson]

I don't believe the EX90 packet loss would cause a CTS unit to disconnect unless the CTMS was having congestion issues itself.  The CTS units and CTMS have their own integration of call drop rules which the EX's or other non-immersive TelePresence do not contain.

From the CTMS 1.8 Admin Guide:  "Warnings are issued every 20 seconds when an endpoint crosses its packet loss threshold. If congestion continues for more than 40 seconds, the endpoint will be dropped."

From the CTS 1.7 Release notes; Cisco TelePresence Smart Media Solution: "Call Drop Rules—The CTS will drop a call if it detects 100% received packet loss for 30 seconds or more or if 10% packet loss is sustained for 3 minutes. The main display may go black for a short period of time while the troubled endpoint is dropped from the call."

I would be more suspect of the CTMS network connection being in question.  If any of the common path points that all devices shared in getting to the CTMS are having issues either directly related to or as a byproduct of the call, then it's possible the EX would experience packet loss and then the CTS would eventually too.  I would investigate the network paths there should be no reason the CTMS would drop a CTS because of loss from an EX.

[vincent herviou]

Hi

Thanks for your reply.

The meeting was with 3 CTS 3xxx, 1 CTS 1300 and 1 EX90.

The EX 90 was the last endpoint to join so was displayed on left screen of the CTS3xxx.

The Packet Loss and jitter were only noticed on left screen for the 3 CTS3xxx. The 3 CTS3xxx did not disconnected at the same time. And according to the CTMS Switching log file, the CTS3xxx disconnected when the EX90 was displayed on the left screen.

My assumptions are that the EX90 (having high PLR and jitter) did not drop the call as the clearpath don't act like CTS but the side effect is that the CTS detect high PLR & jitter on received stream and drop themselves when the video stream of the EX90 was sent to them.

What do you think ?

Thanks

Vincent

[Nicholas Thompson]

The CTS shouldn't play a self deprecating role because of another device hanging off of CTMS.

1)  What happened after the first CTS3xxx disconnected?  

2)  Did the call clear up for all endpoints?

3)  Does this happen with other 4site connections or only with an EX?

[vincent herviou]

Thanks for your interest on the matter. I appreciate.

1)About 1min later a second CTS has been disconnected. After that I don't know if other CTS have been disconnected or if they disconnect by themself (user interaction I mean)

2) See reply one

3) we test call on CTMS without the EX90 and all statistics were ok.

On the EX90 we fixed a QoS issue afterwards but the fact that an endpoint having network issue may make all the other  endpoint disconnect from the meeting is disappointing.

for your information on the CTMS we received this error :

2014-06-26 10:56 AM ALARM_RMP_CONG_NOTIFY_BAD_TX_DCN ERROR Conference Manager Disconnect notification received from CTS3xxx against EX90. 

I opened a TAC case to clarify this too.

Vincent