https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109908 | murf | 2008-03-19 09:41:13 -0600 (Wed, 19 Mar 2008) | 72 lines

(closes issue #11442)
Reported by: tzafrir
Patches:
      11442.patch uploaded by murf (license 17)
Tested by: murf

I didn't give tzafrir very much time to test this, but if he does 
still have remaining issues, he is welcome to 
re-open this bug, and we'll do what is called for.

I reproduced the problem, and tested the fix, so I hope I
am not jumping by just going ahead and committing the fix.

The problem was with what file_save does with templates; 
firstly, it tended to print out multiple options:

[my_category](!)(templateref)

instead of 

[my_category](!,templateref)

which is fixed by this patch.


Nextly, the code to suppress output of duplicate declarations
that would occur because the reader copies inherited declarations
down the hierarchy, was not working. Thus:


 [master-template](!)
 mastervar = bar


 [template](!,master-template)
 tvar = value


 [cat](template)
 catvar = val


would be rewritten as:

 ;!
 ;! Automatically generated configuration file
 ;! Filename: experiment.conf (/etc/asterisk/experiment.conf)
 ;! Generator: Manager
 ;! Creation Date: Tue Mar 18 23:17:46 2008
 ;!
 
 [master-template](!)
 mastervar = bar

 
 [template](!,master-template)
 mastervar = bar
 tvar = value

 
 [cat](template)
 mastervar = bar
 tvar = value
 catvar = val

This has been fixed. Since the config reader 'explodes' inherited
vars into the category, users may, in certain circumstances, see
output different from what they originally entered, but it should
be both correct and equivalent.



........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109942 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109926 65c4cc65-6c06-0410-ace0-fbb531ad65f3

actually implement HTTP request dispatching based on both URI and method; reduce duplication of data when generating responses using ast_http_error()


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109912 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Fix some more breakage that I introduced when changing extension state callbacks to the list macros.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109910 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109909 65c4cc65-6c06-0410-ace0-fbb531ad65f3

because I always compile without optimizations turned on.  Sorry!


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109907 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109883 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109842 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109841 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109838 | russell | 2008-03-18 23:06:05 -0500 (Tue, 18 Mar 2008) | 2 lines

Tweak spacing in a recent change because I'm very picky.

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109839 65c4cc65-6c06-0410-ace0-fbb531ad65f3

double free'd.  (reported by dhubbard directly to me)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109833 65c4cc65-6c06-0410-ace0-fbb531ad65f3

by Juggie while attempting to load chan_zap. Apparently this would happen
if an error were encountered while trying to process zapata.conf.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109802 65c4cc65-6c06-0410-ace0-fbb531ad65f3

instead of trying to piece it together, badly.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109775 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109763 | russell | 2008-03-18 17:34:42 -0500 (Tue, 18 Mar 2008) | 3 lines

Fix one place where the chanspy datastore isn't removed from a channel.
(issue #12243, reported by atis, patch by me)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109764 65c4cc65-6c06-0410-ace0-fbb531ad65f3

start the process of changing HTTP request dispatching to do it based on *both* URI and method, so that POST support can move into a module; move http.c's private function prototypes into _private.h


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109762 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109713 | mmichelson | 2008-03-18 15:52:15 -0500 (Tue, 18 Mar 2008) | 12 lines

This patch makes it so that all queue member status changes are handled through device state
code. This removes several problems people were seeing where their queue members would get into
an "unknown" state. Huge props go to atis on this one since he was the one who found the code
section that was causing the problem and proposed the solution. I just wrote what he suggested :)

(closes issue #12127)
Reported by: atis
Patches:
      12127v3.patch uploaded by putnopvut (license 60)
Tested by: atis, jvandal


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109714 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #12211, closes issue #12209)
 Reported by: sylvain


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109683 65c4cc65-6c06-0410-ace0-fbb531ad65f3

if the string is zero-length, but also if the data field is non-null.

(closes issue #12250)
Reported by: caio1982



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109681 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109680 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109648 | qwell | 2008-03-18 14:23:44 -0500 (Tue, 18 Mar 2008) | 7 lines

Allow codecs that use log2comp (g726) to compile correctly on x86 with gcc4 optimizations.

(closes issue #12253)
Reported by: fossil
Patches:
      log2comp.patch uploaded by fossil (license 140)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109651 65c4cc65-6c06-0410-ace0-fbb531ad65f3

allow the list of periodic announcments specified to be played in a random
order instead of being played sequentially.

(closes issue #6681)
Reported by: alt_phil
Tested by: putnopvut



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109621 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109575 | mmichelson | 2008-03-18 12:58:11 -0500 (Tue, 18 Mar 2008) | 6 lines

Make sure an agent doesn't try to send dtmf to a NULL channel

closes issue #12242
Reported by Yourname


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109576 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109545 65c4cc65-6c06-0410-ace0-fbb531ad65f3

fix up various warnings found via the addition of format string checking... some of these were really, really bad code


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109475 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109451 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Go through and fix a bunch of places where character strings were being interpreted as format strings. Most of these changes are solely to make compiling with -Wsecurity and -Wformat=2 happy, and were not
actual problems, per se.  I also added format attributes to any printf wrapper functions I found that didn't have them.  -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109447 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(AST-2008-004)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109396 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109394 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109386 | file | 2008-03-18 11:58:39 -0300 (Tue, 18 Mar 2008) | 3 lines

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)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109390 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(AST-2008-003)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109389 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109309 | murf | 2008-03-18 00:37:15 -0600 (Tue, 18 Mar 2008) | 17 lines

(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.



........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109357 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #11959)
Reported by: mostyn
Patches: 
      peerstatus3.patch uploaded by mostyn (license 398)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109316 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109282 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Replace minimime with superior GMime library so that the entire contents of an http post are not read into memory.
This does introduce a dependency on the GMime library for handling HTTP POSTs, but it is available in most distros.

If the library is present, then the compile flag for ENABLE_UPLOADS is enabled by default in menuselect.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109229 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109226 | mmichelson | 2008-03-17 17:05:49 -0500 (Mon, 17 Mar 2008) | 12 lines

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.



........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109227 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109172 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Reported by: mvanbaak
Tested by: murf, mvanbaak

Due to a bug that occurred when merge_contexts_and_delete scanned the "old" or existing contexts, and found a context
that doesn't exist in the new set, yet owned by a different registrar. The context is created in the new set, with the
old registrar, and and all the priorities and extens that have a different registrar are copied into it. But, not the
includes, ignorepats, and switches. I added code to do this immediately after the context is created.

This still leaves a logical hole in the code. If you define a context in two places, (eg. in extensions.conf and also 
in extensions.ael), and they both have includes, but different in composition, no new context will be generated, and
therefore the 'old' includes, switches, and ignorepats will not be copied. I'd have added code to simply add any non-duplicates
into the 'new' context that had a different registrar, but there is one big complication: includes, and switches are definitely
order dependent. (ignorepats I'm not sure about). And we'll have to develop some sort of policy about how we 
merge order dependent lists, especially if the intersection of the two sets is empty. (in other words, they do not have any
elements in common). Do the new go first, or the old? I've elected to punt this issue until a user complains. Hopefully,
this is pretty rare thing.




git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109169 65c4cc65-6c06-0410-ace0-fbb531ad65f3

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)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109168 65c4cc65-6c06-0410-ace0-fbb531ad65f3

don't define Zaptel features as libraries, they aren't, and we don't want '--with-zaptel-<foo>' configure options for them
also some minor cleanups


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109166 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109113 65c4cc65-6c06-0410-ace0-fbb531ad65f3