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.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 <h...@gilawa.com> > *Sent:* Friday, March 21, 2025 8:22 AM > *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org> > *Cc:* Alex A <alex.antonev...@replicant.ai>; Ben Kaufman < > bkauf...@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 <bkauf...@bcmone.com> > *Sent:* Freitag, 21. März 2025 14:21 > *To:* Henning Westerholt <h...@gilawa.com>; Kamailio (SER) - Users Mailing > List <sr-users@lists.kamailio.org> > *Cc:* Alex A <alex.antonev...@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-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 <sr-users@lists.kamailio.org> > *Sent:* Donnerstag, 20. März 2025 15:57 > *To:* sr-users@lists.kamailio.org > *Cc:* Alex A <alex.antonev...@replicant.ai>; Ben Kaufman < > bkauf...@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 <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 > <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 -- > sr-users@lists.kamailio.org > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to > the sender! >
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
