sr-users February 2019

sr-users@lists.kamailio.org

78 participants
99 discussions

kamailio 5.2.0 with empty table of rtpengine - kamailio doesn't start
by * Paolo Visintin - evosip.cloud 31 Mar '19

31 Mar '19

Hello, I noticed that , with kamailio ver. 5.2.1 starting with empty rtpengine table causes strange messages in kamailio and it doesn't start modparam("rtpengine", "db_url", "text:///tmp/kamailio/dbtext") cat /tmp/kamailio/dbtext/rtpengine id(int,auto) setid(int) url(string) weight(int) disabled(int) stamp(int) 0(2856) WARNING: tm [tm.c:760]: mod_init(): reparse_on_dns_failover is enabled on a multihomed host -- check the readme of tm module! 0(2856) WARNING: rtpengine [rtpengine_db.c:100]: rtpp_load_db(): No rtpproxy instances in database 0(2856) ERROR: rtpengine [rtpengine.c:2768]: select_rtpp_set(): no rtpp_set_list->rset_first 0(2856) NOTICE: rtpengine [rtpengine.c:1664]: mod_init(): Default rtpp set 0 NOT found 1(2857) NOTICE: usrloc [udomain.c:434]: preload_udomain(): filtered by server_id[0] 2(2858) ERROR: rtpengine [rtpengine.c:1722]: build_rtpp_socks(): no more pkg memory for rtpp_socks 2(2858) ERROR: <core> [core/sr_module.c:847]: init_mod_child(): error while initializing module rtpengine (/usr/lib/x86_64-linux-gnu/kamailio/modules/rtpengine.so) (idx: 2 rank: 2 desc: [udp receiver child=1 sock=172.28.0.120:5060]) 2(2858) ERROR: <core> [core/pt.c:342]: fork_process(): init_child failed for process 2, pid 2858, "udp receiver child=1 sock=172.28.0.120:5060" 2(2858) CRITICAL: <core> [main.c:1633]: main_loop(): Cannot fork 4(2860) ERROR: rtpengine [rtpengine.c:1722]: build_rtpp_socks(): no more pkg memory for rtpp_socks 4(2860) ERROR: <core> [core/sr_module.c:847]: init_mod_child(): error while initializing module rtpengine (/usr/lib/x86_64-linux-gnu/kamailio/modules/rtpengine.so) (idx: 4 rank: 4 desc: [udp receiver child=3 sock=172.28.0.120:5060]) 4(2860) ERROR: <core> [core/pt.c:342]: fork_process(): init_child failed for process 4, pid 2860, "udp receiver child=3 sock=172.28.0.120:5060" 4(2860) CRITICAL: <core> [main.c:1633]: main_loop(): Cannot fork any hint on what could be wrong ? (5.2.0 works perfectly) many thanks! Paolo

6 7

407 Proxy Authentication Required
by Yağız AYDIN 14 Mar '19

14 Mar '19

Hello, I'm trying to implement Kamailio IMS and registration by using Boghe IMS. Registration profiles are default profiles provided by FHoSS ( Alice & Bob). While trying registration, I am facing some problems. REGISTER message behaves as intended and results with 200 OK. After 200 OK message, Boghe IMS is sending SUBSCRIBE message to S-CSCF (via P-CSCF), this message results with a 407 Proxy Authentication Required, I have some questions about this scenario. 1-) Why do I have this SUBSCRIBE message? Even though i commented out WITH_AUTH function, why do I have 407 Proxy Authentication Required message? 2-) On IMS Client side, when informaion about Alice or Bob is entered, login process results with success, but I can't send any message or do come calls. Is is related about this 407 message? 3-) On FHoSS interface, when I check IMPU values of those users, User-Status is marked as REGISTERED. From this perspective, should I consider registration is successful or not? 4-) How can I handle with this 407 Proxy Authentication Required message? Best Regards, Yağız --

2 4

Planning next IRC devel meeting
by Daniel-Constantin Mierla 11 Mar '19

11 Mar '19

