- sr-users - kamailio.org

Kamailio Remote User Registration
by Hildah.Ochieng＠deutschebahn.com 04 Jan '18

04 Jan '18

Dear Kamailio experts, I would like to able to register one kamailio (localuser) in another another kamailio (remoteuser) when the jitsi sip account "localuser@localdomain" is online. Using the UAC module for remote registration the uacreg table's l_username and l_domain attributes are set to refer to the local kamailio while the r_username and r_domain attributes refer to the remote kamailio. I would appreciate your advice on the missing piece of the puzzle. Following is my configuration of the "local" kamailio. The "remote" kamailio.cfg is unchanged. /etc/kamailio/kamailio.cfg loadmodule "db_text.so" loadmodule "uac.so" modparam("uac", "reg_timer_interval", 30) modparam("uac", "reg_retry_interval", 60) modparam("uac", "reg_contact_addr","xx.xx.xx.xx:5060") modparam("uac", "reg_db_table", "uacreg") modparam("uac", "reg_db_url", "text:///etc/kamailio/dbtext") /etc/kamailio/dbtext/uacreg l_uuid(string) l_username(string) l_domain(string) r_username(string) r_domain(string) realm(string) auth_username(string) auth_password(string) auth_proxy(string) expires(int) flags(int) reg_delay (int) 11111111:localuser:localdomain:remoteuser:remotedomain:remoteuser::::360:4:30 Thanks Hildah

2 1

Kamailio fail to start with db_mongodb and ndb_mongodb modules
by Abdul Basit 04 Jan '18

04 Jan '18

Hi, I am trying to setup mongo db as database engine for kamailio as described at <http://www.kamailio.org/wiki/tutorials/kamailio-and-mongodb> http://www.kamailio.org/wiki/tutorials/kamailio-and-mongodb and https://telerain.com/kamailio OS: Debian GNU/Linux 8.10 (jessie) MongoDB server version: 3.4.10 mongo-c-driver-1.9.0.tar.gz compiled with ./configure --disable-static --disable-silent-rules --enable-debug-symbols --enable-ssl=no --enable-sasl=yes --with-libbson=bundled --enable-optimizations --disable-automatic-init-and-cleanup version: kamailio 5.0.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 20:45:44 Dec 27 2017 with gcc 4.9.2 include_modules= utils app_lua db_postgres json evapi db_mongodb ndb_mongodb Kamailio is crashing with segfault as soon as it try to load libmongo-c Dec 28 04:44:14 sipserver systemd[1]: Starting Kamailio (OpenSER) - the Open Source SIP Server... Dec 28 04:44:14 sipserver kamailio: INFO: <core> [core/sctp_core.c:75]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Dec 28 04:44:14 sipserver kamailio: INFO: <core> [core/tcp_main.c:4671]: init_tcp(): using epoll_lt as the io watch method (auto detected) Dec 28 04:44:14 sipserver kamailio[11685]: Listening on Dec 28 04:44:14 sipserver kamailio[11685]: udp: 127.0.0.1:5060 Dec 28 04:44:14 sipserver kamailio[11685]: udp: 192.168.10.20:5060 Dec 28 04:44:14 sipserver kamailio[11685]: tcp: 127.0.0.1:5060 Dec 28 04:44:14 sipserver kamailio[11685]: tcp: 192.168.10.20:5060 Dec 28 04:44:14 sipserver kamailio[11685]: Aliases: Dec 28 04:44:14 sipserver kamailio[11685]: tcp: localhost:5060 Dec 28 04:44:14 sipserver kamailio[11685]: udp: localhost:5060 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: rr [rr_mod.c:175]: mod_init(): outbound module not available Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:203]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:203]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Dec 28 04:44:14 sipserver systemd[1]: Started Kamailio (OpenSER) - the Open Source SIP Server. Dec 28 04:44:14 sipserver kernel: [53109.390171] show_signal_msg: 20 callbacks suppressed Dec 28 04:44:14 sipserver kernel: [53109.390176] kamailio[11696] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.390753] kamailio[11694] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.391605] kamailio[11698] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392073] kamailio[11701] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392408] kamailio[11692] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392497] kamailio[11700] segfault at 38 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392761] kamailio[11703] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392825] kamailio[11697] segfault at 38 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.393098] kamailio[11705] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.393147] kamailio[11699] segfault at 38 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11689 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11688 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 14 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 15 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 16 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 17 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 18 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 19 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 20 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 21 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 22 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 23 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 24 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 25 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11690 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11691 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11692 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11693 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11694 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11695 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11696 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11697 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11698 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11699 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11700 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11701 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11702 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11703 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11704 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11705 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 26 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 27 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11706 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 28 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 29 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11707 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 30 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 31 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11708 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 32 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 33 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11709 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 34 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 5 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11710 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 9 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 35 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11711 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 37 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 39 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11712 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 41 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 43 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11713 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 45 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 47 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11714 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11715 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11716 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11717 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [main.c:768]: handle_sigs(): terminating due to SIGCHLD Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: INFO: <core> [main.c:823]: sig_usr(): signal 15 received Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Dec 28 04:44:14 sipserver systemd[1]: kamailio.service: main process exited, code=exited, status=1/FAILURE Dec 28 04:44:14 sipserver systemd[1]: Unit kamailio.service entered failed state. As I tried googling the issue and found few issues with tls connection. I set in default kamailio.cfg but still facing the saem issue. enable_tls=no ... loadmodule "ndb_mongodb.so" modparam("ndb_mongodb", "server", "name=cgr91rc8;uri='mongodb://localhost/kamailio'") Its mongodb default installation and its accessible without any auth yet. Please suggest the way farward. -- regards, abdul basit

