openzap_pre_buffer_size is a variable you can set to specific number of MS 60 for example.<div>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</div>
<div>dtmf should be dropped as well. probably if the dtmf is too long then it will cause problems anyway.</div><div><br></div><div>if that pre buffer does not fix anything it would point to echo or bleeding.</div><div><br>
</div><div>We could make a variable to disable dtmf detection completely on a per-call basis possibly but you will still probably hear it bleeding.</div><div><br></div><div>This type of problem was reported fixed with sangoma because of the echo canceler.</div>
<div>I don't use dahdi or digium stuff much so I can't comment on what happens when you use it.</div><div> </div><div> <br><br><div class="gmail_quote">On Wed, Jun 16, 2010 at 3:41 AM, François Legal <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;">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>
<font color="#888888"><br>
François<br>
</font><div><div></div><div class="h5"><br>
On Tue, 15 Jun 2010 18:23:13 -0500, "Jeroen C. van Gelderen"<br>
<<a href="mailto:jeroeng@thegreek.com">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">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">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">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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire">http://twitter.com/FreeSWITCH_wire</a><br><br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
</div>