[Asterisk-Dev] Dev Meeting list

[John Todd]

At 8:37 AM +1000 on 4/29/05, Edwin Groothuis wrote:
>On Thu, Apr 28, 2005 at 03:00:55PM -0500, Brian West wrote:
>>  Getting rid of n+101 globally.
>>
>>      Need list of apps that use n+101
>
>For a client I have made a function which is called like this:
>
>     exten => 700,1,EnumLookupNG(1234567890,10,20,30,40)
>
>The first one is the number to lookup, the next ones are the
>priorities to jump to for the relevant types returned by the function.
>
>I can imagine that you have the same for other functions which can
>branch the flow of the program.
>
>No more frustrations when you add a step in front of this and having
>to recalculate all your jump points!
>
>Edwin
>
>--
>Edwin Groothuis      |            Personal website: http://www.mavetju.org
>edwin at mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/


Interesting method, but not quite consistent across all applications 
considering many applications have many arguments they take, and 
adding priorities into the argument list seems a bit "busy".  Here's 
a rehashed message from long ago (and look!  I even used ENUM as the 
example!) - perhaps it may be of some use in this thread:


John Todd   asterisk-dev at lists.digium.com
Fri, 28 Nov 2003 21:49:28 -0500

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