3 6

TLS cipher suites
by Steve 03 Jan '18

03 Jan '18

I have a question about deploying TLSv1.2 with Kamailio 4.3.4-1 on a Lubuntu 16.4.3 desktop environment. I changed the Kamailio default /tls.cfg/ file under the section [server:default] to “method=TLSv1.2” and am using OpenSSL 1.0.2g from the Lubuntu repository. All the programs were loaded through the Synaptic Package Manager. My question is whether this version of Kamailio supports the cipher suite ECDHE-RSA-AES256-GCM-SHA384. My version of OpenSSL lists it as an option, but the highest strength cipher that the Kamailio 4.3.4 server seems to accept is RSA-AES256-GCM-SHA384. My (limited) understanding is that ECDHE is a better method of key exchange than RSA because it is ephemeral with forward secrecy. I used Wireshark to look at the connection protocols for sip clients Jitsi and Blink with the Kamailio server. Jitsi offers only four cipher choices of what I understand are considered compromised security TLS protocols and it connected with the RSA-AES128-CBC-SHA cipher. Blink offers 65 cipher choices, starting with ECDHE-RSA-AES256-GCM-SHA384. My Kamailio server accepted the 29^th offering on the list, RSA-AES256-GCM-SHA384. Unless I am missing something, Kamailio 4.3.4 doesn’t seem to support ephemeral DH key exchanges. Is there some other TLS configuration file or setting for Kamailio that can be changed to allow this? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

Re: [SR-Users] Bind IP to Kamailio without restart
by Duarte Rocha 03 Jan '18

03 Jan '18

Greetings Alex, That's exactly what I need, thanks a lot. Cheers

2 1

Kamailio IMS Proxy Not responding
by Amar Tinawi 03 Jan '18

03 Jan '18

Dears, Good day! i was trying to implement IMS platform in separated servers, i used ubuntu server 16.04 LTS, and ng-voice repository (Kamailio 5.1) with the installation wizard and minimum Conf i also choose FHoSS as HSS bind9 as DNS When i tried to register the Proxy-CSCF is not responding to any request, even no timeout, or error massage, and of course the request is not handled to I-CSCF. The client perform 11 tries, and got no respond Previously i had success with the one image IMS vm, and tried it on separated servers (kamailio version 4.2.4) Am i missing something ? how can i start troubleshoot as there is no error massages ? Is it because i'm using ubuntu 16 instead of 14? your help is highly appreciated ! attached is my configuration files Thanks in Advance Amar

2 1

Re: [SR-Users] Happy New Year 2018!
by Angel Elena 02 Jan '18

02 Jan '18

happy new year and happy sip ;) ----------------------------------------------- Ángel Elena Medina _o) craem(a)craem.net / \ http://blog.craem.net _(___V @craem_ ----------------------------------------------- Zarafa / Zpush Mobile. -------- Mensaje original -------- De: voipspace voipspace <voipspace(a)yandex.com> Fecha: 2/1/18 20:35 (GMT+01:00) Para: miconda(a)gmail.com, "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>, "Kamailio (SER) - Devel Mailing List" <sr-dev(a)lists.kamailio.org>, business(a)lists.kamailio.org Asunto: Re: [SR-Users] Happy New Year 2018! Happy New Year, Every One. Hope you had great time off with family and friends. May 2018 be prosperous and happy for you all. On to bigger and greater thing in the new year. bw Kamailio is awesome! 01.01.2018, 11:09, "Daniel-Constantin Mierla" <miconda(a)gmail.com>: > A Happy And Prosperous Year 2018 to everyone using Kamailio and helping > to improve the project! > > Looking forward to meeting many of you around this world during 2018 and > collaborate online in a friendly environment! > > Daniel > > -- > Daniel-Constantin Mierla > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - www.asipto.com > Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users(a)lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

1 0

Happy New Year 2018!
by Daniel-Constantin Mierla 02 Jan '18

02 Jan '18

A Happy And Prosperous Year 2018 to everyone using Kamailio and helping to improve the project! Looking forward to meeting many of you around this world during 2018 and collaborate online in a friendly environment! Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

2 1

In failure_route after t_drop and t_relay - cancel problem
by voipspace voipspace 02 Jan '18

02 Jan '18

2 2

does kamailio ims support mrfc&mrfp？
by zhang kevin 02 Jan '18

02 Jan '18

hi, dear all, i am a start user of kamailio and have a question listed in the title. if kamailio does not support mrfc and mrfp, how kamailio play the proper ring tone to the calling party? thx! from 张勇zhangyong:kevin

2 1

Issue with linking contact to IMPU on SCSCF
by Rafi A. 02 Jan '18

02 Jan '18

Hi there, I need some help here to understand why the query in [usrloc_db.c:1084] is empty. This causes the linking of contact to IMPU to fail. I'm using Kamailio 5.0.4. 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1284]: unref_subscription_unsafe(): un-reffing subscription [rafi(a)mnc001.mcc001.3gppnetwork.org] - was [3] 10(13882) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:rafi@mnc001.mcc001.3gppnetwork.org> 10(13882) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 10(13882) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:rafi@192.168.10.48:57230;transport=udp>: q_value [-1],sos: [0],expires [600000] 10(13882) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information 10(13882) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:rafi@192.168.10.48:57230;transport=udp] in slot 300 10(13882) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.cs-voice] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.icsi-ref] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [audio] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im.large-message] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.smsip] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [language] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [expires] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:173]: new_ucontact(): generating hash based on [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:280]: mem_insert_scontact(): Created new contact in memory with AOR: [sip:rafi@192.168.10.48:57230;transport=udp] and hash [300] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:289]: db_insert_ucontact(): DB: inserting ucontact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:311]: db_insert_ucontact(): Converted params to string to insert into db: [+g.3gpp.cs-voice;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.g sma-vs;audio;+g.oma.sip-im.large-message;+g.3gpp.smsip;language=en,fr;+g.oma .sip-im;expires=600000] 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:843]: ref_contact_unsafe(): incrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 1 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1225]: link_contact_to_impu(): number of contacts for IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org] is 1 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1065]: db_link_contact_to_impu(): DB: linking contact to IMPU 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1084]: db_link_contact_to_impu(): QUERY IS [] and len is 0 10(13882) ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Query was empty (1065) 10(13882) ERROR: <core> [db_query.c:181]: db_do_raw_query(): error while submitting query 10(13882) ERROR: ims_usrloc_scscf [usrloc_db.c:1086]: db_link_contact_to_impu(): Unable to link impu-contact in DB - impu [sip:rafi@mnc001.mcc001.3gppnetwork.org], contact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) ERROR: ims_usrloc_scscf [impurecord.c:1227]: link_contact_to_impu(): Failed to update DB linking contact [sip:rafi@192.168.10.48:57230;transport=udp] to IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org]...continuing but db will be out of sync! 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 2 Best Regards, Rafael A.

2 1

error when brining up scscf in kamailio 5.1
by Abdelmuhaimen Seaudi 01 Jan '18

01 Jan '18

Hi, After configuring scscf.cfg + kamailio.cfg + scscf.xml, I cannot start scscf, as I get the below error " can't bind presence" I tried commenting out the lines loading the presence module, but it seems this is not relevant. How can I try troubleshoot this issue ? Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: <core> [core/sr_module.c:982]: init_mod(): ims_usrloc_scscf Dec 31 17:22:55 olc-dd scscf[6659]: INFO: ims_usrloc_scscf [hslot.c:69]: ul_init_locks(): locks array size 512 Dec 31 17:22:55 olc-dd scscf[6659]: INFO: ims_usrloc_scscf [contact_hslot.c:67]: init_contacts_locks(): locks array size 512 Dec 31 17:22:55 olc-dd scscf[6659]: INFO: ims_usrloc_scscf [hslot_sp.c:70]: subs_init_locks(): locks array size 512 Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: <core> [core/sr_module.c:714]: find_mod_export_record(): export of <bind_presence> not found (flags 0) Dec 31 17:22:55 olc-dd scscf[6659]: ERROR: ims_usrloc_scscf [ims_usrloc_scscf_mod.c:292]: mod_init(): can't bind presence Dec 31 17:22:55 olc-dd scscf[6659]: ERROR: <core> [core/sr_module.c:984]: init_mod(): Error while initializing module ims_usrloc_scscf (/usr/local/lib64/kamailio/modules/ims_usrloc_scscf.so) Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: debugger [debugger_api.c:1267]: dbg_destroy_mod_levels(): Destroyed _dbg_mod_table, size 32 Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: cdp_avp [cdp_avp_mod.c:224]: cdp_avp_destroy(): Destroying module cdp_avp Dec 31 17:22:55 olc-dd scscf[6659]: INFO: cdp [cdp_mod.c:257]: cdp_exit(): CDiameterPeer child stopping ... Dec 31 17:22:55 olc-dd scscf[6659]: INFO: cdp [diameter_peer.c:364]: diameter_peer_destroy(): destroy_diameter_peer(): Terminating all children... Dec 31 17:22:55 olc-dd scscf[6659]: INFO: cdp [diameter_peer.c:383]: diameter_peer_destroy(): destroy_diameter_peer(): All processes terminated. Cleaning up. Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

1 1

error when creating scscf database in kamailio 5.1
by Abdelmuhaimen Seaudi 01 Jan '18

01 Jan '18

Hi, i am upgrading from kamailio 4.x to 5.1, and when i try to create the scscf databse, i get the below error I tried correcting this by removing the indexes, but the ims did not work properly, with lots of inconsistency in registering, and cannot make calls. what is the correct way to handle this error ? root@olc-dd:/usr/local/src/kamailio-5.1/kamailio/utils/kamctl/mysql# mysql -uroot scscf < ims_usrloc_scscf-create.sql ERROR 1071 (42000) at line 2: Specified key was too long; max key length is 767 bytes Thanks. Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

1 1

Issue with linking contact to IMPU
by Rafi A. 01 Jan '18

01 Jan '18

