| Summary: | ASTERISK-03647: extensions.conf: linked list priorities | ||
| Reporter: | dnum (dnum) | Labels: | |
| Date Opened: | 2005-03-07 22:43:34.000-0600 | Date Closed: | 2011-06-07 14:04:52 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | The current method for selecting the next extension to execute is burdonsum on people writing long extensions, if they want to insert and delete extensions. You could add the following syntax to your API: exten => extension,priority,Command(parameters)[,nextpriority] or exten => extension,priority[,nextpriority],Command(parameters) where 'nextpriority' specifies the name of the next priority to execute after this one's completion | ||
| Comments: | By: Clod Patry (junky) 2005-03-07 22:44:55.000-0600 isn't always N+1 or N+101 ? why not using Goto application or an AGI application? edited on: 03-07-05 22:51 By: twisted (twisted) 2005-03-08 02:15:05.000-0600 We currently have a system for this... exten => s,1,NoOp(priority one, and I want to go to priority labeled 'blah') exten => s,n,Goto(blah) exten => s,n,NoOp(Not where I want to go) exten => s,n,NoOp(still not where I want to go) exten => s,n(blah),NoOp(The call will land here, which is where I want to go) is this current method not sufficient? By: Russell Bryant (russell) 2005-03-11 01:30:13.000-0600 I think the combination of the 'n' priority and priority aliases address these issues ... | ||