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

4 Oct 2016

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 &lt;miconda(a)gmail.com&gt;
 To: "Kamailio (SER) - Development Mailing List"
         &lt;sr-dev(a)lists.sip-router.org&gt;
 Subject: Re: [sr-dev] $fU pv Assign New Value Isnt Rewrite old value
 Message-ID: &lt;6366e966-fb9d-28d9-b002-cbb5f143c24b(a)gmail.com&gt;
 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_header…
...

 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@IP-Address>
 > .................
 > .................
 >
 >
 > This two assignments are realizing on same route block.
 >
 > So, it seems to be a bug.
 >
 >
 >
 > Best Regards,
 > CMA
 >
 > 