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-us...@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 (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
