Review Board 1.7.16


Fix double DTMF digits when 'dtmfmode=inband' and client sends both 'inband' and 'SIP INFO' packets

Review Request #2165 - Created Oct. 16, 2012 and updated

Alec Davis
1.8 to trunk
ASTERISK-20218
Reviewers
asterisk-dev
Asterisk
Asterisk 1.8.16.0

file:/var/log/asterisk/dtmf when only '2' was hit once
[2012-10-17 19:46:17.879406] DTMF[17084] channel.c: DTMF begin '2' received on SIP/822-00000000
[2012-10-17 19:46:17.879467] DTMF[17084] channel.c: DTMF begin ignored '2' on SIP/822-00000000
[2012-10-17 19:46:17.950953] DTMF[17084] channel.c: DTMF end '2' received on SIP/822-00000000, duration 800 ms
[2012-10-17 19:46:17.951004] DTMF[17084] channel.c: DTMF end passthrough '2' on SIP/822-00000000
[2012-10-17 19:46:18.019135] DTMF[17084] channel.c: DTMF end '2' received on SIP/822-00000000, duration 51 ms
[2012-10-17 19:46:18.019228] DTMF[17084] channel.c: DTMF end passthrough '2' on SIP/822-00000000


In ASTERISK-20218 the attached file it can be seen that both PA2P.rtf has both 'inband' and 'SIP INFO' set. 
Asterisk SVN-branch-1.8-r375111M

I was able to verify the same conditions on a Grandstream GXP2000.

Below is after proposed patch:

file:/var/log/asterisk/dtmf when '820' was entered

[2012-10-17 20:16:18.883821] DTMF[23460] channel.c: DTMF begin '8' received on SIP/822-00000004
[2012-10-17 20:16:18.883868] DTMF[23460] channel.c: DTMF begin ignored '8' on SIP/822-00000004
[2012-10-17 20:16:18.963537] DTMF[23460] channel.c: DTMF end '8' received on SIP/822-00000004, duration 89 ms
[2012-10-17 20:16:18.963559] DTMF[23460] channel.c: DTMF end passthrough '8' on SIP/822-00000004
[2012-10-17 20:16:19.263805] DTMF[23460] channel.c: DTMF begin '2' received on SIP/822-00000004
[2012-10-17 20:16:19.263851] DTMF[23460] channel.c: DTMF begin ignored '2' on SIP/822-00000004
[2012-10-17 20:16:19.363423] DTMF[23460] channel.c: DTMF end '2' received on SIP/822-00000004, duration 89 ms
[2012-10-17 20:16:19.363444] DTMF[23460] channel.c: DTMF end passthrough '2' on SIP/822-00000004
[2012-10-17 20:16:19.643830] DTMF[23460] channel.c: DTMF begin '0' received on SIP/822-00000004
[2012-10-17 20:16:19.643876] DTMF[23460] channel.c: DTMF begin ignored '0' on SIP/822-00000004
[2012-10-17 20:16:19.783561] DTMF[23460] channel.c: DTMF end '0' received on SIP/822-00000004, duration 140 ms
[2012-10-17 20:16:19.783582] DTMF[23460] channel.c: DTMF end passthrough '0' on SIP/822-00000004


Console:

    -- Executing [s@voicemail-main:2] VoiceMailMain("SIP/822-00000004", "") in new stack
    -- <SIP/822-00000004> Playing 'vm-login.gsm' (language 'en')
[2012-10-17 20:16:18.935436] WARNING[23399]: chan_sip.c:19239 handle_request_info: Ignoring DTMF_INFO message as DTMF_INBAND is set on channel SIP/822-00000004
[2012-10-17 20:16:19.325618] WARNING[23399]: chan_sip.c:19239 handle_request_info: Ignoring DTMF_INFO message as DTMF_INBAND is set on channel SIP/822-00000004
[2012-10-17 20:16:19.734910] WARNING[23399]: chan_sip.c:19239 handle_request_info: Ignoring DTMF_INFO message as DTMF_INBAND is set on channel SIP/822-00000004
    -- <SIP/822-00000004> Playing 'vm-password.gsm' (language 'en')
asterix*CLI>
Review request changed
Updated (Oct. 18, 2012, 10:25 p.m.)
Testing: dtmfmode=auto is the only issue, now if only SIP INFO is sent by client they are ignored.

sip.conf	client	client	client
dtmfmode	inband	rfc2833	info
  auto		0	1	1	emits warning, and works     - didn't work before changes
  rfc2833	0	1	1	emits warning, and works     - didn't work before changes

  rfc2833	1	1	1	emits warning, and works     - didn't work before changes
  inband	1	1	1	emits warning, and works     - didn't work before changes
  auto		1	1	1	emits warning, and works     - didn't work before changes
  info		1	1	1	No warning, and works        - did work before changes

  info		1	0	1	No warning, and works        - did work before changes
  inband	1	0	1	emits warning, and works     - didn't work before changes
  auto		1	0	1	emits warning, and works     - didn't work before changes
  rfc2833	1	0	1	emits warning, doesn't work! - didn't work before changes

  auto		0	0	1	emits warning, DOESN'T WORK! - DID WORK before changes

Posted (Oct. 19, 2012, 3:19 a.m.)
Per your comments about testing - I'm not comfortable with INFO no longer working with auto, that's a pretty big behavior change. In that scenario we may have to have it continue to be broken for the DTMF received by multiple means situation. That's a much smaller group of people than those who use auto and INFO and have it just work right now.
  1. Regarding 'auto' and 'INFO' on it's own not working, I agree it should work.
    I also need to test 'auto' and 'RFC2833' on it's own.
    
    I had a line in my previous comments, but got deleted when I edited and repasted my test results.
    'More thought required'
    
  2. with changes, 'dtmfmode=auto' and client sending either RFC2833 or INBAND on there own work as expected.
    
    some how we need to workout 'auto'?
    
    Leaving for AstriCon. Will check at airports.

https://reviewboard.asterisk.org/ runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to asteriskteam@digium.com.