Mark! > 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 What you are saying implies that up to 11 it is better to mirror the state of the pbx in a CTI application using the channel states and the extension stati (actually device status would probably be a better name) only, then using bridge events here and there. With 12 things will change and especially with multi-party calls (conferences, added announcement channels, etc..) it will be easier to access the entire state of the pbx using the new bridge infrastructure. jg
