[Asterisk-Dev] Re: [Asterisk-Users] Call completion/error codes and extensions.conf call flow

[Tilghman Lesher]

On Tuesday 13 April 2004 22:53, John Todd wrote:
> At 11:06 PM -0500 on 4/6/03, Tilghman Lesher wrote:
> >On Sunday 06 April 2003 14:09, John Todd wrote:
> >>  There was a conversation last night on the IRC channel between
> >>  myself, Corydon76, citats, and kram on the ability of a call
> >>  process to access the error (or success?) codes underlying a
> >>  call.  I'm uncertain if anything came out of it, but I'll
> >>  re-hash here to solicit other comments.
> >>
> >>  My idea: I'd like to be able to get to error codes when a call
> >>  passes through some kind of action (with perhaps the exception
> >>  of "Trying" or other "non-end-of-message" results) so that I
> >>  can play error messages or take actions that are appropriate
> >>  to the event.  As an example, currently Asterisk only supports
> >>  "busy" or "unavailable" call codes back from any channel type.
> >>   However, chan_sip can provide a large array of codes that are
> >>  more meaningful, such as "403 Forbidden" or "480 Temporarily
> >>  unavailable" which can be more useful for both my internal
> >>  logging as well as can trigger an appropriate recording to be
> >>  played back to the user.  Why code individual cases inside of
> >>  chan_blah when this can be extracted to allow the admin to
> >>  handle them as required?
> >>
> >>  Two solutions were discussed, one method using an application
> >>  and the other simply setting a channel variable.
> >>
> >>  METHOD 1:
> >>  Corydon76 suggested creating an application that handled the
> >>  redirection of the call process flow.  This would look
> >>  something like this:
> >>
> >>  OnResultGoto(201:+100,405:+200,480:+250)
> >>
> >>  where "201", "405", and "480" are the numeric response codes
> >>  corresponding to some useful error message from the channel.
> >>  This would be called immediately the Dial application.  Jumps
> >>  would be done within the existing context, to the priority X
> >>  within the same context where X is represented by "+X".
> >
> >Here's the application and the patch needed in the pbx code to
> >support the result code accessed from the application.  In
> >addition to the relative branches mentioned in the channel, I
> >also made absolute branches work (in the usual [[con]|ext]|pri
> >format).
> >
> >Again, untested code.
> >
> >-Tilghman
>
> [programs included in
> http://lists.digium.com/pipermail/asterisk-users/2003-April/009816.
>html ]
>
> Did anything ever happen with these (IMHO) very useful little
> patches/programs?  If not, you may consider submitting to the
> bugtracker.  I haven't heard of any new discussion about processing
> result codes in some sane way; this seems to be the best so far.  I
> am ashamed to say I haven't tested these, but came across them in
> reviewing my inbox.

I scrapped the idea.  No further work has been done on it, and even my
cvs checkout has been backed out of those changes.

-Tilghman