No subject

      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

........

Modified:
    trunk/   (props changed)
    trunk/main/rtp.c

Propchange: trunk/
------------------------------------------------------------------------------
Binary property 'branch-1.4-merged' - no diff available.

Modified: trunk/main/rtp.c
URL: http://svn.digium.com/svn-view/asterisk/trunk/main/rtp.c?view=diff&rev=175125&r1=175124&r2=175125
==============================================================================
--- trunk/main/rtp.c (original)
+++ trunk/main/rtp.c Thu Feb 12 10:57:25 2009
@@ -1749,6 +1749,21 @@
 	/* Record received timestamp as last received now */
 	rtp->lastrxts = timestamp;
 
+	if (rtp->dtmfcount) {
+		rtp->dtmfcount -= (timestamp - rtp->lastrxts);
+
+		if (rtp->dtmfcount < 0) {
+			rtp->dtmfcount = 0;
+		}
+
+		if (rtp->resp && !rtp->dtmfcount) {
+			struct ast_frame *f;
+			f = send_dtmf(rtp, AST_FRAME_DTMF_END);
+			rtp->resp = 0;
+			return f;
+		}
+	}
+
 	rtp->f.mallocd = 0;
 	rtp->f.datalen = res - hdrlen;
 	rtp->f.data.ptr = rtp->rawdata + hdrlen + AST_FRIENDLY_OFFSET;