Summary: | ASTERISK-22843: testsuite: Sporadic failure of bridge_transfer_callee test on Asterisk 12+ | ||
Reporter: | Matt Jordan (mjordan) | Labels: | |
Date Opened: | 2013-11-12 10:31:39.000-0600 | Date Closed: | 2013-12-11 09:07:14.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Core/Bridging Tests/testsuite |
Versions: | 12.0.0-beta1 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Attachments: | ( 0) ASTERISK-22843.tar.gz | |
Description: | The {{tests/apps/bridge/bridge_transfer_callee}} test sporadically fails when run against Asterisk 12:
https://bamboo.asterisk.org/bamboo/browse/AST-ATSF-C632TE-74/test/case/1410857 The {{F}} option is documented as follows: {noformat} F - When the bridger hangs up, transfer the bridged party to the specified destination and start execution at that location. context exten priority {noformat} In the failed test run, the Bridger - Local/local@call2-00000007;1 - is not hung up. Instead, the bridged party is hung up, and as such, the F option logic is not applied. {noformat} [Nov 12 06:22:09] VERBOSE[17905][C-0000000f] pbx.c: -- Executing [bridge3@test_context:1] Answer("Local/local@call2-00000007;1", "") in new stack [Nov 12 06:22:09] VERBOSE[17905][C-0000000f] pbx.c: -- Executing [bridge3@test_context:2] Bridge("Local/local@call2-00000007;1", "Local/local@call1-00000006;1, F(bridgecontext,bridge3transfer,3)") in new stack [Nov 12 06:22:09] VERBOSE[17903][C-0000000d] pbx.c: == Spawn extension (test_context, call, 4) exited non-zero on 'Surrogate/Local/local@call1-00000006;1' [Nov 12 06:22:09] VERBOSE[17907][C-0000000f] bridge_channel.c: -- Channel Local/local@call1-00000006;1 joined 'simple_bridge' basic-bridge <65296a70-f085-4aea-82cd-bd838f87f5ea> [Nov 12 06:22:09] VERBOSE[17905][C-0000000f] bridge_channel.c: -- Channel Local/local@call2-00000007;1 joined 'simple_bridge' basic-bridge <65296a70-f085-4aea-82cd-bd838f87f5ea> [Nov 12 06:22:09] VERBOSE[17887] manager.c: -- Manager 'user' from 127.0.0.1, hanging up channel: Local/local@call1-00000006;1 [Nov 12 06:22:09] VERBOSE[17907][C-0000000f] bridge_channel.c: -- Channel Local/local@call1-00000006;1 left 'simple_bridge' basic-bridge <65296a70-f085-4aea-82cd-bd838f87f5ea> [Nov 12 06:22:09] VERBOSE[17905][C-0000000f] bridge_channel.c: -- Channel Local/local@call2-00000007;1 left 'simple_bridge' basic-bridge <65296a70-f085-4aea-82cd-bd838f87f5ea> [Nov 12 06:22:09] VERBOSE[17904][C-0000000c] pbx.c: == Spawn extension (call1, local, 1) exited non-zero on 'Local/local@call1-00000006;2' [Nov 12 06:22:09] VERBOSE[17905][C-0000000f] pbx.c: -- Executing [bridge3@test_context:3] UserEvent("Local/local@call2-00000007;1", "Alpha,Test: 3,Status: FAILURE,Channel: Local/local@call2-00000007;1") in new stack [Nov 12 06:22:09] VERBOSE[17905][C-0000000f] pbx.c: -- Executing [bridge3@test_context:4] Hangup("Local/local@call2-00000007;1", "") in new stack {noformat} This is due to the test assuming that the first channel in the bridge is the bridger. That is not guaranteed in Asterisk 12+ - the first channel in the bridge is essentially a race between the two channels. Ordering is not defined. {noformat} def bridge_enter_event(self, ami, event): if self.channel1 is None: self.channel1 = event['channel'] LOGGER.info("Got first channel %s in bridge %s" % (self.channel1, event['bridgeuniqueid'])) return LOGGER.info("Got second channel %s in bridge %s, hanging up %s" % (event['channel'], event['bridgeuniqueid'], self.channel1)) ami.hangup(self.channel1) self.channel1 = None {noformat} The test needs to be updated so that it knows who is the Bridger and who is the Bridgee, and always hangs up the Bridger. | ||
Comments: | By: Kinsey Moore (kmoore) 2013-12-11 09:07:14.237-0600 Fix committed. |