November 2015 - sr-dev - kamailio.org

[kamailio] Module:sca Line seize does not release after some 'bye's (#341)
by Kevin Scott Adams 07 Jul '16

07 Jul '16

I have a situation that I can't get my head around. Every so often I have a SCA seized and I need to manually release it. Here is the log of the sca and bye from the event logs. messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7608]: ERROR: sca [sca_call_info.c:1580]: sca_call_info_bye_handler(): sca_call_info_bye_handler: sip:Mindfield@kamailio.newgarllc.com dialog leg 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;1c389191866 is not active messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7610]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1442601328;method=BYE;from_tag=76C3EC1F-114D759A;to_tag=1c389191866;call_id=96b9ad37-9a7fa462-15c35d3@192.168.1.117;code=200;reason=OK;src_user=Mindfield;src_domain=kamailio.newgarllc.com;src_ip=192.168.1.40;dst_ouser=Mindfield;dst_user=Mindfield;dst_domain=192.168.1.117 And the kamcmd showing the seize line (in this case both are seized) sip:Mindfield@kamailio.newgarllc.com 1 active 1442601278 sip:Mindfield@192.168.1.117 sip:1030@192.168.1.40:5060 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117 76C3EC1F-114D759A 1c389191866 I am running Kamailio 4.2.6. The phones are Polycom VVX 310/410 running 5.3.1. And the PSTN gateway is an Audiocodes Mediant 1000 running 6.60A.292.001. The call volume is light so I don't think there is a lot of traffic but there is about 16 phones one SCA. It is not happening all time. Could be a couple days that nothing happens and then there could be a couple days that it happens multiple times a day. I can't find a common element that would be causing this unless the 'bye' is closing the call before the SCA has a chance to do something with it. Thanks Kev --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/341

4 18

[kamailio] SNMPstats dialog 0 afeter reboot (#424)
by igorPot 06 Jun '16

06 Jun '16

I have rebooted my kamailio machine and now the value of kamailio dialogs is always 0: KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInProgress.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInSetup.0 = Gauge32: 0 KAMAILIO-MIB::kamailioTotalNumFailedDialogSetups.0 = Counter32: 0 And also the status is: KAMAILIO-MIB::kamailioDialogUsageState.0 = INTEGER: idle(0) How can I change it to active(1)? I have dialog.so loaded as well as modparam("dialog", "dlg_flag", 4) and dlg_manage(). If I do 'kamctl stats dialog': # kamctl stats dialog dialog:active_dialogs = 498 dialog:early_dialogs = 57 dialog:expired_dialogs = 24 dialog:failed_dialogs = 73222 dialog:processed_dialogs = 539449 I have the same configruation of SNMPstats and kamailio in 2 other machines and it works perfectly. In this machine it worked until I rebooted the machine. I asked this question in th emailing list and I got the following response: "Must be something in how the SNMP module reads the data from the statistics counters." I don't know if this could help. Thank you. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/424

3 9

[kamailio] Lots of tcp_read_* errors in log, multi-transport server, lack of context in messages (#385)
by Andrey Utkin 06 Jun '16

06 Jun '16

Hi devs, The logs of our Kamailio servers are rich for such lines: ``` Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104) Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading ``` The servers serve WS, WSS, UDP, TCP and TLS as connection transports. So we cannot figure what happens and if this is really a problem, but we get accused by whoever audits the servers. What could be done to make this more trackable? Or maybe these messages should be suppressed, if there's no way to track them and they don't mean any problem? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/385

3 5

[kamailio] cnxcc: segmentation fault on 2 calls get terminatet - kamailio 4.3.3 (#417)
by Rick 06 Jun '16

06 Jun '16

Log: ``` Nov 25 12:01:23 sip42 kamailio[29215]: INFO: <script>: start - duration: 0 Nov 25 12:01:24 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=1.000000, ca2=0.000000 Nov 25 12:01:24 sip42 kamailio[29218]: INFO: <script>: start - duration: 0 Nov 25 12:01:25 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=4.000000, ca2=1.000000 Nov 25 12:01:26 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=7.000000, ca2=4.000000 Nov 25 12:01:27 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=9.000000, ca2=7.000000 Nov 25 12:01:28 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=11.000000, ca2=9.000000 Nov 25 12:01:28 sip42 kamailio[29234]: INFO: <script>: [2JR.9RLbmcERvjSelQ5zHRdAONs1pk0V]: call killed Nov 25 12:01:28 sip42 kamailio[29234]: INFO: <script>: [73tmL4-hk3-50vnsgt19E4rPMMAqHlAG]: call killed Nov 25 12:01:28 sip42 kamailio[29234]: ERROR: cnxcc [cnxcc_mod.c:1023]: terminate_call(): Error executing dlg_end_dlg command. Return code was [404] Nov 25 12:01:28 sip42 kamailio[29246]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 45 Nov 25 12:01:28 sip42 kamailio[29187]: ALERT: <core> [main.c:728]: handle_sigs(): child process 29234 exited by a signal 11 Nov 25 12:01:28 sip42 kamailio[29187]: ALERT: <core> [main.c:731]: handle_sigs(): core was not generated Nov 25 12:01:28 sip42 kamailio[29187]: INFO: <core> [main.c:743]: handle_sigs(): terminating due to SIGCHLD ``` Stacktrace: ``` (gdb) bt full #0 0x00007f3e25b5cfba in get_hash1_raw (s=0x0, len=0) at ../../hashes.h:109 p = 0x0 v = 4284224 h = 0 #1 0x00007f3e25b5d22d in str_hash_get (ht=0x7f3e26333580, key=0x0, len=0) at ../../str_hash.h:94 h = 32766 e = 0x301c31c78 #2 0x00007f3e25b69167 in __free_call (call=0x7f3e2646da00) at cnxcc_mod.c:910 e = 0x0 __FUNCTION__ = "__free_call" #3 0x00007f3e25b68dd5 in terminate_all_calls (credit_data=0x7f3e2646d950) at cnxcc_mod.c:899 call = 0x7f3e2646da00 tmp = 0x7f3e2646da00 __FUNCTION__ = "terminate_all_calls" #4 0x00007f3e25b5952f in check_calls_by_money (ticks=51698976, param=0x0) at cnxcc_check.c:109 credit_data = 0x7f3e2646d950 call = 0x7f3e2646da00 total_consumed_money = 11 consumption_diff = 2 h_entry = 0x7f3e2646d858 tmp = 0x7f3e26335c00 tmp_call = 0x7f3e2647d680 i = 118 __FUNCTION__ = "check_calls_by_money" #5 0x00000000005bcf1c in fork_basic_timer (child_id=-1, desc=0x7f3e25b866fd "CNXCC TB TIMER", make_sock=1, f=0x7f3e25b58200 <check_calls_by_money>, param=0x0, interval=1) at timer_proc.c:79 pid = 0 #6 0x00007f3e25b5ffce in __child_init (rank=0) at cnxcc_mod.c:383 pid = 0 __FUNCTION__ = "__child_init" #7 0x00000000005143d4 in init_mod_child (m=0x7f3e315cf8a8, rank=0) at sr_module.c:915 __FUNCTION__ = "init_mod_child" #8 0x00000000005146db in init_child (rank=0) at sr_module.c:941 No locals. #9 0x0000000000505cef in main_loop () at main.c:1654 i = 4 pid = 1327 si = 0x0 si_desc = "udp receiver child=3 sock=127.0.0.1:5060\000\061\000*>\177\000\000\240.~\264\376\177\000\000\a<\355*>\177\000\000y%p\000\000\000\000\000ȥ3&>\177\000\000\220$\361*>\177\000\000\300(l1>\177\000\000\000\371\360*>\177\000\000\003\000\000\000>\177\000\000\060.~\264\376\177\000\000xBI\000\000\000\000" nrprocs = 4 __FUNCTION__ = "main_loop" #10 0x000000000050be5a in main (argc=13, argv=0x7ffeb47e3138) at main.c:2553 cfg_stream = 0x1b9c010 c = -1 r = 0 tmp = 0x7ffeb47e4ee2 "" tmp_len = 32574 port = 846456272 proto = 0 options = 0x71cae0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1760074178 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0xf63d4e2e p = 0x7f3e3273e000 "" st = {st_dev = 15, st_ino = 9426, st_nlink = 2, st_mode = 16877, st_uid = 109, st_gid = 114, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1448451190, tv_nsec = 195999907}, st_mtim = {tv_sec = 1448451190, tv_nsec = 195999907}, st_ctim = {tv_sec = 1448451190, tv_nsec = 195999907}, __glibc_reserved = {0, 0, 0}} __FUNCTION__ = "main" ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/417

4 13

[kamailio] Database timeout over SSL? (#406)
by Tobias Lindgren 18 Feb '16

18 Feb '16

Hi, having some rare issues writing acc-data to a remote MySQL server. The connection is made using the MySQL SSL options. Most, 99,9%, of the writes work well. The error is: ``` Nov 20 13:48:55 /usr/sbin/kamailio[28976]: WARNING: db_mysql [km_dbase.c:84]: db_mysql_submit_query(): driver error on ping: SSL connection error: socket layer receive error Nov 20 13:48:55 /usr/sbin/kamailio[28976]: ERROR: db_mysql [km_dbase.c:121]: db_mysql_submit_query(): driver error on query: SSL connection error: socket layer receive error Nov 20 13:48:55 /usr/sbin/kamailio[28976]: ERROR: <core> [db_query.c:235]: db_do_insert_cmd(): error while submitting query ``` Apart from the connection details (using [mysql-ssl-conf] for the SSL config block) I have this config: ``` modparam("db_mysql", "ping_interval", 30); modparam("db_mysql", "timeout_interval", 8); ``` The documentation suggests that "ping_interval" is the "Time interval in seconds to send ping messages to MySQL server in order to keep the connection open." However, looking at the code this seems a bit misleading because it looks like the ping is only done on an actual query (db_mysql_submit_query), i.e. not with a regular interval/on a timer as suggested by the documentation? Also the "auto_reconnect" parameter is stated as default 1 (on), but in the code this is just used as a "retry" of the query itself and MYSQL_OPT_RECONNECT is never set on the connection (https://dev.mysql.com/doc/refman/5.5/en/auto-reconnect.html)? Maybe this is not necessary and it's enough to just re-try the query? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/406

4 53

[kamailio] rr: add enable_double_rr_always option (#257)
by Andrey Utkin 15 Feb '16

15 Feb '16

This patch helps us to handle inadequatness of Linphone mobile apps (both iOS and Android flavours are affected) without reinventing a lot of logics to handle each transport (we use TCP, TLS, WS, WSS). E.g. if we have two TLS-based Linphone clients, even with enable_double_rr for gentle cross-forwarding we would get single RR header without transport= attribute, resulting in Linphone sending ACK and BYE via UDP. This new option, being enabled, results in two RR headers being always inserted, with transport attribute being always added. I believe this cannot harm the installation with enable_double_rr, just makes instructions more explicit. The Linphone's behaviour looks like a set of different bugs, but it would get us much more efforts to fix. I don't know if any other useragent needs such workaround. So I would perfectly understand if this commit wouldn't be accepted upstream. Also this commit currently lacks README doc rebuild, because I don't know how to do that. Only XML doc is updated. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/257 -- Commit Summary -- * rr: add enable_double_rr_always option -- File Changes -- M modules/rr/doc/rr_admin.xml (24) M modules/rr/record.c (14) M modules/rr/rr_mod.c (2) M modules/rr/rr_mod.h (1) M tcp_read.c (5) -- Patch Links -- https://github.com/kamailio/kamailio/pull/257.patch https://github.com/kamailio/kamailio/pull/257.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/257

3 10

[kamailio] Crashed happen when loading module cnxcc (#407)
by MomoTerra 12 Feb '16

12 Feb '16

I'm on Kamailio version: kamailio 4.3.3 (x86_64/linux) 22e455 When booting up Kamailio I get a Nov 21 20:36:52 sipr kamailio[24460]: 0(24476) DEBUG: <core> [main.c:747]: handle_sigs(): terminating due to SIGCHLD Kamailio log: http://pastebin.com/7bHHyHqD Redis log: http://pastebin.com/jWyYnbRB Any ideas is greatly appreciated thanks! :). --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/407

2 4

[kamailio] Decrypt callid encrypted by topoh module before save in database (#422)
by pseabra 03 Feb '16

03 Feb '16

Homer can't relate callids encrypted and decrypted, originated by module topoh, issue https://groups.google.com/forum/#!topic/homer-discuss/1_a01BbgnD0 Issue fixed changing function sip_capture_store to decrypt callid and save decrypted callid in database. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/422 -- Commit Summary -- * Decrypt callid encrypted by topoh module before save in database -- File Changes -- M modules/sipcapture/sipcapture.c (11) A modules/sipcapture/th_mask.c (179) A modules/sipcapture/th_mask.h (36) -- Patch Links -- https://github.com/kamailio/kamailio/pull/422.patch https://github.com/kamailio/kamailio/pull/422.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/422

3 4

[kamailio] P-Charging-Vector handling as RFC3455 (#215)
by Emmanuel BUU 03 Feb '16

03 Feb '16

Here are some proposed modifications to handle the P-Charging-Vector header as defined in rfc3455 section 4.6 to - parse charging vector from SIP message - generate new unique charging vector - remove a charging vector header a new pseudo variable pseudo variables are exported and enable Read onlly access to charging vector fields $pcv = whole field $pcv.value = icid-value field (see RFC3455 section 5.6) $pcv.genaddr = icid-generated-at field (see RFC3455 section 5.6) a new function acc_charging_vector() - g = generate a new charging vector or forward the orginal one - f = generate a new charging vector regardless of the orginal charging vector - r = remote the P-Charging vector header from the packet You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/215 -- Commit Summary -- * P-Charging-Vector implementation * Merge remote branch 'upstream/master' * P-Charging-Vector -- File Changes -- M modules/acc/acc_mod.c (18) A modules/acc/chargingvector.c (435) A modules/acc/chargingvector.h (18) -- Patch Links -- https://github.com/kamailio/kamailio/pull/215.patch https://github.com/kamailio/kamailio/pull/215.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215

2 6

[kamailio] http_request and curl_http_request cause crash in 4.3 and dev (#400)
by Olle E. Johansson 27 Jan '16

27 Jan '16

Repeated use of http_request cause a crash related to the storage of the result in a PV. Will upload backtraces and other info to this issue. If anyone else have seen this please add info to this bug report. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/400

4 9