Hello,
change operations over parts of sip headers are not simple "set" operations, see these FAQ items for a better understanding of what happens there:
*
https://www.kamailio.org/wiki/tutorials/faq/main#why_changes_made_to_headers_or
*
https://www.kamailio.org/wiki/tutorials/faq/main#why_parts_of_fromto_header_app
I just added the second one to be more focused on this specific case.
Cheers,
Daniel
Wondering if this is intended behavior. We have a customer doing some craziness with the TO header. They are including their tech prefix in the TO header as well as the RURI. It doesn't cause any issue in our systems but apparently it does with one of our vendors. In an effect to prevent the issue, we thought we would check if the tech prefix was added on the TO header and remove it.
Initially, I tried this by changing the $tU variable.
$avp(tp_len) = $(avp(techprefix){s.len}) + 1; # Get the Length of the Tech Prefix and add 1 for the # or *$tU = $(tU{s.strip, $avp(tp_len)});
The result ended up with the duplication of the DNIS: sut <sip:911999#1812555111118125551111@172.16.3.45:5060>
Where 911999# was the tech prefix and 18125551111 is the DNIS which was still an issue for the vendor.
Through additional reading, I found the suggestion to use the uac_replace_to function in the UAC module which I implemented as follows:
uac_replace_to("$avp(new_to_hdr_uri)");
This resulted in the original TO header username to be appended at the end of the uri: sut <sip:18125551111@172.16.3.45:5060911999#18125551111>
Wondering if I am doing something wrong or this is the way these functions are designed to protect the TO header contents for Dialog matching.
--
Sam D Ware
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla