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