AMI: duplicate events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>


[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux