[asterisk-bugs] [JIRA] (ASTERISK-22844) testsuite: Sporadic failure of bridge_transfer_callee test on Asterisk 12+

[Matt Jordan (JIRA)]

Matt Jordan created ASTERISK-22844:
--------------------------------------

             Summary: testsuite: Sporadic failure of bridge_transfer_callee test on Asterisk 12+
                 Key: ASTERISK-22844
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22844
             Project: Asterisk
          Issue Type: Bug
          Components: Core/Bridging, Tests/testsuite
    Affects Versions: 12.0.0-beta1
            Reporter: Matt Jordan


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 at 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 at test_context:1] Answer("Local/local at call2-00000007;1", "") in new stack
[Nov 12 06:22:09] VERBOSE[17905][C-0000000f] pbx.c:     -- Executing [bridge3 at test_context:2] Bridge("Local/local at call2-00000007;1", "Local/local at 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 at call1-00000006;1'
[Nov 12 06:22:09] VERBOSE[17907][C-0000000f] bridge_channel.c:     -- Channel Local/local at 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 at 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 at call1-00000006;1
[Nov 12 06:22:09] VERBOSE[17907][C-0000000f] bridge_channel.c:     -- Channel Local/local at 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 at 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 at call1-00000006;2'
[Nov 12 06:22:09] VERBOSE[17905][C-0000000f] pbx.c:     -- Executing [bridge3 at test_context:3] UserEvent("Local/local at call2-00000007;1", "Alpha,Test: 3,Status: FAILURE,Channel: Local/local at call2-00000007;1") in new stack
[Nov 12 06:22:09] VERBOSE[17905][C-0000000f] pbx.c:     -- Executing [bridge3 at test_context:4] Hangup("Local/local at 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira