Cisco Cisco Unified Service Monitor 8.6 Weißbuch

Seite von 26
 
White Paper 
 
© 2007 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. 
Page 11 of 26
In a scenario in which the switches are not stacked but have gigabit uplink to an aggregate switch, 
if the number of RTP streams is below 100, then one sensor per switch is excessive. In this 
situation, RSPAN is useful. The configuration done on the switch with SPAN, RSPAN, or ESPAN is 
transparent to the sensor; the sensor functions normally as long as it sees the RTP stream. 
For cases in which RSPAN is not a desirable configuration or not an approved configuration, a 
simple active hub can be used to connect the individual SPAN port from the various switches, and 
the sensor can be deployed on the hub. It is very important to keep spanning tree loops in mind 
when such a configuration is attempted. The use of a hub must be selected as a last resort. 
SPAN Port Limitation 
SPAN ports are widely used to connect packet sniffers for troubleshooting. In the contact center 
world, the SPAN port is used to record the voice conversation. In the service monitor world, the 
SPAN port is used to monitor voice quality. If the SPAN port is required for a packet sniffer, contact 
center, and Service Monitor at the same time, the SPAN port does not allow configuration of the 
same source port tied to multiple SPAN destination ports. This is a limitation of SPAN port 
configuration. The only alternative is to use an active splitter that offers one-to-many streams. The 
simplest splitter must be an active hub that offers a one-to-many stream. In this model, the packet 
sniffer, contact center application, and sensor connect to the hub, and the hub connects to the 
SPAN destination port on the switch. 
It is also recommended that all fax devices be aggregated in one voice gateway, and the 1040s not 
span the switch to which the gateway is connected. Currently the 1040 is known not to correctly 
handle certain cases of calls going to fax machines. 
Cisco Voice Transmission Quality-Based Call Quality—K-Factor 
K-factor (Klirrfaktor) is a mean opinion score (MOS) estimator of the endpoint type defined in ITU 
standard P.564. This standard relates to the testing and performance requirements of such a 
device. K-factor predates the standard. A P.564-compliant version will follow. K-factor is trained 
using thousands of speech samples and impairment scenarios, along with target P.862.1 MOS 
scores for each scenario. The trained K-factor device in the IP phone or gateway can then 
recognize the current impairment and produce a running MOS score prediction. 
R-factor is based on three dimensions: loss, delay, and echo. K-factor and other P.564 MOS 
estimators measure only packet loss, which is a network effect. They are packet loss metrics 
projected onto a psychological scale. In general, primary statistics (packet loss, jitter, and 
concealment ratio) show visible degradation well before MOSs start to degrade. Hence, MOSs are 
a secondary indication of network problems, because it is essentially a packet loss metric. Packet 
loss counts, jitter, concealment ratio, and concealment second counters are primary statistics, 
based on direct observation. MOSs are a secondary statistic. Hence, you should use MOSs as a 
flag, but then use primary statistics to investigate or qualify the alarm. Use primary metrics in SLAs 
rather than MOSs. 
Cisco Voice Transmission Quality–based call quality reports can be obtained using Service Monitor 
in conjunction with Cisco Unified Communications Manager and the latest Cisco Unified IP Phones 
and Cisco Gateways.  
When to Use Cisco Voice Transmission Quality-Based Call Quality Reporting 
Some key points to keep in mind when choosing to go with Cisco Voice Transmission Quality–
based call quality reporting are: