CM8 and DTMF

[fishnoob]

Hey all, hope everyone is doing well this holiday season!

We are on an R8 environment with Session Manager and SIP trunks across the enterprise. Has anyone experienced an issue where instead of an actual DTMF tone, you hear a key press instead, similar to the sound like that of pressing a key on your keyboard? It's like a tick more so than a tone. Funny thing is, it only occurs when it happens when the Avaya user is pressing a touch tone, the customer/far end hears the tick. If the customer/far end presses a key, the DTMF tone is heard on the Avaya end.

Extension to extension, DTMF tones work fine on both ends as well.

This is what we believe to be causing our AT&T *8 failures and are trying to tackle this. We tested this with a PRI on a G450 as well, same result.

Does Avaya have a particular port that's required for touch tones? Our CM8 is behind a firewall.....

Any help is appreciated. i'm rather stuck at this point.

 

[kyle555]

Do you have SIP phones or not? They have a parameter in the settings file for how they do DTMF.
I don't know what dialing *8 means on AT&T by the way.

In your SIP signaling groups, you have a DTMF over IP setting.
pg 688

https://download.avaya.com/css/public/documents/101050635

You're probably at RTP-payload and that's probably what you should be at.

In-band means real audio tone in the speech path. If you listened to a call in wireshark, you'd hear it. It's not preferable because it needs a gateway resource to generate the tone.
Out of band means a SIP signaling message of type "INFO". If you were looking at a wireshark trace, you'd see a SIP message of type "info" saying "he pressed 2"
RTP payload means it's in the RTP stream, but is a different type of media than G711.

Somewhere in your SIP trunk group is a setting for DTMF payload type, might be 127. If you look at a SIP trace for an outbound call from CM, you'll probably see in the SDP a m=audio line with a value of 0, 127. 0 means g711u, 127 means dtmf.

If you look at the RTP of a call with DTMF as RTP payload, you'll see packets in wireshark with "media type 127" and drilling down in the content of the packet, you'll see it's "he pressed 2". If you do it from an Avaya SIP phone, you'd see G711 packets stop and RTP packets start for a short time, but they'd always be same source/destination IP/port as the G711.

In AAM and IX Messaging, you have to pick 1 kind of DTMF type - almost always RTP payload. In Experience Portal, you can pick in-band and/or RTP - so it can listen for both.

Odds are if you call voicemail internally and wiresharked the audio, you'd see the RTP-payload type of packet representing your touch tones.
I wonder what would happen if you called a PSTN access number for voicemail from inside the enterprise to loop it through the PSTN to see if there was some problem there.

If you had 2 Avaya SIP phones on the same system doing RTP payload DTMF and started pushing tones to one another, I'm not sure if you'd hear them or not, but if you did, I'm positive it'd be the receiving phone interpreting the RTP payload message of "he pressed 2" and deciding to play an internal wave file of the sound of DTMF 2. To say, maybe the far end is getting it right but whatever the far end device is thinks it might not be worth playing a sound to the user.

When you say you tested it with a G450 and PRI too, in that case, the G450 would receive that RTP payload packet and make a real tone on the B channel. What is that PRI connected to? Straight to the CO or some ISDN/SIP middleware box?

Is your AT&T SIP setup through an Avaya SBC and Session Manager? There's certainly an interop note you could use to stare and compare your settings vs the specific config Avaya certified.

Ultimately, what problem are you trying to solve? Is it something like your tones are never heard by the far end? Or just sometimes?

 

[fishnoob]

Kyle,

firstly thank you for your reply to mine and all the other threads throughout the community!

As to answer your question of what we are trying to solve, we are trying to ensure that DTMF is heard on both parties, near and far, when buttons are pressed on our Avaya phones.

We are using H.323 9611 type sets with NO sip phones on site unfortunately. As for our DTMF over IP, we are using RTP-Payload and the payload type is 100 or 101 as seen in the "m" line on the SBC.

We are on audiocodes SBC (SIP trunks) and Media Gateways (TDM DS3 trunks)

*8 is the take back and transfer feature that is offered by AT&T so you don't utilize further trunks necessary and the original ANI information is restored. Some refer to it as a network redirect, and we rely heavily upon it. We feel that once we can fix the DTMF tones being heard on the PSTN, we would be able to resolve the *8 failures as well.

Sounds like what you've suggested is already in place so I'm truly at a loss here. Will get the voicemail thing set up to test, however with the holiday season being in swing we are hard pressed to touch the system unnecessarily.

Thanks again for your help! Should any other suggestions, please feel free to include them!

 

[kyle555]

Everything I can find points to you doing it via SIP REFER and not in-call signaling.

https://www.devconnectprogram.com/fileMedia/download/719aa774-5288-4867-abcd-0278f687babe

So, I don' think *8 is something AT&T would listen for in-band in your call to give you another dialtone. I think CM should be smart enough to know what to do.