| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Reported by: markster
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@202496 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
traversal.
It is possible for datastore fixup functions to remove the datastore from the list
and free it. In particular, the queue_transfer_fixup in app_queue does this. While
I don't yet know of this causing any crashes, it certainly could.
Found while discussing a separate issue with Brian Degenhardt.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@201450 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@200991 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
inband ringing after a call is answered.
(closes issue #15158)
Reported by: madkins
Patches:
15158.patch uploaded by mmichelson (license 60)
Tested by: madkins
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@200360 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Hints with two or more devices that include ONHOLD gave unexpected results.
(closes issue #15057)
Reported by: p_lindheimer
Patches:
onhold_trunk.diff uploaded by dvossel (license 671)
pbx.c.1.4.patch uploaded by p (license 558)
devicestate.c.trunk.patch uploaded by p (license 671)
Tested by: p_lindheimer, dvossel
Review: https://reviewboard.asterisk.org/r/254/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@199297 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
During asterisk startup, a lock on the list of modules is obtained by the
primary thread while each module is initialized. Issue 13778 pointed out a
problem with this approach, however. Because the AMI is loaded before other
modules, it is possible for a module reload to be issued by a connected client
(via Action: Command), causing a deadlock.
The resolution for 13778 was to move initialization of the manager to happen
after the other modules had already been lodaded. While this fixed this
particular issue, it caused a problem for users (like FreePBX) who call AMI
scripts via an #exec in a configuration file (See issue 15189).
The solution I have come up with is to defer any reload requests that come in
until after the server is fully booted. When a call comes in to
ast_module_reload (from wherever) before we are fully booted, the request is
added to a queue of pending requests. Once we are done booting up, we then
execute these deferred requests in turn.
Note that I have tried to make this a bit more intelligent in that it will not
queue up more than 1 request for the same module to be reloaded, and if a
general reload request comes in ('module reload') the queue is flushed and we
only issue a single deferred reload for the entire system.
As for how this will impact existing installations - Before 13778, a reload
issued before module initialization was completed would result in a deadlock.
After 13778, you simply couldn't connect to the manager during startup (which
causes problems with #exec-that-calls-AMI configuration files). I believe this
is a good general purpose solution that won't negatively impact existing
installations.
(closes issue #15189)
(closes issue #13778)
Reported by: p_lindheimer
Patches:
06032009_15189_deferred_reloads.diff uploaded by seanbright (license 71)
Tested by: p_lindheimer, seanbright
Review: https://reviewboard.asterisk.org/r/272/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@199022 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and res_feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
(closes issue #13630)
Reported by: festr
Review: https://reviewboard.asterisk.org/r/271/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@198891 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
(closes issue #12946)
Reported by: meral
Patches:
null-cdr2.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, dbrooks
(closes issue #15122)
Reported by: sum
Tested by: sum
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@198068 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
reinvite with 491.
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Review: https://reviewboard.asterisk.org/r/252
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197588 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
There are two flags being added to the chanspy audiohook here. One
is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
we ensure that the read and write slinfactories on the audiohook do
not skew beyond a certain tolerance.
In addition, there is a new audiohook flag added here,
AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
a slinfactory to build up a substantial amount of audio before
flushing it. For this particular issue, this means that the person
spying on the call will hear the conversations in real time with very
little delay in the audio.
(closes issue #13745)
Reported by: geoffs
Patches:
13745.patch uploaded by mmichelson (license 60)
Tested by: snblitz
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197537 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The bridge was terminating immediately after the attended transfer was
completed. The problem was because upon reentering ast_channel_bridge
nexteventts was checked to see if it was set and if so could possibly
return AST_BRIDGE_COMPLETE.
(closes issue #15183)
Reported by: andrebarbosa
Tested by: andrebarbosa, tootai, loloski
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197124 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
AST_CDR_FLAG_LOCKED from being updated in certain cases.
This is accomplished by adding two functions to update the answer time and disposition of calls that checks for the proper lock flags. These functions are used in the ast_bridge_call() function so that ForkCDR(A) calls are respected.
This patch also modifies the way ast_bridge_call() chooses the cdr record to base the bridged_cdr on. Previously the first unlocked cdr record would be chosen, now instead the first cdr record is chosen and forked cdr records are moved to the bridge_cdr. This allows the original cdr record and any forked cdr records to be properly updated with answer and end times.
(closes issue #13797)
Reported by: sh0t
Tested by: sh0t
(closes issue #14744)
Reported by: deepesh
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195881 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a smoother present.
(closes issue #15105)
Reported by: bamby
Patches:
process-vad-correctly.diff uploaded by bamby (license 430)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195206 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
back to the caller call leg when reinvited.
(closes issue #13569)
Reported by: bkw918
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195095 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15144)
Reported by: cristiandimache
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195020 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In the case that we could not remove the desired channel from the
list of channels, there was an extra call to unlock the channel list.
Since we unlock the list later on in the function anyway, this results
in the list being unlocked twice yet only being locked once.
(closes issue #15098)
Reported by: tim_ringenbach
Patches:
remove_extra_unlock.diff uploaded by tim (license 540)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194356 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
pbx_substitute_variables_helper_full with a non-zero'd buffer
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194322 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14815)
Reported by: geoff2010
Patches:
v1-14815.patch uploaded by dimas (license 88)
Tested by: geoff2010, file, dimas, ZX81, moliveras
(closes issue #14460)
Reported by: moliveras
Tested by: moliveras
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194208 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15091)
Reported by: andrew
Patches:
20090512__issue15091.diff.txt uploaded by tilghman (license 14)
Tested by: andrew
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194137 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14167)
Reported by: jpt
Patches:
call-file-missing-cdr2.diff uploaded by mnicholson (license 96)
Tested by: dlotina, rmartinez, mnicholson
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@193391 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Note: This is not a new feature, it was previously undocumented and broken.)
The Asterisk logger has a feature to support absolute pathnames for logger channels, but the code implementing the feature was broken. This has been fixed, and the absolute path feature is now documented in the sample logger.conf.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@193193 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
If the single digit DTMF is an extension in the specified context, then
go there and signal no DTMF. Otherwise, we should exit with that DTMF.
If we're in Macro, we'll exit and seek that DTMF as the beginning of an
extension in the Macro's calling context. If we're not in Macro, then
we'll simply seek that extension in the calling context. Previously,
someone complained about the behavior as it related to the interior of a
Gosub routine, and the fix (#14011) inadvertently broke FreePBX
(#14940). This change should fix both of these situations, but with the
possible incompatibility that if a single digit extension does not exist
(but a longer extension COULD have matched), it would have previously
gone immediately to the "i" extension, but will now need to wait for a
timeout.
(closes issue #14940)
Reported by: p_lindheimer
Patches:
20090420__bug14940.diff.txt uploaded by tilghman (license 14)
Tested by: p_lindheimer
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@193119 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This fixes a regression from commit 176701. The issue was that
ast_generic_bridge never exited after the feature digit timeout had elapsed,
which prevented the queued DTMF from being sent to the other side.
This issue was reported to me directly.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191488 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
glob.h
This allows config.c to compile when linked against uclibc that does not support these parameters
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@189601 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
testing against MAP_FAILED response.
Got rid of shadowed variable used in processign the mmap results.
Change test of mmap results to compare against MAP_FAILED
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@189391 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Many users were finding that their hung up channels were staying up and
causing 100% CPU usage.
(issue #14723)
Reported by: seadweller
Patches:
14723_1-4-tip.patch uploaded by mmichelson (license 60)
Tested by: falves11, bamby
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@189277 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14306)
Reported by: cristiandimache
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@189009 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This fixes potential refcount errors that may occur on ast_filestreams.
AST-208
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@188582 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ast_translate.
audio_audiohook_write_list() does not take into account that the sample size may change after translation depending on if the original frame is is 8khz or 16khz. While no 16kz codecs are supported in 1.4 at the moment, this will save headaches in the future if they ever are. the sample size is now updated after translating to reflect this possibility. Thanks to jcolp and mmichelson for helping me work this out.
(issue AST-197)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@188287 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
deadlock.
Add lock timeouts to avoid this potential deadlock.
(closes issue #14705)
Reported by: jamessan
Patches:
20090320__bug14705.diff.txt uploaded by tilghman (license 14)
Tested by: jamessan
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@187428 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@187301 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Related to issue #14625)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@187300 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This fixes short reads in http manager sessions, such as those done by the
ast-gui branch. (Fixes AST-198)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@187209 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
"ast_read() called with no recorded file descriptor" is a new message added
after a bug was discovered. Unfortunately, it seems there are a bunch of places
that potentially make such calls to ast_read() and trigger this error message
to be displayed. This commit does two things to help to make this message appear
less.
First, the message has been downgraded to a debug level message if dev mode is
not enabled. The message means a lot more to developers than it does to end users,
and so developers should take an effort to be sure to call ast_read only when
a channel is ready to be read from. However, since this doesn't actually cause an
error in operation and is not something a user can easily fix, we should not spam
their console with these messages.
Second, the message has been moved to after the check for any pending masquerades.
ast_read() being called with no recorded file descriptor should not interfere with
a masquerade taking place.
This could be seen as a simple way of resolving issue #14723. However, I still want
to try to clear out the existing ways of triggering this message, since I feel that
would be a better resolution for the issue.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@186984 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
AST_BRIDGE_RETRY.
Without this flag set, warning sounds will not be properly played to either party
of the bridge.
(closes issue #14845)
Reported by: adomjan
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@186832 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14847)
Reported by: kobaz
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@186719 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This change fixes a situation where an audiohook that wants DTMF would not
actually get it. This is in the code path where we end DTMF digit length
emulation while handling a NULL frame.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@185771 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Handle the scenario where we are called to move audiohooks between channels
and the source channel does not actually have any on it.
(closes issue #14734)
Reported by: corruptor
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@185196 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
autocomplete.
When moving the cursor backward and pressing TAB to autocomplete, a NULL is put
in the line and we are loosing what we have already wrote after the actual
cursor position.
(closes issue #14373)
Reported by: eliel
Patches:
asterisk.c.patch uploaded by eliel (license 64)
Tested by: lmadsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@184188 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@183291 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@183241 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@183238 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@183145 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@183123 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182882 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182810 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
runtime global namespace. Along the way, change the prefixes on some internal-only API calls to use a common prefix.
With these changes, for a module to export symbols into the global namespace, it must have *both* the AST_MODFLAG_GLOBAL_SYMBOLS flag and a linker script that allows the linker to leave the symbols exposed in the module's .so file (see res_odbc.exports for an example).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182808 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182807 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
runtime global namespace. Along the way, change the prefixes on some internal-only API calls to use a common prefix.
With these changes, for a module to export symbols into the global namespace, it must have *both* the AST_MODFLAG_GLOBAL_SYMBOLS flag and a linker script that allows the linker to leave the symbols exposed in the module's .so file (see res_odbc.exports for an example).
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182802 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The underlying db1 implementation does not fully isolate the pages retrieved
from astdb, so the lock protecting accesses needs to be extended until the
copy from the shared memory structure is done.
(closes issue #14682)
Reported by: makoto
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182449 f38db490-d61c-443f-a65b-d21fe96a405b
|
