[Asterisk-Users] Re: Proposed solution for exit code priority jumps

[John Todd]

This week has been very productive and has shown a huge leap forward 
in Asterisk development.  The creation of the new concepts of an 
"unstable" branch of the code will, I believe, make for a better 
development environment in the long run.

With that in mind, I'm going to do something I only infrequently do, 
which is to re-post something in it's entirety and look for comments 
again instead of just posting the URL.  I'm getting very tired of the 
current jump-on-error method of priority control and error handling, 
and I think it's time for something a little more meaningful and 
robust.  Now that there will soon be the concept of "unstable" code, 
I think large ideas like this might see the light of day in the near 
future.

I realize this is a major code shift, since it would require work in 
pretty much every single application.  It's easy for me to talk about 
this since I can't accomplish such a task.  However, without 
attention now, this may never be solved, which would be a pity 
because it's a real crimp in the style of anyone doing more than 
trivial dialplan manipulation - anyone doing cascading dial failovers 
will attest to that.

Please look at and comment upon method #1 logic and syntax shown 
below; I think method #2 ("alternate method") is a bit too radical.

Now, back to soundfile clipping...

JT


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