[SR-Users] Re: Kamailio 5.6 (and 5.7) core dumping.
Hi Mattis, We tried v5.6 and v5.7.2 also, in both of them the crash occurs. Peter From: Mattis Lind Date: Monday, 2024. January 29. 13:52 To: Dr. Barabás Péter Cc: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Kamailio 5.6 (and 5.7) core dumping. Hello Péter, Den ons 24 jan. 2024 kl 09:58 skrev Dr. Barabás Péter mailto:dr.peter.bara...@gmail.com>>: Hi Mattis, I have similar cases: https://github.com/kamailio/kamailio/issues/3522 Indeed it looks very similar. One of the core dumps we have seen is identical to one of those that you provided in your report. Question: is $uac_req(evroute) set to 1 and do you handle uac:reply event route? In my case crash only occurs when these are true. If I switch evroute off, no crash occurs. Yes, we have $uac_req(evroute) set to 1 and handle the uac:reply event route. We tested removing those but it had a lot of side-effects we weren't aware of in the rest of our system so we could enable it in our staging environment. What other versions of Kamailio have you tested? We have reverted back to 5.5 and so far it seems to be working, but we have had very little run time on it so we are not convinced yet. The problem is that there is a feature in the nathelp modules (alias_name) that we would like to have which only exists from 5.6 and onwards. /Mattis Péter Barabás From: Mattis Lind via sr-users mailto:sr-users@lists.kamailio.org>> Date: Wednesday, 2024. January 24. 9:46 To: Kamailio (SER) - Users Mailing List mailto:sr-users@lists.kamailio.org>> Cc: Mattis Lind mailto:mattisl...@gmail.com>> Subject: [SR-Users] Kamailio 5.6 (and 5.7) core dumping. Hello Kamailio list! We have a scenario that makes use of the UAC-module to send SIP MESSAGE and then in some cases the Kamailio process core dumps after some time after processing messages. I have been able to gather a core dump which shows this backtrace appended below. We are using Kamailio 5.6 retrieved from the kamailio repository: http://deb.kamailio.org/kamailio56. We are running Kamailio in a Docker container which runs on "5.10.0-25-cloud-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16) x86_64 GNU/Linux" We have previously tried to use Kamailio 5.7 but it gave the same type of crashes. We have been using the uac module a lot but it is just in this scenario we get a core dump. We have some kind of relation to a specific scenario but it can take from several seconds from the last SIP message of this scenario up to 50 minutes until the crash occurs. To me this sounds like some kind of cleanup that is not handled properly. The back trace indicates that free of shared memory could be the issue, but I don't know the code unfortunately. The last things we see in the log file is: 2024-01-23T13:18:08.828+01:00 Jan 23 12:18:08 /usr/sbin/kamailio[4789]: INFO:
[SR-Users] Re: Kamailio 5.6 (and 5.7) core dumping.
Hi Mattis, I have similar cases: https://github.com/kamailio/kamailio/issues/3522 Question: is $uac_req(evroute) set to 1 and do you handle uac:reply event route? In my case crash only occurs when these are true. If I switch evroute off, no crash occurs. Péter Barabás From: Mattis Lind via sr-users Date: Wednesday, 2024. January 24. 9:46 To: Kamailio (SER) - Users Mailing List Cc: Mattis Lind Subject: [SR-Users] Kamailio 5.6 (and 5.7) core dumping. Hello Kamailio list! We have a scenario that makes use of the UAC-module to send SIP MESSAGE and then in some cases the Kamailio process core dumps after some time after processing messages. I have been able to gather a core dump which shows this backtrace appended below. We are using Kamailio 5.6 retrieved from the kamailio repository: http://deb.kamailio.org/kamailio56. We are running Kamailio in a Docker container which runs on "5.10.0-25-cloud-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16) x86_64 GNU/Linux" We have previously tried to use Kamailio 5.7 but it gave the same type of crashes. We have been using the uac module a lot but it is just in this scenario we get a core dump. We have some kind of relation to a specific scenario but it can take from several seconds from the last SIP message of this scenario up to 50 minutes until the crash occurs. To me this sounds like some kind of cleanup that is not handled properly. The back trace indicates that free of shared memory could be the issue, but I don't know the code unfortunately. The last things we see in the log file is: 2024-01-23T13:18:08.828+01:00 Jan 23 12:18:08 /usr/sbin/kamailio[4789]: INFO:
[SR-Users] Re: uac_req_send + evroute + crash
Hi,
I made a dirty workaround in kamailio script and set $uac_req(evroute) = 0
therefore event_route[uac:reply] is not used. Crash has disappeared. But it is
not the solution not to use uac:reply route.
Has anyone idea, what can the cause of this crash?
Thanks
Peter
From: Péter Dr. Barabás
Date: Wednesday, 2023. December 6. 11:29
To: Kamailio (SER) - Users Mailing List
Cc: Dr. Barabás Péter
Subject: Re: [SR-Users] Re: uac_req_send + evroute + crash
Hello,
Any idea about the crash below? I found a ticket regarding to this, I made some
comments and backtraces there also:
https://github.com/kamailio/kamailio/issues/3635
Now this crash is very frequently, 3-4 times every day. There is a timer
mechnism, where kamailio refreshes registrations towards asterisk automically
to ensure continuous availability for mobile users.
The crash exists 3-5 secs after this refresh process, but not always. Sometimes
this process runs fine only CRITICAL logs appears (mentioned below) after it,
but sometimes kamailio crashes during writing these CRITICAL logs.
Peter
From: Dr. Barabás Péter via sr-users
Date: Wednesday, 2023. November 15. 17:03
To: Kamailio (SER) - Users Mailing List
Cc: Dr. Barabás Péter
Subject: [SR-Users] Re: uac_req_send + evroute + crash
Hello Daniel,
I’m using kamailio 5.7.2 currently and this misterious crash occurs again. Now
core files are generated also, here is the trace:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7fae9a2d0859 in __GI_abort () at abort.c:79
#2 0x5614ad79afd8 in qm_debug_check_frag (qm=0x7fae78e77000,
f=0x7fae79805028, file=0x7fae77c8c134 "uac: uac_send.c", line=860,
efile=0x5614ad936f99 "core/mem/q_malloc.c", eline=511) at
core/mem/q_malloc.c:129
#3 0x5614ad79f7c1 in qm_free (qmp=0x7fae78e77000, p=0x7fae79805060,
file=0x7fae77c8c134 "uac: uac_send.c", func=0x7fae77c8cf10 <__func__.15157>
"uac_send_tm_callback", line=860, mname=0x7fae77c8c014 "uac") at
core/mem/q_malloc.c:511
#4 0x5614ad7ab410 in qm_shm_free (qmp=0x7fae78e77000, p=0x7fae79805060,
file=0x7fae77c8c134 "uac: uac_send.c", func=0x7fae77c8cf10 <__func__.15157>
"uac_send_tm_callback", line=860, mname=0x7fae77c8c014 "uac") at
core/mem/q_malloc.c:1350
#5 0x7fae77c3686b in uac_send_tm_callback (t=0x7fae797dcf40, type=131072,
ps=0x7fff8bd990d0) at uac_send.c:860
#6 0x7fae783abc27 in run_trans_callbacks_internal (cb_lst=0x7fae797dcfe8,
type=131072, trans=0x7fae797dcf40, params=0x7fff8bd990d0) at t_hooks.c:241
#7 0x7fae783abd1e in run_trans_callbacks (type=131072,
trans=0x7fae797dcf40, req=0x0, rpl=0x0, code=0) at t_hooks.c:261
#8 0x7fae782bd8cb in free_cell_helper (dead_cell=0x7fae797dcf40, silent=0,
fname=0x7fae783e9f62 "timer.c", fline=653) at h_table.c:165
#9 0x7fae7837649c in wait_handler (ti=724701450, wait_tl=0x7fae797dcff8,
data=0x7fae797dcf40) at timer.c:653
#10 0x5614ad50be68 in timer_list_expire (t=724701450, h=0x7fae78ef5d18,
slow_l=0x7fae78ef95e0, slow_mark=33641) at core/timer.c:857
#11 0x5614ad50c3a7 in timer_handler () at core/timer.c:922
#12 0x5614ad50c8d5 in timer_main () at core/timer.c:961
#13 0x5614ad45fbf3 in main_loop () at main.c:1833
#14 0x5614ad46ae93 in main (argc=14, argv=0x7fff8bd99b48) at main.c:3086
I think it occurs only if $uac_req(evroute) is set to 1 and I define the
event_route[uac:reply] route.
My uac_reply route is easy:
if ($uac_req(evcode)==200) {
xlog("L_INFO", "Registration for user $fU has been refreshed
successfully.");
$sht(vtp=>asterisk_restarted) = $null;
route(SAVE_REG);
}
else {
xlog("L_INFO", "Registration failed: $uac_req(evcode)");
}
the SAVE_REG route is the following:
route[SAVE_REG] {
xlog("L_INFO", "Saving pbx registration...:$fU");
$var(maxExpiry) = MAX_PBX_REG_EXPIRY;
route(GET_CLIENT_ID);
sql_pvquery("ca", "select count(*) from pbxusers where user = '$fU'",
"$var(pbxusersCnt)");
if ($var(pbxusersCnt)>0) {
if ($var(clientId) == 0) {
sql_query("ca", "update pbxusers set expiry = TIMESTAMPADD(SECOND,
$var(maxExpiry), SYSDATE()), online=1 where user = '$fU'");
}
else {
sql_query("ca", "update pbxusers set client_id = '$var(clientId)',
expiry = TIMESTAMPADD(SECOND, $var(maxExpiry), SYSDATE()), online=1 where user
= '$fU'");
}
}
else {
sql_query("ca", "insert into pbxusers (user, expiry, client_id, online)
values ('$fU', TIMESTAMPADD(SECOND, $var(maxExpiry), SYSDATE()),
'$var(clientId)', 0)");
}
}
And GET_CLIENT_ID route is:
route[GET_CLIENT_ID] {
$var(clientId) = 0;
if (is_present_hf("X-AT-ClientId")) {
[SR-Users] Re: uac_req_send + evroute + crash
Hello Daniel,
I’m using kamailio 5.7.2 currently and this misterious crash occurs again. Now
core files are generated also, here is the trace:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7fae9a2d0859 in __GI_abort () at abort.c:79
#2 0x5614ad79afd8 in qm_debug_check_frag (qm=0x7fae78e77000,
f=0x7fae79805028, file=0x7fae77c8c134 "uac: uac_send.c", line=860,
efile=0x5614ad936f99 "core/mem/q_malloc.c", eline=511) at
core/mem/q_malloc.c:129
#3 0x5614ad79f7c1 in qm_free (qmp=0x7fae78e77000, p=0x7fae79805060,
file=0x7fae77c8c134 "uac: uac_send.c", func=0x7fae77c8cf10 <__func__.15157>
"uac_send_tm_callback", line=860, mname=0x7fae77c8c014 "uac") at
core/mem/q_malloc.c:511
#4 0x5614ad7ab410 in qm_shm_free (qmp=0x7fae78e77000, p=0x7fae79805060,
file=0x7fae77c8c134 "uac: uac_send.c", func=0x7fae77c8cf10 <__func__.15157>
"uac_send_tm_callback", line=860, mname=0x7fae77c8c014 "uac") at
core/mem/q_malloc.c:1350
#5 0x7fae77c3686b in uac_send_tm_callback (t=0x7fae797dcf40, type=131072,
ps=0x7fff8bd990d0) at uac_send.c:860
#6 0x7fae783abc27 in run_trans_callbacks_internal (cb_lst=0x7fae797dcfe8,
type=131072, trans=0x7fae797dcf40, params=0x7fff8bd990d0) at t_hooks.c:241
#7 0x7fae783abd1e in run_trans_callbacks (type=131072,
trans=0x7fae797dcf40, req=0x0, rpl=0x0, code=0) at t_hooks.c:261
#8 0x7fae782bd8cb in free_cell_helper (dead_cell=0x7fae797dcf40, silent=0,
fname=0x7fae783e9f62 "timer.c", fline=653) at h_table.c:165
#9 0x7fae7837649c in wait_handler (ti=724701450, wait_tl=0x7fae797dcff8,
data=0x7fae797dcf40) at timer.c:653
#10 0x5614ad50be68 in timer_list_expire (t=724701450, h=0x7fae78ef5d18,
slow_l=0x7fae78ef95e0, slow_mark=33641) at core/timer.c:857
#11 0x5614ad50c3a7 in timer_handler () at core/timer.c:922
#12 0x5614ad50c8d5 in timer_main () at core/timer.c:961
#13 0x5614ad45fbf3 in main_loop () at main.c:1833
#14 0x5614ad46ae93 in main (argc=14, argv=0x7fff8bd99b48) at main.c:3086
I think it occurs only if $uac_req(evroute) is set to 1 and I define the
event_route[uac:reply] route.
My uac_reply route is easy:
if ($uac_req(evcode)==200) {
xlog("L_INFO", "Registration for user $fU has been refreshed
successfully.");
$sht(vtp=>asterisk_restarted) = $null;
route(SAVE_REG);
}
else {
xlog("L_INFO", "Registration failed: $uac_req(evcode)");
}
the SAVE_REG route is the following:
route[SAVE_REG] {
xlog("L_INFO", "Saving pbx registration...:$fU");
$var(maxExpiry) = MAX_PBX_REG_EXPIRY;
route(GET_CLIENT_ID);
sql_pvquery("ca", "select count(*) from pbxusers where user = '$fU'",
"$var(pbxusersCnt)");
if ($var(pbxusersCnt)>0) {
if ($var(clientId) == 0) {
sql_query("ca", "update pbxusers set expiry = TIMESTAMPADD(SECOND,
$var(maxExpiry), SYSDATE()), online=1 where user = '$fU'");
}
else {
sql_query("ca", "update pbxusers set client_id = '$var(clientId)',
expiry = TIMESTAMPADD(SECOND, $var(maxExpiry), SYSDATE()), online=1 where user
= '$fU'");
}
}
else {
sql_query("ca", "insert into pbxusers (user, expiry, client_id, online)
values ('$fU', TIMESTAMPADD(SECOND, $var(maxExpiry), SYSDATE()),
'$var(clientId)', 0)");
}
}
And GET_CLIENT_ID route is:
route[GET_CLIENT_ID] {
$var(clientId) = 0;
if (is_present_hf("X-AT-ClientId")) {
$var(clientId) = $hdr(X-AT-ClientId);
}
}
Any idea, is it a bug or I do something wrong in config files?
Peter
From: Dr. Barabás Péter via sr-users
Date: Sunday, 2023. October 8. 18:49
To: mico...@gmail.com , Kamailio (SER) - Users Mailing List
Cc: Dr. Barabás Péter
Subject: [SR-Users] Re: uac_req_send + evroute + crash
Hello Daniel,
I do not see any “failed to send request with authentication”.
The next CRITICAL log appears after calling uac_req_send():
CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already
freed pointer (0x7f114995ada8), called from uac: uac_send.c:
uac_send_tm_callback(860), first free uac: uac_send.c:
uac_resend_tm_callback(732) - ignoring
Now we use kamailio 5.7.2 and no crash has come, but the critical logs above
exist.
I saw a ticket in github: https://github.com/kamailio/kamailio/issues/3522, may
the crash be similar or the same to that?
I will make a try next week with downgrading to 5.6.2 and try to reproduce the
crash.
Peter
From: Daniel-Constantin Mierla
Date: Friday, 2023. October 6. 13:55
To: Dr. Barabás Péter , Kamailio (SER) - Users
Mailing List
Subject: Re: [SR-Users] uac_req_send + evroute + crash
Hello,
do you also get error log messages that include "failed to sen
[SR-Users] Re: uac_req_send + evroute + crash
Hello Daniel, I do not see any “failed to send request with authentication”. The next CRITICAL log appears after calling uac_req_send(): CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) - ignoring Now we use kamailio 5.7.2 and no crash has come, but the critical logs above exist. I saw a ticket in github: https://github.com/kamailio/kamailio/issues/3522, may the crash be similar or the same to that? I will make a try next week with downgrading to 5.6.2 and try to reproduce the crash. Peter From: Daniel-Constantin Mierla Date: Friday, 2023. October 6. 13:55 To: Dr. Barabás Péter , Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] uac_req_send + evroute + crash Hello, do you also get error log messages that include "failed to send request with authentication"? Which CRITICAL log appears when you call uac_req_send()? You pasted a couple of them in the initial email? Cheers, Daniel On 05.10.23 17:32, Dr. Barabás Péter wrote: Hello, I used kamailio version 5.6.2. I refreshed to 5.7.2 today. As I remember it was in kamailio long time ago therefore I could skip evroute route. But this CRITICAL log appears always when I call uac_req_send(). I call it with settings: $uac_req(auser) = $var(username); $uac_req(apasswd) = $var(password); Where username and password are retrived from web service before call. In event_route I got first 401 after 200. Peter From: Daniel-Constantin Mierla <mailto:mico...@gmail.com> Date: Thursday, 2023. October 5. 17:25 To: Kamailio (SER) - Users Mailing List <mailto:sr-users@lists.kamailio.org> Cc: Dr. Barabás Péter <mailto:dr.peter.bara...@gmail.com> Subject: Re: [SR-Users] uac_req_send + evroute + crash Hello, On 05.10.23 16:34, Dr. Barabás Péter via sr-users wrote: Hi All, I use kamailio In front of Asterisk and kamailio needs to refresh registrations periodically towards Asterisk to ensure the availability of users from Asterisk side. I use uac module and call uac_req_send() for sending REGISTER requests. I set $uac_req(evroute)=1 The event_route[uac:reply] is called fine, but in kamailio logs I see the next lines: CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) - ignoring After some time, kamailio has crashed. CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) – ignoring CRITICAL: [core/pass_fd.c:277]: receive_fd(): EOF on 34 ALERT: [main.c:774]: handle_sigs(): child process 1407950 exited by a signal 6 what version of Kamailio are you using? Is Asterisk challenging for authentication? Does it happen every time or seldom? Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training - Online - Nov 14-16, 2023 -- asipto.com -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training - Online - Nov 14-16, 2023 -- asipto.com __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: uac_req_send + evroute + crash
Hello, I used kamailio version 5.6.2. I refreshed to 5.7.2 today. As I remember it was in kamailio long time ago therefore I could skip evroute route. But this CRITICAL log appears always when I call uac_req_send(). I call it with settings: $uac_req(auser) = $var(username); $uac_req(apasswd) = $var(password); Where username and password are retrived from web service before call. In event_route I got first 401 after 200. Peter From: Daniel-Constantin Mierla Date: Thursday, 2023. October 5. 17:25 To: Kamailio (SER) - Users Mailing List Cc: Dr. Barabás Péter Subject: Re: [SR-Users] uac_req_send + evroute + crash Hello, On 05.10.23 16:34, Dr. Barabás Péter via sr-users wrote: Hi All, I use kamailio In front of Asterisk and kamailio needs to refresh registrations periodically towards Asterisk to ensure the availability of users from Asterisk side. I use uac module and call uac_req_send() for sending REGISTER requests. I set $uac_req(evroute)=1 The event_route[uac:reply] is called fine, but in kamailio logs I see the next lines: CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) - ignoring After some time, kamailio has crashed. CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) – ignoring CRITICAL: [core/pass_fd.c:277]: receive_fd(): EOF on 34 ALERT: [main.c:774]: handle_sigs(): child process 1407950 exited by a signal 6 what version of Kamailio are you using? Is Asterisk challenging for authentication? Does it happen every time or seldom? Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training - Online - Nov 14-16, 2023 -- asipto.com __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] uac_req_send + evroute + crash
Hi All, I use kamailio In front of Asterisk and kamailio needs to refresh registrations periodically towards Asterisk to ensure the availability of users from Asterisk side. I use uac module and call uac_req_send() for sending REGISTER requests. I set $uac_req(evroute)=1 The event_route[uac:reply] is called fine, but in kamailio logs I see the next lines: CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) - ignoring After some time, kamailio has crashed. CRITICAL: [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f114995ada8), called from uac: uac_send.c: uac_send_tm_callback(860), first free uac: uac_send.c: uac_resend_tm_callback(732) – ignoring CRITICAL: [core/pass_fd.c:277]: receive_fd(): EOF on 34 ALERT: [main.c:774]: handle_sigs(): child process 1407950 exited by a signal 6 Any idea that is it a bug or I use something wrong in config? Thanks in advance! Péter Barabás __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Kamailio-asterisk BYE
Hello, we work on a mobile softphone which connects to asterisk through kamailio. Almost everything is fine except one thing. Asterisk allows only one registration to an AOR. In mobile environment network can change, register/unregister can be called frequently in foreground/background cases. Kamailio forwards every request to asterisk. Until I have only one connection between kamailio – asterisk, everything is fine. The next situation is problematic: 1. Client A and client B register to asterisk through kamailio. –> there will be one connection between kamailio and asterisk 2. Client A calls client B. • one connection exist still 3. If client A terminates the call -> one connection remains. It is okay. 4. If client B terminates the call -> a new connection appears (kamailio IP with new port) After case 4 If I try to register again, I got 403 from asterisk, since the setting of asterisk does not allowed to register from different IP:port for the same AOR. (this behaviour cannot be changed now). The question: is there any setting/config exist in kamailio not to create new connection for a BYE in above case. Thanks in advance for your reply. Peter __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Kamailio - asterisk - ACK
Hi James,
thanks for the reply. Yes, record_route() is used in INVITE request.
Meanwhile I found the cause I think here:
https://community.asterisk.org/t/asterisk-rewrites-record-route-header-with-incorrect-tcp-port/91202
So the Record-Route header contains kamailio’s IP and listening TLS port 443
until asterisk. When asterisk sends back 200/OK, it rewrites the port and
client wants to send ACK to this port which is not a listening port of kamailio.
My quick (but don’t know if proper) solution is that in reply route of INVITE I
check that If replay comes from asterisk, I add the following:
if (route(FROMASTERISK)) {
remove_hf("Record-Route");
append_hf("Record-Route: sips:KAMAILIO_IP:443;transport=TLS\r\n");
}
Now the ACK can go back to kamailio which forward it to asterisk.
There was another problem with ACK when it contains private IP, the
fix_nated_contact() in on_reply route solved this.
Peter
From: James Browne
Date: Wednesday, 2023. May 3. 17:17
To: Kamailio (SER) - Users Mailing List
Subject: [SR-Users] Re: Kamailio - asterisk - ACK
If the 200-OK to client A also contains Record-Route header fields,
then the routing of the ACK from client A should be done using that
route, not using the internal IP address of asterisk.
Are you using record_route() function from the rr module?
James
On Wed, 26 Apr 2023 at 09:20, Péter Dr. Barabás
wrote:
>
> Hi all,
>
>
>
> we are developing a softphone mobile application which registers to asterisk
> through kamailio. Kamailo proxies the request to asterisk and replies from
> asterisk to the clients.
>
> Registration works fine with asterisk authentication. The problem appears in
> the following flow:
>
> Mobile client A calls client B.
> Asterisk gets INVITE through kamailo, sends back 401, and get INVITE with
> credentials.
> Asterisk sends invite to client B towards kamailio.
> Kamailio forwards INVITE if client is registered or sends a push notification
> to client B. When client B registers, kamailio continue the suspended
> transaction and forwards INVITE.
> Client B gets INVITE, sends a SIP OK.
> Asterisk gets SIP OK through kamailio and sends an ACK to client B, which is
> OK.
> Asterisk sends the SIP OK to client A through kamailio.
> Kamailio forwards SIP OK to client A but the contact address contains the
> asterisk IP instead kamailio.
> Clilent A try to send ACK but it does not arrive to asterisk, and the call
> will be hungup after 30 secs.
>
>
>
> So the question is what is missing, what is the correct solution? I try to
> use the provided configuration given in following link:
>
> https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
>
>
>
> The difference is that kamailio has no access to asterisk database.
>
>
>
> Thanks for your help.
>
>
>
> With kind regards,
>
> Peter
>
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
[SR-Users] Silo extra_hdrs duplication
Hi, I’m using kamailio’s silo module to store offline messages in it. I set extra_hdrs modparam to e.g. : ‘Resent-from-silo’ so the clients get information that the message has arrived directly (immediatelly) from the sender or it was stored offline and comes from silo. So the problem is the following: * if receiver’s socket is broken (e.g. airplane mode on mobile) and kamailio ‘thinks’ it is registered, server tries to send the message * message will be timed out and based on config it will be stored in silo. * the next step is to check if receiver is registered or not (since the client can re-register during 30sec until the message has timed out) * If client is registered, kamailio tries to send the message immediately with m_dump(). * If the receiver’s connection is still broken, the message will be timed out and store in silo. * In every store, a new ‘resent’ extra_hdrs value is appended. When extra_hdrs length reaches 1024 bytes, the m_dump will fail and it blocks the dumping of messages to the given receiver. Question: can extra_hdrs value be removed before store? Or what can be the solution not to duplicate the extra_hdrs value in some bad network situation? Peter __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Remove silo extra_hdrs before store
Hi, I’m using kamailio’s silo module to store offline messages in it. I set extra_hdrs modparam to e.g. : ‘Resent-from-silo’ so the clients get information that the message has arrived directly (immediatelly) from the sender or it was stored offline and comes from silo. So the problem is the following: * if receiver’s socket is broken (e.g. airplane mode on mobile) and kamailio ‘thinks’ it is registered, server tries to send the message * message will be timed out and based on config it will be stored in silo. * the next step is to check if receiver is registered or not (since the client can re-register during 30sec until the message has timed out) * If client is registered, kamailio tries to send the message immediately with m_dump(). * If the receiver’s connection is still broken, the message will be timed out and store in silo. * In every store, a new ‘resent’ extra_hdrs value is appended. When extra_hdrs length reaches 1024 bytes, the m_dump will fail and it blocks the dumping of messages to the given receiver. Question: can extra_hdrs value be removed before store? Or what can be the solution not to duplicate the extra_hdrs value in some bad network situation? Peter __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
