Terry Wilson
authored
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r310902 | twilson | 2011-03-16 12:19:57 -0500 (Wed, 16 Mar 2011) | 43 lines Merged revisions 310889 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines Merged revisions 310888 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines Don't delay DTMF in core bridge while listening for DTMF features This patch is mostly the work of Olle Johansson. I did some cleanup and added the silence generating code if transmit_silence is set. When a channel listens for DTMF in the core bridge, the outbound DTMF is not sent until we have received DTMF_END. For a long DTMF, this is a disaster. We send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds. Some products see this delay and the time skew on RTP packets that results and start ignoring the audio that is sent afterward. With this change, the DTMF_BEGIN frame is inspected and checked. If it matches a feature code, we wait for DTMF_END and activate the feature as before. If transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a multi-digit feature. If it doesn't match a feature, the frame is forwarded along with the DTMF_END without delay. By doing it this way, DTMF is not delayed. (closes issue #15642) Reported by: jasonshugart Patches: issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396) Tested by: globalnetinc, jde (closes issue #16625) Reported by: sharvanek Review: https://reviewboard.asterisk.org/r/1092/ Review: https://reviewboard.asterisk.org/r/1125/ ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310941 65c4cc65-6c06-0410-ace0-fbb531ad65f3