[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