[asterisk-commits] oej: branch oej/rana-dtmf-rtp-duration-1.6.0 r305797 - in /team/oej/rana-dtmf...

Wed Feb 2 12:08:34 CST 2011

Author: oej
Date: Wed Feb  2 12:08:31 2011
New Revision: 305797

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=305797
Log:
ADding documentation on discoveries in main/features.c

Modified:
    team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration
    team/oej/rana-dtmf-rtp-duration-1.6.0/main/features.c

Modified: team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration
URL: http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration?view=diff&rev=305797&r1=305796&r2=305797
==============================================================================

--- team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration (original)
+++ team/oej/rana-dtmf-rtp-duration-1.6.0/README.rana-dtmf-rtp-duration Wed Feb  2 12:08:31 2011
@@ -5,10 +5,15 @@
 This branch is trying to focus on DTMF in the RTP channel. Asterisk 1.4 and later
 doesn't send the proper DTMF duration on the outbound call leg. If we receive
 a DTMF with a duration of 480 samples, we might end up sending 1440 samples out.
+Another issue is the delayed transmission when using the core bridge with features
+enabled. If you send a three second DTMF inbound, the outbound begins after the inbound
+ends, so you get a six second interruption to the call.
 
 In order to handle this a lot of bugs was fixed. We also added a new control
 frame to update the outbound channel with the latest duration from the inbound,
 in order to try to prevent the outbound channel to run ahead of the inbound.
+If the outbound channel gets these frames, it will stop adding to the outbound
+DTMF, but retransmit previous message instead.
 
 The outbound channel sends a packet for every incoming RTP packet. As usual,
 the inbound and outbond channels are not synchronized at all. So the outbound
@@ -20,3 +25,9 @@
 transmission. We do not break outbound DTMF when we receive inbound
 DTMF end, we continue until we have reached the duration of the DTMF that
 we received on the inbound channel.
+
+By adding a ast_feature_check function to main/features.c we now check 
+the DTMF on the incoming DTMF_BEGIN. If it's not a feature code it's 
+immediately forwarded to the outbound channel. If it's a feature code,
+it's dropped and the feature channel waits for DTMF_END (like now).
+This dramatically changes DTMF behaviour in a PBX bridged call.

Modified: team/oej/rana-dtmf-rtp-duration-1.6.0/main/features.c
URL: http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-rtp-duration-1.6.0/main/features.c?view=diff&rev=305797&r1=305796&r2=305797
==============================================================================
--- team/oej/rana-dtmf-rtp-duration-1.6.0/main/features.c (original)
+++ team/oej/rana-dtmf-rtp-duration-1.6.0/main/features.c Wed Feb  2 12:08:31 2011
@@ -1794,7 +1794,9 @@
 			if (operation) {
 				res = tmpfeature->operation(chan, peer, config, code, sense, tmpfeature);
 			}
-			memcpy(feature, tmpfeature, sizeof(feature));
+			if (feature) {
+				memcpy(feature, tmpfeature, sizeof(feature));
+			}
 			if (res != AST_FEATURE_RETURN_KEEPTRYING) {
 				AST_RWLIST_UNLOCK(&feature_list);
 				break;
@@ -2205,6 +2207,7 @@
 	int hasfeatures=0;
 	int hadfeatures=0;
 	int autoloopflag;
+	int sendingdtmfdigit = 0;
 	struct ast_option_header *aoh;
 	struct ast_bridge_config backup_config;
 	struct ast_cdr *bridge_cdr = NULL;
@@ -2389,12 +2392,10 @@
 					   digits to come in for features. */
 					ast_debug(1, "Timed out for feature!\n");
 					if (!ast_strlen_zero(peer_featurecode)) {
-						ast_log(LOG_DEBUG, "--- Sending DTMF here\n");
 						ast_dtmf_stream(chan, peer, peer_featurecode, 0, f->len);
 						memset(peer_featurecode, 0, sizeof(peer_featurecode));
 					}
 					if (!ast_strlen_zero(chan_featurecode)) {
-						ast_log(LOG_DEBUG, "--- Sending DTMF here - 2\n");
 						ast_dtmf_stream(peer, chan, chan_featurecode, 0, f->len);
 						memset(chan_featurecode, 0, sizeof(chan_featurecode));
 					}
@@ -2461,9 +2462,7 @@
 				}
 				break;
 			}
-		} else if (f->frametype == AST_FRAME_DTMF_BEGIN) {
-			/* eat it */
-		} else if (f->frametype == AST_FRAME_DTMF) {
+		} else if (f->frametype == AST_FRAME_DTMF || f->frametype == AST_FRAME_DTMF_BEGIN) {
 			char *featurecode;
 			int sense;
 			unsigned int dtmfduration = f->len;
@@ -2482,10 +2481,19 @@
 			 * \todo XXX how do we guarantee the latter ?
 			 */
 			featurecode[strlen(featurecode)] = f->subclass;
+			config->feature_timer = backup_config.feature_timer;
+
+			if (f->frametype == AST_FRAME_DTMF_BEGIN) {
+				/* Take a peek if this is the beginning of a feature. If not, just pass this DTMF along untouched. */
+				res = ast_feature_detect(chan, sense == FEATURE_SENSE_CHAN ? &(config->features_caller) : &(config->features_callee),featurecode, NULL);
+				if (res == FEATURE_RETURN_PASSDIGITS) {
+					ast_log(LOG_DEBUG, "We are doing nothing here, but this DTMF is not a feature code\n");
+				}
+				break;
+			}
 			/* Get rid of the frame before we start doing "stuff" with the channels */
 			ast_frfree(f);
 			f = NULL;
-			config->feature_timer = backup_config.feature_timer;
 			res = ast_feature_interpret(chan, peer, config, featurecode, sense);
 			switch(res) {
 			case FEATURE_RETURN_PASSDIGITS:


