Good advice. However, this is such an incredibly bizarre, weird thing to do, that I think one should do some due diligence and really get down to the bone of why exactly you see the need to do this.
A noncompliant UA might be a surface-level story. Perhaps there is some other casual factor. I'd get to the bottom of it. The most important thing of all is to not respond with the hammer of Kamailio programmatic route script flexibility just because you see some kind of nail; maybe it's not meant to be nailed. In every major theology, there are things which are "haram" or similar -- things which are clearly possible, but which are against God's will. -- Alex > On Dec 28, 2024, at 12:02 pm, James Browne <[email protected]> wrote: > >> Is there a way to get loose_route() to operate on freshly added header > without calling msg_apply_changes? > > I doubt it. My experience with kamailio tells me that this simply is > never going to work. > > I've two suggestions (three if we count agreeing with Alex's > suggestion to consider not supporting that UA). > - Get kamailio to manually do the steps that loose_route() would do > anyway. This is messy, because it requires good understanding of loose > routing. You might remove the supplied Route header field, then get > the transport/host/port from your saved Record-Route header fields, > and then set the $du and $fs explicitly (and then get any _other_ > Record-Route values and insert them as Route values), all while being > aware of "r2" parameters (to know whether to exclude one or two Route > values). It might work, but I don't think I'd ever want to even > attempt this nonsense. > - Add TOPOS to kamailio. That strips the topology from the message, > and then the faulty UA should never see Route or Record-Route header > fields so never wreck them. It requires kamailio to keep state in a > database, though, but it should work well. > > James > > On Fri, 27 Dec 2024 at 12:19, Alex Balashov via sr-users > <[email protected]> wrote: >> >> Hi Benoît, >> >> What about the PacketCable spec constrains you only to a single Route >> header? I have never heard of such a constraint, and if it existed, it would >> be a pretty damning violation of a mechanism very deeply infused into the >> heart of RFC 3261. >> >> I mean this with all due respect: once again, you're doing something very >> clever, but maybe a little too clever, perhaps so clever that you're the >> only Kamailio implementor on the planet who is doing it. When that happens, >> it is possible that 1) you and you alone have such unique problems, and must >> devise correspondingly intrepid and ingenious solutions, or 2) there is >> another (simpler) approach. I would encourage you to think more >> strategically and less tactically in these cases: perhaps it is >> programmatically possible, somehow, to solve the problem, but does it mean >> that it should be solved that way, or solved at all? >> >> I cannot say what the better approach is in this case, but it's safe to say >> that no proxy should be storing and restoring the Route set. If you truly >> have a type of endpoint that does not implement the most basic elements of >> the SIP standard, perhaps a business decision should be taken to simply not >> support it? >> >> -- Alex >> >>> On Dec 27, 2024, at 5:18 am, Benoît Panizzon via sr-users >>> <[email protected]> wrote: >>> >>> Hi List >>> >>> To handle CPE which can only handle a limited number of route header >>> (PacketCable SIP specification), I need to store and restore the route >>> header (limited topology hiding only affecting Route Header) to present >>> the CPE only one Route or RR header. >>> >>> I pass the ID of the stored route-set via RR param. >>> >>> So when I get a message back from the CPE is: >>> >>> * Take ID from RR param and pull stored route set from cache. >>> * remove_hf("Route"); >>> * insert_hf("Route: $avp(stored-routeset)\r\n"); >>> * msg_apply_changes(); >>> * loose_route(); >>> >>> I found loose_route() only to be able to correctly determine the next >>> hop, if I first did apply the changes. >>> >>> But after adding rtpengine to the mix, I got back into the known >>> situation that calling rtpengine (on the branch route) after calling >>> msg_apply_changes() results in duplicate SDP. >>> >>> Is there a way to get loose_route() to operate on freshly added header >>> without calling msg_apply_changes? >>> >>> -- >>> Mit freundlichen Grüssen >>> >>> -Benoît Panizzon- @ HomeOffice und normal erreichbar >>> -- >>> I m p r o W a r e A G - Leiter Commerce Kunden >>> ______________________________________________________ >>> >>> Zurlindenstrasse 29 Tel +41 61 826 93 00 >>> CH-4133 Pratteln Fax +41 61 826 93 01 >>> Schweiz Web http://www.imp.ch >>> ______________________________________________________ >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions -- >>> [email protected] >>> To unsubscribe send an email to [email protected] >>> Important: keep the mailing list in the recipients, do not reply only to >>> the sender! >> >> -- >> Alex Balashov >> Principal Consultant >> Evariste Systems LLC >> Web: https://evaristesys.com >> Tel: +1-706-510-6800 >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions -- >> [email protected] >> To unsubscribe send an email to [email protected] >> Important: keep the mailing list in the recipients, do not reply only to the >> sender! -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
