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

Tue Jul 13 13:23:20 PDT 2010

Correct. 

François 

On Tue, 13 Jul 2010 15:09:00 -0400, Moises Silva 
wrote:  

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 [1]

 On Tue, Jul 13,
2010 at 2:35 PM, François Legal  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  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 [4]

 On Thu, Jul 1, 2010 at 1:46 PM, François Legal 
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  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 [7]

 On Wed, Jun 30, 2010 at 6:29 PM,  wrote:

I'll give a
try tomorrow with HWEC disabled. 

DE :
freeswitch-dev-bounces at lists.freeswitch.org [9]
[mailto:freeswitch-dev-bounces at lists.freeswitch.org [10]] DE LA PART DE
Moises Silva
ENVOYÉ : mercredi 30 juin 2010 23:15
À :
freeswitch-dev at lists.freeswitch.org [11]
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 [12]

On Wed, Jun 30, 2010 at 2:58 PM, François Legal 
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 [14]

On Wed, Jun 16, 2010 at 12:09 PM, Anthony
Minessale  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 
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"
  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 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 channel_read_frame(switch_core_session_t
*session, switch
 > for (p = dtmf; p & p++) {
 > if (is_dtmf(*p)) {
 >
_dtmf.digit = *p;
 > - zap_log(ZAP_LOG_DEBUG, "queue DTMF
 [%c]n",
 > *p);

> - switch_channel_queue_dtmf(channel,

 > + 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:%dn", *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,
 > 

> + }
 > }
 > }
 > }
 > ----8 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
[18]
 > 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
[19]
 >
 >
 > ----8 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
Olympic Sports Data Services
 > Email: jeroeng at thegreek.com [20]
 > Phone:
+1 876 953 6182 x128
 >
 >
 >
 >
_______________________________________________
 > FreeSWITCH-dev mailing
list
 > FreeSWITCH-dev at lists.freeswitch.org [21]
 >
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [22]
 >
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[23]
 > http://www.freeswitch.org [24]

_______________________________________________
 FreeSWITCH-dev mailing
list
FreeSWITCH-dev at lists.freeswitch.org
[25]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [26]

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[27]
http://www.freeswitch.org [28]    

-- 
 Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/ [29]
 ClueCon http://www.cluecon.com/
[30]
 Twitter: http://twitter.com/FreeSWITCH_wire [31]

 AIM:
anthm
MSN:anthony_minessale at hotmail.com [32]

GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com [33]
 IRC: irc.freenode.net
[34] #freeswitch

 FreeSWITCH Developer
Conference
sip:888 at conference.freeswitch.org
[35]
googletalk:conf+888 at conference.freeswitch.org [36]
 pstn:+19193869900 

 _______________________________________________
 FreeSWITCH-dev mailing
list
FreeSWITCH-dev at lists.freeswitch.org
[37]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [38]

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[39]
http://www.freeswitch.org [40]  

_______________________________________________
 FreeSWITCH-dev mailing
list
FreeSWITCH-dev at lists.freeswitch.org
[41]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [42]

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[43]
http://www.freeswitch.org [44] 

_______________________________________________
 FreeSWITCH-dev mailing
list
FreeSWITCH-dev at lists.freeswitch.org
[45]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [46]

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[47]
http://www.freeswitch.org
[48]

_______________________________________________
 FreeSWITCH-dev
mailing list
FreeSWITCH-dev at lists.freeswitch.org
[49]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [50]

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[51]
http://www.freeswitch.org
[52]

_______________________________________________
 FreeSWITCH-dev
mailing list
FreeSWITCH-dev at lists.freeswitch.org
[53]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [54]

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[55]
http://www.freeswitch.org [56]

Links:
------
[1]
mailto:moy at sangoma.com
[2] mailto:devel at thom.fr.eu.org
[3]
mailto:moises.silva at gmail.com
[4] mailto:moy at sangoma.com
[5]
mailto:devel at thom.fr.eu.org
[6] mailto:moises.silva at gmail.com
[7]
mailto:moy at sangoma.com
[8] mailto:devel at thom.fr.eu.org
[9]
mailto:freeswitch-dev-bounces at lists.freeswitch.org
[10]
mailto:freeswitch-dev-bounces at lists.freeswitch.org
[11]
mailto:freeswitch-dev at lists.freeswitch.org
[12] mailto:moy at sangoma.com
[13]
mailto:devel at thom.fr.eu.org
[14] mailto:moy at sangoma.com
[15]
mailto:anthony.minessale at gmail.com
[16] mailto:devel at thom.fr.eu.org
[17]
mailto:jeroeng at thegreek.com
[18]
http://www.mail-archive.com/freeswitch-dev@lists.freeswitch.org/msg02830.htm
[19]
http://lists.freeswitch.org/pipermail/freeswitch-dev/2010-April/003607.html
[20]
mailto:jeroeng at thegreek.com
[21]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[22]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[23]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[24]
http://www.freeswitch.org
[25]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[26]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[27]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[28]
http://www.freeswitch.org
[29] http://www.freeswitch.org/
[30]
http://www.cluecon.com/
[31] http://twitter.com/FreeSWITCH_wire
[32]
mailto:MSN%3Aanthony_minessale at hotmail.com
[33]
mailto:PAYPAL%3Aanthony.minessale at gmail.com
[34]
http://irc.freenode.net
[35]
mailto:sip%3A888 at conference.freeswitch.org
[36]
mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org
[37]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[38]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[39]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[40]
http://www.freeswitch.org
[41]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[42]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[43]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[44]
http://www.freeswitch.org
[45]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[46]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[47]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[48]
http://www.freeswitch.org
[49]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[50]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[51]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[52]
http://www.freeswitch.org
[53]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[54]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[55]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[56]
http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100713/b52a71f7/attachment-0001.html 