[asterisk-dev] [Code Review] 4174: Fix race condition where identical SIP requests are processed by multiple threads.

[Joshua Colp]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4174/#review13741
-----------------------------------------------------------

Ship it!


Ship It!


/branches/12/res/res_pjsip_pubsub.c
<https://reviewboard.asterisk.org/r/4174/#comment24239>

    Ew.


- Joshua Colp


On Nov. 12, 2014, 9:51 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4174/
> -----------------------------------------------------------
> 
> (Updated Nov. 12, 2014, 9:51 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> During testing, an odd situation was encountered. In the test, a phone sent an INVITE to Asterisk. A half second later, after receiving no response, the phone retransmits the INVITE to Asterisk. About this time, Asterisk starts to process both incoming INVITEs at the same time in separate threads.
> 
> In thread 1, a dialog is successfully created, a 100 Trying response is sent, and the call is sent into the dialplan.
> In thread 2, the dialog cannot be created because thread 1 has already created a transaction in PJSIP with the same details. The collision results in thread 2 sending a 500 response to the phone.
> 
> At this point, the phone has received an error final response, so the phone assumes the call is failed. However, Asterisk has a successful dialog going, still, so Asterisk continues on with the call. This results in some "fun" situations. Luckily, the situations haven't proven fatal for Asterisk, but they are very confusing for people involved in the calls.
> 
> The solution proposed to fix this problem is to not respond to incoming requests if attempting to create a transaction results in the PJ_EEXISTS error. The logic is that if PJ_EEXISTS is returned, that means that elsewhere, we have already successfully created a transaction for this request and we can safely ignore this one.
> 
> After auditing the code, the only places that required changes were the places that created dialogs based on incoming requests. Places that create out-of-dialog stateful responses were not reacting to errors by sending stateless responses.
> 
> The actual change implemented here is to modify ast_sip_create_dialog_uas() to take an additional parameter that is the status returned from PJSIP when attempting to create the dialog. This way, we can react accordingly if the dialog cannot be created. The Asterisk 12 changes are presented here. The Asterisk 13 changes are on /r/4175
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/res_pjsip_session.c 427735 
>   /branches/12/res/res_pjsip_pubsub.c 427735 
>   /branches/12/res/res_pjsip.c 427735 
>   /branches/12/include/asterisk/res_pjsip.h 427735 
> 
> Diff: https://reviewboard.asterisk.org/r/4174/diff/
> 
> 
> Testing
> -------
> 
> I ran the testsuite nominal incoming calls tests and the presence subscription tests to be sure that this change did not adversely affect them. They still pass.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141113/45297b85/attachment.html>