[sr-dev] Dialplan extension with redis backend

[Javier Gallart]

Helo Daniel

we intend to keep all data in redis. The reason is that we have a pretty big
dialplan and it takes a while to load the table into shared memory. If we
keep it in redis we can make the changes directly; a change in one entry is
just one command, no reload needed.

Regards

On Tue, Apr 10, 2012 at 10:49 PM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:

>  Hello,
>
> do you want to use redis as a replacement for storing the dialplan rules
> in shared memory?
>
> Or just a replacement for the storage backend? So the rules are loaded
> from redis to shared memory.
>
> Cheers,
> Daniel
>
>
> On 4/10/12 1:36 PM, Javier Gallart wrote:
>
> Hello all
>
>  we've been thinking of extending the dialplan module for using redis as
> its backend. These are our thoughts of how we to use it.
> For a regular sql backend, each table has 4 main fields:
> dpid,match_exp,subst_exp,repl_exp
> dpid is given as argument to the only function exported by the module
> (dp_translate). There are two additional arguments to the function, the
> source variable upon which the lookup and translation are to be performed
> and the variable where the transformation will be stored. There are no
> tables/rows in redis, so the approach we were thinking -there are many- was
> using a hash for each pair (dpid,match_exp).
> An example might help:
> Let's say we have this row in potsgres:
> dpid|match_exp|subst_exp|repl_exp
> 1  | ^34 | ^34(.*) | \1
>
>  According to this approach it would translate into this redis structure:
> key = 1:^34
> field 1 name = subst_exp ; value = ^34(.*)
> field 2 name = repl_exp ; value = \1
>
>  The field names could be configurable as module parameters, and we could
> add "redis" and driver in the dburl parameter.
>
>  It would be great to now the opinions of the list about this approach,
> since there are several other ways to accomplish this:
>
>  -"by hand" from the kamailio script
> -LUA
> -Implementing a new module
>
>  We would be happy to implement it once there is an agreement on how to
> proceed. As far as I see it, several modules could be extended in a similar
> way.
>
>  Thanks in advance
>
>  Javi
>
>
>
>
> _______________________________________________
> sr-dev mailing listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> --
> Daniel-Constantin Mierla
> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germanyhttp://www.asipto.com/index.php/kamailio-advanced-training/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120411/ba4eca4a/attachment.htm>