Summary:ASTERISK-20639: Dynamic hints are not properly initialized when the extension contains an underscore.
Reporter:Steven Wheeler (swheeler)Labels:
Date Opened:2012-10-31 12:46:58Date Closed:2012-11-12 14:21:21.000-0600
Versions: Frequency of
is related toASTERISK-07563 [patch] Allow a simple lookup for hint extensions
Environment:Attachments:( 0) asterisk-20639-dynamic-hint-underscore.diff
( 1) bugreport.txt
Description:We use dynamic hints with a func_odbc call to load the hints from a database.  However, when the extension contains an underscore the func_odbc call is not evaluated.

Our hint context:
exten => _[+A-Za-z0-9*#].,hint,${READ_BLF_PHONE_LIST(${EXTEN})}
When we look up the hint for extension johnDoe we get something like:
Hint: SIP/phoneA&SIP/phoneB

But when we look up the hint for extension john_doe we get:

As you can see the variables are not even being evaluated.  If there is any more information you need to debug this please let me know.
Comments:By: Rusty Newton (rnewton) 2012-11-06 17:34:05.516-0600

I didn't even realize you could use '_' in an extension name...   Your dialplan pattern doesn't appear to account for the '_' character. Let us know how fixing that affects it.

Does it behave the same if you make an explicit extension rather than a pattern match for a hint with an underscore in the name (even if you still pull it from the database)?

Can you provide a VERBOSE and DEBUG log set to at least 5 captured during the time the hint is being pulled?

Can you also provide the READ_BLF_PHONE_LIST() function code so we can better understand what is going on inside there?

By: Steven Wheeler (swheeler) 2012-11-07 09:45:22.429-0600

Adding an underscore to the pattern makes no difference.  The pattern only seems to be applied to the first character and the dot matches anything.  Making it an explicitly defined extension in the blf context does not fix the problem either.

I will attach the full log for you to check out.  Here are the contents of the func_ODBC call:
readsql=SELECT phone_list FROM Blf_Phonelists WHERE CONCAT(company_id,'-',username)='${SQL_ESC(${ARG1})}'

By: Steven Wheeler (swheeler) 2012-11-07 09:47:28.878-0600

The hint lookup is done at line 3589 or timestamp '2012-11-07 09:34:01'.  Let me know if you need any more information.

By: Michael L. Young (elguero) 2012-11-07 11:03:27.223-0600

Rusty, I see in the code where it checks if the extension contains an underscore and if it does it will not evaluate the variables and global variables.

My question is whether or not that check should be removed or not, or, if it should be only checking that the extension doesn't start with the underscore.

By: Michael L. Young (elguero) 2012-11-07 20:03:00.796-0600

Give this patch a try.  

Basically, it changes from checking if the extension contains an underscore to checking if the extension starts with an underscore.  If it starts with an underscore, we do not create the hint.

By: Steven Wheeler (swheeler) 2012-11-08 09:05:34.727-0600

That patch fixes the issue for me.  What are the odds of getting it in the 1.8 branch?  Also, I would like to note that this isn't a minor bug as it frequently causes queue members to become unavailable and stop receiving calls which really upsets our end users.

By: Michael L. Young (elguero) 2012-11-08 17:38:28.389-0600

Steven, I will submit the patch for review and then once it is given the okay, I will get it into the 1.8 branch.

The reason why I downgraded the severity to Minor is because there is a workaround; don't name extensions with an underscore in them.  For that reason, I downgraded it.

By: Steven Wheeler (swheeler) 2012-11-12 15:49:39.697-0600

Thanks for the quick fix on this.