Q. What is Cisco® TelePresence Readiness Assessment Manager 1.0?
A. Cisco TelePresence Readiness Assessment Manager 1.0 is a software product that assesses network paths prior to the deployment of TelePresence systems and prior to site extensions or TelePresence model upgrades. Using Cisco TelePresence Readiness Assessment Manager, device and network issues can be proactively determined, facilitating the expected rich quality and experience of TelePresence after its deployment. The benefits of TelePresence Readiness Assessment Manager include accelerated TelePresence deployment and reduction in effort and time through automation of the assessment process and consistent assessment criteria as well as reporting. Cisco TelePresence Readiness Assessment Manager is composed of central management software that runs on the Windows XP/Windows 2003 server or laptop platform and media traffic analysis agents (MTAAs) that run on the Windows XP server or laptop platform. Cisco TelePresence Readiness Assessment Manager 1.0 is part of the Cisco Unified Communications Management Suite.
Q. What readiness assessment scenarios does Cisco TelePresence Readiness Assessment Manager 1.0 address?
A. Cisco TelePresence Readiness Assessment Manager 1.0 addresses the following readiness assessment scenarios:
• Predeployment network assessment
• Reassessment while adding new or additional sites or upgrading a TelePresence model
• Verification after configuration update.
Q. What are the features and benefits of Cisco TelePresence Readiness Assessment Manager 1.0?
A. The key features and benefits of Cisco TelePresence Readiness Assessment Manager 1.0 are:
• Automated network path discovery: Discovers the network elements on the paths between proposed TelePresence sites or rooms
• Automated best practice compliance analysis: Determines network device configuration compliance with best practices recommendations
• Switch and line-card recommendations: Determines and flags noncompliance of line cards in the network path with recommendations for TelePresence deployment
• End-of-sale/end-of-life detection: Determines and flags the end-of-sale/end-of-life status of the devices in the network path
• TelePresence traffic simulation and analysis: Simulates TelePresence traffic among strategically deployable software agents and calculates the quality metrics; determines and flags network paths where quality metrics violate TelePresence traffic quality recommendations
• Resource utilization baseline determination: Determines resource utilization for the devices on the network path in order to detect capacity bottlenecks
• Comprehensive reports: Generates comprehensive executive and detailed reports, which contain the assessment results and recommendations. The information in the reports is presented using charts, graphs, and text. The reports are in Microsoft Word format, and assessors can modify them to include expert comments and recommendations.
• Northbound interfaces: Sends workflow status information by e-mail or pager to subscribers. This helps assessors to get back to the system and perform the next step in the workflow.
Q. Where do I find ordering information? Is an evaluation copy available?
A. Please refer to the Cisco TelePresence Readiness Assessment Manager 1.0 product bulletin for ordering information. For pricing and to place an order, please visit the Cisco Ordering Homepage. A limited-use evaluation copy of the product can be obtained from www.cisco.com/go/ctram for trial and evaluation purposes. Use of the evaluation software is limited to 15 days and 2 TelePresence rooms, and only executive reports are available. For more information about Cisco TelePresence Readiness Assessment Manager 1.0, please visit http://www.cisco.com/go/ctram or contact your local account representative.
Q. Who is the product intended for?
A. Target customers for the product include channel/deployment partners, system integrators, consulting organizations, approved technology partners, and large enterprise customers who can use it for readiness assessment and to achieve success in deploying the Cisco TelePresence solution.
Q. How similar is the traffic generated by an MTAA to real Cisco TelePresence System traffic?
A. Traffic generation is accomplished by taking samples of real Cisco TelePresence System traffic. Various combinations of resolution (1080 by 720), quality (good/better/best), and motion (low/high) are captured to provide a set of 12 traffic profiles on which the simulation is based. Using the "live" traffic as a baseline, an MTAA generates simulated streams with the same interpacket send time, payload size, and other key header information that represents the H.264 video description information in the real traffic. The actual payload is random data (this is not actual video payload). Because the captures were limited to 5 minutes, the traffic pattern repeats every 5 minutes. All captures taken are from a single video and audio source. When an MTAA simulates a Cisco TelePresence System 3000 (three video and audio sources), it uses the single profiles and multiplexes the data in the same manner that the actual Cisco TelePresence System would multiplex the data. In addition to video, the audio streams are simulated in the same manner.
Q. How is latency calculated in the results reported by an MTAA?
A. MTAA latency is computed as the difference between the packet received time and packet sent time for every 100th packet received. The packet sent time is embedded in the Real-Time Transport Protocol (RTP) payload, and the analyzer will retrieve the time stamp when decoding the RTP packets. It is assumed that both the sender and receiver are time synchronized to the same Network Time Protocol (NTP) time source. Synchronization information is exchanged between the agents to account for time offsets. If one or both systems cannot achieve time synchronization, then latency information is not reported. For each 30-second interval, an MTAA reports the average latency of all packets for the interval.
Cisco TelePresence System latency is measured using RTCP (RTP Control Protocol) packets. An RTCP APP ECHO request packet is sent to its remote endpoint (or multipoint entity). The remote endpoint (or multipoint entity) then sends an RTCP APP ECHO reply packet in response. The latency is measured as the difference between the time the request packet is sent and the time the reply packet is received. This method can be used to obtain a round-trip latency. A one-way latency approximation is taken by dividing the round-trip latency by two. The RTCP echo packet is sent once a second, and the latency measurements are accumulated and averaged over a 10-second interval.
Q. How is jitter calculated in the results reported by an MTAA?
A. MTAA jitter is computed based on RFC 3550. Below is a snippet from RFC 3550 that describes the formula for calculating jitter. The key factors to point out are that jitter is calculated continuously as each packet is received, and it is smoothed by the RFC formula. This jitter reported is the value at the end of the 30-second interval.
An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. As shown in the equation below, this is equivalent to the difference in the "relative transit time" for the two packets; the relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at the time of arrival, measured in the same units.
If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as
The interarrival jitter SHOULD be calculated continuously as each data packet i is received from source SSRC_n, using this difference D for that packet and the previous packet i-1 in order of arrival (not necessarily in sequence), according to the formula
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
Cisco TelePresence System jitter is measured as frames are incoming or received from the network. There are two methods for measuring jitter: using the first packet of the frame or using the last packet of the frame. The method that is actually used is determined during the first 30 seconds of the call based on whichever method results in the smallest jitter for that source. The RTP packet payload time stamp is used to measure jitter. Note: this jitter logic applies to both the video and audio streams. But for audio, since there are two frames per packet, the first and last packet are always the same when taking the jitter measurement. For video, there are multiple packets per frame so taking a measurement from the first or last packet may make some difference when reporting jitter statistics.
The jitter value is calculated as the distance between the maximum variance of packets arriving early and the maximum variance of a packet arriving late over a given 10-second interval. For example:
Actual Time= 1000 1035 1070 1099 1131
Expected = 1000 1033 1066 1099 1132
Offset = 0 +2 +4 0 -1
Max Late = 4 (absolute)
Max Early = 1 (absolute)
Jitter = 5
Q. How is packet loss calculated in the results reported by an MTAA?
A. MTAA packet loss is reported as the sum of the packets that have been lost in transmission (network packet loss) and the number of packets assumed to be discarded due to being late (packet discards) divided by the total number of packets that were expected to have been sent during the 30-second interval. The packet loss percentage is calculated for each RTP stream.
This first component, network packet loss, is calculated by inspecting the RTP headers for each stream for a period of 30 seconds and, from those sequence numbers, determining the ones that are missing. This can be easily accomplished because the sequence numbers simply increment by one for each packet sent in a given RTP stream. Duplicate packets are not counted toward the total packets received, and out-of-order packets do not result in lost packets if they arrive in time for playout.
The second component, packet discards, is determined by emulating a jitter buffer to determine which packets (or frames in the case of the video stream) will arrive too late and will be discarded. The playout buffer for both the video and audio have been fixed to 66 milliseconds. This equates to approximately two video frames for the codec used by Cisco TelePresence. Packets arriving outside this window will be considered late and will be discarded. Currently, an MTAA will count these packets toward the overall packet loss percentage that is reported.
The Cisco TelePresence System packet loss calculation is performed every 10 seconds. During this period the number of lost, late, and total received packets are counted. Packets are considered lost when there is an RTP sequence number gap between adjacently received packets in the same manner as an MTAA calculates network packet loss. Packets are considered late when they do not arrive in time to be sent to the hardware. This is consistent with the method an MTAA uses to emulate the playout buffer.
Q. Do I really need a dedicated platform to run an MTAA?
A. The requirement to have a dedicated machine is due to the lack of control over other processes running within your computing environment. There is really nothing preventing users from installing this on the laptop that they use for other applications. However, since the application is designed to generate traffic like a real TelePresence system, CPU cycles spent on other applications running on the system may introduce additional delay in the sending of packets on their scheduled time slot. This results in a traffic profile that is slower than the real TelePresence traffic (that is, the frames may not be transmitting at a 33-millisecond rate).
In addition, Microsoft Windows is not a real-time operating system. An MTAA time-stamps packets just prior to sending them out so the receiving MTAA can make calculations for jitter and latency. If many applications are competing for the CPU, there is increased probability of MTAA latency and jitter measurements and calculations being affected. There is no definitive way to determine that this is occurring, and this anomaly cannot be differentiated from real network jitter/latency. Therefore, it is recommended that a dedicated system be used, where no other applications are running. All applications and processes not related to the MTAA should be disabled.
Q. What switch and router configuration considerations must be made when placing an MTAA on a network?
A. MTAAs support VLAN tagging for voice traffic; however the management traffic is untagged, as VLAN support in the Windows operating system is limited. To help ensure proper voice and management traffic handling at the same time, the voice traffic on the switch access ports should be configured to be sent on the access VLAN. MTAAs should be configured with IP addresses in the access VLAN as well.
MTAAs allow user configurable type of service (ToS)/differentiated services code point (DSCP) values, and the ToS fields are subject to change during the course of transmission depending on the QoS setting of the routers on each hop. The routers may define their own QoS settings to facilitate proper voice traffic priority. Therefore, the destination ToS values may be different from the ToS values set in the sender.
Q. Can an MTAA autodetect the voice VLAN and place itself into the correct network?
A. MTAAs have the capability to detect the voice VLAN by inspecting the Cisco Discovery Protocol messages from the neighboring switch. However, when the voice VLAN is different from the access VLAN, an MTAA cannot acquire an IP address in the correct voice VLAN using Dynamic Host Configuration Protocol (DHCP) nor can it tag the management traffic (signaling between agents and requests from the Cisco TelePresence Readiness Assessment Manager server) with the voice VLAN tag. This is due to the limited VLAN support in the Windows XP operating system.
Q. Can I simply assign an MTAA a static IP address in the voice VLAN?
A. You can assign an MTAA a static IP address in the voice VLAN only if the switch port is configured to use the access VLAN for voice. The solution requires HTTP traffic between the MTAA and Cisco TelePresence Readiness Assessment Manager. Those packets are not VLAN tagged and will be discarded if the switch requires VLAN tagged packets.