Thanks Daniel. I have added the t_is_canceled to the top of my failure blocks and the xdbg() has been removed. - I hadn't noticed the lack of curly braces, but it was only there to help me trace the cancel process. Stephen Dodge From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: 02 April 2012 10:28 To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List Cc: Stephen Dodge (Bistech) Subject: Re: [SR-Users] CANCEL message processing 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/ ________________________________ Information in this message, including any attachments, is confidential to the person to whom it is addressed and may be legally privileged. If you are not the intended recipient please notify the sender and delete the message from your system. Please note that Bistech Group plc, Bistech plc, Bisnet Limited and the sender do not accept any responsibility for viruses. It is your responsibility to check the e-mail and any attachments for viruses. Calls may be monitored and recorded.