<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/3361/">https://reviewboard.asterisk.org/r/3361/</a>
</td>
</tr>
</table>
<br />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">"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?"
----------------------------------------------------
So one thing I think we need to look into is protecting these
types of subscriptions from being destroyed by ARI unsubscribe
commands. It seems to me like delete subscription should only
work on subscriptions that were explicitly created by ARI. Of
course, internally right now it's just stored as a sort of
reference count of 'interested' members, but we could fairly
easily turn that into two distinct types of interested parties
so that you could 'delete' the subscriptions you made without
being able to take out any arbitrary subscription.</pre>
<br />
<p>- Jonathan Rose</p>
<br />
<p>On March 14th, 2014, 4:23 p.m. CDT, Matt Jordan wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers, David Lee, Joshua Colp, and kmoore.</div>
<div>By Matt Jordan.</div>
<p style="color: grey;"><i>Updated March 14, 2014, 4:23 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
testsuite
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.
</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/asterisk/trunk/tests/rest_api/applications/subscribe-bridge/test-config.yaml <span style="color: grey">(4844)</span></li>
<li>/asterisk/trunk/tests/rest_api/applications/subscribe-bridge/subscribe_bridge.py <span style="color: grey">(4844)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/3361/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>