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

Jonathan Rose reviewboard at asterisk.org
Tue Mar 25 10:44:33 CDT 2014


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

(Updated March 25, 2014, 10:44 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers, Matt Jordan and opticron.


Changes
-------

Committed in revision 411086


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/20140325/05267187/attachment.html>


More information about the asterisk-dev mailing list