[asterisk-dev] [Code Review] 2687: CEL Specification for Asterisk 12

Tue Aug 6 15:12:51 CDT 2013

> On Aug. 5, 2013, 9:27 a.m., Matt Jordan wrote:
> > (1) AST_CEL_BRIDGE_TO_CONF is raised when a 2-party bridge transitions to a multi-party bridge. Is there an event for when a multi-party bridge transitions to a 2-party bridge?
> > 
> > (2) In CEL Overview, I'd be a bit more clear that, for each channel in Asterisk, CEL tracks the changes that occur to a channel. For a sequence of CEL events, there is always a Primary channel, and that events for a primary channel have an ordering. Unless otherwise specified, there is no explicit ordering between events on two primary channels.
> > 
> > Basically, for some channel that is the primary on a sequence of events, you're guaranteed that a CHAN_START happens before a CHAN_END; a CONF_START happens before a CONF_END; that a CHAN_END is the last event; etc. However, for two channels, you aren't guaranteed that channel 1's CONF_START will happen before or after channel 2's CONF_START.
> > 
> > (3) In your event descriptions, provide the guaranteed orderings. For example, when a linkedid is retired, can I expect AST_CEL_LINKEDID_END to occur after that channel's AST_CEL_CHAN_END?
> > 
> > (4) I think you need a better explanation of the bridge transitions in Interaction Records. If you go from a two-party to a multi-party, you *may* still get a AST_CEL_BRIDGE_END if the multi-party transitions back to a two-party and the Primary leaves the bridge when it is a two-party again. This is why I think we might want an analogous event for AST_CEL_BRIDGE_TO_CONF - if I'm watching the events for a channel, it'd be nice to know what event I can expect to get when the Primary leaves the bridge.
> > 
> > (5) This is weird:
> > 
> > {quote}
> > An AST_CEL_CONF_ENTER record is generated when a channel enters a multi-participant conference. The entering channel is the Primary for this event. An AST_CEL_CONF_ENTER record is not generated if the bridge is a two-participant bridge and the channel is the first, second, or third party to enter the bridge. See below for an example.
> > {quote}
> > 
> > If the bridge is going from 2-party to 3-party, I'd expect the third person to not raise a 2-party bridge event. I understand that this reflects the Stasis messages and the order in which they come, but it's funky behavior from the perspective of someone trying to use CEL.
> > 
> > (6) How true is the 2-party/multi-party messages if you start with ConfBridge? Does a ConfBridge bridge start by raising 2-party messages and switch to multi-party messages as participants enter, or does it always raise multi-party messages?
> > 
> > (7) I'm not sure I understand this:
> > 
> > {quote}
> > App-App Attended Transfers
> > Attended transfers involving only channels that are running applications are not currently possible.
> > {quote}
> > 
> > When would you ever do an attended transfer when none of the channels are in a bridge?
> > 
> > (8) You need to document the standard fields in a CEL event message.
> > 
> > (9) Structure your examples differently. I would use a two column approach:
> > 
> > * Channel takes some action       | * AST_CEL_EVENT_FOO
> > * Channel takes some other action | * AST_CEL_EVENT_BAR
> > 
> > (10) "Two-Participant Bridge Inverted Exit"  What is an "inverted exit"? That isn't a standard term that everyone would be familiar with.
> > 
> > (11) Multi-participant Conference Nominal
> > 
> > Here we have channels entering a bridge, and yet we never get any 2-party bridge events. That seems odd, based on your previous description of the events.
> > 
> > If a "conference", that is, a multi-party bridge created by ConfBridge, does not ever raise 2-party bridge events, that needs to be documented. You should also document that MeetMe is no longer covered by CEL.
> > 
> >

(1) Even though the bridging system can transition back to a 2-party bridge, CEL continues to track bridges that have made the transition to a conference as a conference until they are destroyed because there is information conveyed in the bridge start and bridge end messages that can not be discerned from multiparty conferences. This is noted in the "Bridge to Conference" section with "All further changes in this bridge will be conveyed via AST_CEL_CONF_ENTER and AST_CEL_CONF_EXIT.", but I'll make it more clear.

(2) Addressed.
(3) Addressed.
(4) See (1).
(5) If the third channel to join the 2-party bridge does not generate the BRIDGE_TO_CONF record, there is not currently a mechanism to allow a CEL user to track the transition as the bridge ID is not provided in the bridge start and bridge end records. An alternative would be to make the BRIDGE_TO_CONF record a strictly 2-party record with no mention of the third channel and then generate a CONF_ENTER record for the third channel.

(6) ConfBridge currently uses a multimix-only non-smart bridge, so all records generated by ConfBridge activities will be conference records (no 2-party records).

(7) It is possible for an external attended transfer to attempt to bridge the far sides of two channels which are not bridged. It is not currently possible for this to succeed.

(8) Addressed.
(9) In progress.
(10) Addressed.
(11) Bridges that can never be 2-party bridges do not generate 2-party records. Added mention of MeetMe not being covered.

- opticron

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2687/#review9322
-----------------------------------------------------------

On July 19, 2013, 4:12 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2687/
> -----------------------------------------------------------
> 
> (Updated July 19, 2013, 4:12 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21567
>     https://issues.asterisk.org/jira/browse/ASTERISK-21567
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Like the CDR engine, the CEL engine has gone through quite a bit of rework due to the bridging changes in Asterisk 12 and its refactoring on top of the Stasis message bus.
> 
> Due to the Stasis refactoring, the CEL engine is now significantly more self-contained in Asterisk 12 than it was in Asterisk 11. All events except for user defined events (even these are delivered via Stasis) are now generated from the same Stasis messages that many other parts of Asterisk consume to monitor the state of channels, bridge, ongoing dial attempts, and other events.
> 
> Due to changes in the bridging system, AST_CEL_BRIDGE_UPDATE (masquerade related) has been removed and equivalent events are now indicated with conference change records, bridge change records, bridge to conference transition records, and local channel optimization records.
> 
> See the wiki article on this subject for more details:
> https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CEL+Specification
> 
> 
> Diffs
> -----
> 
> 
> Diff: https://reviewboard.asterisk.org/r/2687/diff/
> 
> 
> Testing
> -------
> 
> The reworked CEL engine has many new unit tests located under /main/cel on the CLI.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130806/05eac480/attachment.htm>