dtmf generation problem on K3765

[GoogleCodeExporter]

What steps will reproduce the problem?
1. have the dongle idle overnight
2. call some IVR menu (in my case, the operator's IVR to check balance, top up, 
etc.)
3. after first night, dongle just hung up instead of sending dtmf, after second 
night, at^dtmf command appeared to work, but IVR didn't detect dtmf digits.

What is the expected output? What do you see instead?
Expected: just worx :-P
Got:
first time: at^dtmf timeout, chan_dongle disconnecting dongle (but dongle 
itself did not reset!)
second time: at^dtmf reporting no problems, but receiving side not detecting 
dtmf digits

What version of the product are you using? On what operating system?
1.1r10 from tgz
linux 2.6.32, asterisk 1.8.4.4

Please provide any additional information below.
See also attached file.
K3765 firmware version: 11.126.03.06.00

This might be an issue with dongle firmware. Too bad I haven't found a way to 
reliably reproduce this. And of course I wasn't smart enough to try calling my 
landline when the operator's menu didn't detect tones. Will try that when the 
situation pops up again.

Related question: is there a reason why the dongle is used to do the DTMF 
generation, and not simply have Asterisk do this inband for all dongles? IIRC, 
GSM supports inband only, so it has to go inband anyway. One could just skip 
the entire channel_digit_begin?

Original issue reported on code.google.com by mcbchand...@robuust.nl on 8 Aug 2011 at 1:20

Attachments:

• 1244dtmftimeout_notreceived.txt

[GoogleCodeExporter]

return -1 from channel_digit_begin() is want asterisk core to generate DTMF 
inband 

Original comment by bg_...@mail.ru on 8 Aug 2011 at 9:02

[GoogleCodeExporter]

Yes, I know that returning -1 would result in asterisk generating the dtmf. I 
was just curious to find out why the code exists to have the dongle generate 
dtmf. Is it just historic, or maybe the dongle-generated dtmf is more reliable 
due to dongle-internal volume control?
If there is no real advantage in dongle-generated dtmf, the more clean solution 
(imho) would be to just delegate it to asterisk. If there is an advantage, that 
should be documented...

Of course, this bugreport is about a bug in some code, maybe in the dongle 
firmware, maybe somewhere else, so it is still a good idea to find out if we 
can track this issue down and fix it anyway, regardless of the question who 
should generate dtmf ;-)
If it's in the dongle firmware, maybe that should be documented as well.

Original comment by mcbchand...@robuust.nl on 8 Aug 2011 at 9:21

[GoogleCodeExporter]

Did some more testing with this.

When IVR system is not responding to DTMF keys, it also doesn't work when 
generating inband DTMF (i.e. playing dtmf digits and holding receiver in front 
of speakers).
When hanging up and redialing, it worked again, so no dongle reset/reload 
necessary. Generated inband dtmf through speakers also works after redialing, 
so should have worked even if DTMF generation in the dongle was bugged.

So, maybe it's not the dtmf generation that's bugged, but maybe it's the audio 
not being sent to the remote party...
I'll switch the dongle to 2G-only mode and use a radio to find out whether or 
not it is sending anything at all when dtmf in the menu isn't working ;-)

(There is a slight chance the provider's IVR isn't detecting DTMF due to a 
problem with their system, but that's not very likely.)

Original comment by mcbchand...@robuust.nl on 15 Aug 2011 at 10:31