| Summary: | ASTERISK-07563: [patch] Allow a simple lookup for hint extensions | ||||
| Reporter: | Tilghman Lesher (tilghman) | Labels: | |||
| Date Opened: | 2006-08-19 23:44:30 | Date Closed: | 2008-12-10 16:37:57.000-0600 | ||
| Priority: | Minor | Regression? | No | ||
| Status: | Closed/Complete | Components: | Core/NewFeature | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) 20070314__simple_hint_lookup.diff.txt ( 1) 7767-updated.diff ( 2) pbx-branch-1.4-97753.diff ( 3) pbx-trunk-98436.diff | |||
| Description: | Currently, all hints must contain only expressions which do not depend upon a channel definition, since hints may be called without a channel. However, since hints are always context- and extension-specific, there should be a way to reference those indicated values when evaluating a hint. | ||||
| Comments: | By: Tilghman Lesher (tilghman) 2006-08-19 23:56:23 The simplest case for this is: exten => _XXX,hint,SIP/${EXTEN} which potentially saves hundreds of lines of hints. By: jmls (jmls) 2006-11-01 12:38:01.000-0600 nudge nudge .. By: Tilghman Lesher (tilghman) 2006-11-01 12:56:09.000-0600 jmls: not anytime soon. This need a bunch more work. By: jmls (jmls) 2006-11-01 12:58:43.000-0600 cool. just housekeeping. :) By: Tilghman Lesher (tilghman) 2006-12-10 11:46:34.000-0600 Lots more revisions, lots more testing. Now appears to work across reloads. By: Tilghman Lesher (tilghman) 2007-02-07 16:59:38.000-0600 To be clear, what this needs right now are people who are willing to set up a test environment with trunk and test this. By: Brett Nemeroff (brettnem) 2007-03-14 17:15:06 Well if you're going to do that, you might as well support a syntax like: exten => _XXXX,hint,${CUT(CUT(REALTIME(hints,exten,${EXTEN},:,^),:,5),^,2)} To allow the device name to come from anywhere.. What's the status of this? I can test it out.. By: Tilghman Lesher (tilghman) 2007-03-14 17:45:40 brettnem: you're certainly welcome to do whatever legal syntax you want. Yes, this still needs testing. By: Brett Nemeroff (brettnem) 2007-03-14 19:08:37 Well the problem is that it isn't interpreting the code.. Rather it's actualy looking for a device called ${CUT.... [Mar 14 18:08:30] DEBUG[13635]: devicestate.c:157 ast_device_state: Checking if I can find provider for "${CUT" - number: (null) If I use that line to set a variable it returns something like SIP/somedevice01 By: Tilghman Lesher (tilghman) 2007-03-15 02:09:30 Then you probably have unbalanced curly braces. What, exactly, are you using? By: Brett Nemeroff (brettnem) 2007-03-15 16:46:36 I'm actually doing the line as printed above: exten => _XXXX,hint,${CUT(CUT(REALTIME(hints,exten,${EXTEN},:,^),:,5),^,2)} That string itself works inside of a Set. It's possible that I just have the syntax wrong. If I use the {}s on the inside CUT is tries to interpret the REALTIME result as an asterisk command. I still feel that this question is particularly relevant to this bug because I think people interested in this bug will want to do crazy stuff like this. Thanks By: Tilghman Lesher (tilghman) 2007-03-16 13:55:41 Okay, this obviously needs a little more work, so I'm taking it out of testing status. Thank you for your extensive testing so far. By: Michael Gaudette (bluefox) 2007-08-09 09:06:49 Would this functionality allow me to use variables based on which device is looking for status? Example: I have 3 phones with SIP registrations that have 3 different ${ACCOUNTCODE}. Will I be able to do this: exten => _XXX,hint,SIP/${ACCOUNTCODE}-${EXTEN} So that phone1 checks SIP/account1-705 and phone2 checks SIP/account2-705 even though both are pointed to exten 705? I ask because if so, I will be keeping a close eye on this issue and will be glad to help test it. By: Tilghman Lesher (tilghman) 2007-08-09 10:00:44 No, you'd have to derive the channel name itself from the ${EXTEN} argument itself. Now you could retrieve the accountcode from a database by using the ${EXTEN}, but there must be a 1-to-1 (or many-to-1) mapping between the ${EXTEN} and a particular channel. By: Dmitry Andrianov (dimas) 2007-09-25 17:05:02 How specific hints suposed to be deleted once they are "instantiated" from "template" when adding callback? It looks like these will stay forever. also, (alhought it is offtopic) presence of ast_add_extension+ast_hint_extension pairs makes me think that addition of last extra parameter to ast_add_extension (ast_exten **return) is a good idea. By: Tilghman Lesher (tilghman) 2007-09-25 17:51:32 No, the way it should work is that at reload time, each generated hint is compared against the new list of patterns. If it still matches the pattern, it remains along with all of the watchers. If it matches no patterns, it is silently tossed. By: pj (pj) 2007-10-16 16:20:21 I'm trying your patch with this ael syntax: context linestates { hint(SIP/322) 322 => NoOP; hint(SIP/324) 324 => NoOP; hint(SIP/408) 408 => NoOP; hint(SIP/743) 743 => NoOP; hint(SIP/${EXTEN}) _ZXX => NoOP; } but seems, that is not working, 'core show hints' shows: _ZXX@linestates : SIP/${EXTEN} State:Unavailable Watchers 0 743@linestates : SIP/743 State:Unavailable Watchers 0 408@linestates : SIP/408 State:Idle Watchers 0 324@linestates : SIP/324 State:Idle Watchers 0 322@linestates : SIP/322 State:Unavailable Watchers 0 and when I tried subscribe to monitor extension eg. 777, it often crashes asterisk and on eyebeam this extension is offline all the time... monitoring others extension, from example above, is working fine... eyebeam 1.5.16 SVN-trunk-r85944M By: Tilghman Lesher (tilghman) 2007-10-17 09:39:09 Well, considering I haven't touched the code in 6 months, I'm surprised that the patch even still applies. By: pj (pj) 2007-10-17 10:43:35 it will be welcome to update, so we can test again to be ready for merge into trunk... many people will definitively welcome this feature in 1.6 ;-) By: snuffy (snuffy) 2007-12-07 17:40:15.000-0600 This does look like a very nice addition. Updated the diff, only one small part did not apply now fixed. By: Juan Carlos Castro y Castro (jccyc) 2007-12-21 10:49:05.000-0600 OK, did the same thing snuffy did, so it applies to Asterisk 1.4.16.1. I'm very much in need of this functionality. Haven't even tested it yet -- hope it works. By: Tony Plack (plack) 2008-01-11 13:57:46.000-0600 Applied this to branch/1.4 97753 Had to do alot of modificaions, was looking later create a diff for trunk, but I found a bug. If you do an "extensions reload" after phones have registered, the system goes into never-never land with gdb reporting that it is working on send.c in copying a string. Never comes back, but doesn't spike the CPU either. By: Tony Plack (plack) 2008-01-11 16:50:26.000-0600 Problem was where we called ast_add_extension and tried to pass a (void *)strdup into the data parameter. Removed the (void *) and it works great. I have modified the code to this in branch/1.4 to simplify and make the variables in the Application be evaluated at register time (when the hint extension is created. I will be posting a patch shortly against trunk for this function with these changes. We are now using this in a branch/1.4 production enviroment and it works well. Great idea. By: Tony Plack (plack) 2008-01-11 17:16:29.000-0600 I have successfully compiled against trunk 98436. The major difference that I modified from Corydon's change is that I moved the resolution of the Application variables into the ast_add_extension2 where he had removed them because they were stripping any ${EXTEN} from the hint. So now you can do thing like this: _45#XXXX,hint,Custom:${EXTEN:3:4}-${r-we-open} And the system will then generate a hint extension for 45ASTERISK-4874 and a variable for r-we-open=y of 45ASTERISK-4874,hint,Custom:5000-y This works well with the DEVSTATE code in trunk and the backport to 1.4 Good work Corydon. I love it. By: Juan Carlos Castro y Castro (jccyc) 2008-01-17 14:03:44.000-0600 Small bug: your two patches pbx-branch-1.4-97753.diff and pbx-trunk-98436.diff stop working if there's no global variables defined. This is due to the test AST_LIST_FIRST(&globals) which should be moved to wrap only the call to pbx_substitute_variables_varshead() and the subsequent assignment. Workaround: define some dummy local variable. By: Digium Subversion (svnbot) 2008-03-19 11:49:57 Repository: asterisk Revision: 109970 U trunk/CHANGES U trunk/main/pbx.c ------------------------------------------------------------------------ r109970 | file | 2008-03-19 11:49:57 -0500 (Wed, 19 Mar 2008) | 7 lines Add the ability to use a pattern match for a hint. (closes issue ASTERISK-7563) Reported by: Corydon76 Patches: 20070314__simple_hint_lookup.diff.txt uploaded by Corydon76 pbx-trunk-98436.diff uploaded by plack (license 365) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=109970 By: Digium Subversion (svnbot) 2008-03-19 11:50:53 Repository: asterisk Revision: 109971 _U branches/1.6.0/ ------------------------------------------------------------------------ r109971 | file | 2008-03-19 11:50:52 -0500 (Wed, 19 Mar 2008) | 14 lines Blocked revisions 109970 via svnmerge ........ r109970 | file | 2008-03-19 13:54:12 -0300 (Wed, 19 Mar 2008) | 7 lines Add the ability to use a pattern match for a hint. (closes issue ASTERISK-7563) Reported by: Corydon76 Patches: 20070314__simple_hint_lookup.diff.txt uploaded by Corydon76 pbx-trunk-98436.diff uploaded by plack (license 365) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=109971 | ||||