Summary:ASTERISK-01868: Busy message on unavailable - app_dial
Reporter:lt8x7 (lt8x7)Labels:
Date Opened:2004-06-22 20:22:39Date Closed:2004-09-25 02:15:29
Versions:Frequency of
Description:When a SIP extension that is defined in the sip.conf is dialed, but it is not connected/registered to Asterisk, then the dialplan falls to the Priority+101 which results in a "User is busy" message.  It should go to Priority+1 so it returns a "User is unavailable" message.
Comments:By: twisted (twisted) 2004-06-22 22:04:03

Actually, IMHO, this is working as designed.   Asterisk returns busy if the user is not logged in, unavailable if non-answer, or the setup executes, and times out.    


In my dialplan, i added an entry 1005 for user SIP/Josh which exists in sip.conf.   This user is not registered with asterisk, since the device is not even attached to the network at the time.

This is the resulting information from Asterisk:

   -- Executing Dial("SIP/JoshSIP-1f39", "SIP/Josh|15|r") in new stack
Jun 22 21:42:52 NOTICE[1818638]: app_dial.c:694 dial_exec: Unable to create channel of type 'SIP'
 == Everyone is busy at this time

If we cannot create the channel, then dial fails.  On fail, as noted in app_dial,
In general, the dialer will return 0 if it
was unable to place the call, or the timeout expired. However, if all
channels were busy, and there exists an extension with priority n+101 (where
n is the priority of the dialer instance), then it will be the next
executed extension (this allows you to setup different behavior on busy from

Maybe it's not noted so clearly, but for instance, if the user registered, and during that registration timeout became un-reachable, this would work as desired.  However, since dial at this time doesn't distinguish between the ability to create the channel and the channel being busy (they both will fail to be created), they are treated as a "fail" and sent to the busy N+101.  Maybe we should add some logic to dial to distinguish between "busy due to limits" and "unable to create channel".

By: lt8x7 (lt8x7) 2004-06-22 22:09:19

But unable to create channel because the device is not registered/connected is NOT the same as unable to create the channel because it is in use.  There needs to be a differentiation between the two.

By: twisted (twisted) 2004-06-22 22:14:21

The problem here is how dial determines the ability to create the channel.  All it knows is that it can't create the channel.

By: Mark Spencer (markster) 2004-06-22 22:14:48

It would probably be valuable if we created a variable that was set after app_dial finished, say "DIALSTATUS", which would be one of:


Then you could do something like:

; Dial the extension
exten => s,1,Dial(${ARG1},20)
; Based on the status, jump to the right operation
exten => s,2,Goto(s-${DIALSTATUS},1)
; If busy, go to busy voicemail
exten => s-BUSY,1,Voicemail(b${ARG2})
exten => s-BUSY,2,Hangup
; Congestion could provide an error or something
;exten => s-CONGESTION,1,Playback(vm-userunavail)
; Anything else, consider unavailable
exten => _s-.,1,Voicemail(u${ARG2})
exten => _s-.,2,Hangup

By: twisted (twisted) 2004-06-22 22:18:05


 I agree, that could definately be valuable.  How hard would that be to impliment?

By: lt8x7 (lt8x7) 2004-06-22 22:22:43

Mark, your idea sounds ideal.  Let's get it done.

By: quiescent (quiescent) 2004-06-22 23:10:33

Mark, lt8x7, this is already done: ${HANGUPCAUSE}.  It's also documented.  What doesn't appear to be documented, however, is that it's only been implented in chan_zap and chan_sip.

By: twisted (twisted) 2004-06-22 23:30:10

Hangup cause is different than why it couldn't create the channel.

By: Mark Spencer (markster) 2004-06-22 23:31:32

Okay I've committed my first pass at this to CVS head.

By: Brian West (bkw918) 2004-06-22 23:36:41


Flashback :P