The Adtran community holiday season is starting next week! The holiday period will span from December 21, 2024 to January 6, 2025. During this time, responses to feedback form submissions may be delayed. If you are encountering product issues, you can reach out to Adtran support at any time.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
g-man
New Contributor

RTP Packet Loss

Jump to solution

Hello, in need of some assistance. I have a TA900 providing trunks to Asterisks box. After a power outage all my calls are horrible. Monitoring the calls from the TA I am seeing heavy RTP packet loss on eth 0/2(LAN). if I ping the interface it is fine so not sure where and how this packet loss is taking place. Any thoughts?

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
Anonymous
Not applicable

Re: RTP Packet Loss

Jump to solution

So it's just about 100% packet loss for the one direction of RTP data flow if I'm reading this correctly, right? Is there NAT involved somewhere along the way? Your Adtran unit isn't showing any packets discards, so upstream there has to be something dropping the packets. Usually when it's just RTP loss it points to NAT somehow I believe...

View solution in original post

0 Kudos
6 Replies
Anonymous
Not applicable

Re: RTP Packet Loss

Jump to solution

You probably need to keep narrowing down any potential cause of the issue. Back track to where the TA patches into the network. Does that port in the Ethernet switch show it's taking errors? Is the Ethernet switch as a whole under a heavy load? Is there congestion affecting your network as a whole? I usually restart the network components, in case one came back up flaky after the power outage. Some network analysis tools can help you see if network congestion is an issue. For us, I use PRTG and Netflow type tools to get a clearer picture.

jayh
Honored Contributor
Honored Contributor

Re: RTP Packet Loss

Jump to solution

Look at your interface counters for errors, specifically duplex issues which will show as CRC on one end and runts on the other if mismatched or collisions if half-duplex. Most likely after the outage either one or both sides of a link came up as half-duplex.

Normally, with modern gear it's best practice to let things auto-negotiate but in some cases you may need to hard-code speed and duplex. If you do so you must set it on both sides of the link.

Anonymous
Not applicable

Re: RTP Packet Loss

Jump to solution

Also double check one of the devices may have had unsaved changes that where lost after the power outage.  As Jay mentioned the saved config may have different speed or duplex configurations then the config that was actually running.

John Wable

g-man
New Contributor

Re: RTP Packet Loss

Jump to solution

I have no errors on either interface. I have restarted everything and no luck. Monitor is showing the folowing

2020.02.05 12:20:53 VQM.EVENTS Monitoring session ended for xxxxxxxxxx to xxxxxxxxxx, RTP=10.10.88.3:16754->0.0.0.0:10676, MOS (LQ/PQ)=1.00/1.68, loss=1483 pkts, out-of-order=0 pkts, jitter=0 ms

2020.02.05 12:20:53 VQM.EVENTS Monitoring session ended for xxxxxxxxxx to xxxxxxxxx, RTP=0.0.0.0:10676->10.10.88.3:16754, MOS (LQ/PQ)=3.95/3.83, loss=0 pkts, out-of-order=0 pkts, jitter=0 ms

eth 0/2 is UP, line protocol is UP

  Description:  (LAN)

  Hardware address is

  Ip address is

  IP MTU is 1500 bytes

  BW is 100000 Kbit

  100Mb/s, negotiated full-duplex, configured full-duplex

  ARP type: ARPA; ARP timeout is 20 minutes

  Last clearing of "show interface" counters: never

  5 minute input rate 19760 bits/sec, 25 packets/sec

  5 minute output rate 57936 bits/sec, 21 packets/sec

    Queueing method: fifo

    Output queue: 0/256/0 (size/max total/drops)

    Interface Shaper: NOT ENABLED

    10810 packets input, 972537 bytes

    2358 unicasts, 8437 broadcasts, 15 multicasts input

    288 unknown protocol, 0 symbol errors, 0 discards

    0 input errors, 0 runts, 0 giants

    0 no buffer, 0 overruns, 0 internal receive errors

    0 alignment errors, 0 crc errors

    6534 packets output, 2177837 bytes

    6515 unicasts, 2 broadcasts, 17 multicasts output

    0 output errors, 0 deferred, 0 discards

    0 single, 0 multiple, 0 late collisions

    0 excessive collisions, 0 underruns

    0 internal transmit errors, 0 carrier sense errors

    0 resets, 0 throttles

eth 0/1 is UP, line protocol is UP

  Description: WAN

  Hardware address is 00:A0:C8:E6:F6:BB

  Ip address is 76.80.243.98, netmask is 255.255.255.248

  IP MTU is 1500 bytes

  BW is 100000 Kbit

  100Mb/s, negotiated full-duplex, configured full-duplex

  ARP type: ARPA; ARP timeout is 20 minutes

  Last clearing of "show interface" counters: never

  5 minute input rate 22096 bits/sec, 15 packets/sec

  5 minute output rate 4864 bits/sec, 3 packets/sec

    Queueing method: fifo

    Output queue: 0/256/0 (size/max total/drops)

    Interface Shaper: NOT ENABLED

    7744 packets input, 1297649 bytes

    6668 unicasts, 1076 broadcasts, 0 multicasts input

    0 unknown protocol, 0 symbol errors, 0 discards

    0 input errors, 0 runts, 0 giants

    0 no buffer, 0 overruns, 0 internal receive errors

    0 alignment errors, 0 crc errors

    2444 packets output, 377162 bytes

    2422 unicasts, 2 broadcasts, 20 multicasts output

    0 output errors, 0 deferred, 0 discards

    0 single, 0 multiple, 0 late collisions

    0 excessive collisions, 0 underruns

    0 internal transmit errors, 0 carrier sense errors

    0 resets, 0 throttles

Anonymous
Not applicable

Re: RTP Packet Loss

Jump to solution

So it's just about 100% packet loss for the one direction of RTP data flow if I'm reading this correctly, right? Is there NAT involved somewhere along the way? Your Adtran unit isn't showing any packets discards, so upstream there has to be something dropping the packets. Usually when it's just RTP loss it points to NAT somehow I believe...

0 Kudos
g-man
New Contributor

Re: RTP Packet Loss

Jump to solution

I finally solved the issue. The PBX behind the Adtran had two gateways on it. Once I fixed that everything went back to normal.