Hey Guys,
I am testing the t_set_no_e2e_cancel_reason in latest stable Kamailio (and also in 4.2.x) but it does not seem to work. Trying to disable it via e2e_cancel_reason=0 works as expected.
The target would be disabling in the script copying the reason from original CANCEL to hop-by-hop one like: ``` if($hdr(Reason)=="SIP;cause=487;text=ORIGINATOR_CANCEL") t_set_no_e2e_cancel_reason(1); ```
My version: ``` # kamailio -V version: kamailio 4.3.1 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 4.7.2 ```
I am at your disposal for any further troubleshooting steps.
Ta, DanB
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261
Are you doing the t_set_no_e2e_cancel_reason(1) for CANCEL processing? In the code it seems to be considered if it is done for INVITE processing.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261#issuecomment-125484018
Hey @miconda,
Yes, calling it in CANCEL block. More complete script would be like this: ``` if (is_method("CANCEL")) { if($hdr(Reason)=="SIP;cause=487;text=ORIGINATOR_CANCEL") t_set_no_e2e_cancel_reason(1); if (t_check_trans()) route(RELAY); exit; } ```
Putting a xlog there shows that the CANCEL matches properly there but no change in reason (cannot be deactivated).
Ta, DanB
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261#issuecomment-125491931
As commented before, the t_set_no_e2e_cancel_reason(1) should be used when handling the INVITE.
In your case, you can use the workaround of removing the header and applying the changes, so it is no header to propagate.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261#issuecomment-125496535
OK, in that case I have misunderstood you.
Will removing the header work in case of CANCEL?
Are you recommending something like this? ``` if (is_method("CANCEL")) { if($hdr(Reason)=="SIP;cause=487;text=ORIGINATOR_CANCEL") remove_hf("Reason"); if (t_check_trans()) route(RELAY); exit; } ```
I was under the impression the headers in CANCEL cannot be controlled but that could be in old times.
Ta, DanB
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261#issuecomment-125505934
Yes, you can't control much of headers in the CANCEL, but here is about propagating Reason header from incoming CANCEL to the outgoing one. If you remove it from incoming one and then do msg_apply_changes() before tm gets the chance to look at CANCEL, then there is nothing found to propagate.
I added a note to the docs of t_set_no_e2e_cancel_reason() about its usage for INVITE. I will look when I get a chance to see if it can be expanded to work when used for CANCEL.
For now I will close this issue.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261#issuecomment-126041808
Closed #261.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261#event-368630241
Thanks. That makes sense then.
Will test it and come back if any issues.
DanB
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/261#issuecomment-126044253
-
Dan Christian Bogos -
Daniel-Constantin Mierla