SHOP_NAME=Chicago works but also stores the DTMF result. The Variable SHOP_NAME contains “Chicago=3” the number 3 is the DTMF result. Not exactly the desired result. The desired result is SHOP_NAME contains the string “Chicago” without the DTMF result.
This is rather tricky coding, as you are trying to rely on the side effects of a function used in a right hand value (RV) context to create a name to be used in a left hand value context. I suspect that SET() cannot be used in an RV context, (it is only meaningful for “writing” to the function) so the whole construct is doomed, but if this works in the same way as it would in an LV context, you should note that […] doesn’t use dialplan variable names directly, the actual variable names have “DYNAMIC_” prefixed. Also, I’d not expect SET to return anything meaningful in an RV context so I’d expect the code to try and set a variable with an empty name, although that might be suppressed in the same way as not specifying anything is suppressed.
Although I haven’t tried, and haven’t dug into the code, to make sure that a read on SET() really would fail, this does look like the sort of code that I’d expect an LLM to propose.
There are multiple examples that have a SET in them when assigning values to SQL DB from Dynamic Routing. One or two from Lorne Gaetz. However this exact use case is not discussed so perhaps using SET in my scenario is not the correct strategy.
It looks like SET() is actually only usable in an RV context, even though it is only used for its side effects, so the general principle might work, except that one would need to set the underlying channel variable name, including “DYNAMIC_”. I’m still queasy about whether it returns an empty direct value, and whether FREEPBX handles that well.
I think Asterisk’s context of a settable function goes against the mathematical concept of what a function is, but having a set side effect as the main intended effect of a function seems to go even further.
Although the FreePBX documentation says that you can read dynamic route variables by their underlying dialplan variable name, it doesn’t explicitly say you can go the other way, although I can’t think of any reason why that wouldn’t work.
