[Asterisk-Dev] Dial() returns - +1 or +101 and what they mean

[Steven Critchfield]

On Wed, 2003-12-24 at 04:16, Stephen Davies wrote:
> Hi,
> 
> I'm confused about the meaning of the +1 and +101 returns from Dial().
> Right now to me it looks like Asterisk doesn't implement this
> consistently between channel types.
> 
> The handbook explains that the +101 return is used for "Busy", if no
> called party doesn't answer then flow continues at +1.  If a called
> party does answer then the legs are bridged and we are done.
> 
> This is demonstrated with a Zap interface connected to an extension.
> 
>   exten => 6001,1,Dial(Zap/1,10)
>   exten => 6001,2,Voicemail(u6001)
>   exten => 6001,102,Voicemail(b6001)
> 
> So: for Zap interfaces flow branches to +101 if the channel is
> unavailable, to +1 if it isn't answered.
> 
> Note that this logic is applied whether the interface is for a phone
> or for a trunk - so a trunk interface in use behaves like "Busy" and
> brances to +101.  To me that seems illogical.
> 
> Now - in section 4.3.10 an example is presented of "failover
> trunking" - the example uses IAX:
> 
>   exten => _91256NXXXXXXX,1,Dial(IAX/hsv/${EXTEN})
>   exten => _91256NXXXXXXX,2,Dial(Zap/g2/{EXTEN:1})
>   exten => _91256NXXXXXXX,3,Congestion
> 
> Here, it seems an IAX channel will continue to +1 if the channel isn't
> available. This is the opposite to the logic for Zap channels!?
> 
> What am I not understanding?

If you reread the documentation on dial inside asterisk(show application
dial) you will notice it says if the n+101 exists and all channels are
busy it will branch to n+101, else it just branches to n+1. This
explains the above as there is no need to differentiate on dial timeout
since the calling user will decide to hangup if too long or will get
directed to remote side voicemail.

> Or, is the problem that Dial should have more than two returns - right
> now Busy, Congestion and No answer within timeout are all being
> squeezed into two returns.

There has been discussion of multiple returns for dial so it can deal
more gracefully with failure.
-- 
Steven Critchfield <critch at basesys.com>