Hi
@aws2p
By default we configure phones to send DTMF in RFC2833.
If you call a remote IVR, there is always a small chance that even though you send the correct DTMF signal, the other side still fails to understand it.
Examples:
1. your phone, your pbx, and your trunk provider accept and correctly process RFC2833 (all good until here)
2. the other provider says they accept 2833 but they do not pass it on to their destination (DTMF breaks)
3. the other provider provider accepts 2833, and the destination PBX accepts it, but ignores it internally (DTMF breaks)
4. the other provider provider accepts 2833, but the destination PBX does not accept it. Their provider fails to fallback to in-band (DTMF breaks)
5. The other side does not accept 2833 at all, but their provider fails to inform your provider about it during the invite. (DTMF breaks)
6. The other side does not accept 2833 at all, so your PBX reacts correctly and sends in-band, but due to codec transcoding that takes place outside of your PBX, the in-band DTMF is too degraded, and the other side cannot hear it correctly (DTMF breaks)
So you see, there is no perfect solution here, ultimately it is always a best effort. Do you really need to go and change everything on your side, just because some destinations will not accept DTMF correctly? (and even if you do, you might break other destinations that used to work fine).