Hello,
we had segfault today. Kamailio has been running for few months without
problems.
Nov 18 10:51:20 sbc kernel: [11326028.926502] kamailio[14452]: segfault
at 30 ip 00007f20f7f3838a sp 00007ffef3ab7b10 error 4 in
siptrace.so[7f20f7f23000+27000]
GDB:
Reading symbols from kamailio...done.
[New LWP 14452]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/sbin/kamailio -f
/etc/kamailio/kamailio.cfg -P /var/run/kamailio/kam'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f20f7f3838a in sip_trace (msg=0x7f2100f96750, dst=0x0,
dir=0x0) at siptrace.c:1041
1041 sto.totag = get_to(msg)->tag_value;
(gdb) bt
#0 0x00007f20f7f3838a in sip_trace (msg=0x7f2100f96750, dst=0x0,
dir=0x0) at siptrace.c:1041
#1 0x0000000000457ca9 in do_action (h=0x7ffef3ab8320, a=0x7f2100b8a928,
msg=0x7f2100f96750) at action.c:1053
#2 0x0000000000463cb9 in run_actions (h=0x7ffef3ab8320,
a=0x7f2100b8a928, msg=0x7f2100f96750) at action.c:1548
#3 0x00000000004643bf in run_top_route (a=0x7f2100b8a928,
msg=0x7f2100f96750, c=0x0) at action.c:1634
#4 0x0000000000573ea7 in receive_msg (
buf=0x9c9400 <buf> "OPTIONS sip:100@XXX.XXX.XX.XX SIP/2.0\r\nv:
SIP/2.0/UDP
69.64.39.119:5060;branch=z9hG4bK-82135822;rport\r\nContent-Length:
0\r\nf:
\"MisterX\"<sip:100@1.1.1.1>;tag=61326665333131663133633401333733313630343335"...,
len=357, rcv_info=0x7ffef3ab85b0) at receive.c:196
#5 0x0000000000493ff5 in udp_rcv_loop () at udp_server.c:495
#6 0x000000000051fdd7 in main_loop () at main.c:1573
#7 0x0000000000525b6b in main (argc=13, argv=0x7ffef3ab8998) at main.c:2533
(gdb) quit
Our IP is hidden, but there is 69.64.39.119, which is foreign address
and I think, it was attack. Unfortunatelly I don't have SIP packet
details, but you can see 1.1.1.1 or strange tag or content-length=0 in
received message.
I looked into siptrace.c and there is function sip_trace_prepare where
is get_from(msg) checked, but no get_to(msg). This function is run from
main sip_trace function. So I think, we need also check get_to(msg)
function.
I just disabled siptrace module, but we need it.
Thank you.
Marian
Hi,
I try to enable auth_radius module with my kamailo box. But it crashes on
the first REGISTER request.
I have enabled it with this two lines.
loadmodule "auth_radius.so"
modparam("auth_radius", "radius_config",
"/etc/radiusclient/radiusclient.conf")
This is the authentication part of my script.
if (is_method("REGISTER"))
{
if (!radius_www_authorize("$td")) {
switch ($rc) {
case -7:
send_reply("500", "Server Internal Error");
exit;
case -1:
send_reply("400", "Bad Request");
exit;
default:
};
if (defined($avp(digest_challenge)) &&
($avp(digest_challenge) != "")) {
append_to_reply("$avp(digest_challenge)");
};
send_reply("401", "Unauthorized");
exit;
};
}
And in the /etc/radiusclient/dictionary file, I included sip and kamailio
dictionaries.
$INCLUDE dictionary.sip
$INCLUDE dictionary.kamailio
Service succesfully starts but it crashes on the first REGISTER request.
Nov 18 11:30:27 sip kernel: [159645.360105] traps: kamailio[6941] general
protection ip:7f89b1660920 sp:7ffc8d3bac78 error:0 in libc-2.19.so
[7f89b15cb000+19f000]
Nov 18 11:30:27 sip /usr/sbin/kamailio[6961]: CRITICAL: <core>
[pass_fd.c:275]: receive_fd(): EOF on 17
Nov 18 11:30:27 sip /usr/sbin/kamailio[6934]: ALERT: <core> [main.c:728]:
handle_sigs(): child process 6941 exited by a signal 11
Nov 18 11:30:27 sip /usr/sbin/kamailio[6934]: ALERT: <core> [main.c:731]:
handle_sigs(): core was generated
Nov 18 11:30:27 sip /usr/sbin/kamailio[6934]: INFO: <core> [main.c:743]:
handle_sigs(): terminating due to SIGCHLD
Nov 18 11:30:27 sip /usr/sbin/kamailio[6961]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6959]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6951]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6936]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6948]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6944]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6937]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6953]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6945]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6938]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6955]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6943]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6942]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6957]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6939]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6940]: INFO: <core> [main.c:794]:
sig_usr(): signal 15 received
Nov 18 11:30:27 sip /usr/sbin/kamailio[6934]: INFO: <core>
[sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
Thanks,
Hello everyone,
My name is Bruno, I'm a student from Portugal studying IMS at the moment. I've been following tutorials online, trying to get Kamailio to work as an IMS core - I'm pretty much a newbie in this field.
Unfortunantly I've been getting several errors and I can't seem to properly configure everything. I was wondering if there is a All-in-One VM that can be downloaded, with Kamailio ready to be used as an IMS core?
Thanks in advance. Best regards,
Bruno C.
Hello list,
I've been given a task to setup a predictive dialer with for 8000+ agents
taking accepted calls in a queue.
I've done this for a much smaller setup in freeSWITCH but i recently saw
that kamailio has a mohqueue (which i already setup as a PoC) that might
work for this.
My question is whether you think it's a good idea to go with this on
kamailio or is freeSWITCH better suited for this kind of application?
The setup would be to generate outgoing calls based on a list (predictive
dialer) and send answered calls to a queue to be answered by an agent.
Thanks!
David
--
DVG
--
Imagination is more important than knowledge
Albert Einstein
Hello,
I've just installed Kamailio 4.3 on Debian 8.2, but starting kamailio does not work since Debian requires systemctl to be setup.
I've tried the below config but it didn't work (https://github.com/kamailio/kamailio/issues/294#issuecomment-138590939)
usr/local/src/kamailio# systemctl status kamailio.service
â kamailio.service - Kamailio SIP Server
Loaded: loaded (/etc/systemd/system/kamailio.service; disabled)
Active: failed (Result: resources)
systemd[1]: [/etc/systemd/system/kamailio.service:14] Not an absolute path, ignoring: $PIDFILE
systemd[1]: Failed to load environment files: No such file or directory
systemd[1]: kamailio.service failed to run 'start' task: No such file or directory
systemd[1]: Failed to start Kamailio SIP Server.
systemd[1]: Unit kamailio.service entered failed state.
[Unit]
Description=Kamailio (OpenSER) - the Open Source SIP Server
After=syslog.target network.target
[Service]
Type=forking
Environment='PIDFILE=/var/run/kamailio/kamailio.pid'
Environment='CFGFILE=/etc/kamailio/kamailio.cfg'
Environment='SHM_MEMORY=64'
Environment='PKG_MEMORY=8'
Environment='USER=kamailio'
Environment='GROUP=kamailio'
EnvironmentFile=/etc/default/kamailio
PIDFile=$PIDFILE
# ExecStart requires a full absolute path
ExecStart=/usr/sbin/kamailio -P $PIDFILE -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u $USER -g $GROUP
ExecStopPost=/bin/rm -f $PIDFILE
Restart=on-abort
[Install]
WantedBy=multi-user.target
Does anyone have a working kamailio.service file?
Regards,
Grant
Hello,
we just updated one kamailio server from 4.1.5 to 4.3.3, and although the
config file is correct and kamailio starts up, it doesn't initialize TLS
and says " tls support enabled, but no tls engine available (forgot to
load the tls module?)"
In the log I see:
Old shutdown (last lines):
Nov 13 11:44:38 lasola /usr/sbin/kamailio[15890]: DEBUG: <core>
[mem/shm_mem.c:235]: shm_mem_destroy(): destroying the shared memory lock
Nov 13 11:44:41 lasola /usr/sbin/kamailio[14818]: ERROR: <core>
[tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer
(104)
Nov 13 11:44:41 lasola /usr/sbin/kamailio[14818]: ERROR: <core>
[tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading
New startup (first lines):
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
[daemonize.c:583]: set_core_dump(): core dump limits set to
18446744073709551615
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING: <core>
[main.c:2475]: main(): tls support enabled, but no tls engine available
(forgot to load the tls module?)
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: WARNING: <core>
[main.c:2476]: main(): disabling tls...
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
[async_task.c:88]: async_task_init(): start initializing asynk task
framework
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
[sr_module.c:959]: init_mod(): xmlrpc
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
[sr_module.c:689]: find_mod_export_record(): find_export_record: found
<bind_sl> in module sl [/usr/lib/x86_64-linux-gnu/kamailio/modules//sl.so]
Nov 13 11:44:42 lasola /usr/sbin/kamailio[16113]: DEBUG: <core>
[sr_module.c:959]: init_mod(): sl
In our config file we have the following lines for TLS (pretty late, after
all other module loading and after most parameters):
#!ifdef ENABLETLS
loadmodule "tls.so"
modparam("tls", "private_key", "/etc/ssl/private/my.kamailio-key.pem")
modparam("tls", "certificate", "/etc/ssl/certs/my.kamailio.crt")
#!ifdef TLS_CA_CHAIN
# Maybe we want to use a chain to the CA
modparam("tls", "ca_list", "/etc/ssl/certs/my.ca-bundle.crt")
#!endif
enable_tls=1
listen=tls:1.2.3.4:5061
#!endif
After starting up, kamailio listens on port 5060, but not on port 5061. In
version 4.1.1, this config worked without a problem.
Has anybody seen this before? the tls module is there and available, it
doesn't say anything about "cannot load module", and it is only a warning
message. I'm also wondering, why this message is the first after starting
the server. From config I would expect that sl, tm and all the other
modules should be initialized before tls.
Best Regards,
Sebastian
We have multiple kamailio servers with 4 cpu cores and 16G RAM.
We use kamailio+rtpproxy as a outbound sip proxy. Usually there are
many thousands of concurrent sip sessions of occurring there.
Periodically sometimes it just stops serving request and spits out 5**
replies. At that point we usually reload the kamailio daemon and
things return back to normal. As we have a lot of servers, manually
doing this is a pain in the neck. So We installed a homer/sipcapture
on a separate server . And from there, we periodically scan for 500
msgs for a given time interval. If there are any, we then proceed to
reload kamailio.
I know its hell of an inefficient system to monitor.
So I'm wondering, if there can be any more rational way to detect
problems pre-emptively. any fifo/mi command which we could run to find
out if the kamailio instance is hung up?
Cheers
Arif