[Devel] Re: TM failure route bug

[Klaus Darilion]

Hi Bogdan!

Thanks for the fix! No crashes yet :-)

regards
klaus


Bogdan-Andrei Iancu wrote:
> Hi everybody,
> 
> thanks to the help from Klaus, we manage to hunt down one of the 
> remaining bugs. It was reported as a random crash when executing failure 
> route for CANCEL requests.
> 
> I found rather interesting the scenario and what was happening inside 
> OpenSER, so, here is the short-version story - basically a story about 
> an INVITE and its CANCEL:
>    1) a fast CANCEL happens and the CANCEL is processed by the proxy 
> prior to INVITE. So, no INVITE is matched by CANCEL.
>    2) CANCEL is is just forwarded statefully without any other info 
> regarding the INVITE
>    3) the INVITE is finally processed and, without any knowledge of 
> CANCEL, it's statefully forwarded.
>    4) the destination for both CANCEL and INVITE (the same) does not 
> reply at all
>    5) final response timer (FR) hits for CANCEL and triggers the sending 
> of 408 for CANCEL
>    6) 408 reply triggers failure route execution for CANCEL
>    7) t_relay() called in failure route for CANCEL looks again for the 
> corresponding INVITE (if any) and this time actually finds one
>    8) as the found INVITE transaction still has a pending branch (the 
> initial forward) which haven't received any reply, it's trigger the 
> sending of "487 Request Terminated" reply for the INVITE
>    9) 487 reply triggers failure route execution for INVITE. But 
> STOP!!!!! we are already in another failure route execution for CANCEL 
> reply (step 6). So we get to have nested failure route execution!!!!!!
> 
> 
> The problem is that failure route execution wasn't design for nested 
> calls as it relays on static variables to backup vital informations 
> regarding the TM environment and request.
> 
> And here is the crash :(.
> 
> I did a fast fixup in TM : failure route execution uses a stack to 
> backup the info (instead of static variables). This will allow normal 
> processing of this scenario.
> This fixup is not the best: as previously talked with Klaus, the normal 
> behaviour would be that on step 2, when the INVITE is processes, to 
> detect the presence of the CANCEL and to stop any relay for INVITE. But 
> this is more complex and I prefer to do it after the release.
> 
> Again, many thanks to Klaus for help in testing  ;)
> 
> 
> regards,
> bogdan
> 
>