[Home]

Summary:ASTERISK-14059: DTMF is not working correctly for cell phones.
Reporter:alexo (alexo)Labels:
Date Opened:2009-05-03 15:12:31Date Closed:2011-06-07 14:00:38
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cell_calling_202ext.mp3
( 1) cell.log
( 2) land_calling_202ext.mp3
( 3) land.log
Description:We have an issue calling the extension number from cell phones. Sometime is works, but mostly fails.

The problem is that DTMF tones are coming as doubles or just in wrong order. I'll attach asterisk console output for cell phones and land one (yes, land phones works as expected - always).

Any help is really appreciated as most of our customers are mobile.

****** ADDITIONAL INFORMATION ******

I added to my zapata.conf

relaxdtmf=1
toneduration=300

but that didn't help.

Here is the output from dahdi show channel 1:

Channel: 1CLI>
File Descriptor: 9
Span: 1k1*CLI>
Extension: LI>
Dialing: noLI>
Context: from-pstn
Caller ID: LI>
Calling TON: 0
Caller ID name:
Destroy: 0CLI>
InAlarm: 0CLI>
Signalling Type: E & M Wink
Radio: 01*CLI>
Owner: <None>>
Real: <None>I>
Callwait: <None>
Threeway: <None>
Confno: -1CLI>
Propagated Conference: -1
Real in conference: 0
DSP: nok1*CLI>
Relax DTMF: yes
Dialing/CallwaitCAS: 0/0
Default law: ulaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps unless TDM bridged, currently OFF
Actual Confinfo: Num/0, Mode/0x0000
Actual Confmute: No
Hookstate (FXS only): Onhook
Comments:By: alexo (alexo) 2009-05-03 15:32:51

Here is some additional information about the system

# modinfo zaptel | grep ^version
version:        1.4.12.1

# cat /proc/version
Linux version 2.6.18-128.1.6.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Apr 1 09:19:18 EDT 2009

# cat /proc/zaptel/1
Span 1: WCT1/0 "Digium Wildcard TE110P T1/E1 Card 0" (MASTER) B8ZS/ESF

          1 WCT1/0/1 E&M (In use)
          2 WCT1/0/2 E&M (In use)
          3 WCT1/0/3 E&M (In use)
          4 WCT1/0/4 E&M (In use)
          5 WCT1/0/5 E&M (In use)
          6 WCT1/0/6 E&M (In use)
          7 WCT1/0/7 E&M (In use)
          8 WCT1/0/8 E&M (In use)
          9 WCT1/0/9 E&M (In use)
         10 WCT1/0/10 E&M (In use)
         11 WCT1/0/11 E&M (In use)
         12 WCT1/0/12 E&M (In use)
By: Matt Riddell (zx81) 2009-05-03 18:47:07

Likely related to http://bugs.digium.com/view.php?id=14815

ASTERISK-13887
By: alexo (alexo) 2009-05-04 08:56:47

It might, but we don't use RTP.
By: Leif Madsen (lmadsen) 2009-05-04 12:55:32

I've added a relation to 14815 for now *just incase* they are related. They probably aren't, but at least this way the DTMF issues are tracked together.

Additionally, can the reported please try going back to 1.4.21 and see if this issue is present there?
By: alexo (alexo) 2009-05-04 12:59:51

Yes, I reverted back to 1.4.21.1, but the issue was the same, so from now I'm back to 1.4.24.
By: Dmitry Andrianov (dimas) 2009-05-04 13:20:09

I do not think it is related to 14815 because the latter is SIP only (RTP only to be more precise).

In contrast, here we most likely have DSP DTMF detection issues.

alexo,
1. can you record a call from mobile during the period user enters digits? (into a wav file) Look into the file with any tool like WavePad then to see what is going on. I bet the signal is just "wobbling" and there is clear gap in the middle of "2" digit which is interpreted by the Asterisk as inter-digit gap. (You can also put a wav file somewhere annd give us a link if you do not how to deal with it)

2. Is it possible for you to run any of 1.6 versions?

PS: 'relaxdtmf' should be 'yes' according to sample config. (Maybe '1' works fine too but I would use 'yes' just for clarity).
JFYI, 'toneduration' is not used at all in DTMF detection process.


By: alexo (alexo) 2009-05-04 13:31:27

1. I was trying to record the session using ztmonitor, but it gives me

Writing combined stream to /tmp/zaptel.wav
Nothing to do with the stream(s) ...

when I execute ztmonitor 1 -f /tmp/zaptel.wav

Probably I'm using wrong tool? So I need your advice.

2. Probably, but not in near future.

P.S. I was trying both yes and 1 to relaxdtmf. Both work same way.


By: Dmitry Andrianov (dimas) 2009-05-04 13:43:11

You can just add Monitor/StopMonitor application to your dialplan based on some conditions (like caller ID match or something else) to get the stream recorded.

