[asterisk-dev] [Code Review] 4414: res_pjsip_session: Fix double re-INVITE collision crash.

Mark Michelson reviewboard at asterisk.org
Thu Feb 12 14:59:52 CST 2015


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

Ship it!


Ship It!

- Mark Michelson


On Feb. 11, 2015, 10:37 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4414/
> -----------------------------------------------------------
> 
> (Updated Feb. 11, 2015, 10:37 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24727
>     https://issues.asterisk.org/jira/browse/ASTERISK-24727
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> A multi-asterisk box setup with direct media enabled would occasionally
> crash when two re-INVITE collisions on a call leg happen in a row.
> 
> The re-INVITE logic only had one timer struct to defer the re-INVITE.
> When the second collision happens the timer struct is overwritten and put
> into the timer heap again.  Resources for the first timer are leaked and
> the heap has two positions occupied by the same timer struct.  Now the
> heap ordering is potentially corrupted, the timer will fire twice, and any
> resources allocated for the second timer will be released twice.
> 
> * The solution is to put the collided re-INVITE into the delayed requests
> queue with all the other delayed requests and cherry pick the next request
> that can come off the queue when an event happens.
> 
> * Changed to put delayed BYE requests at the head of the delayed queue.
> There is no sense in processing delayed UPDATEs and re-INVITEs when a BYE
> has been requested.
> 
> * Made the start of a BYE request flush the delayed requests queue to
> prevent a delayed request from overlaping the BYE transaction.  I saw a
> few cases were a delayed re-INVITE got started after the BYE transaction
> started.
> 
> * Changed the delayed_request struct to use an enum instead of a string
> for the request method.  Cherry picking the queue is easier with an enum
> than string comparisons and the compiler can warn if a switch statement
> does not cover all defined enum values.
> 
> * Improved the debug output to give more information.  It helps to know
> which channel is involved with an endpoint.  Trunks can have many channels
> associated with the endpoint at the same time.
> 
> 
> Diffs
> -----
> 
>   /branches/13/res/res_pjsip_session.c 431716 
> 
> Diff: https://reviewboard.asterisk.org/r/4414/diff/
> 
> 
> Testing
> -------
> 
> Ran the full testsuite with the patch.  All but one test passes and the failing test fails with or without the patch.
> 
> Setup a test environment with two asterisk boxes and direct media enabled for all legs to perform this call repeatedly:
> PJSIP/100 --> box 1 --> box 2 --> box 1 --> PJSIP/200
> 
> 1) 100 calls 200
> 2) 200 answers
> 3) 100 hangs up
> 4) repeat call
> 
> A crash no longer happens on either Asterisk box with the patch.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150212/7c37b255/attachment.html>


More information about the asterisk-dev mailing list