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
........
r198957 | seanbright | 2009-06-03 16:39:10 -0400 (Wed, 03 Jun 2009) | 11 lines
Fix a possible crash in pbx_spool.
We were trying to reference members of a struct that had previously been freed.
This patch makes sure that we free the struct after it has been removed from
the spooler queue.
(closes issue #15072)
Reported by: garlew
Patches:
spool.diff uploaded by garlew (license 376)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r198891 | dvossel | 2009-06-03 10:49:46 -0500 (Wed, 03 Jun 2009) | 10 lines
Generic call forward api, ast_call_forward()
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: https://origsvn.digium.com/svn/asterisk/trunk@198892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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 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: https://origsvn.digium.com/svn/asterisk/trunk@198856 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Iax2 currently does not support native bridging if the timeoutms value is set. We check for that in iax2_bridge, but then set timeoutms to 0 by default. If the timeoutms is not provided it is set to -1. By setting timeoutms to 0 it is processed causing a bridging retry loop.
(closes issue #15216)
Reported by: oxymoron
Tested by: dvossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
