19 Mar
2015
19 Mar
'15
10:59 p.m.
The issue seems to be related to the invite transaction (which was
canceled), apparently after running its failure handlers. By chance, do
you know if the invite was relayed?
Daniel
On 19/03/15 21:56, Alex Balashov wrote:
On 03/19/2015 04:52 PM, Daniel-Constantin Mierla
wrote:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
Are you doing any operations in the failure route
for a canceled invite?
Like add/remove headers to the invite?
No; only handling for a CANCEL in main route block is:
if(is_method("CANCEL")) {
xlog("L_INFO",
"[R-MAIN:$ci] CANCEL received from $si
(RURI=$ru)\n");
#!ifdef WITH_RTPPROXY
set_rtp_proxy_set("1");
unforce_rtp_proxy();
#!endif
if(!t_relay_cancel()) {
sl_send_reply("500", "Internal Server
Error");
exit;
}
exit;
}
And in failure_route:
if(t_is_canceled()) {
xlog("L_INFO", "[R-OUTBOUND-VENDOR-LNP-DIP-CATCH:$ci]
Transaction cancelled\n");
# Nothing further necessary - CANCEL was already processed
# in TM handling in main request route.
exit;
}
The only other nuance, if it might be relevant, is that the initial
INVITE was processed and relayed out of an rtimer process, after being
t_suspended and being put on an mqueue and t_consumed out of rtimer.
However, this is not the case with CANCEL or any other requests,
sequential or initial.
-- Alex