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

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to