[Freeswitch-dev] A bug in dealing with buggy DTMF handling?

[Örn Arnarson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20121218/2c831a4d/attachment.html