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 <sr-users@lists.kamailio.org>
Sent: Donnerstag, 20. März 2025 15:57
To: sr-users@lists.kamailio.org
Cc: Alex A <alex.antonevych@replicant.ai>; Ben Kaufman <bkaufman@bcmone.com>
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: sr-users@lists.kamailio.org
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