Dear Xenofon, Daniel, I was able to replicate issue in an isolated environement
Configs are here; https://github.com/igorolhovskiy/kamailio-dev-dc/tree/kamailio_bug_5.8.5 Idea is you starting up the lab with > docker compose up -d go inside kamailio container and start sngrep there > docker compose exec kamailio bash # sngrep On a separate terminal start sipp with file provided in sipp folder sipp -r 1 -m 1 -sf uac_1.xml -s 11111 localhost And on sngrep you see the behavoir I've described. From: sip:[email protected]:5061;tag=743711SIPpTag001 -> From: < sip:[email protected]:5061>sip:90002@localhost;tag=743711SIPpTag001 Hope, this helps Le mar. 16 déc. 2025 à 13:29, Xenofon Karamanos <[email protected]> a écrit : > Hey Ihor, > > I can't seem to be able to reproduce this nor in master nor in 5.8.6. > > My config is the default one with the following changes: > > ``` > .... > loadmodule "uac.so" > modparam("rr", "append_fromtag", 1) > ... > request_route { > $avp(callerID) = "81982934"; > > xlog("Incoming request: $rm from $fu to $ru (IP:$si:$sp)\n"); > xlog("callerID set to: $avp(callerID)\n"); > > uac_replace_from("sip:" + $avp(callerID) + "@localhost.localdomain"); > // $fu = "sip:" + $avp(callerID) + "@localhost.localdomain" > > // msg_apply_changes(); > xlog("Modified request FROM: $fu\n"); // Not modifed beacuse we didn't > use msg_apply_changes(); > > t_relay("127.0.0.1", "5050"); // Should modify the FROM header when > forwarind as verified by sngrep > ... > } > ``` > > Crafting a message with you exact `From: > sip:[email protected];tag=83017fca-9fe4-493e-9e66-406034482628` > produces From: > sip:[email protected];tag=83017fca-9fe4-493e-9e66-406034482628` > according to sngrep and inspecting the headers. > > Relevant logs: > *ERROR*: {1 2 INVITE a84b4c76e66711} <script>: Incoming request: INVITE > from sip:[email protected] to sip:[email protected] (IP: > 127.0.0.1:42486) > *ERROR*: {1 2 INVITE a84b4c76e66711} <script>: callerID set to: 81982934 > *ERROR*: {1 2 INVITE a84b4c76e66711} <script>: Modified request FROM: > sip:[email protected] > > > > Do you perform some other advanced logic or use some modparams that might > have modified this behavior? > > Thanks, > Xenofon > > > ------------------------------ > *From:* Ihor Olkhovskyi via sr-users <[email protected]> > *Sent:* Tuesday, December 16, 2025 10:56 > *To:* Kamailio (SER) - Users Mailing List <[email protected]> > *Cc:* Ihor Olkhovskyi <[email protected]> > *Subject:* [SR-Users] Re: Regresion from 5.8.4 to 5.8.6 > > And I have a strong impression that this is the commit, that introduced > this behavoir > > > https://github.com/kamailio/kamailio/commit/6367a41f64ed165792ffe71ea310fd917947ccba > > Le mar. 16 déc. 2025 à 09:48, Ihor Olkhovskyi <[email protected]> a > écrit : > > A bit update: > > uac_replace_from() behave the same way as assigning to $fu (measn > incorrect), and I confirm it on 5.8.5 and onwards (for the moment). > > So, somewhere between 5.8.4 and 5.8.5 this regression was introduced. > > Le lun. 15 déc. 2025 à 15:31, Ihor Olkhovskyi <[email protected]> a > écrit : > > Daniel, > > That's the thing, if I comment out just this string, there is no such > behavoir. > > I will look at uac_replace_from(), but assigning $fu is quite a basic > operation and is ok in a previous version. I've checked, there is no double > changes to $f... family of variables and no msg_apply_changes() in between. > And yes, $fu is changed before creating a transaction. > > I'll dig more in the code to see what can cause this, but my message was > maybe just a warning to community, that transition from 5.8.4 to 5.8.6 > might be not flawless, > > Cheers, > Ihor > > Le lun. 15 déc. 2025 à 15:17, Daniel-Constantin Mierla <[email protected]> > a écrit : > > I don't recall changes on this during the same release series, normally > you should use assignments to $fu in a very careful way, recommended way is > with uac_replace_from(). You have to check you config and be sure you do > not make changes over From-URI twice or more, or try to use > msg_apply_changes() if you do it in request_route before the transaction in > created. > > Cheers, > Daniel > On 15.12.25 14:15, Ihor Olkhovskyi via sr-users wrote: > > Not sure where the bug is, just noticed when playing on local development > Kamailio installation, that simple rewrite of $fu start to act funky. > > Initial From field in a packet is: > > From: > sip:[email protected];tag=83017fca-9fe4-493e-9e66-406034482628 > > In the code I'm having a statement > > $fu = "sip:" + $avp(callerID) + "@localhost.localdomain"; > > Resulting From field on 5.8.4 looks like > > From: > sip:[email protected];tag=83017fca-9fe4-493e-9e66-406034482628 > > Note the 2 spaces after From, but it's ok, I guess, no other changes which > is fine. > > But exact the same config file on 5.8.6 giving this: > > From: <sip:[email protected]> > <sip:[email protected]> > sip:[email protected];tag=83017fca-9fe4-493e-9e66-406034482628 > > Which is not correct SIP URI. I'm not sure when the issue was introduced, > but that's what I've found. If will have a bit more time, will try to > investigate deeper, maybe just to warn about possible bugs with the > versions greater than 5.8.4 (have not tested 5.8.5) > > -- > Best regards, > Ihor (Igor) > > __________________________________________________________ > 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! > > -- > Daniel-Constantin Mierla (@ asipto.com)twitter.com/miconda -- > linkedin.com/in/miconda > Kamailio Consultancy, Training and Development Services -- asipto.com > Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- > kamailioworld.com > > > > -- > Best regards, > Ihor (Igor) > > > > -- > Best regards, > Ihor (Igor) > > > > -- > Best regards, > Ihor (Igor) > -- Best regards, Ihor (Igor)
__________________________________________________________ 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!
