[sr-dev] $fU pv Assign New Value Isnt Rewrite old value sr-dev Digest, Vol 96, Issue 3

[Cléviton Mendes de Araújo]

Daniel, thank you in advance, by his answer quick.

But pay attention to the second assignment, the new value is append to the
end of the previous content of $fU variable and isn't overwriting the $fU
variable with the new value. This behaviour is what one I expected.

That behaviour is Design definition?

Beforehand, let me I join the Kamailio development community.

Best Regards
CMA

> Date: Tue, 4 Oct 2016 08:07:03 +0200
> From: Daniel-Constantin Mierla <miconda at gmail.com>
> To: "Kamailio (SER) - Development Mailing List"
>         <sr-dev at lists.sip-router.org>
> Subject: Re: [sr-dev] $fU pv Assign New Value Isnt Rewrite old value
> Message-ID: <6366e966-fb9d-28d9-b002-cbb5f143c24b at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> it is by design -- $fU is an operation over a sip header, which is done
> in a special way for performance considerations -- for more details and
> how to deal with multiple changes see:
>
>  -
>
https://www.kamailio.org/wiki/tutorials/faq/main#why_changes_made_to_headers_or
>
> Cheers,
> Daniel
>
> On 04/10/16 01:13, Cléviton Mendes de Araújo wrote:
> > Hi,Kamailio Community
> >
> >
> >
> > Is there a bug when we assign new value to $fU pseudo-variable multi
time?
> >
> > My scenery is according below:
> >
> >
> >
> > In a point on config file, let us that $fU value is: 7777. When I do
> > assign:
> >
> > .....
> > $fU = "5555" + $fU;        ### Here $fU = 55557777
> > .....
> >
> > In another point, let us that value $sht(htble=>$var(nnnn)) hold is:
> > 44444444. And I do:
> >
> > .....
> > $fU = $sht(htble=>$var(nnnn));     #### Here, it seems that this is
> > happening $fU = 5555777744444444
> > .....
> >
> > When I turn on ngrep analysis, I catch From header:
> >
> > .................
> > .................
> > From: "User Name" <sip:5555777744444444 at IP-Address>
> > .................
> > .................
> >
> >
> > This two assignments are realizing on same route block.
> >
> > So, it seems to be a bug.
> >
> >
> >
> > Best Regards,
> > CMA
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20161004/711150dd/attachment.html>