Do NOT mix inbound/outbound channels - you should get two WAV files each will contain sound coming into one direction.


By: alexo (alexo) 2009-05-04 14:18:06

Thanks, I'll create two records for land and cell phone later today for compare.
By: alexo (alexo) 2009-05-05 10:30:35

Here is the uploaded tone sound files:

1. Cell phone calling 202 ext three times. Last time was success. I can understand why Asterisk didn't get the second try, but why not the first?
2. Land phone calling same extension. Went fine.
By: Dmitry Andrianov (dimas) 2009-05-05 10:50:49

First of all, mp3 is a bad idea. wav files would be better.
Have you played these files yourself? even the naked ear hears that there is a big problems with the sound (compare what you hear in this file to what you hear in the phone handset when you press "2").
The DTMF signal is kind of "pulsating". And in any sound editor you will see that during 400 ms DTMF digit the amplitude drops to zero for at least 10 milliseconds six times! That is enough to consider inter-digit gap.

I'm not sure if the signal you are receiving is really that bad or it is result of some problems during recording or MP3 encoding. How do you receive these tones? Do you use some GSM gate or what?

First of all please make sure you understand what "wobbling" I mean - hear your signals and what an ordinary phone at your desk produces. Next, check if a person calls your IP phone from mobile and presses digits during a talk - do you also hear distorted sound or not.


By: alexo (alexo) 2009-05-05 11:18:13

Here is the upload links for original wav files:

http://www.propellerheadgroup.com/media/cell_calling_202ext.wav
http://www.propellerheadgroup.com/media/land_calling_202ext.wav
By: alexo (alexo) 2009-05-05 11:20:51

All this true about second try, but what about 1st and the last one? Have you heard anything unusual, that may forbid correct recognizing? Most interesting is why 0 at 1st try "disappeared"?
By: Dmitry Andrianov (dimas) 2009-05-05 11:27:19

No, all this true about first try. Give me your email, I'll send you the picture how the signal looks like. It is very distorted.
By: alexo (alexo) 2009-05-05 13:15:53

I just used RecOnPhone (the application of 9 year old) to decode my samples. And it determines the sequences like 202, 2002, 202. As you see much better than Asterisk does. Any thoughts?
By: Dmitry Andrianov (dimas) 2009-05-05 14:35:40

I emailed you screenshot how the signal looks like.
No doubt it is very distorted so I can not blame Asterisk for not recognizing it.

In Asterisk 1.6 there are additional controls which you can pull to make it more tolerant to such signals.
By: alexo (alexo) 2009-05-05 15:40:21

The question is when the distortion occurs? GSM->Telco -> zaptel -> chan_dahdi.so. If I got things right, they are all the subject. Since the records were made using Monitor() extension command, this involves all chain, right?

I'm trying to debug the issue with Telco to see what they are getting. I'll post a result as soon as I have it.
By: Dmitry Andrianov (dimas) 2009-05-06 03:14:10

