[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