[svn-commits] oej: branch oej/roibus-comfort-noise-trunk r393726 - in /team/oej/roibus-comf...

SVN commits to the Digium repositories svn-commits at lists.digium.com
Fri Jul 5 07:04:47 CDT 2013


Author: oej
Date: Fri Jul  5 07:04:45 2013
New Revision: 393726

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=393726
Log:
Will use this branch for the rest of the work too

Added:
    team/oej/roibus-comfort-noise-trunk/res/res_noise.c   (with props)
Modified:
    team/oej/roibus-comfort-noise-trunk/README.roibos-cng.txt

Modified: team/oej/roibus-comfort-noise-trunk/README.roibos-cng.txt
URL: http://svnview.digium.com/svn/asterisk/team/oej/roibus-comfort-noise-trunk/README.roibos-cng.txt?view=diff&rev=393726&r1=393725&r2=393726
==============================================================================
--- team/oej/roibus-comfort-noise-trunk/README.roibos-cng.txt (original)
+++ team/oej/roibus-comfort-noise-trunk/README.roibos-cng.txt Fri Jul  5 07:04:45 2013
@@ -3,7 +3,7 @@
 
 
 Started: 2012-09-18
-Updated: 2012-11-19
+Updated: 2013-07-05
 
 
 
@@ -146,169 +146,15 @@
 =============
 From file:
 
-The logic for determining if a native bridge can be performed or not lives in ast_channel_bridge in channel.c - there is an if statement with many conditions that have to be met before doing it. You can extend that and add another which is "if the CN support on channel A is the same as channel B then allow native bridge"
+The logic for determining if a native bridge can be performed or not lives in
+ast_channel_bridge in channel.c - there is an if statement with many conditions
+that have to be met before doing it. You can extend that and add another which 
+is "if the CN support on channel A is the same as channel B then allow native bridge"
 
 Question: If I run RTP bridge (not the p2p or remote) can we still operate
 on timer? If not, I have to disable RTP bridging totally. If we rely on incoming
 packets (which will not happen) to send out, CN will not work.
 
-Yes, you can still operate on timer. The RTP bridge still has all the normal bridging logic in it. That's how music on hold and such works.
+Yes, you can still operate on timer. The RTP bridge still has all the normal 
+bridging logic in it. That's how music on hold and such works.
 