Hello, wondering if we we should do a new IRC devel meeting in the near future to sync on development plans. One of the decisions we should take is whether we should target to release the new major version (5.3) before the summer holidays or we leave it for the autumn. If many wants to do it, then a first proposal for a date would be: March 07, 2019, at 15:00 UTC (16:00 Berlin time). As usual, I created a wiki page to track the availability and the topics that should be approched: * https://www.kamailio.org/wiki/devel/irc-meetings/2019a Feel free to add yourself there, propose topics, etc... Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com

3 6

tm.so --> segfault at 3135352e36 ip 00007f761bb57ed1 sp 00007fff9db8b1c0 error 4 in tm.so
by Abdoul Osséni 04 Mar '19

04 Mar '19

Hello, Hello dear list, Today, I have had mutiples crashes. It seems it linked to tm.so module. -rw------- 1 root kamailio 4299702272 Feb 25 13:08 core.kamailio.sig11.29204 -rw------- 1 root kamailio 1453023232 Feb 25 13:12 core.kamailio.sig11.29203 -rw------- 1 root kamailio 1416065024 Feb 25 13:12 core.kamailio.sig11.29207 -rw------- 1 root kamailio 4299681792 Feb 25 13:16 core.kamailio.sig11.19047 -rw------- 1 root kamailio 2108506112 Feb 25 13:20 core.kamailio.sig11.19043 -rw------- 1 root kamailio 4299689984 Feb 25 13:34 core.kamailio.sig11.19247 -rw------- 1 root kamailio 4299681792 Feb 25 13:34 core.kamailio.sig11.19246 -rw------- 1 root kamailio 4299698176 Feb 25 13:35 core.kamailio.sig11.19248 -rw------- 1 root kamailio 4299689984 Feb 25 13:35 core.kamailio.sig11.19243 -rw------- 1 root kamailio 4299685888 Feb 25 13:35 core.kamailio.sig11.19244 -rw------- 1 root kamailio 4299689984 Feb 25 13:36 core.kamailio.sig11.19242 root@sbc:/var/cores# gdb /usr/local/sbin/kamailio core.kamailio.sig11.29204 GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/sbin/kamailio...done. [New LWP 29204] warning: .dynamic section for "/lib/x86_64-linux-gnu/libpthread.so.0" is not at the expected address (wrong library or version mismatch?) Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error warning: File "/lib/x86_64-linux-gnu/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /lib/x86_64-linux-gnu/libthread_db-1.0.so line to your configuration file "/root/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error warning: File "/lib/x86_64-linux-gnu/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /usr/local/etc/ka'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f68b9bb4515 in reply_received (p_msg=0x7f693ccd5cc8) at t_reply.c:2240 2240 last_uac_status=uac->last_received; (gdb) Any ideas? Regards Abdoul

3 8

crash at 480 reply to INVITE
by Juha Heinanen 04 Mar '19

04 Mar '19

