[asterisk-dev] 1.6.1.20 regression: Tones not always generated

[Pavel Troller]

Hi!
  I've found a regression in asterisk-1.6.1.20. The "user's view" of the
problem is, that the ringing tone is not always played, where it should be.
The "debugger's view" reveals, that the problem obviously occurs, when
a RTP session is already established, and a new tone has to be played onto
it (typical examples: DISA(), WaitExten() with d option etc.). It affects
SIP (with progressinband=yes), chan-sccp-b and maybe other channels. DAHDI
is unaffected. And the "coder's view" shows, that the problem is caused by
moving the ast_prod() call in the ast_activate_generator() from the place,
where it was, to the end of the routine, just below the ast_channel_unlock()
call, as a part of this patch:

2010-04-28 21:33 +0000 [r259930]  David Vossel <dvossel at digium.com>

        * main/channel.c, channels/chan_local.c, /: Merged revisions 259870
          via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk
          ................ r259870 | dvossel | 2010-04-28 16:20:03 -0500
          (Wed, 28 Apr 2010) | 39 lines Merged revisions 259858 via
          svnmerge from
          https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
          r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010)
          | 33 lines resolves deadlocks in chan_local Issue_1. In the
          local_hangup() 3 locks must be held at the same time... pvt,
          pvt->chan, and pvt->owner. Proper deadlock avoidance is done when
          the channel to hangup is the outbound chan_local channel, but
          when it is not the outbound channel we have an issue... We
          attempt to do deadlock avoidance only on the tech pvt, when both
          the tech pvt and the pvt->owner are locked coming into that loop.
          By never giving up the pvt->owner channel deadlock avoidance is
          not entirely possible. This patch resolves that by doing deadlock
          avoidance on both the pvt->owner and the pvt when trying to get
          the pvt->chan lock. Issue_2. ast_prod() is used in
          ast_activate_generator() to queue a frame on the channel and make
          the channel's read function get called. This function is used in
          ast_activate_generator() while the channel is locked, which
          mean's the channel will have a lock both from the generator code
          and the frame_queue code by the time it gets to chan_local.c's
          local_queue_frame code... local_queue_frame contains some of the
          same crazy deadlock avoidance that local_hangup requires, and
          this recursive lock prevents that deadlock avoidance from
          happening correctly. This patch removes ast_prod() from the
          channel lock so only one lock is held during the
          local_queue_frame function. (closes issue #17185) Reported by:
          ....
After reverting just this single change, i.e. moving the ast_prod() call,
where it was, all the tones are on their correct places again. I'm aware of
that I've reintroduced the local channel deadlock, but it is less important
for me (not using chan_local very often) than missing tones.

As my knowledge of asterisk internals of tone generation is not very deep,
please excuse me for not supplying a new, better patch, but just reporting
this problem.

With regards, Pavel Troller