[asterisk-dev] [Code Review] 4001: PJSIP: Prevent T38 framehook being put on wrong channel

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On Sept. 18, 2014, 4:19 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4001/
> -----------------------------------------------------------
> 
> (Updated Sept. 18, 2014, 4:19 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This changes gives framehooks a reverse-direction masquerade callback in addition to chan_fixup_cb similar to the callback added to datastores to handle the same situation. The new callback provides the same parameters as the fixup callback, but is called on the new channel's framehooks before moving framehooks from the old channel to the new channel. This gives the framehooks an oppurtunity to decide whether they should remain on the new channel or be removed.
> 
> This new callback is used to prevent the PJSIP T.38 framehook from remaining on a masqueraded channel if the new channel is not also a PJSIP channel. This was causing a crash when a local channel was masqueraded into a PJSIP channel and the framehook was executed on the local channel since the channel's tech private data was not structured as expected.
> 
> 
> Diffs
> -----
> 
>   branches/12/res/res_pjsip_t38.c 423230 
>   branches/12/main/framehook.c 423230 
>   branches/12/include/asterisk/framehook.h 423230 
> 
> Diff: https://reviewboard.asterisk.org/r/4001/diff/
> 
> 
> Testing
> -------
> 
> This corrected my reproduction of the crash and fixed the crash for the original reporter.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140918/5d36512a/attachment-0001.html>