https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r212763 | seanbright | 2009-08-18 12:36:00 -0400 (Tue, 18 Aug 2009) | 11 lines
Delay the creation of temporary files until we have a valid manager command to handle.
Without this patch, asterisk creates a temporary file before determining if the
specified command is valid. If invalid, we weren't properly cleaning up the file.
(closes issue #15730)
Reported by: zmehmood
Patches:
M15730.diff uploaded by junky (license 177)
Tested by: zmehmood
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The logic here was reversed as ast_safe_system returns -1 on error and not on
success. Fix suggested by reporter.
(closes issue #15667)
Reported by: loic
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Based on a post on the gcc-help mailing list and some subsequent reading,
we can increase our portability to various platforms by directly defining
the POSIX and X/OPEN API feature sets we wish to have available. This patch
does that, and also includes a double-check to ensure that the system
we are compiling on can actually provide the requested feature sets.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
documentation of a function/application.
This will make reading the docs on the CLI way more easy.
(closes issue #15694)
Reported by: mvanbaak
Patches:
2009081100-extralinesoptionlist.diff.txt uploaded by mvanbaak (license 7)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Even though the get_channel_by_name() API advertised that you could search by
name or uniqueid (just as the old API did), searching by uniqueid was not
actually implemented. This patch fixes that problem.
The ast_channel_get_full() function now makes a second search attempt by
uniqueid if the parameter was a name. The channel comparison function also
now knows how to compare by unqieueid.
Finally, a bug was fixed in passing where OBJ_POINTER was being passed in some
scenarios where it should not have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some T.38 endpoints treat T38FaxMaxDatagram as the maximum IFP size that should
be sent to them, rather than the maximum packet payload size. If such an
endpoint also requests UDPRedundancy as the error correction mode, we'll end
up calculating a tiny maximum IFP size, so small as to be unusable. This patch
sets a lower bound on what we'll consider the remote's maximum IFP size to be,
assuming that endpoints that do this really can accept larger packets than
they've offered to accept.
(closes issue #15649)
Reported by: dazza76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines
Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it.
(closes issue #15397)
Reported by: caspy
Patches:
20090714__issue15397.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The find_channel_by_group callback was only looking at the channel that was
attempting to make the pickup instead of the other channels in the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209759 | kpfleming | 2009-07-31 19:52:00 -0500 (Fri, 31 Jul 2009) | 7 lines
Minor changes inspired by testing with latest GCC.
The latest GCC (what will become 4.5.x) has a few new warnings, that in these
cases found some either downright buggy code, or at least seriously poorly
designed code that could be improved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209131 | mmichelson | 2009-07-27 12:44:06 -0500 (Mon, 27 Jul 2009) | 18 lines
Allow for UDPTL to use only even-numbered ports if desired.
There are some VoIP providers out there that will not accept SDP
offers with odd numbered UDPTL ports. While it is my personal opinion
that these VoIP providers are misinterpreting RFC 2327, it really is
not a big deal to play along with their silly little games. Of course,
since restricting UDPTL ports to only even numbers reduces the range
of available ports by half, so the option to use only even port numbers
is off by default. A user can enable the behavior by setting
use_even_ports=yes in udptl.conf.
(closes issue #15182)
Reported by: CGMChris
Patches:
15182.patch uploaded by mmichelson (license 60)
Tested by: CGMChris
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@209132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Requiring 'module reload' to reload everything, including
core etc makes russell very unhappy.
The default configuration already loads the 'friendly' aliases template.
Added 'reload=module reload' to that template.
Also removed the comment in main/cli.c that reload should come back.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208746 | jpeeler | 2009-07-25 01:19:50 -0500 (Sat, 25 Jul 2009) | 7 lines
Fix compiling under dev-mode with gcc 4.4.0.
Mostly trivial changes, but I did not know of any other way to fix the
"dereferencing type-punned pointer will break strict-aliasing rules" error
without creating a tmp variable in chan_skinny.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I keep getting annoyed at having to type "module reload" to reload everything,
so I'm adding a note that we need to add "reload" back. "module reload" doesn't
really make sense as the command to reload everything, including the core.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208706 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The udptl-updates branch that was merged yesterday failed to properly send back
T.38 SDP responses with the correct error correction mode, if the incoming SDP
from the other end caused us to change error correction modes. This patch
corrects that situation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208548 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207647 | kpfleming | 2009-07-21 08:04:44 -0500 (Tue, 21 Jul 2009) | 12 lines
Ensure that user-provided CFLAGS and LDFLAGS are honored.
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207680 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines
Only do the chan->fdno check in ast_read() in a developer build.
I changed this check to only happen in a dev-mode build. I also added a
comment explaining what is going on. I also made it so that detection of
this situation does not affect ast_read() operation.
(closes issue #14723)
Reported by: seadweller
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206867 | dvossel | 2009-07-16 16:24:16 -0500 (Thu, 16 Jul 2009) | 8 lines
avoid segfault caused by user error
If the CALLERPRES() dialplan function is set to nothing,
a segfault occurs. This is user error to begin with, but
I'd rather see a cli warning message than have Asterisk
crash on me.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces the security events API. This API is to be used by
Asterisk components to report events that have security implications.
A simple example is when a connection is made but fails authentication. These
events can be used by external tools manipulate firewall rules or something
similar after detecting unusual activity based on security events.
Inside of Asterisk, the events go through the ast_event API. This means that
they have a binary encoding, and it is easy to write code to subscribe to these
events and do something with them.
One module is provided that is a subscriber to these events - res_security_log.
This module turns security events into a parseable text format and sends them
to the "security" logger level. Using logger.conf, these log entries may be
sent to a file, or to syslog.
One service, AMI, has been fully updated for reporting security events.
AMI was chosen as it was a fairly straight forward service to convert.
The next target will be chan_sip. That will be more complicated and will
be done as its own project as the next phase of security events work.
For more information on the security events framework, see the documentation
generated from doc/tex/. "make asterisk.pdf"
Review: https://reviewboard.asterisk.org/r/273/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pthread implementations. Casting it to an unsigned int fixes compiler warnings.
Tested on OpenBSD and Linux both 32 and 64 bit
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Park() was not respecting the arguments passed to it. Any extension/context/priority
given to it was being ignored. This patch remedies this.
(closes issue #15380)
Reported by: DLNoah
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While doing some reading about OpenSSL, I noticed a couple of things that
needed to be improved with our usage of OpenSSL.
1) We had initialization of the library done in multiple modules. This has now
been moved to a core function that gets executed during Asterisk startup.
We already link OpenSSL into the core for TCP/TLS functionality, so this
was the most logical place to do it.
2) OpenSSL is not thread-safe by default. However, making it thread safe is
very easy. We just have to provide a couple of callbacks. One callback
returns a thread ID. The other handles locking. For more information,
start with the "Is OpenSSL thread-safe?" question on the FAQ page of
openssl.org.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows applications that request T.38 negotiation on a channel that
does not support it to get the proper indication that it is not supported, rather
than thinking that negotiation was started when it was not.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
