[Kamailio-Users] Kamailio 3.0.0: configuration request regarding VARIABLES usage (custom variables + $var(x))

[Daniel-Constantin Mierla]

On 02/22/2010 12:52 PM, Henning Westerholt wrote:
> 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.
>    

This is true. Most of the pseudo-variables will require a SIP message to 
be evaluated (not in this particular case).

Module parameters can be evaluated at startup only if the developer did 
it inside modparam setting function or in mod init. Otherwise is just 
setting the int/str value.


>>> 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.

Perhaps the event_route[htable:mod-init] can be moved to a more common 
used module and perhaps renamed to event-route[config:mod-init]. Right 
now it does not depend at all on htable module.

However, it is important to know when is needed to execute the event 
route. The 'mod-init' is executed after all modules were initialized (so 
htables were defined, data was loaded in cache from db, a.s.o).

We can add new event routes, to hook in different steps of 
initialization, like child init, modparam, etc.


>   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

Adding an event route is pretty simple, no need to touch the core and 
config syntax. For example, executing event_route[config:child-init] 
would be:

static int child_init(int rank)
{
     struct sip_msg *fmsg;
     struct run_act_ctx ctx;
     int rtb, rt;

     LM_DBG("rank is (%d)\n", rank);
     if (rank<=0)
         return 0;

     rt = route_get(&event_rt, "config:child-init");
     if(rt>=0 && event_rt.rlist[rt]!=NULL) {
         LM_DBG("executing event_route[config:child-init] (%d)\n", rt);
         if(faked_msg_init()<0)
             return -1;
         fmsg = faked_msg_next();
         rtb = get_route_type();
         set_route_type(REQUEST_ROUTE);
         init_run_actions_ctx(&ctx);
         run_top_route(event_rt.rlist[rt], fmsg, &ctx);
         if(ctx.run_flags&DROP_R_F)
         {
             LM_ERR("exit due to 'drop' in event route\n");
             return -1;
         }
         set_route_type(rtb);
     }
     return 0;
}

In this case, a fake SIP message is built and given to event route 
actions so all functions that are allowed to be executed in 'route' can 
be used in event route. If you don't need that, you can omit some lines 
from the snipped above.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/