This work is done by lmadsen, junky and mvanbaak
during AstriDevCon.
This is the second audit the CLI got, and
this time lmadsen made sure he had _ALL_ modules
loaded that have CLI commands in them.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@145121 f38db490-d61c-443f-a65b-d21fe96a405b
Reported by: nickpeirson
The user attached a patch, but the license is not yet
recorded. I took the liberty of finding and replacing
ALL index() calls with strchr() calls, and that
involves more than just main/pbx.c;
chan_oss, app_playback, func_cut also had calls
to index(), and I changed them out. 1.4 had no
references to index() at all.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@144569 f38db490-d61c-443f-a65b-d21fe96a405b
when a file is invalid from when a file is missing. This is most important when
we have two configuration files. Consider the following example:
Old system:
sip.conf users.conf Old result New result
======== ========== ========== ==========
Missing Missing SIP doesn't load SIP doesn't load
Missing OK SIP doesn't load SIP doesn't load
Missing Invalid SIP doesn't load SIP doesn't load
OK Missing SIP loads SIP loads
OK OK SIP loads SIP loads
OK Invalid SIP loads incompletely SIP doesn't load
Invalid Missing SIP doesn't load SIP doesn't load
Invalid OK SIP doesn't load SIP doesn't load
Invalid Invalid SIP doesn't load SIP doesn't load
So in the case when users.conf doesn't load because there's a typo that
disrupts the syntax, we may only partially load users, instead of failing with
an error, which may cause some calls not to get processed. Worse yet, the old
system would do this with no indication that anything was even wrong.
(closes issue #10690)
Reported by: dtyoo
Patches:
20080716__bug10690.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@142992 f38db490-d61c-443f-a65b-d21fe96a405b
fix a bug which caused a crash when a videodevice was
specified after startgui=1 in the config file. This also
involves a slightly different method to determine if the
gui is active or not.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@126572 f38db490-d61c-443f-a65b-d21fe96a405b
- make data member of the ast_frame struct a named union instead of a void
Recently the ast_queue_hangup function got a new parameter, the hangupcause
Feedback came in that this is no good and that instead a new function should be created.
This I did.
The hangupcause was stored in the seqno member of the ast_frame struct. This is not very
elegant, and since there's already a data member that one should be used.
Problem is, this member was a void *.
Now it's a named union so it can hold a pointer, an uint32 and there's a padding in case someone
wants to store another type in there in the future.
This commit is so massive, because all ast_frame.data uses have to be
altered to ast_frame.data.data
Thanks russellb and kpfleming for the feedback.
(closes issue #12674)
Reported by: mvanbaak
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@117802 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r106235 | file | 2008-03-05 18:32:10 -0400 (Wed, 05 Mar 2008) | 4 lines
Add a control frame to indicate the source of media has changed. Depending on the underlying technology it may need to change some things.
(closes issue #12148)
Reported by: jcomellas
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@106239 f38db490-d61c-443f-a65b-d21fe96a405b
console_video.c
This will ease the task of splitting console_video.c into its components
(V4L and X11 grabbers, various video codecs and packetizers, SDL),
as well as ease future extensions (e.g. additional video sources,
codecs and rendering engines).
For the time being nothing changes for users: video support is off by
default, and requires -DHAVE_VIDEO_CONSOLE on the command line to be included
(if SDL and FFMPEG are available).
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@94615 f38db490-d61c-443f-a65b-d21fe96a405b
see description in config.h .
They are a variant of the set of macros i used in chan_oss.c,
structured in a way to be more robust to the presence of
spurious ';' - basically, they define wrappers for 'do {'
and '} while (0)', plus some helper functions to deal with simple
cases such as ast_copy_string, ast_malloc, strtoul, ast_true ...
The prefix (CV_ as 'Config Variable') tries to be easy to remember
and has been chosen to not conflict with other existing macros in the tree.
For the time being, I have only updated the three source files in the
tree that used the old M_* macros. Hopefully, more files will be
converted.
NOTE:
I understand that inventing my own dialect of C is generally wrong;
however, the lack of adequate support in the language encourages
lazy programming practices (such as ignoring errors, bounds, etc.)
and this increases the chance of vulnerability in the code, especially
because we are parsing user input here.
Hopefully, these macros and the use of ast_parse_arg (in config.h)
should encourage the programmer to write more robust code.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@94191 f38db490-d61c-443f-a65b-d21fe96a405b
This is a NOP as far as the current code is concerned,
but there is already support in ./configure and the
Makefiles for the various libraries used by console_video.c
(not yet in the tree) so addition is trivial.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89533 f38db490-d61c-443f-a65b-d21fe96a405b
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89333 f38db490-d61c-443f-a65b-d21fe96a405b
so it can be reused in the implementation of cli commands when
they have a similar syntax.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89320 f38db490-d61c-443f-a65b-d21fe96a405b
This prevents modifying the strings in the stored variables,
and catched a few instances where this was actually done.
Given the differences between trunk and 1.4 (and the fact that this
is effectively an API change) it is better to fix 1.4 independently.
These are
chan_sip.c::sip_register()
chan_skinny.c:: near line 2847
config.c:: near line 1774
logger.c::make_components()
res_adsi.c:: near line 1049
I may have missed some instances for modules that do not build here.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89268 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79174 | file | 2007-08-13 11:18:04 -0300 (Mon, 13 Aug 2007) | 4 lines
(closes issue #10437)
Reported by: haklin
Don't set the callerid name and number a second time on a newly created channel. ast_channel_alloc itself already sets it and setting it twice would cause a memory leak.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@79175 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r60989 | murf | 2007-04-09 12:32:07 -0600 (Mon, 09 Apr 2007) | 1 line
This is a big improvement over the current CDR fixes. It may still need refinement, but this won't have as many folks bothered.
This also adds the mods from 1.4/r.61136;
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@61152 f38db490-d61c-443f-a65b-d21fe96a405b
convert various #if expressions to #ifdef for macros that may not be defined (and where the value is not important)
Note: two of these changes are in bison generated files which is going to be inconvenient when they are regenerated
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@55329 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51311 | russell | 2007-01-19 11:49:38 -0600 (Fri, 19 Jan 2007) | 23 lines
Merge the changes from the /team/group/vldtmf_fixup branch.
The main bug being addressed here is a problem introduced when two SIP
channels using SIP INFO dtmf have their media directly bridged. So, when a
DTMF END frame comes into Asterisk from an incoming INFO message, Asterisk
would try to emulate a digit of some length by first sending a DTMF BEGIN
frame and sending a DTMF END later timed off of incoming audio. However,
since there was no audio coming in, the DTMF_END was never generated. This
caused DTMF based features to no longer work.
To fix this, the core now knows when a channel doesn't care about DTMF BEGIN
frames (such as a SIP channel sending INFO dtmf). If this is the case, then
Asterisk will not emulate a digit of some length, and will instead just pass
through the single DTMF END event.
Channel drivers also now get passed the length of the digit to their digit_end
callback. This improves SIP INFO support even further by enabling us to put
the real digit duration in the INFO message instead of a hard coded 250ms.
Also, for an incoming INFO message, the duration is read from the frame and
passed into the core instead of just getting ignored.
(issue #8597, maybe others...)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@51314 f38db490-d61c-443f-a65b-d21fe96a405b
selectable by how it is called in the dialplan. This allows a speaker
system hooked up to the soundcard to be used for both ring notification,
as well as paging.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@50847 f38db490-d61c-443f-a65b-d21fe96a405b
doing busy-wait on the output audio device.
As it is set now, it tries to push a frame every 10ms,
which is still too frequent but avoids deep restructuring
of the code (which i should do, though).
Note, this is only for ring tones, regular audio coming
from the network is still delivered as soon as it is
available.
Eventually this could well end up in the 1.4 branch, but
since i am probably the only user of chan_oss there isn't
much urgency to do that.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@47822 f38db490-d61c-443f-a65b-d21fe96a405b