[asterisk-dev] [Code Review] Gently reduce masquerade insanity

David Kerr david.a.kerr at gmail.com
Mon Jan 7 15:58:36 CST 2013

  I do not have a review board userid so cannot login to comment but I
wanted to observe that masquerading takes place during SLA functions and
causes CDR records to get messed up (masquerading doesn't manage CDR
records attached to a channel very well).  If you are messing with /
contemplating eliminating masquerading, then please take a look at asterisk
bug 20747, the comments I placed in this bugid and the comments I placed in
the code of the patch I submitted for this bug.  I just wanted to make you
aware of another place that is affected by masquerade.


On Mon, Jan 7, 2013 at 3:04 PM, David Lee <reviewboard at asterisk.org> wrote:

>    This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2266/
>   Review request for Asterisk Developers.
> By David Lee.
> Description
> Masquerades are an insane implementation detail within Asterisk. It generates
> a number of useless and confusing events, and manipulates channels in a way
> that semantically doesn't make sense. I've given a fairly thorough review of
> masquerade code and its usage on the wiki athttps://wiki.asterisk.org/wiki/x/IwBRAQ.
> While ultimately it makes the most sense to abandon masquerades altogether,
> it will take some time to completely irradicate. Even then, there may always
> be code that's not worth rewriting to get rid of the masquerade.
> This patch does two things to make masquerades slightly less insane:
>  * When swapping the names of the original and clone channel, only emit a
>    single rename event of original -> original<ZOMBIE>. The original code
>    issued three rename events to accomplish the same end.
>  * In addition to swapping the names of the channels, also swap their
>    uniqueid's. This allows the 'Uniqueid' field to be used as a stable
>    identifier for a channel from and external interface, such as AMI.
>   Testing
> I've run a few SIP transfers and parking scenarios. AMI masquerade events seem
> reasonable, and the Uniqueid and Linkedid fields in CELs made more sense.
>   Diffs
>    - /trunk/UPGRADE.txt (378651)
>    - /trunk/include/asterisk/manager.h (378651)
>    - /trunk/main/channel.c (378651)
> View Diff <https://reviewboard.asterisk.org/r/2266/diff/>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130107/099c491d/attachment.htm>

More information about the asterisk-dev mailing list