[svn-commits] lmadsen: tag 1.4.40-rc1 r301811 - /tags/1.4.40-rc1/

SVN commits to the Digium repositories svn-commits at lists.digium.com
Fri Jan 14 12:21:48 CST 2011


Author: lmadsen
Date: Fri Jan 14 12:21:42 2011
New Revision: 301811

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=301811
Log:
Importing files for 1.4.40-rc1 release.

Added:
    tags/1.4.40-rc1/.lastclean   (with props)
    tags/1.4.40-rc1/.version   (with props)
    tags/1.4.40-rc1/ChangeLog   (with props)

Added: tags/1.4.40-rc1/.lastclean
URL: http://svnview.digium.com/svn/asterisk/tags/1.4.40-rc1/.lastclean?view=auto&rev=301811
==============================================================================
--- tags/1.4.40-rc1/.lastclean (added)
+++ tags/1.4.40-rc1/.lastclean Fri Jan 14 12:21:42 2011
@@ -1,0 +1,1 @@
+33

Propchange: tags/1.4.40-rc1/.lastclean
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: tags/1.4.40-rc1/.lastclean
------------------------------------------------------------------------------
    svn:keywords = none

Propchange: tags/1.4.40-rc1/.lastclean
------------------------------------------------------------------------------
    svn:mime-type = text/plain

Added: tags/1.4.40-rc1/.version
URL: http://svnview.digium.com/svn/asterisk/tags/1.4.40-rc1/.version?view=auto&rev=301811
==============================================================================
--- tags/1.4.40-rc1/.version (added)
+++ tags/1.4.40-rc1/.version Fri Jan 14 12:21:42 2011
@@ -1,0 +1,1 @@
+1.4.40-rc1

Propchange: tags/1.4.40-rc1/.version
------------------------------------------------------------------------------
    svn:eol-style = native

Propchange: tags/1.4.40-rc1/.version
------------------------------------------------------------------------------
    svn:keywords = none

Propchange: tags/1.4.40-rc1/.version
------------------------------------------------------------------------------
    svn:mime-type = text/plain

