Re: Regresion from 5.8.4 to 5.8.6

Ihor Olkhovskyi via sr-users <[email protected]>
Newsgroups gmane.comp.voip.ser
Message-ID <CAJTkRNvd6qrqgnXJOPT4jkXOPEVyae6-UjKeHYMvB9+KGz4byg@mail.gmail.com>
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)

__________________________________________________________
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.