Currently, if an acknowledgement of a timer fails Asterisk will not realize
that a serious error occurred and will continue attempting to use the timer's
file descriptor. This can lead to situations where errors stream to the
CLI/log file. This consumes significant resources, masks the actual problem
that occurred (whatever caused the timer to fail in the first place), and
can leave channels in odd states.
This patch propagates the errors in the timing resource modules up through
the timer core, and makes users of these timers handle acknowledgement
failures. It also adds some defensive coding around the use of timers
to prevent using bad file descriptors in off nominal code paths.
Note that the patch created by the issue reporter was modified slightly for
this commit and backported to 1.8, as it was originally written for
Asterisk 10.
Review: https://reviewboard.asterisk.org/r/2178/
(issue ASTERISK-20032)
Reported by: Jeremiah Gowdy
patches:
jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358)
........
Merged revisions 375893 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375894 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375895 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update and extend the configuration_file group and enable linking to the resource. Update title that was left behind many years ago.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a number of modules in resources that did not handle the
negative return value from function calls adequately. This includes:
* res_agi.c: if the result of the read function is a negative number,
indicating some failure, the result would instead be treated as the number
of bytes read. This patch now treats negative results in the same manner
as an end of file condition, with the exception that it also logs the
error code indicated by the return.
* res_musiconhold.c: if spawn_mp3 fails to assign a file descriptor to srcfd,
and instead assigns a negative value, that file descriptor could later be
passed to functions that require a valid file descriptor. If spawn_mp3 fails,
we now immediately retry instead of continuing in the logic.
* res_rtp_asterisk.c: if no codec can be matched between two RTP instances
in a peer to peer bridge, we immediately return instead of attempting to
use the codec payload type as an index to determine the appropriate negotiated
codec.
(issue ASTERISK-19655)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1863/
........
Merged revisions 362362 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362364 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a feature patch which allows an 'announcement' option to be specified in
musiconhold.conf which should be set to the name of a sound. If a valid sound is
specified for this option, then it will be played on that music on hold class whenever
a channel bound to that class is put on hold as well as when Asterisk is able to detect
that a song has ended before starting the next song (excludes external players).
(closes ASTERISK-18977)
Reported by: Timo Teräs
Patches:
asterisk-moh-announcement.diff uploaded by Timo Teräs (license 5409)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352134 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, res_musiconhold existed at the same module priority level
as the timing sources that it depends on. This would cause a problem when
music on hold was reloaded, as the timing source could be changed after
res_musiconhold was processed. This patch adds a new module priority level,
AST_MODPRI_TIMING, that the various timing modules are now loaded at. This
now occurs before loading other resource modules, such that the timing source
is guaranteed to be set prior to resolving the timing source dependencies.
(closes issue ASTERISK-17474)
Reporter: Luke H
Tested by: Luke H, Vladimir Mikhelson, zzsurf, Wes Van Tlghem, elguero, Thomas Arimont
Patches:
asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-1.8.diff uploaded by elguero (License #5026)
asterisk-17474-dahdi_timing-infinite-wait-fix_v3_branch-10.diff uploaded by elguero (License #5026)
asterisk-17474-dahdi_timing-infinite-wait-fix_v3.diff uploaded by elguero (License #5026)
Review: https://reviewboard.asterisk.org/r/1578/
........
Merged revisions 349194 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 349195 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a result of the fix for ASTERISK-18039, realtime caching MOH no longer
properly resumes playing back a file between different holds in the same call.
This is because scanning for new files causes the existing file array to be
emptied and we were just comparing that the saved pointer to the filename
matched the pointer to the filename in a particular position in the array. An
easy fix is to save the filename instead of a pointer to it and then do a
strcmp instead of comparing the addresses.
(closes issue ASTERISK-18912)
Review: https://reviewboard.asterisk.org/r/1596/
........
Merged revisions 346030 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 346031 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346033 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r334357 | rmudgett | 2011-09-02 16:08:16 -0500 (Fri, 02 Sep 2011) | 26 lines
Merged revisions 334355 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r334355 | rmudgett | 2011-09-02 15:59:49 -0500 (Fri, 02 Sep 2011) | 19 lines
MusicOnHold has extra unref which may lead to memory corruption and crash.
The problem happens when a call is disconnected and you had started a MOH
class that does not use the files mode. If you define REF_DEBUG and
recreate the problem, it will announce itself with the following warning:
Attempt to unref mohclass 0xb70722e0 (default) when only 1 ref remained,
and class is still in a container!
* Fixed moh_alloc() and moh_release() functions not handling the
state->class reference consistently.
(closes issue ASTERISK-18346)
Reported by: Mark Murawski
Patches:
jira_asterisk_18346_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett, Mark Murawski
Review: https://reviewboard.asterisk.org/r/1404/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@334358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r331039 | kmoore | 2011-08-08 15:53:30 -0500 (Mon, 08 Aug 2011) | 18 lines
Merged revisions 331038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r331038 | kmoore | 2011-08-08 15:52:45 -0500 (Mon, 08 Aug 2011) | 11 lines
In-queue MOH stops after a periodic announcement
If the seek value is past the end of file when resuming G.722 MOH, MOH will
cease to function for the duration of the MOH session through all starts and
stops until saved state is cleared. Adjusting the code to guarantee a single
valid read (which is already assumed) fixes the bug.
(closes issue ASTERISK-18077)
Review: https://reviewboard.asterisk.org/r/1328/
Tested-by: Jonathan Rose <jrose@digium.com>
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@331040 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r325821 | jrose | 2011-06-30 14:17:32 -0500 (Thu, 30 Jun 2011) | 10 lines
Fixes an issue with Music on Hold classes losing files in playlist when realtime is used.
The bug occurs rather intermittently and I relied on the reporters to test the patch.
After a sanity check and some testing, I'm giving it an OK.
(closes issue ASTERISK-17875)
Reported by: David Cunningham
Patches:
res_musiconhold.c.mohrt17875_v1 uploaded by Igor Goncharovsky (license #5009)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@325864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r292376 | tilghman | 2010-10-19 19:40:29 -0500 (Tue, 19 Oct 2010) | 5 lines
Oops. This module uses the generic timer and no longer uses DAHDI.
This causes a problem with the Solaris and other system builds that have gcc
4.1 (where optional_api is non-optional).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292377 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292050 | tzafrir | 2010-10-16 12:47:00 +0200 (ש', 16 אוק 2010) | 22 lines
Merged revisions 292049 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r292049 | tzafrir | 2010-10-16 12:03:04 +0200 (ש', 16 אוק 2010) | 15 lines
Base directory for MOH should be ASTDATADIR
If the directive 'directory' is relative, make it relative to the
datadir, rather than to the varlibdir. In the sample configuration
it is relative ('moh').
This has no effect unless you have actively set the datadir explicitly
(at build time or at run time).
(closes issue #16906)
Patches:
moh_datadir uploaded by tzafrir (license 46)
Review: https://reviewboard.asterisk.org/r/974/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The result for moh_register was not verified to guarantee
the mohclass as added to the container.
(closes issue #16993)
Reported by: dmitri
Patches:
res_musiconhold_rtclass2.patch uploaded by dmitri (license 1001)
moh_crash2.diff uploaded by dvossel (license 671)
Tested by: dmitri
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269271 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260345 | mmichelson | 2010-04-30 15:08:15 -0500 (Fri, 30 Apr 2010) | 18 lines
Fix potential crash from race condition due to accessing channel data without the channel locked.
In res_musiconhold.c, there are several places where a channel's
stream's existence is checked prior to calling ast_closestream on it. The issue
here is that in several cases, the channel was not locked while checking the
stream. The result was that if two threads checked the state of the channel's
stream at approximately the same time, then there could be a situation where
both threads attempt to call ast_closestream on the channel's stream. The result
here is that the refcount for the stream would go below 0, resulting in a crash.
I have added proper channel locking to res_musiconhold.c to ensure that
we do not try to check chan->stream without the channel locked. A Digium customer
has been using this patch for several weeks and has not had any crashes since
applying the patch.
ABE-2147
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260346 65c4cc65-6c06-0410-ace0-fbb531ad65f3