[OpenSIPS-Users] uac_replace_from in CANCEL
Bogdan-Andrei Iancu
bogdan at opensips.org
Fri Jan 5 10:55:26 UTC 2024
Hi Jason,
For changing the FROM hdr (at INVITE time), better use the
uac_replace_from() function [1] - by doing this, the TM will become
aware of the change and reflect it into CANCEL too.
[1]
https://opensips.org/html/docs/modules/3.4.x/uac.html#func_uac_replace_from
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 24.12.2023 13:33, nz deals wrote:
> Hi Bogdan,
> Agreed that the RFC3261 CANCEL is truly built using INVITE. In my
> case, somehow CANCEL is not the same as the initial INVITE. Due to the
> complexity of my case I have hard times to fix the issue. Let me
> explain a bit.
> On the INVITE i change the From Header, which i can see has also been
> changed during Authorization.
> If i CANCEL then the From header is different (it's the same as i have
> before making my change).
>
> I am also using topology_hiding().
>
>
> under the main route i change the From header for INVITE
>
> set_advertised_address("104.13.xx.xx "); # same as i have used
> in the advertised_address
> # this is my cancel processing
> if (is_method("CANCEL")) {
> if (t_check_trans())
> t_relay(8);
> exit;
> }
> if (has_totag()) {
> if(topology_hiding_match()) {
> # remove and add a custom one
> remove_hf("From");
> append_hf("From:
> \"$fU\"<sip:$fU@$td;custom=$var(custom)>;tag=$ft\r\n");
> force_send_socket("tls:192.xx.xx.xx:5061");
> }
> }
> My opensips version is 3.4.2
> My listening socket is socket=tls:ens192:5061 tag ens192 (its the
> same 192.xx.xx.xx IP that you see in the force_send_socket)
> I am also using public ip as follows
> advertised_address=104.13.xx.xx
> alias=104.13.xx.xx
>
> Regards,
> Jason
>
> On Thu, 21 Dec 2023 at 02:31, Bogdan-Andrei Iancu
> <bogdan at opensips.org> wrote:
>
> Hi Jason,
>
> In transactional stateful SIP, the CANCEL requests are hop by hop
> - each hop in the path is generating its own CANCEL requests to
> the next hop, which consumes it; there is no actual relaying of
> the CANCELs. So, the replacing (which works in relaying mode only)
> doesn't fit here.
>
> Even more, the RFC3261 gives a rigorous way for building the
> CANCEL requests, they are to be built 100% based on the INVITE
> request only (nothing more). OpenSIPS internally builds the CANCEL
> in accordance to the corresponding INVITE, so you should not need
> any such changes.
>
> May you detail why you think you need this FROM replacement?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
> https://www.opensips-solutions.com
> https://www.siphub.com
>
> On 20.12.2023 12:38, nz deals wrote:
>> Hi,
>> I've been attempting to modify the From header in the CANCEL, but
>> it seems the changes aren't taking effect. I've also experimented
>> with remove_hf and append_hf, but unfortunately, these methods
>> didn't work either. Could someone kindly offer suggestions if I
>> might be overlooking something?
>>
>> This is in the main request route
>>
>> if (is_method("CANCEL")) {
>> uac_replace_from("","sip:test at test.com
>> <mailto:sip%3Atest at test.com>");
>> if (t_check_trans())
>> t_relay(8);
>> exit;
>> }
>>
>>
>>
>> Regards,
>> Jason
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240105/f357523f/attachment.html>
More information about the Users
mailing list