[asterisk-bugs] [JIRA] (ASTERISK-25315) DAHDI channels send shortened duration DTMF tones.

[Richard Mudgett (JIRA)]

Richard Mudgett created ASTERISK-25315:
------------------------------------------

             Summary: DAHDI channels send shortened duration DTMF tones.
                 Key: ASTERISK-25315
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25315
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_dahdi
    Affects Versions: 13.5.0, 11.19.0
            Reporter: Richard Mudgett


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.




--
This message was sent by Atlassian JIRA
(v6.2#6252)