About QoS Reporting

This section describes the Oracle® Enterprise Session Border Controller QoS reporting. QoS reporting provides you with real-time evaluation of network and route performance. It lets you contrast internal domain and external domain performance and facilitates SLA verification and traffic engineering. Oracle® Enterprise Session Border Controller QoS reporting is a measurement tool that collects statistics on Voice over IP (VoIP) call flows for SIP and H.323. To provide information, the Oracle® Enterprise Session Border Controller writes additional parameters to the Remote Authentication Dial-in User Service (RADIUS) call record. To provide information, the Oracle® Enterprise Session Border Controller writes additional parameters to the Remote Authentication Dial-in User Service (RADIUS) call record and Historical Data Recording (HDR) records.

You can use QoS statistics for SLA customer reporting, fault isolation, SLA verification, and traffic analysis. The Oracle® Enterprise Session Border Controller employs specialized hardware to inspect Real-Time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP) flows while maintaining wire-speed packet forwarding. QoS metrics are collected and reported on a per-session and per call-leg basis. These metrics are reported through real-time RADIUS records along with call accounting data.

Overview

When a conversation is established between two endpoints, two flows are present in each direction:

RTP flow carries traffic between endpoints with a predictable packet arrival rate. The packets headers have sequence numbers that are used to determine whether packets are missing or lost.
RTCP flow carries information about the RTP flow and keeps a different record. The RTCP packets contain timestamps based on Network Time Protocol (NTP).

QoS Statistics

Reported QoS data includes the following per-flow statistics:

RTP and RTCP lost packets—Count of lost packets for both RTP and RTCP based on comparing the sequence numbers since the beginning of the call or the last context memory poll.
RTP and RTCP average jitter—Incremental number of packets for both RTP and RTCP that have been used to generate the total and max jitter since the beginning of the call or the last context memory poll. The incremental accumulated jitter (in milliseconds) over all the packets received.
RTP and RTCP maximum jitter—Maximum single jitter value (in milliseconds) for both RTP and RTCP from all the packets since the beginning of the call or the last context memory poll.
RTCP average latency—Number of RTCP frames over which latency statistics have been accumulated and the incremental total of latency values reported since the beginning of the call or the last context memory poll.
RTCP maximum latency—Highest latency value measured since the beginning of the call or the last context memory poll.
RTP packet count
RTP bytes sent and received
RTCP lost packets—RTP lost packets reported in RTCP packets.
ATP lost packets—Lost packets determined by monitoring RTP sequence numbers.
R-Factor and MOS data—R-Factor and MOS data for the calling and called segments at the end of a session

Incremental QoS Updates

The Interim Quality of Service (QoS) Update setting provides a more granular view of voice quality for troubleshooting by providing updates in 10 second increments. Without the Interim QoS Update setting selected, the Oracle® Enterprise Session Border Controller (E-SBC) probe provides an average Mean Opinion Score (MOS) only at the end of the call. A troubleshooter cannot see what occurred in other parts of the call. For example, suppose your employee or agent complains of poor voice quality that occurred in the middle of the call, but the average MOS score at the end of the call is 4.40. The troubleshooter might determine that the quality is acceptable, without knowing that the score in the middle of the call is 2.50. The Interim QoS Update setting provides MOS scores every 10 seconds, and with more granular data to help troubleshooting efforts.

Standalone Oracle Communications Operations Monitor (OCOM) probes, such as those that run OCOM software on Linux COTS servers, provide MOS scores in 10 second time chunks. With the Interim QoS Update parameter enabled, the data presented in OCOM looks similar whether coming from an E-SBC probe, OCOM probe, or both. To set voice quality sampling in 10 second increments, go to system-config, comm-monitor and enable interim-qos-update.

The E-SBC provides the following data, per ten second interval.

start + end time of the stream
IP 5-tuple information to correlate to SIP sessions
correlation information if available
SSRC of the RTP stream (to be checked)
Codec type
Codec change information (if codecs changed)

The E-SBC provides the following data, per ten second chunk.

jitter
min/avg/max
packet loss
# of packets received
# of packets lost

The E-SBC delivers voice quality details, as follows:

Per RTP stream.
In 10 second increments, where the increment starts on a full minute based on the NTP clock (not the start time of the stream).
Intervals not covering the full 10 seconds do not return a MOS value.

Note:

The comm-monitor VQ reports do not support disabling latching for a stream because the SBC does not have access to the stream source IP address. Latching may be globally disabled via the media-manager object or, dynamically disabled even when globally enabled in media-manager, for example, when a media for a session has been successfully negotiated but the source of the media flow changes.

RADIUS Support

All the QoS statistics go into the RADIUS CDR. If a RADIUS client is configured on the Oracle® Enterprise Session Border Controller, any time a call occurs a record is generated and sent. Only Stop RADIUS records contain the QoS statistic information.

Only RADIUS Stop records contain QoS information. For non-QoS calls, the attributes appear in the record, but their values are always be zero (0). When you review the list of QoS VSAs, please note that “calling” in the attribute name means the information is sent by the calling party and called in the attribute name means the information is sent by the called party.

The following example shows a CDR that includes QoS data:

Wed Jun 13 18:26:42 2007
        Acct-Status-Type = Stop
        NAS-IP-Address = 127.0.0.100
        NAS-Port = 5060
        Acct-Session-Id = "SDgtu4401-c587a3aba59dcae68ec76cb5e2c6fe6f-v3000i1"
        Acme-Session-Ingress-CallId = "8EDDDC21D3EC4A218FF41982146844310xac1ec85d"
        Acme-Session-Egress-CallId = "SDgtu4401-c587a3aba59dcae68ec76cb5e2c6fe6f-v3000i1"
        Acme-Session-Protocol-Type = "SIP"
        Calling-Station-Id = ""9998776565" <sip:9998776565@10.10.170.2:5060>;tag=2ed75b8317f"
        Called-Station-Id = "<sip:7143221099@10.10.170.2:5060>"
        Acct-Terminate-Cause = User-Request
        Acct-Session-Time = 7
        h323-setup-time = "18:24:36.966 UTC JUN 13 2007"
        h323-connect-time = "18:24:37.483 UTC JUN 13 2007"
        h323-disconnect-time = "18:24:44.818 UTC JUN 13 2007"
        h323-disconnect-cause = "1"
        Acme-Session-Egress-Realm = "peer"
        Acme-Session-Ingress-Realm = "core"
        Acme-FlowID_FS1_F = "localhost:65544"
        Acme-FlowType_FS1_F = "PCMA"
        Acme-Flow-In-Realm_FS1_F = "core"
        Acme-Flow-In-Src-Addr_FS1_F = 10.10.170.15
        Acme-Flow-In-Src-Port_FS1_F = 49156
        Acme-Flow-In-Dst-Addr_FS1_F = 10.10.170.2
        Acme-Flow-In-Dst-Port_FS1_F = 31008
        Acme-Flow-Out-Realm_FS1_F = "peer"
        Acme-Flow-Out-Src-Addr_FS1_F = 10.10.130.2
        Acme-Flow-Out-Src-Port_FS1_F = 21008
        Acme-Flow-Out-Dst-Addr_FS1_F = 10.10.130.15
        Acme-Flow-Out-Dst-Port_FS1_F = 5062
        Acme-Calling-RTCP-Packets-Lost_FS1 = 0
        Acme-Calling-RTCP-Avg-Jitter_FS1 = 15
        Acme-Calling-RTCP-Avg-Latency_FS1 = 0
        Acme-Calling-RTCP-MaxJitter_FS1 = 15
        Acme-Calling-RTCP-MaxLatency_FS1 = 0
        Acme-Calling-RTP-Packets-Lost_FS1 = 0
        Acme-Calling-RTP-Avg-Jitter_FS1 = 3
        Acme-Calling-RTP-MaxJitter_FS1 = 44
        Acme-Calling-Octets_FS1 = 957
        Acme-Calling-Packets_FS1 = 11
        Acme-FlowID_FS1_R = "localhost:65545"
        Acme-FlowType_FS1_R = "PCMA"
        Acme-Flow-In-Realm_FS1_R = "peer"
        Acme-Flow-In-Src-Addr_FS1_R = 10.10.130.15
        Acme-Flow-In-Src-Port_FS1_R = 5062
        Acme-Flow-In-Dst-Addr_FS1_R = 10.10.130.2
        Acme-Flow-In-Dst-Port_FS1_R = 21008
        Acme-Flow-Out-Realm_FS1_R = "core"
        Acme-Flow-Out-Src-Addr_FS1_R = 10.10.170.2
        Acme-Flow-Out-Src-Port_FS1_R = 31008
        Acme-Flow-Out-Dst-Addr_FS1_R = 10.10.170.15
        Acme-Flow-Out-Dst-Port_FS1_R = 49156
        Acme-Called-RTCP-Packets-Lost_FS1 = 0
        Acme-Called-RTCP-Avg-Jitter_FS1 = 13
        Acme-Called-RTCP-Avg-Latency_FS1 = 0
        Acme-Called-RTCP-MaxJitter_FS1 = 21
        Acme-Called-RTCP-MaxLatency_FS1 = 0
        Acme-Called-RTP-Packets-Lost_FS1 = 0
        Acme-Called-RTP-Avg-Jitter_FS1 = 0
        Acme-Called-RTP-MaxJitter_FS1 = 3
        Acme-Called-Octets_FS1 = 77892
        Acme-Called-Packets_FS1 = 361
        Acme-Firmware-Version = "C5.0.0"
        Acme-Local-Time-Zone = "Time Zone Not Set"
        Acme-Post-Dial-Delay = 110
        Acme-Primary-Routing-Number = "sip:7143221099@10.10.170.2:5060"
        Acme-Ingress-Local-Addr = "10.10.170.2:5060"
        Acme-Ingress-Remote-Addr = "10.10.170.15:5060"
        Acme-Egress-Local-Addr = "10.10.130.2:5060"
        Acme-Egress-Remote-Addr = "10.10.130.15:5060"
        Acme-Session-Disposition = 3
        Acme-Disconnect-Initiator = 2
        Acme-Disconnect-Cause = 16
        Acme-SIP-Status = 200
        Acme-Egress-Final-Routing-Number = "sip:7143221099@10.10.130.15:5060"
        Acme-CDR-Sequence-Number = 14
        Client-IP-Address = 172.30.20.150
        Acct-Unique-Session-Id = "0832b03cd3a290b3"
        Timestamp = 1181773602