Hello Karsten, Thank you for your reply. I have opened an issue at https://github.com/kamailio/kamailio/issues/3757
BR, George On Thu, 15 Feb 2024 at 18:39, Karsten Horsmann <khorsm...@gmail.com> wrote: > Hi George, > > > if you think it's a issue please fill a bug report on Github to let the > Devs investigate. Also the questions in the form ask for all what they > need. > > Thank you > > George Diamantopoulos via sr-users <sr-users@lists.kamailio.org> schrieb > am Do., 15. Feb. 2024, 16:06: > >> Update: I have just downgraded to 5.6.4 using >> https://deb-archive.kamailio.org/repos/kamailio-5.6.4 >> >> I have confirmed that topos works correctly with this version, so the >> commit that broke things happened between 5.6.4 and 5.6.5 >> >> It might be related to how multi-homed installations interact with topos >> when doing double rr. Tne difference I noticed is that in 5.6.4, the topos >> substitution in Via is: >> * inbound: Via: SIP/2.0/UDP 195.167.21.66:5060 >> ;branch=z9hG4bKq27z808ysq87yrzq6vp8m26yq;Role=3;Hpt=8e88_16 >> * outbound: Via: SIP/2.0/UDP >> 172.30.154.1;branch=z9hG4bKae0b.fce5449c22b5e79eb01d4f1ab3f7c014.0 >> >> That is kamailio replaces the hop with its internal interface. With topos >> on in 5.6.5, the behaviour is different for the UPDATE: >> * inbound: Via: SIP/2.0/UDP 195.167.21.66:5060 >> ;branch=z9hG4bK1jo121j8j2h5h3wzh2mzj51q5;Role=3;Hpt=8ea8_16 >> * outbound: Via: SIP/2.0/UDP >> 185.73.42.241;branch=z9hG4bKc45b.e6226bcf14264ae3b8674dd25a71191c.0 >> >> 185.73.42.241 is an interface on the same instance, but represents its >> "public" interface. Additionally, it happens to reside on a VRF, so the >> 200OK never reaches it because the routing table of the UAS directs it to >> another host with the same IP. >> >> Hopefully this is enough to get an idea of what might have gone wrong? >> Thanks! >> >> On Thu, 15 Feb 2024 at 15:55, George Diamantopoulos <georged...@gmail.com> >> wrote: >> >>> Hello all, >>> >>> I've noticed that there seems to be a regression with the topos module, >>> more specifically the redis flavour, but I'm assuming the storage backend >>> shouldn't make a difference. >>> I have confirmed this affects both 5.6.5 and 5.7-nightly, so I'm >>> assuming some backported commit is to blame. Kamailio 5.6.4 used >>> previously, to the best of my memory, was not affected. >>> >>> Early dialog UPDATEs sent from the callee seem to be somehow malformed, >>> since the 200 OK the UAS produces goes directly to the UAC despite having >>> executed record_route() for the original INVITE. I can't imagine how this >>> is possible, I thought responses always honour the Via header and record >>> route shouldn't play a role in this case, right? >>> >>> Simply turning topos off restores the intended behaviour, however, so I >>> can't help but think this is somehow related. Here's two call flows >>> demonstrating the behaviour: >>> * Topos on, 200 OK to UPDATE missing: https://pastebin.com/raw/J0zQeM5g >>> * Topos off, 200 OK to UPDATE routed correctly: >>> https://pastebin.com/raw/49yErezb >>> >>> I was wondering if anyone is aware of any commits that might be >>> responsible for this. Additionally, is there an archive of debian packages >>> with previous point releases so that I can confirm this regression with the >>> latest versions? >>> >>> Thank you! >>> >>> Best regards, >>> George >>> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> 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! >> Edit mailing list options or unsubscribe: >> >
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions 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! Edit mailing list options or unsubscribe:
