Stateless proxy always makes sence in high loaded distributed system. Even in 2025 :-)
On Tue, 11 Feb 2020, 14:52 Sebastian Damm, <[email protected]> wrote: > Hi all, > > thanks for the discussion and reminding everyone that it is already > fixed. Henning, I guess we owe you a beer or two at Kamailioworld. :) > > Daniel, to answer your question regarding "why stateless": Our setup > includes anycast, so multiple machines share the same IP address. And > depending on the datacenter location of our gateways or the uplink to > the carrier, even requests and answers can be routed through different > instances running with the same IP address. So yes, even in 2020 there > can be use cases for a stateless loadbalancer. > > We were running 5.2.2, and after I upgraded to 5.2.6, our error reply > counter dropped significantly. Wow. > > Regards, > Sebastian > > On Mon, Feb 10, 2020 at 8:02 PM Henning Westerholt <[email protected]> wrote: > > > > Hello Serge, > > > > there was a regression introduced by b64a25874e3 in 5.2 because of a > wrong refactoring. This were not noticed for some time because only a few > people (still) use stateless load balancers. I noticed it as well in middle > of last year during a customer project. It was fixed in 82635674517 end of > July 2019, you find in the related discussion also some test results that I > posted before doing the backport. So, if this is your problem, after 5.2.4 > is should work again. > > > > Cheers, > > > > Henning > > > > -- > > Henning Westerholt – https://skalatan.de/blog/ > > Kamailio services – https://gilawa.com > > > > -----Original Message----- > > From: sr-users <[email protected]> On Behalf Of Serge > S.Yuriev > > Sent: Monday, February 10, 2020 4:46 PM > > To: Kamailio (SER) - Users Mailing List <[email protected]> > > Subject: Re: [SR-Users] Same Via Tag for INVITE and ACK on S/L > loadbalancer > > > > Hello, > > > > This stateless call flow is smooth in 5.1 branch, at least 5.1.7 but in > 5.2.1 already broken IIRC. > > Some time ago I wrote about this very same issue > > > > 10.02.2020, 18:39, "Daniel-Constantin Mierla" <[email protected]>: > > > In such case, because the proxy is doing stateless forwarding, there > > > is no transaction. I guess the solution right now is to use tm for > > > relaying > > > - is any concern of doing that? > > > > > > If someone wants to look at generating same via branch, I am fine with > > > it, eventually controlled by a parameter if the code change is > > > significant, to be able to switch to current mode if unexpected side > > > effects pop up. > > > > > > One more note in this case: I expect it would be required to generate > > > different tag for 200ok ACK, so it is matched as different transaction > > > by next hop, not sure if there is any easy way to discover the type of > > > ACK in a stateless proxy. > > > > > > I am not sure I remember correctly, but in some discussions I think it > > > was suggested to just reuse the branch value of incoming top Via when > > > doing stateless forwarding. > > > > > > Cheers, > > > Daniel > > > > > > On 10.02.20 16:26, Sebastian Damm wrote: > > >> We use 5.2 on the affected systems. > > >> > > >> On Mon, Feb 10, 2020 at 4:15 PM Serge S. Yuriev <[email protected]> > wrote: > > >>> Hi > > >>> > > >>> I believe you are using 5.2 or 5.3 series? This tend to work > > >>> properly on 5.1 series > > >>> > > >>> 10.02.2020, 18:10, "Sebastian Damm" <[email protected]>: > > >>>> Hi, > > >>>> > > >>>> actually, our only problem is handling negative replies. The ACK > > >>>> belongs to the same transaction and therefore has to carry the > > >>>> same > > >>>> Via branch ID. > > >>>> > > >>>> Sebastian > > >>>> > > >>>> On Mon, Feb 10, 2020 at 3:50 PM Yuriy Gorlichenko < > [email protected]> wrote: > > >>>>> ACK for successull response is a new transaction. It has to be > different. May be it is better to point provider to this? > > >>>>> > > >>>>> On Mon, 10 Feb 2020, 14:26 Sebastian Damm, <[email protected]> > wrote: > > >>>>>> Hi, > > >>>>>> > > >>>>>> I stumbled upon an interop problem with a carrier. We have the > > >>>>>> following scenario: > > >>>>>> > > >>>>>> Gateway --> Loadbalancer --> Carrier > > >>>>>> > > >>>>>> The loadbalancer generates a Via header for each request. But > > >>>>>> since it > > >>>>>> is stateless, the Via tag is generated for each request. As a > > >>>>>> consequence, the Via tag in the ACK differs from the one in the > > >>>>>> INVITE. And one carrier doesn't handle those ACKs if the Via > > >>>>>> tag > > >>>>>> differs. > > >>>>>> > > >>>>>> Is there a way to force the creation of a "deterministic" Via > > >>>>>> branch > > >>>>>> tag? For example, building it from a hash over call-id and > > >>>>>> from-tag or > > >>>>>> something like that? > > > > -- > > wbr, > > Serge > > > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > [email protected] > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > > -- > Sebastian Damm > Voice Engineer > __________________________________________ > sipgate GmbH > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
