Codec issue: G711 outbound but G729 in bound

[dmac]

    Having an issue with DTMF when calling a local store of a National retailer. We use an Adtran 4430SBC and have several Adtran 7100's using this 4430SBC for outbound calls. The firmware on the 4430 is R11.4.1V and on our 7100's we are using R11.10.3E.

    When we call the local number for one of the stores we get their auto attendant but cannot make any selection as DTMF does not to work. We don't see this issue calling anyplace else locally or if we call this national Retailer in another geographic area.

    We wire sharked several of the calls to one of the local stores and what we are seeing is 2 different codec in use on the failed calls, the outgoing call stream is using G.711u but the return stream is using G.729. We have the capture setup between the physical phone and the local switch. When we call this same retailer in another area, we only see one codec on the capture, G.711, same with any other local store or local business.

    I also have an InIn CIC system which does not have this problem when calling these stores. It uses an AudioCodes for its main SBC and is setup to offer G.711 and G.729 codec's. I have the 4430 as a backup SBC connection on the InIn system but only had G.711 enabled on that trunk. We setup a static route in the InIn system to use this backup trunk for testing calls to one of the local stores having this issue. The first test calls worked without an issue so I then enabled G.729 on the trunk. On subsequent calls DTMF failed calling. Removed the G.729 and DTMF started working again.

    We tried limiting the codec first to G,711 but still see both codec on the capture and DTMF still does not work. We then swapped the codec to G.729 and call bypass their Auto Attendant and ring a phone at the store. Looks like their Auto Attendant only uses G.711 and if another codec is used the call is routed to a phone.

   Our next step is to update the firmware on the 4430.

Does anyone else have any idea what could solve this issue.

    Doug

[Anonymous · Accepted solution]

Doug,

The codecs shouldn’t don’t have anything to do with DTMF tones. DTMF tones are either inband or outband (RFC 2833) using DTE 101. If you are doing inband DTMF with G.729 and you have congestion on your WAN link then that can cause your DTMF from not working since the tones are send in the RTP packets and the compression of G.729 on top of that.

Can you attach your wireshark capture and explain the phone numbers that are being used in the call and we can take a look at it.

Thanks,

-Mark

[jayh]

DTMF on G.729 isn't going to work inband with any reliability, if at all. On your outbound SIP trunk(s), try adding the following command:

rtp dtmf-relay offer nte 101

This will force RFC2833 for DTMF which should be reliable with any codec.

[dmac]

Made 2 captures, first to local store and second to a out of area store. Couldn't find how to attach the files. Sending a link. Just the 2 call captures. Both calls made from the same phone. Also 7100 trunk config at bottom which includes the dtmf statement.

https://drive.google.com/drive/folders/0ByEV_Q18jfQvR2pJQ09meFdNaVU?usp=sharing

Local Polycom Phone ext: 7464 (IP:10.60.0.116)

Local store#: 813-949-4238

Out of area store #: 352-567-1551

4430 IP: 10.60.0.33

voice trunk T04 type sip

  description "NPR-6355"

  match dnis "NXX-XXXX" substitute "727-NXX-XXXX" name "Add Area code"

  sip-server primary 10.60.0.40

  rtp dtmf-relay offer nte 101

  codec-list g711_first both

    Doug

[Anonymous]

Doug,

What is the difference between the two captures? Is it just two different phone numbers you dialed from the 7464 extension? I noticed that they have same IPs in capture. 116 of phone and 10.60.0.33 of 4430. What is behind the 4430?

What is the 10.126.252.3 address?

Your config has 10.60.0.40 in the sip-server of T04 in your config below. I don’t see that in the capture.

In the debug that has dtmf not working, you are calling 813 area code number, in the SDP of the 200 OK coming back from 10.60.0.33 PCMU is negotiated but that device is sending G729 RTP for some reason. See image below. So for some reason that device is sending back G729. Not good.

On the capture that has DTMF working, you are placing call to a 352 number with same IPs but in that call G711 (PCMU) is used in both directions.

-Mark

[Anonymous]

If you can get download the config of the 7100 you can post it this way:

How to attach a file to your reply. Click "Use Advanced editor" in the top right corner of the reply and then you will see an option below the reply to attach a file.

-Mark

[dmac]

Mark,

   I have opened a support case on this, RQST00004473557. I uploaded the 4430 config and the 7100 config to it.  It's starting to appear that it's a problem stemming from Walmart that the Adtran devices don't like. My coworker started calling Walmarts across the country and found it's hit or miss. He even called 3 in the Alabama area and had the DTMF issue, 256-881-0581, 256-852-2236, 256-837-7272.

Response to your question ,  the difference between the 2 captures. Both calls were made from the same phone, ext 7464. 2 calls to different Walmart's, the 813 area code is a Walmart in Land 'O Lakes Fl and the 352 area code is in Dade City Fl. The call to the 813 store fails with DTMF and shows the G7.29 codec but the 352 store works fine but only shows the G.711 codec. What I was trying to show was the codec issue we were seeing and when we se this on the capture we know if DTMF wil work or not on the call.

Our Adtran config is quite complex. The route in the capture goes from the phone (10.60.0.116 - Phone is a remote phone in my office) that is registered to a 7100 (10.126.252.3), then the 7100 routes the call to a 6355(10.60.0.40) as an internal call distribution router which sends the call to the 4430SBC (10.60.0.33), which anchors the call. From the 4430SBC the call thrn routes out our AT&T Flex SIP Trunk. Once the call is established the RTP traffic is between the phone and the 4430 and the 4430 to AT&T.This configuration is a work in progress as tech support didn't like that I had 20+ 7100's hanging off a pair of 4430's even though we worked with a Adtran Sales person on the original configuration and purchase. We are looking for a device to use for internal call routing but Sales could not suggest an Adtran device for this purpose and I had 2 6355's sitting on the shelf.

The setup I have to work with support is much simpler. I have a 7100 setup in my office that connects directly to one 4430 going to AT&T to streamline the configurations and troubleshooting.

     Doug

[Anonymous]

Doug,

Thanks for the update and info. Yes, a support ticket is going to be much better to solve this than using the forum. Like you said, it is going to take them on the phone with you to get this resolved. Yes, I agree, you have quite a complex setup there! 😃

If you don’t mind, posting the resolution so that those in forum can benefit from your post.

Thanks!

-Mark

[dmac]

Mark,

    Support say's its an upstream issue not a problem in our config. Contacted our carrier to see if they can help and they came back with the remote side is trying to renegotiate the connection from G.711 to G.729 and we are ignoring the request. It still leaves me with questions as to why our AudioCodes SBC doesn't have an issue and why some stores negotiate G.711 and work fine.

  I have contacted Walmart Corporate on this issue with hopes that someone will look at the issue and contact me back.

   Doug

[Anonymous]

Thanks for the update Doug.

-Mark

[dmac · Accepted solution]

Mark,

   I have had a couple of Store managers from WalMart call me about the issue as their corporate office sends it to the local stores to resolve but the local store managers have no control on the technical side have relayed the issue up stream in their chain. It appears this is not considered an issue to them. At this point there is nothing that can be done unless the corporate management at WallyWorld deems it an issue. Even if I set all my devices to G711 only the issue is still there except for the one store in our area.