[Freeswitch-dev] FXS bridged on FXO ports and DTMF - Deja Vu
Moises Silva
moises.silva at gmail.com
Tue Jul 13 12:09:00 PDT 2010
So, you basically found that CID gets broken with DTMF REMOVAL ?
HW_DTMF_REMOVAL=YES, CID does not work
HW_DTMF_REMOVAL=NO or not set, CID works
is this correct?
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 Tue, Jul 13, 2010 at 2:35 PM, François Legal <devel at thom.fr.eu.org>wrote:
> I don't know, maybe I was mistaken last time I tried, but here it is. I did
> update to 3.5.14 and try again.
>
> CID is OK when HWEC_DTMF_REMOVAL = YES is not set in wanpipex.conf.
> Otherwise it works (therefore, I didn't tried the speech recognition mode).
>
>
>
> François
>
>
>
> On Thu, 1 Jul 2010 17:38:22 -0400, Moises Silva <moises.silva at gmail.com>
> wrote:
>
> Hi,
> You can try the EC in speech recognition mode.
> By default, the ec is in normal mode. But you can set it to speech
> recognition mode with this:
> # wan_ec_client wanpipe1 msr
> msr = mode speech recognition
> Then verify the channel has the required mode:
> # wan_ec_client wanpipe1 stats
> You can take it back to normal mode (IIRC) with:
> # wan_ec_client wanpipe1 mn
> In any case I am interested in your problem with the ec in normal mode. I
> need to check with the driver developer to see if something changed in the
> ec settings.
> Please let me know if speech recognition mode helps.
>
> 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 Thu, Jul 1, 2010 at 1:46 PM, François Legal <devel at thom.fr.eu.org>wrote:
>
>> Yes, CID works back again with HWEC disabled. However, I get echo without
>> HWEC ;-)
>>
>>
>>
>> François
>>
>>
>>
>> On Wed, 30 Jun 2010 18:48:40 -0400, Moises Silva <moises.silva at gmail.com>
>> wrote:
>>
>> 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
>> Then enable again:
>> # wan_ec_client wanpipe1 enable
>> You can verify it's enabled/disabled with
>> # wan_ec_client wanpipe stats
>>
>> 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
>>>
>>>
>> _______________________________________________
>> 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/20100713/b9ff9e0f/attachment-0001.html
More information about the FreeSWITCH-dev
mailing list