Luigi Rizzo [Sat, 15 Dec 2007 00:30:15 +0000 (00:30 +0000)]
Bring in video console support for chan_oss (and later chan_alsa too).
This is disabled in the default build, you need to explicitly enable it
compiling with
make COPTS=-DHAVE_VIDEO_CONSOLE
In return, you will be able to do a video call with chan_oss, using
the webcam (or X11 grabbing) as local source, and rendering the
incoming stream on your screen. Currently supported formats are
h261, h263, h263+, h264, mpeg4 (all through the avcodec lib, part
of ffmpeg).
Incoming video is on the left, outgoing video is on the right,
while the center displays a keypad (if configured so).
Right clicking on the video windows increases the size,
center clicking reduces the size.
Dragging the mouse (with the left key) on the right window
while the X11 grabber is active moves the grab area.
This is the result of work by Sergio Fadda, Marta Carbone
and myself, all properly disclaimed to digium.
Note, there is a lot of work left to do in this module,
including adding support for Video4LinuxV2 (I have patches
from Matteo Brancaleoni which should be integrated),
and making the GUI a lot more friendly than it is now
(e.g. supporting merging or switching among multiple sources,
a text window, and more).
Mark Michelson [Fri, 14 Dec 2007 21:40:34 +0000 (21:40 +0000)]
Change places where the name "INBOX" was hardcoded to use the imapfolder
setting from voicemail.conf instead. This commit will help to get issue
#11415 moving towards commitment.
Mark Michelson [Fri, 14 Dec 2007 18:47:44 +0000 (18:47 +0000)]
After reading Russell's e-mail to the dev list stating that checking option_verbose is not
equivalent to the check done by ast_verb, I wrote a macro, VERBOSITY_LEVEL, which does this
check. I did a quick look in the source and used this macro in some places where option_verbose
was used.
I also converted some verbose messages in logger.c to use ast_verb instead of ast_verbose.
Russell Bryant [Fri, 14 Dec 2007 17:38:11 +0000 (17:38 +0000)]
Blocked revisions 93000 via svnmerge
........
r93000 | russell | 2007-12-14 11:36:08 -0600 (Fri, 14 Dec 2007) | 7 lines
There are a lot of existing systems that #include non-existent files. So, to
make the transition to treating this as an error a bit less painless, just issue
a huge error message for now. Then, later, we can reinstate the code that treats
it as a failure.
When compiling with DETECT_DEADLOCKS, don't spam the CLI with messages
about possible deadlocks. Instead just print the intended single message every
five seconds.
(closes issue 11537, reported and patched by dimas)
Joshua Colp [Thu, 13 Dec 2007 20:23:48 +0000 (20:23 +0000)]
Move usage of the old LOCAL_USER_* macros to the new ast_module_user_* functions in a few documentation places.
(closes issue #11533)
Reported by: IgorG
Patches:
oldmacroclean.v1.diff uploaded by IgorG (license 20)
Russell Bryant [Wed, 12 Dec 2007 23:44:26 +0000 (23:44 +0000)]
Revert an "optimization" that I added in revision 89887, as the user who reported
issue #11449 has demonstrated that it actually was a performance hit on his
machine. I think that it is possible that it could still be a benefit on systems
under higher load, especially SMP systems, but I don't have enough time or interest
to find out at the moment.
(closes issue #11449)
Tilghman Lesher [Wed, 12 Dec 2007 20:05:13 +0000 (20:05 +0000)]
Conversions of free to ast_free, where applicable, and several other formatting fixes.
Reported by: eliel
Patch by: eliel,tilghman
(Closes issue #11209)
Correctly detect where a dynamic feature was activated. Before this patch,
the channel which initiated the bridge was always assumed to have been the one
which activated the dynamic feature. This patch corrects this.
(closes issue #11529, reported and patched by nic_bellamy)
Mark Michelson [Tue, 11 Dec 2007 22:10:43 +0000 (22:10 +0000)]
Trunk build would fail due to the nonexistence of zaptel hwgain
structures missing. Patched configure to check for this stuff and
put a #ifdef around the offending code in chan_zap. Thanks to file
for overseeing this.
Fix potential memory leak with the dialed interfaces list if another memory allocation fails.
(closes issue #11507)
Reported by: eliel
Patches:
global_datastores.c.patch uploaded by eliel (license 64)
Fixing autofill to be more accurate. Specifically, if calls ahead of the current
caller were ringing members (but not yet bridged) there could be available members
and waiting callers who would not get matched up. The member availability checker
was correctly determining the number of available members in this scenario, but
the queue itself did not parallelly reflect this status on the pending calls. This
commit corrects the issue.
(closes issue #11459, reported by equissoftware, patched by me)
Russell Bryant [Tue, 11 Dec 2007 16:29:29 +0000 (16:29 +0000)]
* In unaligned.h, remove some unnecessary casts and mark the arg of the
get_unaligned functions as const
* In event.c, use get_unaligned_uint32() in a couple of places to fix issues on
architectures that don't allow unaligned access
Add G729A as another possible payload name for G729. Some devices use this instead of G729, which is perfectly normal since the payload number itself is defined and can't be used by anything else so the name doesn't matter that much.
(closes issue #11483)
Reported by: revolution
Patches:
rtp.diff uploaded by revolution (license 346)
If there are no members in a queue, then the loop where the datastore for detecting
duplicate dialed numbers will be skipped, meaning the datastore isn't created. This means
that when we try to free it, there's a crash. This stops that crash from occurring.
(closes issue #11499, reported by slavon, patched by eliel)
Joshua Colp [Mon, 10 Dec 2007 16:07:33 +0000 (16:07 +0000)]
Only send a SIGHUP if the pid is greater than -1, otherwise all PIDs greater than -1 will get the SIGHUP... and that is bad.
(closes issue #11453)
Reported by: alanmcmillan
Avoid reinvite race situations with two Asterisks trying
to reinvite each other in 1.4 and trunk.
This patch implements support for the 491 error code that
Asterisk 1.4 generates on situations where we get an
incoming INVITE and already has one in progress.
Thanks to mavetju for reporting and to Raj Jain for an
excellent explanation of the problem.
Patch by myself. Tested with 8 Asterisk servers connected
to each other in a training network.
Luigi Rizzo [Mon, 10 Dec 2007 08:40:59 +0000 (08:40 +0000)]
remove relative paths and use ASTTOPDIR instead.
Give a default value to ASTTOPDIR if unset so we can at least
do a 'make clean' without too much trouble.
The proper fix, however, is to partition the top level
Makefile in a 'setup' and a 'main' part, in a way that the
'setup' part can be included from subdirs' Makefiles and
allow targets to be built without going through the
top level Makefile.
Luigi Rizzo [Mon, 10 Dec 2007 03:50:38 +0000 (03:50 +0000)]
Put into Makefile.moddir_rules the common instructions used to
generate loadable and embedded module lists.
Individual Makefiles now are a lot simpler, possibly as simple as this:
-include $(ASTTOPDIR)/menuselect.makeopts $(ASTTOPDIR)/menuselect.makedeps
MODULE_PREFIX=cdr_
all: _all
include $(ASTTOPDIR)/Makefile.moddir_rules
and also more flexible because in a single directory we can combine
various types of modules (app_, cdr_, func_, ... ) by simply
listing them in the MODULE_PREFIX variable.
The individual Makefiles can also create list of modules to be
excluded by listing them in the variablel MODULE_EXCLUDE (see an
example in channels/Makefile).
With this change it becomes trivial to integrate a directory with
locally created/modified sources into the main build.
Luigi Rizzo [Sun, 9 Dec 2007 16:47:25 +0000 (16:47 +0000)]
Implement the outcome of a discussion on the -dev list re. the use
of DESTDIR and INSTALL_PATH - many thanks to Tzafrir Cohen and
Simon Perreault for extremely useful feedback:
1. comment out the [directories] section the created asterisk.conf ;
you can set the correct defaults at build time using INSTALL_PATH,
so the repetition here is redundant and often wrong.
(The next step now is move asterisk.conf outside the Makefile to
asterisk.conf.sample, because there is little if anything here
that needs to be constructed at build/install time).
2. use DESTDIR?=$(INSTALL_PATH) so you only need to specify a path
once if the two coincide. This should have no ill side effects,
because if you don't specify DESTDIR, you really need
INSTALL_PATH="" to set the correct defaults, and if you specify
DESTDIR the value is not overridden.
The second part required moving the 'export DESTDIR' right after
the assignment to prevent DESTDIR getting set by the export
(this is documented in the Makefile).o hopefully avoid the mistake)$
With this change you can now do something like this from your source tree:
make INSTALL_PATH=/some/place install samples
and then
main/asterisk -vdc
which will pick up the correct config files and libraries from
/some/place - i.e. great for developers!
Russell Bryant [Fri, 7 Dec 2007 21:25:03 +0000 (21:25 +0000)]
Merged revisions 91830 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91830 | russell | 2007-12-07 15:24:33 -0600 (Fri, 07 Dec 2007) | 5 lines
Make the lock protecting each thread's list of locks it currently holds
recursive. I think that this will fix the situation where some people have
said that "core show locks" locks up the CLI.
(related to issue #11080)
Russell Bryant [Fri, 7 Dec 2007 21:17:52 +0000 (21:17 +0000)]
Merged revisions 91828 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91828 | russell | 2007-12-07 15:17:24 -0600 (Fri, 07 Dec 2007) | 6 lines
Fix another bug in the DEBUG_THREADS code. The ast_mutex_init() function had
the mutex attribute object marked as static. This means that multiple threads
initializing locks at the same time could step on each other and end up with
improperly initialized locks.
(found when tracking down locking issues related to issue #11080)
Russell Bryant [Fri, 7 Dec 2007 21:11:44 +0000 (21:11 +0000)]
Merged revisions 91826 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91826 | russell | 2007-12-07 15:11:08 -0600 (Fri, 07 Dec 2007) | 6 lines
I love fixing lock related errors in the lock debugging code. That's about as
ironic as it gets in Asterisk programming land. Anyway, I spotted this bug while
trying to track down why systems are locking up and acting weird in issue #11080.
The mutex attribute object was marked as static in this function when it should
not have been.
Russell Bryant [Fri, 7 Dec 2007 16:40:41 +0000 (16:40 +0000)]
Merged revisions 91783 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91783 | russell | 2007-12-07 10:38:48 -0600 (Fri, 07 Dec 2007) | 6 lines
* Add channel locking around datastore operations that expect the channel
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Remove the dialed variable as it isn't needed.
* Restructure some code for clarity and coding guidelines stuff
Russell Bryant [Fri, 7 Dec 2007 16:28:36 +0000 (16:28 +0000)]
Merged revisions 91780 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91780 | russell | 2007-12-07 10:25:25 -0600 (Fri, 07 Dec 2007) | 7 lines
* Add channel locking around datastore operations that expect the channel
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Handle memory allocation failure.
* Remove the dialed variable, as it wasn't actually needed.
* Tweak some formatting to conform to coding guidelines.
Russell Bryant [Fri, 7 Dec 2007 16:11:00 +0000 (16:11 +0000)]
Merged revisions 91777 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91777 | russell | 2007-12-07 10:08:35 -0600 (Fri, 07 Dec 2007) | 6 lines
* Add a bit more of a verbose comment as to why a hangup frame needs to be
queued up if autoservice gets a NULL return from ast_read().
* Make the process of queueing the hangup frame more efficient by putting the
frame where it is going to end up and avoiding some locking and extra memory
allocations and freeing.
Hangups that happen during autoservice were not processed appropriately. This is
because a hangup actually causes a NULL frame to be received, not a hangup frame.
Queueing a hangup if we receive a NULL frame during autoservice corrects this problem
(closes issue #11467, reported by jmls, patched by me)
Russell Bryant [Fri, 7 Dec 2007 02:43:21 +0000 (02:43 +0000)]
Merged revisions 91677 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91677 | russell | 2007-12-06 20:38:40 -0600 (Thu, 06 Dec 2007) | 4 lines
Allow dialing local channels from Queue() and Dial() again. There was a slight
flaw in the code to prevent call forwards from looping that caused this problem.
(related to issue #11486)
Russell Bryant [Fri, 7 Dec 2007 02:21:07 +0000 (02:21 +0000)]
Merged revisions 91675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91675 | russell | 2007-12-06 20:19:45 -0600 (Thu, 06 Dec 2007) | 7 lines
Fix in an issue in the call forwarding handling code that was causing crashes
on every call into a queue. I'm not entirely sure about the logic in this part
of the code, so I want to look at it some more tomorrow. However, this makes
it safe and keeps it from crashing.
(closes issue #11486, reported by adamg, patched by me)
At the end of a call, when we're reporting, RTCP may already be partially torn down, so check for NULL dereference
Reported by: blitzrage
Patch by: tilghman
(Closes issue #11450)
projects / thirdparty / asterisk.git / log
