[asterisk-dev] [Code Review] 4417: res_pjsip_refer: Fix crash from a REFER and BYE collision.

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On Feb. 13, 2015, 4:39 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4417/
> -----------------------------------------------------------
> 
> (Updated Feb. 13, 2015, 4:39 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24700
>     https://issues.asterisk.org/jira/browse/ASTERISK-24700
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Analyzing a one off crash on a busy system showed that processing a REFER
> request had a NULL session channel pointer.  The only way I can think of
> that could cause this is if an outgoing BYE transaction overlapped the
> incoming REFER transaction in a collision.  Asterisk sends a BYE while the
> phone sends a REFER to complete an attended transfer.
> 
> * Made check the session channel pointer before processing an incoming
> REFER request in res_pjsip_refer.
> 
> * Fixed similar crash potential for res_pjsip supplement incoming request
> processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
> res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
> messages.
> 
> * Made res_pjsip_messaging respond to a message body too large with a 413
> instead of ignoring it.
> 
> 
> Diffs
> -----
> 
>   /branches/13/res/res_pjsip_send_to_voicemail.c 431735 
>   /branches/13/res/res_pjsip_sdp_rtp.c 431735 
>   /branches/13/res/res_pjsip_refer.c 431735 
>   /branches/13/res/res_pjsip_messaging.c 431735 
>   /branches/13/res/res_pjsip_caller_id.c 431735 
> 
> Diff: https://reviewboard.asterisk.org/r/4417/diff/
> 
> 
> Testing
> -------
> 
> Since this is a very timing dependent problem, I made some calls and did an attended transfer for a warm fuzzy that nothing serious broke.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150216/65c440b5/attachment.html>