support the new location for zaptel.h and tonezone.h
use the dependency information output by menuselect to build Makefile rules for each module for header files and libraries
combine the common rules into a top-level Makefile.rules file
remove all (now) unnecessary stuff from subdir Makefiles
change translator API so that the newpvt() callback returns an int instead of a pointer (it no longer allocates memory)
alphabetize --with-<foo> options in configure script
enhance Net-SNMP support in configure script to provide a --with-netsnmp option
fix support for --with-pq so that if pg-config is not found when --with-pq is specified, an error will be generated
add 'optional package' usage to modules now that menuselect can output it
allow res_snmp to build by default, since the new loader changes coming soon will solve the function naming problem (and users can disable it via menuselect anyway)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- don't call the byte swapping macros on single byte numbers
- don't do a ++ increment in the argument in the argument to the byte swapping
macros. This gets expanded to incrementing the variable 4 times in a single
operation, which results in undefined (and obviously undesired) behavior. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
allocated. These changes caused crashes when using a channel type that did
not support the jitterbuffer. Instead of fixing why it's crashing, I'm going
to implement this in a better way next week. The way I did it caused a
jitterbuffer to be allocated on every channel where the channel type supported
jitterbuffers, even if they were disabled.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- if the pbx fails to start, set the owner channel of the pvt strucutre
to be NULL
- return immediately if the pbx fails to start so the loop to set all of
the variables from the "setvar" options aren't set as a bunch of global
variables instead
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
so that channels not using a jitterbuffer don't waste as much memory
- ensure that the channel drivers that use jitterbuffers can handle a failure
from configuring a jitterbuffer on a new channel because of a memory
allocation error
- On passing through these channel drivers, configure the jitterbuffer before
starting the PBX thread instead of afterwards. If the pbx fails to start for
whatever reason, this would have caused a crash.
- Also on passing, move the increase of the usecount to after all of the
possible failure conditions in the function
- fix a place where ast_update_use_count() was not called
- ensure that the owner channel pointer of the channel pvt strcutures is set to
NULL in failure conditions
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
subdirectory instead of a for loop
- remove the FORCE target from the main Makefile and add the couple places
I used it to the .PHONY target. .PHONY does the same thing and is a built-in
more efficient way of doing it.
- add a bunch more targets to .PHONY ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- add a copyright header to the build_tools Makefile
- remove 'depend' from the 'all' target in agi/ and utils/ since it is handled
by the main Makefile already
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since they are targets that do not have resulting files and are never listed
as prerequisites to real targets. Using .PHONY in this manner improves make
performance by never having to check for resulting files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
More ideas for developing better video support in Asterisk?
Join the asterisk-video mailing list to help out in the
Asterisk Video Task Force!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* fixed a few inband Alerting issues, sometimes we need to create alerting, some
times it's inband
* beautified the state debugging of misdn_hangup
* removed "real" bchannel activating/deactivating in chan_misdn.c
* fixed "round_robin" bug when there's only 1 port
* added more informative prints when channel could not be created
* changed some warnings to notices
* reworked the whole bchannel state machine stuff,
it is now like in the examples of mISDNuser and therefore a lot easier,
and it is now harder to create bugs
* bchannel_activate/deactivate is now only called in setup/cleanup bc,
they may merge sometime
* it is very important to setup/cleanup the bchannels under the correct
conditions, especially in the NT Side we can only setup the bchannels
when we send a Message!
In the TE side we can only setup the bchannel when we received the channel
of course
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Block fix from 1.2
- Implement part of that fix that was not already implemented, but in a different way
basically, don't cancel destruction when we receive re-transmits.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r34627 | russell | 2006-06-18 16:15:15 -0400 (Sun, 18 Jun 2006) | 5 lines
don't store multiple secrets delimited with semicolons for peers because this
is only valid for users. Instead, only keep the last specified secret for a
peer entry. Also, document how multiple secrets are handled in the sample
config. (Reported by PCadach on #asterisk-bugs)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@34628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* added early bridge-hook, so we know if we need to generate ringing or
can take it from the far end chan_misdn channel (if available)
* fixed the issue, that we may not activate the bchannel on PTMP,
when we receive ALERTING/PROCEEDING/PROGRESS, only on CONNECT. There might
be other PTMP devices and we might disturb their bchannel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@34552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bug reported in the t38 issue report, but by mistake ignored before commit.
Thanks to everyone informing me about this, and Corydon for helping me sort
out sscanf :-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@34217 65c4cc65-6c06-0410-ace0-fbb531ad65f3