[asterisk-dev] [Code Review] Gently reduce masquerade insanity
David Kerr
david.a.kerr at gmail.com
Mon Jan 7 15:58:36 CST 2013
David,
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.
Thanks
David
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