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. m...@sangoma.com
On Wed, Jun 30, 2010 at 2:58 PM, François Legal <de...@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. m...@sangoma.com
>
>
> On Wed, Jun 16, 2010 at 12:09 PM, Anthony Minessale <
> anthony.miness...@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 <de...@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"
>>> <jero...@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<----
>>> > [r...@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: jero...@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_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org>
>> googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@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
