[asterisk-dev] [Code Review] 3380: ARI: When a channel controlled by stasis is removed from a bridge, automatically created subscriptions to the bridge aren't removed.

[opticron]

> On March 21, 2014, 2:05 p.m., Jonathan Rose wrote:
> > /branches/12/res/res_stasis.c, line 739
> > <https://reviewboard.asterisk.org/r/3380/diff/1/?file=56309#file56309line739>
> >
> >     It might also be appropriate to move this declaration into the loop... but ultimately kind of pointless since it gets reassigned right after the hangup check anyway.

Go ahead and move this into the loop since it doesn't need to persist beyond the loop or across iterations.


- opticron


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


On March 21, 2014, 2:03 p.m., Jonathan Rose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3380/
> -----------------------------------------------------------
> 
> (Updated March 21, 2014, 2:03 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and opticron.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> I was examining a testsuite failure (which should be resolved by https://reviewboard.asterisk.org/r/3361/) and stumbled across the following behavior:
> 
> A channel enters a stasis application
> ARI pushes that channel into a bridge - the bridge is automatically subscribed to the stasis application
> ARI pulls the channel from the bridge - the bridge is still subscribed to the stasis application.
> 
> Looking into why this was, I became aware that the patch which introduced the aforementioned test failure (which turned out to be just because the test was trying to unsubscribe for something that it probably shouldn't have been trying to unsubscribe) had introduced a two subscription scheme when the stasis channels are added to bridges and that only one of these stasis channels was being cleared.  It turned out to be a rather simple problem where the previously used bridge can't be tracked properly because we are resetting it to NULL all the time. The fix was quite simple and I just had to move the initialization of the bridge used to track through repeat iterations out of the loop.
> 
> Today's lesson: Hooray for accidentally looking into test failures that have already been solved!
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/res_stasis.c 411008 
> 
> Diff: https://reviewboard.asterisk.org/r/3380/diff/
> 
> 
> Testing
> -------
> 
> Pretty much just used the scenario described above twice.  The test still fails with this patch in place simply because the second subscription is still active as the channel exits the bridge and deleting automatically created subscriptions manually is probably just a bad idea in general.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140324/23f2c40d/attachment.html>