> On Nov. 13, 2014, 4:30 p.m., Mark Michelson wrote: > > With the fix being made to the leaked bridge in Asterisk, is this change > > still required? Does hanging up self.channels[1] not result in > > self.channels[3] and the bridge being destroyed as expected? > > Corey Farrell wrote: > Still required, I'm guessing that when the first channel hangs up it > leaves the second in a single user bridge. I'm not sure if this is a bug in > Asterisk or just the way it works. The XMLDOC doesn't specify. > > Corey Farrell wrote: > Actually on further inspection it appears the bridge is destroyed, and > the caller is sent back to the previous Dialplan location. core show > channels without hangup of self.channels[3]: > Channel Location State Application(Data) > > Local/waiting_area@d (None) Up Echo() > > Local/waiting_area@d (None) Up Echo() > > 2 active channels > 2 active calls > 14 calls processed > > If I then run 'channel request hangup > Local/waiting_area@default-00000003;1' (or hangup ;2), the test finishes and > passes leak free. > > This is strange to me, why all the other channel pairs were hung up but > not this one.
There are a few of unique properties to the final bridge that, imo, shouldn't affect operations but in practice might: 1) The final bridge between 1 and 3 is the only one where the remaining channel in the bridge came from another bridge rather than directly from the dialplan. In fact, the remaining channel had been in two previous bridges, so its movement through the bridges may have something to do with it. 2) The final bridge between 1 and 3 is the only one where a channel is hung up. In the other cases, a channel is stolen from the bridge, resulting in bridge dissolution. After looking at the code again in action_bridge in features.c, the channels that are bridged together have ast_bridge_set_after_go_on() set on them. Looking at the docs for ast_bridge_set_after_go_on(), it says "If parseable_goto, then use the given context/exten/priority as the relative position for the parseable goto. Else goto the given context/exten/priorit+1". We don't provide a parseable goto, so after becoming unbridged, the channels should move to the next priority in the dialplan after the one they're currently in. Since the channels being bridged are currently at the Echo() priority, they should be returned to the dialplan at the next priority, which is Hangup(). This happens with all but channel 3. Somehow, I'm guessing that some code path is causing the priority number to goto after the bridge to get screwed up, so it ends up back in Echo() instead of moving on to Hangup(). I think this is a problem in Asterisk, not the test. - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4166/#review13745 ----------------------------------------------------------- On Nov. 11, 2014, 8:37 p.m., Corey Farrell wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4166/ > ----------------------------------------------------------- > > (Updated Nov. 11, 2014, 8:37 p.m.) > > > Review request for Asterisk Developers. > > > Repository: testsuite > > > Description > ------- > > self.channels[3] is not hung up, causing the Asterisk graceful shutdown to > timeout. This causes the test to fail under REF_DEBUG mode and prevents > coverage from seeing the code executed by this test. > > > Diffs > ----- > > /asterisk/trunk/tests/bridge/bridge_action/bridge_action.py 5920 > > Diff: https://reviewboard.asterisk.org/r/4166/diff/ > > > Testing > ------- > > > Thanks, > > Corey Farrell > >
-- _____________________________________________________________________ -- 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
