[SR-Users] To Header Manipulation

[Sam Ware]

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 at 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:

$avp(new_to_hdr_uri) = $(tu{re.subst,/sip:(.*[\*#])(.*)/sip:\2/});
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201014/d0629fbc/attachment.htm>