[Asterisk-Dev] Proposed solution for exit code priority jumps

John Todd jtodd at loligo.com
Fri Nov 28 19:49:28 MST 2003


Proposal for Alternate Error Handling Jumping

Why: I have written quite a bit into various extensions.conf files, 
and I've started to find myself getting really, really frustrated 
with the +101 and +51 and +blah format of error handling.  I often 
create very ugly and awkward dialing plans to handle jumps from (as 
an example) multiple Dial statements which directly follow one 
another.  Hardcoding a "Goto" into each application seems to be a 
method that, as Asterisk matures, should be left behind.

I have whined before about the lack of exit codes from many 
applications (especially Dial) and perhaps there is some middle 
ground.  I have come up with two methods that might make the job of 
the advanced administrator significantly easier, and dialplans more 
compact.  Additionally, logic for handling results of applications 
would be visible in the same configuration line as the application, 
instead of in a long chain of comparisons, or not at all, as is the 
current case.

Both of these methods could be implemented (to the best of my 
knowledge) without changing the way the application priority syntax 
currently works, and are completely backwards compatible with current 
methods.  If this is not the case, I would appreciate someone 
explaining how this could be better done, or why it should not be 
done in the first place.

Alas, as with most of my proposals, I can only offer ideas and not 
actually code them.  Volunteers welcome.


Proposed Solution:

Alter the priority statement to take modifiers, if specified, so that 
the three basic exit codes could be given different places to land. 
In my example, exit-1 is the place where we should jump on a "-1" 
exit code, exit0 is where we go on a zero result, and exit1 is "error 
but continue" in situations like Busy, and so on.  Applications like 
ENUMLookup, as an example, would have to document two different 
"error but continue" codes, currently represented by the +101 on no 
ENUM reply (turns into exit code 1) and +51 on TEL (turns into exit 
code 2).

Syntax:
exten => extension,[priority[/exit-1[/exit0[/exit1[/...]]]],Application

Exmaple:
exten => _87810.,1/h/2/4/10,EnumLookup(${EXTEN})
exten => _87810.,2,Dial(SIP/${ENUM})
exten => _87810.,3,Hangup
;
exten => _87810.,4,Answer
exten => _87810.,5,Playback(sorry-no-enum-information)
exten => _87810.,6,Hangup
;
exten => _87810.,10,Dial(Zap/g1/${ENUM})
exten => _87810.,11,Hangup
;
exten => h,1,Hangup


Alternate method (more complex):

Applications could exit with any number of codes, perhaps even 
dynamic code results, and wildcards could be used to match on 
priority jumping.  This is a simpler method than setting an arbitrary 
string as a result of an application and then using a series of 
GotoIf statements to redirect call control.  It is more complex and 
completely encloses the purely ordinal solution I describe as the 
first proposed solution.  Each application might have it's own list 
of exit codes which mean different things, or dynamically exit with 
results that might allow the administrator to take actions without 
having to set variables and create labyrinths of GotoIf's upon an 
application's exit.

Syntax:
exten => extension,[priority[/pattern|priority[...]],Application

Example:
exten => 1234,1/_20.|cont/_40.|fail,Dial(SIP/1234)
exten => fail,1,Hangup
exten => cont,1,Playback(continuing_call)

In the above example, Dial would exit with something like "200 
Completed" and the priority would match against the "200" part of 
that string and jump to extension "cont".  Similarly, "400 Failed" 
would jump to extension "fail".



JT



More information about the asterisk-dev mailing list