[asterisk-dev] [Code Review] 4268: During a dual redirect, prevent a race condition that may cause one of the redirected channels to be hung up.

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4268/
-----------------------------------------------------------

(Updated Dec. 18, 2014, 9:05 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 429741


Bugs: ASTERISK-24536
    https://issues.asterisk.org/jira/browse/ASTERISK-24536


Repository: Asterisk


Description
-------

The reporter of ASTERISK-24536 had an issue where performing a dual redirect on two channels that were bridged together would result in the second channel ("extrachannel") being hung up instead of being redirected. I could not reproduce this issue, and the reporter also states that it no longer happens for him, but having a look at the code, I did see something that looked fishy and that could cause the reported issue.

There is a special channel flag called AST_FLAG_BRIDGE_DUAL_REDIRECT_WAIT that gets set in order for a bridge not to try to perform any actions on a channel until the redirection operation has completed. This helps prevent automatic bridge behaviors from occurring, such as hanging up the last channel remaining in a basic bridge. The problem with the redirect code was that it was setting this flag on the channel based on the presence of a PBX on the channel, not based on whether the channel was in a bridge. This review request changes the redirect code to set the AST_FLAG_BRIDGE_DUAL_REDIRECT_WAIT flag on channels that are bridged.


Diffs
-----

  /branches/13/main/manager.c 429611 

Diff: https://reviewboard.asterisk.org/r/4268/diff/


Testing
-------

A dual redirect of two channels in the same bridge continues to work for me in my development tests. There are formal dual redirect tests coming down the pipeline. Expect to see those on RB before the end of the year.


Thanks,

Mark Michelson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141218/023757cd/attachment-0001.html>