908e Call Audio Quality on SIP Trunk to PRI

[dan_the_computer_man]

We are having an issue with call audio with our 908e.  Our router is configured to convert our SIP trunk to a PRI connecting to our PBX.  Level3 is our carrier with AT&T/SBC as our LEC.

Calls from cell phones, especially AT&T, get 1 clean sounding ring then they are garbled.  Verizon is not clean but sounds like drop outs.

Voice quality with cell phones is also poor and sounds like there's background noise.  We're using codec G.711ulaw.

Voice quality with land lines sounds much better.

[nur]

I am not sure about the garbled. Does it also happen in the sounding ring (i.e. prior to the actual RTP audio) ?

With regards to background noise, since this does not appear on land lines, I assume it is connected to "normal" CNG generated on the cell phones that perhaps got a bit amplified in the network. Does this also happen if the cell phone is located in a quiet environment ? You may also try removing it using NR sip trunks (e.g. PBXMate).

[Anonymous]

I would suspect an issue with the carrier's network.  But perhaps you could mess with gains (make small moves and lower the send and receive levels over several test calls).  On the PRI trunk:

rtp tx gain <value>

rtp rx gain <value>

It's a band-aid, but may allow you to compensate for overly aggressive noise reduction or other DSP out of balance somewhere along the way.

Best,

Chris

[dan_the_computer_man]

The first ring sounds normal then the subsequent rings are over driven or garbled.  Here is a recording from a cell phone. VIDEO0173 - YouTube

.

[Anonymous]

Any way you could obtain a packet capture of a call example?  It would help to narrow down and see if the garbled audio is present in the RTP stream.  If so, it would seem like a carrier issue.  If the RTP is clean, then you may have a malfunction in the TA or PBX.

Chris

[dan_the_computer_man]

Where is the ring generated on a SIP trunk?  Is it emulated by the VOIP carrier, created by the TA, or created by the PBX?

I've contacted the carrier for support.  We are seeing a lot of out-of-order packets that seem to be causing delays close to 90ms.

The PBX was working fine on our T1 PRI prior to cut over.

[nur]

Perhaps, after the cut over, you increased the processing in your PBX and it max its CPU limits. Could you check this ? What happens if you limit the number of channels that are being used simultaneously ? BTW, an increasing delay also increases the risk for echo on the network.

[dan_the_computer_man]

It looks like the carrier, Level3, didn't enable QoS on our data line to support our SIP trunk.  Our internet connection was set to a QoS of BE (Best Effort) which is fine for data but not for VoIP.

It's been over 24hrs and we're still waiting for them to correct this.

[Anonymous]

Hope it makes a difference for you! Depending on how things turn out, a packet capture can reveal/prove that it's a carrier or WAN issue. Hopefully audio will just clear up, but that is at least action you could take if it's not satisfactory following the QoS adjustment. Keep us posted, will you?

[dan_the_computer_man]

We've seen some improvement but not a total correction of our issues since QoS has been enabled.

According to the Voice Quality Monitoring 97%+ of our RTP flows are excellent.

Users still complain about static (possibly out of order packets) and the in ability to place calls (possible service drops).

I'm trying to confirm that QoS is being sent from our routers.  Sure would be nice to have a debug option for displaying packet QoS.

Note: Level3 tried to set the MTU to 2450 which is common for many of their SIP trunk installs.  This is not supported since the max MTU for Ethernet is 1500 on Adtran devices.

[Anonymous]

Have you configured the QoS Policy on the 908 and assigned it to the interfaces carrying the voice traffic?  Also you need to make sure your routers us the same tagging protocol as the carrier, normally the DSCP setting and you would normally set this to 46 for all voice traffic, but if they are using TOS bits you will need to make sure your tag matches thiers.  You also need to make sure if the Adtran is behind any other firewalls/routers that they also follow the same QoS tagging protocol.  It maybe the QoS on the AT&T circuit is not configured at all or configured incorrectly.  You could setup a voice loopback on the Adtran and then call the Loopback number from the PBX if you have quality issues there then it is either the Adtran, the PRI interface or the PBX, if there is no quality issue there then you know it is on the upstream side of the Adtran so either AT&T or Level 3.  Another option would be to configure an Analog line of the Adtran and see if the same inbound issue happens with it as well if it does the problem is between the Adtran and Level 3 somewhere.

Voice Loopback is a simple test to create a demark point for testing.  When you call the number the system will answer and then loopback anything it receives.  You will have to use a number that the PBX will dial out of the PRI interface for.  To Configure Voice Loopback:

voice loopback 5555555

num-rings 1

[dan_the_computer_man]

Level3 just informed us that AT&T has us in a "Bronze" Class of Service (CoS) that only delivers based on Best Effort (BE).  To make things even more fun, AT&T is stripping off the QoS prior to forwarding the traffic to Level3.  Level3 has submitted a request to AT&T to change the CoS to "Silver" which will pass our QoS and provide a better CoS.

[Anonymous]

Hello Daniel,

I went ahead and flagged this post as “Assumed Answered.” If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers 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.

Regards,

Geoff

[dan_the_computer_man · Accepted solution]

Having the carrier reconfigure the QoS and CoS cleaned up our problem.

Later there was a power outage that caused the problem to return.  We tracked it down to the Leve3 NID switching back to Auto-Negotiate while the Adtran was set to 100Mbs Full as they required.

Remember that any device that is set to Auto-Negotiate must connect to another device that is also set to Auto-Negotiate.  NEVER have a mismatch like 100Mbs Full connecting to Auto-Negotiate.  If you do you will see Runts, Alignment Errors, Input Errors,...