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

[Tilghman Lesher]

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