Kamailio 5.2 crashed when it received 480 reply to INVITE. Below is backtrace from the core file. The crash happens in t_reply.c on the last line of this block: uac=&t->uac[branch]; LM_DBG("org. status uas=%d, uac[%d]=%d local=%d is_invite=%d)\n", t->uas.status, branch, uac->last_received, is_local(t), is_invite(t)); last_uac_status=uac->last_received; Earlier it was checked that the transaction was found. Its uac[0] seems to be broken. -- Juha ----------------------------------------- Program terminated with signal SIGSEGV, Segmentation fault. #0_ 0x00007f1073e234c3 in reply_received (p_msg=0x7f1076b605f0) at t_reply.c:2240 2240_ _ _ t_reply.c: No such file or directory. (gdb) bt full #0_ 0x00007f1073e234c3 in reply_received (p_msg=0x7f1076b605f0) at t_reply.c:2240 _ _ _ _ _ _ _ msg_status = 480 _ _ _ _ _ _ _ last_uac_status = 1590315756 _ _ _ _ _ _ _ ack = 0x50550c4 <error: Cannot access memory at address 0x50550c4> _ _ _ _ _ _ _ ack_len = 4 _ _ _ _ _ _ _ branch = 0 _ _ _ _ _ _ _ reply_status = 29 _ _ _ _ _ _ _ onreply_route = 9941216 _ _ _ _ _ _ _ cancel_data = {cancel_bitmap = 0, reason = {cause = 0, u = {text = {s = 0x0, len = 1590087991}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 1590087991}}}} _ _ _ _ _ _ _ uac = 0x0 _ _ _ _ _ _ _ t = 0x7f105dfe6480 _ _ _ _ _ _ _ lack_dst = {send_sock = 0x555b5f02720f <buf+431>, to = {s = {sa_family = 29127, sa_data = "XXX"}, sin = {sin_family = 29127, sin_port = 24322, sin_addr = {s_addr = 21851}, sin_zero = "XXX"}, sin6 = { _ _ _ _ _ _ _ _ _ _ _ _ _ sin6_family = 29127, sin6_port = 24322, sin6_flowinfo = 21851, sin6_addr = {__in6_u = {__u6_addr8 = "XXX", __u6_addr16 = {XXX, XXX, XXX, XXX, XXX, XXX, XXX, XXX}, __u6_addr32 = {XXX, XXX, XXX, _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ XXX}}}, sin6_scope_id = 1980563656}}, id = 32528, proto = 112 'p', send_flags = {f = 30268, blst_imask = 32528}} _ _ _ _ _ _ _ backup_user_from = 0x0 _ _ _ _ _ _ _ backup_user_to = 0xXXX <qm_info+46> _ _ _ _ _ _ _ backup_domain_from = 0xXXX _ _ _ _ _ _ _ backup_domain_to = 0xXXX _ _ _ _ _ _ _ backup_uri_from = 0x0 _ _ _ _ _ _ _ backup_uri_to = 0xXXX _ _ _ _ _ _ _ backup_xavps = 0x45ed834e3 _ _ _ _ _ _ _ replies_locked = 1 _ _ _ _ _ _ _ branch_ret = 1593995512 _ _ _ _ _ _ _ prev_branch = 21851 _ _ _ _ _ _ _ blst_503_timeout = 340003632 _ _ _ _ _ _ _ hf = 0x7f1076490810 _ _ _ _ _ _ _ onsend_params = {req = 0x7f10763c4898, rpl = 0x7f10763c4888, param = 0x97b5f0, code = 10751248, flags = 0, branch = 0, t_rbuf = 0xaf95c0, dst = 0x7f1076db4fc0 <__syslog>, send_buf = {s = 0x555b5ed834e3 "INFO", len = 134217728}} _ _ _ _ _ _ _ ctx = {rec_lev = 1593995791, run_flags = 21851, last_retcode = 1593995708, jmp_env = {{__jmpbuf = {48, 139708676767760, 93849330384899, -7479270984431321856, 93850924380609, 139708690288576, 93850921612515, 134217728}, __mask_was_saved = 12582912, __saved_mask = { _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __val = {6, 140720648489936, 139708687844848, 140720648490064, 93850920720905, 93850924380373, 139708676767760, 140720648489904, 139708469727337, 139708679781296, 139708687844848, 139708684105760, 140720648490560, 5888963087, 93849330384896, 11507136}}}}} _ _ _ _ _ _ _ bctx = 0x7f10760d0010 _ _ _ _ _ _ _ keng = 0x0 _ _ _ _ _ _ _ __func__ = "reply_received" #1_ 0x0000555b5eadf4dc in do_forward_reply (msg=0x7f1076b605f0, mode=0) at core/forward.c:747 _ _ _ _ _ _ _ new_buf = 0x0 _ _ _ _ _ _ _ dst = {send_sock = 0x0, to = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "XXX"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = { _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, id = 0, proto = 0 '\000', send_flags = {f = 0, blst_imask = 0}} _ _ _ _ _ _ _ new_len = 0 _ _ _ _ _ _ _ r = 1 _ _ _ _ _ _ _ ip = {af = XXX, len = 32528, u = {addrl = {XXX, 95}, addr32 = {XXX, XXX, XXX, 0}, addr16 = {XXX, XXX, XXX, XXX, XXX, XXX, XXX, XXX}, addr = "XXX"}} _ _ _ _ _ _ _ s = 0x7ffc14440c68 "" _ _ _ _ _ _ _ len = 32764 _ _ _ _ _ _ _ __func__ = "do_forward_reply" #2_ 0x0000555b5eae12f9 in forward_reply (msg=0x7f1076b605f0) at core/forward.c:852 No locals. #3_ 0x0000555b5eb5b679 in receive_msg ( _ _ _ buf=0x555b5f027060 <buf> "SIP/2.0 480 Request Terminated\r\nVia: SIP/2.0/UDP XXX;branch=z9hG4bKe951.40cf95b28fe54d0cbda88a8fa4c91d48.0\r\nVia: SIP/2.0/UDP XXX:5060;branch=z9hG4bK04B95fa49ac99a7fa91\r\nTo: <sip:XXX"..., len=431, _ _ _ rcv_info=0x7ffc14440ff0) at core/receive.c:433 _ _ _ _ _ _ _ msg = 0x7f1076b605f0 _ _ _ _ _ _ _ ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {139708690288576, 9004276570109933907, 93850921612515, 134217728, 12582912, 6, 9004276570114128211, 3007006209029601619}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 1, _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 139708266465728, 0, 0, 4634971920, 139708266465728, 140720648490768, 93850918093314, 120, 93850918093450, 139708680838560, 139708680838560, 140720648490832}}}}} _ _ _ _ _ _ _ bctx = 0x0 _ _ _ _ _ _ _ ret = 1 _ _ _ _ _ _ _ stats_on = 0 _ _ _ _ _ _ _ tvb = {tv_sec = 0, tv_usec = 0} _ _ _ _ _ _ _ tve = {tv_sec = 0, tv_usec = 0} _ _ _ _ _ _ _ tz = {tz_minuteswest = 0, tz_dsttime = 0} _ _ _ _ _ _ _ diff = 0 _ _ _ _ _ _ _ inb = {s = 0x555b5f027060 <buf> "SIP/2.0 480 Request Terminated\r\nVia: SIP/2.0/UDP XXX;branch=z9hG4bKe951.40cf95b28fe54d0cbda88a8fa4c91d48.0\r\nVia: SIP/2.0/UDP XXX:5060;branch=z9hG4bK04B95fa49ac99a7fa91\r\nTo: <sip:XXX"..., len = 431} _ _ _ _ _ _ _ netinfo = {data = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0} _ _ _ _ _ _ _ keng = 0x0 _ _ _ _ _ _ _ evp = {data = 0x7ffc14440df0, rcv = 0x7ffc14440ff0, dst = 0x0} _ _ _ _ _ _ _ cidlockidx = 0 _ _ _ _ _ _ _ cidlockset = 0 _ _ _ _ _ _ _ errsipmsg = 0 _ _ _ _ _ _ _ __func__ = "receive_msg" #4_ 0x0000555b5ea30dc4 in udp_rcv_loop () at core/udp_server.c:541 _ _ _ _ _ _ _ len = 431 _ _ _ _ _ _ _ buf = "SIP/2.0 480 Request Terminated\r\nVia: SIP/2.0/UDP XXX;branch=z9hG4bKe951.40cf95b28fe54d0cbda88a8fa4c91d48.0\r\nVia: SIP/2.0/UDP XXX:5060;branch=z9hG4bK04B95fa49ac99a7fa91\r\nTo: <sip:XXX"... _ _ _ _ _ _ _ tmp = 0x8000000 <error: Cannot access memory at address 0x8000000> _ _ _ _ _ _ _ from = 0x7f10764b1da0 _ _ _ _ _ _ _ fromlen = 16 _ _ _ _ _ _ _ ri = {src_ip = {af = 2, len = 4, u = {addrl = {XXX, XXX}, addr32 = {XXX, XXX, XXX, XXX}, addr16 = {XXX, XXX, XXX, XXX, XXX, XXX, XXX, XXX}, addr = "XXX"}}, dst_ip = { _ _ _ _ _ _ _ _ _ _ _ af = 2, len = 4, u = {addrl = {XXX, 0}, addr32 = {XXX, 0, 0, 0}, addr16 = {XXX, XXX, 0, 0, 0, 0, 0, 0}, addr = "XXX", '\000' <repeats 11 times>}}, src_port = 5060, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = { _ _ _ _ _ _ _ _ _ _ _ _ _ sa_family = 2, sa_data = "XXX"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = XXX}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1345864889, _ _ _ _ _ _ _ _ _ _ _ _ _ sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0xXXX, proto = 1 '\001'} _ _ _ _ _ _ _ evp = {data = 0x0, rcv = 0x0, dst = 0x0} _ _ _ _ _ _ _ printbuf = "XXX"... _ _ _ _ _ _ _ i = 1981052368 _ _ _ _ _ _ _ j = 5 _ _ _ _ _ _ _ l = 0 _ _ _ _ _ _ _ __func__ = "udp_rcv_loop" #5_ 0x0000555b5e9c8e32 in main_loop () at main.c:1645 _ _ _ _ _ _ _ i = 4 _ _ _ _ _ _ _ pid = 0 _ _ _ _ _ _ _ si = 0x7f1076130940 _ _ _ _ _ _ _ si_desc = "udp receiver child=4 sock=XXX:5060XXX" _ _ _ _ _ _ _ nrprocs = 8 _ _ _ _ _ _ _ woneinit = 1 _ _ _ _ _ _ _ __func__ = "main_loop" #6_ 0x0000555b5e9d0fdd in main (argc=17, argv=0x7ffc14441698) at main.c:2675 _ _ _ _ _ _ _ cfg_stream = 0x555b5fe5c010 _ _ _ _ _ _ _ c = -1 _ _ _ _ _ _ _ r = 0 _ _ _ _ _ _ _ tmp = 0x7ffc14442f30 "" _ _ _ _ _ _ _ tmp_len = 340006256 _ _ _ _ _ _ _ port = 32764 _ _ _ _ _ _ _ proto = 340006352 _ _ _ _ _ _ _ options = 0x555b5ed33020 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" _ _ _ _ _ _ _ ret = -1 _ _ _ _ _ _ _ seed = 1181662442 _ _ _ _ _ _ _ rfd = 4 _ _ _ _ _ _ _ debug_save = 0 _ _ _ _ _ _ _ debug_flag = 0 _ _ _ _ _ _ _ dont_fork_cnt = 0 _ _ _ _ _ _ _ n_lst = 0x0 _ _ _ _ _ _ _ p = 0xffffffff <error: Cannot access memory at address 0xffffffff> _ _ _ _ _ _ _ st = {st_dev = 19, st_ino = 17502, st_nlink = 2, st_mode = 16832, st_uid = 115, st_gid = 123, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1547850959, tv_nsec = 183989794}, st_mtim = {tv_sec = 1547851014, _ _ _ _ _ _ _ _ _ _ _ tv_nsec = 719730801}, st_ctim = {tv_sec = 1547851014, tv_nsec = 955611149}, __glibc_reserved = {0, 0, 0}} _ _ _ _ _ _ _ __func__ = "main"

