[Freeswitch-dev] FXS bridged on FXO ports and DTMF - Deja Vu
Moises Silva
moises.silva at gmail.com
Wed Jun 30 15:48:40 PDT 2010
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.
# wan_ec_client wanpipe1 disable <chan>
Then enable again:
# wan_ec_client wanpipe1 enable <chan>
You can verify it's enabled/disabled with
# wan_ec_client wanpipe stats <chan>
Moises Silva
Senior Software Engineer
Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3
Canada
t. 1 905 474 1990 x 128 | e. moy at sangoma.com
On Wed, Jun 30, 2010 at 6:29 PM, <devel at thom.fr.eu.org> wrote:
> I’ll give a try tomorrow with HWEC disabled.
>
>
>
> *De :* freeswitch-dev-bounces at lists.freeswitch.org [mailto:
> freeswitch-dev-bounces at lists.freeswitch.org] *De la part de* Moises Silva
> *Envoyé :* mercredi 30 juin 2010 23:15
> *À :* freeswitch-dev at lists.freeswitch.org
> *Objet :* Re: [Freeswitch-dev] FXS bridged on FXO ports and DTMF - Deja Vu
>
>
>
> Can you try 3.5.12 with and without hw ec enabled and check if cid is
> there?
>
>
> Moises Silva
> Senior Software Engineer
> Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R
> 9T3 Canada
> t. 1 905 474 1990 x 128 | e. moy at sangoma.com
>
> On Wed, Jun 30, 2010 at 2:58 PM, François Legal <devel at thom.fr.eu.org>
> wrote:
>
> Hello,
>
>
>
> 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.
>
> Roll back to 3.5.11 and CID is back there.
>
>
>
> François
>
>
>
>
>
> On Mon, 28 Jun 2010 18:54:19 -0400, Moises Silva wrote:
>
> Hello,
>
> I spent a few hours playing with DTMF stuff and analog cards and it seems
> there is 2 issues at hand.
>
> 1. Bleeding DTMF.
> 2. Echo DTMF.
>
> 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).
>
> 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
>
> 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?
>
> 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.
>
> In another note, I added a variable and application to disable DTMF.
>
>
> 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:
>
>
> 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:
>
>
> Moises Silva
> Senior Software Engineer
> Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R
> 9T3 Canada
> t. 1 905 474 1990 x 128 | e. moy at sangoma.com
>
> On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale <
> anthony.minessale at gmail.com> wrote:
>
> openzap_pre_buffer_size is a variable you can set to specific number of MS
> 60 for example.
>
> 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
>
> dtmf should be dropped as well. probably if the dtmf is too long then it
> will cause problems anyway.
>
> if that pre buffer does not fix anything it would point to echo or
> bleeding.
>
> We could make a variable to disable dtmf detection completely on a per-call
> basis possibly but you will still probably hear it bleeding.
>
> This type of problem was reported fixed with sangoma because of the
> echo canceler.
>
> I don't use dahdi or digium stuff much so I can't comment on what happens
> when you use it.
>
>
>
>
>
> On Wed, Jun 16, 2010 at 3:41 AM, François Legal <devel at thom.fr.eu.org>
> wrote:
>
> 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
>
> _______________________________________________
> 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
>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:+19193869900
>
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100630/48d5ec63/attachment-0001.html
More information about the FreeSWITCH-dev
mailing list