[svn-commits] lmadsen: tag 1.6.2.16-rc1 r298185 - /tags/1.6.2.16-rc1/
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Mon Dec 13 10:19:11 CST 2010
Author: lmadsen
Date: Mon Dec 13 10:19:05 2010
New Revision: 298185
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=298185
Log:
Importing files for 1.6.2.16-rc1 release.
Added:
tags/1.6.2.16-rc1/.lastclean (with props)
tags/1.6.2.16-rc1/.version (with props)
tags/1.6.2.16-rc1/ChangeLog (with props)
Added: tags/1.6.2.16-rc1/.lastclean
URL: http://svnview.digium.com/svn/asterisk/tags/1.6.2.16-rc1/.lastclean?view=auto&rev=298185
==============================================================================
--- tags/1.6.2.16-rc1/.lastclean (added)
+++ tags/1.6.2.16-rc1/.lastclean Mon Dec 13 10:19:05 2010
@@ -1,0 +1,1 @@
+36
Propchange: tags/1.6.2.16-rc1/.lastclean
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/1.6.2.16-rc1/.lastclean
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/1.6.2.16-rc1/.lastclean
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/1.6.2.16-rc1/.version
URL: http://svnview.digium.com/svn/asterisk/tags/1.6.2.16-rc1/.version?view=auto&rev=298185
==============================================================================
--- tags/1.6.2.16-rc1/.version (added)
+++ tags/1.6.2.16-rc1/.version Mon Dec 13 10:19:05 2010
@@ -1,0 +1,1 @@
+1.6.2.16-rc1
Propchange: tags/1.6.2.16-rc1/.version
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/1.6.2.16-rc1/.version
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/1.6.2.16-rc1/.version
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/1.6.2.16-rc1/ChangeLog
URL: http://svnview.digium.com/svn/asterisk/tags/1.6.2.16-rc1/ChangeLog?view=auto&rev=298185
==============================================================================
--- tags/1.6.2.16-rc1/ChangeLog (added)
+++ tags/1.6.2.16-rc1/ChangeLog Mon Dec 13 10:19:05 2010
@@ -1,0 +1,28720 @@
+2010-12-13 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.6.2.16-rc1 Released.
+
+2010-12-10 16:24 +0000 [r298050] Tilghman Lesher <tlesher at digium.com>
+
+ * main/netsock.c, configure, include/asterisk/autoconfig.h.in,
+ configure.ac: Portability issue on OpenSolaris. Also detect the
+ required structure element, because OpenSolaris defines
+ SIOCGIFHWADDR, but without support for IP sockets. (closes issue
+ #18442) Reported by: ranjtech Patches:
+ 20101209__issue18442.diff.txt uploaded by tilghman (license 14)
+ Tested by: ranjtech
+
+2010-12-09 22:10 +0000 [r297960] Terry Wilson <twilson at digium.com>
+
+ * /, channels/chan_sip.c: Merged revisions 297959 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297959 | twilson | 2010-12-09 16:00:30 -0600 (Thu, 09 Dec 2010)
+ | 14 lines 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-08 18:04 +0000 [r297908] Tilghman Lesher <tlesher at digium.com>
+
+ * configs/extensions.conf.sample: Use inheritance to get correct
+ results for SIPFROMDOMAIN. (from an internal Digium discussion)
+
+2010-12-07 22:58 +0000 [r297824] Jeff Peeler <jpeeler at digium.com>
+
+ * main/channel.c, /: Merged revisions 297823 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297823 | jpeeler | 2010-12-07 16:57:48 -0600 (Tue, 07 Dec 2010)
+ | 12 lines 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:40 +0000 [r297713-297819] Tilghman Lesher <tlesher at digium.com>
+
+ * contrib/init.d/org.asterisk.muted.plist (added), Makefile,
+ utils/muted.c, /: Merged revisions 297818 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297818 | tilghman | 2010-12-07 16:35:50 -0600 (Tue, 07 Dec 2010)
+ | 4 lines Use non-deprecated APIs for CoreAudio Review:
+ https://reviewboard.asterisk.org/r/1040/ ........
+
+ * apps/app_followme.c, /: Merged revisions 297689 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297689 | tilghman | 2010-12-06 18:07:37 -0600 (Mon, 06 Dec 2010)
+ | 8 lines 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 22:03 +0000 [r297605] Jeff Peeler <jpeeler at digium.com>
+
+ * /, channels/chan_sip.c: Merged revisions 297603 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297603 | jpeeler | 2010-12-06 15:57:15 -0600 (Mon, 06 Dec 2010)
+ | 12 lines 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-03 17:40 +0000 [r297534] Sean Bright <sean at malleable.com>
+
+ * channels/chan_console.c: The CLI command should not contain
+ <placeholder>s, these are for descriptions.
+
+2010-12-02 20:06 +0000 [r297405] Paul Belanger <pabelanger at digium.com>
+
+ * Makefile, /: Merged revisions 297404 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297404 | pabelanger | 2010-12-02 15:01:08 -0500 (Thu, 02 Dec
+ 2010) | 7 lines 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:07 +0000 [r297311] Terry Wilson <twilson at digium.com>
+
+ * /, main/abstract_jb.c: Merged revisions 297310 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297310 | twilson | 2010-12-02 12:00:27 -0600 (Thu, 02 Dec 2010)
+ | 12 lines 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 [r297229] Russell Bryant <russell at digium.com>
+
+ * /, apps/app_meetme.c: Merged revisions 297228 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297228 | russell | 2010-12-02 07:16:15 -0600 (Thu, 02 Dec 2010)
+ | 6 lines 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:55 +0000 [r297186] Olle Johansson <oej at edvina.net>
+
+ * /, channels/chan_sip.c: Merged revisions 297185 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297185 | oej | 2010-12-02 09:37:17 +0100 (Tor, 02 Dec 2010) | 5
+ lines 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:52 +0000 [r297073] Jeff Peeler <jpeeler at digium.com>
+
+ * /, channels/chan_sip.c: Merged revisions 297072 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r297072 | jpeeler | 2010-12-01 11:50:09 -0600 (Wed, 01 Dec 2010)
+ | 23 lines 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 17:01 +0000 [r296950-296991] Tilghman Lesher <tlesher at digium.com>
+
+ * include/asterisk/frame.h, /: Merged revisions 296990 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r296990 | tilghman | 2010-12-01 10:59:26 -0600 (Wed, 01
+ Dec 2010) | 5 lines Clarify documentation on how we store codec
+ preference lists. (closes issue #18397) Reported by: birgita
+ ........
+
+ * channels/chan_iax2.c: Missed initializations caused startup
+ errors on Mac OS X (and possibly others, too).
+
+2010-12-01 00:24 +0000 [r296869] Jeff Peeler <jpeeler at digium.com>
+
+ * apps/app_voicemail.c, /: Merged revisions 296868 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r296868 | jpeeler | 2010-11-30 18:23:19 -0600 (Tue, 30
+ Nov 2010) | 4 lines Properly restore backup information file when
+ hanging up during message prepending. ABE-2654 ........
+
+2010-11-29 22:54 +0000 [r296671] Paul Belanger <pabelanger at digium.com>
+
+ * channels/chan_iax2.c, /: Merged revisions 296670 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r296670 | pabelanger | 2010-11-29 17:49:39 -0500 (Mon,
+ 29 Nov 2010) | 5 lines Make sure nothing else is needed before
+ destroying the scheduler. (closes issue #18398) Reported by:
+ pabelanger ........
+
+2010-11-29 07:27 +0000 [r296533] Tilghman Lesher <tlesher at digium.com>
+
+ * main/asterisk.c, configure, include/asterisk/autoconfig.h.in,
+ configure.ac: I love standards. There are so many to choose from.
+ Except when there isn't one. Linux and *BSD disagree on the
+ elements within the ucred structure. Detect which one is in use
+ on the system. (closes issue #18384) Reported by: bjm Patches:
+ cred-diffs uploaded by bjm (license 473)
+ 20101127__issue18384__1.6.2.diff.txt uploaded by tilghman
+ (license 14) 20101127__issue18384__1.8.diff.txt uploaded by
+ tilghman (license 14) Tested by: tilghman, bjm
+
+2010-11-27 10:39 +0000 [r296466] Tilghman Lesher <tlesher at digium.com>
+
+ * apps/app_meetme.c: 18 characters is too short for most date/times
+ (20 is the usual, but we add more in case of greater precision).
+ (closes issue #18369) Reported by: tnakonz
+
+2010-11-26 12:23 +0000 [r296351] Olle Johansson <oej at edvina.net>
+
+ * /, main/say.c: Merged revisions 296309 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r296309 | oej | 2010-11-26 10:53:31 +0100 (Fre, 26 Nov 2010) | 11
+ lines 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:28 +0000 [r296221] Russell Bryant <russell at digium.com>
+
+ * main/channel.c, /: Merged revisions 296213 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r296213 | russell | 2010-11-24 17:26:43 -0600 (Wed, 24 Nov 2010)
+ | 6 lines 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:42 +0000 [r296166] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c, /: Merged revisions 296165 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r296165 | rmudgett | 2010-11-24 16:41:07 -0600 (Wed, 24
+ Nov 2010) | 43 lines 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:23 +0000 [r296001-296083] Russell Bryant <russell at digium.com>
+
+ * main/channel.c, /: Merged revisions 296082 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r296082 | russell | 2010-11-24 14:22:32 -0600 (Wed, 24 Nov 2010)
+ | 12 lines 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, /: Merged revisions 296000 via
+ svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010)
+ | 38 lines 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:36 +0000 [r295907] Olle Johansson <oej at edvina.net>
+
+ * /, main/say.c: Merged revisions 295906 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r295906 | oej | 2010-11-23 10:28:14 +0100 (Tis, 23 Nov 2010) | 8
+ lines 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 20:02 +0000 [r295868] Sean Bright <sean at malleable.com>
+
+ * configs/chan_dahdi.conf.sample: Change some documentation to
+ suggest dahdi_monitor instead of ztmonitor.
+
+2010-11-22 19:28 +0000 [r295843] Richard Mudgett <rmudgett at digium.com>
+
+ * include/asterisk/frame.h, main/channel.c, main/pbx.c, /,
+ apps/app_macro.c, include/asterisk/channel.h: Merged revisions
+ 295790 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010)
+ | 46 lines 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-20 00:45 +0000 [r295710] Russell Bryant <russell at digium.com>
+
+ * include/asterisk/event.h, main/event.c: Fix cache of device state
+ changes for multiple servers. This patch addresses a regression
+ where device states across multiple servers were not being
+ processing completely correctly. The code works to determine the
+ overall state by looking at the last known state of a device on
+ each server. However, there was a regression due to some invasive
+ rewrites of how the cache works that led to the cache only
+ storing the last device state change for a device, regardless of
+ which server it was on. The code is set up to cache device state
+ change events by ensuring that each event in the cache has a
+ unique device name + entity ID (server ID). The code that was
+ responsible for comparing raw information elements (which EID is)
+ always returned a match due to a memcmp() with a length of 0.
+ There isn't much code to fix the actual bug. This patch also
+ introduces a new CLI command that was very useful for debugging
+ this problem. The command allows you to dump the contents of the
+ event cache. (closes issue #18284) Reported by: klaus3000
+ Patches: issue18284.rev1.txt uploaded by russell (license 2)
+ Tested by: russell, klaus3000 (closes issue #18280) Reported by:
+ klaus3000 Review: https://reviewboard.asterisk.org/r/1012/
+
+2010-11-19 21:55 +0000 [r295672] Terry Wilson <twilson at digium.com>
+
+ * /, channels/chan_sip.c: Merged revisions 295628 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r295628 | twilson | 2010-11-19 12:53:36 -0800 (Fri, 19 Nov 2010)
+ | 8 lines 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-18 17:51 +0000 [r295440] Paul Belanger <pabelanger at digium.com>
+
+ * res/res_jabber.c, include/asterisk/jabber.h: Fix compiler
+ warnings when using openssl-dev 1.0.0+ Review:
+ https://reviewboard.asterisk.org/r/1016/
+
+2010-11-16 22:57 +0000 [r295281] Richard Mudgett <rmudgett at digium.com>
+
+ * main/channel.c, /: Merged revisions 295280 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r295280 | rmudgett | 2010-11-16 16:52:06 -0600 (Tue, 16 Nov 2010)
+ | 1 line Dead code elimination in channel.c:ast_channel_bridge()
+ variable who. ........
+
+2010-12-02 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.6.2.15 Released.
+
+2010-11-15 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.6.2.15-rc1
+
+2010-11-15 18:24 +0000 [r294988-295062] Tilghman Lesher <tlesher at digium.com>
+
+ * tests/test_expr.c (added), /: Merged revisions 295026 via
+ svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r295026 | tilghman | 2010-11-15 11:58:37 -0600 (Mon, 15 Nov 2010)
+ | 2 lines Create test verifying results of expression parser
+ ........
+
+ * funcs/func_curl.c: It is possible to crash Asterisk by feeding
+ the curl engine invalid data. (closes issue #18161) Reported by:
+ wdoekes Patches: 20101029__issue18161.diff.txt uploaded by
+ tilghman (license 14) Tested by: tilghman
+
+2010-11-12 21:14 +0000 [r294904-294910] Jeff Peeler <jpeeler at digium.com>
+
+ * apps/app_voicemail.c: Return correct error code if lock path
+ fails. The recent changes to open_mailbox actually caused it to
+ be fixed, but let's be consistent. Reported by alecdavis in
+ asterisk-dev.
+
+ * apps/app_voicemail.c, /: Merged revisions 294903 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r294903 | jpeeler | 2010-11-12 14:49:09 -0600 (Fri, 12
+ Nov 2010) | 16 lines 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:44 +0000 [r294822] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c, /: Merged revisions 294821 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r294821 | rmudgett | 2010-11-11 20:41:13 -0600 (Thu, 11
+ Nov 2010) | 11 lines 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 21:57 +0000 [r294639-294733] Jeff Peeler <jpeeler at digium.com>
+
+ * /, channels/chan_sip.c: Merged revisions 294688 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r294688 | jpeeler | 2010-11-11 15:12:27 -0600 (Thu, 11 Nov 2010)
+ | 18 lines 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) (closes issue #17779) Reported by: lftsy Patches:
+ bug16382-3.patch uploaded by jpeeler (license 325) Tested by:
+ zerohalo ........
+
+ * main/asterisk.c, include/asterisk.h, main/pbx.c, /: Merged
+ revisions 294384 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r294384 | jpeeler | 2010-11-09 11:37:59 -0600 (Tue, 09 Nov 2010)
+ | 47 lines 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-10 23:16 +0000 [r294571] Tilghman Lesher <tlesher at digium.com>
+
+ * main/features.c: Actually pay attention to documented settings in
+ features.conf. (closes issue #16757) Reported by: voxter Patches:
+ 20101012__issue16757.diff.txt uploaded by tilghman (license 14)
+ Review: https://reviewboard.asterisk.org/r/994/
+
+2010-11-10 12:41 +0000 [r294500] Russell Bryant <russell at digium.com>
+
+ * main/devicestate.c: Improve a debug message to be more readable
+ and consistent. (closes issue #18282) Reported by: klaus3000
+ Patches: ast_devstate2str-patch.txt uploaded by klaus3000
+ (license 65)
+
+2010-11-09 20:27 +0000 [r294429] Tilghman Lesher <tlesher at digium.com>
+
+ * configure, configure.ac: Detect GMime properly on systems where
+ gmime flags and libs are configured with pkg-config. (closes
+ issue #16155) Reported by: jcollie Patches:
+ 20100917__issue16155.diff.txt uploaded by tilghman (license 14)
+ Tested by: tilghman
+
+2010-11-08 22:30 +0000 [r294277-294312] Jeff Peeler <jpeeler at digium.com>
+
+ * res/res_timing_timerfd.c: add missing unlock not present in
+ 294277
+
+ * main/timing.c, main/channel.c, res/res_timing_timerfd.c,
+ include/asterisk/timing.h: Fix playback failure when using IAX
+ with the timerfd module. To fix this issue the alert pipe will
+ now be used when the timerfd module is in use. There appeared to
+ be a race that was not solved by adding locking in the timerfd
+ module, but needed to be there anyway. The race was between the
+ timer being put in non-continuous mode in ast_read on the channel
+ thread and the IAX frame scheduler queuing a frame which would
+ enable continuous mode before the non-continuous mode event was
+ read. This race for now is simply avoided. (closes issue #18110)
+ Reported by: tpanton Tested by: tpanton I put tested by tpanton
+ because it was tested on his hardware. Thanks for the remote
+ access to debug this issue!
+
+2010-11-08 20:50 +0000 [r294242] Matthew Nicholson <mnicholson at digium.com>
+
+ * channels/chan_sip.c: Go off hold when we get an empty reinvite
+ telling us to. (closes issue 0014448) Reported by: frawd (closes
+ issue #17878) Reported by: frawd
+
+2010-11-05 00:06 +0000 [r293969] Shaun Ruffell <sruffell at digium.com>
+
+ * codecs/codec_dahdi.c, /: Merged revisions 293968 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r293968 | sruffell | 2010-11-04 19:02:53 -0500 (Thu, 04
+ Nov 2010) | 17 lines 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-03 18:31 +0000 [r293806] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c, /: Merged revisions 293805 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r293805 | rmudgett | 2010-11-03 13:23:04 -0500 (Wed, 03
+ Nov 2010) | 20 lines 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:07 +0000 [r293723] Jeff Peeler <jpeeler at digium.com>
+
+ * /, channels/chan_sip.c: Merged revisions 293722 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r293722 | jpeeler | 2010-11-02 18:02:51 -0500 (Tue, 02 Nov 2010)
+ | 8 lines 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:26 +0000 [r293647] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c, /: Merged revisions 293639 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r293639 | rmudgett | 2010-11-02 16:24:13 -0500 (Tue, 02
+ Nov 2010) | 6 lines 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:49 +0000 [r293340-293417] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c, /: Merged revisions 293416 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r293416 | rmudgett | 2010-10-29 20:45:49 -0500 (Fri, 29
+ Oct 2010) | 1 line Remove some more code that serves no purpose.
+ ........
+
+ * channels/chan_dahdi.c, /: Merged revisions 293339 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r293339 | rmudgett | 2010-10-29 19:34:12 -0500 (Fri, 29
+ Oct 2010) | 1 line Remove some code that serves no purpose.
+ ........
+
+2010-10-28 19:54 +0000 [r293195-293196] Tilghman Lesher <tlesher at digium.com>
+
+ * main/ast_expr2.c, main/ast_expr2.h: Merged revisions 293194 via
+ svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r293194 | tilghman | 2010-10-28 14:44:37 -0500 (Thu, 28 Oct 2010)
+ | 5 lines "!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
+ ........
+
+ * /, res/ael/ael.tab.c, main/ast_expr2.y, res/ael/ael_lex.c,
+ res/ael/ael.tab.h: Merged revisions 293194 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.4 ........
+ r293194 | tilghman | 2010-10-28 14:44:37 -0500 (Thu, 28 Oct 2010)
+ | 5 lines "!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-28 16:09 +0000 [r293158] Jeff Peeler <jpeeler at digium.com>
+
+ * funcs/func_strings.c: Fix infinite loop in FILTER(). Specifically
+ when you're using characters above \x7f or invalid character
+ escapes (e.g. \xgg). (closes issue #18060) Reported by: wdoekes
+ Patches: issue18060_func_strings_filter_infinite_loop.patch
+ uploaded by wdoekes (license 717) Tested by: wdoekes
+
+2010-10-26 18:33 +0000 [r293118] Jeff Peeler <jpeeler at digium.com>
+
+ * apps/app_voicemail.c, /: Merged revisions 293004 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r293004 | jpeeler | 2010-10-25 17:55:28 -0500 (Mon, 25
+ Oct 2010) | 29 lines 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:06 +0000 [r292867] David Vossel <dvossel at digium.com>
+
+ * channels/chan_local.c, /: Merged revisions 292866 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.4
+ ........ r292866 | dvossel | 2010-10-25 14:05:07 -0500 (Mon, 25
+ Oct 2010) | 27 lines 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
[... 28038 lines stripped ...]
More information about the svn-commits
mailing list