[Home]

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-0600Date Closed:2013-12-11 09:07:14.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents: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.