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
A number of va_copy operations weren't matched with a corresponding va_end in res_config_odbc. Also, there was a potential for va_end to be invoked twice on the same va_arg in utils, which would mean invoking va_end on an undefined variable... which is bad.
va_end is removed from various functions in config_pgsql and config_curl since they aren't making their own copy. The invokers of those functions are responsible for calling va_end on them.
(issue ASTERISK-19451)
Reported by: Walter Doekes
Review: https://reviewboard.asterisk.org/r/1848/
........
Merged revisions 362354 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362357 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the XML calendar data returned by a Microsoft Exchange Web Service
specifies an XML Event E-Mail Address ("EmailAddress"), and no e-mail address
is provided, a condition existed where an ast_calendar_attendee struct would
be allocated but not appended to the list of attendees. Because of that,
the memory associated with the attendee would never be freed. This patch
frees the memory if no e-mail address is provided.
........
Merged revisions 361606 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361607 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r360356 | russell | 2012-03-23 22:33:36 -0400 (Fri, 23 Mar 2012) | 6 lines
expression parser: Fix (theoretical) memory leak.
Fix a memory leak that is very unlikely to actually happen. If a malloc()
succeeded, but the following strdup() failed, the memory from the original
malloc() would be leaked.
........
r360357 | russell | 2012-03-23 22:34:39 -0400 (Fri, 23 Mar 2012) | 6 lines
Rebuild parsers.
This is needed to include the last fix to main/ast_expr2.y. The changes look
much bigger as this regeneration of the code was done with newer versions of
flex and bison.
........
Merged revisions 360356-360357 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360358 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added missing error exits with cause in manager_mutestream().
* Cleaned up manager_mutestream() and func_mute_write().
* Some whitespace and comment cleanup.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@359942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change restores functionality that was present in 1.4, when AEL macros
were implemented with the Macro dialplan application. Macros are fraught with
functionality issues, because they consume a large portion of the underlying
application stack. This limits the ability of AEL users to call many layers
of subroutines, an issue which Gosub does not have (originally tested to
100,000 levels deep). Therefore, starting in 1.6.0, AEL macros were
implemented with Gosub.
However, there were some implicit behaviors of Macro, which were not replicated
at the same time as with the transition to Gosub, one of which is documented in
the related issue. In particular, the "h" extension is designed to execute not
in the Macro context, but in the topmost calling context. Due to legacy issues
with a misapplied bugfix many years ago, when a macro exited in 1.4, it looks
in all calling contexts, bubbling up from the deepest level until it finds an
"h" extension.
Since AEL hides the complexity of the underlying dialplan logic from the AEL
programmer, it's reasonable to assume that this behavior should not change in
the transition from Asterisk 1.4 LTS to Asterisk 1.8 LTS, lest we break
working AEL configurations in the transition to Asterisk 1.8 LTS. This fix
is the result, which implements a search for the "h" extension in all calling
Gosub contexts.
Fixes ASTERISK-19336
Patch: 20120308__ael_bugfix_for_trunk__2.diff (License #5003) by Tilghman Lesher
(with slight modifications for 1.8)
Tested by: Johan Wilfer
Review: https://reviewboard.asterisk.org/r/1776/
........
Merged revisions 358810 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 358811 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@358812 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, when using res_srtp, once the SRTP policy has been added to the
current session the policy is locked into place. Any attempt to replace an
existing policy, which would be needed if the remote endpoint negotiated a new
cryptographic key, is instead rejected in res_srtp. This happens in particular
in transfer scenarios, where the endpoint that Asterisk is communicating with
changes but uses the same RTP session.
This patch modifies res_srtp to allow remote and local policies to be reloaded
in the underlying SRTP library. From the perspective of users of the SRTP API,
the only change is that the adding of remote and local policies are now added
in a single method call, whereas they previously were added separately. This
was changed to account for the differences in handling remote and local
policies in libsrtp.
Review: https://reviewboard.asterisk.org/r/1741/
(closes issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
srtp_renew_keys_2012_02_22.diff uploaded by Matt Jordan (license 6283)
(with some small modifications for this check-in)
........
Merged revisions 356604 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 356605 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the res_calendar module was followed immediately by one of the
calendar tech modules and "core stop gracefully" was run, Asterisk
would crash.
This patch adds use count tracking for res_calendar so that it is
unloaded after the tech modules when shutting down gracefully. It
is now not possible to unload all the of the calendar modules via
"module unload res_calednar.so", but it is still possible to unload
them all via "module unload -h res_calendar.so".
Review: https://reviewboard.asterisk.org/r/1752/
........
Merged revisions 356291 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 356297 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a variable AGIEXITONHANGUP for res_agi. If this variable is
set to "yes" on a channel, AGI() will exit immediately once a channel hangup
has been detected. This was the behavior of AGI() in Asterisk 1.4 and earlier
and is still desired by some people.
Review: https://reviewboard.asterisk.org/r/1734/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@355102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There can only be one database connection in res_config_pgsql just like
res_config_sqlite. If the connection is lost, the connection may not get
reestablished to the same database if the res_pgsql.conf and
extconfig.conf files are inconsistent.
* Made only use the configured database from res_pgsql.conf.
* Fixed potential buffer overwrite of last[] in config_pgsql().
(closes issue ASTERISK-16982)
Reported by: german aracil boned
Review: https://reviewboard.asterisk.org/r/1731/
........
Merged revisions 354953 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 354959 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
actually remove res_ais. This commit removes it.
In addition, the 'install_prereq' script has been updated to no longer install
AIS dependency packages, and instead install Corosync packages instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354459 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes res_ais and introduces a new module, res_corosync.
The OpenAIS project is deprecated and is now just a wrapper around
Corosync. This module provides the same functionality using the same
core infrastructure, but without the use of the deprecated components.
Technically res_ais could have been used with an AIS implementation other
than OpenAIS, but that is the only one I know of that was ever used.
Review: https://reviewboard.asterisk.org/r/1700/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354046 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The calendaring tech modules depend on res_calendar and initially
res_calendar just bumped the use count so that it couldn't be unloaded.
res_calendar can potentially create many threads and I've seen issues
where the Asterisk shutdown has failed where it looked like these
threads could be the culprit.
This patch adds unload support for res_calendar. Unloading res_calendar
will also unload the dependant tech modules as well.
(closes issue ASTERISK-16744)
Review: https://reviewboard.asterisk.org/r/1657/
........
Merged revisions 353502 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 353503 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I also went ahead and took a little time to make sure that the manager value
AMI_SUCCESS was used instead of just return 0 being thrown around everywhere since that's
how we handle this stuff these days.
(closes issue ASTERISK-19249)
Reporter: Jamuel Starkey
Patches:
res_monitor.c-ASTERISK-19249.diff uploaded by Jamuel Starkey (license 5766)
........
Merged revisions 352959 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 352965 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a CALENDAR_SUCCESS=1/0 variable that is set to show whether or
not CALENDAR_WRITE has passed. This patch also adds some debugging for caldav
PUT responses and no longer treats responses with no body as an error (as a PUT
gets a 201 Created with no body).
(closes issue ASTERISK-16903)
Reported by: Clod Patry
Tested by: Terry Wilson
Patches:
calendarstatus.diff uploaded by Clod Patry (License #5138), slightly modified by Terry Wilson
Review: https://reviewboard.asterisk.org/r/1692/
- This line, and those below, will be ignored--
M res/res_calendar.c
M res/res_calendar_exchange.c
M res/res_calendar_caldav.c
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352916 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
While the FAXOPT function could be used to set the modem capabilities, the
input to that function was not being applied correctly to the spandsp layer.
This patch applies the current model capabilities before starting the spandsp
layer.
(closes issue: ASTERISK-16409)
Reported by: Kristijan Vrban
Tested by: Matt Jordan, Matthew Nicholson
Patches:
spandsp-modems-1.8.diff uploaded by mnicholson (license 5081)
spandsp-modems-10.diff uploaded by mnicholson (license 5081)
........
Merged revisions 352144 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 352149 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352166 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
In order to better handle RTP sources with strictrtp enabled (which is now default in 10)
using the learning mode to figure out new sources when they change is handled by checking
for a number of consecutive (by sequence number) packets received to an rtp struct
based on a new configurable value called 'probation'. Also, during learning mode instead
of liberally accepting all packets received, we now reject packets until a clear source
has been determined.
Review: https://reviewboard.asterisk.org/r/1663/
........
Merged revisions 351287 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351289 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r350788 | kpfleming | 2012-01-14 09:22:33 -0600 (Sat, 14 Jan 2012) | 8 lines
Ensure that two prerequisites are properly installed on Debian-style distributions.
* Don't specify a specific version of libgmime; newer versions are available
now and acceptable.
* Install libsrtp so that res_srtp can be built.
........
r350789 | kpfleming | 2012-01-14 09:23:32 -0600 (Sat, 14 Jan 2012) | 3 lines
Correct some 'set-but-not-used' variable warnings.
........
Merged revisions 350788-350789 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 350790 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350791 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
Even though we set the frame to the ast_null_frame and return that,
the caller of the frame hook may still need the frame. This now is
a bit more careful about when it frees the frame, i.e., only under
the same conditions that applied when we duplicated it in the first
place.
........
Merged revisions 349822 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A frame that is translated via ast_translate is also duplicated via ast_frdup.
This will allocate a new frame on the heap, which needs to be free'd
at the appropriate time. This issue reporter used valgrind to find that this
occurred in res_fax's fax_gateway_framehook; a quick search through the code
showed that only place this was currently not handling the translatted frame
properly.
(closes issue ASTERISK-19133)
Reported by: Sylvain Rochet
........
Merged revisions 349608 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit removes the V.21 preamble detection code previously added to the
generic DSP implementation in Asterisk, and instead enhances the res_fax module
to be able to utilize V.21 preamble detection functionality made available by
FAX technology modules. This commit also adds such support to res_fax_spandsp,
which uses the Spandsp modem tone detection code to do the V.21 preamble
detection.
There should be no functional change here, other than much more reliable V.21
preamble detection (and thus T.38 gateway initiation).
........
Merged revisions 349248 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349249 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
The function ast_srtp_protect used a common buffer for both SRTP and SRTCP
packets. Since this function can be called from multiple threads for the same
SRTP session (scheduler for SRTCP and channel for SRTP) it was possible for the
packets to become corrupted as the buffer was used by both threads
simultaneously.
This patch adds a separate buffer for SRTCP packets to avoid the problem.
(closes issue ASTERISK-18889, Reported/patch by Daniel Collins)
........
Merged revisions 347995 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 347996 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@348567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Terry Wilson
Matthew Jordan
Jonathan Rose
Walter Doekes
Kinsey Moore
Russell Bryant
Richard Mudgett
Tilghman Lesher
Sean Bright
Mark Michelson
Kevin P. Fleming