Correct operation of timout parameter for dial application

Home » Asterisk Users » Correct operation of timout parameter for dial application
Asterisk Users 1 Comment

Hi All,

I’d just like to verify what the correct operation of the timeout parameter is for the dial application. I’m not sure if I’ve encountered a bug or a configuration issue.

When a sip phone is not responding to invites on an outbound call, the dial application still waits the duration of timeout before continuing with dialplan execution. I was under the impression that app_dial would timeout on the signalling prior to the timeout parameter specified in the dial parameter.

For example, consider the following dialplan:

exten => 111,1),Dial(SIP/phone1,30,tg)
exten => 111,n,NoOp(DialStatus=${DIALSTATUS})
exten => 111,n,GotoIf($[${DIALSTATUS} = CHANUNAVAIL]?unavail)
exten => 111,n,GotoIf($[${DIALSTATUS} = NOANSWER]?unavail)
exten => 111,n,GotoIf($[${DIALSTATUS} = BUSY]?busy)
exten => 111,n,GotoIf($[${DIALSTATUS} = CONGESTION]?busy)
exten => 111,n(unavail), Goto(voice-mail,vmu-phone1,1)
exten => 111,n(busy), Goto(voice-mail,vmb-phone1,1)

Under normal operation the originating caller is passed through to voicemail. However, if/when the device is not responding to invites, for whatever reason, the dial application waits 30 seconds before setting the DIALSTATUS to NOANSWER. Is this expected behaviour? In previous versions of asterisk, specifically (v1.2/v1.4) when the device did not respond to invites the dial application exited prior to the value specified by timeout.

Can anyone clarify this issue for me please? Is this expected behaviour?

We are currently running v1.6.2.13

Thanks
Bruce

One thought on - Correct operation of timout parameter for dial application

  • I seem to recall an issue like that some time back where somebody thought
    that if their SIP phone wasn’t responding, the Dial app should wait the
    full 30 seconds before giving up, but I cannot find the related commit for
    that. I’m sure there’s arguments on both sides for the behavior. I’d
    suggest that you open an issue on issues.asterisk.org, and we can take a
    look at how we could accommodate both approaches.