Hi all, I have some probleem detecting DTMF send by a GSM phone, I'm using SIP with ulaw. do you know what are the options to improve the detection ? I'm using asterisk 1.05, is the CVS HEAD version had some improvement about DTMF detection? Florian.
Hi Florian, If you really are using ulaw, and you do not have extreme packet loss or jitter, DTMF detection should be very reliable. It is no better in CVS HEAD because it wasn't broken in the first place. What does wrong with DTMF detection? Do you realise how DTMF from a GSM phone works? If you get digits when you press them really slowly on the phone, but miss some when you press them fast, then welcome to the land of GSM :-) The DTMF tones don't come from phone. The come from the basestation. Most basestations stretch each digit to well over a second. It really screws up any attempt at timing based entry methods. :-( Regards, Steve Florian Lefeuvre wrote:> Hi all, > > I have some probleem detecting DTMF send by a GSM phone, > I'm using SIP with ulaw. > do you know what are the options to improve the detection ? > I'm using asterisk 1.05, > is the CVS HEAD version had some improvement about DTMF detection? > > Florian.
Steve:
Given this and the number of recent messages related to DTMF problems
can you add any thoughts on how to improve implementations?
I too have problems correctly handling DTMF in my environment. In the
LAN /IP world DTMF works as expected to allow an IP phone user to
access my Asterisk based menu.
Calls from the PSTN usually work as expected but occasionally someone
reports that pressing the keypad digits has no affect. Instead the timeout
clause is eventually hit and the caller is disconnected.
Cell phone users cannot even use their phone keypad to respond to
prompts. They always timeout.
Thanks,Steve
Steve Underwood wrote:
> Hi Peter,
>
> If that is true, someone must have broken something. Not only does the
> DTMF detector I wrote not care about small imperfections, it even
> tolerates a dropped packet with the DTMF passes over a VoIP path (this
> kind of tolerance was added a couple of years ago).
>
> Regards,
> Steve
>
>
> Peter Svensson wrote:
>
>> We have some problems with dtmf detection on our lines. We use E1 pris
>> connected to a TE405P. Mostly we see duplicated digits. Unless the
>> signal is perfect and distortion free Asterisk sees the small
>> imperfections as the end of the digit.
>>
>> We can provoke this problem from some of our office phones (when on
>> speaker phone). Asterisk is more or less the only place we see this
>> problem.
>>
>> Peter
>>
>>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@upenn.edu
On Wed, 16 Feb 2005, Steve Underwood wrote:> If that is true, someone must have broken something. Not only does the > DTMF detector I wrote not care about small imperfections, it even > tolerates a dropped packet with the DTMF passes over a VoIP path (this > kind of tolerance was added a couple of years ago).Actually, the problem has gone away for us, probably after some upgrade. We are running a cvs head version from december. The phones that used to be problematic no longer are. The last time we seem to have seen that problem according to the logs was in september. After an upgrade there the problems went away. Asterisk does handle imperfect DTMF tones correctly for us on our pure TDM setup. We use VoIP very little and only over a lightly loaded lan and have not noted any problems there either. Sorry about the false alarm. Peter
> > >On Feb 16, 2005, at 10:34 AM, Steve Underwood wrote: > > > >>>>> >>>>> BTW, Steve, if you're still reading, what is the RADIO_RELAX option >>>>> intended to be for in dsp.c? >>> >>> >>> >>> It is something someone else added to the code to make the detection >>> criteria in relaxed mode even more relaxed. If setting that helps, >>> something in your channel must be causing some serious filtering of >>> low frequencies. Can you try logging the audio to a file, and send it >>> to me for analysis? chan_spy, or something like that, should do the >>> job. >>> >> >> > >Actually, it was Florian that posted about this option. I haven't tried >it (spent an awful lot of time last week compiling different >configurations of stable, head, patches...taking a break this week). >This is Florian said: > >On Feb 15, 2005, at 1:12 PM, Florian Lefeuvre wrote: > > > >>> >>> I find the compilation option RADIO_RELAX. >>> this option change a threshold in DTMF detection (function dtmf_detect >>> in dsp.c) >>> I remark an big improvement in the detection of the dtmf over GSM. >>> have you ever test this option? >>> RADIO is obscur for me, does it mean all wireless device? >>> >>> Florian >> >> > >-mark >Hi Steve, I was the one who post a question about the RADIO_RELAX option. In fact when I set it , I remark some better result in the detection of the DTMF... after a few more tests, It appears I was wrong. I did a record of samples used by the DTMF_detect function. I obtain an audio file : PCM , 16 bits signed, big endian, Fs 8kHz. If I compare an audio file of DTMF generated by land line with one generated by GSM phone, I remarks a big difference. for a land line, the shape is very good., amplitude is nearly constant for a dtmf. for a gsm phone, the shape is bad, it can can an amplitude 5 times bigger than a land line. After some tests, I see that lot's of errors occurs when the signal amplitude was too big (saturation). I wonder if I should clip or attenuate the signal or a better detection... if you want I can send you some file.... Florian .