[asterisk-bugs] [Asterisk 0013513]: Recording transcoded call with Monitor() uses 4 licenses of G.729

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13513 
====================================================================== 
Reported By:                blitzrage
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   13513
Category:                   Resources/res_monitor
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 140850 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-18 10:24 CDT
Last Modified:              2008-10-30 17:11 CDT
====================================================================== 
Summary:                    Recording transcoded call with Monitor() uses 4
licenses of G.729
Description: 
When recording a call with Monitor() in the dialplan where one end is ulaw,
and the other G.729, it appears that Asterisk utilizes 4 licenses of G.729
in a single call. There may be some sort of optimization that could be done
here, or perhaps there is a reason this needs to happen?

My guess is that Asterisk is converting the ulaw to g.729 before it hits
Monitor(), and is then converting it back to .wav for recording?
====================================================================== 

---------------------------------------------------------------------- 
 (0094449) blitzrage (administrator) - 2008-10-30 17:11
 http://bugs.digium.com/view.php?id=13513#c94449 
---------------------------------------------------------------------- 
Note to me from kpfleming out of band:

lmadsen: ok, so in that scenario, there is translator on the read side of
the ulaw channel, converting its incoming frames to g729 (encoder). there
is a translator on the read side of the g729 channel, converting its
incoming frames to slin (decoder).

there are also two decoders inside the g729 channel, being used by the
monitor streams.

so it is possible that when ast_channel_make_compatible gets called and
one of the channels has a monitor on it, it should take into account the
format that the monitor would like to see and try to produce that format
along the way

but it certainly does not do that today 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-30 17:11 blitzrage      Note Added: 0094449                          
======================================================================