DTMF issue with SIP trunk

[arunknair82]

We are facing an issue while making outgoing calls using SIP line, the DTMF input that we are sending is not recognized by the other end(Auto attendand/IVR) but when we use analog trunk to make calls it works fine.
Another strange thing is it works fine on sip trunk callsto some numbers and doesn't work on some numbers.
I checked with SIP provider and they said they are offering inband DTMF and i noticed that in our configuration all extensions the outband DTMF is selected under VOIP tab. If i uncheck this, DTMF over SIP trunk works fine but DTMF over analog stops working
Is there any solution for this.

 

[janni78]

You can select Inband on the SIP trunks VoIP tab.

"Trying is the first step to failure..." - Homer

 

[arunknair82]

Currentlly i selected RFC2833 because in the email fromSIP provider they mentioned below:
Protocol= SIP
SIP Port = 5060
Transport Protocol=UDP
Voice Codec= G711 A-Law
DTMF = IN-Band DTMF with RFC2833

I will change to inband will it break anything?

 

[janni78]

Well, if they support RFC2833 it should work but they might not know what they are talking about and you can try with Inband =)

"Trying is the first step to failure..." - Homer

 

[amriddle01]

This is an article I always quote to explain this issue, chances are it's not you...

What are the problems with DTMF and VoIP?

In some VoIP routes a switch may be configured to detect in-band DTMF which is sent by the VoIP ATA, but then switches to an out of band RFC2833 DTMF required for an upstream provider. This upstream carrier then terminates the call to the PSTN, possibly to a voice mail system, which will require regeneration of the audible inband DTMF tones. The switch has to detect and remove the tone sent by the ATA from the audio stream because the upstream provider specified RFC2833 DTMF. At times the switch can't always completely remove the in-band DTMF tone which is a problem, because by the time it has detected the DTMF tone, it has already passed a short amount of it. This small amount of in-band tone along with the RFC2833 tone sent are both received by the far end voice mail system which will then register an error (problem), possibly an invalid mailbox or invalid password.

Troubleshooting DTMF problems with your VoIP connection.

Troubleshooting DTMF issues are hit and miss and may be as simple as using a different DTMF setting and retrying. But, before making any changes with settings make sure that the issues that you are experiencing are not related to packet loss. Packet loss can create havoc with VoIP connections and in relation DTMF tones. Some things that you might look to try are:
Check for and correct any packet loss.
Call your provider and ask what options they may have to correct issues with DTMF. They may be able to change the setting to Inband to see if that helps.

Transmission carried Inband DTMF is only considered to be reliable when the G711 (non-compressed) codec is used. If G729 is being used and the DTMF is set to use Inband it usually fails due to the compression. The rfc2833 DTMF setting is generally considered to be the most reliable.

 

[arunknair82]

Tried everything possible under settings related with DTMF. Still DTMF is not recognized when call another companies toll free number. This issue only with this number and strangely if we call it from mobile it accepts the DTMF.
Literally stuck!

 

[amriddle01]

Yes you are, it's not you, it's the carrier(s) and how they interact with the destination/along the way

 

[arunknair82]

But it works when i uncheck the out band dtmf under each Voip tab of each extension but breaks DTMF on existing analog trunks
Will this create any other problems. I can set the Analog trunks only for incoming and use the SIP for outgoing
What exactly should i tell the provider to change from their end.

 

[amriddle01]

What exactly should I tell the provider to change from their end

Nothing, and they couldn't anyway. It's an imperfection in the technology/protocols used really. The way SIP works actually makes it a poor fit as a protocol for for running voice/real-time communications..... ironically

Not everyone using SIP will ever see this, some see it a lot...what can you do...