[Home]

Summary:ASTERISK-20512: Manager sends a bridge/link message following a hold
Reporter:Sidney Gluckman (sidgluckman)Labels:
Date Opened:2012-10-04 10:36:43Date Closed:2017-12-19 05:26:33.000-0600
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Core/Channels
Versions:1.8.11.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Asterisk Now 2.02/CentOS Release 5.8 (Final)Attachments:( 0) hold_log.0
Description:Using a Polycom SoundPointIP 321, when I place a call on hold I get a "Hold:On" manager event followed by an "Unlink" event and a "Bridge:Link" event.  I have been using version 1.6.2.21 previously with no "Unlink" or "Bridge:Link" events.  I can understand why an "Unlink" event might get sent but a "Bridge:Link" event seems incorrect.
Comments:By: Sidney Gluckman (sidgluckman) 2012-10-04 10:38:40.011-0500

The Invite for the hold occurs at line 5168 of the file.
By: Matt Jordan (mjordan) 2012-10-04 11:01:11.817-0500

Bridge Link/Unlink events are sent as part of the bridge loop at the channel level that occurs within the standard two party bridge.  When a feature has to be operated on the channel - such as parking, or attended transfer, or - in your case apparently, restricting the media stream - the two party bridge between the channels is broken.  Control then transfers to a higher layer, typically in features.c.  During that period of time, the two channels are technically not bridged, as frames are not being passed back and forth between the two.  That doesn't mean that the bridge is torn down; just that no media is transferred.

When the channels are able to pass media again, you should receive a new Link event.

I agree this is a little non-intuitive, but changing this behavior in a release branch would not be acceptable.  As such, having a 'bridge begin' or a 'bridge end' event would make a bit more sense as an improvement to AMI, and should be handled as such.
By: Sidney Gluckman (sidgluckman) 2012-10-04 11:07:27.277-0500

Right, I agree that the bridge between channels is broken so then shouldn't I get a bridge unlink event instead of a bridge link event when the hold occurs?
By: Matt Jordan (mjordan) 2012-10-04 11:18:38.906-0500

Reopening.  This does seem weird.

{code}
[Oct  4 15:16:14] DEBUG[28698] manager.c: Examining event:
Event: Unlink
Privilege: call,all
Channel1: SIP/5924-00000002
Channel2: SIP/5944-00000003
Uniqueid1: 1349385372.2
Uniqueid2: 1349385372.3
CallerID1: 5924
CallerID2: 5944


[Oct  4 15:16:14] DEBUG[28698] manager.c: Examining event:
Event: Bridge
Privilege: call,all
Bridgestate: Link
Bridgetype: core
Channel1: SIP/5924-00000002
Channel2: SIP/5944-00000003
Uniqueid1: 1349385372.2
Uniqueid2: 1349385372.3
CallerID1: 5924
CallerID2: 5944
{code}

By: Joshua C. Colp (jcolp) 2017-12-19 05:26:34.011-0600

I'm suspending this issue as bridging has been completely rewritten and this issue is no longer applicable.