[Home]

Summary:ASTERISK-02311: Native bridging does Link/Unlink/Link
Reporter:Tony Mountifield (softins)Labels:
Date Opened:2004-09-01 03:18:54Date Closed:2010-09-14 13:05:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full.txt
( 1) full-with-sip-debug.txt
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. :-)
Comments:By: Brian West (bkw918) 2004-09-01 11:16:48

You will always drop out of the native bridge on anything thats NON voice.  that includes DTMF.  Thats how I see it..
By: Tony Mountifield (softins) 2004-09-01 11:45:40

But the behaviour I'm describing always happens immediately, and always is due to an ANSWER control frame. Nothing to do with DTMF.

I suspect the ANSWER frame outght to be handled before calling ast_channel_bridge() the first time.
By: Brian West (bkw918) 2004-09-01 12:30:36

maybe so.. but since its a nonvoice frame its going to fall out of the native bridge and then bridge back.
By: zoa (zoa) 2004-09-01 14:09:01

AFAIK this is only happening when reinvite=no.
By: Brian West (bkw918) 2004-09-01 14:31:32

ya you're correct :P
By: Tony Mountifield (softins) 2004-09-01 15:50:15

That's because canreinvite=no forces * to do native bridging!

I fully understand the non-voice frame is going to make it drop out of the bridge - that was part of my original bug report. My point is that I believe the frame should have been dealt with before doing the bridge, so that it doesn't make the bridge drop out as soon as it is entered.

Any comment from Mark?
By: Mark Spencer (markster) 2004-09-01 16:33:04

Does this mean there are two ANSWER frames being received?
By: Tony Mountifield (softins) 2004-09-01 16:45:23

I don't know, but there is certainly one in the queue when ast_channel_bridge() is being called, because that is the reason the debug message gives for breaking out of the loop.

I've attached the relevant part of the "full" log, full.txt.
By: Mark Spencer (markster) 2004-09-01 23:56:29

Can you please include "sip debug" with the "full log"? thanks.
By: Tony Mountifield (softins) 2004-09-02 03:31:36

Full log with sip debug uploaded, covering a single call. The link/unlink/link happens around line 345.
By: zoa (zoa) 2004-09-02 04:52:23

if that double line gets removed, is it possible to show on the CLI that a reinvite was used and no RTP is passing through * ?
By: Tony Mountifield (softins) 2004-09-02 05:02:26

Not sure what you're getting at. All the phones in question have canreinvite=no, and that is the situation for which the fix is needed. Well, "needed" is too strong: it doesn't appear to cause a problem in practice, but is just slightly odd behaviour.
By: Mark Spencer (markster) 2004-09-02 09:45:05

Fixed in CVS, reopen if not.
By: Digium Subversion (svnbot) 2008-01-15 15:06:33.000-0600

Repository: asterisk
Revision: 3710

U   trunk/channel.c
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r3710 | markster | 2008-01-15 15:06:32 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix "duplicate answer" issue (bug ASTERISK-2311)

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

http://svn.digium.com/view/asterisk?view=rev&revision=3710
By: Digium Subversion (svnbot) 2010-09-14 13:00:02

Repository: asterisk
Revision: 286679

U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r286679 | mnicholson | 2010-09-14 13:00:02 -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 ASTERISK-2311)

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

http://svn.digium.com/view/asterisk?view=rev&revision=286679
By: Digium Subversion (svnbot) 2010-09-14 13:02:25

Repository: asterisk
Revision: 286681

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

------------------------------------------------------------------------
r286681 | mnicholson | 2010-09-14 13:02:25 -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 ASTERISK-2311)
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=286681
By: Digium Subversion (svnbot) 2010-09-14 13:04:22

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 ASTERISK-2311)
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=286682
By: Digium Subversion (svnbot) 2010-09-14 13:05:40

Repository: asterisk
Revision: 286683

_U  trunk/
U   trunk/main/channel.c

------------------------------------------------------------------------
r286683 | mnicholson | 2010-09-14 13:05:40 -0500 (Tue, 14 Sep 2010) | 28 lines

Merged revisions 286682 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r286682 | mnicholson | 2010-09-14 13:04:21 -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 ASTERISK-2311)
   ........
 ................
................

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

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