Summary: | ASTERISK-17342: [review][branch] DTMF is delayed through features.c | ||
Reporter: | Olle Johansson (oej) | Labels: | |
Date Opened: | 2011-02-03 02:51:52.000-0600 | Date Closed: | 2011-05-06 14:52:09 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | 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, asterisk starts sending after and the call is interrupted for a total of 8 secs. 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 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. I've also changed two DTMF relay events to actually use the same duration as the incoming DTMF. I have no experience of messing around with features.c and bridges, so please review this carefully. It is proven to work both in a 1.6.0 version and 1.4. | ||
Comments: | By: Olle Johansson (oej) 2011-02-03 02:57:26.000-0600 http://svn.digium.com/svn/asterisk/team/oej/pinesounds-dtmf-feature-delay-1.4 contains this patch. By: Russell Bryant (russell) 2011-05-06 14:52:09 This got committed a while ago |