[asterisk-users] WaitExten() always times out

[Miguel Molina]

El 19/08/10 15:07, Kathryn Jones escribió:
> Thanks for your reply :)
>
> I added Answer to my dialplan:
>
> exten => xxx,1,Answer()
> exten => xxx,n,Background(welcome)
> exten => xxx,n,WaitExten(7)
>
> exten => _X,1,AGI(agi.php)
> exten => _X,n,PlayBack(vm-tocallnumber)
> exten => _X,n,Dial(SIP/voiptrunk/${NUM})
>
> exten => t,1,Noop(*****timeout*****)
> exten => t,n,Playback(pbx-invalid)
> exten => t,n,Hangup()
>
> cli output:
>
> -- Executing [xxx at default:1] Answer("SIP/xx.xx.xx.xx-00000004", "") in 
> new stack
>     -- Executing [xxx at default:2] 
> BackGround("SIP/xx.xx.xx.xx-00000004", "welcome") in new stack
>     -- <SIP/xx.xx.xx.xx-00000004> Playing 'welcome.slin' (language 'en')
>     -- Executing [xxx at default:3] WaitExten("SIP/xx.xx.xx.xx-00000004", 
> "7") in new stack
>     -- Timeout on SIP/xx.xx.xx.xx-00000004, going to 't'
>     -- Executing [t at default:1] NoOp("SIP/xx.xx.xx.xx-00000004", 
> "*****timeout*****") in new stack
>     -- Executing [t at default:2] Playback("SIP/xx.xx.xx.xx-00000004", 
> "pbx-invalid") in new stack
>     -- <SIP/xx.xx.xx.xx-00000004> Playing 'pbx-invalid.gsm' (language 
> 'en')
>     -- Executing [t at default:3] Hangup("SIP/xx.xx.xx.xx-00000004", "") 
> in new stack
>   == Spawn extension (default, t, 3) exited non-zero on 
> 'SIP/xx.xx.xx.xx-00000004'
> [] WARNING[1235]: chan_sip.c:3780 retrans_pkt: Maximum retries 
> exceeded on transmission 0ef328f40a5fd6ca31a68dae2af75219 at xx.xx.xx.xx 
> for seqno 102 (Critical Response) -- See doc/sip-retransmit.txt.
> [] WARNING[1235]: chan_sip.c:3780 retrans_pkt: Maximum retries 
> exceeded on transmission 0ef328f40a5fd6ca31a68dae2af75219 at xx.xx.xx.xx 
> for seqno 102 (Critical Response) -- See doc/sip-retransmit.txt.
>
> I still can't read the DTMF input :(
>
> I also tried adding:
>
> dtmfmode = rfc2833
> rfc2833compensate = yes
> relaxdmtf = no ; should be no because setting it to yes cause talkoff
>
> to sip.conf and chan_dahdi.conf
> and increasing rxgain=20 (I wasn't sure how much was appropriate)
>
> Nothing seems to help.
>
> ANY tips or ideas will be apreciated.
>
>
> On Thu, Aug 19, 2010 at 1:19 PM, Tilghman Lesher <tlesher at digium.com 
> <mailto:tlesher at digium.com>> wrote:
>
>     On Wednesday 18 August 2010 16:52:38 Kathryn Jones wrote:
>     > I must not be receiving them properly, since I can't make it
>     work. I just
>     > can't see why :P.
>     >
>     > My asterisk version is 1.6.2.6. Like I said before, for outgoing
>     .call
>     > files WaitExten works fine, it's on incoming calls that I cannot
>     receive
>     > the number I need.
>
>     There's your answer.  On outgoing calls, the other end signals the
>     line into
>     answered state, whereas on incoming calls, you must explicitly
>     answer the
>     channel before listening for DTMF.
>
>     --
>     Tilghman Lesher
>     Digium, Inc. | Senior Software Developer
>     twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
>     Check us out at: www.digium.com <http://www.digium.com> &
>     www.asterisk.org <http://www.asterisk.org>
>
I suggest you to debug DTMF and core, enabling them in logger.conf:

console => notice,warning,error,debug,dtmf

And issuing a "logger reload" command in asterisk CLI.

A rxgain of 20 is too much for me, leave them in rxgain = 0.0 and 
txgain= 0.0. Maybe 20dB gain is high enough to distort the audio signal 
and make DTMF detection more difficult.

Look at the DTMF events in your CLI, that way you can debug better. You 
can enable core debug if you want issuing the CLI command "core set 
debug X", with X on 1 or 2, and setting it off when you want.

If your call is received from the PSTN, asterisk will detect the inband 
DTMF tones in the audio signal. The rfc2833 configurations are only for 
VoIP endpoints.

Good luck in your debugging,

-- 
Ing. Miguel Molina
Grupo de Tecnología
Millenium Phone Center


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100819/85ec5318/attachment.htm