KPIs
The KPI Metrics is a standards of measurement by which efficiency, performance, progress, or quality of the platform are assessed.
The following KPI categories are described:
Platform-Wide and Prefix Tag KPIs
Table 20-1 describes the Operations Monitor platform-wide and prefix tag KPIs, where:
The platform-wide KPIs provide data about the overall signaling of the network, such as the total number of calls across all devices.
The prefix tag KPIs provide data about traffic that is specific to the selected prefix number.
Table 20-1 Platform Wide and Prefix Tag KPIs
Path | KPI Metric | Applicable | Parameter | Description |
---|---|---|---|---|
Default |
Active calls |
Platform, Prefix tag |
- |
Number of established concurrent calls. Counts end-to-end calls (an end-to-end call can comprise of several correlated call legs). |
Default |
Registered users |
Platform, Prefix tag |
- |
Number of registered users with at least one active binding/contact. Counts only once if a user is registered with multiple contacts or on multiple servers. |
Default |
Registered contacts |
Platform, Prefix tag |
- |
Number of registered contacts. Each active binding/contact is counted if a user is registered with multiple contacts or on multiple servers. |
Default |
Call attempts since startup |
Platform, Prefix tag |
- |
Number of call attempts counted since the core process started. Counts end-to-end calls (an end-to-end call can comprise of several correlated call legs). |
Default |
Call attempts for each second (CAPS) |
Platform, Prefix tag |
- |
Number of call attempts for each second. Counts end-to-end calls (an end-to-end call can comprise of several correlated call legs). |
Default |
Calls established |
Platform, Prefix tag |
- |
Number of established calls for each second. Counts end-to-end calls (an end-to-end call can comprise of several correlated call legs). |
Default |
Closed calls for each second |
Platform, Prefix tag |
- |
Number of calls that finished for each second. Counts end-to-end calls (an end-to-end call can comprise of several correlated call legs). |
Default |
Register attempts for each second |
Platform, Prefix tag |
- |
Number of completed SIP REGISTER transactions for each second |
IETF KPIs and metrics |
Ineffective registration attempts |
Platform, Prefix tag |
- |
Ineffective registration attempts are utilized to detect failures or impairments causing an inability for a registrar to receive a UA REGISTER request.A failed registration attempt is a final failure response to the initial REGISTER request. It indicates a failure received from the destination registrar, interim proxies, or due to a timeout of the REGISTER request at the originating UA.A failure response is described as a 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or possible 6XX message.IRA may be used to detect problems in downstream signaling functions, which may be impairing the REGISTER message from reaching the intended registrar; or, it may indicate a registrar has become overloaded and is unable to respond to the request.Calculated as a percentage of failed and timed-out REGISTER transactions out of all REGISTER transactions. |
IETF KPIs and metrics |
Ineffective registration attempts by code |
Platform, Prefix tag |
Lower bound for the code Upper bound for the code |
Percentage of SIP REGISTER transactions that failed with a response code in the given range out of all REGISTER transactions. |
IETF KPIs and metrics |
Session establishment ratio (SER) |
Platform, Prefix tag |
- |
This metric is used to detect the ability of a terminating UA or downstream proxy to successfully establish sessions per new session INVITE requests. SER is defined as the ratio between the number of new session INVITE requests resulting in a 200 OK response to the total number of attempted INVITE requests less INVITE requests resulting in a 3XX response. This metric is similar to Answer Seizure Ratio (ASR) in telephony applications of SIP. |
IETF KPIs and metrics |
Session Establishment Effectiveness Ratio (SEER) |
Platform, Prefix tag |
- |
SEER is defined as follows: SEER = (Number of INVITE requests resulting in a 200 OK, 480, 486, 600, or 603 response)/(Total number of attempted INVITE requests - Number of INVITE requests resulting in a 3XX response) The response codes 480, 486, 600, and 603 were chosen as they indicate the effect of an individual user of the UA. It is possible that an individual user could cause a negative effect on the UA. For example, they may have incorrectly configured the UA causing a response code not directly related to a SSP, but this cannot be easily determined from an intermediary B2BUA somewhere in between the originating and terminating UA. With this in consideration, response codes such as 401, 407, and 420 (not an exhaustive list) are not included in the numerator of the metric.
This metric is similar to Network Effectiveness Ratio (NER). KPI value is a percentage that takes only INVITEs on ingress legs into account. |
IETF KPIs and metrics |
Session defects ratio |
Platform, Prefix tag |
- |
Session defects provide a subset of SIP failure responses, which consistently indicate a failure in dialog processing. Defects are necessary to provide input to calculations such as Defects for each Million (DPM) or other similar metrics. These failure responses are in response to initial session setup requests, such as a new INVITE. The following failure responses provide a guideline for defective criterion:
KPI value is a percentage that takes only INVITEs on ingress legs into account. |
IETF KPIs and metrics |
Ineffective session attempts ratio |
Platform, Prefix tag |
- |
Ineffective session attempts occur when a proxy or agent internally releases a setup request with a failed or overloaded condition. This metric is similar to Ineffective Machine Attempts (IMA) in telephony applications of SIP. The following failure responses provide a guideline for this criterion:
KPI value is a percentage that takes only INVITEs on ingress legs into account. |
IETF KPIs and metrics |
Session disconnect failure ratio |
Platform, Prefix tag |
- |
Session disconnect failures occur when an active session is terminated due to a failure condition that can be identified by a REASON header in a BYE message. This occurs, for example, when a user agent (UA) is controlling an IP or TDM (Time Division Multiplexing) media gateway, and the media gateway notifies the UA of a failure condition causing the loss of media related to an established session. The REASON value is utilized to determine whether the disconnect was a failure. This metric is similar to Cutoff Calls (CC) in telephony applications of SIP. KPI value is a percentage that takes only INVITEs on ingress legs into account. |
IETF KPIs and metrics |
Successful session completion ratio |
Platform, Prefix tag |
- |
This metric is defined as the ratio between successfully completed sessions and the total number of session attempts. A successfully completed session is when it begins with a setup request and ends with a session completion message. This metric is similar to Call Completion Ratio (CCR) in telephony applications of SIP. KPI value is a percentage that takes only INVITEs on ingress legs into account. |
IETF KPIs and metrics |
Failed session completion ratio |
Platform, Prefix tag |
- |
Session completion fails when an INVITE is sent from the originating UA, but there is no indication the INVITE reached the target UA. This can also occur if the target UA does not respond to the INVITE or the response never reaches the target UA associated with the session. KPI value is a percentage that takes only INVITEs on ingress legs into account. |
IETF KPIs and metrics |
Session success ratio |
Platform, Prefix tag |
- |
Session success ratio is defined as the percentage of successfully completed sessions compared to sessions that fail due to ISA or SDF. This metric is also known as Call Success Ratio (CSR) in telephony applications of SIP. KPI value is a percentage that takes only INVITEs on ingress legs into account. |
IETF KPIs and metrics |
Combined maximum successful session request delay |
Platform, Prefix tag |
- |
This metric combines the ISUP Post Dial Delay (PDD) and SIP Session Request Delay (SRD) into a single metric. SSRD is defined as the time interval from the first bit of the initial INVITE message containing the information sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received indicating an audible or visual status of the initial session setup request. |
IETF KPIs and metrics |
Combined maximum failed session request delay |
Platform, Prefix tag |
- |
This metric combines the ISUP Post Dial Delay (PDD) and SIP Session Request Delay (SRD) into a single metric. Failed Session Request Delay (FSRD) is the time interval from the first bit of the initial INVITE message containing the information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. A failure response is described as a 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or possible 6XX message. |
IETF KPIs and metrics |
Combined maximum session request delay |
Platform, Prefix tag |
- |
This metric combines the ISUP Post Dial Delay (PDD) and SIP Session Request Delay (SRD) into a single metric. Session Request Delay (SRD) is utilized to detect failures or impairments causing a delay in responding to a UA session request. SRD is measured for both successful and failed session setup requests as this metric relates to the user experience. It is recommended that the SSRD and the FSRD are used instead of SRD as the time greatly varies between the two. SRD is similar to Post-Selection Delay from telephony applications. |
IETF KPIs and metrics |
Session disconnect delay |
Platform, Prefix tag |
- |
Session Disconnect Delay (SDD) is the time interval between the first bit of the sent session completion message, such as a BYE, and the last bit of the subsequently received 2XX response. |
IETF KPIs and metrics |
Session duration time |
Platform, Prefix tag |
- |
Session Duration Time (SDT) is utilized to detect technical issues causing short session durations. For example, poor audio quality. SDT is defined as an average of duration of the interval between receipt of the first bit of a 200 OK response to an INVITE plus the receipt of the last bit of an associated BYE message. Retransmissions of the 200 OK and ACK messages due to network impairments do not reset the metric timers. |
IETF KPIs and metrics |
Average successful session request delay |
Platform, Prefix tag |
- |
Average of all per-leg SSRD values for a second. SSRD is defined as the time interval from the first bit of the initial INVITE message containing the information sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received, indicating an audible or visual status of the initial session setup request. Calculated based on the timings of the state-defining leg of a call. |
IETF KPIs and metrics |
Average failed session request delay |
Platform, Prefix tag |
- |
Average of all per-leg FSRD values for a second. Failed Session Request Delay (FSRD) is the time interval from the first bit of the initial INVITE message containing the information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. Calculated based on the timings of the state-defining leg of a call. |
IETF KPIs and metrics |
Maximum successful session request delay |
Platform, Prefix tag |
- |
Maximum of all per-leg SSRD values for a second. SSRD is defined as the time interval from the first bit of the initial INVITE message containing the information sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received, indicating an audible or visual status of the initial session setup request. Calculated based on the timings of the state-defining leg of a call. |
IETF KPIs and metrics |
Maximum failed session request delay |
Platform, Prefix tag |
- |
Maximum of all per-leg FSRD values for a second. Failed Session Request Delay (FSRD) is the time interval from the first bit of the initial INVITE message containing the information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. Calculated based on the timings of the state-defining leg of a call. |
Advanced metrics |
Number of ISUP Q.850 cause codes |
Platform, Prefix tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of ISUP call segments that finished or failed with a cause code in the given range. |
Advanced metrics/ Network/ TCP |
Total number of active TCP streams |
Platform |
- |
Total number of TCP streams being tracked. |
Advanced metrics/ Network/ TCP |
Number of TCP streams created |
Platform |
- |
Number of new TCP streams for each second. |
Advanced metrics/ Network/ TCP |
Number of TCP streams timed out |
Platform |
- |
Number of TCP streams for each second that timed out. |
Advanced metrics/ Network/ TCP |
Number of TCP ACK messages |
Platform |
- |
Number of TCP SYN messages. |
Advanced metrics/ Network/ TCP |
Number of TCP SYN messages |
Platform |
- |
Number of TCP ACK messages. |
Advanced metrics/ Network/ TCP |
Number of TCP RST messages |
Platform |
- |
Number of TCP RST messages for each second. |
Advanced metrics/ Network/ TCP |
Number of TCP FIN Messages |
Platform |
- |
Number of TCP FIN messages for second. |
Advanced metrics/ Network/ SCTP |
Number of SCTP DATA chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP INIT chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP INIT ACK chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP SACK chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP HEARTBEAT chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP HEARTBEAT ACK chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP ABORT chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP SHUTDOWN chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP SHUTDOWN ACK chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP ERROR chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP COOKIE ECHO Chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP ECNE chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP CWR chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP SHUTDOWN COMPLETE chunks |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of active SCTP associations |
Platform |
- |
- |
Advanced metrics/ Network/ SCTP |
Number of SCTP associations created |
Platform |
- |
Total number of SCTP associations being tracked. |
Advanced metrics/ Network/ SCTP |
Number of SCTP associations created |
Platform |
- |
Number of new SCTP associations for each second. |
Advanced metrics/ Network/ SCTP |
Number of SCTP packets |
Platform |
- |
Number of SCTP packets for each second. |
Advanced metrics/ Network |
Number of IPv4 packets |
Platform |
- |
Number of IPv4 packets for each second. |
Advanced metrics/ Network |
Number of IPv6 packets |
Platform |
- |
Number of IPv6 packets for each second. |
Advanced metrics/SIP Traffic |
SIP requests |
Platform |
- |
Number of SIP requests for each second. |
Advanced metrics/SIP Traffic |
SIP replies |
Platform |
- |
Number of SIP replies for each second. |
Advanced metrics/SIP Traffic |
Number of SIP requests with a given method name: REGISTER requests |
Platform |
- |
Number of SIP REGISTER request messages for each second. |
Number of SIP REGISTER request messages for each second |
Number of SIP requests with a given method name |
Platform |
- |
Number of SIP requests with the given method name for each second. |
Advanced metrics/SIP traffic |
Number of SIP responses with a given response code |
Platform |
Minimum answer code Maximum answer code |
Number of SIP answer messages for each second with a response code in the given range. |
Advanced metrics/SIP traffic |
Number of SIP messages over a given transport protocol |
Platform |
Transport protocol (UDP, TCP, SCTP) |
Number of SIP messages for each second over the given transport protocol. |
Advanced metrics/SIP traffic |
Number of fragmented UDP SIP messages |
Platform |
- |
Number of SIP messages for each second that were received in multiple UDP fragments. |
Advanced metrics/ Megaco/ H.248 |
Number of Megaco legs created |
Platform |
- |
Number of new Megaco legs for each second. |
Advanced metrics/ Megaco/ H.248 |
Number of active Megaco legs |
Platform |
- |
Total number of Megaco legs. |
Advanced metrics/ Megaco/ H.248 |
Number of Megaco legs that finished |
Platform |
- |
Number of Megaco legs that finished for each second. |
Advanced metrics/ Megaco/ H.248 |
Number of Megaco legs that finished after a completed SDP negotiation |
Platform |
- |
Number of Megaco legs that finished for each second with a previous complete SDP negotiation. |
Advanced metrics/ Megaco/ H.248 |
Percentage of finished Megaco connections with a complete SDP negotiation |
Platform |
- |
Percentage of finished Megaco legs with a complete SDP negotiation (out of all finished Megaco legs). |
Advanced metrics/ MGCP |
Number of MGCCP legs created |
Platform |
- |
Number of new MGCP legs for each second. |
Advanced metrics/ MGCP |
Number of active MGCP legs |
Platform |
- |
Total number of MGCP connections being active. |
Advanced metrics/ MGCP |
Number of MGCP legs that finished |
Platform |
- |
Number of MGCP legs that finished for each second. |
Advanced metrics/ MGCP |
Number of MGCP legs that finished after a complete SDP negotiation |
Platform |
- |
Number of MGCP legs that finished for each second where a complete SDP negotiation happened before. |
Advanced metrics/ MGCP |
Percentage of finished MGCP connections with a complete SDP negotiation |
Platform |
- |
Percentage of finished MGCP connections with a complete SDP negotiation (out of all finished MGCP connections). |
Advanced metrics/SIP transactions |
Number of completed transactions |
Platform |
- |
Number of completed SIP transactions for each second. |
Advanced metrics/SIP transactions |
Number of completed transactions with a given method name |
Platform |
Transaction Method |
Number of completed SIP transactions for each second with a given method name. |
Advanced metrics/SIP transactions |
Number of completed transactions with a given method name and response code |
Platform |
Transaction method Minimum answer code Maximum answer code |
Number of completed SIP transactions for each second with a given method name and a response code in the given range. |
Advanced metrics/SIP transactions |
Number of completed transactions with a given response code |
Platform |
Minimum answer code Maximum answer code |
Number of completed SIP transactions for each second with a response code in the given range. |
Advanced metrics/SIP transactions |
Number of timeout transactions |
Platform |
- |
Number of SIP transactions for each second that timed out, for example, did not see a final response in time. |
Advanced metrics/SIP transactions |
Number of completed transactions with the number of request retransmissions bigger than a given value |
Platform |
Method to monitor Minimum number of retransmissions |
Number of SIP transactions with a given method name for each second where the number of retransmissions was at least the configured count. |
Advanced metrics/SIP transactions |
Number of INVITE transactions completed with a code > 299 with the number of retransmissions of the final response bigger than a given value |
Platform |
Minimum number of retransmissions |
Number of SIP INVITE transactions for each second that failed (response code > 299) where the final response was retransmitted at least the number of configured times. |
Advanced metrics/SIP transactions |
Number of timeout transactions with a certain method |
Platform |
Method to Monitor |
Number of SIP transactions for each second with a given method name that timed out, for example, did not see a final response. |
Advanced metrics/SIP transactions |
Maximum response time |
Platform |
- |
Displays the maximum response time, platform wide, in any given second. All non-INVITE transactions are taken into account. |
Advanced metrics/ Calls |
Number of calls ended because of a session timeout |
Platform, Prefix tag |
- |
Number of end-to-end calls (an end-to-end call can comprise of several correlated call legs) for each second that stopped being monitored because they were longer than the threshold (System setting, Session-timeout for calls). |
Advanced metrics/ Calls |
Number of currently active calls |
Platform, Prefix tag |
Relevant Call State |
Number of concurrent calls that are in the given call state. |
Advanced metrics/ Calls |
Number of calls with a given call length |
Platform, Prefix tag |
Call length (milliseconds>= Call length (milliseconds)< |
Number of calls for each second that finished after being established for a time in the given range. |
Advanced metrics/ Calls |
Number of calls with a given ringing time |
Platform, Prefix tag |
Ringing time (milliseconds)>= Ringing time (milliseconds)< |
Number of calls for each second that were established after ringing for a time in the given range. |
Advanced metrics/ Calls |
Number of calls with Q.850 cause codes |
Platform, Prefix tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of SIP or ISUP calls for each second where one of the segments finished or failed and received a Q.850 reason (SIP) or cause value (ISUP) in the given range. |
Advanced metrics/ Calls |
Number of SIP calls with Q.850 cause codes in headers |
Platform, Prefix tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of calls for each second where a SIP segment finished or failed and a Reason header contained a Q.850 cause value in the given range. |
Advanced metrics/ Calls |
Number of ISUP calls with Q.850 cause codes |
Platform, Prefix tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of calls for each second where an ISUP segment finished or failed with a cause value in the given range. |
Advanced metrics/ Calls |
SDP declared RTP Transcoding |
Platform, Prefix tag |
Transcoding type Predicate type |
Number of times for each second when an RTP transcoding event was detected within a SIP call.RTP transcoding is detected by comparing the negotiated SDP between the SIP segments of the call. |
Advanced metrics/ Calls |
Active calls with a RTP Transcoding |
Platform, Prefix tag |
Transcoding type Predicate type |
Number of active SIP calls for each second in which RTP transcoding was detected. RTP transcoding is detected by comparing the negotiated SDP between the SIP segments of the call. |
Advanced metrics/ Calls |
Number of calls closed by the callee |
Platform, Prefix tag |
- |
Number of calls for each second where the called party ended the call. |
Advanced metrics/ Calls |
Number of active calls belonging to this probe |
Platform, Prefix tag |
- |
This is a KPI created on behalf of an Mediation Engine Connector (MEC). It counts only those active calls where the ingress leg is not touching a neighbor device. |
Advanced metrics/ Calls |
Number of calls closed with a reason header in the BYE message |
Platform, Prefix tag |
- |
Number of calls for each second that were ended with a BYE message containing a reason header indicating Session Disconnect Failure (SDF). To count as SDF the reason header must contain a Q.850 cause value other than 16, 17, 18, 19, 21, or 31. |
Advanced metrics/ Calls |
Number of calls failed due to a timeout during a session setup |
Platform, Prefix tag |
- |
Number of calls for each second that timed out during session setup. |
Advanced metrics/ Calls |
Number of calls timed out while waiting for the response to the BYE message |
Platform, Prefix tag |
- |
Number of calls for each second where the response to BYE was not received in time. |
Advanced metrics/ Calls |
Number of calls failed due to a non-200 OK response to the INVITE |
Platform, Prefix tag |
- |
Number of calls for each second that failed due to a non-200 OK response to the INVITE. |
Advanced metrics/ Calls |
Number of established ingress legs |
Platform, Prefix tag |
- |
Number of ingress legs for each second that were established. |
Advanced metrics/ Calls |
Number of redirected ingress legs |
Platform, Prefix tag |
- |
Number of ingress legs for each second where the INVITE was answered with a response in the 300 range. |
Advanced metrics/ Calls |
Number of failed ingress legs |
Platform, Prefix tag |
- |
Number of ingress legs for each second where the INVITE was answered with a response greater than or equal to 400. |
Advanced metrics/ Calls |
Number of ingress legs timed out during the setup |
Platform, Prefix tag |
- |
Number of ingress legs for each second that timed out during session setup. |
Advanced metrics/ Calls |
Number of ingress legs with a session time out |
Platform, Prefix tag |
- |
Number of ingress legs for each second that stopped being tracked because they were established for longer than the threshold (System setting, Session-timeout for calls). |
Advanced metrics/ Calls |
Number of successfully closed ingress legs |
Platform, Prefix tag |
- |
Number of ingress legs for each second that were closed successfully. |
Advanced metrics/ Calls |
Number of ingress legs closed with SDF |
Platform, Prefix tag |
- |
Number of ingress legs for each second that were ended with a BYE message containing a reason header indicating Session Disconnect Failure (SDF). To count as SDF the reason header must contain a Q.850 cause value other than 16, 17, 18, 19, 21, or 31. |
Advanced metrics/ Calls |
Number of ingress legs with timeout after the BYE was sent |
Platform, Prefix tag |
- |
Number of ingress legs for each second with a timeout after the BYE was sent. |
Advanced metrics/ Calls |
Number of ingress legs failed with a certain response code |
Platform, Prefix tag |
Lower bound for the code Upper bound for the code |
Number of ingress legs for each second where the INVITE was answered with a response code in the given range. |
Advanced metrics/ Calls |
Number of ingress legs with Q.850 cause code |
Platform, Prefix tag |
Minimum Q.850 cause codeMaximum Q.850 cause code |
Number of ingress SIP or ISUP legs that finished or failed for each second and received a Q.850 reason (SIP) or cause value (ISUP) in the given range. |
Advanced metrics/ Calls |
Number of SIP ingress legs with the Q.850 cause code in the headers |
Platform, Prefix tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of ingress SIP legs that finished or failed for each second and received a reason header with a Q.850 cause value in the given range. |
Advanced metrics/ Calls |
Number of ISUP ingress legs with a Q.850 cause code |
Platform, Prefix tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of ingress ISUP legs that finished or failed for each second and received a Q.850 cause value in the given range. |
Advanced metrics/ Calls |
Number of session establishments |
Platform, Prefix tag |
- |
Indicates the number of session establishments. A session is established when one of the following events occurs in a call:
Counted once for each end-to end call. |
Advanced metrics/ Registrations |
Expired contacts in the last second |
Platform, Prefix tag |
- |
Number of registered contacts that expired for each second. Counts for each binding for each server. |
Advanced metrics/ Registrations |
New contacts in the last second |
Platform, Prefix tag |
- |
Number of new contacts for each second (first-time REGISTER). Counts for each binding for each server. |
Advanced metrics/ Registrations |
Contacts refreshed in the last second |
Platform, Prefix tag |
- |
Number of contacts refreshed for each second (refreshing REGISTER). Counts for each binding for each server. |
Advanced metrics/ Registrations |
Failed registrations in the last second |
Platform, Prefix tag |
- |
Number of failed REGISTER attempts for each second. Counts REGISTER transactions that failed with response codes >= 300, except 302, 401, or 407. |
Advanced metrics/ Registrations |
Unauthorized registrations in the last second |
Platform, Prefix tag |
- |
Number of failed REGISTER attempts for each second where a 401/407 response was not followed by another attempt. |
Advanced metrics/ Registrations |
Registered contacts gone in the last second |
Platform, Prefix tag |
- |
Number of contacts that were gone for each second. A contact is gone if it is explicitly unregistered (expires=0). Additionally contacts that are not listed in a REGISTER response anymore are treated as gone if System setting Registrations gone events is enabled. |
Advanced metrics/ RTCP |
Number of RTCP packets (all types) |
Platform |
- |
Number of RTCP packets for each second. |
Advanced metrics/ RTCP |
Number of RTCP-XR packets |
Platform |
- |
Number of RTCP Extended Report (XR) packets for each second. |
Advanced metrics/ RTCP |
Minimum jitter values reported in the RTCP of finished streams |
Platform |
- |
Lowest jitter value (in milliseconds) from RTCP Receiver Reports of all streams that ended in a given second. |
Advanced metrics/ RTCP |
Maximum jitter values reported in the RTCP of finished streams |
Platform |
- |
Highest jitter value (in milliseconds) from RTCP Receiver Reports of all streams that ended in a given second. |
Advanced metrics/ RTCP |
Average jitter values reported in the RTCP of finished streams |
Platform |
- |
Average of the jitter values (in milliseconds) from RTCP Receiver Reports of all streams that ended in a given second. |
Advanced metrics/ RTCP |
Minimum delay values reported in the RTCP of finished streams |
Platform |
- |
Lowest delay value (in milliseconds) of all streams that ended in a given second. The delay for each stream is calculated or taken from RTCP-XR (preferring the latter). |
Advanced metrics/ RTCP |
Maximum delay values reported in the RTCP of finished streams |
Platform |
- |
Highest delay value (in milliseconds) of all streams that ended in a given second. The delay for each stream is calculated or taken from RTCP-XR (preferring the latter). |
Advanced metrics/ RTCP |
Average delay values reported in the RTCP of finished streams |
Platform |
- |
Average of the delay values (in milliseconds) of all streams that ended in a given second. The delay for each stream is calculated or taken from RTCP-XR (preferring the latter). |
Advanced metrics/ RTCP |
Minimum MOScq values reported in the RTCP-XR of finished streams |
Platform |
- |
Lowest MOSCQ value from RTCP-XR VoIP Metrics Report Blocks of all streams that ended in a given second. Only streams which reported MOS are taken into account. |
Advanced metrics/ RTCP |
Maximum MOScq values reported in the RTCP-XR of finished streams |
Platform |
- |
Highest MOSCQ value from RTCP-XR VoIP Metrics Report Blocks of all streams that ended in a given second. Only streams which reported MOS are taken into account. |
Advanced metrics/ RTCP |
Average MOScq values reported in the RTCP-XR of finished streams |
Platform |
- |
Average of all MOSCQ values from RTCP-XR VoIP Metrics Report Blocks of all streams that ended in a given second. Only streams which reported MOS are taken into account. |
Advanced metrics/ RTCP Usage |
Streams with RTCP |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP packet was seen (incl. RTCP-XR). |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR packet was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 1 (Loss RLE Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 2 (Duplicate RLE Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 3 (Packet Receipt Times Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 4 (Receiver Reference Times Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 5 (DLRR Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 6 (Statistics Summary Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 7 (Statistics Summary Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 8 (BT's Extended Network Quality Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 9 (Texas Instrument Extended VoIP Quality Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 10 (Port-repair Loss RLE Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 11 (Multicast Acquisition Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 12 (IDMS Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 13 (ECN Summary Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 14 (Measurement Information Report Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 15 (Packet Delay Variation Metrics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 16 (Delay Metrics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 17 (Burst/Gap Loss Summary Statistics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 18 (Burst/Gap Discard Summary Statistics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 19 (Frame Impairment Summary Statistics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 20 (Burst/Gap Loss Metrics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 21 (Burst/Gap Discard Metrics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 22 (MPEG2 Transport Stream PSI-Independent Decodability Statistics Metrics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 23 (De-jitter Buffer Metrics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 24 (Discard Count Metrics Block) |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type in range 25-254 |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Advanced metrics/ RTCP Usage |
Streams with RTCP-XR Block Type 255 |
Platform |
- |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
Device, Trunk and IP Tag KPIs
Table 20-2 describes the Operations Monitor device trunk and IP tag KPIs, where:
The device, and trunk KPIs provide data about the devices.
The IP tag KPIs provide data about the IP addresses that match specific IP tags.
Table 20-2 Device, Trunk and IP Tag KPIs
Path | KPI Metric | Applicable | Parameter | Description |
---|---|---|---|---|
Default |
Active sessions (incoming) |
Device, IP tag |
- |
Number of established call legs to the device. |
Default |
Active sessions (outgoing) |
Device, IP tag |
- |
Number of established call legs from the device. |
Default |
Active sessions (traversing) |
Device |
- |
Number of established calls that traverse the device (where there is both an incoming and an outgoing leg). |
Default |
Call attempts for each second (CAPS) (incoming) |
Device, IP tag |
- |
Number of call attempts for each second to the device. Counts for each incoming leg. |
Default |
Call attempts for each second (CAPS) (outgoing) |
Device, IP tag |
- |
Number of call attempts for each second out of the device. Counts for each outgoing leg. |
Default |
Call attempts for each second (traversing) |
Device |
- |
Number of call attempts for each second traversing the device (where there is both an incoming and an outgoing leg) |
Default |
Registered Users |
Device, IP tag |
- |
Number of users registered to the device. Users with multiple bindings/contacts are counted only once. |
Default |
Registered Contacts |
Device, IP tag |
- |
Number of contacts registered to the device |
Default |
Response time for this device |
Device, IP tag |
- |
Maximum response time in milliseconds. Based on all completed transactions where the device is the server. |
Default |
Transit time (maximum) for this device |
Device |
- |
Maximum time difference in milliseconds between an incoming and an outgoing leg of the same call traversing a device. |
IETF metrics |
Combined Maximum successful session request delay |
Device, IP tag |
- |
This metric combines the ISUP Post Dial Delay (PDD) and SIP Session Request Delay (SRD) into a single metric. Sessions are only accounted for if they originated at this specific device. SSRD is defined as the time interval from the first bit of the initial INVITE message containing the information sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received indicating an audible or visual status of the initial session setup request. |
IETF metrics |
Combined maximum failed session request delay |
Device, IP tag |
- |
This metric combines the ISUP Post Dial Delay (PDD) and SIP Session Request Delay (SRD) into a single metric. Sessions are only accounted for if they originated at this specific device. Failed Session Request Delay (FSRD) is the time interval from the first bit of the initial INVITE message containing the information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. A failure response is described as a 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or possible 6XX message. |
IETF metrics |
Combined maximum session request delay |
Device, IP tag |
- |
This metric combines the ISUP Post Dial Delay (PDD) and SIP Session Request Delay (SRD) into a single metric. Sessions are only accounted for if they originated at this specific device. Session Request Delay (SRD) is utilized to detect failures or impairments causing delay in responding to a UA session request. SRD is measured for both successful and failed session setup requests as this metric relates to the user experience. It is recommended that the SSRD and the FSRD are used instead of SRD as the time greatly varies between the two. SRD is similar to Post-Selection Delay from telephony applications. |
IETF metrics |
Incoming session establishment ratio |
Device, IP tag |
- |
SER is defined as follows: SER = Number of new session INVITE requests resulting in a 200 OK response/(Total number of attempted INVITE requests - Number of INVITE requests resulting in a 3XX response). If defined for a device, it counts the incoming calls to that device. If defined for a trunk, it counts the calls for which the initial INVITE goes to that trunk (egress). This metric is similar to Answer Seizure Ratio (ASR) in telephony applications of SIP. |
IETF metrics |
Outgoing session establishment ratio |
Device, IP tag |
- |
SER is defined as follows: SER = Number of new session INVITE requests resulting in a 200 OK response/(Total number of attempted INVITE requests - Number of INVITE requests resulting in a 3XX response). If defined for a device, it counts the outgoing calls to that device. If defined for a trunk, it counts the calls for which the initial INVITE goes to that trunk (ingress). This metric is similar to Answer Seizure Ratio (ASR) in telephony applications of SIP. |
IETF metrics |
Incoming session establishment effectiveness ratio |
Device, IP tag |
- |
This metric is complimentary to SER, but is intended to exclude the potential effects of an individual user of the target UA from the metric. SEER is defined as follows: SEER = (Number of INVITE requests resulting in a 200 OK, 480, 486, 600, or 603 response)/(Total number of attempted INVITE requests - Number of INVITE requests resulting in a 3XX response). The response codes 480, 486, 600, and 603 were chosen as they indicate the effect of an individual user of the UA. It is possible that an individual user could cause a negative effect on the UA. For example, they may have incorrectly configured the UA causing a response code not directly related to a SSP, but this cannot be easily determined from an intermediary B2BUA somewhere in between the originating and terminating UA. With this in consideration, response codes such as 401, 407, and 420 (not an exhaustive list) were not included in the numerator of the metric. If defined for a device, it counts the incoming calls to that device. If defined for a trunk, it counts the calls for which the initial INVITE comes from the platform to that trunk (egress). This metric is similar to Network Effectiveness Ratio (NER). |
IETF metrics |
Outgoing session establishment effectiveness ratio |
Device, IP tag |
- |
This metric is complimentary to Session establishment ratio (SER), but is intended to exclude the potential effects of an individual user of the target UA from the metric. SEER = (Number of INVITE requests resulting in a 200 OK, 480, 486, 600, or 603 response)/(Total number of attempted INVITE requests - Number of INVITE requests resulting in a 3XX response). The response codes 480, 486, 600, and 603 were chosen as they accurately indicate the effect of an individual user of the UA. It is possible that an individual user could cause a negative effect on the UA. For example, they may have incorrectly configured the UA resulting a response code that is not related to a SSP. This cannot be easily determined from an intermediary B2BUA somewhere in between the originating and terminating UA. With this in consideration, response codes such as 401, 407, and 420 (not an exhaustive list) were not included in the numerator of the metric. If defined for a device, this metric counts the outgoing calls to that device. If defined for a trunk, this metric counts the calls for which the initial INVITE comes from the platform to that trunk (ingress). This metric is similar to Network Effectiveness Ratio (NER). |
IETF metrics |
Incoming ineffective registration attempts |
Device, IP tag |
- |
Ineffective registration attempts are utilized to detect failures or impairments causing an inability for a registrar to receive a UA REGISTER request. A failed registration attempt is a final failure response to the initial REGISTER request. It indicates a failure received from the destination registrar, interim proxies, or due to a timeout of the REGISTER request at the originating UA. A failure response is described as a 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or possible 6XX message. IRA may be used to detect problems in downstream signaling functions, which may be impairing the REGISTER message from reaching the intended registrar; or, it may indicate a registrar has become overloaded and is unable to respond to the request. |
IETF metrics |
Outgoing ineffective registration attempts |
Device, IP tag |
- |
Ineffective registration attempts are utilized to detect failures or impairments causing an inability for a registrar to receive a UA REGISTER request. A failed registration attempt is a final failure response to the initial REGISTER request. It indicates a failure received from the destination registrar, interim proxies, or due to a time-out of the REGISTER request at the originating UA. A failure response is described as a 4XX (excluding 401, 402, and 407 non-failure challenge response codes), 5XX, or possible 6XX message. IRA may be used to detect problems in downstream signaling functions, which may be impairing the REGISTER message from reaching the intended registrar; or, it may indicate a registrar has become overloaded and is unable to respond to the request. |
IETF metrics |
Incoming session success ratio |
Device, IP tag |
- |
Session Success Ratio (SSR) is defined as the percentage of successfully completed sessions compared to sessions, which fail due to ISA or SDF. This metric is also known as Call Success Ratio (CSR) in telephony applications of SIP. |
IETF metrics |
Outgoing session success ratio |
Device, IP tag |
- |
Session Success Ratio (SSR) is defined as the percentage of successfully completed sessions compared to sessions, which fail due to ISA or SDF. This metric is also known as Call Success Ratio (CSR) in telephony applications of SIP. |
IETF metrics |
Session disconnect delay |
Device, IP tag |
- |
Session Disconnect Delay (SDD) is the time interval between the first bit of the sent session completion message, such as a BYE, and the last bit of the subsequently received 2XX response. |
IETF metrics |
Incoming session duration time |
Device, IP tag |
- |
Session Duration Time (SDT) is utilized to detect technical issues causing short session durations. For example, poor audio quality. SDT is defined as an average of duration of the interval between receipt of the first bit of a 200 OK response to an INVITE plus receipt of the last bit of an associated BYE message. Retransmissions of the 200 OK and ACK messages due to network impairments do not reset the metric timers. |
IETF metrics |
Outgoing session duration time |
Device, IP tag |
- |
Session Duration Time (SDT) is utilized to detect technical issues causing short session durations. For example, poor audio quality. SDT is defined as an average of duration of the interval between receipt of the first bit of a 200 OK response to an INVITE plus receipt of the last bit of an associated BYE message. Retransmissions of the 200 OK and ACK messages due to network impairments do not reset the metric timers. |
IETF metrics |
Average successful session request delay |
Device, IP tag |
- |
Successful Session Request Delay (SSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information is sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received indicating an audible or visual status of the initial session setup request. Sessions are only accounted for if they originated at this specific device. |
IETF metrics |
Average successful session request delay (all sessions) |
Device, IP tag |
- |
Successful Session Request Delay (SSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information is sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received indicating an audible or visual status of the initial session setup request. Metric computed for all sessions passing through this device. |
IETF metrics |
Average failed session request delay |
Device, IP tag |
- |
Failed Session Request Delay (FSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. A failure response is described as a 3XX (excluding 401, 402, and 407 non- failure challenge response codes), 5XX, or possible 6XX message. Sessions are only accounted for if they originated at this specific device. |
IETF metrics |
Average failed session request delay (all sessions) |
Device, IP tag |
- |
Failed Session Request Delay (FSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. A failure response is described as a 3XX (excluding 401, 402, and 407 non- failure challenge response codes), 5XX, or possible 6XX message. Metric computed for all sessions passing through this device. |
IETF metrics |
Maximum successful session request delay |
Device, IP tag |
- |
Successful Session Request Delay (SSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information is sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received indicating an audible or visual status of the initial session setup request. Sessions are only accounted for if they originated at this specific device. |
IETF metrics |
Maximum successful session request delay (all sessions) |
Device, IP tag |
- |
Successful Session Request Delay (SSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information is sent by the originating user agent to the intended mediation or destination agent until the last bit of the first provisional response is received indicating an audible or visual status of the initial session setup request. Metric computed for all sessions passing through this device. |
IETF metrics |
Maximum failed session request delay |
Device, IP tag |
- |
Failed Session Request Delay (FSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. A failure response is described as a 3XX (excluding 401, 402, and 407 non- failure challenge response codes), 5XX, or possible 6XX message. Sessions are only accounted for if they originated at this specific device. |
IETF metrics |
Maximum failed session request delay (all sessions) |
Device, IP tag |
- |
Failed Session Request Delay (FSRD) is defined as the time interval from the first bit of the initial INVITE message containing the necessary information sent by the originating agent or user to the intended mediation or destination agent until the last bit of the first provisional response or a failure indication response. A failure response is described as a 3XX (excluding 401, 402, and 407 non- failure challenge response codes), 5XX, or possible 6XX message. Metric computed for all sessions passing through this device. |
Advanced Metrics |
Number of active sessions |
Device, IP tag |
Direction of the session Relevant call state |
Number of call segments active in the given call direction and state. |
Advanced Metrics |
Number of established calls for each second |
Device, IP tag |
Direction of the call |
Number of call segments for each second that got established, in the given call direction. |
Advanced Metrics |
Number of closed calls for each second |
Device, IP tag |
Direction of the call |
Number of call segments for each second that finished, in the given call direction. |
Advanced Metrics |
Number of session timeout calls for each second |
Device, IP tag |
Direction of the call |
Number of end-to-end calls (an end-to-end call can comprise of several correlated call legs) for each second that stopped being monitored because they were longer than the threshold (System setting, Session-timeout for calls). |
Advanced Metrics |
Number of failed calls for each second |
Device, IP tag |
Direction of the call |
Number of call segments for each second that failed, in the given call direction. |
Advanced Metrics |
Number of calls completed/ established with a specific code for each second |
Device, IP tag |
Direction of the call Lower bound for the code Upper bound for the code |
Number of SIP call segments for each second in the given direction that received a final response to the INVITE with a response code in the given range. |
Advanced Metrics |
Number of calls with Q.850 cause codes |
Device, IP tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of SIP or ISUP call segments for each second where a Q.850 cause value in the given range was received, in a reason header (SIP) or in a cause parameter (ISUP). |
Advanced Metrics |
Number of SIP calls with Q.850 cause codes |
Device, IP tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of SIP call segments for each second where a reason header with a Q.850 cause value in the given range was received. |
Advanced Metrics |
Number of ISUP calls with Q.850 cause codes |
Device, IP tag |
Minimum Q.850 cause code Maximum Q.850 cause code |
Number of ISUP call segments for each second where a Q.850 cause value in the given range was received. |
Advanced Metrics |
Number of calls with a given length |
Device, IP tag |
Direction of the call Call length (milliseconds)>= Call length (milliseconds)< |
Number or call segments for each second that finished after being established for a duration in the given range, in the given call direction. |
Advanced Metrics |
Number of session establishments |
Device, IP tag |
Direction of the call |
Indicates the number of session establishments. A session is established when one of the following events occur:
Counts for each call segment in the given direction. |
Advanced Metrics |
Number of closed calls with a Reason header in the BYE message (SDF) |
Device, IP tag |
Direction of the call |
Number of call segments for each second in the given direction that were ended with a BYE message containing a reason header indicating Session Disconnect Failure (SDF). To count as SDF the reason header must contain a Q.850 cause value other than 16, 17, 18, 19, 21, or 31. |
Advanced Metrics |
Number of SIP call attempts |
Device, IP tag |
Direction of the call |
Number of SIP call attempts for each second in the given call direction (for each call segment). |
Advanced Metrics |
Number of ISUP call attempts |
Device, IP tag |
Direction of the call |
Number of ISUP call attempts for each second in the given call direction (for each call segment). |
Advanced Metrics |
Number of SIP calls that terminated abnormally |
Device, IP tag |
Direction of the call |
Number of SIP call segments for each second that terminated abnormally, in the given call direction. |
Advanced Metrics |
Number of ISUP calls that terminated abnormally |
Device, IP tag |
Direction of the call |
Number of ISUP call segments for each second that terminated abnormally, in the given call direction. |
Advanced metrics |
Rate of incoming SIP calls that terminated abnormally |
Device, IP tag |
- |
Rate of incoming SIP call segments for each second that terminated abnormally. In percent of abnormally-terminated calls out of call terminated calls. |
Advanced metrics |
Rate of outgoing SIP calls that terminated abnormally |
Device, IP tag |
- |
Rate of outgoing SIP call segments for each second that terminated abnormally. In percent of abnormally-terminated calls out of call terminated calls. |
Advanced metrics |
Rate of incoming ISUP calls that terminated abnormally |
Device, IP tag |
- |
Rate of incoming ISUP call segments for each second that terminated abnormally. In percent of abnormally-terminated calls out of call terminated calls. |
Advanced metrics |
Rate of outgoing ISUP calls that terminated abnormally |
Device, IP tag |
- |
Rate of outgoing ISUP call segments for each second that terminated abnormally. In percent of abnormally-terminated calls out of call terminated calls. |
Advanced Metrics |
Expired contacts |
Device, IP tag |
- |
Number of contacts that were registered to the device and expired for each second. |
Advanced Metrics |
Number of new contacts for each second |
Device, IP tag |
- |
Number of new contacts for each second that registered to the device (initial REGISTER). |
Advanced Metrics |
Refreshed contacts |
Device, IP tag |
- |
Number of contacts registered to the device that refreshed the binding for each second (refreshing REGISTER). |
Advanced Metrics |
Failed registrations |
Device, IP tag |
- |
Number of registration attempts to the device that failed for each second. |
Advanced Metrics |
Number of unauthorized registrations for each second |
Device, IP tag |
- |
Number of registration attempts to the device that finally failed with REGISTER response code 401 or 407. |
Advanced Metrics |
Number of registered contacts gone for each second |
Device, IP tag |
- |
Number of contacts that were gone for each second. A contact is gone if it is explicitly unregistered (expires=0). Additionally contacts that are not listed in a REGISTER response anymore are treated as gone if System setting, Registrations gone events is enabled. |
Advanced Metrics |
Number of registration attempts with a specific code for each second |
Device, IP tag |
Lower bound for the code Upper bound for the code |
Number of registration attempts to the device that received a REGISTER response code in the given range. |
Advanced Metrics |
Total number of active calls |
Device, IP tag |
- |
Sum of the numbers of incoming and outgoing established call segments on the device. This counts traversing calls twice. |
Advanced Metrics |
Total number of active calls (including traversing calls) |
Device |
- |
Sum of the numbers of incoming, outgoing, and traversing established calls on the device. This counts traversing calls three times. |
Advanced Metrics |
SDP declared RTP transcoding |
Device, IP Tag |
Transcoding type Predicate type |
Number of times each second when an RTP transcoding even was detected within a SIP call. RTP transcoding is detected by comparing the negotiated SDP between the SIP segments of the call. |
Advanced metrics |
Active calls with RTP transcoding |
Device |
Transcoding type Predicate type |
Number of active SIP calls for each second in which RTP transcoding was detected. RTP transcoding is detected by comparing the negotiated SDP between the SIP segments of the call. |
Advanced metrics / TCP counters |
Number of active TCP connections to/from this device |
Device, IP tag |
- |
Number of active TCP connections monitored on the device. |
Advanced metrics/TCP counters |
Number of created TCP connections to/from this device |
Device, IP tag |
- |
Number of new TCP connections monitored on the device. |
Advanced metrics/TCP counters |
Number of timeout TCP connections to/from this device |
Device, IP tag |
- |
Number of monitored TCP connections on the device that timed out. |
Advanced metrics/TCP counters |
Number of TCP SYN messages to/from this device |
Device, IP tag |
Direction of the message |
Number of TCP packets of the respective type in the sent or received by the device (direction according to the KPI parameter). |
Advanced metrics/TCP counters |
Number of TCP ACK messages to/from this device |
Device, IP tag |
Direction of the message |
Number of TCP packets of the respective type in the sent or received by the device (direction according to the KPI parameter). |
Advanced metrics/TCP counters |
Number of TCP RST messages to/from this device |
Device, IP tag |
Direction of the message |
Number of TCP packets of the respective type in the sent or received by the device (direction according to the KPI parameter). |
Advanced metrics/TCP counters |
Number of TCP FIN messages to/from this device |
Device, IP tag |
Direction of the message |
Number of TCP packets of the respective type in the sent or received by the device (direction according to the KPI parameter). |
Advanced metrics/ SCTP counters |
Number of active SCTP associations on this device |
Device, IP tag |
- |
Number of active SCTP associations monitored on the device. |
Advanced metrics/ SCTP counters |
Number of SCTP associations created on this device |
Device, IP tag |
- |
Number of new SCTP associations monitored on the device, for each second. |
Advanced metrics/ SCTP counters |
Number of SCTP DATA chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP INIT chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP INIT ACK chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP SACK chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP HEARTBEAT chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP HEARTBEAT ACK chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP ABORT chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter) |
Advanced metrics/ SCTP counters |
Number of SCTP SHUTDOWN chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter) |
Advanced metrics/ SCTP counters |
Number of SCTP SHUTDOWN ACK chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP ERROR chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP COOKIE ECHO chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP COOKIE ACK chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP ECNE chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP CWR chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ SCTP counters |
Number of SCTP SHUTDOWN COMPLETE chunks to/from this device |
Device, IP tag |
Direction of the message |
Number of SCTP chunks of the respective type sent or received by the device for each second (direction is a KPI parameter). |
Advanced metrics/ Traffic |
Bandwidth consumed by SIP requests with the specified method |
Device, IP tag |
SIP Method |
Bytes/second consumed by SIP requests with the given method sent or received by the device. |
Advanced metrics/ Traffic |
Bandwidth consumed by fragmented SIP requests with the specified method |
Device, IP tag |
SIP Method |
Bytes/second consumed by SIP requests with the given method sent or received by the device, only counting the messages if they were a fragmented UDP datagram. |
Advanced metrics/ Traffic |
Number of UDP packets |
Device, IP tag |
Direction of the message |
Number of UDP packets for each second sent or received by the device. |
Advanced metrics/ Traffic |
Bandwidth of the UDP packets |
Device, IP tag |
Direction of the message |
Bytes/second of UDP packets sent or received by the device. This counts the packet starting with the transport header (not including the Ethernet and IP headers). |
Advanced metrics/ Traffic |
Number of TCP packets |
Device, IP tag |
Direction of the message |
Number of TCP packets for each second sent or received by the device. |
Advanced metrics/ Traffic |
Bandwidth of the TCP packets |
Device, IP tag |
Direction of the message |
Bytes/second of TCP packets sent or received by the device. This counts the packet starting with the transport header (not including the Ethernet and IP headers). |
Advanced metrics/ Traffic |
Number of SCTP packets |
Device, IP tag |
Direction of the message |
Number of SCTP packets for each second sent or received by the device. |
Advanced metrics/ Traffic |
Bandwidth of the SCTP packets |
Device, IP tag |
Direction of the message |
Bytes/second of SCTP packets sent or received by the device. This counts the packet starting with the transport header (not including the Ethernet and IP headers) |
Advanced metrics/ Traffic |
Number of fragmented UDP packets |
Device, IP tag |
Direction of the message |
Number of fragmented UDP packets for each second sent or received by the device. |
Advanced metrics/ Traffic |
Number of fragmented IPv4 packets in memory |
Device, IP tag |
Direction of the message |
Number of fragmented IPv4 packets sent or received by the device currently kept in memory. |
Advanced metrics/ Traffic |
Number of fragmented IPv6 packets in memory |
Device, IP tag |
Direction of the message |
Number of fragmented IPv6 packets sent or received by the device currently kept in memory. |
Advanced metrics/ Traffic |
Number of IPv4 packets |
Device, IP tag |
Direction of the message |
Number of IPv4 packets sent or received for each second. |
Advanced metrics/ Traffic |
Number of IPv6 packets |
Device, IP tag |
Direction of the message |
Number of IPv6 packets sent or received for each second. |
Advanced metrics/ Transactions |
Number of incoming transactions with the given method name and response code |
Device, IP tag |
Transaction method Minimum answer code Maximum answer code |
Number of transactions for each second where the device was the server (incoming transactions) and the method name and response code match the given parameters. |
Advanced metrics/ Transactions |
Number of outgoing transactions with the given method, name, and response code |
Device, IP tag |
Transaction method Minimum answer code Maximum answer code |
Number of transactions for each second where the device was the client (outgoing transactions) and the method name and response code match the given parameters. |
Advanced metrics/ Transactions |
Number of incoming timed-out transactions with a certain method |
Device, IP tag |
Method to Monitor |
Number of transactions for each second where the device received the request of the given type but did not send a final response in time. |
Advanced metrics/ Transactions |
Number of outgoing timed-out transactions with a certain method |
Device, IP tag |
Method to Monitor |
Number of transactions for each second where the device sent the request of the given type but did not receive a final response in time. |
Megaco/ H.248 |
Number of Megaco legs created |
Device, IP tag |
- |
Number of new Megaco legs for each second on the Media Gateway. |
Megaco/ H.248 |
Number of active Megaco legs |
Device, IP tag |
- |
Number of active Megaco legs on the Media Gateway. |
Megaco/ H.248 |
Number of Megaco legs that finished |
Device, IP tag |
- |
Number of Megaco legs on the Media Gateway that finished for each second. |
Megaco/ H.248 |
Number of Megaco legs that finished after a complete SDP negotiation |
Device, IP tag |
- |
Number of Megaco legs on the Media Gateway that finished for each second, only counting those legs where a complete SDP negotiation happened before. |
Megaco/ H.248 |
Percentage of finished Megaco connections with a complete SDP negotiation |
Device, IP tag |
- |
Percentage of Megaco legs that finished after a complete SDP negotiation out of all finished Megaco legs on the Media Gateway. |
Megaco/ H.248 |
Average millisecond response time for a Megaco request |
Device, IP tag |
- |
Average response time for a Megaco request on the Media Gateway. |
MGCP |
Number of MGCP legs created |
Device, IP tag |
- |
Number of new MGCP legs for each second on the Gateway. |
MGCP |
Number of active MGCP legs |
Device, IP tag |
- |
Number of active MGCP legs on the Gateway. |
MGCP |
Number of MGCP legs that finished |
Device, IP tag |
- |
Number of MGCP legs on the Gateway that finished for each second. |
MGCP |
Number of MGCP legs that finished after a complete SDP negotiation |
Device, IP tag |
- |
Number of MGCP legs on the Gateway that finished for each second, only counting those legs where a complete SDP negotiation happened before. |
MGCP |
Percentage of finished MGCP connections with a complete SDP negotiation |
Device, IP tag |
- |
Percentage of MGCP legs that finished after a complete SDP negotiation out of all finished MGCP legs on the Gateway. |
MGCP |
Average millisecond response time for a MGCP request |
Device, IP tag |
- |
Average millisecond response time for a MGCP request on the Gateway. |
RTCP |
Number of RTCP packets (all types) |
Device |
Direction |
Number of RTCP packets sent or received by the device. |
RTCP |
Number of RTCP-XR packets |
Device |
Direction |
Number of RTCP-XR packets sent or received by the device. |
RTCP |
Minimum jitter values reported in RTCP of finished streams |
Device |
Direction |
Lowest jitter value (in milliseconds) from RTCP Receiver Reports of all streams that ended in a given second. |
RTCP |
Maximum jitter values reported in RTCP of finished streams |
Device |
Direction |
Highest jitter value (in milliseconds) from RTCP Receiver Reports of all streams that ended in a given second. |
RTCP |
Average jitter values reported in RTCP of finished streams |
Device |
Direction |
Average of the jitter values (in milliseconds) from RTCP Receiver Reports of all streams that ended in a given second. |
RTCP |
Minimum delay values reported in RTCP of finished streams |
Device |
Direction |
Lowest delay value (in milliseconds) of all streams that ended in a given second. The delay for each stream is calculated or taken from RTCP-XR (preferring the latter). |
RTCP |
Maximum delay values reported in RTCP of finished streams |
Device |
Direction |
Highest delay value (in milliseconds) of all streams that ended in a given second. The delay for each stream is calculated or taken from RTCP-XR (preferring the latter). |
RTCP |
Average delay values reported in RTCP of finished streams |
Device |
Direction |
Average of the delay values (in milliseconds) of all streams that ended in a given second. The delay for each stream is calculated or taken from RTCP-XR (preferring the latter). |
RTCP |
Minimum MOScq values reported in RTCP of finished streams |
Device |
Direction |
Lowest MOSCQ value from RTCP-XR VoIP Metrics Report Blocks of all streams that ended in a given second. Only streams which reported MOS are taken into account. |
RTCP |
Maximum MOScq values reported in RTCP of finished streams |
Device |
Direction |
Highest MOSCQ value from RTCP-XR VoIP Metrics Report Blocks of all streams that ended in a given second. Only streams which reported MOS are taken into account. |
RTCP |
Average MOScq values reported in RTCP of finished streams |
Device |
Direction |
Average of all MOSCQ values from RTCP-XR VoIP Metrics Report Blocks of all streams that ended in a given second. Only streams which reported MOS are taken into account. |
RTCP Usage |
Streams with RTCP |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP packet was seen (including RTCP-XR). |
RTCP Usage |
Streams with RTCP-XR Block Type 1 (Loss RLE Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR packet was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 2 (Duplicate RLE Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 3 (Packet Receipt Times Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 4 (Receiver Reference Times Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 5 (DLRR Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 6 (Statistics Summary Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 7 (Statistics Summary Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 8 (BT's Extended Network Quality Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 9 (Texas Instrument Extended VoIP Quality Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 10 (Port-repair Loss RLE Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 11 (Multicast Acquisition Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 12 (IDMS Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 13 (ECN Summary Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 14 (Measurement Information Report Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 15 (Packet Delay Variation Metrics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 16 (Delay Metrics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 17 (Burst/Gap Loss Summary Statistics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 18 (Burst/Gap Discard Summary Statistics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 19 (Frame Impairment Summary Statistics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 20 (Burst/Gap Loss Metrics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 21 (Burst/Gap Discard Metrics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 22 (MPEG2 Transport Stream PSI-Independent Decodability Statistics Metrics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 23 (De-jitter Buffer Metrics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 24 (Discard Count Metrics Block) |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type in range 25-254 |
Device |
Direction |
Counter is increased for each RTP stream that ended and where at least one RTCP-XR block of the given type was seen. |
RTCP Usage |
Streams with RTCP-XR Block Type 255 |
Device |
Direction |
Counter is increased for each RTP stream that ends and where at least one RTCP-XR block of the given type was seen. |