[sr-dev] Dialplan extension with redis backend

[Daniel-Constantin Mierla]

Hello,

how do you plan the operations to be done? Fetch all the rules per dpid 
in private memory at runtime, compile the regexps and then start 
applying them?

 From your proposal, the key can be practically anything, can you fetch 
redis records by a regexp/prefix matching over the key?

Cheers,
Daniel

On 4/11/12 9:29 AM, Javier Gallart wrote:
> 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 <mailto: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 list
>>     sr-dev at lists.sip-router.org  <mailto:sr-dev at lists.sip-router.org>
>>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>     -- 
>     Daniel-Constantin Mierla
>     Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
>     http://www.asipto.com/index.php/kamailio-advanced-training/
>
>

-- 
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://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/2b7875c2/attachment.htm>