(these memleaks stop development of gk codes, now i can continue)
Fix printHandler 'Unbalanced Structure' issues with locking printHandler
data for single thread.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@343281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now that these files are in the tree, they should prefer the tree's local
copy of all Asterisk headers over any that may be installed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254931 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Many architectural and functional changes.
Main changes are threading model chanes (many thread in ooh323 stack
instead of one), modifications and improvements in signalling part,
additional codecs support (726, speex), t38 mode support.
This module tested and used in production environment.
(closes issue #15285)
Reported by: may213
Tested by: sles, c0w, OrNix
Review: https://reviewboard.asterisk.org/r/324/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227898 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?". After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
perfectly fine.
For more information about why a module goes in addons, see README-addons.txt.
chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