2 20

kamailio/asterisk no call with sound if use rtpproxy/rtpengine
by PICCORO McKAY Lenz 28 Feb '19

28 Feb '19

i have setup asterisk/rtpproxy/kamailio following the guide in https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb and later NAT traversal with rtpproxy as i understand in simple we must have: phone/caller-->[-->rtpproxy->kamailio->asterisk->kamailio->rtpproxy -]->phone/dest But when you make a call between two phones, there is no sound... ...to make it work and get sound have to open the ports (range 10000 to 30000 udp) in the asterisk exposing them to the public ip whre its the kamailio and rtpproxy. We configured kamailio with rtpproxy (also tried with rtpengine), and when I configure Asterisk and Kamailio in "real time" mode, everything goes well, the extensions are registered, the authentication is in the asterisk side (table sipusers requires ignore the version check parameter if you use kamailio 5+) etc etc .. but there's no sound, we have: kamailio.bindip="10.10.1.1" desc "kamailio.bindip" kamailio.bindport=5060 desc "kamailio.bindport" asterisk.bindip="10.10.1.2" desc "asterisk.bindip" asterisk.bindport=5060 desc "asterisk.bindport" listen=udp:10.10.1.1:5060 advertise 200.1.1.1:5060 at rtpproxy we have: /usr/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock -u kamailio -p /var/run/rtpproxy/rtpproxy.pid -l 10.10.1.1 -A 200.1.1.1 -F -m 10000 -M 30000 why we need to make asterisk open the ports directly to the publlic ip? N]OTE: the public ip are not a real interface in the kamailio/rtppropxy machine, are provided by the service AWS at amazon! a NAT kind i guess! Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com

