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

[Adam Goryachev]

asterisk-users-admin at lists.digium.com <> wrote:
> At 8:53 PM -0600 1/14/04, Steven Critchfield wrote:
>> On Wed, 2004-01-14 at 14:12, Jeremy McNamara wrote:
>>>  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.
>> 
>> Hmm, F would be good, possibly B also. I could see a good case for
the
>> lead digit for a pattern doing a goto to a context that could define
>> those for outbound calls. 
>> 
>> [normal_extensions]
>> exten => 9,1,Goto(Extended_out,s,1)
>> 
>> [Extended_out]
>> exten => s,1,Playtones(dialtone)
>> 
>> exten => F,1,background(Failed)
>> exten => F,2,hangup
>> 
>> exten => B,1,congestion
>> 
>> exten => _NXXXXXX,1,Dial(Zap/g2/${EXTEN})
>> 
>> 
>> This example tightly controls the B and F special extensions to a
>> specific dial in the context. --
>> Steven Critchfield <critch at basesys.com>
> 
> That's a step in the right direction, I suppose, but we've already
> got applications that break this model (ENUM lookups, as an example,
> have a third return state of +51 on successful tel: lookups.)  As we
> get more sophisticated applications, we start crippling ourselves
> just to stick with "the way it's always been."
> 
> I see sanity only in one of two paths:
> 
>    - eliminate exceptions; reduce possible returns from an application
> to either Success, Fail or Busy, and hand back any other possible
> values by setting some arbitrary string
> 
>    - have some method that allows controlled Goto's based on the
> numeric failure code, and then have every application list it's
> possible failure codes in the "show application <blah>" summary

I wrote an email this morning which is 'awaiting moderator approval' ..
It would be nice if SOMEONE was the moderator, heck, even I would
volunteer to do that... It's damn annoying when you happen to send from
a non-subscribed email address....

Anyway, basically what I said is your above option 2, each application
can define what their 'exit codes' are, whether failure or success. In
this way, we basically copy the way bash and most programming languages
are written. (ie, a function/program returns a code to describe what
happened). In bash this happens to be $?. So, pick a variable name, and
use that to return an arbitrary number defined in the show application
output.

Then create a app or something which will allow for case statements.
Maybe like:
Case(checkval,val1=context|ext|prio,val2=prio2,val3....)

Regards,
Adam

 --
Adam Goryachev
Website Managers
Ph:  +61 2 9345 4395                        adam at websitemanagers.com.au
Fax: +61 2 9345 4396                        www.websitemanagers.com.au