Looking for Traffic Characteristics for network Loss, Latency and Jitter for TAA/TC endpoints

[ANDREW BEEZLEY]

Hello - Can anyone point me to a link where I can find a document that describes the traffic characteristics for packet loss, latency and jitter thresholds for TC-based endpoints?  I'm looking for something similar to what was created for CTS/TX series endpoints that lists out the network thresholds and max bandwidth consumption (similar to what is found in this document).

I have a large customer that primarily utilizes MX300 endpoints over internet connections and most of their sites are experiencing call quality and integrity issues such as audio clipping, video artifact and call drops.  The logs from the endpoints show that the decoders are throwing away packets due to inbound "bursty" traffic as well as receiving packet loss due to corrupt data in the payload and headers, etc.  All the typical problems you would see as a result of a network path trouble.  ClearPath is enabled on all the endpoints with the exception of Video Aware Forward Error Correction since the endpoints are all configured with max call rate of 768Kbps. 

Also, can someone tell me how the Touch UI reports loss and Jitter versus what goes into the call summary log (status.txt) in the log archive?  How granular will the Touch UI provide the information?  Is it an average of 10 second buckets, 30 second buckets for "Current Packet loss"?  The reason I ask is because I see a higher loss rate in the logs than what the user sees in the room when looking at call statistics through the UI.  I also will see a max jitter value much higher than what the user reported seeing in the Call Status through the Touch.

Many thanks in advance,

-Andrew

[juriss]

I'm not sure about specific documents that describe and document what you are looking for...

However I can share what my experiences are in supporting approx 800 endpoints that are a mix of MXP/C/EX/MX series systems.located across the US and connected via an MPLS based WAN

By far the most common issue we have is port setting mismatches that result in half duplex conditions.    its a bit of a pet peeve lately to get these correct

No amount of QOS will fix basic Duplex mismatches and 90% or more of my network troubles are fixed by going Auto on both sides

Either BOTH the VTC endpoint and the closet switch should use Auto or Neither should use auto. We have gone to setting all systems to AUTO and trying to force the local LAN folks to set the closet switch to Auto also 

If you have TMS, do a system overview report and it will show you the systems that are in half duplex. (Endpoint set for Auto and closet switch set to 100Full)    

If the endpoint is set for 100Full and the closet switch is set to Auto... the closet switch will show the half duplex status (we do not have direct visibility to that)

I really like the new web interface functions in the TC7 software

If the closet switch is Cisco and has Cisco CDP enabled... the status page in the endpoint will show switch name and port that its connected to and if its in half duplex mode

In the web interface there are a few spots to see network performance

A - in the Call control menu... by pressing the "i" button next to the connected systems  I believe that it shows jitter and loss in semi real time

B - Under Diagnostics and Call History....  it shows the basic call history, they if you click the entry it will provide expanded detail for that call...I believe that will show the worst case jitter and the total packet loss... this is only available after the call is complete

What we have seen in terms as network performance is:

Audio Jitter = 5.5ms to 8.5ms.. smaller packets

Video Jitter = 25ms to 150ms... larger packets

The above are from the detailed call history and represent max values over a 1+ hour call

Most of our traffic is carried as best effort, we are only recently working to get traffic marked with COS (CS4/AF41) and then its carried in WAN class 2

I have found that VTC calls that have a high Jitter rate, have less packet loss that VTC calls with low Jitter.   My theory is that when the Jitter buffer is large... less packets are discarded   When the Jitter buffer is small...  more packets are discarded because that rare rouge late packet missed the jitter buffer window

We also setup TMS to email folks if a system experiences "Downspeeding"   and per Tandberg docs... Downspeeding will happen when paket loss is 10% or more for 2 seconds...  When downspeeding it will drop 64k  up to three times and then it it does not improve, it will return to the original speed...  makes sense and we will see a burst of 3 downspeeding events and then nothing for the rest of the call.

Hope that helps and I'm curious if others have the same experience and similar opinions

SCJ

[Kenneth Hicks IV · Accepted solution]

Andrew,

  I found some other information that may answer some of your questions on Clearpath:

ClearPath is a proprietary packet loss recovery technology which will automatically start if supported by the far end. ClearPath works in the following way: 

► If packet loss for audio is more than 1.5%, protection of the audio is started by using FEC (Forward Error Correction) if call bandwidth is 768kbps or more. FEC will stop when packet loss is less than 0,5% for some time. The FEC overhead will be 100%.
► If packet loss for video is more than 0,5%, protection of the video is started by using FEC if call bandwidth is 768kbps or more. FEC will stop when packet loss is less than 0,1% for some time. The FEC overhead will be 30%.
► The FEC overhead will be within the call rate so the video rate will have to drop to give room for the additional FEC packets.
► If the video rate is above 768kbps and we are experiencing between 5-15% packet loss, the video rate will be down speeded by 10%. For loss more than 15% the video rate will be down speeded by 15%.
► If the current available bit rate for the main video is less than 768kbps the bit rate will be down speeded by 10% if the packet loss is more than 5%.
► A test will be done to check if the loss is stable. In the beginning of the call any loss will be considered as stable, but then a loss will have to be consistent for 15 seconds before adjusting down the video rate.
► If there has been no packet loss for the last 30 seconds and the video rate is less then 768kbps because of previous down speeding, the video rate will be up speeded by 5%. If this up speeding does not cause additional losses another up speeding will take place after 10 seconds.
► If the last video up speeding introduces packet loss, it will take another 2 minutes before considering additional up speeding.
► In addition to FEC, ClearPath is also using something called Super P frames. These are reference frames used to synchronize the encoder and decoder whenever you get packet loss. Using Super P frames will considerably reduce the pay load during packet loss environments compared to sending a whole new frame every time a packet is lost. Super P frames will be used at any bandwidth.
► FEC will not be used for dual stream, but Super P frames will.
► FEC and Super P frames will not be used in MultiSite for the dual stream.

Let me know if this answers some of your questions.

Kenny