today on another mac. We ignore the return value of locking operations almost
everywhere in Asterisk. So, ignore these, as well, so Asterisk will actually
work on systems where this is occurring while I look into what the issue is.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100465 | tilghman | 2008-01-27 15:59:53 -0600 (Sun, 27 Jan 2008) | 11 lines
When deleting a task from the scheduler, ignoring the return value could
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption. Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue #11386)
Reported by: flujan
Patches:
20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
as a channel variable BRIDGEPVTCALLID
This is important for call tracing in log files and CDRs, so that
the SIP callID can be traced along servers.
The CHANNEL dialplan function won't work here, since the outbound
channel is gone when we need the Call-ID.
Other channel drivers may now implement the same function :-),
but this patch only supports chan_sip.so.
Inspired by (issue #11816)
Reported by: ctooley
Patch by oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99540 | tilghman | 2008-01-22 10:54:06 -0600 (Tue, 22 Jan 2008) | 7 lines
Ensure that we can get an address even when we don't have a default route.
(closes issue #9225)
Reported by: junky
Patches:
20080122__bug9225.diff.txt uploaded by Corydon76 (license 14)
Tested by: oej, loloski, sergee
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes introduces TCP and TLS support for chan_sip. There are various
new options in configs/sip.conf.sample that are used to enable these features. Also,
there is a document, doc/siptls.txt that describes some things in more detail.
This code was implemented by Brett Bryant and James Golovich. It was reviewed
by Joshua Colp and myself. A number of other people participated in the testing
of this code, but since it was done outside of the bug tracker, I do not have their
names. If you were one of them, thanks a lot for the help!
(closes issue #4903, but with completely different code that what exists there.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99081 | russell | 2008-01-18 15:37:21 -0600 (Fri, 18 Jan 2008) | 9 lines
Revert adding the packed attribute, as it really doesn't make sense why that
would do any good. Fix the real bug, which is to do the check to see if the
frame came from a translator at the beginning of ast_frame_free(), instead of
at the end. This ensures that it always gets checked, even if none of the
parts of the frame are malloc'd, and also ensures that we aren't looking at
free'd memory in the case that it is a malloc'd frame.
(closes issue #11792, reported by explidous, patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99004 | russell | 2008-01-17 16:37:22 -0600 (Thu, 17 Jan 2008) | 10 lines
Have IAX2 optimize the codec translation path just like chan_sip does it. If
the caller's codec is in our codec list, move it to the top to avoid transcoding.
(closes issue #10500)
Reported by: stevedavies
Patches:
iax-prefer-current-codec.patch uploaded by stevedavies (license 184)
iax-prefer-current-codec.1.4.patch uploaded by stevedavies (license 184)
Tested by: stevedavies, pj, sheldonh
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
immediately at startup. Any commands in the startup_commands file in the Asterisk
config diretory will get executed.
(closes issue #11781)
Reported by: jamesgolovich
Patches:
asterisk-startupcmds.diff.txt uploaded by jamesgolovich (license 176)
-- With some changes by me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98986 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines
Commit a fix for some memory access errors pointed out by the valgrind2.txt
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98325 | file | 2008-01-11 15:51:10 -0400 (Fri, 11 Jan 2008) | 6 lines
If the incoming RTP stream changes codec force the bridge to break if the other side does not support it.
(closes issue #11729)
Reported by: tsearle
Patches:
new_codec_patch_udiff.patch uploaded by tsearle (license 373)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sample length with g722. It is _2_ samples per byte, not 1. This was all
over the place, and I believed it, and it is what caused me to take so long
to figure out what was broken.
- Update copyright information on codec_g722.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fix was made in favor of the proposed patch since it doesn't involve changing
a core codec define.
(closes issue #11722, reported and initially patched by caio1982, final patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r97973 | tilghman | 2008-01-10 17:08:36 -0600 (Thu, 10 Jan 2008) | 6 lines
1) When we get a translated frame out, clone it, because if the
translator pvt is freed before we use the frame, bad things happen.
2) Getting a failure from ast_sched_delete means that the schedule
ID is currently running. Don't just ignore it.
(Closes issue #11698)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r97849 | murf | 2008-01-10 13:21:27 -0700 (Thu, 10 Jan 2008) | 1 line
This is a fix for 2 things: a problem Terry was having in OSX with null pointers, which was my fault, as I probably forgot to run the sed script last time I made mods. So, I moved the fix into the flex input itself. Then, I found when I used flex 2.5.33, that it was using __STDC_VERSION__, and that's not real good; so I added back in a DIFFERENT sed script to fix that little mess. Tested everything, a couple different ways. Hope I did no harm, at the least.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Add the Dialplan class, for NewExten and VarSet events, which should cut
down on the volume of traffic in the Call class.
2) Permit some commands to be run from multiple classes, such as allowing
DBGet to be run from either the System or the Reporting class.
3) Heavily document each class in the sample config, as there were several
that made no sense to be in the write= line, and two that made no sense to be
in the read= line (since they controlled no permissions there).
(Closes issue #10386)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
based on configuration templates that use Asterisk dialplan function and
variable substitution. It should be possible to create phone profiles and
templates that work for the majority of phones provisioned over http. It
is currently only intended to provision a single user account per phone.
An example profile and set of templates for Polycom phones is provided.
NOTE: Polycom firmware is not included, but should be placed in
AST_DATA_DIR/phoneprov/configs to match up with the included templates.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
revision changed, every module that used the version was getting rebuilt after
every svn update. This severly annoyed me pretty quickly, so I have improved
the situation.
Now, instead of generating version.h, main/version.c is generated. version.c
includes the version information, as well as a couple of API calls for modules
to retrieve the version. So now, only version.c will get rebuilt, and the main
asterisk binary relinked, which is must faster than rebuilding http.c, manager.c,
asterisk.c, relinking the asterisk binary, chan_sip.c, func_version.c, res_agi ...
The only minor change in behavior here is that the version information reported by
chan_sip, for example, is the version of the Asterisk core, and not necessarily the
Asterisk version that the chan_sip module came from.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@96717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r96575 | tilghman | 2008-01-04 17:03:40 -0600 (Fri, 04 Jan 2008) | 7 lines
Fix the problem of notification of a device state change to a device with a '-'
in the name. Could probably do with a better fix in trunk, but this bug has
been open way too long without a better solution.
Reported by: stevedavies
Patch by: tilghman
(Closes issue #9668)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@96576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
not work for everyone, but it did for some. This set of changes makes trunk
start again for those having problems. Instead of building libresample as a
static library, it just links the object files in directly with the asterisk
binary.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
gdb dying while debugging asterisk. The problem seems to be related
with a race in the handling of module_list, which in turn is triggeded
by calling dlopen() on a system which uses initializers to create
locks.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_resample, and mark codec_resample as dependent upon res_resample. This
prevents the linker from optimizing away libresample, and also makes it so the
libresample code isn't linked in to multiple places. (I have another module
in a branch that needs it, too.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r95577 | mmichelson | 2007-12-31 17:43:13 -0600 (Mon, 31 Dec 2007) | 9 lines
Avoiding a potentially bad locking situation. ast_merge_contexts_and_delete writelocks the conlock, then
calls ast_hint_extension, which attempts to readlock the same lock. Recursion with read-write locks is
dangerous, so the inner lock needs to be removed. I did this by copying the "guts" of ast_hint_extension
into ast_merge_contexts_and_delete (sans the extra lock).
(this change is inspired by the locking problems seen in issue #11080, but I have no idea if this is the
problematic area experienced by the reporters of that issue)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit imports libresample for use in Asterisk. It also adds a new codec
module, codec_resample. This module uses libresample to re-sample signed linear
audio between 8 kHz and 16 kHz.
It also provides an alternative for converting between 16 kHz G.722 and 8 kHz
signed linear when using G.722, which will likely be useful as some people have
complained about volume issues when the current codec_g722 converts to 8 kHz
signed linear. But, to test this, you will have to disable the g722-to-slin and
g722-to-slin16 translators in codec_g722.c.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r95024 | russell | 2007-12-27 15:40:02 -0600 (Thu, 27 Dec 2007) | 9 lines
Don't report a syntax error when an empty string is passed to ast_get_group.
Just return 0.
(closes issue #11540)
Reported by: tzafrir
Patches:
group_empty.diff uploaded by tzafrir (license 46)
-- slightly changed by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95025 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94828 | russell | 2007-12-27 08:33:21 -0600 (Thu, 27 Dec 2007) | 9 lines
Change ast_translator_best_choice() to only pay attention to audio formats.
This fixes a problem where Asterisk claims that a translation path can not be
found for channels involving video.
(closes issue #11638)
Reported by: cwhuang
Tested by: cwhuang
Patch suggested by cwhuang, with some additional changes by me.
........
r94829 | russell | 2007-12-27 08:44:29 -0600 (Thu, 27 Dec 2007) | 2 lines
Use the constant that I really meant to use here ...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94801 | russell | 2007-12-26 13:04:31 -0600 (Wed, 26 Dec 2007) | 4 lines
Just in case the AST_FLAG_END_DTMF_ONLY flag was already set before starting
autoservice, remember it and ensure that the channel has the same setting when
autoservice gets stopped. (pointed out by d1mas, patched up by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94797 | russell | 2007-12-26 12:46:39 -0600 (Wed, 26 Dec 2007) | 4 lines
When a channel is in autoservice, mark a flag on the channel that says that
we only care about the END of a digit. That way, no magic digit emulation stuff
will happen when all we're doing is queueing up END frames.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94790 | russell | 2007-12-26 11:06:26 -0600 (Wed, 26 Dec 2007) | 5 lines
Don't store DTMF BEGIN frames while a channel is in autoservice. It's just
going to make ast_read() do a lot of extra work when the channel comes back
out of autoservice.
(closes issue #11628, patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94767 | tilghman | 2007-12-24 13:36:59 -0600 (Mon, 24 Dec 2007) | 5 lines
Race: we need to wait to queue a NewChannel event until after the channel is
inserted into the channel list. The reason is because some manager users
immediately queue requests from the channel when they see that event and are
confused when Asterisk reports no such channel. (Closes issue #11632)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r94468 | mmichelson | 2007-12-21 10:49:35 -0600 (Fri, 21 Dec 2007) | 6 lines
Since we are freeing list elements within a list traversal, we need to use the safe
traversal and remove the item from the list before freeing it.
(closes issue 11612, reported by dtyoo)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
so that paths and filename are writable by asterisk.c without
causing segfaults.
This involves defining the variables as const char *,
and having them point to as static, writable buffer
defined in asterisk.c
On passing, fix some errors in using these variables
in some files in utils/ , and in res/snmp/agent.c
which was redefining a variable without using paths.h
(not applicable to 1.4)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@94168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and likely in other places too.
This is quite useful when placing mail/html stuff in config files.
/*!
\brief Convert some C escape sequences (\b\f\n\r\t) into the
equivalent characters.
\brief s The string to be converted (will be modified).
\return The converted string.
*/
char *ast_unescape_c(char *s);
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk goes into a busy loop, the machine will be recoverable. We'd still
need to do a restart to put Asterisk back into high priority mode, but at
least a reboot won't be required. (Closes issue #11559)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93625 | mmichelson | 2007-12-18 11:02:48 -0600 (Tue, 18 Dec 2007) | 6 lines
Rework deadlock avoidance used in ast_write, since it meant that agent channels which were being monitored
had one audio file recorded and one empty audio file saved.
(closes issue #11529, reported by atis patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
modified.
This requires casting the strings in asterisk.c when writing to
them, so we do it through a macro to do it consistently.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
globally visible.
Document the fact that DEFAULT_TMP_DIR cannot be overridden
from the default configuration (this needs to be fixed, as you
could have a totally different spooldir configured at runtime,
and yet DEFAULT_TMP_DIR keeps the compile-time default).
Remove two unused entries for sounds and images.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93377 | file | 2007-12-17 18:28:09 -0400 (Mon, 17 Dec 2007) | 7 lines
Do not try to access information about a lock when printing out a trylock attempt. It is possible for the lock that it references to no longer be valid. This would have caused segfaults or deadlocks.
(issue #BE-263)
(closes issue #11080)
Reported by: callguy
(closes issue #11100)
Reported by: callguy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
you need to reload after changes. Thanks YS.
Reported by: ys
Patches:
trunk93163_manager_reload.c.diff uploaded by ys (license 281)
(related to issue #11414)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
manager realtime implementation.
If you change accounts in manager.conf, you now need to reload to activate the
changes (deletions, additions). This was not the case with 1.4.
Reported by: ys
Patches:
trunk93163_manager_reload.c.diff uploaded by ys (license 281)
(closes issue #11414)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Refer to the proper documentation
- Implement separate signalling/media QoS/CoS in many channels using RTP
- Improve warnings and verbose messages
- Deprecate some old settings
Minor modifications by me, a big effort from IgorG.
Thanks!
Reported by: IgorG
Patches:
qoscleanup-89394-4-trunk.patch uploaded by IgorG (license 20)
Tested by: IgorG
(closes issue #11145)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
equivalent to the check done by ast_verb, I wrote a macro, VERBOSITY_LEVEL, which does this
check. I did a quick look in the source and used this macro in some places where option_verbose
was used.
I also converted some verbose messages in logger.c to use ast_verb instead of ast_verbose.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10690)
........
r92696 | qwell | 2007-12-12 18:11:09 -0600 (Wed, 12 Dec 2007) | 7 lines
If a typo is found in a config file, we previous continued on with what was already loaded.
We do not want to do this (see bug below for details).
This makes it so that if a [ is found without a ], the entire config will fail, and nothing in it will be loaded.
Issue 10690.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
get_unaligned functions as const
* In event.c, use get_unaligned_uint32() in a couple of places to fix issues on
architectures that don't allow unaligned access
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r92204 | file | 2007-12-10 12:36:15 -0400 (Mon, 10 Dec 2007) | 6 lines
Add G729A as another possible payload name for G729. Some devices use this instead of G729, which is perfectly normal since the payload number itself is defined and can't be used by anything else so the name doesn't matter that much.
(closes issue #11483)
Reported by: revolution
Patches:
rtp.diff uploaded by revolution (license 346)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91830 | russell | 2007-12-07 15:24:33 -0600 (Fri, 07 Dec 2007) | 5 lines
Make the lock protecting each thread's list of locks it currently holds
recursive. I think that this will fix the situation where some people have
said that "core show locks" locks up the CLI.
(related to issue #11080)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91777 | russell | 2007-12-07 10:08:35 -0600 (Fri, 07 Dec 2007) | 6 lines
* Add a bit more of a verbose comment as to why a hangup frame needs to be
queued up if autoservice gets a NULL return from ast_read().
* Make the process of queueing the hangup frame more efficient by putting the
frame where it is going to end up and avoiding some locking and extra memory
allocations and freeing.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91737 | mmichelson | 2007-12-07 09:39:58 -0600 (Fri, 07 Dec 2007) | 7 lines
Hangups that happen during autoservice were not processed appropriately. This is
because a hangup actually causes a NULL frame to be received, not a hangup frame.
Queueing a hangup if we receive a NULL frame during autoservice corrects this problem
(closes issue #11467, reported by jmls, patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91450 | file | 2007-12-06 12:49:42 -0400 (Thu, 06 Dec 2007) | 6 lines
Fix various in the udptl implementation. It could return empty modem frames, have an incorrect sequence number on packets, and display the wrong sequence number in the debug messages.
(closes issue #11228)
Reported by: Cache
Patches:
udptl-4.patch uploaded by dimas (license 88)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Now use Response: success
- New header "Ping: pong" :-)
- The Events action
- Now use Response: Success
- The new status is reported as "Events: On" or "Events: Off"
- Report if manager is enabled in the reload event
Small cleanups...
From moremanager
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Newstate event
- Now has "CalleridNum" for numeric caller id, like Newchannel
- The event does not send "<unknown>" for unknown caller IDs just an empty field
- Newstate and Newchannel events
- these have changed headers
"State" -> ChannelStateDesc Text based channel state
-> ChannelState Numeric channel state
- The events does not send "<unknown>" for unknown caller IDs just an empty field
- Newstate event
- Now has "CalleridNum" for numeric caller id, like Newchannel
- The event does not send "<unknown>" for unknown caller IDs just an empty field
- Link and Unlink events
- The "Link" and "Unlink" bridge events in channel.c are now renamed to "Bridge"
- The link state is in the bridgestate: header as "Link" or "Unlink"
- For channel.c bridges, "Bridgetype: core" is added. This opens up for
bridge events in rtp.c and channel drivers
- The "Rename" manager event has a renamed header, to use the same
terminology for the current channel as other events
- Oldname -> Channel
(Moremanager)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Maybe belongs in the new cdr category?
---moremanager---
Event: NewAccountCode
Modules: cdr.c
Purpose: To report a change in account code for a live channel
Example:
Event: NewAccountCode
Privilege: call,all
Channel: SIP/olle-01844600
Uniqueid: 1177530895.2
AccountCode: Stinas account 1234848484
OldAccountCode: Olles Account 12345
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Thanks, eliel, for writing the original patch. Modified by me to follow
other manager events and the new "moremanager" style.
(closes issue #11478)
Reported by: eliel
Patches:
manager.c.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91192 | russell | 2007-12-05 11:31:42 -0600 (Wed, 05 Dec 2007) | 10 lines
Make the lock in the threadstorage debugging code untracked to avoid a deadlock
on thread destruction.
(closes issue #11207)
Reported by: ys
Patches:
threadstorage.c.diff uploaded by ys (license 281)
Also fixes an open bug report: (closes issue #11446)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91074 | russell | 2007-12-04 18:48:47 -0600 (Tue, 04 Dec 2007) | 4 lines
When DEBUG_THREADS is enabled, we only have the details about who is holding
a lock that we are waiting on for a mutex, not rwlocks. This should fix the
problem where people have reported "core show locks" crashing sometimes.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91077 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90967 | russell | 2007-12-04 13:57:39 -0600 (Tue, 04 Dec 2007) | 7 lines
Make some changes to some additions I made recently for doing channel autoservice
when looking up extensions. This code was added to handle the case where a
dialplan switch was in use that could block for a long time. However, the way
that I added it, it did this for all extension lookups. However, lookups in the
in-memory tree of extensions should _not_ take long enough to matter. So, move
the autoservice stuff to be only around executing a switch.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@91011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This introduces two new options for zapata.conf: mwimonitor and mwimonitornotify.
The mwimonitor option enables MWI monitoring. When the MWI state on a line changes,
then the script specified by mwimonitornotify will be executed for custom handling
of the state change, similar to the externnotify option of voicemail.conf.
Also, when the MWI state on an FXO line changes, an internal Asterisk event is
generated to indicate the new state of the associated mailbox. That may, any
module that cares about MWI information will get notified and can handle it
just as if app_voicemail had sent this notification.
(BE-253, original patch from markster, with some minor modifications by me to
add comments, documentation, and internal event support)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90432 | tilghman | 2007-12-02 03:34:23 -0600 (Sun, 02 Dec 2007) | 7 lines
Clarify the return value on autoservice. Specifically, if you started
autoservice and autoservice was already on, it would erroneously return an
error.
Reported by: adiemus
Patch by: dimas
(Closes issue #11433)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This works in much the same way as the automonitor, except that instead of using the monitor
app, it uses the mixmonitor app. By providing an 'x' or 'X' as a dial or queue option, a DTMF
sequence may be entered (as defined in features.conf) to start the one-touch mixmonitor.
This patch also introduces some new API calls to the audiohooks code for searching for an audiohook
by type and for searching for a running audiohook by type.
Big thanks to joetester for writing the initial patch, testing it and patiently waiting for it to
be committed.
(closes issue #10185, reported and patched by xmarksthespot)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90348 | russell | 2007-11-30 13:26:04 -0600 (Fri, 30 Nov 2007) | 8 lines
Change the behavior of ao2_link(). Previously, in inherited a reference.
Now, it automatically increases the reference count to reflect the reference
that is now held by the container.
This was done to be more consistent with ao2_unlink(), which automatically
releases the reference held by the container. It also makes it so it is
no longer possible for a pointer to be invalid after ao2_link() returns.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90145 | russell | 2007-11-28 18:20:34 -0600 (Wed, 28 Nov 2007) | 5 lines
This set of changes is to make some callerID handling thread-safe.
The ast_set_callerid() function needed to lock the channel. Also, the handlers
for the CALLERID() dialplan function needed to lock the channel when reading
or writing callerid values directly on the channel structure.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90059 | mmichelson | 2007-11-28 16:08:50 -0600 (Wed, 28 Nov 2007) | 13 lines
Removing some seemingly pointless code. This sets a channel variable for every priority
executed in the dialplan if you have debug set to anything non-zero. This seems pointless
due to the fact that these channel variables are not referenced anywhere else in the code and
their names are esoteric enough that they would not be practical to reference in the dialplan. Plus
the fact that this behavior isn't documented anywhere means that the change is not likely to cause
any disruption. If anything, this may actually cause a slight performance increase if running with
debug on.
The motivating influence for this code change is the eventwhencalled option for queues. If set to
vars, all channel variables will be output to the manager. These unnecessary channel variables make
the output a lot more difficult to deal with.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89893 | russell | 2007-11-27 18:20:13 -0600 (Tue, 27 Nov 2007) | 4 lines
- update documentation for some of the goto functions to note that they
handle locking the channel as needed
- update ast_explicit_goto() to lock the channel as needed
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89790 | russell | 2007-11-27 15:45:51 -0600 (Tue, 27 Nov 2007) | 41 lines
Merge changes from team/russell/autoservice_1.4
This set of changes fixes an issue that was reported to me on IRC yesterday.
The user, d1mas, was using chan_zap for incoming calls and was having DTMF
recognition issues in some situations. Specifically, he noticed that the
problem occurred when using DISA or WaitExten. He also noticed that when
using Read, the problem did not occur. His system also used DUNDi for
dialplan lookups.
So, he theorized that if the DUNDi lookups blocked for some period of time,
that audio from the zap channel could get lost. If the audio got lost, then
it wouldn't be run through the DTMF detector, and digits could get lost.
He was correct, and the following set of changes fixes the problem. However,
the changes go a little bit further than what was necessary to fix this exact
problem.
1) I updated pbx_extension_helper() to autoservice the associated channel to
handle cases where extension lookups may take a long time. This would
normally be a dialplan switch that does some lookup over the network, such
as the DUNDi or IAX2 switches.
This ensures that even while a DUNDi lookup is blocking, the channel will be
continuously serviced.
2) I made a change to the autoservice code. This is actually something that
has bothered me for a long time. When a channel is in autoservice, _all_
frames get thrown away. However, some frames really shouldn't be thrown
away. The most notable examples are signalling (CONTROL) frames, and DTMF.
So, this patch queues up important frames while a channel is in autoservice.
When autoservice is stopped on the channel, the queued up frames get stuck
back on the channel so that they can get processed instead of thrown away.
3) I made another change to the autoservice code to handle the case where
autoservice is started on channels recursively.
Previously, you could call ast_autoservice_start() multiple times on a
channel, and it would stop the first time ast_autoservice_stop() gets
called. Now, it will ensure that autoservice doesn't actually stop until
the final call to ast_autoservice_stop().
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89709 | kpfleming | 2007-11-27 14:16:56 -0600 (Tue, 27 Nov 2007) | 2 lines
on second thought... revert all the other changes i've made in app options parsing leaving only one: if an empty argument is supplied for an option, set that argument pointer to point to an empty string rather than NULL, so that the application can do normal checks on it without worrying about it being NULL
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89721 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also by accident fixed a bad typo by a previous committer, which actually made video calls
not work fully...
Merged revisions 89630 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89630 | oej | 2007-11-27 16:23:17 +0100 (Tis, 27 Nov 2007) | 12 lines
If we get a codec offer using a well-known payload type, but using it for another
codec that we don't know, Asterisk did not remove that codec from the list.
With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.
(closes issue #11376)
Reported by: lasse
Patches:
bug11376.txt uploaded by oej (license 306)
Tested by: lasse
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89622 | murf | 2007-11-26 23:24:02 -0700 (Mon, 26 Nov 2007) | 1 line
closes issue #11379; OK, this is an attempt to make both sides happy. To the cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89610 | file | 2007-11-26 17:10:29 -0400 (Mon, 26 Nov 2007) | 2 lines
Fix issues with async dialing with an application executing. The application has to be terminated and control returned to the thread before hanging things up. (issue #BE-252)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Restructure other changes to UPGRADE.txt and CHANGES
We're still looking for scripts that replace
asterisk -rx "show shannels concise"
by using the manager interface, but still produces the same output.
Anyone?
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89577 | file | 2007-11-26 11:34:38 -0400 (Mon, 26 Nov 2007) | 6 lines
If channel allocation fails because the alert pipe could not be created also free the scheduler context.
(closes issue #11355)
Reported by: eliel
Patches:
main.channel.c.patch uploaded by eliel (license 64)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89540 | tilghman | 2007-11-24 00:19:23 -0600 (Sat, 24 Nov 2007) | 9 lines
Currently, zero-length voicemail messages cause a hangup in VoicemailMain.
This change fixes the problem, with a multi-faceted approach. First, we
do our best to avoid these messages from being created in the first place,
and second, if that fails, we detect when the voicemail message is
zero-length and avoid exiting at that point.
Reported by: dtyoo
Patch by: gkloepfer,tilghman
(Closes issue #11083)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89536 | tilghman | 2007-11-23 11:18:26 -0600 (Fri, 23 Nov 2007) | 10 lines
Up until this point, the XML output of the manager has been technically
invalid, due to the repetition of certain parameters in a single event.
This caused various issues for XML parsers, some of which refused to parse
at all, given the invalidity of the rendered XML. So this commit fixes
the XML output, ensuring that each entity parameter has a unique name, thus
ensuring valid XML.
Reported by: msetim
Patch by: tilghman
(Closes issue #10220)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
only do the calculations if fax detection is enabled on the dsp.
(closes issue #11331)
Reported by: dimas
Patches:
dsp.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
would return LONG_MIN (1 in 9 quintillion if using 64-bit longs). Since there
is no positive equivalent of LONG_MIN, the result of labs() in this case is
unpredictable. This fixes that situation.
(closes issue #11336, reported and patched by sperreault)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unfortunately, since trunk uses read/write locks for the context lock, it means that I have
actually *introduced* a deadlock condition since they are not recursive. Removing this change
for now and will look into introducing a different one.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89457 | mmichelson | 2007-11-20 11:50:31 -0600 (Tue, 20 Nov 2007) | 9 lines
According to comments in main/pbx.c, it is essential that if we are going to lock
the conlock as well as the hints lock, it must be locked in that respective order.
In order to prevent a potential deadlock, we need to lock the conlock prior to
locking the hints lock in ast_hint_state_changed (see the call stack example on
issue #11323 for how this can happen).
(closes issue #11323, reported by eelcob, suggestion for patch by eelcob, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is only to complete the build, clearly the linker
behaviour will be completely different and likely to
cause trouble in those cases.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89367 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89325 | kpfleming | 2007-11-16 10:47:46 -0600 (Fri, 16 Nov 2007) | 4 lines
To help combat problems where people build external modules (asterisk-addons or others) and then change the build options of the Asterisk build in a way that makes the incompatible without warning, this commit introduces an MD5 signature of the important build-time options and includes that signature into modules when they are built. When the loader loads one of these modules and notices the problem, it will emit a warning to console and refuse to initialize the module, as doing so could cause the system to be unstable or even crash.
If you upgrade to this version of Asterisk, you must rebuild *all* of your modules that came from other sources before trying to run this version. If you are using Digium's G.729 binary codec module, you will need v33 or newer.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
through ast_mutex primitives.
To detect all occurrences, I have renamed the lock field in struct ast_channel
so it is clear that it shouldn't be used directly.
There are some uses in res/res_features.c (see details of the diff)
that are error prone as they try and lock two channels without
caring about the order (or without explaining why it is safe).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents modifying the strings in the stored variables,
and catched a few instances where this was actually done.
Given the differences between trunk and 1.4 (and the fact that this
is effectively an API change) it is better to fix 1.4 independently.
These are
chan_sip.c::sip_register()
chan_skinny.c:: near line 2847
config.c:: near line 1774
logger.c::make_components()
res_adsi.c:: near line 1049
I may have missed some instances for modules that do not build here.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- handle memory allocation failures
- add an ast_ prefix to a publicly exported function
- put curly braces in the right places
- add a bunch of spaces where they should be be used
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- move a verbose message to after the item is added to the list
- make use of the ARRAY_LEN macro in one spot
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89258 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89239 | tilghman | 2007-11-13 07:51:53 -0600 (Tue, 13 Nov 2007) | 4 lines
Debugging is running into the 16-lock limit. Increase to avoid.
(This define is only effective when debugging is turned on, so there's
no effect for most installations.)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also fix a common typo I kept seeing (arguement) in various files.
Closes issue #11222, patch by snuffy (with arguement > argument by me).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- the *_CURRENT macros no longer need the list head pointer argument
- add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove the AST_FORMAT_MAX_* types, as these are consuming 3 out of our available 32 bits.
- Add a native slin16 type, so that 16kHz codecs can translate without losing resolution.
(This doesn't affect anything immediately, until another codec has wb support.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89036 | murf | 2007-11-06 10:52:50 -0700 (Tue, 06 Nov 2007) | 1 line
closes issue #8786 - where the [catname](!) and [catname](othercat1,othercat2,...) notation gets dropped across a ConfigUpdate (or any other thing that would cause a config file to be written). While I was at it, I also cleaned up some of the destroy routines to free up comments, which was not being done. Made sure the new struct I introduced is also cleaned up properly at destruction time. My code handles multiple template inclusions. Many thanks to ssokol for his patch, which, while not literally used in the final merge, served as a foundation for the fix.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of the current memory allocations when you start Asterisk, when the command's
handler gets called for initialization.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the constructor for the list of modules was run
after the constructors for the embedded modules
(which appended entries to the list).
As a result, the list appeared empty when it was
time to use it.
On linux the order of execution of constructor
was evidently different (it may depend on the
ordering of modules in the ELF file).
This is only a workaround - there may be other
situations where the execution of constructors
causes problems, so if we manage to find a more
general solution this workaround can go away.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89031 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88805 | russell | 2007-11-05 16:07:54 -0600 (Mon, 05 Nov 2007) | 12 lines
After seeing crashes related to channel variables, I went looking around at the
ways that channel variables are handled. In general, they were not handled in
a thread-safe way. The channel _must_ be locked when reading or writing from/to
the channel variable list.
What I have done to improve this situation is to make pbx_builtin_setvar_helper()
and friends lock the channel when doing their thing. Asterisk API calls almost
all lock the channel for you as necessary, but this family of functions did not.
(closes issue #10923, reported by atis)
(closes issue #11159, reported by 850t)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
namely main/Makefile .
I am unclear where decisions on the build environment (CFLAGS,
LDFLAGS, LIBS and so on) should be made - right now they are
split here and there.
As a first step in cleaning up this situation, i am trying to at
least collect all instances of each variable in one place.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88719 | russell | 2007-11-05 14:40:01 -0600 (Mon, 05 Nov 2007) | 7 lines
Merge changes from asterisk/team/kpfleming/SRV-priority-handling
Previously, the SRV record support in Asterisk was broken. There was no
guarantee on what record Asterisk would choose to actually use. This set of
changes improves the situation by ensuring that Asterisk will choose the
highest priority record.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88709 | russell | 2007-11-05 14:11:04 -0600 (Mon, 05 Nov 2007) | 20 lines
Merge the last bit of changes from asterisk/team/russell/readq-1.4
The issue here is that the channel frame readq handling got broken when the
code was converted to use the linked list macros. It caused corruption of the
list head and tail pointers. So, I fixed up the usage of the linked list
macros and in passing, simplified the code. I also documented what the code
is doing, as it was a bit difficult to figure out at first.
This bug showed itself with crashes showing messed up head/tail pointers for
the readq. However, there are a couple of crashes that aren't quite as obvious,
but I think may be related. So, if your bug gets closed by this commit, but
you still have a problem, please reopen or create a new bug report.
(closes issue #10936)
(closes issue #10595)
(closes issue #10368)
(closes issue #11084)
(closes issue #10040)
(closes issue #10840)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r88624 | russell | 2007-11-05 11:46:02 -0600 (Mon, 05 Nov 2007) | 5 lines
Fix up datastore handling in ast_do_masquerade(). The code is intended to move
any channel datastores from the old channel to the new one. However, it did
not use the linked list macros properly to accomplish the task. The existing
code would only work if there was only a single datastore on the old channel.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
details and examples are in include/asterisk/stringfields.h.
Not applicable to older branches except for 1.4 which will
receive a fix for the routines that free memory pools.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #11147)
........
r88283 | qwell | 2007-11-02 11:51:08 -0500 (Fri, 02 Nov 2007) | 4 lines
We need to make sure to specify a language to ast_fileexists, otherwise it may fail for anything besides en
Issue 11147, fix discovered by both citats and myself (independently), with input from Corydon76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87373 | russell | 2007-10-29 14:21:06 -0500 (Mon, 29 Oct 2007) | 5 lines
Remove a lock that doesn't make any sense. The regions lock needs to be held
when traversing the list of allocated chunks so that they can be printed out
to the CLI.
(Thanks to eliel on #asterisk-dev for pointing this out!)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r86750 | russell | 2007-10-22 10:52:48 -0500 (Mon, 22 Oct 2007) | 8 lines
Don't leak a frame in the case that an END frame is received and the time since
the BEGIN is less than that of the defined minimum DTMF duration.
(closes issue #11051)
Reported by: casper
Patches:
channel.c.86664.diff uploaded by casper (license 55)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r85532 | russell | 2007-10-13 00:24:33 -0500 (Sat, 13 Oct 2007) | 8 lines
Properly handle the case where read() may return the text for more than one
CLI command at once for a remote console.
(closes issue #10888)
Reported by: jamesgolovich
Patches:
asterisk-climultiple.diff.txt uploaded by jamesgolovich (license 176)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also fixes a few cli messages and some minor formatting.
(closes issue #11001)
Reported by: seanbright
Patches:
newcli.1.patch uploaded by seanbright (license 71)
newcli.2.patch uploaded by seanbright (license 71)
newcli.4.patch uploaded by seanbright (license 71)
newcli.5.patch uploaded by seanbright (license 71)
newcli.6.patch uploaded by seanbright (license 71)
newcli.7.patch uploaded by seanbright (license 71)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r86330 | russell | 2007-10-18 13:03:10 -0500 (Thu, 18 Oct 2007) | 10 lines
The channel needs to stay locked while running timer callbacks, as they access
and modify channel data that may change elsewhere. I went through every timer
callback in the source tree to make sure that none of them did any additional
locking that could introduce deadlocks, and all is well.
(closes issue #10765)
Reported by: Ivan
Patches:
ast_1_4_11_svn_patch_channel_rc.diff uploaded by Ivan (license 229)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r86237 | russell | 2007-10-17 23:40:52 -0500 (Wed, 17 Oct 2007) | 9 lines
Revert a change that I made for issue #10979 which, as has been pointed out to
me in issue #11018, doesn't really make sense. There is no reason to have
the base64 decode function force a '\0' terminated buffer, when the result is
almost always binary, anyway. In fact, this caused some breakage, as some code
in res_crypto passed in a buffer exactly the right size to get its binary
result, which got stomped on by this patch.
(closes issue #11018, reported by dimas)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r85647 | russell | 2007-10-15 14:11:38 -0500 (Mon, 15 Oct 2007) | 5 lines
The loop in the handler for the "core show locks" could potentially block for
some amount of time. Be a little bit more careful and prepare all of the
output in an intermediary buffer while holding a global resource. Then, after
releasing it, send the output to ast_cli().
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r85552 | file | 2007-10-15 11:55:04 -0300 (Mon, 15 Oct 2007) | 4 lines
If Monitor or a spy was added to a P2P or native bridged channel bring the channel back to the generic bridging core so the monitor or spy operations work.
(closes issue #10943)
Reported by: julianjm
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r85533 | russell | 2007-10-13 01:48:10 -0400 (Sat, 13 Oct 2007) | 12 lines
Fix an issue with console verbosity when running asterisk -rx to execute a command
and retrieve its output. The issue was that there was no way for the main Asterisk
process to know that the remote console was connecting in the -rx mode. The way that
James has fixed this is to have all remote consoles muted by default. Then, regular
remote consoles automatically execute a CLI command to unmute themselves when they
first start up.
(closes issue #10847)
Reported by: atis
Patches:
asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r84818 | file | 2007-10-05 15:55:36 -0300 (Fri, 05 Oct 2007) | 4 lines
Update the remembered RTP peer information when putting an endpoint on hold or taking it off hold so that the RTP stack does not initiate a needless reinvite.
(closes issue #10868)
Reported by: mavince
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@84819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a patch for it. It replaces a bunch of simple calls to snprintf with ast_copy_string
(closes issue #10843)
Reported by: Corydon76
Patches:
2007092900_10843.diff uploaded by mvanbaak (license 7)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@84173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
another CLI command with the same command text registered. This prevents
a crash if someone accidentally calls ast_cli_register() on the same CLI
command data twice. This also fixes a small bug where the helpers list
would get unlocked without being locked if building the full command failed.
(closes issue #10858, reported by jamesgolovich, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@84169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Tilghman Lesher
Joshua Colp
James Golovich
Jason Parker
Olle Johansson
Steve Murphy
Pari Nannapaneni
Mark Michelson
Terry Wilson
Kevin P. Fleming
Luigi Rizzo
Dwayne M. Hubbard
Matthew Fredrickson