<div dir="ltr"><span id="goog_1353916780"></span><a href="/"></a><span id="goog_1353916781"></span><div><div>Hello everyone,<br></div>I'd like to get some feedback from the community regarding the current operation of bridge creation and bridge subscriptions.<br>
<br></div><div>Recently, a fix for a bridge subscription leak was committed which caused two tests to fail. These tests were expecting to have a persistent subscription to the bridge for its entire lifetime which isn't entirely unreasonable but is not the way that the API is currently designed.<br>
<br></div><div>Currently, the API is designed such that a user of the API must first create a bridge and then subscribe to it if it wants additional information as events via websocket during the lifetime of the bridge. The review[1] to fix these two failings tests assumes this is the correct way to do things and modifies subscriptions during the lifetime of the bridge accordingly. One downside of this is that between creation and subscription, some other entity could alter the state of the bridge without its creator or subscriber(s) knowing.<br>
<br></div><div>An alternative fix for these broken tests would be to add a parameter to the POST that creates the bridge to allow automatic creation of subscriptions for one or more Stasis applications. This solution would prevent modification of the bridge's state without the creator or other designated application knowing about it.<br>
<br></div><div>Are there other solutions worth considering?<br><br></div><div>[1] <a href="https://reviewboard.asterisk.org/r/3398/">https://reviewboard.asterisk.org/r/3398/</a><br><br><div>Kinsey Moore<br></div>Digium, Inc. | Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com">http://digium.com</a> & <a href="http://asterisk.org">http://asterisk.org</a><br>
</div></div>