Commit graph

6 commits

Author SHA1 Message Date
David Vossel
c26c190711 Asterisk media architecture conversion - no more format bitfields
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal.  For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal

The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs.  Functionally
no change in behavior should be present in this patch.  Thanks to twilson
and russell for all the time they spent reviewing these changes.

Review: https://reviewboard.asterisk.org/r/1083/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-02-03 16:22:10 +00:00
Tilghman Lesher
317429294c Merged revisions 279472 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r279472 | tilghman | 2010-07-25 22:27:06 -0500 (Sun, 25 Jul 2010) | 2 lines
  
  Formats need to load before apps, because some apps call ast_format_str_reduce() at load time.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-26 03:28:02 +00:00
Tilghman Lesher
b4e18d5660 Add load priority order, such that preload becomes unnecessary in most cases
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-20 19:35:02 +00:00
Russell Bryant
8ab22f5dd0 Set a module load priority for format modules.
A recent change to app_voicemail made it such that the module now assumes that
all format modules are available while processing voicemail configuration.
However, when autoloading modules, it was possible that app_voicemail was
loaded before the format modules.  Since format modules don't depend on
anything, set a module load priority on them to ensure that they get loaded
first when autoloading.

This fix applies to trunk, 1.6.1, and 1.6.2.  The fix for 1.4 and 1.6.0 will
require a different approach since the module load priority functionality is
not present in the module API.

(issue #16412)
Reported by: jiddings


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@233692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-12-08 18:00:16 +00:00
Tilghman Lesher
d8e0c58437 Expand codec bitfield from 32 bits to 64 bits.
Reviewboard: https://reviewboard.asterisk.org/r/416/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-11-04 14:05:12 +00:00
Kevin P. Fleming
2a53f2ec98 Add basic (passthrough, playback, record) support for ITU G.722.1 and G.722.1C (also known as Siren7 and Siren14)
This patch adds passthrough, file recording and file playback support for the codecs listed above, with negotiation over SIP/SDP supported. Due to Asterisk's current limitation of treating a codec/bitrate combination as a unique codec, only G.722.1 at 32 kbps and G.722.1C at 48 kbps are supported.

Along the way, some related work was done:

1) The rtpPayloadType structure definition, used as a return result for an API call in rtp.h, was moved from rtp.c to rtp.h so that the API call was actually usable. The only previous used of the API all was chan_h323.c, which had a duplicate of the structure definition instead of doing it the right way.

2) The hardcoded SDP sample rates for various codecs in chan_sip.c were removed, in favor of storing these sample rates in rtp.c along with the codec definitions there. A new API call was added to allow retrieval of the sample rate for a given codec.

3) Some basic 'a=fmtp' parsing for SDP was added to chan_sip, because chan_sip *must* decline any media streams offered for these codecs that are not at the bitrates that we support (otherwise Bad Things (TM) would result).

Review: http://reviewboard.digium.com/r/158/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-02-13 13:35:24 +00:00