[asterisk-dev] [Code Review] 3850: res_pjsip_session: Ensure session supplements are invoked before redirection occurs

[Matt Jordan]

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

Ship it!


Ship It!

- Matt Jordan


On July 25, 2014, 6:05 a.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3850/
> -----------------------------------------------------------
> 
> (Updated July 25, 2014, 6:05 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Currently the PJSIP INVITE session module handles all redirects and calls into us using a callback when they occur. We react based on this. Unfortunately, it is invoked before any transaction state changes occur which means that any registered session supplements are invoked *AFTER* our callback and after we handle the redirect scenario. This means that we may have already call forwarded the channel elsewhere before something like res_pjsip_diversion has any chance to update the redirecting information on the channel.
> 
> There are two options for fixing this:
> 1. Change the res_pjsip_diversion module to use a SIP service to get access to the redirect before the PJSIP INVITE session module gets it.
> 2. Ensure session supplements are invoked before redirection completes.
> 
> This patch implements option #2 so that developers of other modules do not need to know about the special situation that redirects impose. Session supplements are called directly in the redirect callback before handling and are NOT called as a result of a transaction state change later.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/res_pjsip_session.c 419318 
> 
> Diff: https://reviewboard.asterisk.org/r/3850/diff/
> 
> 
> Testing
> -------
> 
> Ran diversion tests over and over, confirmed no spurious failures.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140729/1977b0bc/attachment.html>