Hello,
a new module was committed in trunk, to be released as 1.5.0 - the plan at: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x
The rtimer module allows to execute route block on timer. It can create new processes that will do the timer execution of the routes or use existing timer. There can be multiple timers and each timer can execute multiple route blocks.See readme at: http://kamailio.org/docs/modules/devel/rtimer.html
Such features is useful if you want to do periodic jobs in your service
1) clean a database were you store temporary data - e.g., delete entries older than 2 hours
modparam("rtimer", "timer", "name=ta;interval=10;mode=1;") modparam("rtimer", "exec", "timer=ta;route=8")
route[8] { sql_query("ca", "delete from tmp where timeval<$TS-3600","ra"); }
2) save statistics in database so you can build graph, etc... http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#statistics
route[8] { sql_query("ca", "insert into kamailio_stats values ($stat(...), ...)","ra"); }
3) Along with another pretty new feature - sending sip requests from config file: http://lists.kamailio.org/pipermail/users/2009-January/021426.html
you can implement keep-alive/syncronization mechanisms within your farm of sip routers.
Any other ideas? Let's see the best one for using the new stuff from uac and the rtimer module...
Cheers, Daniel
Wouldn't it be more elegant to allow this to be done through MI so that people could just invoke certain routes via cron jobs?
That way, one gets the benefit of running jobs that have visibility into the namespace and state of the proxy and access to script constructs without having to bother with an internal task scheduler.
Daniel-Constantin Mierla wrote:
Hello,
a new module was committed in trunk, to be released as 1.5.0 - the plan at: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x
The rtimer module allows to execute route block on timer. It can create new processes that will do the timer execution of the routes or use existing timer. There can be multiple timers and each timer can execute multiple route blocks.See readme at: http://kamailio.org/docs/modules/devel/rtimer.html
Such features is useful if you want to do periodic jobs in your service
- clean a database were you store temporary data - e.g., delete entries
older than 2 hours
modparam("rtimer", "timer", "name=ta;interval=10;mode=1;") modparam("rtimer", "exec", "timer=ta;route=8")
route[8] { sql_query("ca", "delete from tmp where timeval<$TS-3600","ra"); }
- save statistics in database so you can build graph, etc...
http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#statistics
route[8] { sql_query("ca", "insert into kamailio_stats values ($stat(...), ...)","ra"); }
- Along with another pretty new feature - sending sip requests from
config file: http://lists.kamailio.org/pipermail/users/2009-January/021426.html
you can implement keep-alive/syncronization mechanisms within your farm of sip routers.
Any other ideas? Let's see the best one for using the new stuff from uac and the rtimer module...
Cheers, Daniel
On 01/16/2009 03:45 PM, Alex Balashov wrote:
Wouldn't it be more elegant to allow this to be done through MI so that people could just invoke certain routes via cron jobs?
you can do that if fits your needs.
That way, one gets the benefit of running jobs that have visibility into the namespace and state of the proxy and access to script constructs without having to bother with an internal task scheduler.
But sometime you need access to the internals of kamailio (openser) and then you can use this one. It can be a standalone process, so it won't affect the rest of processing.
Cheers, Daniel
Daniel-Constantin Mierla wrote:
Hello,
a new module was committed in trunk, to be released as 1.5.0 - the plan at: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x
The rtimer module allows to execute route block on timer. It can create new processes that will do the timer execution of the routes or use existing timer. There can be multiple timers and each timer can execute multiple route blocks.See readme at: http://kamailio.org/docs/modules/devel/rtimer.html
Such features is useful if you want to do periodic jobs in your service
- clean a database were you store temporary data - e.g., delete
entries older than 2 hours
modparam("rtimer", "timer", "name=ta;interval=10;mode=1;") modparam("rtimer", "exec", "timer=ta;route=8")
route[8] { sql_query("ca", "delete from tmp where timeval<$TS-3600","ra"); }
- save statistics in database so you can build graph, etc...
http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#statistics
route[8] { sql_query("ca", "insert into kamailio_stats values ($stat(...), ...)","ra"); }
- Along with another pretty new feature - sending sip requests from
config file: http://lists.kamailio.org/pipermail/users/2009-January/021426.html
you can implement keep-alive/syncronization mechanisms within your farm of sip routers.
Any other ideas? Let's see the best one for using the new stuff from uac and the rtimer module...
Cheers, Daniel
Daniel-Constantin Mierla wrote:
That way, one gets the benefit of running jobs that have visibility into the namespace and state of the proxy and access to script constructs without having to bother with an internal task scheduler.
But sometime you need access to the internals of kamailio (openser) and then you can use this one. It can be a standalone process, so it won't affect the rest of processing.
Yeah, I know. But from a low coupling / high cohesion design standpoint, it seems better to deputise ancillary things like task scheduling outside of the proxy -- especially if a lot of these things are anticipated to be cleanup jobs on external databases anyway. Or maybe you just used those as examples without having a particular need in mind.
On 01/16/2009 03:58 PM, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
That way, one gets the benefit of running jobs that have visibility into the namespace and state of the proxy and access to script constructs without having to bother with an internal task scheduler.
But sometime you need access to the internals of kamailio (openser) and then you can use this one. It can be a standalone process, so it won't affect the rest of processing.
Yeah, I know. But from a low coupling / high cohesion design standpoint, it seems better to deputise ancillary things like task scheduling outside of the proxy -- especially if a lot of these things are anticipated to be cleanup jobs on external databases anyway. Or maybe you just used those as examples without having a particular need in mind.
There were samples, my real usage is more complex :-) ... sip farm server inter-communication ... think of what one can do with: - htable - sqlops - uac - rtimer - + the rest of sip routing features in kamailio (openser)
Cheers, Daniel
On 01/16/2009 03:58 PM, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
That way, one gets the benefit of running jobs that have visibility into the namespace and state of the proxy and access to script constructs without having to bother with an internal task scheduler.
But sometime you need access to the internals of kamailio (openser) and then you can use this one. It can be a standalone process, so it won't affect the rest of processing.
Yeah, I know. But from a low coupling / high cohesion design standpoint,
also, worth to mention that this does not add any overhead to the core of the proxy. It is just a module, if one needs it, can use, otherwise just don't load...
1.5.0 includes a lot of work in making the core slimmer, moving towards the core framework design planned to get with sip-router.org project.
Cheers, Daniel
it seems better to deputise ancillary things like task scheduling outside of the proxy -- especially if a lot of these things are anticipated to be cleanup jobs on external databases anyway. Or maybe you just used those as examples without having a particular need in mind.
-
Alex Balashov -
Daniel-Constantin Mierla -
Daniel-Constantin Mierla