[Home]

Summary:ASTERISK-12752: Recording transcoded call with Monitor() uses 3 licenses of G.729
Reporter:Leif Madsen (lmadsen)Labels:
Date Opened:2008-09-18 10:24:08Date Closed:2011-06-07 14:08:05
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_monitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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?

****** STEPS TO REPRODUCE ******

* Setup two extensions:  100 and 200
* Assign one to ulaw, and the other to G.729 codecs
* Call Monitor() before Dial() in the dialplan
* Run 'show g729' from the CLI

extensions.conf
---------------

[macro-recordcall]
exten => s,1,Noop(${CALLERID(ANI)})
exten => s,n,Set(callrecordingfile=${ARG1}_${ARG2}_${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)})
exten => s,n,Monitor(wav,${callrecordingfile},m)

[default]
exten => _XXX,1,NoOp()
exten => _XXX,n,Macro(recordcall,${CALLERID(num)},${EXTEN})
exten => _XXX,n,Dial(SIP/${EXTEN})


sip.conf
--------

[100]
type=friend
context=default
host=dynamic
disallow=all
allow=ulaw

[200]
type=friend
context=default
host=dynamic
disallow=all
allow=g729

****** ADDITIONAL INFORMATION ******

*CLI>     -- Executing [300@default:1] NoOp("SIP/200-0f735920", "") in new stack
   -- Executing [300@default:2] Macro("SIP/200-0f735920", "recordcall|200|300") in new stack
   -- Executing [s@macro-recordcall:1] NoOp("SIP/200-0f735920", "200") in new stack
[Sep 18 07:19:29] DEBUG[14488]: app_macro.c:337 _macro_exec: Executed application: Noop
   -- Executing [s@macro-recordcall:2] Set("SIP/200-0f735920", "callrecordingfile=200_300_20080918-071929") in new stack
[Sep 18 07:19:29] DEBUG[14488]: app_macro.c:337 _macro_exec: Executed application: Set
   -- Executing [s@macro-recordcall:3] NoOp("SIP/200-0f735920", "200") in new stack
[Sep 18 07:19:29] DEBUG[14488]: app_macro.c:337 _macro_exec: Executed application: Noop
   -- Executing [s@macro-recordcall:4] NoOp("SIP/200-0f735920", "300") in new stack
[Sep 18 07:19:29] DEBUG[14488]: app_macro.c:337 _macro_exec: Executed application: Noop
   -- Executing [s@macro-recordcall:5] Monitor("SIP/200-0f735920", "wav|200_300_20080918-071929|m") in new stack
[Sep 18 07:19:29] DEBUG[14488]: app_macro.c:337 _macro_exec: Executed application: Monitor
   -- Executing [300@default:3] Dial("SIP/200-0f735920", "SIP/300") in new stack
   -- Called 300
   -- SIP/300-0f73d160 is ringing
   -- SIP/300-0f73d160 answered SIP/200-0f735920
show g729
1/3 encoders/decoders of 6 licensed channels are currently in use
Comments:By: Leif Madsen (lmadsen) 2008-09-18 10:24:41

Of note: this was originally reported to me by someone else, and I was able to reproduce it as outlined above.
By: Leif Madsen (lmadsen) 2008-10-14 11:28:20

Pinging this issue and assigning this issue to file because... well... I haven't assigned anything to him today! Would you mind checking this out real quick, and if you can't resolve it, please assign to someone else more appropriate?

Thanks!
By: Leif Madsen (lmadsen) 2008-10-30 11:33:40

Note to self: kpfleming would like to see the output of 'core show channel' on the g729 leg of the call.
By: Leif Madsen (lmadsen) 2008-10-30 17:11:36

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
By: Leif Madsen (lmadsen) 2008-11-18 08:36:19.000-0600

After having a discussion with Kevin and the rest of the development members, there is no change necessarily required here. The behaviour of using multiple channels is exactly what is expected based on the way the code is written today.

If I understand correctly, this is how you get 3 decoder channels (which is a utilization of 3 licenses. You get an encoder and decoder which equals 1 license, then the other 2 decoder channels are the other 2 channels, which totals to 3 liceneses in use):

ulaw --> g729 (1 encoder)
ulaw <-- g729 (1 decoder)

The above is your call. That is utilizing a single license.

The following will be the additional 2 decoders you're using to Monitor() the call.

ulaw --> g729 --> wav  (1 decoder)
ulaw <-- wav <--- g729 (1 decoder)

You may be able to optimize out one of the decoders by using the M() flag in the Dial() application to trigger the Monitor() to happen on the other channel. I have no had a chance to reproduce the issue because I'm having issues with getting my G.729 license to load correctly on my development box. But basically instead of calling the Macro(recordcall,...) before the Dial(), you would do it just before bridging to the other channel with the M() flag.

For now, this issue will remain acknowledged, but it is debatable whether this is really a bug or not. It appears the way this work will not change for the foreseeable future.
By: Leif Madsen (lmadsen) 2008-11-24 15:56:08.000-0600

Suspending this issue as this is a known issue, but there are no plans to have this issue fixed anytime in the near future. Please reopen when there is interest in resolving this issue. Thanks!