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

Wed Jun 30 11:58:53 PDT 2010

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

 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
[5]
 > 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
[6]
 >
 >
 > ----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 [7]
 > Phone:
+1 876 953 6182 x128
 >
 >
 >
 >
_______________________________________________
 > FreeSWITCH-dev mailing
list
 > FreeSWITCH-dev at lists.freeswitch.org [8]
 >
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [9]
 >
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[10]
 > http://www.freeswitch.org [11]

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

UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
[14]
http://www.freeswitch.org [15]    

  -- 
Anthony Minessale
II

FreeSWITCH http://www.freeswitch.org/ [16]
ClueCon
http://www.cluecon.com/ [17]
 Twitter: http://twitter.com/FreeSWITCH_wire
[18]

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

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

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

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

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

Links:
------
[1]
mailto:moy at sangoma.com
[2] mailto:anthony.minessale at gmail.com
[3]
mailto:devel at thom.fr.eu.org
[4] mailto:jeroeng at thegreek.com
[5]
http://www.mail-archive.com/freeswitch-dev@lists.freeswitch.org/msg02830.htm
[6]
http://lists.freeswitch.org/pipermail/freeswitch-dev/2010-April/003607.html
[7]
mailto:jeroeng at thegreek.com
[8]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[9]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[10]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[11]
http://www.freeswitch.org
[12]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[13]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[14]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[15]
http://www.freeswitch.org
[16] http://www.freeswitch.org/
[17]
http://www.cluecon.com/
[18] http://twitter.com/FreeSWITCH_wire
[19]
mailto:MSN%3Aanthony_minessale at hotmail.com
[20]
mailto:PAYPAL%3Aanthony.minessale at gmail.com
[21]
http://irc.freenode.net
[22]
mailto:sip%3A888 at conference.freeswitch.org
[23]
mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org
[24]
mailto:FreeSWITCH-dev at lists.freeswitch.org
[25]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
[26]
http://lists.freeswitch.org/mailman/options/freeswitch-dev
[27]
http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100630/b4d61334/attachment-0001.html 