About -> News -> New types of scripting routes

NEW additions to configuration file routes

The configuration possibilities for OpenSIPS have been enriched with new additions related to the routes. The intention was to extend the action range and also to make the configuration file easier to write and read.

Named routes

The routes can have string names also, not only numerical IDs as it was until now. This way the routing flow will be more meaningful and easier to understand and follow. The backward compatibility was kept - and you can also use number IDs as route names. Ex:

----
route[relay] {...}

route{...; route(relay); ....}
----

STARTUP route

startup_route is a new type of route, different to the routes that existed until now (route, onreply route, failure route, branch route, local route) because they are not triggered at the receipt of a SIP message but do independent processing. The startup_route - called only once when the server is started and before the listener processes are created. You can configure here some initialization actions to ease up the future processing. For example, you could take some values from database and store them in cache or in shared memory pseudovariables to have faster access to those values when needed. Ex:

-----
startup_route {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
    cache_store("local", "rule1", "$avp(i:100)");
}
-----

TIMER route

timer_route is also a new type of route, also triggered by a non related SIP message event - it is called on a timer basis at a given interval. This can be used to configure some periodical actions that do some data refresh actions for example. The time interval is given after the name of the route separated by comma and it represents a value in seconds. Ex:

-----
timer_route[gw_update, 300] {
   avp_db_query("select gwlist where ruleid==1",$avp(i:100));
   $shv(i:100) =$avp(i:100);
}
-----

Per branch "onreply_route"

One new type of onreply_route was added: per branch on reply route. Sometimes it is useful to know in a reply route to which branch it belongs to. Now this is very simple to achieve - if you call t_on_reply("name") from a branch route then only the replies for that branch will go through onreply_route[name]. Ex:

-------
branch_route[1] {
    if ($rU=="alice")
        t_on_reply("alice"); # the "alice" reply route
                             # is set only for second branch
}


onreply_route[alice] {
    xlog("received reply on the branch from alice\n");
}