[asterisk-dev] [Code Review] 2740: Hide Surrogate channels; clean up channel allocation side effects; kill Masquerade event with fire

[svnbot]

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

(Updated Aug. 8, 2013, 9:13 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers, David Lee, Joshua Colp, and Putnopvut.


Changes
-------

Committed in revision 396392


Repository: Asterisk


Description
-------

While working on cleaning up the bridge baseline test, I noticed a few troubling things:

* Surrogate channels, which exist only as a quick stand-in for a 'real' channel so that the real channel can be moved into another thread, were leaking out into the outside world. This is a "bad thing", as these channels only exist to be immediately hung up and are an implementation detail of Asterisk's internals.

* When we create a channel, we publish a *lot* of snapshots. This is due to a number of channel set routines that publish snapshots when their property changes - in general, this is a good thing (as we have specific events tied to the changing of account codes and AMA flags) and it reduces the burden on developers to "know" that if they change these properties they should publish an event. Before a channel is finished being allocated, however, is not a good thing - and the plethora of snapshots is wasteful.

* The Masquerade event somehow returned. I thought we killed it already.

This patch does the following:
(1) It provides a Surrogate channel technology with a consolidated "implementation detail flag" on the channel technology. This tells consumers of Stasis that the creation of this channel is an implementation detail in Asterisk and can be ignored (if they so choose). This consolidates the conference recorder/announcer flags as well - these flags had no additional meaning beyond "ignore this channel please".

(2) It modifies allocation of a channel in two ways:
   (a) If a channel technology can be determined from the name, we set it directly in the allocation routine. This prevents the initial publication of the message from going out with a NULL channel technology where possible. This lets Stasis consumers get the right channel technology on the first publication.
   (b) It reorganizes allocation to make use of the 'finalized' property on the channel. This was already used to know that a channel had completely finished its construction in the masquerade routine; now we also use it to know whether or not the setting of certain channel properties is occurring during or post construction. The various set routines were modified accordingly as well.

(3) The masquerade event is now dead, Jim. It no longer serves any purpose whatsoever - if you perform a call pickup you'll get a Pickup event; if you perform an attended transfer you will still get those events; if you steal a channel to put it elsewhere you'll get the corresponding NewExten or BridgeEnter events.


Diffs
-----

  trunk/apps/confbridge/conf_chan_announce.c 396109 
  trunk/apps/confbridge/conf_chan_record.c 396109 
  trunk/channels/chan_bridge_media.c 396109 
  trunk/include/asterisk/channel.h 396109 
  trunk/main/cdr.c 396109 
  trunk/main/cel.c 396109 
  trunk/main/channel.c 396109 
  trunk/main/channel_internal_api.c 396109 
  trunk/main/manager_bridges.c 396158 
  trunk/main/manager_channels.c 396109 

Diff: https://reviewboard.asterisk.org/r/2740/diff/


Testing
-------

The bridge_baseline test is now producing sane output.


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130808/a1361a6d/attachment-0001.htm>