[svn-commits] oej: branch oej/rana-dtmf-duration-1.8 r369560 - in /team/oej/rana-dtmf-durat...

[SVN commits to the Digium repositories]

Author: oej
Date: Tue Jul  3 09:56:52 2012
New Revision: 369560

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=369560
Log:
Adding some bits and pieces

Modified:
    team/oej/rana-dtmf-duration-1.8/   (props changed)
    team/oej/rana-dtmf-duration-1.8/res/res_rtp_asterisk.c

Propchange: team/oej/rana-dtmf-duration-1.8/
------------------------------------------------------------------------------
--- automerge (original)
+++ automerge Tue Jul  3 09:56:52 2012
@@ -1,1 +1,1 @@
-*
+Is-there-life-off-net?

Modified: team/oej/rana-dtmf-duration-1.8/res/res_rtp_asterisk.c
URL: http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-duration-1.8/res/res_rtp_asterisk.c?view=diff&rev=369560&r1=369559&r2=369560
==============================================================================
--- team/oej/rana-dtmf-duration-1.8/res/res_rtp_asterisk.c (original)
+++ team/oej/rana-dtmf-duration-1.8/res/res_rtp_asterisk.c Tue Jul  3 09:56:52 2012
@@ -167,7 +167,7 @@
 	enum dtmf_send_states sending_dtmf;     /*!< - are we sending dtmf */
 	char send_digit;	/*!< digit we are sending */
 	char send_dtmf_frame;	/*!< Number of samples in a frame with the current packetization */
-	AST_LIST_HEAD_NOLOCK(, ast_frame) dtmfqueue;	/*!< Queue for DTMF that we receive while occupied with transmitting an outbound DTMF */
+	AST_LIST_HEAD_NOLOCK(, ast_frame) dtmfqueue;	/*!< \ref DTMFQUEUE : Queue for DTMF that we receive while occupied with transmitting an outbound DTMF */
 	struct timeval dtmfmute;
 
 	int send_payload;
@@ -339,6 +339,25 @@
 	.sendcng = ast_rtp_sendcng,
 };
 
+/*! * \page DTMFQUEUE Queue for outbound DTMF events
+
+	The Asterisk RTP Engine contains a queue for outbound DTMF events. Because of Asterisk's
+	architecture, we might have situations where DTMF events are not happening at the same
+ 	time on the inbound call leg and the outbound. Because the feature handling, we might
+	"swallow" a DTMF for a while to figure out the next digit. When we realize that this
+	is not a digit we want, we start playing out the complete DTMF on the outbound call leg.
+
+	During that time, we might get an incoming DTMF begin signal on the inbound call leg,
+	which is transported over the bridge and to the outbound call leg, that gets a 
+	request to begin a new DTMF, while still playing out the previous one.
+
+	In order not to drop this DTMF, we queue it up until we're done with the previous
+	DTMF and then play it out.
+
+	The DTMF queue is held in the rtp structure. 
+*/
+
+
 static inline int rtp_debug_test_addr(struct ast_sockaddr *addr)
 {
 	if (!rtpdebug) {
@@ -676,6 +695,7 @@
 	if (rtp->sending_dtmf) {
 		ast_debug(3, "Received DTMF begin while we're playing out DTMF. Ignoring \n");
 		rtp->sending_dtmf = DTMF_SEND_INPROGRESS_WITH_QUEUE;	/* Tell the world that there's an ignored DTMF */
+	//	AST_LIST_INSERT_TAIL(&frames, f, frame_list);
 /* OEJ Fix ??? */
 	}