Topic Last Modified: 2012-11-12
The Server Media Quality Trend Report provides a way for you to graphically compare up to 5 servers on Quality of Experience metrics such as call volume, poor call percentage, packet loss, and jitter. This makes it easier to do such things as identify servers that are performing poorly, identify servers that are underutilized, or identify servers that are being overused.
Accessing the Server Media Quality Trend Report
The Server Media Quality Trend Report can be accessed from either one of the following report:
-
Server Performance Report (by clicking the Trend metric)
-
Call Detail Report (by clicking the A/V edge server metric. If the caller or callee is a server, you can also reach the Server Quality Media Trend Report by clicking the endpoint name.)
Making the Best Use of Server Media Quality Trend Report
When you click the Trend metric on the Server Performance Report for a specific server, the Server Media Quality Trend Report will open. However, you will see only a blank instance of that report; the server you selected on the Server Performance Report will not be displayed onscreen. Instead, you will need to select that server from the Servers dropdown. Note, too that the Servers dropdown includes a Select All option. This option will not work if you have more than 5 servers; the Server Media Quality Trend Report can only display data for a maximum of 5 servers at a time.
On the graphs displayed by the Server Media Quality Trend Report, the points labeled Call Volume and Poor Call Percentage are hotlinks; clicking a point on the graph will open an instance of the Call List Report showing the total calls (or poor calls) for the specified time period.
Filters
Filters provide a way for you to return a more finely-targeted set of data or to view the returned data in different ways. The following table lists the filters that you can use with the Server Media Quality Trend Report.
Server Media Quality Trend Report Filters
Name | Description |
---|---|
From |
Start date/time for the time range. To view data by hours, enter both the start date and time as follows: 7/7/2012 1:00 PM If you do not enter a start time, the report automatically begins at 12:00 AM on the specified day. To view data by day, enter just the date: 7/7/2012 To view by week or by month, enter a date that falls anywhere within the week or month that you want to view (you do not have to enter the first day of the week or month): 7/3/2012 Weeks always run from Sunday through Saturday. |
To |
End date/time for the time range. To view data by hours, enter both the end date and time as follows: 7/7/2012 1:00 PM If you do not enter an end time, the report automatically ends at 12:00 AM on the specified day. To view data by day, enter just the date: 7/7/2012 To view by week or by month, enter a date that falls anywhere within the week or month that you want to view (you do not have to enter the first day of the week or month): 7/3/2012 Weeks always run from Sunday through Saturday. |
Interval |
Time interval. Select one of the following:
If the start and end dates exceed the maximum number of values allowed for the selected interval, only the maximum number of values (starting from the start date) is displayed. For example, if you select the Daily interval with a start date of 8/7/2012 and an end date of 9/28/2012, data is displayed for the days 8/7/2012 12:00 AM to 9/7/2012 12:00 AM (that is, a total of 31 days' worth of data). |
Server type |
Type of server involved in the call. Allowed values are:
|
Servers |
Name of the server involved in the session; this dropdown list is automatically populated for you based on the value of the Server type filter. You can select up to 5 different servers when compiling a report. |
Access type |
Indicates whether the participant was logged on to the internal network or from the external network. Allowed values are:
|
Network type |
Indicates the type of network the participant was connected to. Allowed values are:
|
VPN |
Indicates whether an external participant was using a virtual private network (VPN) connection during the session. Allowed values are:
|
Metrics
The following table lists the information provided in the Server Media Quality Trend Report.
Server Media Quality Trend Report Metrics
Name | Can you sort on this item? | Description |
---|---|---|
Call volume |
No |
Total number of calls. |
Degradation (MOS) |
No |
Average amount of MOS (mean option score) degradation experienced during a call. Degradation values can range from a low of 0.0 to a high of 5.0; a value of 0.5 or less represents acceptable degradation. Historically, mean options scores were calculated by having users rate the quality of a call on a scale of 1-to-5. Lync Server uses a set of algorithms to predict how users would have rated a call. High degradation values can be caused by congestion; lack of bandwidth; wireless congestion or interference, or an overloaded media server or endpoint. High degradation results in distorted or lost audio. |
Poor call percentage |
No |
The total number of calls classified as poor. A poor call is any call which at least one of the measured metrics exceeded the allowed value (for example, a call that experienced excessive jitter). |
Round trip (ms) |
No |
Average amount of time (in milliseconds) required for a Real-Time Transport Protocol packet to travel to one endpoint and then back. Round-trip times of 200 milliseconds or less are considered of acceptable quality. High round-trip values can be caused by international call routing; a routing misconfiguration; or an overloaded media server. High round-trip times result in difficulties with two-way, real-time audio conversations. |
Packet loss |
No |
Average rate of Real-Time Transport Protocol (RTP) packet loss. (Packet loss occurs when RTP packets, a protocol used for transmitting audio and video across the Internet, failed to reach their destination.) High loss rates are generally caused by congestion; lack of bandwidth; wireless congestion or interference; or an overloaded media server. Packet loss typically results in distorted or lost audio. |
Jitter (ms) |
No |
Average jitter detected between RTP packet arrivals. (Jitter is a measure of the "shakiness" of a call.) High jitter values are typically caused by congestion or an overloaded media server, and result in distorted or lost audio. |
Healer concealed ratio |
No |
Average ratio of concealed audio samples to the total to the total number of samples. (A concealed audio sample is a technique used to smooth out the abrupt transition that would usually be caused by dropped network packets.) High values indicate significant levels of loss concealment applied caused by packet loss or jitter, and results in distorted or lost audio. |
Healer stretched ratio |
No |
Average ratio of stretched audio samples to the total to the total number of samples. (Stretched audio is audio that has been expanded to help maintain call quality when a dropped network packet has been detected.) High values indicate significant levels of sample stretching caused by jitter, and result in audio sounding robotic or distorted. |
Healer compressed ratio |
No |
Average ratio of compressed audio samples to the total number of samples. (Compressed audio is audio that has been compressed to help maintain call quality when a dropped network packet has been detected.) High values indicate significant levels of sample compression caused by jitter, and result in audio sounding accelerated or distorted. |