Ahh. I forgot that Asterisk actually "removes" (or "squelches" in Asterisk terminology) detected DTMF tones from the signal - this is clearly visible in your landline call WAV file.
Because of this, the WAV file Monitor writes can be just wrong (because if Asterisk has positive hit one moment during a signal, it will remove ("zero") corresponding part of the signal producing "gaps" itself.

So, ztmonitor is probably the better choice. It should be something like
ztmonitor 1 -t /tmp/zap-tx.raw -r /tmp/zap-rx.raw

However this tool does not seem to work on my machine...


By: alexo (alexo) 2009-05-06 10:23:13

Here is what I get:

1. The 1st cell call was successful and asterisk recognized sequence as 202 (as it was) - http://www.propellerheadgroup.com/media/cell_calling_202_worked_at_first_try.wav

I still see the amplitude dropping to zero during tone duration, but this one pattern worked for some reason. Maybe pauses were almost equal?

2. The next call was try of pressing 202 four times (all failed).
Asterisk record at  http://www.propellerheadgroup.com/media/cell_calling_202_failed_all_tries_asterisk.wav
Zaptel record at http://www.propellerheadgroup.com/media/cell_calling_202_failed_all_tries_zaptel.wav as well raw file at http://www.propellerheadgroup.com/media/cell_calling_202_failed_all_tries_zaptel.raw

What I see from zaptel record is that the tones were continuous comparing to torn tones as processed by Asterisk.

So it looks like we came to where we started. Something in chan_dahdi.so breaks signal. Do we have enough debug info to fix it?

P.S. You may hear land phone tones at the end of raw file. It was caught by accident, but left it just you want to compare.


By: Dmitry Andrianov (dimas) 2009-05-06 10:42:13

I will run these files through Asterisk DSP code to see what asterisk thinks.
However as you left landline tones in the raw file - I bet you can hear the huge difference yourself. Just compare the last set of three DTMF tones from the raw file (landline) with the previous (cell). Compared to the cell, landline signal is just perfect.
By: alexo (alexo) 2009-05-06 10:44:41

Here is how the sequence of four 202 was processed by Asterisk:

[May  6 07:37:03] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms
[May  6 07:37:03] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '2' on Zap/1-1
[May  6 07:37:03] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '2' on Zap/1-1
[May  6 07:37:03] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms
[May  6 07:37:03] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '2' on Zap/1-1
[May  6 07:37:03] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '2' on Zap/1-1
   -- Invalid extension '22' in context 'ivr-1' on Zap/1-1

[May  6 07:37:04] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '0' received on Zap/1-1, duration 0 ms
[May  6 07:37:04] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '0' on Zap/1-1
[May  6 07:37:04] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '0' on Zap/1-1
[May  6 07:37:05] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms
[May  6 07:37:05] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '2' on Zap/1-1
[May  6 07:37:05] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '2' on Zap/1-1

[May  6 07:37:16] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms
[May  6 07:37:16] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '2' on Zap/1-1
[May  6 07:37:16] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '2' on Zap/1-1
[May  6 07:37:16] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms
[May  6 07:37:16] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '2' on Zap/1-1
[May  6 07:37:16] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '2' on Zap/1-1
   -- Invalid extension '22' in context 'ivr-1' on Zap/1-1

[May  6 07:37:22] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms
[May  6 07:37:22] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '2' on Zap/1-1
[May  6 07:37:22] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '2' on Zap/1-1
[May  6 07:37:24] DTMF[12563]: channel.c:2229 __ast_read: DTMF end '2' received on Zap/1-1, duration 0 ms
[May  6 07:37:24] DTMF[12563]: channel.c:2271 __ast_read: DTMF end accepted without begin '2' on Zap/1-1
[May  6 07:37:24] DTMF[12563]: channel.c:2282 __ast_read: DTMF end passthrough '2' on Zap/1-1
   -- Invalid extension '22' in context 'ivr-1' on Zap/1-1
By: alexo (alexo) 2009-05-06 10:49:13

Yes, I hear the difference, but that doesn't explain why the tones were changed so badly (torn) during Asterisk processing. Guess that's the only issue.
By: Dmitry Andrianov (dimas) 2009-05-06 19:08:47

Well.... I looked at the raw file. It is really interesting. It definitely has a distortion in it - more about this later.

You should know that Asterisk detects DTMF in 20ms frames (160 samples). The 400ms signal in your samples spans about 20 frames. In most of these frames  Asterisk is unable to detect DTMF (because of distortion) but in some frames Asterisk detects DTMF successfully. This has two major consequences:

A. Since during a 400ms real signal there are multiple frames where DTMF is found followed by the frames where DTMF is not found, Asterisk reports multiple copies of the same digit. (Because a frame where DTMF is not present considered a valid inter-digit pause).

B. In frames where Asterisk detects DTMF, it zeroes content of the frame to remove that DTMF tone from voice channel. This is done by chan_dahdi code and this is what causes dropouts in the signal as seen by Monitor.

The bottom line of the above: there is no bug which distorts signal in the chan_dahdi. It is just normal behavior of Asterisk plus very bad input signal.


Now to the input signal: as I said it is interesting. only a few samples are "damaged" in each frame but these samples cause the distortion you can hear. It looks like the distortion is caused by overflow of 16-bit integers used to represent slinear (signed linear) samples at points where amplitude is too high.

So to me it looks like your signal just overloads your Zap device. Aren't you using too much rxgain or someting?


By: alexo (alexo) 2009-05-07 08:52:06

Interesting point. rxgain was set to 0 (default) and listening few samples recorded with voice I noticed same distortions - amplitude drops to zero several times during sample duration.

This is what I have done so far:

1. Migrated from zaptel to dahdi kernel driver (that should be done anyway to support future upgrades and to avoid possible bugs still present in zaptel driver).
2. Played with rxgain in chan_dahdi.conf.

There few notices. When I decreasing rxgain (I was trying up to -3.0) the voice record with dadhi_monitor showed distortions and voice sounded like robot's one (checked, it wasn't the robot :) Increasing the level (I was trying up to 2.0) gave me more human-like voice. I can say it sounded very close to original.

But in all tests DTMF amplitude didn't change at all. Was I using wrong parameter to tune or why tone signal wasn't changed?


By: alexo (alexo) 2009-05-07 10:07:37

Looks like migration from zaptel to dahdi did the trick. I made around 10 tests with cell phones and DTMF tones sounded as they suppose to. And, yes, they all were recognized correctly.

So please put the ticket to close pending state.
By: Leif Madsen (lmadsen) 2009-05-12 14:05:28

Closed per reporter as changing from Zaptel to DAHDI resolved the issue.