[asterisk-app-dev] AMI: duplicate events

[Mark Michelson]

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