<div dir="ltr">Hello,<div><br></div><div>I'm dealing with an end device whose designers don't seem to grasp the concept of negotiation.</div><div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>Any thoughts on the matter? Is this a conscious choice?</div><div style><br></div><div style>I'm running FS stable, version 1.2.3.</div><div style><br></div><div style>Regards,</div><div style>
Örn</div></div>