Added: tags/1.4.40-rc1/ChangeLog
URL: http://svnview.digium.com/svn/asterisk/tags/1.4.40-rc1/ChangeLog?view=auto&rev=301811
==============================================================================
--- tags/1.4.40-rc1/ChangeLog (added)
+++ tags/1.4.40-rc1/ChangeLog Fri Jan 14 12:21:42 2011
@@ -1,0 +1,30936 @@
+2011-01-14  Leif Madsen <lmadsen at digium.com>
+
+	* Asterisk 1.4.40-rc1 Released
+
+2011-01-12 18:39 +0000 [r301591]  Matthew Nicholson <mnicholson at digium.com>
+
+	* main/manager.c: Don't store the thread id for the manager session
+	  in the structure we pass to the thread for the manager session.
+	  ABE-2543
+
+2011-01-12 18:10 +0000 [r301502]  Jeff Peeler <jpeeler at digium.com>
+
+	* main/channel.c: Fix CPU spike when pressing DTMF after agent
+	  login. The problem here is that DTMF was being continuously
+	  deferred and requeued since ast_safe_sleep is called in a loop.
+	  There are serveral other places in the code that sleeps and then
+	  loops in a similar fashion. Because of this fact I opted to not
+	  defer DTMF any more, which will not affect the original fix:
+	  https://reviewboard.asterisk.org/r/674 (closes issue #18130)
+	  Reported by: rgj
+
+2011-01-12  Leif Madsen <lmadsen at digium.com>
+
+	* Asterisk 1.4.39 Released.
+
+2010-12-13  Leif Madsen <lmadsen at digium.com>
+
+	* Asterisk 1.4.39-rc1 Released.
+
+2010-12-09 22:00 +0000 [r297959]  Terry Wilson <twilson at digium.com>
+
+	* channels/chan_sip.c: Ignore spurious REGISTER requests If a
+	  REGISTER request with a Call-ID matching an existing transaction
+	  is received it was possible that the REGISTER request would
+	  overwrite the initreq of the private structure. This info is used
+	  to generate messages for other responses in the transaction. This
+	  patch ignores REGISTER requests that match non-REGISTER
+	  transactions. (closes issue #18051) Reported by: eeman Tested by:
+	  twilson Review: https://reviewboard.asterisk.org/r/1050/
+
+2010-12-07 22:57 +0000 [r297823]  Jeff Peeler <jpeeler at digium.com>
+
+	* main/channel.c: Revert code that changed SSRC for DTMF. Some
+	  previous behavior was attempted to be restored, but mistakingly I
+	  did not realize that the previous behavior was incorrect. This
+	  fixes DTMF not being detected since DTMF shouldn't cause the SSRC
+	  to change. (related to issue #17404) (closes issue #18189)
+	  (closes issue #18352) Reported by: marcbou Tested by: cmbaker82
+
+2010-12-07 22:35 +0000 [r297818]  Tilghman Lesher <tlesher at digium.com>
+
+	* Makefile, utils/muted.c, contrib/init.d/org.asterisk.muted.plist
+	  (added): Use non-deprecated APIs for CoreAudio Review:
+	  https://reviewboard.asterisk.org/r/1040/
+
+2010-12-07 15:23 +0000 [r297775]  Sean Bright <sean at malleable.com>
+
+	* main/astobj2.c: Avoid a crash if we don't pass an argument to
+	  'astobj2 test.'
+
+2010-12-07 00:07 +0000 [r297689]  Tilghman Lesher <tlesher at digium.com>
+
+	* apps/app_followme.c: Don't create a Local channel if the target
+	  extension does not exist. (closes issue #18126) Reported by:
+	  junky Patches: followme.diff uploaded by junky (license 177)
+	  (partially restructured by me to avoid a possible memory leak)
+
+2010-12-06 21:57 +0000 [r297603]  Jeff Peeler <jpeeler at digium.com>
+
+	* channels/chan_sip.c: Improve handling of REGISTER requests with
+	  multiple contact headers. The changes here attempt to more
+	  strictly follow RFC 3261 section 10.3. Basically the following
+	  will now cause a 400 Bad Response to be returned, if: - multiple
+	  Contact headers are present with one set to expire all bindings
+	  ("*") - wildcard parameter is specified for Contact without
+	  Expires header or Expires header is not set to zero. ABE-2442
+	  ABE-2443
+
+2010-12-02 20:01 +0000 [r297404]  Paul Belanger <pabelanger at digium.com>
+
+	* Makefile: Resolve compile error under FreeBSD We now set
+	  _ASTCFLAGS+=-march=i686 for i386 processors, still allowing
+	  ASTCFLAGS to override the setting. Review:
+	  https://reviewboard.asterisk.org/r/1043/
+
+2010-12-02 18:00 +0000 [r297310]  Terry Wilson <twilson at digium.com>
+
+	* main/abstract_jb.c: Initialize offset for adaptive jitter buffer
+	  When the adaptive jitter buffer is enabled in sip.conf, the first
+	  frame placed in the jitter buffer fails with something like:
+	  jb_warning_output: Resyncing the jb. last_delay 0, this delay
+	  -215886466, threshold 1000, new offset 215886466 This happens
+	  because the offset is not initialized before calling jb_put().
+	  This patch modifies jb_put_first_adaptive() to set the offset to
+	  the frame's timestamp. Review:
+	  https://reviewboard.asterisk.org/r/1041/
+
+2010-12-02 13:16 +0000 [r297228]  Russell Bryant <russell at digium.com>
+
+	* apps/app_meetme.c: Add "DAHDI" to a couple of app_meetme error
+	  messages. This is in response to some questions on IRC. To the
+	  user, there was nothing that made it obvious that this error had
+	  anything to do with DAHDI not being loaded.
+
+2010-12-02 08:37 +0000 [r297185]  Olle Johansson <oej at edvina.net>
+
+	* channels/chan_sip.c: If we get a NOTIFY from a non-existing
+	  subscription we should answer with 481, not bad event. If we
+	  answer 481 the subscription that we don't want will be cancelled.
+
+2010-12-01 17:50 +0000 [r297072]  Jeff Peeler <jpeeler at digium.com>
+
+	* channels/chan_sip.c: Fix not stopping MOH when transfered local
+	  channel queue member is answered. The problem here is only
+	  present when local channels are used with the MOH passthru option
+	  as well as no optimization (/nm). I will describe the slightly
+	  bizarre scenario that was used to test, where phones B and C are
+	  queue members: Phone A dials into a queue with two members using
+	  local channels and the above options. Phone B answers. Phone A
+	  blind transfers phone B into the same queue. Phone A hangs up.
+	  Phone C answers, but phone B didn't stop playing MOH. In this
+	  scenario, the unhold frame that should have gotten to phone B
+	  never arrived due to the masquerade from the blind transfer. This
+	  is usually fine since app_queue manages the starting and stopping
+	  of MOH. However, with the passthrough option enabled when
+	  app_queue attempts to stop MOH it tries to do so on the local
+	  channel rather than the real channel. The easiest solution was to
+	  just make sure to send an unhold frame during the transfer since
+	  it wouldn't make sense to have MOH playing after a transfer
+	  anyway. This only modifies SIP transfers, but the other transfers
+	  did not seem to be a problem. If DTMF based transfers were a
+	  problem it might be okay to add ast_moh_stop to finishup, but I
+	  didn't want to have to add that unless required. ABE-2624
+
+2010-12-01 16:59 +0000 [r296990]  Tilghman Lesher <tlesher at digium.com>
+
+	* include/asterisk/frame.h: Clarify documentation on how we store
+	  codec preference lists. (closes issue #18397) Reported by:
+	  birgita
+
+2010-12-01 00:23 +0000 [r296868]  Jeff Peeler <jpeeler at digium.com>
+
+	* apps/app_voicemail.c: Properly restore backup information file
+	  when hanging up during message prepending. ABE-2654
+
+2010-12-01 00:20 +0000 [r296867]  Tilghman Lesher <tlesher at digium.com>
+
+	* main/asterisk.c, channels/chan_iax2.c: Get rid of the annoying
+	  startup and shutdown errors on OS X. This mainly deals with the
+	  problem of constructors on platforms where an explicit
+	  constructor order cannot be specified (any system with gcc 4.2 or
+	  less). However, this is only a problem on those systems where we
+	  need to initialize mutexes with a constructor, because we have
+	  other code that also relies upon constructors, and we cannot
+	  specify that mutexes are initialized first (and destroyed last).
+	  There are two approaches to dealing with this issue, related to
+	  whether the code exists in the core Asterisk binary or in a
+	  separate code module. In the core case, constructors are run
+	  immediately upon load, and the file_versions list mutex needs to
+	  be already initialized, as it is referenced in the first
+	  constructor within each core source file. In this case, we use
+	  pthread_once to ensure that the mutex is initialized immediately
+	  before it is used for the first time. The only caveat is that the
+	  mutex is not ever destroyed, but because this is the core, it
+	  makes no real difference; the only time when destruction is safe
+	  would be just prior to process destruction, which takes care of
+	  that anyway. And due to using pthread_once, the mutex will never
+	  be reinitialized, which means only one structure has leaked at
+	  the end of the process. Hence, it is not a problematic leak. The
+	  second approach is to use the load_module and unload_module
+	  routines, which, for obvious reasons, exist only in loadable
+	  modules. In this second case, we don't have a problem with the
+	  constructors, but only with destructor order, because mutexes can
+	  be destroyed before their final usage is employed. However, we
+	  need the mutexes to still be destroyed, in certain scenarios: if
+	  the module is unloaded prior to the process ending, it should be
+	  clean, with no allocations by the module hanging around after
+	  that point in time.
+
+2010-11-29 22:49 +0000 [r296670]  Paul Belanger <pabelanger at digium.com>
+
+	* channels/chan_iax2.c: Make sure nothing else is needed before
+	  destroying the scheduler. (closes issue #18398) Reported by:
+	  pabelanger
+
+2010-11-26 09:53 +0000 [r296309]  Olle Johansson <oej at edvina.net>
+
+	* main/say.c: Fix bugs in saying numbers using the Swedish language
+	  syntax (closes issue #18355) Reported by: oej Patch by: oej Much
+	  help from Peter Lindahl. Testing by the ClearIT team during a
+	  coffee break. Review: https://reviewboard.asterisk.org/r/1033/
+
+2010-11-24 23:26 +0000 [r296213]  Russell Bryant <russell at digium.com>
+
+	* main/channel.c: Make Asterisk less crashy. Since we might not put
+	  a new translation path on the channel, go ahead and set it to
+	  NULL right after destroying the old one to ensure we don't try to
+	  free an invalid translation path later on.
+
+2010-11-24 22:41 +0000 [r296165]  Richard Mudgett <rmudgett at digium.com>
+
+	* channels/chan_dahdi.c: Oneway audio to SIP phone from FXS port
+	  after FXS port gets a CallWaiting pip. The FXS connected phone
+	  has to have CW/CID support to fail, as it will send back a DTMF
+	  'A' or 'D' when it's ready to receive CallerID. A normal phone
+	  with no CID never fails. Also the SIP phone does not hear MOH
+	  when the CW call is answered. The DTMF end frame is suppressed
+	  when the phone acknowledges the CW signal for CID. The problem is
+	  the DTMF begin frame needs to be suppressed as well. The DTMF
+	  begin frame is causing SIP to start sending the DTMF RTP frames.
+	  Since the DTMF end frame is suppressed, SIP will not stop sending
+	  those DTMF RTP packets. * Suppress the DTMF begin and end frames
+	  when the channel driver is looking for DTMF digits. * Fixed a
+	  couple issues caused by not cleaning up the CID spill if you
+	  answer the CW call while it is sending the CID spill. * Fixed not
+	  sending CW/CID spill to the phone when the call is natively
+	  bridged. (Fixed by not using native bridge if CW/CID is
+	  possible.) * Suppress received audio when sending CW/CID spills.
+	  The other parties involved do not need to hear the CW/CID spills
+	  and may be confused if the CW call is for them. (closes issue
+	  #18129) Reported by: alecdavis Patches: issue_18129_v1.8_v3.patch
+	  uploaded by rmudgett (license 664) Tested by: alecdavis, rmudgett
+	  NOTE: * v1.4 does not have the main problem fixed by suppressing
+	  the DTMF start frames. The other three items fixed are relevant.
+	  * If you really must restore native bridging between analog
+	  ports, you need to disable CW/CID either by configuring
+	  chan_dahdi.conf callwaitingcallerid=no or dialing *70 before
+	  dialing the number to temporarily disable CW.
+
+2010-11-24 20:22 +0000 [r296000-296082]  Russell Bryant <russell at digium.com>
+
+	* main/channel.c: Fix false reporting of an error by set_format().
+	  In the case that the native format was able to be changed to
+	  match the new requested format, the code proceeded to attempt to
+	  build a translation path, anyway. The result would be NULL, since
+	  no translation path is necessary and resulted in this function
+	  thinking an error has occurred. This case is now specifically
+	  caught and no attempt to build a translation path is attempted.
+	  Thanks to our automated tests and bamboo.asterisk.org for
+	  catching this problem and making a whole lot of noise when things
+	  started failing. :-)
+
+	* apps/app_dial.c, main/channel.c: Handle failures building
+	  translation paths more effectively. The problem scenario occurred
+	  on a heavily loaded system that was using the codec_dahdi module
+	  and exceeded the hardware transcoding capacity. The failure mode
+	  at that point was not good. The report came in to us as an
+	  Asterisk lock-up. The "core show locks" shows a ton of threads
+	  locked up (but no obvious deadlock). Upon deeper investigation,
+	  when the system is in this state, the CPU was maxed out. The CPU
+	  was being consumed by the Asterisk logger spewing messages on
+	  every audio frame for calls set up after transcoder capacity was
+	  reached. The purpose of this patch is to make Asterisk handle
+	  failures to create a translation path in a more graceful manner.
+	  If we can't translate, then the call just needs to be dropped, as
+	  it's not going to work. These are the changes: 1) In set_format()
+	  of channel.c (which is called by set_read_format() and
+	  set_write_format()), it was ignoring if
+	  ast_translator_build_path() failed and returned NULL. It now pays
+	  attention to that case and returns a result reflecting failure.
+	  With this change in place, the bridging code will immediately
+	  detect a failure and end the bridge instead of proceeding to try
+	  to bridge frames that can't be translated and making channel
+	  drivers freak out by sending them frames in a format they weren't
+	  expecting. 2) In ast_indicate_data() of channel.c, failure of
+	  ast_playtones_start() was ignored. It is now reflected in the
+	  return value of the function. This didn't turn out to have any
+	  affect on the bug, but seemed like a good change to leave in. 3)
+	  In app_dial(), when only sending a call to a single endpoint, it
+	  will attempt to do some bridging of its own of early audio. It
+	  uses make_compatible() when it's going to do this. However, it
+	  ignored failure from make compatible. So, even with the fix from
+	  #1, if there was early audio going through app_dial, there would
+	  still be a period of invalid frames passing through. After
+	  detecting failure here, Dial() exits. ABE-2658
+
+2010-11-23 09:28 +0000 [r295906]  Olle Johansson <oej at edvina.net>
+
+	* main/say.c: Fix support of saynumber(1,n) in the Swedish language
+	  (closes issue #18353) Reported by: oej Review:
+	  https://reviewboard.asterisk.org/r/1031/
+
+2010-11-22 18:46 +0000 [r295790]  Richard Mudgett <rmudgett at digium.com>
+
+	* main/channel.c, main/pbx.c, apps/app_macro.c,
+	  include/asterisk/channel.h, include/asterisk/frame.h: The channel
+	  redirect function (CLI or AMI) hangs up the call instead of
+	  redirecting the call. To recreate the problem: 1) Party A calls
+	  Party B 2) Invoke CLI "channel redirect" command to redirect
+	  channel call leg associated with A. 3) All associated channels
+	  are hung up. Note that if the CLI command were done on the
+	  channel call leg associated with B it works. This regression was
+	  a result of the fix for issue #16946
+	  (https://reviewboard.asterisk.org/r/740/). The regression affects
+	  all features that use an async goto to execute the dialplan
+	  because of an external event: Channel redirect, AMI redirect, SIP
+	  REFER, and FAX detection. The struct ast_channel._softhangup code
+	  is a mess. The variable is used for several purposes that do not
+	  necessarily result in the call being hung up. I have added
+	  doxygen comments to describe how the various _softhangup bits are
+	  used. I have corrected all the places where the variable was
+	  tested in a non-bit oriented manner. The primary fix is the new
+	  AST_CONTROL_END_OF_Q frame. It acts as a weak hangup request so
+	  the soft hangup requests that do not normally result in a hangup
+	  do not hangup. JIRA SWP-2470 JIRA SWP-2489 (closes issue #18171)
+	  Reported by: SantaFox (closes issue #18185) Reported by:
+	  kwemheuer (closes issue #18211) Reported by: zahir_koradia
+	  (closes issue #18230) Reported by: vmarrone (closes issue #18299)
+	  Reported by: mbrevda (closes issue #18322) Reported by: nerbos
+	  Review: https://reviewboard.asterisk.org/r/1013/
+
+2010-11-19 20:53 +0000 [r295628]  Terry Wilson <twilson at digium.com>
+
+	* channels/chan_sip.c: Discard responses with more than one Via
+	  This is not a perfect solution as headers that are joined via
+	  commas are not detected. This is a parsing issue that to fix
+	  "correctly" would necessitate a new SIP parser. Review:
+	  https://reviewboard.asterisk.org/r/1019/
+
+2010-11-19 19:32 +0000 [r295552-295553]  Erin Spiceland <erin at thespicelands.com>
+
+	* res/res_agi.c: Revert a new feature which should have gone into
+	  trunk.
+
+	* res/res_agi.c: Add extra functionality to AGI command WAIT FOR
+	  DIGIT. Add the ability to play a sound file, listen for more than
+	  just one digit, specify escape characters. Backwards compatible
+	  (to work with only timeout specified). (closes issue #15531)
+	  Reported by: diLLec Patches:
+	  asterisk-res_agi-203638-patched.patch uploaded by diLLec (license
+	  839) Tested by: diLLec, espiceland
+
+2010-11-16 22:52 +0000 [r295280]  Richard Mudgett <rmudgett at digium.com>
+
+	* main/channel.c: Dead code elimination in
+	  channel.c:ast_channel_bridge() variable who.
+
+2010-11-16 21:29 +0000 [r295200]  Jeff Peeler <jpeeler at digium.com>
+
+	* apps/app_voicemail.c: Ensure original message duration is
+	  preserved when prepending a message. It seems the fix to issue
+	  17103 was a little overzealous and removed the code that backed
+	  up the textfile containing the original message duration. This
+	  code has now been restored. (related to issue #17103) ABE-2654
+
+2010-12-02  Leif Madsen <lmadsen at digium.com>
+
+	* Asterisk 1.4.38 Released.
+
+2010-11-15  Leif Madsen <lmadsen at digium.com>
+
+	* Asterisk 1.4.38-rc1 Released.
+
+2010-11-15 18:05 +0000 [r295026-295031]  Tilghman Lesher <tlesher at digium.com>
+
+	* tests/test_expr.c: Err, oops. Made it const to verify that it
+	  wasn't altered, but forgot to revert before commit.
+
+	* tests/test_expr.c (added): Create test verifying results of
+	  expression parser
+
+2010-11-12 20:49 +0000 [r294903]  Jeff Peeler <jpeeler at digium.com>
+
+	* apps/app_voicemail.c: Fix regression causing abort in voicemail
+	  after opening a mailbox with no mesgs. In order to be more safe,
+	  some error handling code was changed to respect more error
+	  conditions including the potential memory allocation failure for
+	  deleted and heard message tracking introduced in 293004. However,
+	  last_message_index returns -1 for zero messages (perhaps as
+	  expected) and was triggering the stricter error checking. Because
+	  last_message_index is only called directly in one place, just
+	  return 0 from open_mailbox (for file based storage) when no
+	  messages are detected unless a real error has occurred. (closes
+	  issue #18240) Reported by: leobrown Patches:
+	  bug18240.1-6-2.diff.txt uploaded by alecdavis (license 585)
+	  Tested by: pabelanger
+
+2010-11-12 02:41 +0000 [r294821]  Richard Mudgett <rmudgett at digium.com>
+
+	* channels/chan_dahdi.c: Asterisk is getting a "No D-channels
+	  available!" warning message every 4 seconds. Asterisk is just
+	  whining too much with this message: "No D-channels available!
+	  Using Primary channel XXX as D-channel anyway!". Filtered the
+	  message so it only comes out once if there is no D channel
+	  available without an intervening D channel available period.
+	  (closes issue #17270) Reported by: jmls
+
+2010-11-11 22:11 +0000 [r294641-294739]  Jeff Peeler <jpeeler at digium.com>
+
+	* main/pbx.c: I didn't mean to merge this, sorry
+
+	* channels/chan_sip.c: Fix problem with qualify option packets for
+	  realtime peers never stopping. The option packets not only never
+	  stopped, but if a realtime peer was not in the peer list multiple
+	  options dialogs could accumulate over time. This scenario has the
+	  potential to progress to the point of saturating a link just from
+	  options packets. The fix was to ensure that the poke scheduler
+	  checks to see if a peer is in the peer list before continuing to
+	  poke. The reason a peer must be in the peer list to be able to
+	  properly manage an options dialog is because otherwise the call
+	  pointer is lost when the peer is regenerated from the database,
+	  which is how existing qualify dialogs are detected. (closes issue
+	  #16382) Reported by: lftsy Patches: bug16382-3.patch uploaded by
+	  jpeeler (license 325) Tested by: zerohalo
+
+	* main/pbx.c: One small addition to 294384 found while very
+	  carefully merging to 1.6.
+
+2010-11-09 17:37 +0000 [r294384]  Jeff Peeler <jpeeler at digium.com>
+
+	* main/asterisk.c, include/asterisk.h, main/pbx.c: Fix a deadlock
+	  in device state change processing. Copied from some notes from
+	  the original author (Russell): Deadlock scenario: Thread 1:
+	  device state change thread Holds - rdlock on contexts Holds -
+	  hints lock Waiting on channels container lock Thread 2: SIP
+	  monitor thread Holds the "iflock" Holds a sip_pvt lock Holds
+	  channel container lock Waiting for a channel lock Thread 3: A
+	  channel thread (chan_local in this case) Holds 2 channel locks
+	  acquired within app_dial Holds a 3rd channel lock it got inside
+	  of chan_local Holds a local_pvt lock Waiting on a rdlock of the
+	  contexts lock A bunch of other threads waiting on a wrlock of the
+	  contexts lock To address this deadlock, some locking order rules
+	  must be put in place and enforced. Existing relevant rules: 1)
+	  channel lock before a pvt lock 2) contexts lock before hints lock
+	  3) channels container before a channel What's missing is some
+	  enforcement of the order when you involve more than any two. To
+	  fix this problem, I put in some code that ensures that (at least
+	  in the code paths involved in this bug) the locks in (3) come
+	  before the locks in (2). To change the operation of thread 1 to
+	  comply, I converted the storage of hints to an astobj2 container.
+	  This allows processing of hints without holding the hints
+	  container lock. So, in the code path that led to thread 1's
+	  state, it no longer holds either the contexts or hints lock while
+	  it attempts to lock the channels container. (closes issue #18165)
+	  Reported by: antonio ABE-2583
+
+2010-11-08 18:59 +0000 [r294163]  Matthew Nicholson <mnicholson at digium.com>
+
+	* channels/chan_sip.c: Modify our handling of 491 responses to drop
+	  any pending reinvite retry scheduler entries if we get a new 491.
+	  This prevents a scheduler entry from leaking if we receive a 491
+	  response when one is pending. If a scheduler entry leaks, the pvt
+	  it is associated my get destroyed before the scheduler entry
+	  fires, and then memory corruption and crashes can occur when the
+	  scheduled reinvite attempts to access and modify the memory of
+	  the destroyed pvt. ABE-2543
+
+2010-11-05 00:02 +0000 [r293968]  Shaun Ruffell <sruffell at digium.com>
+
+	* codecs/codec_dahdi.c: codecs/codec_dahdi: Prevent "choppy" audio
+	  when receiving unexpected frame sizes. dahdi-linux 2.4.0
+	  (specifically commit 9034) added the capability for the wctc4xxp
+	  to return more than a single packet of data in response to a
+	  read. However, when decoding packets, codec_dahdi was still
+	  assuming that the default number of samples was in each read. In
+	  other words, each packet your provider sent you, regardless of
+	  size, would result in 20 ms of decoded data (30 ms if decoding
+	  G723). If your provider was sending 60 ms packets then
+	  codec_dahdi would end up stripping 40 ms of data from each
+	  transcoded frame resulting in "choppy" audio. This would only
+	  affect systems where G729 packets are arriving in sizes greater
+	  than 20ms or G723 packets arriving in sizes greater than 30ms.
+	  DAHDI-744.
+
+2010-11-04 21:28 +0000 [r293922]  David Vossel <dvossel at digium.com>
+
+	* res/res_features.c: Fixes ringback tone on feature semi-attended
+	  transfer ABE-2168
+
+2010-11-03 18:23 +0000 [r293805]  Richard Mudgett <rmudgett at digium.com>
+
+	* channels/chan_dahdi.c: Party A in an analog 3-way call would
+	  continue to hear ringback after party C answers. All parties are
+	  analog FXS ports. 1) A calls B. 2) A flash hooks to call C. 3) A
+	  flash hooks to bring C into 3-way call before C answers. (A and B
+	  hear ringback) 4) C answers 5) A continues to hear ringback
+	  during the 3-way call. (All parties can hear each other.) * Fixed
+	  use of wrong variable in dahdi_bridge() that stopped ringback on
+	  the wrong subchannel. * Made several debug messages have more
+	  information. A similar issue happens if B and C are SIP channels.
+	  B continues to hear ringback. For some reason this only affects
+	  v1.8 and trunk. * Don't start ringback on the real and 3-way
+	  subchannels when creating the 3-way conference. Removing this
+	  code is benign on v1.6.2 and earlier.
+
+2010-11-02 23:02 +0000 [r293722]  Jeff Peeler <jpeeler at digium.com>
+
+	* channels/chan_sip.c: Add enabled/disabled information for
+	  rtautoclear sip show settings output. When setting to zero/"no",
+	  the numeric default was shown making it not obvious the disabled
+	  setting was respected. (closes issue #18123) Reported by:
+	  zerohalo
+
+2010-11-02 21:24 +0000 [r293639]  Richard Mudgett <rmudgett at digium.com>
+
+	* channels/chan_dahdi.c: Make warning message have more useful
+	  information in it. Change "Unable to get index, and nullok is not
+	  asserted" to "Unable to get index for '<channel-name>' on channel
+	  <number> (<function>(), line <number>)".
+
+2010-10-30 01:45 +0000 [r293339-293416]  Richard Mudgett <rmudgett at digium.com>
+
+	* channels/chan_dahdi.c: Remove some more code that serves no
+	  purpose.
+
+	* channels/chan_dahdi.c: Remove some code that serves no purpose.
+
+2010-10-28 19:44 +0000 [r293194]  Tilghman Lesher <tlesher at digium.com>
+
+	* main/ast_expr2.c, main/ast_expr2.h, main/ast_expr2.y: "!00"
+	  evaluated as false, which is incorrect. Fixing. Reported (though
+	  the reporter did not understand he was reporting a bug) on the
+	  asterisk-users list:
+	  http://lists.digium.com/pipermail/asterisk-users/2010-October/255505.html
+
+2010-10-25 22:55 +0000 [r293004]  Jeff Peeler <jpeeler at digium.com>
+
+	* apps/app_voicemail.c: Fix inprocess_container in voicemail to
+	  correctly restrict max messages. The comparison function logic
+	  was off, so the number of sessions for a given mailbox were not
+	  being incremented properly. This problem caused the maximum
+	  number of messages per folder to not be respected when
+	  simultaneously leaving multiple voicemails just below the
+	  threshold. These problems should be fixed by the above, but just
+	  in case: Fixed resequence_mailbox to rely on the actual number of
+	  detected number of files in a directory rather than just assuming
+	  only 10 messages more than the maximum had been left. Also if
+	  more messages than the maximum are deleted they are actually
+	  removed now. The second purpose of this commit should have been
+	  separated out probably, but is related to the above. Again, if
+	  the number of messages in a given voicemail folder exceeds the
+	  maximum set limit make sure to allocate enough space for the
+	  deleted and heard index tracking array. A few random fixes: There
+	  was a forgotten decrement of the inprocess count in
+	  imap_store_file. When using IMAP storage, do not look in the
+	  directory where file based storage messages may still reside and
+	  influence the message count. Ensure to use only the first format
+	  in sendmail. ABE-2516
+
+2010-10-25 19:05 +0000 [r292866]  David Vossel <dvossel at digium.com>
+
+	* channels/chan_local.c: This patch turns chan_local pvts into
+	  astobj2 objects. chan_local does some dangerous things involving
+	  deadlock avoidance. tech_pvt functions like hangup and
+	  queue_frame are provided with a locked channel upon entry. Those
+	  functions are completely safe as long as you don't attempt to
+	  give up that channel lock, but that is impossible to guarantee
+	  due to the required deadlock avoidance necessary to lock both the
+	  tech_pvt and both channels involved. In the past, we have tried
+	  to account for this by doing things like setting a "glare" flag
+	  that indicates what function should destroy the pvt. This was
+	  used in local_hangup and local_queue_frame to decided who should
+	  destroy the pvt if they collided in separate threads. I have
+	  removed the need to do this by converting all chan_local
+	  tech_pvts to astobj2. This means we can ref a pvt before deadlock
+	  avoidance and not have to worry about that pvt possibly getting
+	  destroyed under us. It also cleans up where we destroy the
+	  tech_pvt. The only unlink from the tech_pvt container occurs in
+	  local_hangup now, which is where it should occur. Since there
+	  still may be thread collisions on some functions like
+	  local_hangup after deadlock avoidance, I have added some checks
+	  to detect those collisions and exit appropriately. I think this
+	  patch is going to solve quite a bit of weirdness we have had with
+	  local channels in the past.
+
+2010-10-21 00:00 +0000 [r292411]  Paul Belanger <paul.belanger at polybeacon.com>
+
+	* apps/app_dial.c: Record priv-recordintro as sln, not gsm This
+	  removes the gsm->sln step when transcoding priv-recordintro.
+	  (closes issue #18176) Reported by: pabelanger Patches:
+	  chan_sip.diff uploaded by pabelanger (license 224)
+
+2010-10-18 21:50 +0000 [r292223]  Jeff Peeler <jpeeler at digium.com>
+
+	* apps/app_voicemail.c: Fix improper operator key acceptance and
+	  clean up temp recording files. This is a fix for when pressing
+	  the operator key after recording an unavailable, busy, name, or
+	  temporary message in mailbox options. The operator key should not
+	  be accepted here, but should be allowed during the message
+	  recording. If the operator key is pressed during ensure the file
+	  is saved or deleted as apporopriate. Also, ensure removal of
+	  temporary recorded files after an early hang up or when message
+	  acceptance confirmation times out. ABE-2518
+
+2010-10-18 21:47 +0000 [r292222]  Leif Madsen <lmadsen at digium.com>
+
+	* sounds/sounds.xml, sounds/Makefile: Add support for the new
+	  English (Australian Accent) sound files. (closes issue #17426)
+	  Reported by: camsown Patches: core-sounds-en_AU.txt uploaded by
+	  camsown (license 1050) add_AU_sounds.patch.txt uploaded by
+	  lmadsen (license 10) Tested by: camsown, lmadsen, jtodd, qwell
+
+2010-10-15 19:30 +0000 [r291938]  Paul Belanger <paul.belanger at polybeacon.com>
+
+	* configs/gtalk.conf.sample: Clean up formatting.
+
+2010-10-15 02:13 +0000 [r291862]  Terry Wilson <twilson at digium.com>
+
+	* channels/chan_oss.c: Don't access o->next after freeing o on
+	  unload
+
+2010-10-13 23:29 +0000 [r291643]  Richard Mudgett <rmudgett at digium.com>
+
+	* channels/chan_dahdi.c: Deadlock between dahdi_exception() and
+	  dahdi_indicate(). There is a deadlock between dahdi_exception()
+	  and dahdi_indicate() for analog ports. The call-waiting and
+	  three-way-calling feature can experience deadlock if these
+	  features are trying to do something and an event from the bridged
+	  channel happens at the same time. Deadlock avoidance code added
+	  to obtain necessary channel locks before attemting an operation
+	  with call-waiting and three-way-calling. (closes issue #16847)
+	  Reported by: shin-shoryuken Patches: issue_16847_v1.4.patch
+	  uploaded by rmudgett (license 664) issue_16847_v1.6.2.patch
+	  uploaded by rmudgett (license 664) issue_16847_v1.8_v2.patch
+	  uploaded by rmudgett (license 664) Tested by: alecdavis, rmudgett
+	  Review: https://reviewboard.asterisk.org/r/971/
+
+2010-10-13 22:45 +0000 [r291577]  Terry Wilson <twilson at digium.com>
+
+	* main/channel.c: Don't ignore frames that have been queued when
+	  softhangup'd When an outgoing call is answered and hung up by the
+	  far end *very* quickly, we may not read any frames and therefor
+	  end up with a call that displays the wrong
+	  disposition/DIALSTATUS. The reason is because ast_queue_hangup()
+	  immediately sets the _softhangup flag on the channel and then
+	  queues the HANGUP control frame, but __ast_read refuses to read
+	  any frames if ast_check_hangup() indicates that a hangup request
+	  has been made (which it will if _softhangup is set). So, we end
+	  up losing control frames. This change makes __ast_read continue
+	  to read frames even if a soft hangup has been requested. It
+	  queues a hangup frame to make sure that __ast_read() will still
+	  eventually return NULL. Much thanks to David Vossel for all of
+	  the reviews, discussion, and help! (closes issue #16946) Reported
+	  by: davidw Review: https://reviewboard.asterisk.org/r/740/
+
+2010-10-13 15:23 +0000 [r291392]  Russell Bryant <russell at digium.com>
+
+	* channels/chan_sip.c: Lock pvt so pvt->owner can't disappear when
+	  queueing up a frame. This fixes a crash due to a hangup race
+	  condition. ABE-2601
+
+2010-10-12 16:55 +0000 [r291263]  Tilghman Lesher <tlesher at digium.com>
+
+	* main/acl.c: Oops, incorrect range (although unallocated at ARIN)
+
+2010-10-11 18:29 +0000 [r291109]  Richard Mudgett <rmudgett at digium.com>
+
+	* channels/chan_sip.c: Add missing unlock to an exception condition
+	  in reload_config().
+
+2010-10-08 02:35 +0000 [r290862]  Jeff Peeler <jpeeler at digium.com>
+
+	* main/asterisk.c: Ensure editline cleanup occurs when Ctrl-C is
+	  pressed at control console. A recent change was made to avoid a
+	  race condition on shutdown which only called the end functions
+	  from the console thread. However, when pressing Ctrl-C the quit
+	  handler is called from the signal handler thread. (closes issue
+	  #17698) Reported by: jmls
+
+2010-10-07 20:56 +0000 [r290750]  Jason Parker <jparker at digium.com>
+
+	* autoconf/ast_ext_lib.m4, configure,
+	  include/asterisk/autoconfig.h.in: Allow PRI to build properly
+	  when using --with-pri. Use the directories found for the parent
+	  when using lib dependencies. (closes issue #17314) Reported by:
+	  tzafrir Patches: 17314-withdeps.diff uploaded by qwell (license
+	  4)
+
+2010-10-05 20:20 +0000 [r290392]  Tilghman Lesher <tlesher at digium.com>
+
+	* res/res_jabber.c: Fix a crash by ensuring that we don't alter
+	  memory after it's freed. (closes issue #17387) Reported by: jmls
+	  Patches: 20100726__issue17387.diff.txt uploaded by tilghman
+	  (license 14) Tested by: jmls
+
+2010-10-05 17:41 +0000 [r290323]  Richard Mudgett <rmudgett at digium.com>
+
+	* contrib/valgrind.supp: Merged revision 258974 from
+	  https://origsvn.digium.com/svn/asterisk/trunk .......... r258974
+	  | diruggles | 2010-04-26 14:05:47 -0500 (Mon, 26 Apr 2010) | 4
+	  lines Line 24 missed in compatibility fix in revision 233577
+	  added a "fun:" prefix line 24 ..........
+
+2010-10-04 20:15 +0000 [r290100-290177]  Tilghman Lesher <tlesher at digium.com>
+
+	* configure, configure.ac: Fixing Mac OS X auto-builder.
+
+	* configure, configure.ac: Automatically re-run configure test for
+	  menuselect, when the relevant makeopts settings change.
+
+2010-10-02 08:50 +0000 [r289949]  Olle Johansson <oej at edvina.net>
+
+	* main/manager.c: Add documentation for undocumented option to AMI
+	  action originate
+
+2010-10-02 04:42 +0000 [r289873]  Tilghman Lesher <tlesher at digium.com>
+
+	* apps/app_voicemail.c: When forwarding a message, a prepend means
+	  that the filesystem will always have a better copy. (closes issue
+	  #17803) Reported by: dpetersen Patches:
+	  20100923__issue17803.diff.txt uploaded by tilghman (license 14)
+	  Tested by: dpetersen
+
+2010-10-01 22:58 +0000 [r289797]  Jeff Peeler <jpeeler at digium.com>
+
+	* main/rtp.c, channels/chan_sip.c, include/asterisk/rtp.h: Change
+	  RFC2833 DTMF event duration on end to report actual elapsed time.
+	  The scenario here is with a non P2P early media session. The
+	  reported time length of DTMF presses are coming up short when
+	  sending to the remote side. Currently the event duration is a
+	  running total that is incremented when sending continuation
+	  packets. These continuation packets are only triggered upon
+	  incoming media from the remote side, which means that the running
+	  total probably is not going to end up matching the actual length
+	  of time Asterisk received DTMF. This patch changes the end event
+	  duration to be lengthened if it is detected that the end event is
+	  going to come up short. Review:
+	  https://reviewboard.asterisk.org/r/957/ ABE-2476
+
+2010-10-01 17:03 +0000 [r289703]  Paul Belanger <paul.belanger at polybeacon.com>
+
+	* configs/jabber.conf.sample, res/res_jabber.c: Disable debugging
+	  by default and reformat .config file. Review:
+	  https://reviewboard.asterisk.org/r/929/
+
+2010-10-01 16:20 +0000 [r289699]  Jeff Peeler <jpeeler at digium.com>
+
+	* channels/chan_sip.c: Ensure user portion of SIP URI matches
+	  dialplan when using encoded characters. This commit takes a
+	  simliar approach to 288112 and checks the dialplan to determine
+	  the proper action for an incoming contact header as to whether or
+	  not it should be decoded or not. sip_new was blindly always
+	  decoding the extension, which also caused the outgoing contact

[... 30216 lines stripped ...]



More information about the svn-commits mailing list