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:mico...@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.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to