2 4

Call Terminatted in Mobile Firefox
by Ravikanth Challa 28 Feb '19

28 Feb '19

Hi All, I got call terminated only in mobile Firefox due to tlsv1 alert unknown ca error. If you have any solution on this please respond on this mail. I added kamailio error logs screen shot [cid:image002.jpg@01D4CF9C.92CE04D0] Thanks, Ravikanth Challa. CONFIDENTIALITY NOTICE: This message (including any attachment) is confidential and may be legally privileged. Access to this message by anyone other than the intended recipient(s) listed above is unauthorized. If you are not the intended recipient you are hereby notified that any disclosure, copying, or distribution of the message, or any action taken or omission of action by you in reliance upon it, is prohibited and may be unlawful. Please immediately notify the sender by reply e-mail and permanently delete all copies of the message if you have received this message in error. This e-mail message including attachment(s), if any, is believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and sender accepts no liability for any damage caused by any virus transmitted by this email.

1 0

Kamailio behind NAT or With Public IP - Which one is highly recommended
by Pintu Lohar 28 Feb '19

28 Feb '19

Hi Everyone, Which one among the below option is highly recommended for setting up Kamailio (for production) 1. Kamailio behind NAT *or* 2. Setting up Kamailio using public IP? are there any disadvantages if we setup Kamailio behind NAT and use advertise option in listen parameters? We have tested both the options, and both the options work great for us( a. Kamailio behind NAT with advertising in listen parameters b.Kamailio setup with public IP). So wondering which one is best and highly recommended? Some extra info : 1. We use TLS 2. Using coturn for media Thanks Pintu

