Thank you for the first tip. The already defined pseudo variable is a good alternative for the "src_ip" keyword. It is working fine.
However, the alternative variables solutions do not offer the same flexibility in definition as $var. Shared variables can not be composed from other variables + text. I fear AVP variables are not really different....
I will use the combined method of 'customer variables' and route-specific '$var-variables'. Although it requires multiple definitions, the given flexibility is the best.
Klaus
On Monday 22 February 2010, Alex Balashov wrote:
What would be even more useful is if these values could be used as input to modparams. Are modparam values evaluated for PV spec?
I don't think that modparam evaluates PVs at the moment, i've gave it a short try, and only got a syntax error.
With regards to the question of the OP, if you need to access this variable only in one place then perhaps you could just ommit the temporary definition. If you only have the problem of visibility, what about using another type of storage, like Alex suggested, '$shv' or perhaps '$avp'?
If the values need to be loaded from a database and postprocessed somehow, or something like that, then this problem could also be elegantly solved if there existed an additional type of 'route' that was not module or event-specific, e.g. not like route[htable:mod-init], but was tied to Kamailio booting up, like an 'onload_route'. Was there not a little talk of this some time ago?
You probably could already use the htable specific route as generic startup route, you only need to load the module for this to work. But a generic solution would be indeed better. I think that Daniel extended the routing framework some time ago in a way that it would allow to easier specify functionality like this, but i did not looked into the details so far.
Henning