Re: Regresion from 5.8.4 to 5.8.6

Ihor Olkhovskyi via sr-users <[email protected]>
Newsgroups gmane.comp.voip.ser
Message-ID <[email protected]>
Xenofon,


Thanks for looking into it, for sure I do use other advanced logic, it's 
just a part of a script that I've found not working for me.


I'll try to make a lab that reproduce this behavior, but it will take 
some time for sure. Why I pinpointed to this commit, it was about 
"enclosing URI in <>" what is actually happening in my case, but a bit 
incorrect.


I'll try to add some logs around commit code to see what exactly is 
happening there.


Le 16/12/2025 à 13:29, Xenofon Karamanos 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 
> <mailto: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 
> <https://github.com/kamailio/kamailio/commit/6367a41f64ed165792ffe71ea310fd917947ccba>
>
> Le mar. 16 déc. 2025 à 09:48, Ihor Olkhovskyi <[email protected] 
> <mailto:[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] <mailto:[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] <mailto:[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
>                 <mailto: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
>                 <mailto: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]>
>                 <mailto:sip:[email protected]>sip:[email protected];tag=83017fca-9fe4-493e-9e66-406034482628
>                 <mailto: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]
>                 <mailto:[email protected]> To unsubscribe
>                 send an email to [email protected]
>                 <mailto:[email protected]> Important:
>                 keep the mailing list in the recipients, do not reply
>                 only to the sender!
>
>             -- Daniel-Constantin Mierla (@ asipto.com
>             <http://asipto.com>) twitter.com/miconda
>             <http://twitter.com/miconda> -- linkedin.com/in/miconda
>             <http://linkedin.com/in/miconda> Kamailio Consultancy,
>             Training and Development Services -- asipto.com
>             <http://asipto.com> Kamailio World Conference, May 7-8,
>             2026 - Berlin, Germany -- kamailioworld.com
>             <http://kamailioworld.com>
>
>
>
>         --
>         Best regards,
>         Ihor (Igor)
>
>
>
>     --
>     Best regards,
>     Ihor (Igor)
>
>
>
> --
> Best regards,
> Ihor (Igor)

-- 
Regards,
Ihor

__________________________________________________________
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!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.