[asterisk-dev] DTMF offer oddities

[Sebastian Damm]

Hi,

I've noticed some changes in handling of DTMF offers in SIP packages
since my last update of Asterisk to 1.2.16.

The behavior was somehow "foreseeable" still at version 1.2.13, at 1.2.15
it was already "different". Don't know about 1.2.14.

Here is how it should be (according to my knowledge):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SIP INFO:
Clients are only allowed to send INFO packets, if INFO is listed in the
Allow line (if present). Otherwise the client must not send INFO packets
at all.

RfC2833:
Clients shall only send RfC2833 RTP event packages, if there are lines
like the following in the SDP part of the INVITE/183/200 OK:

	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16

If those lines are missing, the devices indicates that it cannot process
RTP event packages.

inband:
Inband DTMF tones can be sent always, as they are transmitted within the
audio stream. 


Now what Asterisk is doing. You have two ways of defining the DTMF mode.
One is in sip.conf and one is in the dialplan with the DTMFMode command.

If you have set dtmfmode=rfc2833 in sip.conf:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When replying to incoming INVITEs, which don't have those rtpmap lines
mentioned above, Asterisk doesn't offer rtpevents. Why? If I want some
kind of autodetection, I set dtmfmode to auto in sip.conf.

When replying to incoming INVITEs with rtpevents offered, Asterisk
includes rtpevents, too. So that behavior is fine.

When setting the dtmfmode dynamically to info via dialplan, asterisk does
not offer rtpevents. That should be correct, too. But Asterisk does not
append the INFO method to the Allow line.


If you have set dtmfmode=info in sip.conf:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Asterisk does never append the INFO method to the Allow line. This
behavior has always been like this. Devices checking on the Allow line
will never send INFO packets to an Asterisk server.

When setting the dtmfmode to rfc2833 dynamically via dialplan, Asterisk
does not offer rtpevents in it's answers. Clients checking on this send
DTMF tones inband because neither the allow line nor the rtpevents line
indicate one of the "better" method being supported.


In Asterisk 1.2.13 at least the rtpevents were always offered, no matter
what the dtmfmode setting said. While that was also not correct, it
allowed most clients to communicate at least via rfc2833 with our
servers. 

Background: We have the peers in our network set to dtmfmode=info as
standard, then we set the dtmfmode to rfc or inband if required in a
conversation. This does not work anymore for some clients since the
update to 1.2.16, because some clients which sent rfc2833 dtmf tones
before now send their dtmf tones inband.


From my point of view the behavior of dtmf offers is buggy. Can we do
something about it?

Best regards,
Sebastian