The configure script tests for compiler attributes didn't actually enable
enough warnings or provide a proper test harness to determine whether the
compiler supports the attribute in question or not; this caused gcc 4.1 to
report that it supports 'weakref', but it doesn't actually support it in the
way that is needed for our optional API mechanism. The new configure script
test will properly distinguish between full support and partial support
for this attribute, among others.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk will now automatically ignore incorrect incoming SDP version numbers
when necessary to complete a T.38 re-INVITE operation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200726 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit changes the 'incoming SDP version' check logic a bit more; when
'ignoresdpversion' is *not* set for a peer, if we initiate a re-INVITE to
switch to T.38, we'll always accept the peer's SDP response, even if they
don't properly increment the SDP version number as they should. If this situation
occurs, a warning message will be generated suggesting that the peer's
configuration be changed to include the 'ignoresdpversion' configuration option
(although ideally they'd fix their SIP implementation to be RFC compliant).
AST-221
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix up modules in the 'apps' directory, and also correct the bad example of
enum definitions in include/asterisk/app.h, which many developers followed
(thanks for reading the documentation!). In addition, add some basic usage
examples of the 'pahole' and 'pglobal' tools to the coding guidelines.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These modules all contained variables that are module-global but not system-global,
but were not marked 'static'.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using the 'pahole' tool, it is now quite easy to see where structure fields
could be organized differently to keep the compiler from having to add
padding to satisfy alignment requirements. These changes reduced the sizes of
sip_pvt and sip_peer by a few bytes each (on 64-bit platforms), and also fixed
a spelling error in a field name.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides a new implementation of the optional API support defined
in asterisk/optional_api.h; this new version provides solves compatibility
issues with the use of linker version scripts for suppressing global symbols.
In addition, there is now a functional (and tested!) implementation for Mac OS/X,
so module writers no longer need to use special tests before calling optional
API functions. All future implementations must provide these same semantics,
so that module writers can rely on them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This works relatively well (assuming you are using /var/run/asterisk) as your
run directory and upstart 0.3.9. Needs to be generalized and eventually added
to the 'make install' target for Ubuntu.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When allocating the channel use ao2_ref(-1) to release it, instead of calling
ast_free().
Also avoid freeing structures inside that channel (on error) if they will be
released by the channel destructor being called if the reference counter reachs
0.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the definition of new_find_extension(), the arguments 'callerid' and
'label' were swapped. The prototype declaration and all calls to the
function are ordered 'callerid' then 'label', but the function itself
was ordered 'label' then 'callerid'.
(closes issue #15303)
Reported by: JimDickenson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also I removed an unnecessary free of a cid_name. This will be freed properly
in the channel destructor.
Reported by mnicholson in #asterisk-dev.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP's cli NOTIFY command only used UDP rather than copying the transport type from the peer.
(closes issue #15283)
Reported by: jthurman
Patches:
sip-notify-tcp-svn199728.patch uploaded by jthurman (license 614)
Tested by: jthurman, dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized. The lower the value, the higher the priority. The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set. If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority
on load. Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty.
(closes issue #15191)
Reported by: alecdavis
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/262/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199743 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r199626 | seanbright | 2009-06-08 15:24:32 -0400 (Mon, 08 Jun 2009) | 21 lines
Increase the size of our thread stack on 64 bit processors.
We were setting the stack size for each thread to 240KB regardless of
architecture, which meant that in some scenarios we actually had less available
stack space on 64 bit processors (pointers use 8 bytes instead of 4). So now we
calculate the stack size we reserve based on the platform's __WORDSIZE, which
gives us:
32 bit -> 240KB
64 bit -> 496KB
128 bit -> 1008KB (that's right, we're ready for 128 bit processors)
Patch typed by me but written by several members of #asterisk-dev, including
Kevin, Tilghman, and Qwell.
(closes issue #14932)
Reported by: jpiszcz
Patches:
06052009_issue14932.patch uploaded by seanbright (license 71)
Tested by: seanbright
........
r199628 | seanbright | 2009-06-08 15:28:33 -0400 (Mon, 08 Jun 2009) | 2 lines
Fix a typo in the stack size calculation just introduced.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move MusicOnHold, SetMusicOnHold, StartMusicOnHold, StopMusicOnHold static
documentation to the new AstXML form.
(issue #15245)
Reported by: eliel
Patches:
res_musiconhold_static_conversion.txt uploaded by lmadsen (license 10)
(with some fixes and formatting by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move function PP_EACH_USER and PP_EACH_EXTENSION documentation to the new
AstXML form.
(issue #15245)
Reported by: eliel
Patches:
res_phoneprov_static_conversion.txt uploaded by lmadsen (license 10)
(with PP_EACH_USER add by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move function MEETME_INFO static documentation to the new AstXML form.
(issue #15245)
Reported by: eliel
Patches:
app_meetme_static_conversion.txt uploaded by lmadsen (license 10)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move function MINIVMACCOUNT and MINIVMCOUNTER statis documentation to the new
AstXML form.
(issue #15245)
Reported by: eliel
Patches:
app_minivm_static_conversion.txt uploaded by lmadsen (license 10)
(with minor changes by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move function SYSINFO static documentation to the new AstXML form.
(issue #15245)
Reported by: eliel
Patches:
func_sysinfo_static_conversion.txt uploaded by lmadsen (license 10)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199374 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r199297 | dvossel | 2009-06-05 16:19:56 -0500 (Fri, 05 Jun 2009) | 14 lines
Fixes issue with hints giving unexpected results.
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: https://origsvn.digium.com/svn/asterisk/trunk@199298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since a DAHDI channel may belong to multiple groups, we need to use
a bitwise and instead of equivalence to determine whether to display
the channel information.
(closes issue #15248)
Reported by: gentian
Patches:
15248.patch uploaded by mmichelson (license 60)
Tested by: gentian
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r199022 | seanbright | 2009-06-04 10:14:57 -0400 (Thu, 04 Jun 2009) | 40 lines
Safely handle AMI connections/reload requests that occur during startup.
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: https://origsvn.digium.com/svn/asterisk/trunk@199051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kevin P. Fleming
Russell Bryant
Mark Michelson
Moises Silva
Sean Bright
Eliel C. Sardanons
Leif Madsen
David Brooks
David Vossel
Tilghman Lesher