asterisk

Commit Graph

Author	SHA1	Message	Date
Tilghman Lesher	f59fe83c56	More 32->64 bit codec conversions. In the process of swapping ULAW to a place in the extended codec space, we found several unhandled cases, where a 32-bit integer was still being used to handle a codec field. Most of these have been fixed with this commit, although there is at least one case (codec_dahdi) which depends upon outside headers to be altered before a conversion can be made. (Fixes AST-278, SWP-459) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231850 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Alexandr Anikin	9530310954	Reworked chan_ooh323 channel module. 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	16 years ago
Russell Bryant	c511a26749	Move Asterisk-addons modules into the main Asterisk source tree. 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	17 years ago

Author

SHA1

Message

Date

Tilghman Lesher

f59fe83c56

More 32->64 bit codec conversions.

In the process of swapping ULAW to a place in the extended codec space, we
found several unhandled cases, where a 32-bit integer was still being used to
handle a codec field.  Most of these have been fixed with this commit, although
there is at least one case (codec_dahdi) which depends upon outside headers to
be altered before a conversion can be made.
(Fixes AST-278, SWP-459)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231850 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Alexandr Anikin

9530310954

Reworked chan_ooh323 channel module.

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

Russell Bryant

c511a26749

Move Asterisk-addons modules into the main Asterisk source tree.

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

3 Commits (08fa8a6e5ff18c6013a99ee4ea0906649cc6e96e)