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.comhttps://gilawa.com/
From: Yuriy G ovoshlook@gmail.com Sent: Freitag, 21. März 2025 15:26 To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Henning Westerholt hw@gilawa.com; Alex A alex.antonevych@replicant.ai; Ben Kaufman bkaufman@bcmone.com 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 <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> 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 <hw@gilawa.commailto:hw@gilawa.com> Sent: Friday, March 21, 2025 8:22 AM To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai>; Ben Kaufman <bkaufman@bcmone.commailto:bkaufman@bcmone.com> 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 <bkaufman@bcmone.commailto:bkaufman@bcmone.com> Sent: Freitag, 21. März 2025 14:21 To: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com>; Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai> 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-...
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 <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Sent: Donnerstag, 20. März 2025 15:57 To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Alex A <alex.antonevych@replicant.aimailto:alex.antonevych@replicant.ai>; Ben Kaufman <bkaufman@bcmone.commailto: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.orgmailto: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-... )
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 -- sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.orgmailto:sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!