[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 reviewboard at asterisk.org
Mon Mar 24 08:19:26 CDT 2014


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

Ship it!


This change looks good. Go ahead and move the last_bridge declaration into the loop as well as you've commented above.

- opticron


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/0369a135/attachment.html>


More information about the asterisk-dev mailing list