July 2023 - sr-users - kamailio.org

Re: sr-users Digest, Vol 218, Issue 16
by satyaprakash ch 11 Jul '23

11 Jul '23

Hi Please find some more before and after, Ip address and number is masked FYI. INFO: <script>: TIME : TEST - Rewriting To header with Request line so that vendor prefix is present INFO: <script>: TIME : TEST2 - tu is sip:+123456789@10.0.77.88 and ru is sip:10.0.1.47:5060 INFO: <script>: TIME : TEST3 - tu is sip:+123456789@10.0.77.88 and ru is sip:10.0.1.47:5060 ERROR: tm [tm.c:1752]: _w_t_relay_to(): t_forward_noack failed ERROR: tm [t_reply.c:1081]: run_failure_handlers(): error running run_top_route for failure handler INFO: <script>: TIME : [Mon Jul 10 12:24:14 2023] CALL ID : [31bca077-99fa-123c-eb84-00219b9e3ef4] [WITHINDIALOG] The request is [ACK] INFO: <script>: TIME : [Mon Jul 10 12:24:14 2023] CALL ID : [31bca077-99fa-123c-eb84-00219b9e3ef4] [PROXY_OUTBOUND_HANDLE] [ACK] INFO: <script>: TIME : [Mon Jul 10 12:24:14 2023] CALL ID : [ 205526695_49743609(a)206.147.84.20] [WITHINDIALOG] The request is [ACK] Here is the code i suspect, Let me know if you can find some thing why the error usually gets, *failure_route["serial"] { if (!t_next_contacts()) { exit; } t_on_failure("serial"); xlog("L_INFO","TIME : [$Tf] CALL ID : [$ci] [serial]The altered ruri is [$ru] \n"); xlog("L_INFO", "TIME : TEST - Rewriting To header with Request line so that vendor prefix is present"); xlog("L_INFO","TIME : TEST2 - tu is $tu and ru is $ru \n"); $tu = $ru; xlog("L_INFO","TIME : TEST3 - tu is $tu and ru is $ru \n"); t_relay();}event_route[tm:branch-failure:REMOVE_OLD_REGISTER] { if (t_check_status("(404)|(410)")) { xlog("L_INFO","TIME : Received code [$T(reply_code)] from SBC, need to remove registration \n"); xlog("L_INFO","TIME : [$Tf] CALL ID : [$ci] [REMOVE_OLD_REGISTER] contact is [$ct]Unregister section is entered [$ru] \n"); unregister("location", "$tu", "$T_reply_ruid"); }}* Thank you. On Tue, Jul 11, 2023 at 3:46 PM <sr-users-request(a)lists.kamailio.org> wrote: > Send sr-users mailing list submissions to > sr-users(a)lists.kamailio.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > sr-users-request(a)lists.kamailio.org > > You can reach the person managing the list at > sr-users-owner(a)lists.kamailio.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sr-users digest..." > > Today's Topics: > > 1. Need an error description (satyaprakash ch) > 2. Re: Need an error description (Alex Balashov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Jul 2023 22:25:31 +0530 > From: satyaprakash ch <chiramchetty.satyaprakash(a)gmail.com> > Subject: [SR-Users] Need an error description > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.kamailio.org> > Message-ID: > < > CAO-xAtGhcDMiPtoGdBeb6qvhOg8u7hxKt-w-5oU4KuOkdRHuqg(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="0000000000005a4339060024dadd" > > Hi, > > Can anyone help me with the error why can we get this? > > ERROR: tm [tm.c:1752]: _w_t_relay_to(): t_forward_noack failed ERROR: tm > [t_reply.c:1081]: run_failure_handlers(): error running run_top_route for > failure handler > > Thank you. >

2 1

Need an error description
by satyaprakash ch 10 Jul '23

10 Jul '23

Hi, Can anyone help me with the error why can we get this? ERROR: tm [tm.c:1752]: _w_t_relay_to(): t_forward_noack failed ERROR: tm [t_reply.c:1081]: run_failure_handlers(): error running run_top_route for failure handler Thank you.

2 1

event_route[tm:local-response] only executes a few times
by Kaufman 10 Jul '23