7 11

Problem with ghost dialogs
by Cyrille Demaret 28 Feb '19

28 Feb '19

Hi, I'm running Kamailio 5.1.4 and I have some problem with some random dialogs sometimes staying in early state and never ends until I restart Kamailio. According to the init_ts, this dialog is there since 11/01/2019. * Do you have an idea how I can diagnose this problem? * Is there a way to kill these dialogs? I have tried with "dlg.end_dlg" but It seems it's not possible to kill dialogs in early states. { h_entry: 3382 h_id: 4069 call-id: d6e6de79-7d55-486f-889f-01b05c003411 from_uri: sip:0037xxxxxxxxxxx@mydomain.com to_uri: sip:1234@mydomain.com state: 2 start_ts: 0 init_ts: 1547195739 timeout: 0 lifetime: 43200 dflags: 1536 sflags: 0 iflags: 0 caller: { tag: a909d6fa-cee9-44ac-ad76-3697fcd5cb0e contact: sip:asterisk@192.168.102.20:5080;alias=192.168.102.20~5080~1 cseq: 7362 route_set: socket: udp:192.168.102.10:5060 } callee: { tag: contact: cseq: route_set: socket: } profiles: { { caller: sip:0037xxxxxxxxxxx@mydomain.com } { callee: sip:1234@mydomain.com } } variables: { } } Thank you for your help. Best regards, Cyrille

4 7

Dispatcher problem $avp(dsattrs) is null
by jaflong jaflong 28 Feb '19

28 Feb '19

I am doing a ds_select_dst call. I think dispatcher did run because $du gets updated The problem is $(avp(dsattrs)) value is null. Any ideas why?

2 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 February 2019