| Summary: | ASTERISK-25315: DAHDI channels send shortened duration DTMF tones. | ||
| Reporter: | Richard Mudgett (rmudgett) | Labels: | |
| Date Opened: | 2015-08-11 12:35:15 | Date Closed: | 2015-08-12 13:39:23 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_dahdi |
| Versions: | 11.19.0 13.5.0 | Frequency of Occurrence | Frequent |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) asterisk_25315_digits.wav ( 1) asterisk_25315_full.txt | |
| Description: | Pressing DTMF digits on a phone to go out on a DAHDI channel can result in the digit not being recognized or even heard by the peer.
{noformat} Phone -> Asterisk -> DAHDI/channel {noformat} Turns out the DAHDI behavior with DTMF generation (and any other generated tones) is exposed by the {{buffers=}} setting in {{chan_dahdi.conf}}. When Asterisk requests to start sending DTMF then DAHDI waits until the write buffer is empty before generating any samples for the DTMF tones. When Asterisk subsequently requests DAHDI to stop sending DTMF then DAHDI immediately stops generating the DTMF samples. As a result, the more samples there are in the write buffer the shorter the time DTMF actually gets sent on the wire. If there are more samples in the write buffer than the time DTMF is supposed to be sent then no DTMF gets sent on the wire. With the {{buffers=12,half}} setting and each buffer representing 20 ms of samples then the write buffer is going to contain around 120 ms of samples. For DTMF to be recognized by the peer the actual sent DTMF duration needs to be a minimum of 40 ms. Therefore, the intended duration needs to be a minimum of 160 ms for the peer to receive the minimum DTMF digit duration to recognize it. A simple and effective solution to work around the DAHDI behavior is for Asterisk to flush the write buffer when sending DTMF so the full duration of DTMF is actually sent on the wire. When someone is going to send DTMF they are not likely to be talking before sending the tones so the flushed write samples are expected to just contain silence. | ||
| Comments: | By: Richard Mudgett (rmudgett) 2015-08-11 12:57:15.917-0500 The attached files were made with a modified Asterisk that added debug messages to show what happens better: PJSIP/202 calls PJSIP/201 where this call's channel chain is: {noformat} PJSIP/202-00000000 -> DAHDI/i1/2564286001-1 -> PRI -> DAHDI/i2/0000000202-1 -> PJSIP/201-00000001 {noformat} The TE205P card's T1 PRI spans 1 and 2 are connected by a cross over cable so everything is available on one box. [^asterisk_25315_full.txt] - Log capture of an established call sending digits 1-9, 0, *, #. Only the 1, 6, 8, *, and # went through. The BUGBUG log messages show that the DAHDI/i1 channel is passing the digits to DAHDI but they are not getting to the other side for the DAHDI/i2 channel to see them. [^asterisk_25315_digits.wav] - dahdi_monitor capture of the received audio on PRI span 2. Capture command used: {{dahdi_monitor 25 -m -r asterisk_25315_digits.wav}} The key option set in {{chan_dahdi.conf}} for the PRI channels is {{buffers=12,half}}. | ||