[Freeswitch-dev] FXS bridged on FXO ports and DTMF - Deja Vu

François Legal devel at thom.fr.eu.org
Wed Jun 16 01:41:44 PDT 2010


Does this really fix it ?
I wonder because the problem I see here is also that the FXS side detects
the DTMF and then queues it on the FXO side for generation. That leads to
the called party receiving twice the DTMF, the first one is the inband
DTMF, the second is the one queued/generated by the FXO channel.

For a clean fix, I guess some kind of application should be created, that
would prevent DTMF to be queued on the other channel. Such application
would then be called before the bridge. Maybe there is a cleaner way to do
this.

François

On Tue, 15 Jun 2010 18:23:13 -0500, "Jeroen C. van Gelderen"
<jeroeng at thegreek.com> wrote:
> Hi everybody,
> 
> I have a problem that is very similar to a problem 
> reported by François [1] except for the fact that 
> my FXS and FXO ports are on a Xorcom Astribank 
> device instead of a Sangoma.
> 
> To quote François: "The problem is that each leg of 
> the bridge is detecting the inband DTMF, and so 
> [F]reeswitch sends each detected DTMF from one leg 
> to the other, and so on and so forth (as each leg 
> detects the DTMF again and again)"
> 
> HIS words but evidenced by the MY log :)
> 
> The snippet below has DTMF coming in on the FXS port 
> (1:1) and bouncing between it and the FXO port (3:1). 
> The ports are simply bridged together with
> 
>   "bridge(OpenZap/3/1/F)" or "bridge(OpenZap/3/1/w)"
> 
> I'm running:
> 
> FreeSWITCH version: 1.0.head (git-01c0c69 2010-06-08 16-22-21 -0500)
> dahdi: Version: SVN-trunk-r8762
> 
> Output of lsdahdi at end of message.
> 
> ----8<----8<----8<----8<----8<----8<----8<----
> [...]
> 2010-06-13 04:18:39.217256 [DEBUG] mod_openzap.c:721 queue DTMF [4]
> 2010-06-13 04:18:39.256255 [DEBUG] zap_io.c:2062 3:1 GENERATE DTMF [4]
> 2010-06-13 04:18:39.397253 [DEBUG] mod_openzap.c:721 queue DTMF [4]
> 2010-06-13 04:18:39.439252 [DEBUG] mod_openzap.c:780 Dropping frame!
(write
> not ready)
> 2010-06-13 04:18:39.439252 [DEBUG] zap_io.c:2062 1:1 GENERATE DTMF [4]
> 2010-06-13 04:18:39.637249 [DEBUG] mod_openzap.c:721 queue DTMF [4]
> 2010-06-13 04:18:39.676248 [DEBUG] zap_io.c:2062 3:1 GENERATE DTMF [4]
> 2010-06-13 04:18:39.859244 [DEBUG] mod_openzap.c:780 Dropping frame!
(write
> not ready)
> [...ad infinitum...]
> ----8<----8<----8<----8<----8<----8<----8<----
> 
> Because I needed DTMF pass-through working "now" 
> I applied an ugly HACK. This drops DTMF tones 
> detected on spans 3 and 4 (which are my FXO 
> spans). This is very WRONG but it does solve 
> my immediate problem:
> 
> ----8<----8<----8<----8<----8<----8<----8<----
> diff --git a/libs/openzap/mod_openzap/mod_openzap.c
> b/libs/openzap/mod_openzap/mod_openzap.c
> index 5aebfea..ff3b081 100644
> --- a/libs/openzap/mod_openzap/mod_openzap.c
> +++ b/libs/openzap/mod_openzap/mod_openzap.c
> @@ -718,8 +718,12 @@ static switch_status_t
> channel_read_frame(switch_core_session_t *session, switch
>                 for (p = dtmf; p && *p; p++) {
>                         if (is_dtmf(*p)) {
>                                 _dtmf.digit = *p;
> -                               zap_log(ZAP_LOG_DEBUG, "queue DTMF
[%c]\n",
> *p);
> -                               switch_channel_queue_dtmf(channel,
&_dtmf);
> +                               if (tech_pvt->zchan->span_id == 3 ||
> tech_pvt->zchan->span_id == 4) {
> +                                       zap_log(ZAP_LOG_DEBUG, "Ignoring
> DTMF [%c] on FXO port %d:%d\n", *p, tech_pvt->zchan->span_id,
> tech_pvt->zchan->chan_id)
> ;
> +                               } else {
> +                                       zap_log(ZAP_LOG_DEBUG, "queue
DTMF
> [%c]\n", *p);
> +                                      
switch_channel_queue_dtmf(channel,
> &_dtmf);
> +                               }
>                         }
>                 }
>         }
> ----8<----8<----8<----8<----8<----8<----8<----
> 
> Can someone point me in the "right" direction 
> instead? Do I need to do this at the OpenZAP/DAHDI 
> level by disabling some kind of DTMF detection 
> like was done for the Sangoma driver?
> 
> Any and all pointers appreciated.
> 
> Cheers,
> -Slim
> 
> [1] [Freeswitch-dev] FXS bridged on FXO ports and DTMF
>
http://www.mail-archive.com/freeswitch-dev@lists.freeswitch.org/msg02830.htm
> l
> 
> [Freeswitch-dev] Problem with sending 
> DTMF on FXS port bridged to	an FXO port
>
http://lists.freeswitch.org/pipermail/freeswitch-dev/2010-April/003607.html
> 
> 
> ----8<----8<----8<----8<----8<----8<----8<----
> [root at localhost freeswitch]# lsdahdi
> ### Span  1: XBUS-00/XPD-00 "Xorcom XPD #00/00: FXS" (MASTER)
>   1 FXS        FXOKS
>   2 FXS        FXOKS
>   3 FXS        FXOKS
>   4 FXS        FXOKS
>   5 FXS        FXOKS
>   6 FXS        FXOKS
>   7 FXS        FXOKS
>   8 FXS        FXOKS
>   9 Output     FXOKS
>  10 Output     FXOKS
>  11 Input      FXOKS
>  12 Input      FXOKS
>  13 Input      FXOKS
>  14 Input      FXOKS
> ### Span  2: XBUS-00/XPD-10 "Xorcom XPD #00/10: FXS"
>  15 FXS        FXOKS
>  16 FXS        FXOKS
>  17 FXS        FXOKS
>  18 FXS        FXOKS
>  19 FXS        FXOKS
>  20 FXS        FXOKS
>  21 FXS        FXOKS
>  22 FXS        FXOKS
> ### Span  3: XBUS-00/XPD-20 "Xorcom XPD #00/20: FXO"
>  23 FXO        FXSKS        RED
>  24 FXO        FXSKS        RED
>  25 FXO        FXSKS        RED
>  26 FXO        FXSKS        RED
>  27 FXO        FXSKS        RED
>  28 FXO        FXSKS        RED
>  29 FXO        FXSKS        RED
>  30 FXO        FXSKS        RED
> ### Span  4: XBUS-00/XPD-30 "Xorcom XPD #00/30: FXO"
>  31 FXO        FXSKS        RED
>  32 FXO        FXSKS        RED
>  33 FXO        FXSKS        RED
>  34 FXO        FXSKS        RED
>  35 FXO        FXSKS        RED
>  36 FXO        FXSKS        RED
>  37 FXO        FXSKS        RED
>  38 FXO        FXSKS        RED
> ----8<----8<----8<----8<----8<----8<----8<----
> 
> 
> Cheers,
> -Slim
> --
> Jeroen C. "Slim" van Gelderen
> Olympic Sports Data Services
> Email: jeroeng at thegreek.com
> Phone: +1 876 953 6182 x128
> 
> 
> 
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org



More information about the FreeSWITCH-dev mailing list