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
Hello,
the internal dialog id - the pair h_entry,h_id - seems exposed to some
issues. They:
- h_entry is the slot index (in the internal hash table) where the
dialog structure will be stored
- h_id is an incremented counter for each slot
h_entry is computed as a hash function over Call-Id value, then made
modulo nr. of slots.
The problems can appear upon restart when changing the hash_size module
parameter:
http://kamailio.org/docs/modules/stable/modules_k/dialog.html#id2534423
If it is decremented, then some dialogs might be left outside since
their h_entry might not be valid anymore. Also, when hash_size is
changed, for matching on SIP dialog attributes of ongoing calls, the
hash function over callid made modulo over the new nr. of slots may get
a different hash table slot index, resulting in dialog structure not
being found.
A very unlikely issue is caused by the h_id, which being incremented can
overflow and start from 0 again. But will overlap if an dialog is still
going on after 2^32 new dialogs on that hash table slot were initiated.
I wanted to brought all in the discussion to make a decision. I see few
options for the moment:
1) document this issue, so a restart with change of hash_size parameter
must have 0 active dialogs
2) replace h_entry with the value of the hash function over call id,
doing modulo operation each time to find the slot. The unlikely issue
with overflow of h_id is still there
3) switch over another kind of unique id (sriud.{c,h} added recently in
lib/srutils/ can be an option). This will imply changing the database
structure
Besides these, might be better to drop using the Record-Route header
parameter to carry dialog id and just do SIP based dialog matching.
Completely trusting those tokens in RR parameter might add some security
risks and if there is a fallback to SIP-based dialog matching, using the
shortcut with RR does not impact anymore that much.
Opinions and other suggestions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.php/kamailio-advanced-training/
Hello,
I am studying the use case when a redis command returns an array
(REDIS_REPLY_ARRAY type in hiredis.h from
https://github.com/antirez/hiredis )
Function pv_get_redisc in kamailio/modules/ndb_redis/ndb_redis_mod.c :
365 returns a pv_value_t structure and currently only deals with
REDIS_REPLY_STRING
and REDIS_REPLY_INTEGER cases.
It seems looking at pvar.h that pv_value_t structure does not deal with
arrays. Is that correct? So returning an array is not an option...
Then a better aproach could be changing pv_parse_redisc_name function:
right now from README in ndb_redis:
after executing redis_cmd("srvN", "SET foo bar", "r"); I could get
$redis(r->type) and $redis(r->value)
it could be a good idea to add options like: $redis(r->size) and
$redis(r->value[Number]) when changing pv_parse_redisk_name function.
Do you think of that as a good approach?
Thanks in advance!
Vicente.