Hi Mark, These new bridge events in Asterisk 12 are also all logged on CEL? Tks Em 16/10/2013 18:54, "Mark Michelson" <mmichelson at digium.com> escreveu: > 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 > > ______________________________**_________________ > asterisk-app-dev mailing list > asterisk-app-dev at lists.digium.**com <asterisk-app-dev at lists.digium.com> > http://lists.digium.com/cgi-**bin/mailman/listinfo/asterisk-**app-dev<http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131017/7accb3c8/attachment.html>