[SR-Users] Re: Via header force change protocol to TLS?

Thanks, I'll check it out! Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 On Thu, May 23, 2024 at 4:16 PM Sergey Safarov &lt;s.safarov(a)gmail.com&gt; wrote: > We have tested this PR using the Linphone app. > So your case will be resolved using this PR. > Need to enable HAproxy protocol headers. > > On Wed, May 22, 2024 at 4:36 PM Sergey Safarov &lt;s.safarov(a)gmail.com&gt; > wrote: > >> Please try Kamailio PR >> https://github.com/kamailio/kamailio/pull/3731 >> >> We have developed this PR for use case you have described. >> We have tested Route and Record-Route headers not Via. >> So will provide some review for this PR then will be fine. >> >> On Wed, May 22, 2024 at 2:22 PM David Villasmil < >> david.villasmil.work(a)gmail.com&gt; wrote: >> >>> Hello Sergey, >>> >>> Thanks for the suggestion. Not sure if his is what i'm looking for, >>> allow me to explain further: >>> We set up an NetworkLoadBalancer on AWS to offload tls on it. This Load >>> balancer is a TLS listener on the outside and a TCP connection to the proxy >>> inside. >>> So when sending an INVITE to the connected client, the via has a TCP >>> protocol like >>> >>> Via: SIP/2.0/TCP >>> mydomain:port;branch=z9hG4bKf176.53ac8af0d7090a31e44548f15ea420ff.0 >>> >>> and the client (linphone) disconnects and tries to contact the proxy on >>> that address on a TCP socket, which doesn't exist. I tried many >>> solutions none of which actually work... last one setting $du =$du + >>> ";transport=tls" and forcing the socket to the TCP socket to the load >>> balancer, but of course i'm getting warnings about this. >>> >>> is this something that PR (not merged) would be addressing, i didn't >>> see that. >>> If not, is there a way of doing this without any trickery? >>> >>> Thanks! >>> >>> Regards, >>> >>> David Villasmil >>> email: david.villasmil.work(a)gmail.com >>> phone: +34669448337 >>> >>> >>> On Wed, May 22, 2024 at 12:16 PM Sergey Safarov &lt;s.safarov(a)gmail.com&gt; >>> wrote: >>> >>>> Probable you need this PR >>>> https://github.com/kamailio/kamailio/pull/3810 >>>> >>>> Or you can try >>>> https://github.com/kamailio/kamailio/pull/3731 >>>> In this PR we faced the same issue and solved this. >>>> >>>> >>>> On Wed, May 22, 2024 at 3:43 AM David Villasmil via sr-users < >>>> sr-users(a)lists.kamailio.org&gt; wrote: >>>> >>>>> Hello Anthony, did you solve this problem? I'm facing the same problem >>>>> >>>>> Thanks! >>>>> Regards, >>>>> >>>>> David Villasmil >>>>> email: david.villasmil.work(a)gmail.com >>>>> phone: +34669448337 >>>>> >>>>> >>>>> On Mon, Feb 5, 2018 at 5:57 AM Anthony Alba &lt;ascanio.alba7(a)gmail.com&gt; >>>>> wrote: >>>>> >>>>>> I have kamailio behind a TLS termination proxy so the sockets are >>>>>> correctly deduced to be TCP. However the clients only talk TLS to the proxy >>>>>> and are confused when the top Via header added by Kamailio is TCP. Is there >>>>>> a way for Kamailio to forcibly pretend its protocol is TLS? Like >>>>>> advertised_address but "advertised_protocol" instead. >>>>>> >>>>>> (With pjsip testing: it has a flag use_tls which ignores TCP from >>>>>> Kamailio and continues to use the persistent TLS transport to proxy. >>>>>> Linphone fails because it tries to honor TCP in Via and is unable to >>>>>> establish TCP transport). >>>>>> >>>>>> BTW I am using t_relay_to_tcp so Kamailio will return traffic to the >>>>>> proxy as TCP even though the contact addresses specify transport=TLS. >>>>>> _______________________________________________ >>>>>> Kamailio (SER) - Users Mailing List >>>>>> sr-users(a)lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>> >>>>> __________________________________________________________ >>>>> Kamailio - Users Mailing List - Non Commercial Discussions >>>>> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org >>>>> Important: keep the mailing list in the recipients, do not reply only >>>>> to the sender! >>>>> Edit mailing list options or unsubscribe: >>>>> >>>>