[SR-Users] Re: how to call loose_route() after adding route header without using msg_apply_changes?

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 <sr-users(a)lists.kamailio.org> 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 <sr-users(a)lists.kamailio.org> 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. > > > > > 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 -- sr-users(a)lists.kamailio.org > > 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! > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org > 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!