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 <bog...@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 <bog...@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:t...@test.com"); >> if (t_check_trans()) >> t_relay(8); >> exit; >> } >> >> >> >> >> Regards, >> Jason >> >> _______________________________________________ >> Users mailing >> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users