10 Jul '23

Hello, I'm writing a 302 redirect server and wanting to capture some events on all replies, so I'm trying to do this in event_route[tm:local-response], but I noticed that the event route is only called a few times for the first few requests, and then never gets executed again. This is the simplest case in which I can reproduce the issue: #!KAMAILIO loadmodule "pv" loadmodule "tm" loadmodule "xlog" route { xinfo("[$rm $ci-$cs] Src:[$si:$sp] RURI:[$ru] To:[$tu] From:[$fu]\n"); t_send_reply("404", "Not Found"); exit; } event_route[tm:local-response] { xcrit("[$rm $ci-$cs] tm:local-response replied locally\n"); } If I start Kamailio with kamailio -ddDDeE it has 8 children. If I use sipp to send 10 requests, this is what I see in the kamailio logs. The critical line in the event route is only printed four times. This is tested on 5.7.0 and 5.6.4 9(66) INFO: <script>: [INVITE 1-14(a)172.26.0.3-1<mailto:1-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 9(66) CRITICAL: <script>: [INVITE 1-14(a)172.26.0.3-1<mailto:1-14@172.26.0.3-1>] tm:local-response replied locally 10(67) INFO: <script>: [ACK 1-14(a)172.26.0.3-1<mailto:1-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) INFO: <script>: [INVITE 2-14(a)172.26.0.3-1<mailto:2-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) CRITICAL: <script>: [INVITE 2-14(a)172.26.0.3-1<mailto:2-14@172.26.0.3-1>] tm:local-response replied locally 12(69) INFO: <script>: [ACK 2-14(a)172.26.0.3-1<mailto:2-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 13(70) INFO: <script>: [INVITE 3-14(a)172.26.0.3-1<mailto:3-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 13(70) CRITICAL: <script>: [INVITE 3-14(a)172.26.0.3-1<mailto:3-14@172.26.0.3-1>] tm:local-response replied locally 14(71) INFO: <script>: [ACK 3-14(a)172.26.0.3-1<mailto:3-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 15(72) INFO: <script>: [INVITE 4-14(a)172.26.0.3-1<mailto:4-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 15(72) CRITICAL: <script>: [INVITE 4-14(a)172.26.0.3-1<mailto:4-14@172.26.0.3-1>] tm:local-response replied locally 16(73) INFO: <script>: [ACK 4-14(a)172.26.0.3-1<mailto:4-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 9(66) INFO: <script>: [INVITE 5-14(a)172.26.0.3-1<mailto:5-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 10(67) INFO: <script>: [ACK 5-14(a)172.26.0.3-1<mailto:5-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) INFO: <script>: [INVITE 6-14(a)172.26.0.3-1<mailto:6-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 12(69) INFO: <script>: [ACK 6-14(a)172.26.0.3-1<mailto:6-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 13(70) INFO: <script>: [INVITE 7-14(a)172.26.0.3-1<mailto:7-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 14(71) INFO: <script>: [ACK 7-14(a)172.26.0.3-1<mailto:7-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 15(72) INFO: <script>: [INVITE 8-14(a)172.26.0.3-1<mailto:8-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 16(73) INFO: <script>: [ACK 8-14(a)172.26.0.3-1<mailto:8-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 9(66) INFO: <script>: [INVITE 9-14(a)172.26.0.3-1<mailto:9-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 10(67) INFO: <script>: [ACK 9-14(a)172.26.0.3-1<mailto:9-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 11(68) INFO: <script>: [INVITE 10-14(a)172.26.0.3-1<mailto:10-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] 12(69) INFO: <script>: [ACK 10-14(a)172.26.0.3-1<mailto:10-14@172.26.0.3-1>] Src:[172.26.0.3:5060] RURI:[sip:service@172.26.0.2:5060] To:[sip:service@172.26.0.2:5060] From:[sip:sipp@172.26.0.3:5060] Kaufman

2 2

Random number
by Ali Taher 07 Jul '23

07 Jul '23

Hello, As per Kamailio documentation, $RANDOM returns a random value from the [0 - 2^31) range. But when testing it it's always returning a random number of 9 or 10 digits. I'm not sure if it's always the case or if it can also returns numbers with 1 or 2 digits as well. Another question, how can I force it to return a number of specific digits starting with certain prefix. Regards,

2 1

Finding a way to gracefully restart kamailio with dialog module enabled and DMQ sync
by Benoît Panizzon 07 Jul '23

07 Jul '23

Hi Gang We are still having massive issues on how to safely reload kamailio after config changes when using the dialog module and DMQ. If there are active dialogues, kamailio corrupts them on a restart even when using MySQL as dialog backend. As we use two core nodes for redundancy, I am looking for a way to gracefully restart kamailio. I am considering adding some key in a hash table or anything else I can reload on runtime to indicate to kamailio not to accept any new calls (effectively rejecting Invites without To-Tag with 503 causing the registrar or IC peer to hopefully resend the invite to the other node). Then wait, until no more dialogues are active, so kamailio can safely be restarted. My Issue now: How can I find out, one specific node does not have any active dialogues? 'kamcmd dlg.stats_active' returns the count of all DMQ synced nodes, not of the local one. And suggestions or any other ideas how I can 'reload' the kamailio config without disrupting active dialogues? My last resort would be to look into the database: modparam("dialog", "h_id_start", -1) # Use server_id modparam("dialog", "h_id_step", 2) So odd/even H_ID should tell me the number per node. But I see a lot of orphan dialogues hanging around in the database not being cleaned so I guess that will not be reliable at all. Yes, I know I will get the question: 'Why do you need to restart kamailio that often'. We have started production on our kamailio based TSP platform. And of course, despite a LOT of testing beforehand, there is always some issue that pops up. At the moment, I have to implement a config change about once or twice a week to fix some new minor issues. I hope, somewhen in the future we will hopefully have a stable config which will last for several months, but at the moment this is the situation. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 4

Randomize calling number
by Ali Taher 06 Jul '23

06 Jul '23

Hello, What is the best way to change the calling number to a random number (based on specific pattern, like number of digits for example) in an invite packet without using a database. So the scenario is : * receive an invite packet from certain source * change the calling number * send back the invite packet including the new calling number to the original source. Regards, Ali Taher

3 7

302 Handling issue in failure route
by Devang Dhandhalya 05 Jul '23

05 Jul '23

Hello All I am handling 302 response in the failure route and when receiving 302 response in kamailio, it's not going into the failure route , kamailio just executing the onreply route when 302 response are received. A few days ago the same code with failure route worked but now it does not. i dont know why kamailio is not executing a failure route from where we can redirect calls to another server. code snippet route[RELAY]{ t_on_reply("MANAGE_REPLY"); t_on_failure("MANAGE_FAILURE"); t_on_branch("MANAGE_BRANCH"); if (!t_relay()) { sl_reply_error(); } exit; } failure_route[MANAGE_FAILURE] { if (t_is_canceled()) { exit; } if (t_check_status("302")){ get_redirects("*"); $ru= $T_rpl($sel(contact.uri)); route(RELAY); } } kamailio version : 5.6.4 Please suggest if I am doing anything wrong. -- Regards, *Devang Dhandhalya* -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

3 3

SL absorbed ACK is counted as dropped by core.drop_requests
by Kaufman 03 Jul '23

03 Jul '23

Just checking to see if this is the designed behavior. The SL module will attempt to match ACKs for stateless replies and handle them (absorb them?). The question I have is that it looks as though this ACK gets counted as dropped by the core.drop_requests from the KEX module. Tested using this config: #!KAMAILIO loadmodule "pv" loadmodule "sl" loadmodule "xlog" loadmodule "kex" loadmodule "corex" loadmodule "ctl" modparam("sl", "bind_tm", 0) route { xinfo("[$ci] $rm Request. Src:[$si:$sp] RURI:[$ru] To:[$tu] From:[$fu]\n"); sl_send_reply("404", "Not Found"); } event_route[sl:filtered-ack] { xnotice("sl:filtered-ack ACK [$ci] to local reply absorbed\n"); } Then validate by kamcmd stats.fetch core:drop_requests Is this the designed and "correct" behavior? Kaufman

3 4