[Freeswitch-dev] FXS bridged on FXO ports and DTMF - Deja Vu
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@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@thegreek.com Phone: +1 876 953 6182 x128
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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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@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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
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. <action application="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: <action application="export" data="freetdm_disable_dtmf=yes"/> 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: <action application="enable_dtmf"/> 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@sangoma.com On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale < anthony.minessale@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@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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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@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@thegreek.com [7] Phone: +1 876 953 6182 x128
_______________________________________________
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [8]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [9]
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [10]
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@hotmail.com [19] GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com [20] IRC: irc.freenode.net [21] #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org [22] googletalk:conf+888@conference.freeswitch.org [23] pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@sangoma.com [2] mailto:anthony.minessale@gmail.com [3] mailto:devel@thom.fr.eu.org [4] mailto:jeroeng@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@thegreek.com [8] mailto:FreeSWITCH-dev@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@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@hotmail.com [20] mailto:PAYPAL%3Aanthony.minessale@gmail.com [21] http://irc.freenode.net [22] mailto:sip%3A888@conference.freeswitch.org [23] mailto:googletalk%3Aconf%2B888@conference.freeswitch.org [24] mailto:FreeSWITCH-dev@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
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@sangoma.com On Wed, Jun 30, 2010 at 2:58 PM, François Legal <devel@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@sangoma.com
On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale < anthony.minessale@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@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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
I’ll give a try tomorrow with HWEC disabled. De : freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] De la part de Moises Silva Envoyé : mercredi 30 juin 2010 23:15 À : freeswitch-dev@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@sangoma.com On Wed, Jun 30, 2010 at 2:58 PM, François Legal <devel@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@sangoma.com On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale <anthony.minessale@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@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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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@sangoma.com On Wed, Jun 30, 2010 at 6:29 PM, <devel@thom.fr.eu.org> wrote:
I’ll give a try tomorrow with HWEC disabled.
*De :* freeswitch-dev-bounces@lists.freeswitch.org [mailto: freeswitch-dev-bounces@lists.freeswitch.org] *De la part de* Moises Silva *Envoyé :* mercredi 30 juin 2010 23:15 *À :* freeswitch-dev@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@sangoma.com
On Wed, Jun 30, 2010 at 2:58 PM, François Legal <devel@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@sangoma.com
On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale < anthony.minessale@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@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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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@sangoma.com [1] On Wed, Jun 30, 2010 at 6:29 PM, wrote: I'll give a try tomorrow with HWEC disabled. DE : freeswitch-dev-bounces@lists.freeswitch.org [3] [mailto:freeswitch-dev-bounces@lists.freeswitch.org [4]] DE LA PART DE Moises Silva ENVOYÉ : mercredi 30 juin 2010 23:15 À : freeswitch-dev@lists.freeswitch.org [5] 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@sangoma.com [6] 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@sangoma.com [8] 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 [12]
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 [13]
----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@thegreek.com [14] Phone: +1 876 953 6182 x128
_______________________________________________
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [15]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [16]
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [17]
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [19] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [20] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [21] http://www.freeswitch.org [22] -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ [23] ClueCon http://www.cluecon.com/ [24] Twitter: http://twitter.com/FreeSWITCH_wire [25] AIM: anthm MSN:anthony_minessale@hotmail.com [26] GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com [27] IRC: irc.freenode.net [28] #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org [29] googletalk:conf+888@conference.freeswitch.org [30] pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [31] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [32] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [33] http://www.freeswitch.org [34] _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [35] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [36] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [37] http://www.freeswitch.org [38] _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [39] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [40] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [41] http://www.freeswitch.org [42] Links: ------ [1] mailto:moy@sangoma.com [2] mailto:devel@thom.fr.eu.org [3] mailto:freeswitch-dev-bounces@lists.freeswitch.org [4] mailto:freeswitch-dev-bounces@lists.freeswitch.org [5] mailto:freeswitch-dev@lists.freeswitch.org [6] mailto:moy@sangoma.com [7] mailto:devel@thom.fr.eu.org [8] mailto:moy@sangoma.com [9] mailto:anthony.minessale@gmail.com [10] mailto:devel@thom.fr.eu.org [11] mailto:jeroeng@thegreek.com [12] http://www.mail-archive.com/freeswitch-dev@lists.freeswitch.org/msg02830.htm [13] http://lists.freeswitch.org/pipermail/freeswitch-dev/2010-April/003607.html [14] mailto:jeroeng@thegreek.com [15] mailto:FreeSWITCH-dev@lists.freeswitch.org [16] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [17] http://lists.freeswitch.org/mailman/options/freeswitch-dev [18] http://www.freeswitch.org [19] mailto:FreeSWITCH-dev@lists.freeswitch.org [20] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [21] http://lists.freeswitch.org/mailman/options/freeswitch-dev [22] http://www.freeswitch.org [23] http://www.freeswitch.org/ [24] http://www.cluecon.com/ [25] http://twitter.com/FreeSWITCH_wire [26] mailto:MSN%3Aanthony_minessale@hotmail.com [27] mailto:PAYPAL%3Aanthony.minessale@gmail.com [28] http://irc.freenode.net [29] mailto:sip%3A888@conference.freeswitch.org [30] mailto:googletalk%3Aconf%2B888@conference.freeswitch.org [31] mailto:FreeSWITCH-dev@lists.freeswitch.org [32] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [33] http://lists.freeswitch.org/mailman/options/freeswitch-dev [34] http://www.freeswitch.org [35] mailto:FreeSWITCH-dev@lists.freeswitch.org [36] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [37] http://lists.freeswitch.org/mailman/options/freeswitch-dev [38] http://www.freeswitch.org [39] mailto:FreeSWITCH-dev@lists.freeswitch.org [40] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [41] http://lists.freeswitch.org/mailman/options/freeswitch-dev [42] http://www.freeswitch.org
Hello I'm trying to use bridge using Lua at the same way like diaplan call from, (http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_bridge#Calling_multiple...); but when is executed only doing the first one, and not implementing the "failover" using pipe "|" This is the sentence session:execute("bridge", " {ignore_early_media=true,originate_timeout=8,origination_caller_id_name='Arturo monroy',origination_caller_id_number='1001',hangup_after_bridge=true,api_on_answer='',execute_on_answer=''}sofia/internal/189@192.168.1.16|{ignore_early_media=true,originate_timeout=15,origination_caller_id_name='1001',origination_caller_id_number='1001',hangup_after_bridge=false,api_on_answer='',execute_on_answer=''}sofia/internal/185@192.168.1.203") Saludos Arturo Monroy
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 <channel> msr = mode speech recognition Then verify the channel has the required mode: # wan_ec_client wanpipe1 stats <channel> You can take it back to normal mode (IIRC) with: # wan_ec_client wanpipe1 mn <channel> 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@sangoma.com On Thu, Jul 1, 2010 at 1:46 PM, François Legal <devel@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@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@sangoma.com
On Wed, Jun 30, 2010 at 6:29 PM, <devel@thom.fr.eu.org> wrote:
I’ll give a try tomorrow with HWEC disabled.
*De :* freeswitch-dev-bounces@lists.freeswitch.org [mailto: freeswitch-dev-bounces@lists.freeswitch.org] *De la part de* Moises Silva *Envoyé :* mercredi 30 juin 2010 23:15 *À :* freeswitch-dev@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@sangoma.com
On Wed, Jun 30, 2010 at 2:58 PM, François Legal <devel@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@sangoma.com
On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale < anthony.minessale@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@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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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@sangoma.com [1] 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@sangoma.com [4] On Wed, Jun 30, 2010 at 6:29 PM, wrote: I'll give a try tomorrow with HWEC disabled. DE : freeswitch-dev-bounces@lists.freeswitch.org [6] [mailto:freeswitch-dev-bounces@lists.freeswitch.org [7]] DE LA PART DE Moises Silva ENVOYÉ : mercredi 30 juin 2010 23:15 À : freeswitch-dev@lists.freeswitch.org [8] 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@sangoma.com [9] 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@sangoma.com [11] 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 [15]
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 [16]
----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@thegreek.com [17] Phone: +1 876 953 6182 x128
_______________________________________________
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [18]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [19]
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [20]
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [22] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [23] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [24] http://www.freeswitch.org [25] -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ [26] ClueCon http://www.cluecon.com/ [27] Twitter: http://twitter.com/FreeSWITCH_wire [28] AIM: anthm MSN:anthony_minessale@hotmail.com [29] GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com [30] IRC: irc.freenode.net [31] #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org [32] googletalk:conf+888@conference.freeswitch.org [33] pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [34] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [35] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [36] http://www.freeswitch.org [37] _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [38] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [39] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [40] http://www.freeswitch.org [41] _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [42] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [43] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [44] http://www.freeswitch.org [45] _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [46] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [47] UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [48] http://www.freeswitch.org [49] Links: ------ [1] mailto:moy@sangoma.com [2] mailto:devel@thom.fr.eu.org [3] mailto:moises.silva@gmail.com [4] mailto:moy@sangoma.com [5] mailto:devel@thom.fr.eu.org [6] mailto:freeswitch-dev-bounces@lists.freeswitch.org [7] mailto:freeswitch-dev-bounces@lists.freeswitch.org [8] mailto:freeswitch-dev@lists.freeswitch.org [9] mailto:moy@sangoma.com [10] mailto:devel@thom.fr.eu.org [11] mailto:moy@sangoma.com [12] mailto:anthony.minessale@gmail.com [13] mailto:devel@thom.fr.eu.org [14] mailto:jeroeng@thegreek.com [15] http://www.mail-archive.com/freeswitch-dev@lists.freeswitch.org/msg02830.htm [16] http://lists.freeswitch.org/pipermail/freeswitch-dev/2010-April/003607.html [17] mailto:jeroeng@thegreek.com [18] mailto:FreeSWITCH-dev@lists.freeswitch.org [19] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [20] http://lists.freeswitch.org/mailman/options/freeswitch-dev [21] http://www.freeswitch.org [22] mailto:FreeSWITCH-dev@lists.freeswitch.org [23] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [24] http://lists.freeswitch.org/mailman/options/freeswitch-dev [25] http://www.freeswitch.org [26] http://www.freeswitch.org/ [27] http://www.cluecon.com/ [28] http://twitter.com/FreeSWITCH_wire [29] mailto:MSN%3Aanthony_minessale@hotmail.com [30] mailto:PAYPAL%3Aanthony.minessale@gmail.com [31] http://irc.freenode.net [32] mailto:sip%3A888@conference.freeswitch.org [33] mailto:googletalk%3Aconf%2B888@conference.freeswitch.org [34] mailto:FreeSWITCH-dev@lists.freeswitch.org [35] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [36] http://lists.freeswitch.org/mailman/options/freeswitch-dev [37] http://www.freeswitch.org [38] mailto:FreeSWITCH-dev@lists.freeswitch.org [39] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [40] http://lists.freeswitch.org/mailman/options/freeswitch-dev [41] http://www.freeswitch.org [42] mailto:FreeSWITCH-dev@lists.freeswitch.org [43] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [44] http://lists.freeswitch.org/mailman/options/freeswitch-dev [45] http://www.freeswitch.org [46] mailto:FreeSWITCH-dev@lists.freeswitch.org [47] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [48] http://lists.freeswitch.org/mailman/options/freeswitch-dev [49] http://www.freeswitch.org
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@sangoma.com On Tue, Jul 13, 2010 at 2:35 PM, François Legal <devel@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@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@sangoma.com
On Thu, Jul 1, 2010 at 1:46 PM, François Legal <devel@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@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@sangoma.com
On Wed, Jun 30, 2010 at 6:29 PM, <devel@thom.fr.eu.org> wrote:
I’ll give a try tomorrow with HWEC disabled.
*De :* freeswitch-dev-bounces@lists.freeswitch.org [mailto: freeswitch-dev-bounces@lists.freeswitch.org] *De la part de* Moises Silva *Envoyé :* mercredi 30 juin 2010 23:15 *À :* freeswitch-dev@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@sangoma.com
On Wed, Jun 30, 2010 at 2:58 PM, François Legal <devel@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@sangoma.com
On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale < anthony.minessale@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@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@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@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@thegreek.com Phone: +1 876 953 6182 x128
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
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@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@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@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@lists.freeswitch.org [9] [mailto:freeswitch-dev-bounces@lists.freeswitch.org [10]] DE LA PART DE Moises Silva ENVOYÉ : mercredi 30 juin 2010 23:15 À : freeswitch-dev@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@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@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@thegreek.com [20] Phone: +1 876 953 6182 x128
_______________________________________________
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org [21]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev [22]
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev [23]
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@hotmail.com [32] GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com [33] IRC: irc.freenode.net [34] #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org [35] googletalk:conf+888@conference.freeswitch.org [36] pstn:+19193869900 _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@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@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@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@sangoma.com [2] mailto:devel@thom.fr.eu.org [3] mailto:moises.silva@gmail.com [4] mailto:moy@sangoma.com [5] mailto:devel@thom.fr.eu.org [6] mailto:moises.silva@gmail.com [7] mailto:moy@sangoma.com [8] mailto:devel@thom.fr.eu.org [9] mailto:freeswitch-dev-bounces@lists.freeswitch.org [10] mailto:freeswitch-dev-bounces@lists.freeswitch.org [11] mailto:freeswitch-dev@lists.freeswitch.org [12] mailto:moy@sangoma.com [13] mailto:devel@thom.fr.eu.org [14] mailto:moy@sangoma.com [15] mailto:anthony.minessale@gmail.com [16] mailto:devel@thom.fr.eu.org [17] mailto:jeroeng@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@thegreek.com [21] mailto:FreeSWITCH-dev@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@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@hotmail.com [33] mailto:PAYPAL%3Aanthony.minessale@gmail.com [34] http://irc.freenode.net [35] mailto:sip%3A888@conference.freeswitch.org [36] mailto:googletalk%3Aconf%2B888@conference.freeswitch.org [37] mailto:FreeSWITCH-dev@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@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@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@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@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
If however you have this issue even with HW EC, call Sangoma tech support and we will be happy to look at the issue.
I wish this was Sangoma hardware esp. with hardware ec :) My DTMF "bouncing" issues were indeed caused by echo but now that I've got OSLEC running (thanks for patching that) calls are echo-free and crystal clear. The issue now is that my users dial their transfers (-say- #44) reasonably fast and that often causes two successive DTMF digits to be detected as one (#4). In order to reliably reach the extension the clerk cannot dial more than one digit per second. That seems excessively slow. I suspect there must be a knob somewhere to tune that (in libteletone)? Other causes to look for? Cheers, -Slim
The tone on/off conditions should be, minimum on 40ms and 50ms off. I recommend you to record a call with those double digit detections. If you can reproduce them yourself by dialing quickly it'd be even better. Once you have the recording you can run libteletone on the recorded audio (see libs/freetdm/src/detect_dtmf.c) and may be start tweaking it. You could also run spandsp dtmf detector over the recorded audio to see if does a better job (I'd think so). Another way to test if spandsp does better is to disable dtmf detection completely from freetdm (the disable_dtmf dial plan app does that) and then use spandsp_start_dtmf application on the dialplan (see mod_spandsp). I'd be interested in looking at the recording too, you can send it to my email if you want me to take a look. You can record all the read/write audio using: ftmod trace /path/prefix <span> [<chan>] That starts recording all incoming and outgoing data on the channel (if no channel is specified all channels on the span are recorded), the specified prefix will be used for each of the files. The recording starts immediately (although if there is no call then most likely no one is reading/writing to the channel), you must stop the recording when done with: ftmod notrace <span> [<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@sangoma.com On Sat, Jul 3, 2010 at 4:22 AM, Jeroen C. van Gelderen <jeroeng@thegreek.com
wrote:
If however you have this issue even with HW EC, call Sangoma tech support and we will be happy to look at the issue.
I wish this was Sangoma hardware esp. with hardware ec :)
My DTMF "bouncing" issues were indeed caused by echo but now that I've got OSLEC running (thanks for patching that) calls are echo-free and crystal clear.
The issue now is that my users dial their transfers (-say- #44) reasonably fast and that often causes two successive DTMF digits to be detected as one (#4).
In order to reliably reach the extension the clerk cannot dial more than one digit per second. That seems excessively slow. I suspect there must be a knob somewhere to tune that (in libteletone)? Other causes to look for?
Cheers, -Slim
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
participants (6)
-
Anthony Minessale
-
Arturo Monroy
-
devel＠thom.fr.eu.org
-
François Legal
-
Jeroen C. van Gelderen
-
Moises Silva