sr-dev July 2020

sr-dev@lists.kamailio.org

26 participants
390 discussions

[kamailio/kamailio] app_java.so: undefined symbol: JNI_CreateJavaVM please help (#1969)

by xevilstar

### Description  ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` (paste your output here) ``` * **Operating System**:  ``` (paste your output here) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1969

4 years, 3 months

[kamailio/kamailio] t_set_fr only works with UDP (#1966)

by Boden Garman

4 years, 3 months

[kamailio/kamailio] RPM repos at https://rpm.kamailio.org (#2084)

by Daniel-Constantin Mierla

Build own repositories for RPM packages for various distros: CentOS, RedHate, OpenSuse ... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2084

4 years, 3 months

[kamailio/kamailio] rtpengine module is not retrying for rtpengine_offer. retry is working for rtpengine_answer and rtpengine_delete (#1696)

by Surendra Tiwari

### Description we are using rtpengine with kamailio [KSR-LUA]. kamailio sending the rtpengine_offer to rtpengine. If kamailio didn't get the response from the rtpengine then it's not retrying . for rtpengine_answer and rtpengine_delete retry is working pretty good. we are using following rtpengine configuration # ----- rtpengine params ----- modparam("rtpengine", "db_url", DBURL) modparam("rtpengine", "table_name" , "rtpengine") modparam("rtpengine", "rtpengine_allow_op", 1) modparam("rtpengine", "queried_nodes_limit", 4) modparam("rtpengine", "rtpengine_retr", 2) modparam("rtpengine", "rtp_inst_pvar", "$avp(RTP_INSTANCE)") modparam("rtpengine", "setid_default", 1) modparam("rtpengine", "rtpengine_tout_ms", 400)  ### Troubleshooting #### Reproduction This issue can be reproduced by above configuration. and need to use rtpengine_offer,rtpengine_answer and rtpengine_delete with ksr lua routing.  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.1.4 (x86_64/linux) a1df59 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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: a1df59 compiled on 06:23:23 Oct 30 2018 with gcc 4.8.4 ``` * **Operating System**:  ``` root@ip-172-31-4-160:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty root@ip-172-31-4-160:~# uname -a Linux ip-172-31-4-160 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27 10:45:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1696

4 years, 3 months

[kamailio/kamailio] Active dialog stats stays static on a passive kamailio node that replicates dialogs via DMQ (#1692)

by Joel Serrano

### Description In a setup with 2 kamailios in active/passive with a virtual IP that failovers between them: sbc01 (active) is handling calls. sbc02 (passive) is started, and does an initial dialog sync via DMQ ``` root@sbc01:~# kamctl rpc stats.get_statistics all | grep dialog "dialog:active_dialogs = 39", "dialog:early_dialogs = 2", "dialog:expired_dialogs = 0", "dialog:failed_dialogs = 583", "dialog:processed_dialogs = 2527", root@sbc01:~# ``` ``` root@sbc02:/etc/kamailio# kamctl rpc stats.get_statistics all | grep dialog "dialog:active_dialogs = 39", "dialog:early_dialogs = 0", "dialog:expired_dialogs = 0", "dialog:failed_dialogs = 0", "dialog:processed_dialogs = 0", root@sbc02:/etc/kamailio# ``` >From that point onwards, as long as sbc01 stays as active, sbc02 stays as passive, and no restarts occur anywhere, the values for `dialog` metrics in sbc02 will not change and remain as they are, in the previous example, active_dialogs would remain as 39. ### Troubleshooting This was discovered during some tests from #1591 #### Reproduction Setup 2 kamailio instances that replicate dialogs via DMQ. 1- On Kamailio1 put some traffic to have some active dialogs (must call `dlg_manage()` in routing script for these test calls) 2- Start Kamailio2 3- Compare output of: `kamcmd stats.get_statistics dialog:` on both nodes. 4- Alter the amount of active dialogs on Kamailio1 (either end some or create new ones). 5- Repeat step 3. Kamailio1 --> Step5 will have different values from Step3. Kamailio2 --> Step5 will have exactly the same values from Step3. ### Possible Solutions `dialog:active_dialogs` should remain as 0 on Kamailio2, as technically there are no dialogs being handled by that server, it only has information of replicated dialogs and those stats are available in the `dlg.stats_active` metric. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -V version: kamailio 5.2.0-pre1 (x86_64/linux) 2ecf60-dirty flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 2ecf60 -dirty compiled with gcc 6.3.0 ``` * **Operating System**:  ``` root@sbc02:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.5 (stretch) Release: 9.5 Codename: stretch root@sbc02:~# uname -a Linux sbc02 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux root@sbc02:~# ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1692

4 years, 3 months

[kamailio/kamailio] t_forward_nonack not decoding/unescaping URI (#2255)

by Julien Chavanton

### Description SIP OPTION relayed using `t_forward_nonack()` not being URI decoded  ### Troubleshooting #### Reproduction register with PATH and use SIP OPTION keep alive or simply send relay a SIP OPTIONS with a route. #### Debugging Data  ```#1 0x00007fa3067a998f in t_forward_nonack (t=0x7fa3246fce88, p_msg=0x7fa3885aa1c0, proxy=0x0, proto=0) at t_fwd.c:1729 1729 raise(SIGSEGV); (gdb) l 1724 ser_error=MIN_int(lowest_ret, E_CFG); 1725 return -1; 1726 } 1727 if(lowest_ret!=E_CFG) { 1728 LM_ERR("failure to add branches\n"); 1729 raise(SIGSEGV); << raising exception to get the coredump 1730 } 1731 ser_error=lowest_ret; 1732 return lowest_ret; 1733 } ``` #### Log Messages ``` 4(34) ERROR: tm [ut.h:245]: uri2dst2(): bad_uri: sip:247.25.169.51:52307%3Btransport%3Dtls 4(34) ERROR: tm [t_fwd.c:1728]: t_forward_nonack(): failure to add branches ``` ### Possible Solutions This patch can fix the problem from the routing script : ``` if (is_method("OPTIONS") && uri!=myself) { $var(path_uri) = $(hdr(Route){re.subst,/<(.*)>/\1/}); if (defined $(var(path_uri){uri.params}) && $(var(path_uri){uri.params}{param.value,received}) != "") { $var(received) = $(var(path_uri){uri.params}{param.value,received}); if ($var(received) =~ "sip:.*:.*") { $du = $var(received); $avp(received) = $(var(path_uri){uri.params}{param.value,received}); avp_subst("$avp(received)", "/%3Btransport%3Dtcp/;transport=tcp/ig"); if ($avp(received) =~ "sip:.*:.*") { $du = $avp(received); } } t_relay(); } ``` ### Additional Information tested on 5.3.2, something changed during 5.3.0.dev, I will try to pin point the commit -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2255

4 years, 3 months

[kamailio/kamailio] kamailio packages for Ubuntu 20.04 (#2338)

by Henning Westerholt

It would be great if to deb.kamailio.org new packages for the new Ubuntu 20.04 could be added. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2338

4 years, 3 months

[kamailio/kamailio] segfault during avp destroy after t_continue / branching (#2421)

by malcolmohare

### Description I have an occasional segfault while executing this line. ``` $avp(set_to_a2a_reply) = $null; ``` The steps that occur up to this point are 1. host gets invite 2. host sees no online entries in location table 3. host does t_suspend 4. ... waiting ... 5. host receives xhttp request with transaction details to perform t_continue ``` $vn(result) = t_continue("$var(tx_hash_index)", "$var(tx_label)", "PUSHRESUME"); ``` 6. the pushresume route eventually does a lookup() finding an entry in the location table 7. we enter the branch route 8. the avp gets cleared with the null assignment 9. signal 11 *boom* This happens a few times a week, but the code path executes 800,000 times in a week so its pretty rare. ### Troubleshooting I've looked through the core dumps, looks to me like a memory issue but not 100% sure. #### Reproduction Unable to reproduce myself #### Debugging Data So the code at this failure is looking through the avp list found in crt_list and looking for the avp with a matching name to destroy. You can see at frame 0 that the avp address its trying to check against is not valid. I can't access ANY of the memory referenced by crt_list. The memory location looks pretty close to where the transaction cell is addressed. If you look at the sip message I've put under the stack trace, you may notice several "address out of bounds" fields, and if you look at the ua_instance field its printing the ua and then some other data appended (not sure if this is some gdb printing bug or its actually messed up). Is this indicative of running out of shm? ``` (gdb) print crt_list $1 = {0x7f590c6273c0, 0x7f590c6273c8, 0x7f590c6273d0, 0x7f590c6273d8, 0x7f590c6273e0, 0x7f590c6273e8} (gdb) print crt_list[0] $2 = (avp_list_t *) 0x7f590c6273c0 (gdb) print *crt_list[0] Cannot access memory at address 0x7f590c6273c0 (gdb) print t $3 = (struct cell *) 0x7f590c627238 (gdb) print *t Cannot access memory at address 0x7f590c627238 ``` If you need something specific from the bt please let me know. I have to double check the output to make sure there is no customer data in it before I paste it, so bt full is a bit tricky to provide. ``` #0 0x00000000009d2ab9 in match_by_name (avp=0x300f317375020c06, id=102, name=0x7ffe8098fd08) at usr_avp.c:378 #1 0x00000000009d510e in search_next_avp (s=0x7ffe8098fd00, val=0x0) at usr_avp.c:494 #2 0x00000000009d3ea2 in search_avp (ident=..., val=0x0, state=0x7ffe8098fd00) at usr_avp.c:462 #3 0x00000000009d2c1a in search_first_avp (flags=1, name=..., val=0x0, s=0x7ffe8098fd00) at usr_avp.c:414 #4 0x00000000009e7c70 in destroy_avps (flags=1, name=..., all=0) at usr_avp.c:1157 #5 0x00007f5da4f65f06 in pv_set_avp (msg=0x7ffe8099a250, param=0x7f5da6321060, op=254, val=0x7ffe8098ff20) at pv_core.c:1983 #6 0x0000000000589689 in lval_pvar_assign (h=0x7ffe80993280, msg=0x7ffe8099a250, lv=0x7f5da6321108, rv=0x7f5da6321248) at lvalue.c:351 #7 0x000000000058b6b7 in lval_assign (h=0x7ffe80993280, msg=0x7ffe8099a250, lv=0x7f5da6321108, rve=0x7f5da6321240) at lvalue.c:399 #8 0x000000000044662a in do_action (h=0x7ffe80993280, a=0x7f5da6321950, msg=0x7ffe8099a250) at action.c:1430 #9 0x000000000044b7ad in run_actions (h=0x7ffe80993280, a=0x7f5da6320e38, msg=0x7ffe8099a250) at action.c:1557 #10 0x000000000042743a in do_action (h=0x7ffe80993280, a=0x7f5da73203e0, msg=0x7ffe8099a250) at action.c:678 #11 0x000000000044b7ad in run_actions (h=0x7ffe80993280, a=0x7f5da73203e0, msg=0x7ffe8099a250) at action.c:1557 #12 0x0000000000430110 in do_action (h=0x7ffe80993280, a=0x7f5da7320510, msg=0x7ffe8099a250) at action.c:1045 #13 0x000000000044b7ad in run_actions (h=0x7ffe80993280, a=0x7f5da7320510, msg=0x7ffe8099a250) at action.c:1557 #14 0x000000000044c80c in run_top_route (a=0x7f5da7320510, msg=0x7ffe8099a250, c=0x7ffe80993280) at action.c:1643 #15 0x00007f5da523176e in prepare_new_uac (t=0x7f590c627238, i_req=0x7ffe8099a250, branch=1, uri=0x7ffe809933d0, path=0x7ffe809933b0, next_hop=0x7ffe809933c0, fsocket=0x0, snd_flags=..., fproto=0, flags=0, instance=0x7ffe809933a0, ruid=0x7ffe80993390, location_ua=0x7ffe80993380) at t_fwd.c:343 #16 0x00007f5da523c283 in add_uac (t=0x7f590c627238, request=0x7ffe8099a250, uri=0x7ffe8099a4c0, next_hop=0x7ffe8099a4d0, path=0x7ffe8099a888, proxy=0x0, fsocket=0x0, snd_flags=..., proto=0, flags=0, instance=0x7ffe8099a8a8, ruid=0x7ffe8099a8c0, location_ua=0x7ffe8099a8d0) at t_fwd.c:788 #17 0x00007f5da5250df1 in t_forward_nonack (t=0x7f590c627238, p_msg=0x7ffe8099a250, proxy=0x0, proto=0) at t_fwd.c:1668 #18 0x00007f5da537b879 in _w_t_relay_to (p_msg=0x7ffe8099a250, proxy=0x0, force_proto=0) at tm.c:1416 #19 0x00007f5da537f062 in w_t_relay (p_msg=0x7ffe8099a250, _foo=0x0, _bar=0x0) at tm.c:1630 #20 0x00000000004301a1 in do_action (h=0x7ffe80994b00, a=0x7f5da737d788, msg=0x7ffe8099a250) at action.c:1054 #21 0x000000000044b7ad in run_actions (h=0x7ffe80994b00, a=0x7f5da737d788, msg=0x7ffe8099a250) at action.c:1557 #22 0x000000000044c744 in run_actions_safe (h=0x7ffe8099a090, a=0x7f5da737d788, msg=0x7ffe8099a250) at action.c:1622 #23 0x0000000000776f29 in rval_get_int (h=0x7ffe8099a090, msg=0x7ffe8099a250, i=0x7ffe809950c8, rv=0x7f5da737d8c0, cache=0x0) at rvalue.c:912 #24 0x00000000007813c1 in rval_expr_eval_int (h=0x7ffe8099a090, msg=0x7ffe8099a250, res=0x7ffe809950c8, rve=0x7f5da737d8b8) at rvalue.c:1910 #25 0x000000000078204a in rval_expr_eval_int (h=0x7ffe8099a090, msg=0x7ffe8099a250, res=0x7ffe80995640, rve=0x7f5da737dfc8) at rvalue.c:1918 #26 0x000000000042f442 in do_action (h=0x7ffe8099a090, a=0x7f5da738ff88, msg=0x7ffe8099a250) at action.c:1030 #27 0x000000000044b7ad in run_actions (h=0x7ffe8099a090, a=0x7f5da737b458, msg=0x7ffe8099a250) at action.c:1557 #28 0x000000000042743a in do_action (h=0x7ffe8099a090, a=0x7f5da70ad478, msg=0x7ffe8099a250) at action.c:678 #29 0x000000000044b7ad in run_actions (h=0x7ffe8099a090, a=0x7f5da70acb58, msg=0x7ffe8099a250) at action.c:1557 #30 0x000000000043015e in do_action (h=0x7ffe8099a090, a=0x7f5da70ad5a8, msg=0x7ffe8099a250) at action.c:1049 #31 0x000000000044b7ad in run_actions (h=0x7ffe8099a090, a=0x7f5da70ad5a8, msg=0x7ffe8099a250) at action.c:1557 #32 0x000000000042743a in do_action (h=0x7ffe8099a090, a=0x7f5da7281608, msg=0x7ffe8099a250) at action.c:678 #33 0x000000000044b7ad in run_actions (h=0x7ffe8099a090, a=0x7f5da727d458, msg=0x7ffe8099a250) at action.c:1557 #34 0x0000000000430110 in do_action (h=0x7ffe8099a090, a=0x7f5da7294e18, msg=0x7ffe8099a250) at action.c:1045 #35 0x000000000044b7ad in run_actions (h=0x7ffe8099a090, a=0x7f5da7232a50, msg=0x7ffe8099a250) at action.c:1557 #36 0x000000000044c80c in run_top_route (a=0x7f5da7232a50, msg=0x7ffe8099a250, c=0x0) at action.c:1643 #37 0x00007f5da533d8ca in t_continue (hash_index=47761, label=1485553300, route=0x7f5da7232a50) at t_suspend.c:278 #38 0x00007f5da5158e8e in w_t_continue (msg=0x7ffe809a0050, idx=0x7f5da6da3b98 "0\264ڦ]\177", lbl=0x7f5da6da3cb8 "\230\330ڦ]\177", rtn=0x7f5da6da2f58 "\370\310ڦ]\177") at tmx_mod.c:658 #39 0x0000000000430350 in do_action (h=0x7ffe8099bc40, a=0x7f5da6dace70, msg=0x7ffe809a0050) at action.c:1072 #40 0x000000000044b7ad in run_actions (h=0x7ffe8099bc40, a=0x7f5da6dace70, msg=0x7ffe809a0050) at action.c:1557 #41 0x000000000044c744 in run_actions_safe (h=0x7ffe8099ff70, a=0x7f5da6dace70, msg=0x7ffe809a0050) at action.c:1622 #42 0x00000000005882ed in lval_pvar_assign (h=0x7ffe8099ff70, msg=0x7ffe809a0050, lv=0x7f5da6dacd38, rv=0x7f5da6dae780) at lvalue.c:282 #43 0x000000000058b6b7 in lval_assign (h=0x7ffe8099ff70, msg=0x7ffe809a0050, lv=0x7f5da6dacd38, rve=0x7f5da6dae778) at lvalue.c:399 #44 0x000000000044662a in do_action (h=0x7ffe8099ff70, a=0x7f5da6dab490, msg=0x7ffe809a0050) at action.c:1430 #45 0x000000000044b7ad in run_actions (h=0x7ffe8099ff70, a=0x7f5da6dab490, msg=0x7ffe809a0050) at action.c:1557 #46 0x000000000043015e in do_action (h=0x7ffe8099ff70, a=0x7f5da6dab5c0, msg=0x7ffe809a0050) at action.c:1049 #47 0x000000000044b7ad in run_actions (h=0x7ffe8099ff70, a=0x7f5da6dab5c0, msg=0x7ffe809a0050) at action.c:1557 #63 0x00000000005c4a87 in main (argc=16, argv=0x7ffe809a1f58) at main.c:2628 (gdb) frame 5 #5 0x00007f5da4f65f06 in pv_set_avp (msg=0x7ffe8099a250, param=0x7f5da6321060, op=254, val=0x7ffe8098ff20) at pv_core.c:1983 1983 pv_core.c: No such file or directory. (gdb) print *msg $6 = {id = 7307, pid = 12151, tval = {tv_sec = 1595776279, tv_usec = 968094}, fwd_send_flags = {f = 0 '\000', blst_imask = 0 '\000'}, rpl_send_flags = {f = 0 '\000', blst_imask = 0 '\000'}, first_line = {type = 1, flags = 1, len = 97, u = {request = {method = {s = 0x7f590a4f9958 <Address 0x7f590a4f9958 out of bounds>, len = 6}, uri = {s = 0x7f590a4f995f <Address 0x7f590a4f995f out of bounds>, len = 80}, version = { s = 0x7f590a4f99b0 <Address 0x7f590a4f99b0 out of bounds>, len = 7}, method_value = 1}, reply = {version = {s = 0x7f590a4f9958 <Address 0x7f590a4f9958 out of bounds>, len = 6}, status = { s = 0x7f590a4f995f <Address 0x7f590a4f995f out of bounds>, len = 80}, reason = {s = 0x7f590a4f99b0 <Address 0x7f590a4f99b0 out of bounds>, len = 7}, statuscode = 1}}}, via1 = 0x7f590a4fb528, via2 = 0x7f590a4fb6d0, headers = 0x7f590a4fb3e8, last_header = 0x7f590a4fc4f0, parsed_flag = 18446744073709551615, h_via1 = 0x7f590a4fb4e8, h_via2 = 0x7f590a4fb690, callid = 0x7f590a4fbf80, to = 0x7f590a4fbd28, cseq = 0x7f590a4fbfc0, from = 0x7f590a4fbae0, contact = 0x7f590a4fbf40, maxforwards = 0x7f590a4fbaa0, route = 0x0, record_route = 0x7f590a4fb4a8, content_type = 0x7f590a4fc430, content_length = 0x7f590a4fc470, authorization = 0x0, expires = 0x0, proxy_auth = 0x0, supported = 0x7f590a4fc070, require = 0x0, proxy_require = 0x0, unsupported = 0x0, allow = 0x7f590a4fc030, event = 0x0, accept = 0x0, accept_language = 0x0, organization = 0x0, priority = 0x0, subject = 0x0, user_agent = 0x7f590a4fc130, server = 0x0, content_disposition = 0x0, diversion = 0x0, rpid = 0x0, refer_to = 0x0, session_expires = 0x7f590a4fc0b0, min_se = 0x7f590a4fc0f0, sipifmatch = 0x0, subscription_state = 0x0, date = 0x0, identity = 0x0, identity_info = 0x0, pai = 0x0, ppi = 0x0, path = 0x0, privacy = 0x0, body = 0x0, eoh = 0x7f590a4fa57c <Address 0x7f590a4fa57c out of bounds>, unparsed = 0x7f590a4fa57c <Address 0x7f590a4fa57c out of bounds>, rcv = { src_ip = {af = 2, len = 4, u = {addrl = {2122129324, 0}, addr32 = {2122129324, 0, 0, 0}, addr16 = {8108, 32381, 0, 0, 0, 0, 0, 0}, addr = "\254\037}~", '\000' <repeats 11 times>}}, dst_ip = {af = 2, len = 4, u = {addrl = { 2122129324, 0}, addr32 = {2122129324, 0, 0, 0}, addr16 = {8108, 32381, 0, 0, 0, 0, 0, 0}, addr = "\254\037}~", '\000' <repeats 11 times>}}, src_port = 49204, dst_port = 5061, proto_reserved1 = 41848, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\300\064\254\037}~\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 13504, sin_addr = {s_addr = 2122129324}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = { sin6_family = 2, sin6_port = 13504, sin6_flowinfo = 2122129324, sin6_addr = {in6_u = {u6_addr8 = "\000\000\000\000\000\000\000\000`\236A\000\000\000\000", u6_addr16 = {0, 0, 0, 0, 40544, 65, 0, 0}, u6_addr32 = {0, 0, 4300384, 0}}}, sin6_scope_id = 2157584208}}, bind_address = 0x7f5da6139788, proto = 3 '\003'}, buf = 0x7f590a4f9958 <Address 0x7f590a4f9958 out of bounds>, len = 6799, new_uri = { s = 0x7f5da73ffe30 "sips:[redacted]@192.168.1.45:5061;transport=TLS;ob", len = 98}, dst_uri = { s = 0x7f5da7401a80 "sip:2Eo2OHMVoyb69QMH38d5rB/cFwQlrB/GAbSU@54.172.127.136:5062;transport=tls;lr;ob", len = 80}, parsed_uri_ok = 0, parsed_uri = {user = {s = 0x7f590a4f9964 <Address 0x7f590a4f9964 out of bounds>, len = 58}, passwd = {s = 0x0, len = 0}, host = {s = 0x7f590a4f999f <Address 0x7f590a4f999f out of bounds>, len = 16}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = SIPS_URI_T, flags = (unknown: 0), transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}}, parsed_orig_ruri_ok = 0, parsed_orig_ruri = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = { s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = (unknown: 0), transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = { s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}}, add_rm = 0x7f5da6fd52b8, body_lumps = 0x0, reply_lump = 0x7f590558ec20, add_to_branch_s = "z9hG4bK19ab.785259c573052806570cfa5c8301c629.1", '\000' <repeats 11 times>, add_to_branch_len = 46, hash_index = 47761, msg_flags = 144, flags = 75497472, set_global_address = {s = 0x0, len = 0}, set_global_port = {s = 0x0, len = 0}, force_send_socket = 0x0, force_tcp_connid = 0, path_vec = { s = 0x7f5da740d678 "<sip:2Eo2OHMVoyb69QMH38d5rB/cFwQlrB/GAbSU@54.172.127.136:5062;transport=tls;lr;ob>", len = 82}, claim = {s = 0x0, len = 0}, instance = {s = 0x7f5da73fd998 "1101D657-7037-4BB8-82F1-978CA802A249", len = 36}, reg_id = 1, ruid = {s = 0x7f5da73756a8 "uloc-d73b4347-5ed7bb86-14fe-b76cf179", len = 35}, location_ua = { s = 0x7f5da73fa9c8 "iPhone/iPhone10,2 ****MobileiOSComms/1.4.9696.0 PJSUA/iOS-2.5.5 WebRTC/******/v60.3112 iOS/13.5.1 ****** *****/2.2.3558562.5.5-svnCE_ACCOUNT_ID%g1A00866562DRS71QASCMV9", len = 131}, ldv = {flow = {decoded = 0, rcv = {src_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, dst_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, src_port = 0, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = { sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, 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}}, bind_address = 0x0, proto = 0 '\000'}}}} ``` #### Log Messages None #### SIP Traffic Not a specific message, this is random ### Possible Solutions None I can find ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 4.4.2 (x86_64/linux) 892ad6 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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: 892ad6 compiled on 17:55:07 Jul 2 2020 with x86_64-unknown-linux-gnu-gcc 4.9.4 ``` * **Operating System**: ``` Linux ip-172-31-114-254 4.14.181-108.257.amzn1.x86_64 #1 SMP Wed May 27 02:43:03 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2421

4 years, 3 months

[kamailio/kamailio] pua: different behavior depending on db_mode (#2414)

by Victor Seva

### Description If db_mode == 2 (PUA_DB_ONLY) ``SIP-If-Match`` header doesn't exists on dialog event ``` PUBLISH sip:testuser1003@spce.test SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bKcc38.e1cf4686000000000000000000000000.0 To: <sip:testuser1003@spce.test> From: <sip:testuser1003@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-86dabd12 CSeq: 10 PUBLISH Call-ID: 200464472a3c6cfc-497(a)127.0.0.1 Content-Length: 709 User-Agent: Sipwise NGCP Proxy 8.X Max-Forwards: 70 Event: dialog Expires: 23761 Content-Type: application/dialog-info+xml ``` same escenario but with db_mode == 0 ``` PUBLISH sip:testuser1002@spce.test SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5062;branch=z9hG4bK5e55.d35147e4000000000000000000000000.0 To: <sip:testuser1002@spce.test> From: <sip:testuser1002@spce.test>;tag=40bd18ec79e1d8f7e9c3f54805d1ecb3-84a3a447 CSeq: 10 PUBLISH Call-ID: 3cce05ee326f011b-24523(a)127.0.0.1 Content-Length: 682 User-Agent: Sipwise NGCP Proxy 8.X Max-Forwards: 70 Event: dialog Expires: 23761 SIP-If-Match: a.1596025051.24523.1.0 Content-Type: application/dialog-info+xml ``` #### Log Messages with db_mode == 0 ``` Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:406]: dialog_publish_multi(): CALLING dialog_publish for URI sip:testuser1002@spce.test Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:255]: build_dialoginfo(): new_body:#012<?xml version="1.0"?>#012<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:testuser1002@spce.test">#012 <dialog id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1" call-id="NGCP%invite_shared_line%///1-26774(a)127.126.0.1" local-tag="26774SIPpTag001" remote-tag="51E6E31F-5F2168FA000B8FF4-430B7700" direction="initiator">#012 <state>early</state>#012 <remote>#012 <identity>sip:testuser1003@spce.test</identity>#012 <target uri="sip:127.0.0.1:5085;transport=udp"/>#012 </remote>#012 <local>#012 <identity>sip:testuser1002@spce.test</identity>#012 <target uri="sip:testuser1002@127.126.0.1:51602"/>#012 </local>#012 </dialog>#012</dialog-info>#012 Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:315]: dialog_publish(): publish uri= sip:testuser1002@spce.test Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:50]: print_publ(): publ: Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:51]: print_publ(): uri= sip:testuser1002@spce.test Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:52]: print_publ(): id= DIALOG_PUBLISH.NGCP%invite_shared_line%///1-26774(a)127.126.0.1 Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:53]: print_publ(): expires= 23760 Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:498]: send_publish(): pres_uri=sip:testuser1002@spce.test Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [hash.c:132]: search_htable(): core_hash= 322 Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [hash.c:174]: search_htable(): no etag restriction Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [hash.c:183]: search_htable(): found record Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:587]: send_publish(): record found Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:673]: send_publish(): etag:a.1596025051.24523.1.0 Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:106]: publ_build_hdr(): UPDATE_TYPE [etag]= a.1596025051.24523.1.0 Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:683]: send_publish(): publ->pres_uri:#012sip:testuser1002@spce.test#012 Jul 29 14:18:03 sp1 proxy[24523]: DEBUG: <null> pua [send_publish.c:684]: send_publish(): str_hdr:#012Max-Forwards: 70#015#012Event: dialog#015#012Expires: 23761#015#012SIP-If-Match: a.1596025051.24523.1.0#015#012Content-Type: application/dialog-info+xml#015#012 130#012 ``` with db_mode == 2 ``` Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:406]: dialog_publish_multi(): CALLING dialog_publish for URI sip:testuser1002@spce.test Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:255]: build_dialoginfo(): new_body:#012<?xml version="1.0"?>#012<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:testuser1002@spce.test">#012 <dialog id="NGCP%invite_shared_line%///1-8362(a)127.126.0.1" call-id="NGCP%invite_shared_line%///1-8362(a)127.126.0.1" local-tag="8362SIPpTag001" remote-tag="18DEC3EE-5F2165A30000D6FF-42FB6700" direction="initiator">#012 <state>early</state>#012 <remote>#012 <identity>sip:testuser1003@spce.test</identity>#012 <target uri="sip:127.0.0.1:5085;transport=udp"/>#012 </remote>#012 <local>#012 <identity>sip:testuser1002@spce.test</identity>#012 <target uri="sip:testuser1002@127.126.0.1:51602"/>#012 </local>#012 </dialog>#012</dialog-info>#012 Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:315]: dialog_publish(): publish uri= sip:testuser1002@spce.test Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:50]: print_publ(): publ: Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:51]: print_publ(): uri= sip:testuser1002@spce.test Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:52]: print_publ(): id= DIALOG_PUBLISH.NGCP%invite_shared_line%///1-8362(a)127.126.0.1 Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua_dialoginfo [dialog_publish.c:53]: print_publ(): expires= 23760 Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:498]: send_publish(): pres_uri=sip:testuser1002@spce.test Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:564]: send_publish(): insert type Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:568]: send_publish(): UPDATE_TYPE and no record found Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:683]: send_publish(): publ->pres_uri:#012sip:testuser1002@spce.test#012 Jul 29 14:03:47 sp1 proxy[5714]: DEBUG: <null> pua [send_publish.c:684]: send_publish(): str_hdr:#012Max-Forwards: 70#015#012Event: dialog#015#012Expires: 23761#015#012Content-Type: application/dialog-info+xml#015#012 92#012 ``` ### Possible Solutions I think the problem here is that on db_mode == 2 pua never search for the pua record if no etag is set change introduced at https://github.com/kamailio/kamailio/commit/6822ff45e931ad3e93b22ebf7d1beb3… ### Additional Information * **Kamailio Version** - output of `kamailio -v` This is Sipwise's kamailio version based on 5.3.5 ``` version: kamailio 5.3.5 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, NO_SIG_DEBUG, DNS_IP_HACK, 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, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, 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 with gcc 8.3.0 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2414

4 years, 3 months

[kamailio/kamailio] pua: update_version_puadb() use pres_id to select record (#2420)

by Victor Seva

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #2414 #### Description * only relevant when db_mode is PUA_DB_ONLY * call_id/to_tag/from_tag values can be "", for instance with DIALOG_PUBLISH.* records. Then **ALL** records get version field update * update_vesion_puadb() is called from send_publish() and pres->id value is valid after a call to get_record_puadb() You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2420 -- Commit Summary -- * pua: update_version_puadb() use pres_id to select record -- File Changes -- M src/modules/pua/pua_db.c (20) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2420.patch https://github.com/kamailio/kamailio/pull/2420.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2420

4 years, 3 months

← Newer
1
...
7
8
9
10
11
12
13
...
39
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2020