Hello, I'm dealing with an end device whose designers don't seem to grasp the concept of negotiation. The device in question "supports" inband DTMF as well as RFC2833. However, once you set it to either, it will blindly use it, regardless of the support of the other end. I have a scenario now where I set dtmf_type=none, and export dtmf_type=none in the dialplan for certain calls, and this works beautifully for devices that actually listen and don't transmit RFC2833 when it's not an option in the SDP. However, when the device sends RFC2833 in spite of it not being supported as per the SDP, FreeSwitch will send the DTMF to the b-leg as SIP-INFO, despite dtmf_type having been set to none. If I export dtmf_type=rfc2833, it will correctly use RFC2833 for the b-leg. If I do not export it at all it will also use RFC2833. Most likely, it's not intended for FS to use SIP-INFO when explicitly told to use inband, even though the device on the A-leg is buggy. Any thoughts on the matter? Is this a conscious choice? I'm running FS stable, version 1.2.3. Regards, Örn