[sr-dev] RFC: updating default values

Daniel-Constantin Mierla miconda at gmail.com
Wed Apr 16 12:06:06 CEST 2014


Hello,

I am opening this discussion to decide if there is need to adjust some 
of the default values we have in Kamailio. Many of them were set even 
like 10 years ago, so they might not be very actual anymore.

The main goal is to get the best possible settings for common usage.

To start with, here are some values that should be reviewed:

- default private memory is 4MB - if the config is not that small, it 
might not be sufficient free pkg to play with (e.g., for sql_query() 
result, storage of $var(...) values). Should it be increased to 8MB or 
other value? Debian/Centos have startup script that sets its value to 8 
via command line

- default shared memory is 32MB - for a decent deployment with tm, 
location, lcr/dispatcher, permissions, and anti-flood, it might leave 
not much free space. Should we double it or set to a different value

- usrloc - db_ops_ruid should enabled (1) - seems stable, without it 
there are problems updating/deleting location records when UA changes 
the call-id for same contact address.

- usrloc - hash_size - now is 9, which results in 512 slots, meaning is 
ok for few thousands of registered users, for more, performance will 
decrease when doing save/lookup location -- should it be made 10 (1024 
slots for internal hash table)?

- auth_db - load_credentials defaults to 'rpid', meaning that the query 
to get the password will retrieve also the rpid column. I haven't see 
rpid being used that much lately (replaced by PAI/PPI). I would make 
this parameter empty by default to avoid querying for an extra column 
that is likely to be empty.

Perhaps there are more, I just wanted to get started. Reply with your 
comments to above list as well as add new items you thinks their default 
values should be adjusted.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda




More information about the sr-dev mailing list