[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