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.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
We use dialog module in our configuration.
uac_replace_from/to is called after dlg_manage().
restore_mode is auto.
URIs are modified automatically in all subsequent local requests, exclude
BYE generated in dlg timeout.
In this case original URIs are sent to both caller and calee sides.
If call going through only one kamailio server, all works fine.
Problem starts with a chain of servers with from/to manipulation.
When timeout occurs in one kamailio server, calee kamailio server receives
BYE with original (not modified) URIs and URI restore gets wrong parsing
result.
Call clears in caller side and stay connected in caller.
Whether there is any solution?
BR ,
Julia.
Hi,
Is it possible to use kamailio to manage a very simple queue? All calls inbound go directly in queue and then the system to to extract calls and route to agent. A very simple call center.
I've seen that there's a mohqueue module...is there any conf example?
Many thanks
Hello,
I try to use event_route[core:receive-parse-error] in 4.1.6
event_route[core:receive-parse-error] {
xlog("L_WARN", "Event-parse-error: $rm from
$avp(inc_carrier)/n$mb/n");
}
When core parse error occurs , *log message is not printed*.
What is wrong?
Thank you,
Julia
Hi all,
I’ve had Kamailio running nicely for nearly a year, but have hit a segfault twice since upgrading to 4.1.6 earlier this week.
The log shows:
Oct 2 11:28:03 localhost /usr/sbin/kamailio[1222]: : <core> [pass_fd.c:293]: receive_fd(): ERROR: receive_fd: EOF on 23
Oct 2 11:28:03 localhost kernel: [11259.904645] kamailio[1206]: segfault at 58 ip 00007fa56fba0f86 sp 00007fffea594ca0 error 4 in dialog.so[7fa56fb63000+54000]
Oct 2 11:28:03 localhost /usr/sbin/kamailio[1175]: ALERT: <core> [main.c:777]: handle_sigs(): child process 1206 exited by a signal 11
Oct 2 11:28:03 localhost /usr/sbin/kamailio[1175]: ALERT: <core> [main.c:780]: handle_sigs(): core was not generated
Oct 2 11:28:03 localhost /usr/sbin/kamailio[1175]: INFO: <core> [main.c:792]: handle_sigs(): INFO: terminating due to SIGCHLD
Oct 2 11:28:03 localhost /usr/sbin/kamailio[1220]: INFO: <core> [main.c:843]: sig_usr(): INFO: signal 15 received
….
The first two lines above seem to be the important parts. Nothing was logged for about 10s prior to this extract. An earlier instance of the issue showed almost the same details:
Oct 1 20:39:12 localhost /usr/sbin/kamailio[1219]: : <core> [pass_fd.c:293]: receive_fd(): ERROR: receive_fd: EOF on 23
Oct 1 20:39:12 localhost kernel: [554502.639227] kamailio[1207]: segfault at 58 ip 00007fd62c5c6f86 sp 00007fffd77c9890 error 4 in dialog.so[7fd62c589000+54000]
I’m trying to catch a core next time it occurs, no core is available yet.
Is this a new issue in 4.1.6?
Any suggestions about the likely cause?
Cheers,
Dave.
Hello,
I'm having trouble with this scenario (Kamailio and Asterisk are working on
the same server, Asterisk listens on 4060 instead of 5060): the UAC sends an
ACK request with the following R-URI: sip:955*95%23@
<sip:955*95%23@%3cIP_ASTERISK/KAMAILIO%3e:4060> <IP_ASTERISK/KAMAILIO>:4060.
When I'm doing a capture on loopback interface, I just see an ACK request
from IP <IP_ASTERISK/KAMAILIO>:5060 to IP <IP_ASTERISK/KAMAILIO>:5060.
So the ACK seems to loop inside Kamailio.
What could explain that the good port defined by the UAC is deleted?
Regards,
Igor.
