[SR-Users] Re: Latest point releases seem to break early dialog UPDATEs from B-side when using topos (again)
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 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 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 >> 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:
[SR-Users] Re: Latest point releases seem to break early dialog UPDATEs from B-side when using topos (again)
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 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 > 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:
[SR-Users] Re: Latest point releases seem to break early dialog UPDATEs from B-side when using topos (again)
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 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:
