[sr-dev] Dialplan extension with redis backend

Javier Gallart jgallartm at gmail.com
Thu Apr 12 17:24:35 CEST 2012


Hi Daniel,

we are making ourselves familiar with the dialplan module sources. About
the matching in redis, we can't fetch records by regexp/prefix matching
over the key: for now we are thinking about exact matching starting from
the longest prefix in the number (match_op = 1). Once the best match key is
found we have come up with a few general solutions for the subst/repl rules:

-Compile them at runtime
-Compile them at startup and save them in additional fields of the same
redis hash
-Compile them at startup and save them compiled in memory; the redis hash
could store a pointer in another filed.
-(...)

What do you think?


Regards

Javi


On Wed, Apr 11, 2012 at 11:17 AM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:

>  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> 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/
>>
>>
>
> --
> 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/20120412/aff181a6/attachment.htm>


More information about the sr-dev mailing list