The Contact hdr is not relevant for TM, still it is if you are using
nathelper (for pinging) or dialog support with topo hiding (where the Ct
must be retained).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 15.01.2024 21:07, nz deals wrote:
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 <[email protected]>
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
<[email protected]> 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:[email protected]
<mailto:sip%[email protected]>");
if (t_check_trans())
t_relay(8);
exit;
}
Regards,
Jason
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
