Just fyi, you can disable hw ec from the CLI so you don't have to start/stop the port for your tests. Start the card with HWEC enabled, then you can use wan_ec_client.<div><br></div><div># wan_ec_client wanpipe1 disable <chan></div>
<div><br></div><div>Then enable again:</div><div><br></div><div># wan_ec_client wanpipe1 enable <chan></div><div><br></div><div>You can verify it's enabled/disabled with </div><div><br></div><div># wan_ec_client wanpipe stats <chan><br>
<div><br></div><div><br clear="all">Moises Silva<br>Senior Software Engineer<br>Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada<br>t. 1 905 474 1990 x 128 | e. <a href="mailto:moy@sangoma.com">moy@sangoma.com</a><br>
<br><br><div class="gmail_quote">On Wed, Jun 30, 2010 at 6:29 PM, <span dir="ltr"><<a href="mailto:devel@thom.fr.eu.org">devel@thom.fr.eu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div lang="FR" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;color:#1F497D">I’ll give a try tomorrow with HWEC disabled.</span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;color:#1F497D"> </span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt">De :</span></b><span style="font-size:10.0pt">
<a href="mailto:freeswitch-dev-bounces@lists.freeswitch.org" target="_blank">freeswitch-dev-bounces@lists.freeswitch.org</a>
[mailto:<a href="mailto:freeswitch-dev-bounces@lists.freeswitch.org" target="_blank">freeswitch-dev-bounces@lists.freeswitch.org</a>] <b>De la part de</b>
Moises Silva<br>
<b>Envoyé :</b> mercredi 30 juin 2010 23:15<br>
<b>À :</b> <a href="mailto:freeswitch-dev@lists.freeswitch.org" target="_blank">freeswitch-dev@lists.freeswitch.org</a><br>
<b>Objet :</b> Re: [Freeswitch-dev] FXS bridged on FXO ports and DTMF -
Deja Vu</span></p>
</div><div><div></div><div class="h5">
<p class="MsoNormal"> </p>
<p class="MsoNormal">Can you try 3.5.12 with and without hw ec enabled and check
if cid is there?</p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br clear="all">
Moises Silva<br>
Senior Software Engineer<br>
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3
Canada<br>
t. 1 905 474 1990 x 128 | e. <a href="mailto:moy@sangoma.com" target="_blank">moy@sangoma.com</a><br>
<br>
</p>
<div>
<p class="MsoNormal">On Wed, Jun 30, 2010 at 2:58 PM, François Legal <<a href="mailto:devel@thom.fr.eu.org" target="_blank">devel@thom.fr.eu.org</a>> wrote:</p>
<p>Hello,</p>
<p> </p>
<p>did try to upgrade to wanpipe 3.5.12 (from 3.5.11) and thought the DTMF
problem seems to be fixed (did not had the opportunity to really test it
thourougthly), I seem to have lost the CID feature in the upgrade.</p>
<p>Roll back to 3.5.11 and CID is back there.</p>
<p> </p>
<p>François</p>
<div>
<p> </p>
<p> </p>
<p>On Mon, 28 Jun 2010 18:54:19 -0400, Moises Silva wrote:</p>
</div>
<blockquote style="border:none;border-left:solid #1010FF 1.5pt;padding:0cm 0cm 0cm 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hello,<br>
<br>
I spent a few hours playing with DTMF stuff and analog cards and it seems there
is 2 issues at hand.<br>
<br>
1. Bleeding DTMF.<br>
2. Echo DTMF.<br>
<br>
The first issue, for software DTMF, can be solved with Anthony's pre buffer
size feature. However that introduces delay by design, and it will not work for
large DTMFs (if the dtmf is larger than the buffer).<br>
<br>
For hardware DTMF a new driver was just released that includes a configuration
to allow the EC chip to perform the dtmf tone removal which cuts down the
bleeding to only 20ms (in my testing) there is no way a DTMF detector will
consider that a valid DTMF and therefore the bleeding should be solved with no
delay introduced. The option is HWEC_DTMF_REMOVAL = YES, must be added along
with the usual TDMV_HW_DTMF = YES in wanpipex.conf<br>
<br>
Ideally the software DTMF detector (in this case teletone) should cut it at the
same time that it detects it. I thought may be spandsp would help, but it seems
spandsp does not have an option to squelch the dtmf tone. May be Steve can help
with that. I pinged him on IRC and he said he may get some code working, but
there is no date for that and also that would involve integrating spandsp into
FreeTDM, any reason to not do this now that spandsp is LGPL?<br>
<br>
As for the echo dtmf. It seems sometimes an outgoing DTMF may be detected as
incoming DTMF due to echo. There is not much we can do there if you don't have
echo cancellation. If however you have this issue even with HW EC, call Sangoma
tech support and we will be happy to look at the issue.<br>
<br>
In another note, I added a variable and application to disable DTMF. <br>
<br>
<br>
</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">That will disable DTMF (either
software or hardware) in the leg executing that app. If you want to disable in
the outgoing leg (before a bridge), you must export a special variable:<br>
<br>
<br>
</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The DTMF is enabled
automatically on each call, so there is no need to enable it for each call. But
in case you need to enable it:<br>
<br>
<br>
</p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Moises Silva<br>
Senior Software Engineer<br>
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3
Canada<br>
t. 1 905 474 1990 x 128 | e. <a href="mailto:moy@sangoma.com" target="_blank">moy@sangoma.com</a><br>
<br>
</p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale <<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>>
wrote:</p>
<p class="MsoNormal">openzap_pre_buffer_size is a variable you can set to
specific number of MS 60 for example. </p>
<div>
<p class="MsoNormal">it will pre_buffer the audio on the channel so when you
detect dtmf it will completely drop the buffer so all of the original</p>
</div>
<div>
<p class="MsoNormal">dtmf should be dropped as well. probably if
the dtmf is too long then it will cause problems anyway.</p>
</div>
<div>
<p class="MsoNormal">if that pre buffer does not fix anything it would point to
echo or bleeding.</p>
</div>
<div>
<p class="MsoNormal">We could make a variable to disable dtmf detection
completely on a per-call basis possibly but you will still probably hear it
bleeding.</p>
</div>
<div>
<p class="MsoNormal">This type of problem was reported fixed with sangoma because
of the echo canceler.</p>
</div>
<div>
<p class="MsoNormal">I don't use dahdi or digium stuff much so I can't comment on
what happens when you use it.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On Wed, Jun 16, 2010 at 3:41 AM, François Legal <<a href="mailto:devel@thom.fr.eu.org" target="_blank">devel@thom.fr.eu.org</a>>
wrote:</p>
<p class="MsoNormal">Does this really fix it ?<br>
I wonder because the problem I see here is also that the FXS side detects<br>
the DTMF and then queues it on the FXO side for generation. That leads to<br>
the called party receiving twice the DTMF, the first one is the inband<br>
DTMF, the second is the one queued/generated by the FXO channel.<br>
<br>
For a clean fix, I guess some kind of application should be created, that<br>
would prevent DTMF to be queued on the other channel. Such application<br>
would then be called before the bridge. Maybe there is a cleaner way to do<br>
this.<br>
<span style="color:#888888"><br>
François</span></p>
<div>
<div>
<p class="MsoNormal"><br>
On Tue, 15 Jun 2010 18:23:13 -0500, "Jeroen C. van Gelderen"<br>
<<a href="mailto:jeroeng@thegreek.com" target="_blank">jeroeng@thegreek.com</a>>
wrote:<br>
> Hi everybody,<br>
><br>
> I have a problem that is very similar to a problem<br>
> reported by François [1] except for the fact that<br>
> my FXS and FXO ports are on a Xorcom Astribank<br>
> device instead of a Sangoma.<br>
><br>
> To quote François: "The problem is that each leg of<br>
> the bridge is detecting the inband DTMF, and so<br>
> [F]reeswitch sends each detected DTMF from one leg<br>
> to the other, and so on and so forth (as each leg<br>
> detects the DTMF again and again)"<br>
><br>
> HIS words but evidenced by the MY log :)<br>
><br>
> The snippet below has DTMF coming in on the FXS port<br>
> (1:1) and bouncing between it and the FXO port (3:1).<br>
> The ports are simply bridged together with<br>
><br>
> "bridge(OpenZap/3/1/F)" or
"bridge(OpenZap/3/1/w)"<br>
><br>
> I'm running:<br>
><br>
> FreeSWITCH version: 1.0.head (git-01c0c69 2010-06-08 16-22-21 -0500)<br>
> dahdi: Version: SVN-trunk-r8762<br>
><br>
> Output of lsdahdi at end of message.<br>
><br>
> ----8<----8<----8<----8<----8<----8<----8<----<br>
> [...]<br>
> 2010-06-13 04:18:39.217256 [DEBUG] mod_openzap.c:721 queue DTMF [4]<br>
> 2010-06-13 04:18:39.256255 [DEBUG] zap_io.c:2062 3:1 GENERATE DTMF [4]<br>
> 2010-06-13 04:18:39.397253 [DEBUG] mod_openzap.c:721 queue DTMF [4]<br>
> 2010-06-13 04:18:39.439252 [DEBUG] mod_openzap.c:780 Dropping frame!<br>
(write<br>
> not ready)<br>
> 2010-06-13 04:18:39.439252 [DEBUG] zap_io.c:2062 1:1 GENERATE DTMF [4]<br>
> 2010-06-13 04:18:39.637249 [DEBUG] mod_openzap.c:721 queue DTMF [4]<br>
> 2010-06-13 04:18:39.676248 [DEBUG] zap_io.c:2062 3:1 GENERATE DTMF [4]<br>
> 2010-06-13 04:18:39.859244 [DEBUG] mod_openzap.c:780 Dropping frame!<br>
(write<br>
> not ready)<br>
> [...ad infinitum...]<br>
> ----8<----8<----8<----8<----8<----8<----8<----<br>
><br>
> Because I needed DTMF pass-through working "now"<br>
> I applied an ugly HACK. This drops DTMF tones<br>
> detected on spans 3 and 4 (which are my FXO<br>
> spans). This is very WRONG but it does solve<br>
> my immediate problem:<br>
><br>
> ----8<----8<----8<----8<----8<----8<----8<----<br>
> diff --git a/libs/openzap/mod_openzap/mod_openzap.c<br>
> b/libs/openzap/mod_openzap/mod_openzap.c<br>
> index 5aebfea..ff3b081 100644<br>
> --- a/libs/openzap/mod_openzap/mod_openzap.c<br>
> +++ b/libs/openzap/mod_openzap/mod_openzap.c<br>
> @@ -718,8 +718,12 @@ static switch_status_t<br>
> channel_read_frame(switch_core_session_t *session, switch<br>
> for (p = dtmf; p
&& *p; p++) {<br>
>
if (is_dtmf(*p)) {<br>
>
_dtmf.digit = *p;<br>
> -
zap_log(ZAP_LOG_DEBUG, "queue DTMF<br>
[%c]\n",<br>
> *p);<br>
> -
switch_channel_queue_dtmf(channel,<br>
&_dtmf);<br>
> +
if (tech_pvt->zchan->span_id == 3 ||<br>
> tech_pvt->zchan->span_id == 4) {<br>
> +
zap_log(ZAP_LOG_DEBUG, "Ignoring<br>
> DTMF [%c] on FXO port %d:%d\n", *p, tech_pvt->zchan->span_id,<br>
> tech_pvt->zchan->chan_id)<br>
> ;<br>
> +
} else {<br>
> +
zap_log(ZAP_LOG_DEBUG, "queue<br>
DTMF<br>
> [%c]\n", *p);<br>
> +<br>
switch_channel_queue_dtmf(channel,<br>
> &_dtmf);<br>
> +
}<br>
>
}<br>
> }<br>
> }<br>
> ----8<----8<----8<----8<----8<----8<----8<----<br>
><br>
> Can someone point me in the "right" direction<br>
> instead? Do I need to do this at the OpenZAP/DAHDI<br>
> level by disabling some kind of DTMF detection<br>
> like was done for the Sangoma driver?<br>
><br>
> Any and all pointers appreciated.<br>
><br>
> Cheers,<br>
> -Slim<br>
><br>
> [1] [Freeswitch-dev] FXS bridged on FXO ports and DTMF<br>
><br>
<a href="http://www.mail-archive.com/freeswitch-dev@lists.freeswitch.org/msg02830.htm" target="_blank">http://www.mail-archive.com/freeswitch-dev@lists.freeswitch.org/msg02830.htm</a><br>
> l<br>
><br>
> [Freeswitch-dev] Problem with sending<br>
> DTMF on FXS port bridged to an FXO port<br>
><br>
<a href="http://lists.freeswitch.org/pipermail/freeswitch-dev/2010-April/003607.html" target="_blank">http://lists.freeswitch.org/pipermail/freeswitch-dev/2010-April/003607.html</a><br>
><br>
><br>
> ----8<----8<----8<----8<----8<----8<----8<----<br>
> [root@localhost freeswitch]# lsdahdi<br>
> ### Span 1: XBUS-00/XPD-00 "Xorcom XPD #00/00: FXS"
(MASTER)<br>
> 1 FXS FXOKS<br>
> 2 FXS FXOKS<br>
> 3 FXS FXOKS<br>
> 4 FXS FXOKS<br>
> 5 FXS FXOKS<br>
> 6 FXS FXOKS<br>
> 7 FXS FXOKS<br>
> 8 FXS FXOKS<br>
> 9 Output FXOKS<br>
> 10 Output FXOKS<br>
> 11 Input FXOKS<br>
> 12 Input FXOKS<br>
> 13 Input FXOKS<br>
> 14 Input FXOKS<br>
> ### Span 2: XBUS-00/XPD-10 "Xorcom XPD #00/10: FXS"<br>
> 15 FXS FXOKS<br>
> 16 FXS FXOKS<br>
> 17 FXS FXOKS<br>
> 18 FXS FXOKS<br>
> 19 FXS FXOKS<br>
> 20 FXS FXOKS<br>
> 21 FXS FXOKS<br>
> 22 FXS FXOKS<br>
> ### Span 3: XBUS-00/XPD-20 "Xorcom XPD #00/20: FXO"<br>
> 23 FXO FXSKS
RED<br>
> 24 FXO FXSKS
RED<br>
> 25 FXO FXSKS
RED<br>
> 26 FXO FXSKS
RED<br>
> 27 FXO FXSKS
RED<br>
> 28 FXO FXSKS
RED<br>
> 29 FXO FXSKS
RED<br>
> 30 FXO FXSKS
RED<br>
> ### Span 4: XBUS-00/XPD-30 "Xorcom XPD #00/30: FXO"<br>
> 31 FXO FXSKS
RED<br>
> 32 FXO FXSKS
RED<br>
> 33 FXO FXSKS
RED<br>
> 34 FXO FXSKS
RED<br>
> 35 FXO FXSKS
RED<br>
> 36 FXO FXSKS
RED<br>
> 37 FXO FXSKS
RED<br>
> 38 FXO FXSKS
RED<br>
> ----8<----8<----8<----8<----8<----8<----8<----<br>
><br>
><br>
> Cheers,<br>
> -Slim<br>
> --<br>
> Jeroen C. "Slim" van Gelderen<br>
> Olympic Sports Data Services<br>
> Email: <a href="mailto:jeroeng@thegreek.com" target="_blank">jeroeng@thegreek.com</a><br>
> Phone: +1 876 953 6182 x128<br>
><br>
><br>
><br>
> _______________________________________________<br>
> FreeSWITCH-dev mailing list<br>
> <a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
</p>
</div>
</div>
<p class="MsoNormal">-- <br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a>
#freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900</p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a></p>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org" target="_blank">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a></p>
</div>
<p class="MsoNormal"> </p>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div></div>