-
-Edvina AB
-Olle E. Johansson
-
-
-Started: 2012-09-18
-Updated: 2012-11-19
-
-
-
-
-
-Comfort Noise support in Asterisk 1.8
-=====================================
-
-Comfort Noise in SIP/RTP is 
-- negotiated in the SDP as a codec
-- starts activated by a silence in the media stream
-- the sender stops sending media, sends a single CNG RTP packet that indicates
-  a noise level
-- the receiver activated a Comfort Noise Generator in the call until media 
-  reappears from the sender
-
-A requirement for using this is that it is included as a codec with payload
-13 (or dynamic) in the SDP
-
-Asterisk Architecture
-=====================
-In a bridged call, where one end is SIP with CNG enabled, the RTP system
-will get an incoming CNG frame with a noise level. This will be sent
-over the bridge to the bridged channel.
-
-If that channel is SIP with CNG enabled for the call, the RTP system
-will send out a CNG frame.  This is to enable forwarding a CNG frame 
-across to another SIP device which now gets the responsibility to play out 
-the noise.
-
-It that channel is a type that doesn't support CNG or SIP with CNG
-disabled, then Asterisk needs to generate noise in the bridged
-channel - not the SIP channel that received the CNG frame. 
-
-Current state:
-==============
-
-* RTP Channel
--------------
-
-- Asterisk RTP (res_rtp_asterisk.c) will read CNG packets and produce a warning. 
-  These will be forwarded to the core.
-- CNG packets will be sent only as RTP keepalives
-
-* SIP Channel
--------------
-- The SIP channel will negotiate any CNG support if offered and
-  offer CNG if configured. SIP.conf setting:
-	;comfort-noise=yes              ; Enable Comfort Noise generation on RTP streams
-	;                               ; Available per device too
-
-* Core
-------
-- If a generator is active and CNG is received, Asterisk moves to timer based
-  generation of outbound packets
-- Comfort noise generator added to core
-- Comfort noise generator will be used when CNG frame is received, until the RTP
-  channel signals that CNG will end.
-
-Debugging
-=========
-Place a call between one phone that supports CN (I've used a SNOM 820) and a
-phone that lacks support for it (or has it disabled for testing). 
-- Turn on RTP debug and SIP debug.
-- Set core debug to 3.
-You will now see that Asterisk receives a CN RTP packet, and will activate
-the noise generator on the other channel. This happens many times during 
-the call.
-
-Todo :: comfort noise support
------------------------------
-  - Check how this affects RTP bridge and queue bridge
-  - Add CN support in SDP for outbound calls
-  - As step 2, add silence detection to calls
-  	- Measure noise level
-  	- Start sending CNG
-  	- Listen for talk detection
-  	- Stop sending CNG, send media
-
-Done:
-  - Support in core bridge
-  - For inbound streams, generate noise in calls (both inbound and outbound calls)
-  - Added res_noise.c from cmantunes from https://issues.asterisk.org/jira/browse/ASTERISK-5263
-    This includes a noise generator
-  - Add SIP negotiation in SDP - done
-  - Support CN codec on incoming INVITEs - done
-
-References
-----------
-
-- RFC 3389 http://tools.ietf.org/html/rfc3389
-- Appendix II to Recommendation G.711 (02/2000) - A comfort noise
-        payload definition for ITU-T G.711 use in packet-based
-        multimedia communication systems.
-
-
-Terms
------
-- DTX Discontinues Transmission capability
-- VAD Voice Activity Detection
-- CN Comfort Noise 
-- CNG Comfort Noise Generator
-
-RTP Framing (RFC 3389 section 4)
---------------------------------
-The RTP header for the comfort noise packet SHOULD be constructed as
-   if the comfort noise were an independent codec.  Thus, the RTP
-   timestamp designates the beginning of the comfort noise period.
-
-At the beginning of
-   an inactive voice segment (silence period), a CN packet is
-   transmitted in the same RTP stream and indicated by the CN payload
-   type.  The CN packet update rate is left implementation specific. For
-   example, the CN packet may be sent periodically or only when there is
-   a significant change in the background noise characteristics.  The
-   CNG algorithm at the receiver uses the information in the CN payload
-   to update its noise generation model and then produce an appropriate
-   amount of comfort noise.
-
-Noise Level (RFC 3389 Section 3.1)
-----------------------------------
-The magnitude of the noise level is packed into the least significant
-   bits of the noise-level byte with the most significant bit unused and
-   always set to 0 as shown below in Figure 1.  The least significant
-   bit of the noise level magnitude is packed into the least significant
-   bit of the byte.
-
-   The noise level is expressed in -dBov, with values from 0 to 127
-   representing 0 to -127 dBov.  dBov is the level relative to the
-   overload of the system.  (Note: Representation relative to the
-   overload point of a system is particularly useful for digital
-   implementations, since one does not need to know the relative
-   calibration of the analog circuitry.)  For example, in the case of a
-   u-law system, the reference would be a square wave with values +/-
-   8031, and this square wave represents 0dBov.  This translates into
-   6.18dBm0.
-
------------------
-Various notes:
-=============
-From file:
-
-The logic for determining if a native bridge can be performed or not lives in ast_channel_bridge in channel.c - there is an if statement with many conditions that have to be met before doing it. You can extend that and add another which is "if the CN support on channel A is the same as channel B then allow native bridge"
-
-Question: If I run RTP bridge (not the p2p or remote) can we still operate
-on timer? If not, I have to disable RTP bridging totally. If we rely on incoming
-packets (which will not happen) to send out, CN will not work.
-
-Yes, you can still operate on timer. The RTP bridge still has all the normal bridging logic in it. That's how music on hold and such works.
-
-

Added: team/oej/roibus-comfort-noise-trunk/res/res_noise.c
URL: http://svnview.digium.com/svn/asterisk/team/oej/roibus-comfort-noise-trunk/res/res_noise.c?view=auto&rev=393726
==============================================================================
--- team/oej/roibus-comfort-noise-trunk/res/res_noise.c (added)
+++ team/oej/roibus-comfort-noise-trunk/res/res_noise.c Fri Jul  5 07:04:45 2013
@@ -1,0 +1,164 @@
+/*
+ * Asterisk -- An open source telephony toolkit.
+ *
+ * Copyright (C) 1999 - 2005, Digium, Inc.
+ *
+ * Contributed by Carlos Antunes <cmantunes at gmail.com>
+ *
+ * See http://www.asterisk.org for more information about
+ * the Asterisk project. Please do not directly contact
+ * any of the maintainers of this project for assistance;
+ * the project provides a web site, mailing lists and IRC
+ * channels for your use.
+ *
+ * This program is free software, distributed under the terms of
+ * the GNU General Public License Version 2. See the LICENSE file
+ * at the top of the source tree.
+ */
+
+/*! \file 
+ *
+ * \brief Just generate white noise 
+ * 
+ */
+
+/*** MODULEINFO
+	<support_level>random</support_level>
+ ***/
+
+
+#include "asterisk.h"
+
+ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
+
+#include "asterisk/lock.h"
+#include "asterisk/file.h"
+#include "asterisk/logger.h"
+#include "asterisk/channel.h"
+#include "asterisk/pbx.h"
+#include "asterisk/module.h"
+#include "asterisk/app.h"
+
+#include <math.h>
+
+static char *app = "WhiteNoise";
+
+
+/*** DOCUMENTATION
+	<application name="WhiteNoise" language="en_US">
+		<synopsis>
+			Generates white noise
+		</synopsis>
+		<syntax>
+		<parameter name="args">
+			<argument name="timeout" required="true" />
+			<argument name="level" required="false" />
+		</parameter>
+		</syntax>
+		<description>
+			<para>Generates white noise at 'level' dBov's for 'timeout' seconds or indefinitely if timeout
+			is absent or is zero.</para>
+			<para>Level is a non-positive number. For example, WhiteNoise(0.0) generates
+			white noise at full power, while WhiteNoise(-3.0) generates white noise at
+			half full power. Every -3dBov's reduces white noise power in half. Full
+			power in this case is defined as noise that overloads the channel roughly 0.3%
+			of the time. Note that values below -69 dBov's start to give out silence
+			frequently, resulting in intermittent noise, i.e, alternating periods of
+			silence and noise.</para>
+
+		</description>
+	</application>
+***/
+
+static int noise_exec(struct ast_channel *chan, const char *data) {
+
+	struct ast_module_user *u;
+	char *excessdata;
+	float level = 0;
+	float timeout = 0;
+	char *s;
+	int res;
+	struct ast_noise_generator *gendata;
+
+        AST_DECLARE_APP_ARGS(args,
+                AST_APP_ARG(timeout);
+                AST_APP_ARG(level);
+        );
+
+	/* Verify we potentially have arguments and get local copy */
+        if (!data) {
+                ast_log(LOG_WARNING, "WhiteNoise usage following: WhiteNoise([timeout[, level]])\n");
+                return -1;
+        }
+	
+	/* Separate arguments */	
+        s = ast_strdupa(data);
+        AST_STANDARD_APP_ARGS(args, s);
+
+	if (args.timeout) {	
+		/* Extract second argument, if available, and validate
+		 * timeout is non-negative. Zero timeout means no timeout */
+		args.timeout = ast_trim_blanks(args.timeout);
+		timeout = strtof(args.timeout, &excessdata);
+		if ((excessdata && *excessdata) || timeout < 0) {
+			ast_log(LOG_WARNING, "Invalid argument 'timeout': WhiteNoise requires non-negative floating-point argument for timeout in seconds\n");				
+			return -1;
+		}
+
+		/* Convert timeout to milliseconds
+		 * and ensure minimum of 20ms      */
+		timeout = roundf(timeout * 1000.0);
+		if (timeout > 0 && timeout < 20) {
+			timeout = 20;
+		}
+	} 
+
+	if (args.level) {
+		/* Extract first argument and ensure we have
+		 * a valid noise level argument value        */
+		args.level = ast_trim_blanks(args.level);
+		level = strtof(args.level, &excessdata);
+		if ((excessdata && *excessdata) || level > 0) {
+			ast_log(LOG_ERROR, "Invalid argument 'level': WhiteNoise requires non-positive floating-point argument for noise level in dBov's\n");
+			return -1;
+		}
+	} 
+
+	ast_debug(1, "Setting up white noise generator with level %.1fdBov's and %.0fms %stimeout\n", level, timeout, timeout == 0 ? "(no) " : "");
+
+	u = ast_module_user_add(chan);
+	if (ast_channel_state(chan) != AST_STATE_UP) {
+		ast_answer(chan);
+	}
+	gendata = ast_channel_start_noise_generator(chan, level);
+	if (data == NULL)	{
+		ast_log(LOG_WARNING, "Failed to activate white noise generator on '%s'\n",ast_channel_name(chan));
+		res = -1;
+	} else {
+		/* Just do the noise... */
+		res = -1;
+		if (timeout > 0) {
+			res = ast_safe_sleep(chan, timeout);
+		} else  {
+			while(!ast_safe_sleep(chan, 10000));
+		}
+		ast_channel_stop_noise_generator(chan, gendata);
+	}
+	ast_module_user_remove(u);
+	return res;
+}
+
+static int unload_module(void) {
+	ast_module_user_hangup_all();
+	
+	return ast_unregister_application(app);
+}
+
+static int load_module(void) {
+	return ast_register_application_xml(app, noise_exec);
+}
+
+AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_GLOBAL_SYMBOLS, "White Noise Generator Application",
+                .load = load_module,
+                .unload = unload_module,
+               );

Propchange: team/oej/roibus-comfort-noise-trunk/res/res_noise.c
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: team/oej/roibus-comfort-noise-trunk/res/res_noise.c
------------------------------------------------------------------------------
    svn:keywords = Author Date Id Revision

Propchange: team/oej/roibus-comfort-noise-trunk/res/res_noise.c
------------------------------------------------------------------------------
    svn:mime-type = text/plain




More information about the svn-commits mailing list