asterisk users - Jan 2004 - Re: Proposed solution for exit code priority jumps

Hi John,

First, I have not much experience dealing with complex dial plans. But since
you asked, thought of some feedback.

In my opinion .conf files should be kept as simple as possible. It should
provide straight forward and simple manipulations to simple & common
applications. If more complex manipulations are necessary, then those
scenarios could be built using scripts. Therefore, I think a structured
scripting implementation would be an option here. You may take a look at SER
and see how scriptic it's config files are. It is not simple but very
logical. So why patch what we have with another hack, which two will find
limitations. Instead, go for a more flexible script based dial plan.

Now If I have to choose one of two options you mentioned below, I would pick
the first one.

Cheers

SW


At 9:49 PM -0500 11/28/03, John Todd wrote:
>
>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