Hi there, I need some help here to understand why the query in [usrloc_db.c:1084] is empty. This causes the linking of contact to IMPU to fail. I'm using Kamailio 5.0.4. 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1284]: unref_subscription_unsafe(): un-reffing subscription [rafi(a)mnc001.mcc001.3gppnetwork.org] - was [3] 10(13882) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:rafi@mnc001.mcc001.3gppnetwork.org> 10(13882) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 10(13882) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:rafi@192.168.10.48:57230;transport=udp>: q_value [-1],sos: [0],expires [600000] 10(13882) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information 10(13882) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:rafi@192.168.10.48:57230;transport=udp] in slot 300 10(13882) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.cs-voice] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.icsi-ref] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [audio] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im.large-message] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.smsip] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [language] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [expires] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:173]: new_ucontact(): generating hash based on [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:280]: mem_insert_scontact(): Created new contact in memory with AOR: [sip:rafi@192.168.10.48:57230;transport=udp] and hash [300] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:289]: db_insert_ucontact(): DB: inserting ucontact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:311]: db_insert_ucontact(): Converted params to string to insert into db: [+g.3gpp.cs-voice;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.g sma-vs;audio;+g.oma.sip-im.large-message;+g.3gpp.smsip;language=en,fr;+g.oma .sip-im;expires=600000] 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:843]: ref_contact_unsafe(): incrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 1 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1225]: link_contact_to_impu(): number of contacts for IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org] is 1 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1065]: db_link_contact_to_impu(): DB: linking contact to IMPU 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1084]: db_link_contact_to_impu(): QUERY IS [] and len is 0 10(13882) ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Query was empty (1065) 10(13882) ERROR: <core> [db_query.c:181]: db_do_raw_query(): error while submitting query 10(13882) ERROR: ims_usrloc_scscf [usrloc_db.c:1086]: db_link_contact_to_impu(): Unable to link impu-contact in DB - impu [sip:rafi@mnc001.mcc001.3gppnetwork.org], contact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) ERROR: ims_usrloc_scscf [impurecord.c:1227]: link_contact_to_impu(): Failed to update DB linking contact [sip:rafi@192.168.10.48:57230;transport=udp] to IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org]...continuing but db will be out of sync! 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 2

1 0

Issue with linking contact to IMPU
by Rafi Aizenstain 01 Jan '18

01 Jan '18

Hi there, I need some help here to understand why the query in [usrloc_db.c:1084] is empty. This causes the linking of contact to IMPU to fail. I'm using Kamailio 5.0.4. 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1284]: unref_subscription_unsafe(): un-reffing subscription [rafi(a)mnc001.mcc001.3gppnetwork.org] - was [3] 10(13882) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:rafi@mnc001.mcc001.3gppnetwork.org> 10(13882) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 10(13882) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:rafi@192.168.10.48:57230;transport=udp>: q_value [-1],sos: [0],expires [600000] 10(13882) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information 10(13882) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:rafi@192.168.10.48:57230;transport=udp] in slot 300 10(13882) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.cs-voice] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.icsi-ref] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [audio] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im.large-message] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.smsip] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [language] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [expires] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:173]: new_ucontact(): generating hash based on [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:280]: mem_insert_scontact(): Created new contact in memory with AOR: [sip:rafi@192.168.10.48:57230;transport=udp] and hash [300] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:289]: db_insert_ucontact(): DB: inserting ucontact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:311]: db_insert_ucontact(): Converted params to string to insert into db: [+g.3gpp.cs-voice;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-vs;audio;+g.oma.sip-im.large-message;+g.3gpp.smsip;language=en,fr;+g.oma.sip-im;expires=600000] 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:843]: ref_contact_unsafe(): incrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 1 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1225]: link_contact_to_impu(): number of contacts for IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org] is 1 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1065]: db_link_contact_to_impu(): DB: linking contact to IMPU 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1084]: db_link_contact_to_impu(): QUERY IS [] and len is 0 10(13882) ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Query was empty (1065) 10(13882) ERROR: <core> [db_query.c:181]: db_do_raw_query(): error while submitting query 10(13882) ERROR: ims_usrloc_scscf [usrloc_db.c:1086]: db_link_contact_to_impu(): Unable to link impu-contact in DB - impu [sip:rafi@mnc001.mcc001.3gppnetwork.org], contact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) ERROR: ims_usrloc_scscf [impurecord.c:1227]: link_contact_to_impu(): Failed to update DB linking contact [sip:rafi@192.168.10.48:57230;transport=udp] to IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org]...continuing but db will be out of sync! 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 2 Best Regards, Rafael A.

1 0

error running icscf module on kamailio 4.4
by Abdelmuhaimen Seaudi 31 Dec '17

31 Dec '17

Hi, After setting up IMS components on kamailio 4.4, i get the following error when IMS client tries to register, what is this error, how can i correct it ? 1(14194) ERROR: <core> [sr_module.c:1766]: get_int_fparam(): Unexpected param type: 1280329042 1(14194) ERROR: ims_icscf [registration.c:78]: I_perform_user_authorization_request(): no int value param passed Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

2 1

error running icscf in kamailio 4.4
by Abdelmuhaimen Seaudi 31 Dec '17

31 Dec '17

Hi, After setting up IMS components on kamailio 4.4, i get the following error when IMS client tries to register, what is this error, how can i correct it ? 1(14194) ERROR: <core> [sr_module.c:1766]: get_int_fparam(): Unexpected param type: 1280329042 1(14194) ERROR: ims_icscf [registration.c:78]: I_perform_user_authorization_request(): no int value param passed Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

1 0

Bind IP to Kamailio without restart
by Duarte Rocha 29 Dec '17

29 Dec '17

Greetings, I want to add a new IP to eht0 in my proxy and i want Kamailio to be able to listen to it without me having to restart it. I already have the "listen" parameter set to listen=udp:eth0:5060. Is there any way to reload this parameter it in runtime in order to include the new ip? Is there any alternative to this ? Thanks in advance. Cheers

2 1

PCSCF Access denied issue
by Kranti Kumar 29 Dec '17

29 Dec '17

Hi All, We are using *Kamailio IMS VM* image and we are able to run HSS(/hss.sh) successfully. But while running PCSCF (kamailio -f /usr/local/etc/kamailio/kamailio-pcscf.cfg), we are getting below errors. 0(1772) DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql 0(1772) DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f208368d1b8 not found in pool 0(1772) DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening co nnection: mysql://xxxx:xxxx@server.net1.test/pcscf 0(1772) ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver er ror: Access denied for user 'pcscf'@'pcscf.net1.test' (using password: YES) 0(1772) ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the pool 0(1772) ERROR: ims_usrloc_pcscf [usrloc_db.c:79]: init_db(): unable to co nnect to the database 0(1772) ERROR: ims_usrloc_pcscf [ul_mod.c:203]: mod_init(): Error initializing db connection 0(1772) ERROR: <core> [sr_module.c:962]: init_mod(): Error while initializing module ims_usrloc_pcscf (/usr/local/lib64/kamailio/modules/ims_usrloc_pcscf.so) ERROR: error while initializing modules To fix the above error, we tried below commands *mysql -u root -p GRANT ALL ON *.* TO root IDENTIFIED BY 'root'; quit* - replace bind-address in /etc/mysql/my.cnf to 0.0.0.0 But still we are getting the same issue. Could any one please help us to resolve this issue. Could any one please guide us the troubleshooting steps. Thank you so much in advance. Regards, -kranti

4 6

Trying to fail a call over after 200 OK
by iTalk IP Support Department 28 Dec '17

28 Dec '17

