[OpenSIPS-Users] uac_replace_from in CANCEL

[nz deals]

Thank you Bogdan,

It seems that replacing remove_hf with uac_replace_from has resolved the
issue.
Just a quick question: if I use remove_hf("Contact") during INVITE, will TM
become aware of this change?



Regards,
Jason

On Fri, 5 Jan 2024 at 23:55, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> 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");
>>                 if (t_check_trans())
>>                         t_relay(8);
>>                 exit;
>>         }
>>
>>
>>
>>
>> Regards,
>> Jason
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240116/49000737/attachment.html>