[Asterisk-Dev] Dev Meeting list

[Matthew Boehm]

Andrew Kohlsmith wrote:
> On April 28, 2005 11:59 pm, Matthew Boehm wrote:
>> What I think would work is having every app return different result
>> codes for different "happenings" during the app. It is then up to
>> the Asterisk manager to do the checking and jumping.
>
> You mean the Dialplan, right?

    Yes. It should not be the applications job to bounce around. It should
be the programmers job in the dial plan to bounce around.

> It's the same as any API, really.  0 for success, nonzero for some
> kind of error or condition that may need to be checked.

    Exactly. But each result needs to be well documented.

> I'd alter this a little.  result should be 0 for success, and copy
> ${DIALSTATUS} to the generic app result (${RES}?  ${?}?  we need
> something short).
>
> Dial's a bad example since it already has ${DIALSTATUS}, and also
> ${HANGUPCAUSE} for that matter.  My current hangup macro looks
> something like this:

    I would remove ${DIALSTATUS} and ${HANGUPCAUSE} all togehter and merge
them into ${RES}.


> Well I would also have pbx.c force ${RES} to the value of 0 before
> calling any application, but after variable substitution so that it's
> possible to do something like this:
>
> exten => _NXXXXXX,n,MyFunkyApp(${RES})
> exten => _NXXXXXX,n,NoOp(MyFunkyApp result was ${RES})
>
> and have MyFunkyApp() process the result of the app above it, and
> similarly for NoOp(), process the result of the app above it.

    Aye.

>> If the asterisk manager doesn't throw in a jump for a particular
>> result code, there needs to be some sort of 'catch all'.

    For instance, lets say MyApp() can possibly return 10 different ${RES}
results. But I as the dial plan programmer only check for 2 of these
results, I need to be able to say "any other ${RES}, do this.." instead of
checking for each.

-Matthew