Hello,
One of our customers has 2 T1's that terminate into a NeteVanta 838 (provided by carrier) and provide Ethernet handoffs to the Adtran908e. For quite some time I have been monitoring their calls and I have been noticing a lot of calls receiving lower MOS scores due to packet loss. The site only has around 28 phones and a 3Mbit pipe of dedicated internet access with prioritized voice traffic from the carrier. I have asked the carrier to investigate this issue and explain why packet loss still occurs under all these circumstances. They replied by saying that they manage the download QoS/CoS and we need to manage the upload to guarantee EF. They also said that this customer is bursting 3300bytes within 20 seconds of having the counters cleared at the prem site and this is affecting the calls regardless of voice traffic prioritization. I have enabled the following QoS map on the router and they carrier still notices the bursts.
ip access-list extended qos-match-coredial
permit udp any host x.x.x.x ( <-- voice server)
qos map qos-map-coredial 10
match ip list qos-match-coredial
priority percent 3
set dscp 46
interface eth 0/2
description Connection to OUTSIDE
speed 100
ip address x.x.x.x x.x.x.x
media-gateway ip primary
qos-policy out qos-map-coredial
no shutdown
The bandwidth of eth 0/2 is set to 100000Kbit, 100Mb/s full-duplex. I just need some suggestions how to improve that QoS map. Should I hardcorde the interface with 3Mbit and then specify the priority percent? Should I use max-reserved-bandwidth and traffic-shape-rate in the config?
Thanks in advance,
Adrian
Tetu04,
Thanks for posting! Yes, you should generally have a traffic shape rate applied for QoS to any ethernet interface where the bandwidth might bottleneck or be policed upstream. Below is a configuration you might try.
ip access-list extended qos-match-coredial
permit udp any host x.x.x.x ( <-- voice server)
!
qos map qos-map-coredial 10
match ip list qos-match-coredial
priority percent 50
set dscp 46
!
interface eth 0/2
qos-policy out qos-map-coredial
traffic-shape rate 3000000
The priority percentage is up to you, but should be based on the maximum number of concurrent calls you expect, and the voice codec in use. Feel free to reply on this thread if you have further questions.
Thanks!
David
David,
I was actually able to get the qos map implemented correctly
qos map qos-map-coredial 10
match ip list qos-match-coredial
priority unlimited
set dscp 46
interface eth 0/2
description Connection to OUTSIDE
speed 100
ip address 207.238.229.154 255.255.255.252
ip packet-capture glf-traffic-capture
media-gateway ip primary
traffic-shape rate 3000000
max-reserved-bandwidth 100
qos-policy out qos-map-coredial
no shutdown
ip access-list extended qos-match-coredial
permit udp any host 64.94.197.230
deny udp any any eq 5060
*********************************
greatlakes.ta908e-1#sh qos map interface eth 0/2
eth 0/2
qos-policy out: qos-map-coredial
map entry 10
match ip list qos-match-coredial
set DSCP value to 46
priority bandwidth: unlimited
note: since unlimited, other qos bandwidths cannot be assured
packets matched: 1143794, bytes matched: 288725884
map entry default
packets matched: 4492079, bytes matched: 1523550066
packets dropped: 97, bytes dropped: 145666
5 minute offered rate 1336104 bits/sec, drop rate 0 bits/sec
At this point the carrier doesn't see us bursting anymore and they also do not see any EF drops or any packet loss on their local loop. The low MOS calls still exist as before and the customer is still complaining. Is there any information within the Adtran device that I can obtain that provides proof that this issue is a result of the carrier’s network? At this point, the carrier will do nothing about it until I obtain proof. I have copied call examples from nCommand that clearly shows low MOS score, packet loss and reason of degradation but it is still not enough proof. I will go on site and run some packet capture and hopefully some bad calls will appear and I can show them the packet loss in the RTP Stream Analysis. If you have any other suggestions, please advise.
Thanks,
Adrian
Tetu04,
The QoS on the Adtran is only going to help with the outbound audio flow. I think a packet capture, and RTP stream analysis, is a good idea to show exactly how the packets are arriving at the Adtran unit. Outside of VQM, we often check "show voice quality-stats" for further calls statistics. We recommend R10.5.3 firmware when using this command since some improvements to the output were made starting with R10.5.0. A low delay and low jitter network will usually result in no discards, no drops, and average and maximum delay of 50ms. Below is a link to a document that goes over the statistics in more detail. See page 15.
Understanding Call Quality Statistics in AOS
Thanks!
David
Tetu04,
Were you able to get the packet capture and do any RTP analysis within Wireshark? Feel free to leave an update on here or any additional questions you may have.
Thanks,
David
Hello David,
I went on site and ran multiple packet captures. The packet captures clearly show the packet loss in the RTP stream analysis. The packets cross two different networks until they reach the SIP server provider's voice server. As I mentioned above, I have been working with the T1 provider. I have sent them all the captures and after QoS maps were applied on both ends, they concluded that their network is clean and the packet loss has to happen somewhere upstream. I am in the process of hearing back from the second ISP provider to see what their results indicate.
Tetu04,
I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.
Thanks!
David