aboutsummaryrefslogtreecommitdiffstats
path: root/res
diff options
context:
space:
mode:
authorrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2009-02-12 16:51:13 +0000
committerrussell <russell@f38db490-d61c-443f-a65b-d21fe96a405b>2009-02-12 16:51:13 +0000
commit4ae6029018d87aafd95f1bd55e55e54ca2544cb5 (patch)
treefa7622add1f34c318a96c8a1c443393b36f34433 /res
parent3dac9575b009ab5f5ac301acc733f60908ae5c2f (diff)
Don't send DTMF for infinite time if we do not receive an END event.
I thought that this was going to end up being a pretty gnarly fix, but it turns out that there was actually already a configuration option in rtp.conf, dtmftimeout, that was intended to handle this situation. However, in between Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost. So, this commit brings it back to life. The default timeout is 3 seconds. However, it is worth noting that having this be configurable at all is not really the recommended behavior in RFC 2833. From Section 3.5 of RFC 2833: Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. Three seconds will pretty much _always_ be far more than three packet interarrival times. However, that behavior is not required, so I'm going to leave it with our legacy behavior for now. Code from svn/asterisk/team/russell/issue_14460 (closes issue #14460) Reported by: moliveras git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@175124 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'res')
0 files changed, 0 insertions, 0 deletions