On 10/16/2013 04:29 PM, jg wrote: > Whenever 2 channels form a bridge, I see a duplicate pair of "Bridge" > events (Asterisk 11.5.1), like > > Event: Bridge > Privilege: call,all > Bridgestate: Link > Bridgetype: core > Channel1: SIP/Sn370-0000002a > Channel2: Local/voicemailmain at from-internal-00000008;1 > Uniqueid1: 1381958063.58 > Uniqueid2: 1381958063.59 > CallerID1: *7001 > CallerID2: asterisk > > Event: Bridge > Privilege: call,all > Bridgestate: Unlink > Bridgetype: core > Channel1: SIP/Sn370-0000002a > Channel2: Local/voicemailmain at from-internal-00000008;1 > Uniqueid1: 1381958063.58 > Uniqueid2: 1381958063.59 > CallerID1: *7001 > CallerID2: asterisk > > Event: Bridge > Privilege: call,all > Bridgestate: Link > Bridgetype: core > Channel1: SIP/Sn370-0000002a > Channel2: Local/voicemailmain at from-internal-00000008;1 > Uniqueid1: 1381958063.58 > Uniqueid2: 1381958063.59 > CallerID1: *7001 > CallerID2: asterisk > > ... > > Event: SoftHangupRequest > Privilege: call,all > Channel: Local/voicemailmain at from-internal-00000008;2 > Uniqueid: 1381958063.60 > Cause: 16 > > Event: Hangup > Privilege: call,all > Channel: Local/voicemailmain at from-internal-00000008;2 > Uniqueid: 1381958063.60 > CallerIDNum: *7001 > CallerIDName: Snom 370 ??? > ConnectedLineNum: asterisk > ConnectedLineName: <unknown> > AccountCode: > Cause: 0 > Cause-txt: Unknown > > Event: Bridge > Privilege: call,all > Bridgestate: Unlink > Bridgetype: core > Channel1: SIP/Sn370-0000002a > Channel2: Local/voicemailmain at from-internal-00000008;1 > Uniqueid1: 1381958063.58 > Uniqueid2: 1381958063.59 > CallerID1: *7001 > CallerID2: asterisk > > The "Bridge" events are symmetric with respect to "Link" and "Unlink", > but initially there is a quick "Link" and "Unlink" that does not seem > to serve any purpose. > > Is this an artifact of the manager interface? > > jg In all versions prior to Asterisk 12, the Bridge event is...less than useful. What you're seeing here isn't really an artifact of the manager interface so much as that Asterisk is exposing too much of its internals. In the case of the bridging, there is a 3-deep series of for loops that control a bridge. The outer-most one is what is responsible for executing DTMF and timed features on channels in a bridge. The second-tier one is the one that emits these Link and Unlink events. So what happens is that any time the second-tier loop is broken and the outermost one takes control, you'll see a Bridge Unlink event. This second-tier loop can be broken by such things as receiving specific control frame types, receiving DTMF, and certain timeouts. I can't tell what's happening in your particular case, partially because the Bridgetype field on those Bridge events will always say "core" even if the bridge type should be something else. All of this is to say that aside from the initial Bridge Link event, using Bridge events to try to figure out whether channels are actually bridged is not advised. In Asterisk 12, however, a different bridging framework is used, so instead of seeing two-party Bridge events, you now have bridge-centric events that give you an accurate picture of the bridge. You have events like BridgeCreate, when a bridge is created; BridgeEnter, when a channel enters a bridge; BridgeLeave, when a channel exits a bridge; and BridgeDestroy, when a Bridge is destroyed. With this, you get a much more accurate and clear picture of the state of the system and are also not restricted to seeing Bridge events only on two-party calls. Mark Michelson
