Copy paste from <a href="http://freeswitch.org">freeswitch.org</a><br><br><p>Asterisk uses a modular design where a central core loads shared
objects to extend the functionality with bits of code known as
"modules". Modules are used to implement specific protocols such as
SIP, add applications such as custom IVRs and tie in other external
interfaces such as the Manager Interface. The core of Asterisk is a
threading model but a very conservative one. Only origination channels
and channels executing an application have threads. The B leg of any
call operate only within the same thread as the A leg and when
something happens like a call transfer the channel must first be
transferred to a threaded mode which often times includes a practice
called channel masquerade, a process where all the internals of a
channel are torn from one dynamic memory object and placed into
another. A practice that was once described in the code comments as
being "nasty". The same went for the opposite operation the thread was
discarded by cloning the channel and letting the original hang-up which
also required hacking the cdr structure to avoid seeing it as a new
call. One will often see 3 or 4 channels up for a single call during a
call transfer because of this.</p>
<p>/* XXX This is a seriously wacked out operation. We're essentially putting the guts of<br>
the clone channel into the original channel. Start by killing off the original<br>
channel's backend. I'm not sure we're going to keep this function, because<br>
while the features are nice, the cost is very high in terms of pure nastiness. XXX */</p>
<p>
This became the de facto way to pull a channel out of the grips of
another thread and the source of many headaches for application
developers. This uncertain threading scheme was one of the motivating
factors for a rewrite.</p>
<p>Asterisk uses linked-lists to manage its open channels. A
linked-list is a series of dynamic memory chained together by using a
structure that has a pointer to its own type as one of the members
allowing you to endlessly chain objects and keep track of them.<br>
They are indeed a useful programming practice but when used in a
threaded application become very difficult to manage. One must use
mutexes, a kind of traffic light for threads to make sure only 1 thread
ever has write access to the list or you risk one thread tearing a link
out of a list while another is traversing it. This also leads to
horrible situations where one thread may be destroying or masquerading
a channel while another is accessing it which will result in a
Segmentation Fault which is a fatal error in the program and causes it
to instantly halt which, of course means in most cases all your calls
will be lost. We've all seen the infamous "Avoiding initial deadlock"
message which essentially is an attempt to lock a channel 10 times and
if still won't lock, just go ahead and forget about the lock.</p><br><br><div class="gmail_quote">2009/1/24 Udo Schacht-Wiegand <span dir="ltr"><<a href="mailto:asterisk@wiegand.name">asterisk@wiegand.name</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On a production system, running 1.4.17 (compiled from bristuff-0.4.0-test6-xr1) we had this strange issue two times in the last<br>
weeks:<br>
<br>
[2009-01-13 13:58:30] WARNING[1213] channel.c: Fixup failed on channel SIP/2332-081d0108<MASQ>, strange things may happen.<br>
[2009-01-13 13:58:30] WARNING[1213] channel.c: Hangup failed! Strange things may happen!<br>
[2009-01-13 13:58:30] WARNING[1213] channel.c: Failed to perform masquerade<br>
[2009-01-13 13:58:30] WARNING[1213] channel.c: Channel 'SIP/2332-081d0108' may not have been hung up properly<br>
<br>
and:<br>
<br>
[2009-01-23 14:27:17] WARNING[21528] channel.c: Fixup failed on channel SIP/2332-083c3778<MASQ>, strange things may happen.<br>
[2009-01-23 14:27:17] WARNING[21528] channel.c: Hangup failed! Strange things may happen!<br>
[2009-01-23 14:27:17] WARNING[21528] channel.c: Failed to perform masquerade<br>
[2009-01-23 14:27:17] WARNING[21528] channel.c: Channel 'SIP/2332-083c3778' may not have been hung up properly<br>
<br>
Both times all SIP channels got stuck and the CLI became inresponsive. Calls continued for a while, but new SIP calls could not be<br>
established.<br>
<br>
On the second time this happended, all SIP phones could not subscribe to the Asterisk any longer and a few minutes later the log<br>
filled with:<br>
<br>
[2009-01-23 14:43:21] ERROR[22319] chan_sip.c: Call to peer '2333' rejected due to usage limit of 10<br>
<br>
On the CLI one could see, that there were 100s of (rejected) calls to this SIP phones.<br>
<br>
The phones that show up in the ERROR messages are in a group call made by a<br>
Dial(Local/...&Local.../&Local/...) construct. But other SIP phones were affected as well. It seemed like the whole chan_sip module<br>
became stuck. I also could not "unload chan_sip.so", but can't remeber the exact error message it gave.<br>
<br>
The only thing that was left was to restart Asterisk.<br>
<br>
Can someone give me some clue what the 'Fixup failed ...' and 'masquerade' warnings actually mean?<br>
<br>
Any help appreciated.<br>
Udo<br>
<br>
<br>
<br>
_______________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br>