[asterisk-bugs] [Asterisk 0002342]: Native bridging does Link/Unlink/Link

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=2342 
====================================================================== 
Reported By:                softins
Assigned To:                markster
====================================================================== 
Project:                    Asterisk
Issue ID:                   2342
Category:                   Resources/res_features
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           I did not set the version :( 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2004-09-01 03:18 CDT
Last Modified:              2010-09-14 13:04 CDT
====================================================================== 
Summary:                    Native bridging does Link/Unlink/Link
Description: 
When native bridging between two channels, console output shows two
attempts:

    -- SIP/2000-9614 is ringing
    -- SIP/2000-9614 answered SIP/2001-b010
    -- Attempting native bridge of SIP/2001-b010 and SIP/2000-9614
    -- Attempting native bridge of SIP/2001-b010 and SIP/2000-9614

and the Manager API shows successive Link/Unlink/Link events:

Event: Link
Channel1: SIP/2001-b010
Channel2: SIP/2000-9614
Uniqueid1: 1094025702.4
Uniqueid2: 1094025702.5

Event: Unlink
Channel1: SIP/2001-b010
Channel2: SIP/2000-9614
Uniqueid1: 1094025702.4
Uniqueid2: 1094025702.5

Event: Link
Channel1: SIP/2001-b010
Channel2: SIP/2000-9614
Uniqueid1: 1094025702.4
Uniqueid2: 1094025702.5

According to debug output, the cause appears to be that the first time
ast_channel_bridge() is called, it does the Link, but then breaks out of
the for(;;) loop with a "FRAME CONTROL (4) frame" (AST_CONTROL_ANSWER), and
so performs an immediate Unlink.

ast_channel_bridge() was called from ast_bridge_call() in res_features.c,
which goes back round the loop and calls ast_channel_bridge() again. This
time the bridging is maintained.

In the past it didn't behave like this, but I don't know how long ago it
changed.

I haven't atttached a patch, because I don't know what the correct fix is.
:-)
====================================================================== 

---------------------------------------------------------------------- 
 (0126934) svnbot (reporter) - 2010-09-14 13:04
 https://issues.asterisk.org/view.php?id=2342#c126934 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 286682

_U  branches/1.8/
U   branches/1.8/main/channel.c

------------------------------------------------------------------------
r286682 | mnicholson | 2010-09-14 13:04:22 -0500 (Tue, 14 Sep 2010) | 21
lines

Merged revisions 286681 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
  r286681 | mnicholson | 2010-09-14 13:02:24 -0500 (Tue, 14 Sep 2010) | 14
lines
  
  Merged revisions 286679 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r286679 | mnicholson | 2010-09-14 13:00:01 -0500 (Tue, 14 Sep 2010) |
7 lines
    
    Only drop duplicate answer frames if the channel is bridged.
    
    Back in r3710 ast_read() was modified to drop answer frames on
channels that were in the UP state.  This modification prevented bridges
that were up before the answer from being broken and reestablished by an
ANSWER control frame.  That change also prevents pickup of channels called
from the ast_dial framework from working properly.  The ast_dial framework
expects to see an ANSWER frame after dialing and the pickup code queues one
but ast_read() drops it.  This new change only drops ANSWER frames when the
channel is bridged, allowing the answer queued by the pickup code to
properly pass through ast_read() on to the ast_dial framework.
    
    ABE-2473
    (related to issue https://issues.asterisk.org/view.php?id=2342)
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=286682 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-14 13:04 svnbot         Checkin                                      
2010-09-14 13:04 svnbot         Note Added: 0126934                          
======================================================================