Hi, in asterisk 1.6.2.16 I get spurious DTMF recognition over SIP from an Audiocodes. I think the DTMF recognition is the Audiocdes' fault, the Audiocodes log seems to say so as well, but I want to make sure, and fixing the Audiocodes is not an option in this particular case - don't ask.
Can someone explain to me what the following means *exactly* [Feb 10 21:15:40] DTMF[2538] channel.c: DTMF begin 'A' received on SIP/sip-out-3-0003a606 [Feb 10 21:15:40] DTMF[2538] channel.c: DTMF begin passthrough 'A' on SIP/sip-out-3-0003a606 [Feb 10 21:15:40] DTMF[2538] channel.c: DTMF end 'A' received on SIP/sip-out-3-0003a606, duration 12 ms [Feb 10 21:15:40] DTMF[2538] channel.c: DTMF end accepted with begin 'A' on SIP/sip-out-3-0003a606 [Feb 10 21:15:40] DTMF[2538] channel.c: DTMF end 'A' detected to have actual duration 59 on the wire, emulation will be triggered on SIP/sip-out-3-0003a606 [Feb 10 21:15:40] DTMF[2538] channel.c: DTMF end 'A' has duration 59 but want minimum 80, emulating on SIP/sip-out-3-0003a606 [Feb 10 21:15:40] DTMF[2538] channel.c: DTMF end emulation of 'A' queued on SIP/sip-out-3-0003a606 Does this mean asterisk's DSP recognizes this inband in the audiostream? Can this also be RFC2833 sent by the audiocodes? Is there some way I can stop this in asterisk, maybe disable detection of the 'A' through 'F' digits in the sourcecode? The setting 'dtmfmode', is it only used on outgoing DTMF? In other words if I set a SIP peer to inband, will incoming RFC 2833 format DTMF still be detected/accepted by asterisk? thanks for any help, Antonio. -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
