Background / Invalid Extension through cell phone

Asterisk Asterisk Support
1

Hi,

I have had an issue for a long time, and really just can’t solve it.

My boss and others seem to have a problem when they call into our asterisk phone system. It often takes 3-4 tries of entering an extension before the system gets it right.

Below is my context that the call comes into, and some debugging from the asterisk console.

[corporate]
;;exten => fax,1,Macro(faxreceive)
#include “local_ext.conf”

exten => s, 1, answer
exten => s, 2, Wait(2)
exten => s, 3, Background(menu_ty)
exten => s, 4, Background(menu_ext)
exten => s, 5, WaitExten(30)
exten => s, 6, Voicemail(u100)
exten => s, 7, Hangup()

exten => t, 1, Hangup
exten => i, 1, goto(s|4)

Below, you will see the call come into Zap/53. He is trying to dial extension 104. The first few times, only the 4 is recognized. Then 14. But if you look at the cellphone screen, you see 104104104104104104.

– Executing BackGround(“Zap/53-1”, “menu_ext”) in new stack
– Playing ‘menu_ext’ (language ‘en’)
– Invalid extension ‘4’ in context ‘corporate’ on Zap/53-1
== CDR updated on Zap/53-1
– Executing Goto(“Zap/53-1”, “s|4”) in new stack
– Goto (corporate,s,4)
– Executing BackGround(“Zap/53-1”, “menu_ext”) in new stack
– Playing ‘menu_ext’ (language ‘en’)
– Invalid extension ‘4’ in context ‘corporate’ on Zap/53-1
== CDR updated on Zap/53-1
– Executing Goto(“Zap/53-1”, “s|4”) in new stack
– Goto (corporate,s,4)
– Executing BackGround(“Zap/53-1”, “menu_ext”) in new stack
– Playing ‘menu_ext’ (language ‘en’)
– Playing ‘vm-intro’ (language ‘en’)
pbxCLI>
– Invalid extension ‘4’ in context ‘corporate’ on Zap/53-1
== CDR updated on Zap/53-1
– Executing Goto(“Zap/53-1”, “s|4”) in new stack
– Goto (corporate,s,4)
– Executing BackGround(“Zap/53-1”, “menu_ext”) in new stack
– Playing ‘menu_ext’ (language ‘en’)
pbxCLI>
– Invalid extension ‘14’ in context ‘corporate’ on Zap/53-1
== CDR updated on Zap/53-1
– Executing Goto(“Zap/53-1”, “s|4”) in new stack
– Goto (corporate,s,4)
– Executing BackGround(“Zap/53-1”, “menu_ext”) in new stack
– Playing ‘menu_ext’ (language ‘en’)
pbxCLI>
pbxCLI>
== Spawn extension (ebay, s, 2) exited non-zero on ‘Zap/56-1’
– Hungup 'Zap/56-1’
pbx*CLI>
== CDR updated on Zap/53-1
– Executing Macro(“Zap/53-1”, “stdexten|104|IAX2/congdonj”) in new stack
– Executing Dial(“Zap/53-1”, “IAX2/congdonj|20|tw”) in new stack

2

This would be better titled “cell phone DTMF problem” :laughing: I was told that some mobile carriers do not transmit the best signals into PSTN.

3

Are there any known patches? Would relaxed DTMF help? Or is this just something we have to live with?

4

Relaxed DTMF did not help me quite, if I call from T-mobile. No problem when I call from Nextel. But you could Google.

5

Not just an asterisk issue. I think it’s just the poor quality of service that cell phones give. I found that if I hold the buttons down longer that it works better. Apparently my cell phone does send true DTMF, so holding the button results in a longer tone, and hence less chance for a “button press” to be dropped…

6

Some carriers, maybe. T-Mobile is GSM, supposingly DTMF is transmitted out of band - so it should always be accurate. :cry:

7

I am experiencing problems with DTMF digits doubling for calls coming in in-Band from the GSM network over EuroISDN PRI to asterisk.
We have recorded a wave file and found out that we need to have debouncing of about
400ms (make asterisk blind to DTMF for 400ms after receiving a valid DTMF digit).
However, I have looked over the source code, including dsp.c, and could not find how to set this parameter.
Can someone advise how to do this.

8

If 400ms is accurate and stable, I can think of a wacky way: Read() one digit at a time.

exten => s,1,NoOp(Rid bouncing tones); untested exten => s,n(start),Read(digit,1) exten => s,n,GotoIf($[${digit}=#?cont) exten => s,n,Set(number=${number}${digit}) exten => s,n,Answer(400); just wait for 400 ms exten => s,n,Goto(start) exten => s,n(cont),stuff...

9

Thank you, will try.
Another question - can ASterisk in the bridged mode capture DTMF from leg A, process it per your recommendation and spit it out to leg B ?