[sr-dev] Crash bug

Daniel-Constantin Mierla miconda at gmail.com
Thu Mar 19 21:59:47 CET 2015


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:
>
>> 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
>

-- 
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




More information about the sr-dev mailing list