Re: How to place a delay between cancelling branch and retrying next one on timer expiry?

Thank you for looking into this everyone.

I ended up going with suggestions (added a dispatcher to use a next FS
instance on the retry).

To address any late replies from cancelled branches, added the following
logic:

when cancelling add "first attempt" IP to hashtable with expiry and then
drop any traffic from it in:

route[WITHINDLG]
 if ($sht(cancel=>$ci) == $si) {
xlog("L_INFO",'{ "route_name":"$cfg(route)",
"correlations":$dlg_var(correlations), "text":"$si branch is already
canceled. Dropping $rm" }');
drop;
}

reply_route {
 if ($sht(cancel=>$ci) == $si) {
if ($rs=="200") {
xlog("L_INFO",'{ "route_name":"$cfg(route)",
"correlations":$dlg_var(correlations), "text":"$si branch is already
canceled. Dropping 200 reply" }');
drop;
}}


Thanks again

On Fri, Mar 21, 2025 at 12:02 PM Henning Westerholt <[email protected]> wrote:

> Thank you both for the detailed feedback.
>
>
>
> The RFC 3261 standard is pretty clear on that matter, a CSEQ should be
> increased for new requests, like when challenged for authentication.
>
>
>
> There are also good examples in the standard, like this one:
> https://datatracker.ietf.org/doc/html/rfc5359#section-2.8
>
> It clearly shows that the CSEQ should be not incremented from a SIP proxy
> on serial forking.
>
>
>
> I had a quick look to the issue tracker for freeswitch and I found a few
> bugs that might be related, but nothing that pointed exactly in this
> direction. So maybe a new issue could be opened there as well.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
>
>
> *From:* Yuriy G <[email protected]>
> *Sent:* Freitag, 21. März 2025 15:26
> *To:* Kamailio (SER) - Users Mailing List <[email protected]>
> *Cc:* Henning Westerholt <[email protected]>; Alex A <
> [email protected]>; Ben Kaufman <[email protected]>
> *Subject:* Re: [SR-Users] Re: How to place a delay between cancelling
> branch and retrying next one on timer expiry?
>
>
>
> Just about the FS problem: I can definitely reproduce the same   behaviour
> on 1.10 right now (482 merged calls). So yeah, It is still exists.
>
> I also struggle a bit with this issue especially when do some extended
> test scenarios.
> It just doesn't recognizes different branches.
>
> So best approach - avoid send the same call to the same machine.
>
>
>
> On Fri, Mar 21, 2025, 15:00 Ben Kaufman via sr-users <
> [email protected]> wrote:
>
> It was about two years ago that I tested, so my statments here are just
> what I recall, and therefor may be incorrect:
>
>
>
> I believe that I tested against 1.10, and there was no change in
> Freeswtich behavior.  Looking through issues it seems like Freeswitch's
> support team's position was that the CSeq number should be incremented.  Of
> course, this would be problematic at the proxy level as it would then have
> to track the offset it's creating from the UAC (I know there are functions
> for this in Kamailio, but this doesn't seem the appropriate place for
> this).  There are some old issues reported for the same type of thing
> within Kamailio, where Daniel pointed that the issue was Freeswitches
> behavior, so it was a both sides pointing fingers situation (although I'm
> pretty sure Daniel is correct).
>
>
>
> I think many people encoutring this issue went ahead with the "sleep"
> solution.  I inherited maintenance of an environment where this was done,
> and the issue came to my attention via performance issues caused by the
> blocking sleep call.  Since I also had an array of Freeswitch servers which
> could handle the request, my direct solution was to just make sure that the
> failure route pointed to a different Freeswitch than the request route.
> That was a workable situation in my scenario and much easier than trying to
> convince someone the behavior is incorrect.  My guess is that the
> Freeswitch behavior is the same to this day simply because it hasn't been
> revisited.
>
>
>
> On a personal level, I'm in the process of removing these Freeswitch
> instances.  This isn't a complaint against Freeswitch, but rather that it
> was installed to handle media relay and RTPEngine is much better suited if
> that's the only task that's needed.  Given this, I don't have a lot of
> motivation to dig into he issue further, but if needed, I think I could
> pretty easily cook up a small docker-compose environment that illustrates
> the problem.
>
>
>
> Regards,
>
> Kaufman
> ------------------------------
>
> *From:* Henning Westerholt <[email protected]>
> *Sent:* Friday, March 21, 2025 8:22 AM
> *To:* Kamailio (SER) - Users Mailing List <[email protected]>
> *Cc:* Alex A <[email protected]>; Ben Kaufman <
> [email protected]>
> *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.
>
>
>
> 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]>
> *Sent:* Donnerstag, 20. März 2025 15:57
> *To:* [email protected]
> *Cc:* Alex A <[email protected]>; Ben Kaufman <
> [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] <[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
> <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!
>
>

__________________________________________________________
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!