----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3361/ -----------------------------------------------------------
(Updated March 28, 2014, 4:02 a.m.) Status ------ This change has been marked as submitted. Review request for Asterisk Developers, David Lee, Joshua Colp, and kmoore. Changes ------- Committed in revision 4904 Repository: testsuite Description ------- The change in r410528 (https://reviewboard.asterisk.org/r/3336/) introduced a subtle behaviour change that broke the rest_api/bridges/subscription test. Previously, the test did the following: * Create a Stasis application 'testsuite' * Create a Stasis application 'bridge-watching-app' * POST a channel to application 'testsuite' * POST a bridge * Subscribe application 'bridge-watching-app' to the bridge * Add the previously posted channel to the bridge ** Verify that the app 'testsuite' sees the bridge update (as its channel is in the bridge) ** Verify that the app 'bridge-watching-app' sees the bridge update (as it was subscribed) * Unsubscribe the app 'testsuite' from the bridge * Remove the channel from the bridge ** Verify that the app 'bridge-watching-app' see the bridge update ** Verify that the app 'testsuite' does NOT see the bridge update <------------ THIS IS NOW BROKEN The last verification broke because we now ensure that applications who have channels in a bridge are now subscribed implicitly to the bridge while their channel is in it. You can now no longer unsubscribe from the implicit subscription created by your channel: you may decrement the subscription count, but it won't be sufficient to nuke out the subscription that ARI has created for you. I actually think this behaviour change is a good thing: If you have a channel in an application, and it is doing "things", you should always be notified of the "things" it is doing. Even if you claim you don't want to know - otherwise, how do you know when you can DELETE the channel? Or do something else crazy to it? This test has now been updated so that the thing unsubscribed is the 'bridge-watching-app'. This still verifies subscribes/unsubscribes - but it does so where the entity subscribing for the bridge updates never had a 'stake' in the state of the bridge in the first place. Diffs ----- /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/test-config.yaml 4844 /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/subscribe_bridge.py 4844 Diff: https://reviewboard.asterisk.org/r/3361/diff/ Testing ------- Thanks, Matt Jordan
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
