2 Apr
2012
2 Apr
'12
11:27 a.m.
Hello,
On 3/30/12 5:17 PM, Stephen Dodge (Bistech) wrote:
Hi Guys,
I have a question regarding the correct processing for cancelled requests
1. (A)--------------------INVITE ------------------->(B)
2. (A)<------------------180 RIGING------------------(B)
3. (A)--------------------CANCEL-------------------->(B)
4. (A)<------------------OK--------------------------(B)
5. (A)<---------487 Request Terminated---------------(B)
6. (A)--------------------ACK----------------------->(B)
I have the following section to deal with cancel messages however I am
finding that the 487 response still hits my failure_route block.
The failure_route block is called for serial forking.
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
xdbg("## BISNET ## - Cancel Processing\n");
t_relay();
exit;
}
first, a quick note about cfg snippet above:
- you added xdbg() after the IF which makes t_relay() to be executed
always -- you should add curly braces when having more than one action
in an IF statement.
I can obviously do something like a
(!t_check_status("487")) within
the failure block but is there a better way to deal with this response ?
Although this doesn't really cause me a problem at the moment I see
the following error in the debug
/usr/sbin/kamailio[23786]: ERROR: tm [tm.c:1368]: ERROR: w_t_relay_to:
t_relay_to failed
/usr/sbin/kamailio[23786]: ERROR: sl [sl_funcs.c:282]: ERROR:
sl_reply_error used: transaction canceled (487/SL)
As always your help is appreciated.
you have to add at the top of failure route:
if (t_is_canceled()) {
exit;
}
The failed transaction is the INVITE, which gets 487. While makes no
point in rerouting the INVITE since the caller canceled, it is useful in
some cases to get to failure route (e.g., statistics, end rtpproxy relay
session initiated for INVITE, ...).
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
http://www.asipto.com/index.php/kamailio-advanced-training/