Avaya Media Gateways RTP-STAT

3 Ways to find and Fix QoS related issues

In this post, Avaya Media Gateways RTP-STAT, you will learn how to identify which interface or endpoint is suffering poor voice quality by going through the RTP-Stream logs, and Media Gateway’s VoIP engines using the RTP-STAT Application. These reports allow you to read the Jitter, Loss, Round-Trip, direction of the RTP Stream, etc.

Recently, I was helping one of our clients fix issues with static on their calls. As I was going through my steps, testing and troubleshooting, T1s, and Media Gateways, I wasn’t able to find anything that indicated what was causing the static. Not until a lightbulb went on in my head and I remembered the RTP-STAT commands part of the Avaya Media Gateway.

By using these statistics (RTP-STAT), I was able to find where the problem originated and adjusted those settings to fix the static issue.

These are the 3 ways=

• 1.- Find where the static exist
• 2.- Test the environment 
• 3.- Make recommendations

1.- Find where the static exist

Before you can start testing and adjusting settings in your system, it is important to collect the data from your customer. These are some of elements needed=

Call Direction – Knowing the direction of the call will help you understand what path and elements used within the system.

Time of the call – If the static happens around the same time.

Frequency – Find out if this event occurs on any particular day, and how often

Where? – Try to narrow the issue into a group / area / location

2.- Test the environment

With the call logs already collected from your customer, it is time for you to start testing and learning the resources used whenever the static happens. Start by understanding the types of trunks and their technology, and what types of telephone handsets are used.

H.323 Trunks – These trunks are connected via Fiber or a Private Cloud Network, where you need to have to have the Service Provider test their equipment. Once you have them tested, you should also verify which IP-Network-Regions are responsible for handling affected calls.

SIP Trunks – The same procedures apply as the H.323 Trunks. When working with the service provider and the network system administrators, ensure their Router/switches IP Interfaces are set with Full Duplex and the same speed at both ends (Router/switch and our system). 

No matter how fast their connection is or how much bandwidth , it is recommended to assign QoS parameters to the voice traffic. This could be done by applying Policy Maps and trusting the Media Gateway Interfaces in their Network Switches.

Media Processors – These are the VoIP Engines responsible of encode/decode the voice signal. You can test each MP module individually by running busyout/relesae/test commands, by running show voip-dsp  and parameters will display errors and voip engine versions.

RTP Statistics – This is a section of the Media Gateway that allows you to read RTP Voice traffic traversing in and out of the primary interface from the Media Gateway.

RTP Sessions – These are logs that are saved into a buffer that gets overwritten once full.

RTP Statistics Session Events – These are auto-generated by the Media Gateway, whenever the call or RTP-Stream scores a higher number than the one configured in the Threshold value.

RTP Statistics Detailed – Here you can read the entire event detailing the date/time of the call, as well as the duration. It provides both IP Address local and remote, Codec details, and RTP direction detailing QoS elements (Jitter, Round Trip, Loss, DSCP values, etc.). See the Resources below for more details.

Speed and Duplex – By running a “show int vlan 1”, assuming that VLAN1 is related to the PMI, you can verify if there are any CRCs, Drops, Collisions, and Duplex mismatch.

3.- Make recommendations

Now that you have identified which IP Phones and Interfaces are affected, it is time for you to make recommendations to the customer. Have the network administrator show you a print of their network switch interfaces.

For those with high Jitter and Loss counters, have the network administrator provide a traffic analysis report to see if the problem is related to a saturated network or a particular interface.

*.- References

RTP-STAT Application Guide

RTP-STAT Commands

rtp-stat threshold codec-loss 6.0
rtp-stat threshold average-codec-loss 0.0
rtp-stat threshold codec-rtt 700
rtp-stat threshold echo-return-loss 5
rtp-stat threshold loss 6.0
rtp-stat threshold remote-loss 6.0
rtp-stat threshold average-loss 0.0
rtp-stat threshold average-remote-loss 0.0
rtp-stat threshold jitter 70
rtp-stat threshold remote-jitter 70
rtp-stat threshold rtt 500
rtp-stat event-threshold echo-return-loss 0
rtp-stat event-threshold loss 1
rtp-stat event-threshold remote-loss 0
rtp-stat event-threshold jitter 0
rtp-stat event-threshold remote-jitter 0
rtp-stat event-threshold rtt 0
rtp-stat event-threshold ssrc-change 0
rtp-stat-service

Question – When troubleshooting static with IP Phones, what do you normally find the issues are?