[asterisk-commits] russell: tag 1.4.19-rc3 r109512 - /tags/1.4.19-rc3/
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Tue Mar 18 11:33:05 CDT 2008
Author: russell
Date: Tue Mar 18 11:33:04 2008
New Revision: 109512
URL: http://svn.digium.com/view/asterisk?view=rev&rev=109512
Log:
Importing files for 1.4.19-rc3 release
Added:
tags/1.4.19-rc3/.lastclean (with props)
tags/1.4.19-rc3/.version (with props)
tags/1.4.19-rc3/ChangeLog (with props)
Added: tags/1.4.19-rc3/.lastclean
URL: http://svn.digium.com/view/asterisk/tags/1.4.19-rc3/.lastclean?view=auto&rev=109512
==============================================================================
--- tags/1.4.19-rc3/.lastclean (added)
+++ tags/1.4.19-rc3/.lastclean Tue Mar 18 11:33:04 2008
@@ -1,0 +1,1 @@
+32
Propchange: tags/1.4.19-rc3/.lastclean
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/1.4.19-rc3/.lastclean
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/1.4.19-rc3/.lastclean
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/1.4.19-rc3/.version
URL: http://svn.digium.com/view/asterisk/tags/1.4.19-rc3/.version?view=auto&rev=109512
==============================================================================
--- tags/1.4.19-rc3/.version (added)
+++ tags/1.4.19-rc3/.version Tue Mar 18 11:33:04 2008
@@ -1,0 +1,1 @@
+1.4.19-rc3
Propchange: tags/1.4.19-rc3/.version
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/1.4.19-rc3/.version
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/1.4.19-rc3/.version
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/1.4.19-rc3/ChangeLog
URL: http://svn.digium.com/view/asterisk/tags/1.4.19-rc3/ChangeLog?view=auto&rev=109512
==============================================================================
--- tags/1.4.19-rc3/ChangeLog (added)
+++ tags/1.4.19-rc3/ChangeLog Tue Mar 18 11:33:04 2008
@@ -1,0 +1,16698 @@
+2008-03-18 Russell Bryant <russell at digium.com>
+
+ * Asterisk 1.4.19-rc3 released.
+
+2008-03-18 16:25 +0000 [r109482] Terry Wilson <twilson at digium.com>
+
+ * include/asterisk/astobj.h: Fix character string being treated ad
+ format string
+
+2008-03-18 15:10 +0000 [r109393] Jason Parker <jparker at digium.com>
+
+ * /, channels/chan_sip.c: Merged revisions 109391 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.2 ........
+ r109391 | qwell | 2008-03-18 10:08:41 -0500 (Tue, 18 Mar 2008) |
+ 3 lines Do not return with a successful authentication if the
+ From header ends up empty. (AST-2008-003) ........
+
+2008-03-18 14:58 +0000 [r109386] Joshua Colp <jcolp at digium.com>
+
+ * main/rtp.c, channels/chan_sip.c: Put a maximum limit on the
+ number of payloads accepted, and also make sure a given payload
+ does not exceed our maximum value. (AST-2008-002)
+
+2008-03-18 06:37 +0000 [r109309] Steve Murphy <murf at digium.com>
+
+ * pbx/ael/ael-test/ael-ntest23 (added),
+ pbx/ael/ael-test/ael-ntest23/t1/a.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t1/b.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t1/c.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t2/d.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t2/e.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t2/f.ael (added),
+ pbx/ael/ael-test/ref.ael-ntest23 (added), pbx/ael/ael_lex.c,
+ pbx/ael/ael-test/ael-ntest23/t3/g.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t3/h.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t3/i.ael (added), pbx/ael/ael.flex,
+ pbx/ael/ael-test/ael-ntest23/t3/j.ael (added),
+ pbx/ael/ael-test/ael-ntest23/qq.ael (added),
+ pbx/ael/ael-test/ael-ntest23/t1 (added),
+ pbx/ael/ael-test/ael-ntest23/t2 (added),
+ pbx/ael/ael-test/ael-ntest23/t3 (added),
+ pbx/ael/ael-test/ael-ntest23/extensions.ael (added): (closes
+ issue #11903) Reported by: atis Many thanks to atis for spotting
+ this problem and reporting it. The fix was to straighten out how
+ items are placed on and removed from the file stack. Regressions
+ as well as the provided test case helped to straighten out all
+ code paths. valgrind was used to make sure all memory allocated
+ was freed. Sorry for not solving this earlier. I got distracted.
+ Added the ntest23 regression test, which is mainly a copy of
+ ntest22, but with a few juicy errors thrown in, to replicate the
+ kind of error that atis spotted.
+
+2008-03-17 22:05 +0000 [r109226] Mark Michelson <mmichelson at digium.com>
+
+ * main/utils.c: Fix a logic flaw in the code that stores lock info
+ which is displayed via the "core show locks" command. The idea
+ behind this section of code was to remove the previous lock from
+ the list if it was a trylock that had failed. Unfortunately,
+ instead of checking the status of the previous lock, we were
+ referencing the index immediately following the previous lock in
+ the lock_info->locks array. The result of this problem, under the
+ right circumstances, was that the lock which we currently in the
+ process of attempting to acquire could "overwrite" the previous
+ lock which was acquired. While this does not in any way affect
+ typical operation, it *could* lead to misleading "core show
+ locks" output.
+
+2008-03-17 17:55 +0000 [r109171] Michiel van Baak <michiel at vanbaak.info>
+
+ * channels/chan_skinny.c: Update the directory of placed calls on
+ skinny phones when dialing a channel that does not provide
+ progress (analog ZAP lines) The phone does handle the double
+ update on calls to channels that do provide progress and wont
+ insert duplicate items (closes issue #12239) Reported by: DEA
+ Patches: chan_skinny-call-log.txt uploaded by DEA (license 3)
+
+2008-03-17 16:24 +0000 [r109107] Joshua Colp <jcolp at digium.com>
+
+ * channels/chan_sip.c: 200 OKs in response to a reinvite need to be
+ sent reliably. If the remote side does not receive one the dialog
+ will be torn down. (closes issue #12208) Reported by: atrash
+
+2008-03-17 15:15 +0000 [r109057] Jason Parker <jparker at digium.com>
+
+ * main/file.c: Backport revision 106439 from trunk. I didn't
+ realize this was broken in 1.4 as well. Closes issue #12222.
+
+2008-03-17 14:18 +0000 [r109012] Mark Michelson <mmichelson at digium.com>
+
+ * apps/app_chanspy.c: Make sure that we release the lock on the
+ spyee channel if the spyee or spy has hung up (closes issue
+ #12232) Reported by: atis
+
+2008-03-16 21:47 +0000 [r108961] Michiel van Baak <michiel at vanbaak.info>
+
+ * main/dial.c: add missing break to case AST_CONTROL_SRCUPDATE
+ (closes issue #12228) Reported by: andrew Patches: SRC.patch
+ uploaded by andrew (license 240)
+
+2008-03-14 20:09 +0000 [r108792-108796] Russell Bryant <russell at digium.com>
+
+ * channels/chan_oss.c: Fix a channel name issue. chan_oss registers
+ the "Console" channel type, but it created channels with an "OSS"
+ prefix. (closes issue #12194, reported by davidw, patched by me)
+
+ * contrib/init.d/rc.suse.asterisk: Update the SuSE init script to
+ start networking before asterisk, as well. (closes issue #12200,
+ reported by and change suggested by reinerotto)
+
+2008-03-14 16:44 +0000 [r108737] Mark Michelson <mmichelson at digium.com>
+
+ * channels/chan_sip.c: Fix a race condition in the SIP packet
+ scheduler which could cause a crash. chan_sip uses the scheduler
+ API in order to schedule retransmission of reliable packets (such
+ as INVITES). If a retransmission of a packet is occurring, then
+ the packet is removed from the scheduler and retrans_pkt is
+ called. Meanwhile, if a response is received from the packet as
+ previously transmitted, then when we ACK the response, we will
+ remove the packet from the scheduler and free the packet. The
+ problem is that both the ACK function and retrans_pkt attempt to
+ acquire the same lock at the beginning of the function call. This
+ means that if the ACK function acquires the lock first, then it
+ will free the packet which retrans_pkt is about to read from and
+ write to. The result is a crash. The solution: 1. If the ACK
+ function fails to remove the packet from the scheduler and the
+ retransmit id of the packet is not -1 (meaning that we have not
+ reached the maximum number of retransmissions) then release the
+ lock and yield so that retrans_pkt may acquire the lock and
+ operate. 2. Make absolutely certain that the ACK function does
+ not recursively lock the lock in question. If it does, then
+ releasing the lock will do no good, since retrans_pkt will still
+ be unable to acquire the lock. (closes issue #12098) Reported by:
+ wegbert (closes issue #12089) Reported by: PTorres Patches:
+ 12098-putnopvutv3.patch uploaded by putnopvut (license 60) Tested
+ by: jvandal
+
+2008-03-14 14:29 +0000 [r108682] Jason Parker <jparker at digium.com>
+
+ * res/res_musiconhold.c: Fix a potential segfault if chan (or
+ chan->music_state) is NULL. Closes issue #12210, credit to
+ edantie for pointing this out.
+
+2008-03-13 21:38 +0000 [r108469-108583] Russell Bryant <russell at digium.com>
+
+ * apps/app_chanspy.c, main/channel.c, include/asterisk/channel.h:
+ Fix another issue that was causing crashes in chanspy. This
+ introduces a new datastore callback, called chan_fixup(). The
+ concept is exactly like the fixup callback that is used in the
+ channel technology interface. This callback gets called when the
+ owning channel changes due to a masquerade. Before this was
+ introduced, if a masquerade happened on a channel being spyed on,
+ the channel pointer in the datastore became invalid. (closes
+ issue #12187) (reported by, and lots of testing from atis) (props
+ to file for the help with ideas)
+
+ * channels/chan_sip.c: Make a tweak that gets the LEDs on polycom
+ phones to blink when an extension that has been subscribed to
+ goes on hold. Otherwise, they just stay on like it does when an
+ extension is in use. (closes issue #11263) Reported by: russell
+ Patches: notify_hold.rev1.txt uploaded by russell (license 2)
+ Tested by: russell
+
+ * apps/app_followme.c: Fix a couple uses of sprintf. The second one
+ could actually cause an overflow of a stack buffer. It's not a
+ security issue though, it only depends on your configuration.
+
+2008-03-12 21:53 +0000 [r108227-108288] Mark Michelson <mmichelson at digium.com>
+
+ * channels/chan_sip.c: Change AST_SCHED_DEL use to ast_sched_del
+ for autocongestion in chan_sip. The scheduler callback will
+ always return 0. This means that this id is never rescheduled, so
+ it makes no sense to loop trying to delete the id from the
+ scheduler queue. If we fail to remove the item from the queue
+ once, it will fail every single time. (Yes I realize that in this
+ case, the macro would exit early because the id is set to -1 in
+ the callback, but it still makes no sense to use that macro in
+ favor of calling ast_sched_del once and being done with it) This
+ is the first of potentially several such fixes.
+
+ * include/asterisk/sched.h: Added a large comment before the
+ AST_SCHED_DEL macro to explain its purpose as well as when it is
+ appropriate and when it is not appropriate to use it. I also
+ removed the part of the debug message that mentions that this is
+ probably a bug because there are some perfectly legitimate places
+ where ast_sched_del may fail to delete an entry (e.g. when the
+ scheduler callback manually reschedules with a new id instead of
+ returning non-zero to tell the scheduler to reschedule with the
+ same idea). I also raised the debug level of the debug message in
+ AST_SCHED_DEL since it seems like it could come up quite
+ frequently since the macro is probably being used in several
+ places where it shouldn't be. Also removed the redundant line,
+ file, and function information since that is provided by ast_log.
+
+2008-03-12 19:57 +0000 [r108135] Russell Bryant <russell at digium.com>
+
+ * apps/app_chanspy.c, main/channel.c: (closes issue #12187,
+ reported by atis, fixed by me after some brainstorming on the
+ issue with mmichelson) - Update copyright info on app_chanspy. -
+ Fix a race condition that caused app_chanspy to crash. The issue
+ was that the chanspy datastore magic that was used to ensure that
+ spyee channels did not disappear out from under the code did not
+ completely solve the problem. It was actually possible for
+ chanspy to acquire a channel reference out of its datastore to a
+ channel that was in the middle of being destroyed. That was
+ because datastore destruction in ast_channel_free() was done near
+ the end. So, this left the code in app_chanspy accessing a
+ channel that was partially, or completely invalid because it was
+ in the process of being free'd by another thread. The following
+ sort of shows the code path where the race occurred:
+ =============================================================================
+ Thread 1 (PBX thread for spyee chan) || Thread 2 (chanspy)
+ --------------------------------------||-------------------------------------
+ ast_channel_free() || - remove channel from channel list || -
+ lock/unlock the channel to ensure || that no references retrieved
+ from || the channel list exist. ||
+ --------------------------------------||-------------------------------------
+ || channel_spy() - destroy some channel data || - Lock chanspy
+ datastore || - Retrieve reference to channel || - lock channel ||
+ - Unlock chanspy datastore
+ --------------------------------------||-------------------------------------
+ - destroy channel datastores || - call chanspy datastore d'tor ||
+ which NULL's out the ds' || - Operate on the channel ...
+ reference to the channel || || - free the channel || || || -
+ unlock the channel
+ --------------------------------------||-------------------------------------
+ =============================================================================
+
+2008-03-12 19:16 +0000 [r108086] Kevin P. Fleming <kpfleming at digium.com>
+
+ * channels/chan_sip.c: if we receive an INVITE with a
+ Content-Length that is not a valid number, or is zero, then don't
+ process the rest of the message body looking for an SDP closes
+ issue #11475 Reported by: andrebarbosa
+
+2008-03-12 18:26 +0000 [r108083] Joshua Colp <jcolp at digium.com>
+
+ * apps/app_mixmonitor.c, include/asterisk/audiohook.h,
+ main/audiohook.c: Add a trigger mode that triggers on both read
+ and write. The actual function that returns the combined audio
+ frame though will wait until both sides have fed in audio, or
+ until one side stops (such as the case when you call Wait).
+ (closes issue #11945) Reported by: xheliox
+
+2008-03-12 16:59 +0000 [r108031] Russell Bryant <russell at digium.com>
+
+ * main/channel.c: Destroy the channel lock after the channel
+ datastores. (inspired by issue #12187)
+
+2008-03-12 01:52 +0000 [r107877] Tilghman Lesher <tlesher at digium.com>
+
+ * contrib/scripts/iax-friends.sql, contrib/scripts/sip-friends.sql:
+ Document all of the possible realtime fields
+
+2008-03-11 23:37 +0000 [r107714-107826] Jason Parker <jparker at digium.com>
+
+ * doc/voicemail_odbc_postgresql.txt: Update documentation for pgsql
+ ODBC voicemail. (closes issue #12186) Reported by: jsmith
+ Patches: vm_pgsql_doc_update.patch uploaded by jsmith (license
+ 15)
+
+ * channels/chan_gtalk.c: Copy voicemail dependency logic for
+ res_adsi to chan_gtalk (for jabber). (closes issue #12014)
+ Reported by: junky
+
+2008-03-11 20:48 +0000 [r107713] Kevin P. Fleming <kpfleming at digium.com>
+
+ * Makefile.rules, channels/Makefile: get chan_vpb to build properly
+ in dev mode
+
+2008-03-11 20:47 +0000 [r107712] Jason Parker <jparker at digium.com>
+
+ * apps/app_voicemail.c: Add a newline on a log
+
+2008-03-11 19:20 +0000 [r107582-107646] Joshua Colp <jcolp at digium.com>
+
+ * res/res_features.c: Make sure the visible indication is on the
+ right channel so when the masquerade happens the proper
+ indication is enacted. (closes issue #11707) Reported by: iam
+
+ * apps/app_meetme.c: Add an additional check for setting conference
+ parameter when using the marked user options. It was possible for
+ it to return to a no listen/no talk state if a masquerade
+ happened. (closes issue #12136) Reported by: aragon
+
+ * apps/app_exec.c: Fix a minor spelling error. (closes issue
+ #12183) Reported by: darrylc
+
+2008-03-11 Russell Bryant <russell at digium.com>
+
+ * Asterisk 1.4.19-rc2 released.
+
+2008-03-11 15:18 +0000 [r107352-107472] Kevin P. Fleming <kpfleming at digium.com>
+
+ * apps/app_rpt.c: backport a fix from trunk
+
+ * channels/misdn/isdn_lib.c, codecs/Makefile,
+ channels/chan_misdn.c: fix various other problems found by gcc
+ 4.3
+
+ * configure, include/asterisk/autoconfig.h.in, configure.ac,
+ apps/app_sms.c: stop checking for mktime() in the configure
+ script... we don't use it, and the test is buggy under gcc 4.3
+
+ * configure, main/Makefile, configure.ac, makeopts.in: check for
+ compiler support for -fno-strict-overflow before using it (tested
+ with Debian's gcc 4.3, 4.1 and 3.4) (closes issue #12179)
+ Reported by: Netview
+
+ * configure, configure.ac: fix small bug in IMAP toolkit testing
+
+ * main/udptl.c, utils/Makefile, main/Makefile,
+ main/editline/readline.c, pbx/Makefile: fix up various compiler
+ warnings found with gcc-4.3: - the output of flex includes a
+ static function called 'input' that is not used, so for the
+ moment we'll stop having the compiler tell us about unused
+ variables in the flex source files (a better fix would be to
+ improve our flex post-processing to remove the unused function) -
+ main/stdtime/localtime.c makes assumptions about signed integer
+ overflow, and gcc-4.3's improved optimizer tries to take
+ advantage of handling potential overflow conditions at compile
+ time; for now, suppress these optimizations until we can fiure
+ out if the code needs improvement - main/udptl.c has some
+ references to uninitialized variables; in one case there was no
+ bug, but in the other it was certainly possibly for unexpected
+ behavior to occur - main/editline/readline.c had an unused
+ variable
+
+2008-03-11 00:59 +0000 [r107290] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_sip.c: If we fail to alloc a channel, we should
+ re-lock the pvt structure before returning.
+
+2008-03-10 21:32 +0000 [r107230] Tilghman Lesher <tlesher at digium.com>
+
+ * main/pbx.c: Use non-global storage for eswitch
+
+2008-03-10 20:27 +0000 [r107173] Jason Parker <jparker at digium.com>
+
+ * channels/chan_zap.c: Make sure to reenable echo can after a
+ "failed" (canceled, etc) three-way call. (closes issue #11335)
+ Reported by: rebuild
+
+2008-03-10 20:17 +0000 [r107099-107161] Russell Bryant <russell at digium.com>
+
+ * main/pbx.c: Fix another bug specifically related to asynchronous
+ call origination. Once the PBX is started on the channel using
+ ast_pbx_start(), then the ownership of the channel has been
+ passed on to another thread. We can no longer access it in this
+ code. If the channel gets hung up very quickly, it is possible
+ that we could access a channel that has been free'd. (inspired by
+ BE-386)
+
+ * main/pbx.c: Fix some bugs related to originating calls. If the
+ code failed to start a PBX on the channel (such as if you set a
+ call limit based on the system's load average), then there were
+ cases where a channel that has already been free'd using
+ ast_hangup() got accessed. This caused weird memory corruption
+ and crashes to occur. (fixes issue BE-386) (much debugging credit
+ goes to twilson, final patch written by me)
+
+ * main/channel.c: Resolve a compiler warning.
+
+ * main/channel.c: Fix a race condition where the generator can go
+ away (closes issue #12175, reported by edantie, patched by me)
+
+2008-03-10 14:33 +0000 [r107016] Joshua Colp <jcolp at digium.com>
+
+ * apps/app_dial.c, main/cdr.c, include/asterisk/cdr.h: Move where
+ unanswered CDRs are dropped to the CDR core, not everything uses
+ app_dial. (closes issue #11516) Reported by: ys Patches:
+ branch_1.4_cdr.diff uploaded by ys (license 281) Tested by:
+ anest, jcapp, dartvader
+
+2008-03-08 15:59 +0000 [r106945] Kevin P. Fleming <kpfleming at digium.com>
+
+ * channels/chan_zap.c: don't generate D-Channel "up" and "down"
+ messages unless the channel state is actually changing; also,
+ generate the "up" message when an implicit "up" occurs due to
+ reception of a normal event when we thought the channel was
+ "down"
+
+2008-03-07 22:51 +0000 [r106895] Russell Bryant <russell at digium.com>
+
+ * apps/app_meetme.c: Only start the SLA thread if SLA has actually
+ been configured.
+
+2008-03-07 22:14 +0000 [r106842] Jason Parker <jparker at digium.com>
+
+ * main/editline/Makefile.in: Fix hardcoded grep in editline, were
+ GNU grep is required. (closes issue #12124) Reported by: dmartin
+
+2008-03-07 19:32 +0000 [r106788] Joshua Colp <jcolp at digium.com>
+
+ * main/channel.c: Ignore source update control frame. (closes issue
+ #12168) Reported by: plack
+
+2008-03-07 17:16 +0000 [r106704] Russell Bryant <russell at digium.com>
+
+ * include/asterisk/sched.h: Change a warning message to a debug
+ message. This is happening quite frequently, and it is not worth
+ spamming users with these messages unless we are pretty confident
+ that it should never happen. As it stands today, it _will_ and
+ _does_ happen and until that gets cleaned up a reasonable amount
+ on the development side, let's not spam the logs of everyone
+ else. (closes issue #12154)
+
+2008-03-07 16:22 +0000 [r106552-106635] Tilghman Lesher <tlesher at digium.com>
+
+ * apps/app_voicemail.c: Warn the user when a temporary greeting
+ exists (Closes issue #11409)
+
+ * main/rtp.c: Properly initialize rtp->schedid (Closes issue
+ #12154)
+
+ * apps/app_chanspy.c, apps/app_rpt.c, main/asterisk.c,
+ apps/app_speech_utils.c, apps/app_voicemail.c, main/channel.c,
+ funcs/func_enum.c, channels/chan_misdn.c, main/frame.c,
+ main/manager.c: Safely use the strncat() function. (closes issue
+ #11958) Reported by: norman Patches: 20080209__bug11958.diff.txt
+ uploaded by Corydon76 (license 14)
+
+2008-03-06 22:10 +0000 [r106437] Mark Michelson <mmichelson at digium.com>
+
+ * main/pbx.c: Quell an annoying message that is likely to print
+ every single time that ast_pbx_outgoing_app is called. The reason
+ is that __ast_request_and_dial allocates the cdr for the channel,
+ so it should be expected that the channel will have a cdr on it.
+ Thanks to joetester on IRC for pointing this out
+
+2008-03-06 04:40 +0000 [r106328] Tilghman Lesher <tlesher at digium.com>
+
+ * sounds/Makefile: Upgrade to the next release of sounds
+
+2008-03-05 22:37 +0000 [r106237] Russell Bryant <russell at digium.com>
+
+ * channels/chan_iax2.c: Fix a potential deadlock and a few
+ different potential crashes. (closes issue #12145, reported by
+ thiagarcia, patched by me)
+
+2008-03-05 22:32 +0000 [r106235] Joshua Colp <jcolp at digium.com>
+
+ * channels/chan_oss.c, main/rtp.c, channels/chan_mgcp.c,
+ apps/app_dial.c, main/channel.c, channels/chan_phone.c,
+ main/dial.c, channels/chan_zap.c, channels/chan_sip.c,
+ channels/chan_skinny.c, channels/chan_h323.c, main/file.c,
+ channels/chan_alsa.c, apps/app_followme.c,
+ include/asterisk/frame.h: Add a control frame to indicate the
+ source of media has changed. Depending on the underlying
+ technology it may need to change some things. (closes issue
+ #12148) Reported by: jcomellas
+
+2008-03-05 21:12 +0000 [r106178] Michiel van Baak <michiel at vanbaak.info>
+
+ * doc/realtime.txt: document var_metric so no bugreports will come
+ in when it's actually a configuration issue. (issue #12151)
+ Reported and patched by: caio1982 1.4 patch by me
+
+2008-03-05 15:32 +0000 [r106038] Kevin P. Fleming <kpfleming at digium.com>
+
+ * channels/chan_zap.c: when a PRI call must be moved to a different
+ B channel at the request of the other endpoint, ensure that any
+ DSP active on the original channel is moved to the new one
+ (closes issue #11917) Reported by: mavetju Tested by: mavetju
+
+2008-03-05 15:17 +0000 [r106015] Tilghman Lesher <tlesher at digium.com>
+
+ * channels/chan_sip.c, include/asterisk/sched.h: Correctly
+ initialize retransid in SIP, and ensure that the warning when
+ failing to delete a schedule entry can actually hit the log.
+ (closes issue #12140) Reported by: slavon Patches: sch2.patch
+ uploaded by slavon (license 288) (Patch slightly modified by me)
+
+2008-03-05 01:52 +0000 [r105932] Russell Bryant <russell at digium.com>
+
+ * main/rtp.c, main/translate.c, include/asterisk/frame.h: Fix a bug
+ that I just noticed in the RTP code. The calculation for setting
+ the len field in an ast_frame of audio was wrong when G.722 is in
+ use. The len field represents the number of ms of audio that the
+ frame contains. It would have set the value to be twice what it
+ should be.
+
+2008-03-04 18:10 +0000 [r105674-105676] Joshua Colp <jcolp at digium.com>
+
+ * main/rtp.c: In addition to setting the marker bit let's change
+ our ssrc so they know for sure it is a different source.
+
+ * main/rtp.c, channels/chan_sip.c, include/asterisk/rtp.h: When a
+ new source of audio comes in (such as music on hold) make sure
+ the marker bit gets set. (closes issue #10355) Reported by:
+ wdecarne Patches: 10355.diff uploaded by file (license 11)
+ (closes issue #11491) Reported by: kanderson
+
+2008-03-04 Russell Bryant <russell at digium.com>
+
+ * Asterisk 1.4.19-rc1 released.
+
+2008-03-04 04:31 +0000 [r105591] Russell Bryant <russell at digium.com>
+
+ * main/pbx.c: Backport a minor bug fix from trunk that I found
+ while doing random code cleanup. Properly break out of the loop
+ when a context isn't found when verify that includes are valid.
+
+2008-03-03 18:06 +0000 [r105572] Jason Parker <jparker at digium.com>
+
+ * res/snmp/agent.c: Fix type for astNumChannels. (closes issue
+ #12114) Reported by: jeffg Patches: 12114.patch uploaded by jeffg
+ (license 192)
+
+2008-03-03 17:16 +0000 [r105563-105570] Russell Bryant <russell at digium.com>
+
+ * channels/chan_local.c: In the case of an ast_channel allocation
+ failure, take the local_pvt out of the pvt list before destroying
+ it.
+
+ * channels/chan_local.c: Fix a potential memory leak of the
+ local_pvt struct when ast_channel allocation fails. Also, in
+ passing, centralize the code necessary to destroy a local_pvt.
+
+ * main/autoservice.c: Update the copyright information for
+ autoservice. Most of the code in this file now is stuff that I
+ have written recently ...
+
+ * main/asterisk.c, main/channel.c, include/asterisk.h,
+ main/autoservice.c: Merge in some changes from
+ team/russell/autoservice-nochans-1.4 These changes fix up some
+ dubious code that I came across while auditing what happens in
+ the autoservice thread when there are no channels currently in
+ autoservice. 1) Change it so that autoservice thread doesn't keep
+ looping around calling ast_waitfor_n() on 0 channels twice a
+ second. Instead, use a thread condition so that the thread
+ properly goes to sleep and does not wake up until a channel is
+ put into autoservice. This actually fixes an interesting bug, as
+ well. If the autoservice thread is already running (almost always
+ is the case), then when the thread goes from having 0 channels to
+ have 1 channel to autoservice, that channel would have to wait
+ for up to 1/2 of a second to have the first frame read from it.
+ 2) Fix up the code in ast_waitfor_nandfds() for when it gets
+ called with no channels and no fds to poll() on, such as was the
+ case with the previous code for the autoservice thread. In this
+ case, the code would call alloca(0), and pass the result as the
+ first argument to poll(). In this case, the 2nd argument to
+ poll() specified that there were no fds, so this invalid pointer
+ shouldn't actually get dereferenced, but, this code makes it
+ explicit and ensures the pointers are NULL unless we have valid
+ data to put there. (related to issue #12116)
+
+2008-03-03 15:28 +0000 [r105557-105560] Joshua Colp <jcolp at digium.com>
+
+ * main/channel.c: It is possible for no audio to pass between the
+ current digit and next digit so expand logic that clears
+ emulation to AST_FRAME_NULL. (closes issue #11911) Reported by:
+ edgreenberg Patches: v1-11911.patch uploaded by dimas (license
+ 88) Tested by: tbsky
+
+ * channels/chan_sip.c: Add a comment to describe some logic.
+ (closes issue #12120) Reported by: flefoll Patches:
+ chan_sip.c.br14.patch-just-a-comment uploaded by flefoll (license
+ 244)
+
+2008-02-29 23:34 +0000 [r105409] Russell Bryant <russell at digium.com>
+
+ * main/autoservice.c: Fix a major bug in autoservice. There was a
+ race condition in the handling of the list of channels in
+ autoservice. The problem was that it was possible for a channel
+ to get removed from autoservice and destroyed, while the
+ autoservice thread was still messing with the channel. This led
+ to memory corruption, and caused crashes. This explains multiple
+ backtraces I have seen that have references to autoservice, but
+ do to the nature of the issue (memory corruption), could cause
+ crashes in a number of areas. (fixes the crash in BE-386) (closes
+ issue #11694) (closes issue #11940) The following issues could be
+ related. If you are the reporter of one of these, please update
+ to include this fix and try again. (potentially fixes issue
+ #11189) (potentially fixes issue #12107) (potentially fixes issue
+ #11573) (potentially fixes issue #12008) (potentially fixes issue
+ #11189) (potentially fixes issue #11993) (potentially fixes issue
+ #11791)
+
+2008-02-29 14:47 +0000 [r105326] Philippe Sultan <philippe.sultan at gmail.com>
+
+ * res/res_jabber.c: Fix a potential memory leak
+
+2008-02-29 14:34 +0000 [r105296] Tilghman Lesher <tlesher at digium.com>
+
+ * apps/app_voicemail.c: If the message file does not exist, just
+ return harmlessly, instead of crashing. (Closes issue #12108)
+
+2008-02-29 13:48 +0000 [r105261] Joshua Colp <jcolp at digium.com>
+
+ * apps/app_voicemail.c: Bump up the size of the uniqueid variable.
+ (closes issue #12107) Reported by: asgaroth
+
+2008-02-29 13:05 +0000 [r105209] Philippe Sultan <philippe.sultan at gmail.com>
+
+ * res/res_jabber.c: Automatically create new buddy upon reception
+ of a presence stanza of type subscribed. (closes issue #12066)
+ Reported by: ffadaie Patches: branch-1.4-12066-1.diff uploaded by
+ phsultan (license 73) trunk-12066-1.diff uploaded by phsultan
+ (license 73) Tested by: ffadaie, phsultan
+
+2008-02-28 22:23 +0000 [r105116] Russell Bryant <russell at digium.com>
+
+ * main/utils.c, include/asterisk/lock.h: Fix a bug in the lock
+ tracking code that was discovered by mmichelson. The issue is
+ that if the lock history array was full, then the functions to
+ mark a lock as acquired or not would adjust the stats for
+ whatever lock is at the end of the array, which may not be
+ itself. So, do a sanity check to make sure that we're updating
+ lock info for the proper lock. (This explains the bizarre stats
+ on lock #63 in BE-396, thanks Mark!)
+
+2008-02-28 21:56 +0000 [r105113] Tilghman Lesher <tlesher at digium.com>
+
+ * contrib/init.d/rc.debian.asterisk: Update init script for LSB
+ compat (closes issue #9843) Reported by: ibc Patches:
+ rc.debian.asterisk.patch uploaded by ibc (license 211) Tested by:
+ paravoid
+
+2008-02-28 20:11 +0000 [r105059] Mark Michelson <mmichelson at digium.com>
+
+ * apps/app_queue.c: When using autofill, members who are in use
+ should be counted towards the number of available members to call
+ if ringinuse is set to yes. Thanks to jmls who brought this issue
+ up on IRC
+
+2008-02-28 19:20 +0000 [r104920-105005] Jason Parker <jparker at digium.com>
+
+ * main/cdr.c, main/pbx.c: Make pbx_exec pass an empty string into
+ applications, if we get NULL. This protects against possible
+ segfaults in applications that may try to use data before
+ checking length (ast_strdupa'ing it, for example) (closes issue
+ #12100) Reported by: foxfire Patches: 12100-nullappargs.diff
+ uploaded by qwell (license 4)
+
+ * channels/chan_skinny.c: According to a video at www.cisco.com,
+ the 7921G supports 6 line appearances.
+
+2008-02-28 00:05 +0000 [r104868] Tilghman Lesher <tlesher at digium.com>
+
+ * main/Makefile, build_tools/strip_nonapi: Compatibility fix for
+ PPC64 (closes issue #12081) Reported by: jcollie Patches:
+ asterisk-1.4.18-funcdesc.patch uploaded by jcollie (license 412)
+ Tested by: jcollie, Corydon76
+
+2008-02-27 21:49 +0000 [r104841] Mark Michelson <mmichelson at digium.com>
+
+ * main/dial.c: Two fixes: 1. Make the list of ast_dial_channels a
+ lockable list. This is because in some cases, the ast_dial may
+ exist in multiple threads due to asynchronous execution of its
+ application, and I found some cases where race conditions could
+ exist. 2. Check in ast_dial_join to be sure that the channel
+ still exists before attempting to lock it, since it could have
+ gotten hung up but the is_running_app flag on the
+ ast_dial_channel may not have been cleared yet. (closes issue
+ #12038) Reported by: jvandal Patches: 12038v2.patch uploaded by
+ putnopvut (license 60) Tested by: jvandal
+
+2008-02-27 20:56 +0000 [r104787] Joshua Colp <jcolp at digium.com>
+
+ * apps/app_chanspy.c: Don't loop around infinitely trying to spy on
+ our own channel, and don't forget to free/detach the datastore
+ upon hangup of the spy.
+
+2008-02-27 20:36 +0000 [r104783] Mark Michelson <mmichelson at digium.com>
+
+ * main/file.c: Bump a couple of more buffers up by 2 so that
+ annoying warnings aren't generated like crazy on every
+ fileexists_core call.
+
+2008-02-27 18:15 +0000 [r104704] Tilghman Lesher <tlesher at digium.com>
+
+ * main/manager.c: Ensure the session ID can't be 0.
+
+2008-02-27 17:41 +0000 [r104665] Joshua Colp <jcolp at digium.com>
+
+ * main/file.c: Bump up the buffer by 2.
+
+2008-02-27 17:33 +0000 [r104625] Russell Bryant <russell at digium.com>
+
+ * apps/app_chanspy.c: Fix a problem in ChanSpy where it could get
+ stuck in an infinite loop without being able to detect that the
+ calling channel hung up. (closes issue #12076, reported by junky,
+ patched by me)
+
+2008-02-27 17:26 +0000 [r104598] Jason Parker <jparker at digium.com>
+
+ * res/res_features.c: Inherit language from the transfering channel
+ on a blind transfer. (closes issue #11682) Reported by: caio1982
+ Patches: local_atxfer_lang3-1.4.diff uploaded by caio1982
+ (license 22) Tested by: caio1982, victoryure
+
+2008-02-27 17:07 +0000 [r104596] Joshua Colp <jcolp at digium.com>
+
+ * main/loader.c: Use the lock (which already existed, it just
+ wasn't used) on the updaters list to protect the contents instead
+ of the overall module list lock. (closes issue #12080) Reported
+ by: ChaseVenters
+
+2008-02-27 16:53 +0000 [r104593] Kevin P. Fleming <kpfleming at digium.com>
+
+ * main/file.c: fallback to standard English prompts properly when
+ using new prompt directory layout (closes issue #11831) Reported
+ by: IgorG Patches: fallbacken.v1.diff uploaded by IgorG (license
+ 20) (modified by me to improve code and conform rest of function
+ to coding guidelines)
+
+2008-02-27 16:45 +0000 [r104591] Russell Bryant <russell at digium.com>
+
+ * channels/chan_zap.c: When we receive a known alarm, make sure
+ that the unknown alarm flag is not still set to make sure that
+ when we come back out of alarm, it gets reported in the log and
+ manager interface (after discussion with tzafrir on the -dev
+ list)
+
+2008-02-27 15:52 +0000 [r104536] Joshua Colp <jcolp at digium.com>
+
+ * res/res_smdi.c: Only stop the MWI monitor thread if it was
+ actually started. (closes issue #12086) Reported by: francesco_r
+
+2008-02-27 01:15 +0000 [r104332-104334] Russell Bryant <russell at digium.com>
+
+ * apps/app_chanspy.c: Avoid some recursion in the cleanup code for
+ the chanspy datastore (closes issue #12076, reported by junky,
+ patched by me)
+
+ * channels/chan_zap.c: Zaptel 1.4 now exposes FXO battery state as
+ an alarm. However, Asterisk 1.4 does not know what to do with
+ these alarms. Only Asterisk 1.6 cares about it. So, if we get an
+ unknown alarm in chan_zap, don't generate confusing log messages
+ about it.
+
+2008-02-26 18:26 +0000 [r104132-104141] Jason Parker <jparker at digium.com>
+
+ * Makefile: Add badshell to .PHONY target (thanks Kevin)
+
+ * Makefile: Since all shells aren't as awesome as bash, we have to
+ fail if somebody tries to use a literal "~" in DESTDIR.
+
+ * sounds/Makefile: Revert previous abspath change. ...abspath is
+ new in GNU make 3.81. I feel so...defeated. Must find new fix!
+
+ * sounds/Makefile: Fix a very bizarre issue we were seeing with our
+ buildbot when using a DESTDIR that wasn't an absolute path (such
+ as DESTDIR=~/asterisk-1.4). Apparently what was happening, was
+ that some of the targets were being expanded to the full path, so
+ $@ ended up being /root/asterisk-1.4/[...]/ rather than
+ ~/asterisk-1.4/[...]/ It appears that this may be a new "feature"
+ in GNU make. (*cough*
+ http://en.wikipedia.org/wiki/Principle_of_least_surprise *cough*)
+
+2008-02-26 00:25 +0000 [r104119] Russell Bryant <russell at digium.com>
+
+ * include/asterisk/smdi.h, apps/app_voicemail.c,
+ channels/chan_zap.c, res/res_smdi.c, configs/smdi.conf.sample:
+ Merge changes from team/russell/smdi-1.4 This commit brings in a
+ significant set of changes to the SMDI support in Asterisk. There
+ were a number of bugs in the current implementation, most notably
+ being that it was very likely on busy systems to pop off the
+ wrong message from the SMDI message queue. So, this set of
+ changes fixes the issues discovered as well as introducing some
+ new ways to use the SMDI support which are required to avoid the
+ bugs with grabbing the wrong message off of the queue. This code
+ introduces a new interface to SMDI, with two dialplan functions.
+ First, you get an SMDI message in the dialplan using
+ SMDI_MSG_RETRIEVE() and then you access details in the message
+ using the SMDI_MSG() function. A side benefit of this is that it
+ now supports more than just chan_zap. For example, with this
+ implementation, you can have some FXO lines being terminated on a
+ SIP gateway, but the SMDI link in Asterisk. Another issue with
+ the current implementation is that it is quite common that the
+ station ID that comes in on the SMDI link is not necessarily the
+ same as the Asterisk voicemail box. There are now additional
+ directives in the smdi.conf configuration file which let you map
+ SMDI station IDs to Asterisk voicemail boxes. Yet another issue
+ with the current SMDI support was related to MWI reporting over
+ the SMDI link. The current code could only report a MWI change
+ when the change was made by someone calling into voicemail. If
+ the change was made by some other entity (such as with IMAP
+ storage, or with a web interface of some kind), then the MWI
+ change would never be sent. The SMDI module can now poll for MWI
+ changes if configured to do so. This work was inspired by and
+ primarily done for the University of Pennsylvania. (also related
[... 15929 lines stripped ...]
More information about the asterisk-commits
mailing list