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:
    branches/1.4/main/rtp.c

Modified: branches/1.4/main/rtp.c
URL: http://svn.digium.com/svn-view/asterisk/branches/1.4/main/rtp.c?view=diff&rev=175124&r1=175123&r2=175124
==============================================================================
--- branches/1.4/main/rtp.c (original)
+++ branches/1.4/main/rtp.c Thu Feb 12 10:51:13 2009
@@ -1298,6 +1298,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;