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
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...
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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi
When I do assigning:
$fU = $sht(htble=>xxx:$var(nnnn));
The Kamailio 4.4.2 write in network socket the old value of $fU.
So, it seems to be there a bug?
Best Regards, CMA
Hello,
have you watched the traffic on the network with ngrep/sngrep/... or did you just print the value with xlog() or something similar?
Cheers, Daniel
On 28.05.19 02:22, Cléviton Mendes de Araújo wrote:
Hi
When I do assigning:
$fU = $sht(htble=>xxx:$var(nnnn));
The Kamailio 4.4.2 write in network socket the old value of $fU.
So, it seems to be there a bug?
Best Regards, CMA
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Hi, Mr. Mierla
Yes.
It was through ngrep, in fact, I detected the source of the problem. It was not quite a bug anymore, but yes, it was a lapse of mine. My INVITE had the From and P-Asserted-Identity header fields. In this scenario our Telephone Carrier relies more on the PAI header to set the originating number because we using DID. That's why I was thinking that the assignment to $fU variable was bugged.
So that there is not any error in the Identification of the DID originator number, I decided to define the two fields:
$fU = $var(newUsername); subst_hf("P-Asserted-Identity", "/<sip:[^@]*@/<sip:$var(newUsername)@/", "a");
I solved the problem like this.
Greetings! Cleviton
Values are not commuted until the packet is going out.
On Tue, 28 May 2019 at 01:19, Cléviton Mendes de Araújo < clevitonmendes@gmail.com> wrote:
Hi
When I do assigning:
$fU = $sht(htble=>xxx:$var(nnnn));
The Kamailio 4.4.2 write in network socket the old value of $fU.
So, it seems to be there a bug?
Best Regards, CMA
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-
Cléviton Mendes de Araújo -
Daniel-Constantin Mierla -
David Villasmil