Hi Everyone: I would appreciate your insight regarding a problem we are trying to solve. We are using Kamailio (4.1.8) along with multiple asterisk (13 and above) clusters for various telephony features. We are using the dispatcher module to send calls to the asterisk clusters in round robin and failover algorithms. We need a solution to fail a call and hand it over to another asterisk server after Kamailio has received a 200OK from Asterisk server A. I understand the failover works before the 200OK is sent from asterisk A and calls can easily be sent to asterisk B but again the challenge here to fail the call over to another asterisk server after a 200OK is received from the first one. If this is impossible I was wondering if refer and re-direct is an option to get this done. Thanks in advance for looking at this and for your responses.

2 1

Handling redirect replies and send to new host
by voipspace voipspace 28 Dec '17

28 Dec '17

Hi I am aiming to do the following User calls to Kamailio Switch (A) Switch (A) calls to Kamailio redirect server (B).. (B) runs script to determine route (B) sends Stateless 300 redirect reply to (A). (A) sends ACK to (B). (A) send user call to another host (extracted from header variable from redirect reply) (A) call to (B) rewritehost("x.x.x.x"); t_relay(); (A) On receipt of the 300 response I do not want this redirect to go back to the user. onreply_route { if (t_check_status("3[0-9][0-9]")) { // How do I send ACK to (B) to finish this redirect ? // Then I want a new relay to the host. How would I do it ? } }

3 2

PUBLISH modification.
by Володимир Іванець 27 Dec '17

27 Dec '17

Hello! I am trying to modify PUBLISH packet before handle_publish function execution. The best what I could think of is to make all required changes, update Destination URI to the Kamailio itself and then send it. In this case Kamailio will receive another PUBLISH packet with modified values. I was wondering someone knows cleaner way of achieving this. Thanks!

2 2

How to send "bye" to caller when callee abruptly terminates (Connection reset by peer)
by Pranathi Venkatayogi 26 Dec '17

26 Dec '17

Hi, Currently when callee abruptly closes the connection (TCP RST), Kamailio does not send “BYE” to the caller. Caller is left to believe that he is talking to the callee. What is best way to solve this? I have attempted using tcpops module to track connection RSTs and then send $dlg_bye in event_route[tcp:reset] . In the event_route, I can access only these - $conid , $Ri , $Rp , $si , $sp and $proto variable and do not know how to get to the dlg this connection belongs. Questions: How do I load the dialog associated with this conid? Is there a way to enumerate all dialogs? Thanks in advance, Pranathi.

2 2

Module dispatcher no
by Евгений Голей 26 Dec '17

26 Dec '17

Hello! Sorry for English, I know only Russian . There was a situation when it is necessary to control 1 IP address of the remote gateway from different sockets to kamailio. This is necessary to provide a backup bypass to a remote gateway through two independent Internet providers. Previously, I used the dispatcher module, but in this situation it did not help, I want to understand it the way it should or it's a bug. Here are the settings ------------(PROV-1)----------------\ / \ / (socket:udp:Y1.Y1.Y1.Y1:7060) Remote GW (sip:A1.A1.A1.A1:5060)------ (INTERNET) KAMAILIO \ (socket:udp:X1.X1.X1.X1:7060) \ / -----------(PROV-2)------------------/ kamailio.cfg ... loadmodule "dispatcher.so" ################################################################# modparam("dispatcher", "db_url", "mysql://root:@localhost/kamailio510") modparam("dispatcher", "dst_avp", "$avp(test)") modparam("dispatcher", "flags", 2) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshold", 1) modparam("dispatcher", "ds_inactive_threshold", 2) modparam("dispatcher", "ds_probing_mode", 1) List gw dispatcher ]# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 2 ATTRS: { BODY: socket=udp:Y1.Y1.Y1.Y1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:Y1.Y1.Y1.Y1:7060 } } DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 1 ATTRS: { BODY: socket=udp:X1.X1.X1.X1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:X1.X1.X1.X1:7060 } } } } } } Result if the remote gateway is not accessible through the network of the provider 2 (udp:X1.X1.X1.X1:7060), for the unknown reason the status of the first record, which corresponds to the provider 1 (udp:Y1.Y1.Y1.Y1:7060), changes. There are no errors with sockets, OPTIONS packages are sent and a response of 200 OK from the provider is received. 1. OPTIONS requests are sent through provider 2, but there are no answers. But the status changes for some reason at the first. # kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: IP PRIORITY: 2 ATTRS: { BODY: socket=udp:Y1.Y1.Y1.Y1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:Y1.Y1.Y1.Y1:7060 } } DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 1 ATTRS: { BODY: socket=udp:X1.X1.X1.X1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:X1.X1.X1.X1:7060 } } } } } } At testing it was found out, that камаилио does not allow to supervise a condition at use my circuit. I tried on 5.0.3 and on 5.1.0 the dispatcher works similarly. Please help with advice. Best regards Evgeniy

1 0

Multiple Kamailio Servers + Location Table
by Daniel W. Graham 26 Dec '17

26 Dec '17

When multiple Kamailio servers are using the same database with different server_id's (one active the rest standby in this test), records disappear and are no longer tracked in location database table. Some entries remain, but it never populates to the normal amount unless only one server is using the database. Anyone run into this before? Happened with 5.0 and is happening with 5.1. -dan

4 7

Dispatcher module OPTIONS and event routes: how are they handled by core?
by George Diamantopoulos 21 Dec '17

21 Dec '17

Hello all, I use the dispatcher module extensively for load balancing and fail-over. My kamailio instance is multihomed, and I use the "socket" attribute to determine which socket SIP messages should use for each dispatcher destination, as such: +----+-------+-------------------------+-------+----------+-----------------------------+ | id | setid | destination | flags | priority | attrs | +----+-------+-------------------------+-------+----------+-----------------------------+ | 1 | 0 | sip:192.168.0.1:5060 | 8 | 0 | socket=udp: 10.10.10.1:5060 | | 2 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp: 44.44.44.1:5060 | | 3 | 1 | sip:222.222.22.2:5060 | 8 | 0 | socket=udp: 55.55.55.1:5060 | +----+-------+-------------------------+-------+----------+-----------------------------+ The dispatcher module uses OPTIONS to probe each destination for availability. When a destination goes down or up, the respective event-route is executed. What I need to do is to be able to "capture" the sending socket used for this probing when a destination becomes unavailable or available in the event-routes. The $fs variable is set, but unfortunately its value does not make sense. Here's an example route and the results that are printed: event_route[dispatcher:dst-down] { xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs) $T_req($Ru)\n"); } Now say destination with id = '2' goes down. This is what I get in the logs for the event_route above: ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060 (sip: 192.168.0.1:5060) Contact: <sip:111.111.11.1:5060> udp:10.10.10.1:5060 <null> <null> <null> The xlog PV/log mapping for the above line is the following: $rm: OPTIONS $ru: sip:111.111.11.1:5060 $du: sip:192.168.0.1:5060 $ds: Contact: <sip:111.111.11.1:5060> $Ru: udp:10.10.10.1:5060 The rest are $null. $ru and $ds are consistent with the actual destination being probed, $du and $fs are not (the are set to values corresponding to id = '1', for some reason). This log line is, of course, inaccurate. Not only does it not make sense, but also this is not consistent with messages captured on network interfaces using sngrep: Kamailio does indeed behave as it should, the OPTIONS is sent out to 111.111.11.1 from socket udp:44.44.44.1:5060. But this is not reflected in the log entry above when the event_route is executed. Now the weird part is that this OPTIONS "transaction" (which is locally generated by kamailio) has the $du PV set to the value of another destination (namely the that of id = '1'). As a result, the $fs PV is consistent with that choice for $du. I can verify with sngrep that this is not the case in reality, as the request was sent to destination id = '2' from the correct socket as indicated above. What I would like to ask is whether these "OPTIONS" used by dispatcher for probing go through the request_route processing at some point. This is the only way that would explain the $du PV being set to a false value. If yes, is there any way to prevent this from happening? I need to be able to access the $fs PV when a destination goes up or down, and I can't have any other configuration file routes interfering with that. Thanks! Best regards, George

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users