[Home]

Summary:ASTERISK-01753: [post-1.0 discussion] [patch] Implementation of labels in the dialplan
Reporter:Tilghman Lesher (tilghman)Labels:
Date Opened:2004-06-03 16:19:48Date Closed:2004-10-03 10:52:09
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20040623__labels.diff.txt
Description:Labels may be specified in the dialplan with the following syntax:

exten[:label] => ...

and invoked in the dialplan with variable interpolation:

${LABEL(label)}


****** ADDITIONAL INFORMATION ******

This patch has been tested and is functional.
Comments:By: Mark Spencer (markster) 2004-06-03 17:34:22

This looks kinda like the existing "hint" functionality.
By: Olle Johansson (oej) 2004-06-09 11:47:40

Markster, please tell me more about the "hint" functionality!
By: Olle Johansson (oej) 2004-06-13 16:08:41

Read the source, still do not understand the "hint" functionality... Sorry. Markster, if you have time, please add some notes on the hint functionality.
By: Mark Spencer (markster) 2004-06-23 16:37:42

Hints provide an association with an extension.  While hints are specifically designed to convey the channels that are used by an extension, they could be used for other purposes as well.
By: Mark Spencer (markster) 2004-06-23 16:39:52

Of course you could also simply declare these in the [globals] section:

[globals]
LABEL1234=foo
LABEL1235=bar
.
.
.
[default]
exten => _XXXX,1,Noop(${LABEL${EXTEN}})
By: Tilghman Lesher (tilghman) 2004-06-23 17:42:32

Newest patch uploaded.  Here's an example from my own dialplan, using labels; I hope this clearly show why labels are desireable.

;
; 280 - Close shop
;
exten =>                280,1,DBPut(vcch/open=0)
exten =>                280,2,SetVar(ext=101)
; If this extension is here, set away (otherwise indicates alternate location; don't change)
exten:280getlocation => 280,3,DBGet(location=${ext}/location)
exten =>                280,4,GotoIf($[${location} = 1]?${LABEL(280closeshop)}:${LABEL(280loop)})
exten:280closeshop =>   280,5,DBPut(${ext}/location=0)
exten:280loop =>        280,6,SetVar(ext=$[${ext} + 1])
; Repeat for extensions 101 - 107
exten =>                280,7,GotoIf($[${ext} < 108]?${LABEL(280getlocation)})
exten =>                280,8,Playback(custom/officeclosed)
exten =>                280,9,Hangup
By: Mark Spencer (markster) 2004-06-24 09:47:20

Do you see a label as more of an alias for a priority or an alias for context/extension/priority?
By: Tilghman Lesher (tilghman) 2004-06-24 10:24:23

I see it as a complete alias for context/extension/priority.
By: Mark Spencer (markster) 2004-06-25 14:57:58

Would you be satisfied with a label that was for priority?  It would be extremely easy not only to implement, but to mix into the dialplan, something along the lines of:

exten => 100,1,Dial(Zap/1,20)
exten => 100,2,Goto(${DIALSTATUS})
exten => 100,20(NOANSWER),Voicemail(u6275)
exten => 100,30(BUSY),Voicemail(b6275)

Thoughts?  You could still do:

exten => 200,1,Goto(100,NOANSWER)
By: Tilghman Lesher (tilghman) 2004-06-25 16:00:43

While labels only for priorities are useful (local labels), it's also useful to have labels for context/extension/priority (global labels).

Would it be a problem to include both types?  Obviously, having labels which are local in scope (extension scope) is another advantageous feature.
By: Mark Spencer (markster) 2004-06-25 16:29:58

Having them associated strictly with extension priorities means that the searching is greatly simplified and the datastructures need not be extended beyond an extremely trivial level.
By: Tilghman Lesher (tilghman) 2004-06-25 16:41:38

I'm actually considering another feature right now that would make searching trivial anyway, so I don't think that's a reason for rejecting global labels.

I'd opt for the more functional of the two, if we can only implement one.
By: twisted (twisted) 2004-07-23 20:34:08

Is there any interest in this still?  If so, this is an update request.

-HouseKeeping
By: Tilghman Lesher (tilghman) 2004-07-23 20:47:26

The patch is and has been ready to be committed.
By: Mark Spencer (markster) 2004-07-24 16:48:19

Yah, at this point it's a question of deciding whether this is really how labels should be done.

Generally, I have positive feelings about the concept of labels, but labels would be greatly simplified if they could be tied to extensions as in the example I've given.

In any case, nothing this extreme should come in before 1.0 I don't think and the discussion should probably be resumed after that point.
By: Tilghman Lesher (tilghman) 2004-07-25 16:49:08

I disagree that labels would be simpler if tied to extensions.  In that case, we're talking about labels which are limited in scope, so the complexity of finding the right label is reduced, while increasing the complexity of scope
(i.e. now you're keeping track of context and extension in scope, to ensure that labels from one context/extension don't conflict with labels from another context/extension).

And if you don't limit the scope, then you have global labels that need to be specially-named to apply only to a certain context/extension, to ensure that a similarly named label can't apply elsewhere. That's essentially just like the implementation here, except with more disadvantages (one disadvantage being that you can't jump around from one extension to another).

BTW, I'd be happy to add local labels, possibly with the dereference syntax as ${LOCAL(string)} to this patch (non-conflicting with global labels).  Or another possiblity might be to rename the current implementation as GLABEL (global label) and have local labels as LABEL, possibly even LABEL checking for a local label first, then using a global label as a fallback.
By: Mark Spencer (markster) 2004-07-25 17:17:25

You're missing my concept.

My concept is that a label is (within a single extension) an alias for a given priority.

You may reuse labels from one extension to another.
By: Tilghman Lesher (tilghman) 2004-07-25 17:43:04

No, I'm not missing your concept at all.  In order for labels to be specific a certain extension, you need to enforce scope (i.e. label "xxx" applies only to context "yyy" and extension "zzz").  So the complexity moves from the label definition to the scope definition, which doesn't reduce complexity (just moves it around).
By: Mark Spencer (markster) 2004-07-25 17:45:32

You clearly ARE misunderstanding it, or you wouldn't be making the assertions you are making!

There is NO enforcement of scope.  You use a label interchangably with a priority in the dialplan.  End of story.  Nothing more, no new structures, and only the most trivial change to the existing structure.
By: Tilghman Lesher (tilghman) 2004-07-25 17:46:56

Or more explicitly, you have:

label xxx, applies to context yy1 and extension zz1
label xxx, applies to context yy2 and extension zz2
label xxx, applies to context yy3 and extension zz3

You have the same level of complexity, because you're enforcing the scope to apply only to the specific context/extension.
By: mochouinard (mochouinard) 2004-08-08 01:39:48

I can't wait to see who will comeup with the documentation of that label thing...

I would suguest we keep the exten => NUMBER,Priority, method, Since alot of scripts is base on it.
By: Tilghman Lesher (tilghman) 2004-08-08 02:20:26

Uh, not adding features because somebody has built a script that handles a configuration in a non-extensible way is not a very good design reason.  If someone doesn't design their scripts in an extensible way, it's their own fault.
By: Mark Spencer (markster) 2004-10-03 00:20:09

Implemented labels in dialplan, in conjunction with new "n" and "s" priorities allowing much much cleaner dialplans (see updated extensions.conf.sample)
By: Russell Bryant (russell) 2004-10-03 10:52:09

not included in the 1.0 branch