[sr-dev] Re: [kamailio/kamailio] dmq_usrloc not replicating contact attributes (#1968)
This problem is almost more of a bug than enhancement and so it shouldn't be closed. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1968#issuecomment-1813796746 You are receiving this because you are subscribed to this thread. Message ID: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] Using PATH makes nathelper to send the SIP ping to itself (#2011)
This change is a very nice to have and shouldn't be closed. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2011#issuecomment-1813795417 You are receiving this because you are subscribed to this thread. Message ID: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] Allow function set_advertised_address to receive variable as parameter (#2137)
Has anyone figured out a clean alternative for this problem? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2137#issuecomment-1813794358 You are receiving this because you are subscribed to this thread. Message ID: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
Re: [sr-dev] [kamailio/kamailio] dialog: access dialog table by reference for dmq_send_all_dlgs (#2570)
Thank you very much @miconda! -- 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/2570#issuecomment-737509778___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] dialog DMQ replication worker stops processing msgs and consume all shmmem (#2547)
Created the pull request @miconda. I hope it is all right! -- 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/2547#issuecomment-736117037___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] dialog/dmq access dialog table by reference (#2570)
- Access to the d_table entries should be done by reference so there is no risk of race conditions to get and release the lock 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 #2547 Description It was seen the access to the d_table was not being made by reference on the function dmq_send_all_dlgs. It was then leading to race conditions where the same entry could have its lock changed elsewhere and then a dead lock would occur. By checking the code in other places where the d_table is used, everywhere it is accessed by reference, this function was the only one not following this logic. Changes were done to have "entry" as a reference to d_table and not a copy. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2570 -- Commit Summary -- * dialog/dmq access dialog table by reference -- File Changes -- M src/modules/dialog/dlg_dmq.c (10) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2570.patch https://github.com/kamailio/kamailio/pull/2570.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/2570 ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] dialog DMQ replication worker stops processing msgs and consume all shmmem (#2547)
Hello there, just checking if there are any feedback about this issue and our analysis? -- 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/2547#issuecomment-726417840___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] DMQ workers stops processing msgs and consume all shmmem (#2547)
### Description
Kamailio is configured to use the DMQ replication for dialog.
When running a load test Kamailio DMQ workers eventually becomes unresponsive
and stops processing DMQ messages. As a side effect the shm memory is fully
consumed then SIP processing stops happening properly and everything else stops
working due to that.
### Troubleshooting
Investigation showed that the DMQ workers are locked in the dmq_send_all_dlgs.
Debugging and studying the function it was identified that it is prone to data
inconsistency because it uses a copy of the (d_table->entries)[index] and not a
pointer to it. This gives a small window where a change in the d_table for that
entry can occur and changing the lock information before the copy can actually
get the lock making the process to get stuck in the lock get.
There is a need for some expert to validate this conclusion.
Reproduction
Run a simple load test making calls at a rate of ~5 cps and keep around ~2000
calls connected all the time. A higher cps seems to make it easier to reproduce
the problem.
Adding network degradation to the environment makes the problem happens, but
when running a tool such as SIPp for the load test, the retransmission can be
forced by simply killing the SIPp instance receiving calls which will then
force Kamailio to retransmit.
Debugging Data
```
7236 # DMQ WORKER
#0 0x7fa7bd760bf9 in syscall () from /lib64/libc.so.6
#1 0x7fa793395484 in futex_get (lock=0x7ffd072acaa4) at
../../core/futexlock.h:121
#2 0x7fa7933a123b in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657
(gdb) p entry
$1 = {first = 0x7fa79f8540d0, last = 0x7fa79f8540d0, next_id = 86622,
lock = {val = 2}, locker_pid = {val = 7211}, rec_lock_level = 0}
(gdb) p &entry->lock
$2 = (gen_lock_t *) 0x7ffd072acaa4
(gdb) p index
$3 = 187
(gdb) p (d_table->entries)[index]
$1 = {first = 0x0, last = 0x0, next_id = 86652, lock = {val = 0},
locker_pid = {val = 0}, rec_lock_level = 0}
(gdb) p entry
$2 = {first = 0x7fa79f8540d0, last = 0x7fa79f8540d0, next_id = 86622,
lock = {val = 2}, locker_pid = {val = 7211}, rec_lock_level = 0}
#3 0x7fa79339cfa3 in dlg_dmq_handle_msg (msg=0x7fa79fca15c8,
resp=0x7ffd072aceb0, node=0x7fa79ee93cb8) at dlg_dmq.c:391
#4 0x7fa793f3bb98 in worker_loop (id=0) at worker.c:113
#5 0x7fa793f39314 in child_init (rank=0) at dmq.c:296
#6 0x005990e8 in init_mod_child (m=0x7fa7bc735d98, rank=0) at
core/sr_module.c:780
#7 0x00598d5d in init_mod_child (m=0x7fa7bc736b00, rank=0) at
core/sr_module.c:776
#8 0x00598d5d in init_mod_child (m=0x7fa7bc737038, rank=0) at
core/sr_module.c:776
#9 0x00598d5d in init_mod_child (m=0x7fa7bc738eb8, rank=0) at
core/sr_module.c:776
#10 0x00598d5d in init_mod_child (m=0x7fa7bc73a0e0, rank=0) at
core/sr_module.c:776
#11 0x00598d5d in init_mod_child (m=0x7fa7bc73ab70, rank=0) at
core/sr_module.c:776
#12 0x00598d5d in init_mod_child (m=0x7fa7bc73d8e0, rank=0) at
core/sr_module.c:776
#13 0x00598d5d in init_mod_child (m=0x7fa7bc73e720, rank=0) at
core/sr_module.c:776
#14 0x00598d5d in init_mod_child (m=0x7fa7bc73f1b8, rank=0) at
core/sr_module.c:776
#15 0x00598d5d in init_mod_child (m=0x7fa7bc73fd08, rank=0) at
core/sr_module.c:776
#16 0x00598d5d in init_mod_child (m=0x7fa7bc740128, rank=0) at
core/sr_module.c:776
#17 0x00598d5d in init_mod_child (m=0x7fa7bc7409d0, rank=0) at
core/sr_module.c:776
#18 0x00598d5d in init_mod_child (m=0x7fa7bc7414d8, rank=0) at
core/sr_module.c:776
#19 0x00598d5d in init_mod_child (m=0x7fa7bc742cd8, rank=0) at
core/sr_module.c:776
#20 0x00598d5d in init_mod_child (m=0x7fa7bc742fc8, rank=0) at
core/sr_module.c:776
#21 0x00598d5d in init_mod_child (m=0x7fa7bc744ed0, rank=0) at
core/sr_module.c:776
#22 0x00598d5d in init_mod_child (m=0x7fa7bc745920, rank=0) at
core/sr_module.c:776
#23 0x00598d5d in init_mod_child (m=0x7fa7bc748d60, rank=0) at
core/sr_module.c:776
#24 0x00598d5d in init_mod_child (m=0x7fa7bc7498f8, rank=0) at
core/sr_module.c:776
#25 0x00599887 in init_child (rank=0) at core/sr_module.c:825
#26 0x0042ab2d in main_loop () at main.c:1763
#27 0x00433a96 in main (argc=12, argv=0x7ffd072aeb48) at main.c:2856
7237 # DMQ WORKER
#0 0x7fa7bd760bf9 in syscall () from /lib64/libc.so.6
#1 0x7fa793395484 in futex_get (lock=0x7ffd072acaa4) at
../../core/futexlock.h:121
#2 0x7fa7933a123b in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657
(gdb) p entry
$1 = {first = 0x7fa79f38bdb8, last = 0x7fa79f38bdb8, next_id = 15672,
lock = {val = 2}, locker_pid = {val = 7221}, rec_lock_level = 1}
(gdb) p &entry->lock
$2 = (gen_lock_t *) 0x7ffd072acaa4
(gdb) p index
$1 = 402
(gdb) p (d_table->entries)[index]
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
It is worth mentioning that the INVITE authentication which depends on the cseq tracking, still works fine after the change. -- 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/2535#issuecomment-722697944___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
After our change to == 0, the load test ran for over 20 hours with no problems! Just to be aligned we compiled the latest from the 5.4 branch and started running the test again. So far, 3h+ in with no problems. I think we are safe to say the deadlock is not happening anymore. Thank you for your effort Daniel! Also may I ask when is it expected the next 5.4 release? -- 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/2535#issuecomment-722165892___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
Also continuing the investigation we saw that the function dlg_cseq_msg_sent we saw it was processing a KDMQ message and went past the condition of your commit. However from the conversation it seemed DMQ message should not go through the track cseq logic. So after checking the patch, the condition of checking the tag len > 0 will always be false for the initial KDMQ, so based on the comment we changed the check to == 0. Is that a correct assumption? -- 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/2535#issuecomment-721527715___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
Hi Daniel, we've run the test, but unfortunately the problem happened again
after about 5 hours of test.
The UDP receiver had the DMQ lock (0x7f28bd321478) and tried to get the dialog
lock(0x7f28bdf8b5b4), and the Timer process got the dialog lock
(0x7f28bdf8b5b4) and tried to get the DMQ worker lock (0x7f28bd321478)...
Check the backtrace of the processes in deadlock:
1331udp receiver child=3 sock=45.116.131.61:5060
```
#0 0x7f28dca971c9 in syscall () from /lib64/libc.so.6
#1 0x7f28b269e5cd in futex_get (lock=0x7f28bdf8b5b4) at
../../core/mem/../futexlock.h:121
#2 0x7f28b26a7226 in dlg_lookup_mode (h_entry=2827, h_id=70761, lmode=0)
at dlg_hash.c:781
#3 0x7f28b26a7e4d in dlg_get_by_iuid (diuid=0x7f28b2958d40 <_dlg_ctx+64>)
at dlg_hash.c:849
#4 0x7f28b27393e0 in dlg_get_ctx_dialog () at dlg_var.c:940
#5 0x7f28b26c44fb in dlg_lookup_msg_dialog (msg=0x7ffe79df6bd0,
dir=0x7ffe79df6bcc) at dlg_handlers.c:1227
#6 0x7f28b26e4386 in dlg_cseq_msg_sent (evp=0x7ffe79df75e0) at
dlg_cseq.c:400
(gdb) p ((struct to_body*)(&msg)->to->parsed)->tag_value.len
$1 = 0
(gdb) p msg.first_line.u.request.method_value
$2 = 16384
(gdb) p *(((struct to_body*)(&msg)->to->parsed))
$9 = {error = 1, body = {
s = 0x7f28dbbb0714 "\r\nFrom:
;tag=9bf3c67f7017dfd69402f08ee6e7069c-d6bc8b8a\r\nCSeq:
10 KDMQ\r\nCall-ID: 4a4bd13913afec15-1331@45.116.131.61\r\nContent-Length:
310\r\nUs"..., len = 32}, uri = {
s = 0x7f28dbbb0715 "sip:dialog@10.61.187.66:5060>\r\nFrom:
;tag=9bf3c67f7017dfd69402f08ee6e7069c-d6bc8b8a\r\nCSeq:
10 KDMQ\r\nCall-ID: 4a4bd13913afec15-1331@45.116.131.61\r\nContent-Length:
310\r\nUse"..., len = 28}, display = {s = 0x0, len = 0},
tag_value = {s = 0x0, len = 0}, parsed_uri = {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}}, param_lst = 0x0, last_param = 0x0}
#7 0x00503088 in sr_event_exec (type=2, evp=0x7ffe79df75e0) at
core/events.c:240
#8 0x7f28b7035a43 in msg_send_buffer (dst=0x7f28bf3a8c28,
buf=0x7f28bee53140 "KDMQ sip:dialog@10.61.187.66:5060 SIP/2.0\r\nVia:
SIP/2.0/UDP 10.61.187.75;branch=z9hG4bK4646.29f4a7c1", '0' ,
".0\r\nTo: \r\nFrom:
"..., len=716, flags=0)
at ../../core/forward.h:148
#9 0x7f28b703aff9 in send_pr_buffer (rb=0x7f28bf3a8bd8,
buf=0x7f28bee53140, len=716) at t_funcs.c:69
#10 0x7f28b700d8eb in send_prepared_request_impl (request=0x7f28bf3a8bd8,
retransmit=1, branch=0) at uac.c:669
#11 0x7f28b700ee74 in t_uac_with_ids (uac_r=0x7ffe79df7c00, ret_index=0x0,
ret_label=0x0) at uac.c:753
#12 0x7f28b700eda0 in t_uac (uac_r=0x7ffe79df7c00) at uac.c:721
#13 0x7f28b7012038 in request (uac_r=0x7ffe79df7c00, ruri=0x7ffe79df7bd0,
to=0x7ffe79df7bd0, from=0x7ffe79df7be0, next_hop=0x0)
at uac.c:1089
#14 0x7f28b3281053 in dmq_send_message (peer=0x7f28bdf954a8,
body=0x7ffe79df7fb0, node=0x7f28be1bf270,
resp_cback=0x7f28b2956af0 , max_forwards=1,
content_type=0x7f28b2956ab0 )
at dmq_funcs.c:251
#15 0x7f28b327f4ff in bcast_dmq_message1 (peer=0x7f28bdf954a8,
body=0x7ffe79df7fb0, except=0x0,
resp_cback=0x7f28b2956af0 , max_forwards=1,
content_type=0x7f28b2956ab0 , incl_inactive=0)
at dmq_funcs.c:170
(gdb) p &dmq_node_list->lock
$1 = (gen_lock_t *) 0x7f28bd321478
#16 0x7f28b327f8d4 in bcast_dmq_message (peer=0x7f28bdf954a8,
body=0x7ffe79df7fb0, except=0x0,
resp_cback=0x7f28b2956af0 , max_forwards=1,
content_type=0x7f28b2956ab0 )
at dmq_funcs.c:188
#17 0x7f28b26f445c in dlg_dmq_send (body=0x7ffe79df7fb0, node=0x0) at
dlg_dmq.c:88
#18 0x7f28b26fdde4 in dlg_dmq_replicate_action (action=DLG_DMQ_STATE,
dlg=0x7f28be36a058, needlock=0, node=0x0) at dlg_dmq.c:628
#19 0x7f28b26ca370 in dlg_onroute (req=0x7f28dbee2088,
route_params=0x7ffe79df8340, param=0x0) at dlg_handlers.c:1559
#20 0x7f28b68f35c6 in run_rr_callbacks (req=0x7f28dbee2088,
rr_param=0x7ffe79df8430) at rr_cb.c:96
#21 0x7f28b69069b2 in after_loose (_m=0x7f28dbee2088, preloaded=0) at
loose.c:984
#22 0x7f28b69070dc in loose_route (_m=0x7f28dbee2088) at loose.c:1018
#23 0x7f28b690b240 in w_loose_route (msg=0x7f28dbee2088, p1=0x0, p2=0x0) at
rr_mod.c:276
#24 0x00472e48 in do_action (h=0x7ffe79df8fe0, a=0x7f28dbb11a38,
msg=
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
Hi Daniel, thanks for your review, appreciate it! We will test that change tomorrow but isn't it then also possible to fall in the deadlock when receiving/processing an invite? -- 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/2535#issuecomment-721047447___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
Actually I forget to mention that the track_cseq_updates was set to 0, not 1 as per your comment 0 is what breaks the authentication and also it was already set to 1 -- 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/2535#issuecomment-720885491___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
Hi Daniel, thanks for your attention! Regarding the tests you suggested, we ran all changes individually and both dm_worker and worker_usleep didn't work and problem still happened. The track_cseq_updates is still under test but is already running for 7 hours without having the issue. Usually the freeze was happening within the first 2 hours of test. Also considering the previous analysis we've done, we can see the function dlg_cseq_msg_sent is being called when the dead lock happened, so I guess this is a strong evidence there is something wrong with this feature + DMQ? Also I saw this commit https://github.com/kamailio/kamailio/commit/a309a0ee48278923871197391a30d485f0513a4f from yesterday, is this potentially a fix for this problem? -- 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/2535#issuecomment-720875687___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
The investigation done so far regarding the dead lock shows that 2 process
entered a dead lock, a udp worker and the timer process.
The timer process was trying to delete a dialog reference, and got the dialog
lock (d_table->entry lock) and then tried to get the DMQ node list lock.
On the other hand, the UDP worker was trying to broadcast a DMQ message, got
the DMQ node list lock and then tried to get the d_table entry lock for the
same dialog as the timer process.
```
N 21068 main process - attendant
Y 21247 udp receiver child=0 sock=124.47.168.242:5060 TRYING TO GET
LOCK 0x7f03675bdc48
Y 21248 udp receiver child=1 sock=124.47.168.242:5060 TRYING TO GET
LOCK 0x7f03675bdc48
Y 21249 udp receiver child=2 sock=124.47.168.242:5060 TRYING TO GET
LOCK 0x7f03675bdc48
Y 21250 udp receiver child=3 sock=124.47.168.242:5060 TRYING TO GET
LOCK 0x7f03675bdc48
Y 21251 udp receiver child=4 sock=124.47.168.242:5060 TRYING TO GET
LOCK 0x7f03675bdc48
Y 21252 udp receiver child=5 sock=124.47.168.242:5060 TRYING TO GET
LOCK 0x7f03675bdc48
Y 21253 udp receiver child=6 sock=124.47.168.242:5060 TRYING TO GET
LOCK 0x7f036822441c HAS LOCK 0x7f03675bdc48
Y 21254 udp receiver child=7 sock=124.47.168.242:5060
Y 21255 udp receiver child=0 sock=10.51.1.72:5060
Y 21257 udp receiver child=1 sock=10.51.1.72:5060
Y 21258 udp receiver child=2 sock=10.51.1.72:5060
Y 21260 udp receiver child=3 sock=10.51.1.72:5060
Y 21261 udp receiver child=4 sock=10.51.1.72:5060
Y 21262 udp receiver child=5 sock=10.51.1.72:5060
Y 21263 udp receiver child=6 sock=10.51.1.72:5060
Y 21264 udp receiver child=7 sock=10.51.1.72:5060
N 21265 slow timer
Y 21266 timer TRYING TO GET LOCK 0x7f03675bdc48 HAS
LOCK 0x7f036822441c
N 21267 secondary timer
N 21268 ctl handler
N 21269 JSONRPCS FIFO
Y 21270 DMQ WORKER TRYING TO GET LOCK 0x7f03675bdcd4
Y 21271 DMQ WORKER TRYING TO GET LOCK 0x7f03675bdcec
Y 21273 Dialog KA Timer
Y 21275 Dialog Clean Timer TRYING TO GET LOCK 0x7f036822441c
N 21278 WEBSOCKET KEEPALIVE
N 21279 WEBSOCKET TIMER
N 21281 TIMER NH
N 21282 TIMER NH
Y 21283 TIMER UAC REG
N 21284 tcp receiver (generic) child=0
N 21285 tcp receiver (generic) child=1
N 21286 tcp receiver (generic) child=2
N 21287 tcp receiver (generic) child=3
N 21289 tcp receiver (generic) child=4
N 21291 tcp receiver (generic) child=5
N 21292 tcp receiver (generic) child=6
N 21293 tcp receiver (generic) child=7
N 21294 tcp main process
```
21266 # timer BT:
```
#0 0x7f0386d30bf9 in syscall () from /lib64/libc.so.6
#1 0x7f035d4effa9 in futex_get (lock=0x7f03675bdc48) at
../../core/futexlock.h:121 <- TRYING TO GET LOCK 0x7f03675bdc48
#2 0x7f035d4f205b in bcast_dmq_message1 (peer=0x7f0368231ff0,
body=0x7ffe95bc0920, except=0x0, resp_cback=0x7f035cbc9af0
, max_forwards=1, content_type=0x7f035cbc9ab0
, incl_inactive=0)
at dmq_funcs.c:156
#3 0x7f035d4f28d4 in bcast_dmq_message (peer=0x7f0368231ff0,
body=0x7ffe95bc0920, except=0x0, resp_cback=0x7f035cbc9af0
, max_forwards=1, content_type=0x7f035cbc9ab0
) at dmq_funcs.c:188
#4 0x7f035c96704d in dlg_dmq_send (body=0x7ffe95bc0920, node=0x0) at
dlg_dmq.c:88
#5 0x7f035c9709d5 in dlg_dmq_replicate_action (action=DLG_DMQ_RM,
dlg=0x7f03684b77f8, needlock=0, node=0x0) at dlg_dmq.c:628
#6 0x7f035c90a39a in destroy_dlg (dlg=0x7f03684b77f8) at dlg_hash.c:367
#7 0x7f035c914064 in dlg_unref_helper (dlg=0x7f03684b77f8, cnt=2,
fname=0x7f035c9b222d "dlg_handlers.c", fline=1212) at dlg_hash.c:1081 << ---
GOT LOCK 0x7f036822441c
(gdb) p *d_entry
$2 = {first = 0x7f0369205248, last = 0x7f036855c680, next_id =
30442, lock = {val = 2}, locker_pid = {val = 21266}, rec_lock_level = 0}
(gdb) p dlg->h_entry
$3 = 2340
(gdb) p &d_entry->lock
$5 = (gen_lock_t *) 0x7f036822441c
#8 0x7f035c945bd2 in unref_dlg_from_cb (t=0x7f036936b678, type=131072,
param=0x7ffe95bc0e20) at dlg_handlers.c:1212
#9 0x7f03612d3165 in run_trans_callbacks_internal (cb_lst=0x7f036936b6f0,
type=131072, trans=0x7f036936b678, params=0x7ffe95bc0e20) at t_hooks.c:258
#10 0x7f03612d3297 in run_trans_callbacks (type=131072,
trans=0x7f036936b678, req=0x0, rpl=0x0, code=0) at t_hooks.c:285
#11 0x7f03611f9b8f in free_cell_helper (dead_cell=0x7f036936b678, silent=0,
fname=0x7f0361313363 "timer.c", fline=643) at h_table.c:165
#12 0x7f03612bfc4d in wait_handler (ti=1856451739, wait_tl=0x7f036936b700,
data=0x7f036936b678) at timer.c:643
#13 0x004ea094 in timer_list_expire (t=1856451739, h=0x7f036587d380,
slow_l=0x7f036587f948, sl
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
Thanks henningw! I was just wondering about some config in the DMQ or dialog which can be causing the issue because it looks like others in the community are using DMQ + dialog without issues. -- 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/2535#issuecomment-720155958___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
Hello, sorry for being pushy, but just hoping someone could acknowledge the problem or if this is some config on my side which is causing the issue. This is a major problem, it is worst than a crash, a manual intervention with kill -9 is necessary to restore the service back. -- 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/2535#issuecomment-719032733___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Kamailio freezes with DMQ and dialog (#2535)
### Description When running a load test Kamailio eventually becames unresponsive and stops processing calls. Kamilio is configured to use the DMQ replication for dialog and usrloc. Also the dialog keepalived is enabled. ### Troubleshooting >From investigation, the problem happens faster and easier when there is some >network degradation causing packet loss and/or retransmissions but even >without any noticeable network issue the freeze eventually happens. Reproduction Run a simple load test making calls at a rate of ~5 cps and keep around ~2000 calls connected all the time. A higher cps seems to make it easier to reproduce the problem. Adding network degradation to the environment makes the problem happens, but when running a tool such as SIPp for the load test, the retransmission can be forced by simply killing the SIPp instance receiving calls which will then force Kamailio to retransmit. Debugging Data Output of kamct trap: [gdb_kamailio_20201028_213030.txt](https://github.com/kamailio/kamailio/files/5455020/gdb_kamailio_20201028_213030.txt) Log Messages Local generated requests shows up in the log, but are not sent in the network ### Possible Solutions Not found so far ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 5.4.2 (x86_64/linux) c3b91f flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, 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 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: c3b91f compiled on 13:50:37 Oct 27 2020 with gcc 4.8.5 ``` * **Operating System**: ``` # cat /etc/centos-release CentOS Linux release 7.8.2003 (Core) # uname -a Linux hostname 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 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/2535___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Can't install kamailio-sipcapture-daemon-config package due to missing dependency (#1861)
Sorry to comment on a closed ticket, but this problem is happening again for the 5.2.8 version from the rpm.kamailio.org/centos repo. Looks like the fix was reverted somehow # yum install kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.intergrid.com.au * epel: fedora.mirror.serversaustralia.com.au * extras: mirror.nsw.coloau.com.au * updates: mirror.intergrid.com.au Resolving Dependencies --> Running transaction check ---> Package kamailio-sipcapture-daemon-config.x86_64 0:5.2.2-3.el7.centos will be updated ---> Package kamailio-sipcapture-daemon-config.x86_64 0:5.2.8-0.el7.centos will be an update --> Processing Dependency: kamailio-sipcapture = 5.2.8 for package: kamailio-sipcapture-daemon-config-5.2.8-0.el7.centos.x86_64 --> Finished Dependency Resolution Error: Package: kamailio-sipcapture-daemon-config-5.2.8-0.el7.centos.x86_64 (kamailio-5.2) Requires: kamailio-sipcapture = 5.2.8 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest -- 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/1861#issuecomment-714038968___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] $dns pseudovar does not allow direct index access on the addr attribute (#2179)
### Description
When trying to use the pseudovar $dns(xyz=>addr[0]) Kamailio script parser
complains there is a syntax error and script won't start. However if a variable
with value 0 is used, it works.
There is no reason why one should not access those indexes directly using the
value 0.
Piece of code that does not work:
```
if(dns_query("$rd", "ddst")) {
$var(dest_ip) = $dns(ddst=>addr[0]); # We just need first IP
}
```
Piece of code that works:
```
if(dns_query("$rd", "ddst")) {
$var(i) = 0;
$var(dest_ip) = $dns(ddst=>addr[$var(i)]); # We just need first IP
}
```
I tried using the 0 with quotes, but no luck. I had to use a variable to access
the index 0.
I have not tried the "type" attribute, maybe same problem can happen with it.
Reproduction
Try adding this piece of code to the script:
```
if(dns_query("$rd", "ddst")) {
$var(dest_ip) = $dns(ddst=>addr[0]); # We just need first IP
}
```
This will output this error when running kamailio -c:
```
0(22439) ERROR: ipops [ipops_pv.c:249]: pv_parse_dns_name(): invalid index
[ddst=>addr[0]]
0(22439) ERROR: ipops [ipops_pv.c:261]: pv_parse_dns_name(): error at PV dns
name: ddst=>addr[0]
0(22439) ERROR: [core/pvapi.c:952]: pv_parse_spec2(): pvar "dns" has an
invalid name param [ddst=>addr[0]]
0(22439) ERROR: [core/pvapi.c:1107]: pv_parse_spec2(): wrong char
[)/41] in [$dns(ddst=>addr[0])] at [18 (5)]
0(22439) CRITICAL: [core/cfg.y:3508]: yyerror_at(): parse error in
config file /etc/kamailio/routing.cfg, line 2398, column 20-38: Can't get from
cache: $dns(ddst=>addr[0])
```
### Possible Solutions
Instead of direct index access with integer values, it is necessary to access
it with a variable.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
# kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 67f967
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: 67f967
compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5
```
--
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/2179___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Evaluate deprecation of function t_newtran() (#2155)
### Description It was discovered that the function t_newtran() is causing a conflict with the transaction flags. When calling it before setting transaction flags, the flags are apparently lost, so for instance when using the ACC module, if the ACC flags are set after the t_newtran, these flags seems to get lost and no ACC entries are saved Some discussion around the t_newtran usage was already held in the past and it seems the function is not needed anymore to help detecting retransmissions, given the t_precheck_trans() can do this job without having to have an early creation of the transaction. Not sure if the t_newtran is necessary in any other scenario, but if it is not I think it should be deprecated. ### Reproduction Create simple script which uses ACC and the setflag to save ACC entries in DB. Verify ACC records are being saved properly. Before calling the setflag(), add a call to t_newtran(). Make calls and check ACC records are not saved anymore. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 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: 67f967 compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 ``` * **Operating System**: ``` # cat /etc/centos-release CentOS Linux release 7.7.1908 (Core) # uname -a Linux dev1-sbc-01 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019 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/2155___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Allow function set_advertised_address to receive variable as parameter (#2137)
After reading the purpose of the corex module, I think the idea can be changed to add a new function in the corex module which would do the same as the set_advertised_address, but accepting variables as parameters. Then there is no need to modify the old function. -- 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/2137#issuecomment-558876544___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] force_send_socket with pseudo variable (#2145)
Sergey, you can use the $fs variable for this purpose: $fs = $proto + ":" + $Ri + ":5060" But anyway, many old functions are string only and not all have an equivalent method that supports pseudo variables I think all legacy functions need a rework allowing pseudo-variables as parameter. -- 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/2145#issuecomment-557933506___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] s.select transformation not returning null for nonexistent indexes (#2128)
Closed #2128. -- 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/2128#event-2813242870___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] s.select transformation not returning null for nonexistent indexes (#2128)
Thanks for the info Daniel. I created the ticket because I thought the behaviour had changed at some point, but if it was always like this it is fine. I will close the ticket now. -- 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/2128#issuecomment-555745082___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] listen advertise using ACL (#2131)
Although you can workaround the issue with the set_advertised_address, I created this ticket https://github.com/kamailio/kamailio/issues/2137 to allow variables instead of strings as parameter for the function. -- 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/2131#issuecomment-555247160___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Allow function set_advertised_address to receive variable as parameter (#2137)
### Description Currently the functions set_advertised_address and set_advertised_port only accept strings as parameters. Trying to use it with variable causes an error. Having the function using a hard coded value is not a good practice and in order to add flexibility to the script in different installations it would be nice to have this function accepting variables. Also, the 'advertise' option on the 'listen' parameter is not always desired because it apply for all messages sent via the socket, and there are situations where different advertised IP for the same interface are necessary. ### Expected behavior set_advertised_address should receive a variable as parameter and use its value to change the SIP headers. ### Actual observed behavior Kamailio won't start if set_advertised_address is used with a variable due to script parse error or it will set the SIP message with the literal string "$var(test)" for example, instead of using the value of $var(test). ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 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: 67f967 compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 ``` * **Operating System**: ``` # uname -a Linux voice-conn-kamailio-1 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017 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/2137___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] listen advertise using ACL (#2131)
Just giving my 2 cents in this matter, but by having the function set_advertised_address accepting variables instead of only pure strings would probably help solving this problem in the script logic. I asked about this possibility not too long ago and Daniel pointed me out some workaround which I couldn't implement (http://sip-router.1086192.n5.nabble.com/set-advertised-address-with-variable-tp171746.html). Anyway I just think that the set_advertised_address function would give a lot more flexibility for scenarios like this where there isn't only one IP to advertise on the same listening IP. -- 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/2131#issuecomment-554863670___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] s.select transformation not returning null for nonexistent indexes (#2128)
### Description
When trying to iterate over a semi-colon separated string list, the s.select
transformation seems to be returning empty string instead of null, so the
suggested idea from here does not work ->
https://www.kamailio.org/wiki/tutorials/faq/main#how_to_iterate_through_the_ite
It is expected that the access to an invalid index would return null.
### Troubleshooting
avp and var variables were tried and both had the same result.
### Reproduction
Original piece of code is below. The while loop will run until the
max_while_loops is reached.
The "DEBUG" log line will print the loop iterator value and an empty string for
nonexistent values.
```
$var(allowed_headers) = "X-header1; X-header2;";
if (not_empty("$var(allowed_headers)")) {
xlog("L_NOTICE","Forwarding headers: $avp(allowed_headers)\n");
$var(i) = 0;
while($(var(allowed_headers){s.select,$var(i),;}) != $null)
{
xlog("L_NOTICE","DEBUG: $var(i) -
$(var(allowed_headers){s.select,$var(i),;})\n");
$var(hdr) =
$(var(allowed_headers){s.select,$var(i),;}{s.trim});
if (not_empty("$var(hdr)") &&
not_empty("$(hdr($var(hdr)))")) {
xlog("L_NOTICE","Header: $var(hdr):
$(hdr($var(hdr))) allowed\n");
append_hf("$var(hdr): $(hdr($var(hdr)))\r\n");
}
$var(i) = $var(i) + 1;
}
}
```
It is also possible to simulate it by simply doing this:
```
$var(allowed_headers) = "X-header1; X-header2;";
if ($(var(allowed_headers){s.select,100,;}) != $null) {
xlog("L_ERR","THIS IS WRONG :(");
}
```
### Possible Solutions
Other while conditions can be done. but this is the most elegant and is not
working For example, checking with "not_empty" works, but then we can't
actually have empty values in the semi-colon separated list because it would
stop the loop and entries after that would not be reached
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
# kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 67f967
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: 67f967
compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5
```
* **Operating System**:
```
# uname -a
Linux voice-conn-kamailio-1 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20
12:24:47 UTC 2017 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/2128___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] LCR stopper flag doesn't allow load balance of multiple identical rules (#2105)
Closed #2105. -- 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/2105#event-2732013395___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] LCR stopper flag doesn't allow load balance of multiple identical rules (#2105)
Hi Juha, Thanks for the info, I just tested the solution and it works! Appreciated your help! Cheers, Patrick -- 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/2105#issuecomment-544811210___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] LCR stopper flag can't be used with multiple identical rules (#2105)
### Description Multiple rules with the same prefix and with the stopper flag are added. All the rules have the same priority in the target table. When routing calls to this prefix (load_gw + next_gw), the LCR module does not load balance the calls, it always sends to the same GW. Reproduction Scenario is the following, the LCR rules have one default GW which is reachable via an empty rule. However, a certain prefix must not be sent there, so a rule with the stopper flag is added pointing to another GW. This works fine and the default GW is never attempted. However, for load balance purposes, it is necessary to send calls to this prefix to 2 different GWs. So another rule with the same prefix is added with the stopper flag set too. The target table was updated accordingly and has the same priority. When we have all this setup, by calling "next_gw()" we always get the same GW (which is random depending on the DB situation I think). The other(s) GW is never attempted. This does not allow to load balance 2 GWs for rules with the stopper flag. Given the stopper flag should prevent selecting shorter prefixes, it should not restrict the routing for rules with the same prefix (same length). Having this, the load balance of stopper rules would be possible. ### Possible Solutions Apparently, there is no workaround, expect by not using the stopper flag, however then there is a risk of sending calls to GWs with shorter prefix length which is not desired. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 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: 67f967 compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5 ``` * **Operating System**: ``` uname -a Linux uat1-sbc-0002 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:46 UTC 2019 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/2105___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Using PATH makes nathelper to send the SIP ping to itself (#2011)
Yes. As long as the script actually expects OPTIONS to an external domain, calling a loose_route() will route it properly. I usually do not allow OPTIONS passing through my Kamailio to external users but had to add this exception for this case, reason why I think a flag can be added to avoid this local loop and the extra logic in the script. -- 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/2011#issuecomment-513600873___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Using PATH makes nathelper to send the SIP ping to itself (#2011)
### Description When using the PATH header option to keep track of original Kamailio node that received the REGISTER, if nathelper is also used with SIP ping enabled, the SIP OPTIONS is sent to itself following the PATH header and not sent directly to the destination. The nathelper/user location modules should have a flag similar to the "path_check_local" of the registrar module, which is meant to avoid looping the message to itself in case the next hop pointed by the PATH header is "myself". ### Troubleshooting Reproduction Configure the registrar module to support PATH and before saving the contact info add the PATH header with the local Kamailio information. Also make sure to have the nathelper and usrloc modules configured to send the keepalive SIP OPTIONS to the registered extensions. By the time the SIP OPTIONS is sent, Kamailio sends to itself, then the message has to be loose_route'd to the final destination. This could be avoided by having the nathelper module to identify the next hop is Kamailio itself skipping this destination as a call to "lookup()" does for the registrar module when the flag path_check_local is true. SIP Traffic 172.128.128.10 is the Kamailio IP and 172.128.128.20 is the extension IP ``` 11:51:07.224713 IP (tos 0x60, ttl 64, id 64497, offset 0, flags [none], proto UDP (17), length 518) 172.128.128.10.5060 > 172.128.128.10.5060: SIP, length: 490 OPTIONS sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 Route: From: sip:s...@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 To: sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP Call-ID: 40ee1573-7506bba3-5e30c05@172.128.128.10 CSeq: 1 OPTIONS Content-Length: 0 11:51:07.226132 IP (tos 0x60, ttl 64, id 44359, offset 0, flags [none], proto UDP (17), length 502) 172.128.128.10.5060 > 172.128.128.20.5060: SIP, length: 474 OPTIONS sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 172.128.128.10;branch=z9hG4bKb958.b807e80b742db62504a45220d8f0e974.0 Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 From: sip:s...@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 To: sip:345671002@172.128.128.20:5060;rinstance=d1eb3444a5cec5a1;transport=UDP Call-ID: 40ee1573-7506bba3-5e30c05@172.128.128.10 CSeq: 1 OPTIONS Content-Length: 0 11:51:07.303474 IP (tos 0x0, ttl 128, id 10816, offset 0, flags [none], proto UDP (17), length 786) 172.128.128.20.5060 > 172.128.128.10.5060: SIP, length: 758 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.128.128.10;branch=z9hG4bKb958.b807e80b742db62504a45220d8f0e974.0 Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 Contact: To: ;tag=bb0c1f2d From: sip:s...@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 Call-ID: 40ee1573-7506bba3-5e30c05@172.128.128.10 CSeq: 1 OPTIONS Accept: application/sdp, application/sdp Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri User-Agent: Z 3.15.40006 rv2.8.20 Allow-Events: presence, kpml, talk Content-Length: 0 11:51:07.306821 IP (tos 0x60, ttl 64, id 64570, offset 0, flags [none], proto UDP (17), length 727) 172.128.128.10.5060 > 172.128.128.10.5060: SIP, length: 699 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.128.128.10:5060;branch=z9hG4bK2540713 Contact: To: ;tag=bb0c1f2d From: sip:s...@mydomain.com;tag=uloc-5d2e6499-2fb5-1-0-c15309d2 Call-ID: 40ee1573-7506bba3-5e30c05@172.128.128.10 CSeq: 1 OPTIONS Accept: application/sdp, application/sdp Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Supported: replaces, norefersub, extended-refer, timer, outbound, path, X-cisco-serviceuri User-Agent: Z 3.15.40006 rv2.8.20 Allow-Events: presence, kpml, talk Content-Length: 0 ``` ### Possible Solutions Not found. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 5.2.2 (x86_64/linux) 67f967 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
[sr-dev] [kamailio/kamailio] dmq_usrloc not replicating contact attributes (#1968)
### Description
The dmq_usrloc module is not replicating the extra attributes saved in the xavp
for the contact. So remote nodes don't receive these values, being unable to
access it properly.
It is expected that the attributes are replicated as well.
Reproduction
Setup two nodes using the dmq_usrloc and usrloc in db_mode=0.
When receiving a REGISTER, before saving the contact add some attribute in the
xavp_contact. In a subsequent message to this contact (e.g.: INVITE) use a
lookup() or registered() and try to access the desired xavp_contact attribute.
If the request is received in the local node (which received the original
REGISTER), the attribute will be valid, but if the request is received in the
remote node, the attribute is empty.
Log Messages
```
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: registrar
[save.c:410]: pack_ci(): generated ruid is: uloc-5cee2114-5abe-2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
[ucontact.c:73]: ucontact_xavp_store(): trying to clone per contact xavps
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG:
[core/xavp.c:697]: xavp_clone_level_nodata(): cloned root xavp [ulattrs]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG:
[core/xavp.c:721]: xavp_clone_level_nodata(): cloned inner xavp [cluster_node]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
[ucontact.c:1701]: update_ucontact(): exists callback for type=
UL_CONTACT_UPDATE
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc
[ul_callback.h:84]: run_ul_callbacks(): contact=0x7f51b624d418, callback type
2/15, id 1 entered
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:776]: dmq_ul_cb_contact(): Callback from usrloc with type=2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:427]: init_usrloc_dmq_recv(): Initializing usrloc_dmq_recv for
pid (23230)
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:785]: dmq_ul_cb_contact(): Replicating local update to other
nodes...
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:746]: usrloc_dmq_send_contact(): sending serialized data
{"action":1,"aor":"345671002","ruid":"uloc-5cee20df-5953-1","c":"sip:345671002@172.28.128.200:5060;rinstance=38e53fed7e84e081;transport=UDP","received":"","path":"","callid":"NOeeFh1Bh5JR0eJG8DENkg..","user_agent":"Z
3.15.40006
rv2.8.20","instance":"","expires":1559110577,"cseq":12,"flags":0,"cflags":3072,"q":-1,"last_modified":1559109977,"methods":4294967295,"reg_id":0,"server_id":0}
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc
[usrloc_sync.c:315]: usrloc_dmq_send(): sending dmq broadcast...
```
### Possible Solutions
Only workaround seems to use usrloc with db_mode=3 and then not use the
dmq_usrloc, having the usrloc with attributes info shared via the DB
### Additional Information
Kamailio 5.2.2 installed from the repo.
```
# kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 67f967
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: 67f967
compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5
```
* **Operating System**:
```
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
# uname -a
Linux kamailio-2 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017
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/1968___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Add optional parameter to ds_is_from_list() to check only active GW (#1908)
### Description Currently ds_is_from_list() matches all GWs in the dispatcher list, not considering if the GW is disabled or not. It might have situation where a GW is permanently disabled but can't be removed (because of CDR references for instance). In this case it is not desired to match a disabled GW in the test. The function should accept a new parameter which will tell if it should or not match disabled GWs. For backward compatibility, it should not be a mandatory parameter and its default value should be to match disabled GW (as it is today). ### Expected behavior ds_is_from_list() should return false in case it matches a disabled GW and the new parameter tells not to match disabled GWs. -- 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/1908___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Terminated Websocket connection keeps logging "forcibly closing connection" (#1886)
Daniel, something was really fixed in the 5.2.2 version because now the error message about the closed websocket are not happening anymore. It's been one week with no occurrence. On version 5.2.1, it was pretty common to start seeing the message at some point. -- 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/1886#issuecomment-474197302___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Terminated Websocket connection keeps logging "forcibly closing connection" (#1886)
Closed #1886. -- 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/1886#event-2212402712___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Terminated Websocket connection keeps logging "forcibly closing connection" (#1886)
Thanks Daniel. I will upgrade my server and keep testing to see whether it happens again or not! Kind regards, Patrick Wakano -- 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/1886#issuecomment-472202166___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Terminated Websocket connection keeps logging "forcibly closing connection" (#1886)
### Description In my WebRTC setup, I have Kamailio receiving connections from the WebRTC clients (JSSip and SIPML5). Very frequently the logs starts showing the error messages below. These messages happen every second, so it flood the log files with this message. Besides that, since it keeps repeating for a very long time, it is also a concern that Kamailio didn't properly cleaned some internal data, and actually falls under a situation it can't do that anymore. This could consume resources and lead to some performance impact. ``` Mar 12 03:30:31 dev1-sbcaio-01 /usr/sbin/kamailio[6785]: WARNING: websocket [ws_frame.c:813]: ws_keepalive(): forcibly closing connection Mar 12 03:30:31 dev1-sbcaio-01 /usr/sbin/kamailio[6785]: ERROR: websocket [ws_conn.c:377]: wsconn_close_now(): getting TCP/TLS connection ``` ### Troubleshooting >From investigation it is not 100% sure, but it looks like the problem happens >when the websocket connection is abruptly terminated (not from the browser). The kamcmd ws.dump command shows no active connections. Reproduction Register to Kamailio via websocket connection with JSSIP (https://tryit.jssip.net/) or SIPML5 (https://www.doubango.org/sipml5/call.htm) clients. After registered and with connection opened, put the computer to sleep. Some time after that the "ws_keepalive(): forcibly closing connection" will start happening in the logs. Unfortunately, sometimes this procedure does not cause the problem (I guess the browser properly terminates the websocket connection), but was the closest I got to reproducing the error. Log Messages Logs for debug=3 ``` Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [8] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe375617b30] refcnt [10627] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: WARNING: websocket [ws_frame.c:813]: ws_keepalive(): forcibly closing connection Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:333]: wsconn_rm(): wsconn_rm for [0x7fe375617b30] refcnt [10627] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:417]: wsconn_put_mode(): wsconn_put start for [0x7fe375617b30] refcnt [10627] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:431]: wsconn_put_mode(): wsconn_put end for [0x7fe375617b30] refcnt [10626] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: ERROR: websocket [ws_conn.c:377]: wsconn_close_now(): getting TCP/TLS connection Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [8] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe375617b30] refcnt [10627] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [5] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe3755bf3f8] refcnt [23851] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [5] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe3755bf3f8] refcnt [23852] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [7] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe3755f59d8] refcnt [20786] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [7] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe3755f59d8] refcnt [20787] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [12] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe375647ea8] refcnt [19629] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [12] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe375647ea8] refcnt [19630] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:452]: wsconn_get(): wsconn_get for id [6] Mar 12 03:30:36 kamailio-sbc /usr/sbin/kamailio[6785]: DEBUG: websocket [ws_conn.c:459]: wsconn_get(): wsconn_get returns wsc [0x7fe3755e58b0] refcnt [20803] Mar 12 03:30:36 kamailio-sbc /
Re: [sr-dev] [kamailio/kamailio] Can't install kamailio-sipcapture-daemon-config package due to missing dependency (#1861)
Hi Sergey, Check below. I think it is ok. It is not properly configured so it dies after the start, but service itself is there. ``` # systemctl status sipcapture.service ● sipcapture.service - Kamailio SIP router server daemon for sipcapture Loaded: loaded (/usr/lib/systemd/system/sipcapture.service; enabled; vendor preset: disabled) Active: inactive (dead) # systemctl start sipcapture # systemctl status sipcapture.service ● sipcapture.service - Kamailio SIP router server daemon for sipcapture Loaded: loaded (/usr/lib/systemd/system/sipcapture.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2019-02-20 17:07:57 AEDT; 1s ago Main PID: 17547 (kamailio) CGroup: /system.slice/sipcapture.service ├─17547 /usr/sbin/kamailio -DD -P /run/sipcapture/sipcapture.pid -f /etc/kamailio/kamailio-sipcapture.cfg -m 32 -M 4 └─17568 /usr/sbin/kamailio -DD -P /run/sipcapture/sipcapture.pid -f /etc/kamailio/kamailio-sipcapture.cfg -m 32 -M 4 ``` -- 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/1861#issuecomment-466877632___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Can't install kamailio-sipcapture-daemon-config package due to missing dependency (#1861)
Hi Sergey, I think so. Check below what was installed. Is that what you expected? ``` # repoquery --list kamailio-sipcapture-daemon-config /etc/kamailio/kamailio-sipcapture.cfg /etc/sysconfig/sipcapture /usr/lib/systemd/system/sipcapture.service /usr/lib/tmpfiles.d/sipcapture.conf ``` -- 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/1861#issuecomment-466840718___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Can't install kamailio-sipcapture-daemon-config package due to missing dependency (#1861)
Hi Sergey, I just tested and now it is installing fine! Thanks for your time! Patrick Wakano ``` # yum install kamailio-sipcapture-daemon-config-5.2.1 Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.ventraip.net.au * epel: fedora.mirror.serversaustralia.com.au * extras: centos.mirror.serversaustralia.com.au * updates: mirror.ventraip.net.au Resolving Dependencies --> Running transaction check ---> Package kamailio-sipcapture-daemon-config.x86_64 0:5.2.1-2.el7.centos will be installed --> Finished Dependency Resolution Dependencies Resolved = Package Arch Version Repository Size = Installing: kamailio-sipcapture-daemon-configx86_64 5.2.1-2.el7.centoshome_kamailio_v5.2.x-rpms 15 k Transaction Summary = Install 1 Package Total download size: 15 k Installed size: 39 k Is this ok [y/d/N]: y Downloading packages: kamailio-sipcapture-daemon-config-5.2.1-2.el7.centos.x86_64.rpm | 15 kB 00:00:02 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : kamailio-sipcapture-daemon-config-5.2.1-2.el7.centos.x86_64 1/1 Verifying : kamailio-sipcapture-daemon-config-5.2.1-2.el7.centos.x86_64 1/1 Installed: kamailio-sipcapture-daemon-config.x86_64 0:5.2.1-2.el7.centos Complete! ``` -- 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/1861#issuecomment-466273358___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Can't install kamailio-sipcapture-daemon-config package due to missing dependency (#1861)
kamailio-sipcapture-daemon-config can't be installed because it depends on the kamailio-sipcapture package, which can't be found... Use the http://download.opensuse.org/repositories/home:/kamailio:/v5.2.x-rpms/CentOS_7/ repo and try to install the kamailio-sipcapture-daemon-config. The dependency can't be resolved and so the package does not install. It is not clear if the dependency is missing or if it is not valid. ``` # yum install kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au Resolving Dependencies --> Running transaction check ---> Package kamailio-sipcapture-daemon-config.x86_64 0:5.2.1-1.el7.centos will be installed --> Processing Dependency: kamailio-sipcapture = 5.2.1 for package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 --> Finished Dependency Resolution Error: Package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 (home_kamailio_v5.2.x-rpms) Requires: kamailio-sipcapture = 5.2.1 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest # yum deplist kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au package: kamailio-sipcapture-daemon-config.x86_64 5.2.1-1.el7.centos dependency: /bin/sh provider: bash.x86_64 4.2.46-31.el7 dependency: kamailio-sipcapture = 5.2.1 Unsatisfied dependency ``` * **Operating System**: ``` # uname -a Linux voice-conn-kamailio-1 3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) ``` -- 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/1861___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Broken Kamailio repository for CentOS 7 (#1604)
Reopened #1604. -- 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/1604#event-1939535594___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Broken Kamailio repository for CentOS 7 (#1604)
Closed #1604. -- 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/1604#event-1939535428___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Broken Kamailio repository for CentOS 7 (#1604)
Hello @sergey-safarov and @miconda, Was this task done? Just tried today and the installation from the opensuse repo is not working Running the "clean metadata" does not solve the problem. Patrick Wakano `Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. kamailio-auth-ephemeral-5.0.7- FAILED 4% [===- ] 0.0 B/s | 464 kB --:--:-- ETA http://download.opensuse.org/repositories/home%3A/kamailio%3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-auth-ephemeral-5.0.7-7.el7.centos.x86_64.rpm: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=home_kamailio_v5.0.x-rpms clean metadata Trying other mirror. ` -- 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/1604#issuecomment-434917791___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Broken Kamailio repository for CentOS 7 (#1604)
### Description Centos RPM repo is generating Kamailio 5.0.7 packages that can't be installed ### Troubleshooting Reproduction By using the repo https://download.opensuse.org/repositories/home:/kamailio:/v5.0.x-rpms/CentOS_7/home:kamailio:v5.0.x-rpms.repo when trying to install Kamailio 5.0.7, yum returns this error: ``` Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. kamailio-5.0.7-3.el7.centos.x8 FAILED http://download.opensuse.org/repositories/home%3A/kamailio%3A/v5.0.x-rpms/CentOS_7/x86_64/kamailio-5.0.7-3.el7.centos.x86_64.rpm: [Errno 14] HTTP Error 416 - Requested Range Not Satisfiable Trying other mirror. ``` Debugging Data Log Messages SIP Traffic ### Possible Solutions ### Additional Information * **Operating System**: ``` $ cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) ``` -- 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/1604___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Memory leak after SIP message fails to be sent due to no socket found (#1554)
Hi Daniel, I am using the RPM packages for CentOS so I was not able to make my environment work with head from Master so easily. nonetheless I applied the change to the head of 5.0 branch and it did work fine! No more increase in the "delayed_free", instead it counted on the "freed" stat. Also no memory leak was observed as well! Thank you very much! -- 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/1554#issuecomment-395298233___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Memory leak after SIP message fails to be sent due to no socket found (#1554)
Hi Daniel, Thanks for the prompt reply! I will try to test your patch by today! This is the case I detected the problem. During investigation, I also saw same problem with the SIP ping from the LCR module, but I guessed they had the same root cause in the TM module. -- 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/1554#issuecomment-395240621___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Memory leak after SIP message fails to be sent due to no socket found (#1554)
### Description When SIP message fails to be sent due to no socket found, apparently the TM module is not deleting the transaction and so it is causing a memory leak. ### Troubleshooting Reproduction The easiest way to reproduce the problem is to setup a dispatcher destination with SIP ping enabled. Kamailio should not be listening to the interface which is used to reach that destination. So this will cause Kamailio to complain about not finding a socket to send the OPTIONS. After this happens, it is possible to see from the **kamcmd tm.stats** command that the "created" has increased by 1, freed has not changed and "delayed_free" also increased by 1. Problem is that the delayed_free never gets freed and after checking the **kamcmd core.shmmem**, for every failed OPTIONS request under this condition, 5808 bits are leaked... This goes on until there is no shared memory left. Debugging Data Log Messages ``` /usr/sbin/kamailio[20755]: DEBUG: dispatcher [dispatch.c:2664]: ds_ping_set(): probing set #2, URI sip:10.11.12.13:6060 /usr/sbin/kamailio[20755]: DEBUG: tm [uac.c:427]: t_uac_prepare(): next_hop= /usr/sbin/kamailio[20755]: DEBUG: [core/resolve.c:1225]: srv_sip_resolvehost(): 10.11.12.13:6060 proto=0 /usr/sbin/kamailio[20755]: DEBUG: [core/resolve.c:1346]: srv_sip_resolvehost(): returning 0xada520 (10.11.12.13:6060 proto=1) /usr/sbin/kamailio[20755]: DEBUG: [core/forward.c:174]: get_out_socket(): socket determined: 0x7f33189ee298 /usr/sbin/kamailio[20755]: DEBUG: tm [uac.c:152]: dlg2hash(): hashid 8554 /usr/sbin/kamailio[20755]: DEBUG: tm [uac.c:238]: t_run_local_req(): executing event_route[tm:local-request] /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:600]: parse_msg(): SIP Request: /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:602]: parse_msg(): method: /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:604]: parse_msg(): uri: /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:606]: parse_msg(): version: /usr/sbin/kamailio[20755]: DEBUG: [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, = ; state=16 /usr/sbin/kamailio[20755]: DEBUG: [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:491]: parse_headers(): Via found, flags=2 /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:493]: parse_headers(): this is the first via /usr/sbin/kamailio[20755]: DEBUG: [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:171]: get_hdr_field(): [25]; uri=[sip:10.11.12.13:6060] /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:172]: get_hdr_field(): to body [#015#012] /usr/sbin/kamailio[20755]: DEBUG: [core/parser/msg_parser.c:152]: get_hdr_field(): cseq : <10> /usr/sbin/kamailio[20755]: DEBUG: pv [pv_trans.c:564]: tr_eval_string(): i=0 j=10 /usr/sbin/kamailio[20755]: NOTICE:
