Hi Ben, thank you. 16 years is indeed a longer time, one could hope that its now fixed in a newer version.
Cheers, Henning From: Ben Kaufman <[email protected]> Sent: Freitag, 21. März 2025 14:21 To: Henning Westerholt <[email protected]>; Kamailio (SER) - Users Mailing List <[email protected]> Cc: Alex A <[email protected]> Subject: Re: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry? The reference is 16 years old, so perhaps my statement would have been better phrased as "didn't support" rather than what was at the time "doesn't support": https://freeswitch-users.freeswitch.narkive.com/pl2VL6Gu/482-request-merged-in-serial-forking With that said, the very specific statment of "We currently don't support forked dialogs" is here: https://narkive.com/pl2VL6Gu:6.378.42 It's been a few years since I dealt with the issue first hand, but IIRC it was relatively simple to recreate by relaying an INVITE to a freeswitch that returns failure, then re-targeting that same freeswitch from kamailio failure route. Regards, Kaufman ________________________________ From: Henning Westerholt Sent: Friday, March 21, 2025 2:41 AM To: Kamailio (SER) - Users Mailing List Cc: Alex A; Ben Kaufman Subject: RE: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry? CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello Ben, do you have any reference (e.g. bug tracker, e-mail thread) for the "freeswitch don't support SIP branching"? It sounds quite strange to me in this time that there are still those large issues regarding the standard support in such a project. Thanks, Henning From: Ben Kaufman via sr-users <[email protected]<mailto:[email protected]>> Sent: Donnerstag, 20. März 2025 15:57 To: [email protected]<mailto:[email protected]> Cc: Alex A <[email protected]<mailto:[email protected]>>; Ben Kaufman <[email protected]<mailto:[email protected]>> Subject: [SR-Users] Re: How to place a delay between cancelling branch and retrying next one on timer expiry? I've dealt with the same issue, and as far as I understand, the problem is with Freeswitch not supporting branching and IIRC not recognizing that the via branch has changed. Adding a sleep function as indicated in that link is a blocking process, so if you have this serial forking occur frequently it could cause kamailio to have issues. There is a non-blocking async_sleep function that I didn't have success with, but that was probably a misunderstanding of how it worked on my part. With that said, you might try adding another sip_profile to your freeswitch server (on a different port) and see if sending the serially forked call to the other sip_profile addresses it. Otherwise, I'd recommend adding another freeswich instance (even if it's on the same server) rather than calling sleep(); Regards, Kaufman ________________________________ From: Alex A via sr-users Sent: Wednesday, March 19, 2025 4:58 PM To: [email protected]<mailto:[email protected]> Cc: Alex A Subject: [SR-Users] How to place a delay between cancelling branch and retrying next one on timer expiry? CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi All, I have an interesting use-case where I need to place a delay between cancelling branch and retrying next one. Background: Running Kamailio 5.6.x Kamailio routes requests via a freeswitch B2BUA server on select call flows (where B2BUA functionality is required). Call flow examples: PSTN --> Kamailio --> Freeswitch --> appserver1 PSTN --> Kamailio --> Freeswitch --> appserver2 On attempt failures, a branch retry is required from appserver1 to appserver2; however freeswitch B2BUA remains the same Since Freeswitch does not quite follow the RFC 3261 timer K specifications (should be 0 seconds for reliable transports, but FS keeps transactions for T4 (set to 2 seconds)); I have implemented an artificial delay in failure route before retrying (as per recommendation described here: https://freeswitch-users.freeswitch.narkive.com/TsSye66D/482-request-merged-in-serial-forking-solved ) Script config: onreply_route[MANAGE_REPLY] { xlog("L_INFO", "reply $T_reply_code received"); if (t_check_status( "1[1-9][0-9]")) { t_reset_fr(); } else { t_set_fr(120000); } } route(NATDETECT); #!ifdef WITH_RTPENGINE route(RTPMANAGE); #!endif } route[RELAY] { if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if(is_method("INVITE|BYE|UPDATE|CANCEL|ACK")) { setflag(FLT_DLGINFO); } if (!t_relay()) { sl_reply_error(); } exit; } route[TOCARRIER] { process bunch of things, attach custom headers, generate request URI t_on_failure("MANAGE_FAILURE_CARRIER"); route(RELAY); } failure_route[MANAGE_FAILURE_CARRIER] { xlog("L_INFO", "reply $T_reply_code received"); if ($avp(inbound_attempt)<=1){ if ($dlg_var(b2bua)=="true"){ usleep(1900000); } route("TOCARRIER"); } Call Flows: The above fix works well when an explicit error reply is received back. error reply SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 503 <-- Freeswitch failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch call continues as expected. however does not work when NO reply is received at all and the timer expires. Current timer expiry SIP exchange: SBC --> INVITE(branch0) ---> Freeswitch SBC <-- 100/180 <-- Freeswitch SBC (timer expires) failure_route executed (sleep runs here) SBC --> INVITE(branch1) ---> Freeswitch SBC <-- 482 Merged <-- Freeswitch SBC --> CANCEL(branch0) ---> Freeswitch I am looking to CANCEL branch0 before the sleep delay runs Based on source code, t_cancel_branches("this") can only be executed in reply_route; however the chellenge is that reply_route never sees the "faked 408" on timer expiry(although the failure route does see $T_reply_code 408). Any suggestions on how to handle this would be greatly appreciated. TIA
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
