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

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

> 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.
John,

Absolutely no disrespect intended or implied (to you or anyone)...

I'd vote for method #1, however...

We both know there are probably less then a dozen active developers that
have the knowledge/exerience to address it, and their plates are obviously
very full. The rest of us don't have the skills to participate in the
development even if we could devote the time. Lobbying them directly 
with some form of architectural change document and obtaining their buy-
in "might" see some results over time.

Since there seems to be more then one topic like this lurking, it would
appear a more formal forum for such proposals would be a Good Thing.
Maybe that could be tied in some how with the movement towards cycling
stable releases.

Rich

John Todd wrote:
> 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.

We were talking in the conf the other day about possibly creating a 'F' 
extension for 'failure'.  I'm not sure if this is even remotely
close to
what your talking about or not.

Just my 2 pesos,

Jeremy McNamara

On Tuesday 13 January 2004 20:48, John Todd wrote:
> 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.
I have a third solution, which I have discussed with several other
developers, so I'll hash it out here:

We'll define several trappable variables, which can be extended at any
time.  Each application can choose to implement each one in terms of an
error label to goto on any particular condition or to simply return a
generic code and not allow a particular error condition to be handled.

For example, we might define the channel variables TRAP_HANGUP,
TRAP_BUSY, and TRAP_NOANSWER.  Each channel variable would
be defined to a label, which is at least a priority, possibly an
extension and priority, or context, extension, and priority, via the
usual syntax:  [[context|]extension|]priority.

When an application wishes to allow a particular error code to be
caught, it may lookup the appropriate channel variable.  If it exists
and is parsable into a label, then that context, extension, and priority
are set to be next in the dialplan and the application simply returns 0.
If the variable does not exist or is not parsable, then the generic
methods should be used (e.g. priority + 1 for unavailable; priority +
101 for busy).

This will allow for unlimited numbers of possible error or branch
conditions to be caught, without catching undesirable conditions.
There should probably be a generic function that can be called
to do the parsing and extension branching for each appropriate
condition, e.g. ast_app_handle_branch("TRAP_BUSY").

-Tilghman