With that in mind, I'm going to do something I only infrequently do, which is to re-post something in it's entirety and look for comments again instead of just posting the URL. I'm getting very tired of the current jump-on-error method of priority control and error handling, and I think it's time for something a little more meaningful and robust. Now that there will soon be the concept of "unstable" code, I think large ideas like this might see the light of day in the near future.
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.
Please look at and comment upon method #1 logic and syntax shown below; I think method #2 ("alternate method") is a bit too radical.
Now, back to soundfile clipping...
JT
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.
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
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
