Unable to use recordings made via feature codes

bmartindcs · September 21, 2018, 6:53pm

We’re running the Freepbx Distro, 13.0.195.12 box with Asterisk 13.17.0. Phones are Sangoma S700. Phones and Sip trunks are using G.729 without issue. If we try to use a feature code to record a recording, it works fine and we can play it back from the featurecode without issue. However, the recording is not updated in the “recordings” module nor on the IVR it is used on.

If I click “play” for the recording in the recordings module, I get the following error:

“Unable to find intermediary converter for /var/lib/asterisk/sounds/en/custom/FILENAME.g729 file:/var/www/html/admin/libraries/media/Media/Media.php:299”

Same happens if I try to use the buttons to convert the file to other formats.

If we record the recording with the desktop or a cell phone as a WAV file then upload that in the recordings module, it will work fine. It’s only when we try to use the feature code for the recording does the problem manifest itself.

I confirmed that the res_convert module is loaded/running.

I show that the format_g729 modules are both showing loaded/running as follows:
codec_g729.so g729 Coder/Decoder, based on Intel IPP 0 Running unknown
format_g729.so Raw G.729 data 0 Running core
res_format_attr_g729.so G.729 Format Attribute Module 1 Running core

My google-fu shows one bug report that stated after someone upgraded their modules this started and then support bounced saying it’s a support issue not a bug.

Hoping someone can shed some light on this.

tm1000 · September 21, 2018, 6:58pm

Did you pay for a license for g729?

bmartindcs · September 21, 2018, 9:15pm

No, I thought the patent expired as of last year (and my understanding is it’s now included in SNG7 distro?). I didn’t think this was a codec issue since everything else works. Do I simply need to just upgrade their box to SNG7/FPBX14 then or swap out codec with the bcg one?

Stewart1 · September 21, 2018, 10:23pm

Sorry, I don’t know the solution to your issue, but have a few comments:

You can determine if this is codec-related by setting up a ‘spare’ account on one phone as a new extension, with both phone and extension configured for ulaw or alaw. If feature code recordings are then ok, this can also function as a workaround.

Possibly, whatever forced you onto G.729 is no longer applicable, e.g. you had internet over mobile data, but now have cable. Or, your connection can be upgraded at low cost to accommodate G.711. If so, get rid of G.729 – it sounds awful, especially when the remote party is on a mobile and you have two compression codec generation losses. When you hear the improved voice quality, you’ll think you got new ears.

Unless these recordings are very temporary, e.g. an announcement giving closing hours for a specific holiday, don’t record them through the phone – this is the first impression of your company that customers get; make it a good one. If your budget permits, get Allison to record them; see https://www.sangoma.com/value-professional-voice/ . Not only does she sound great, but the voice will match the other FreePBX prompts. Next step down, see https://www.fiverr.com/gigs/search?query=ivr . If you must record in-house, get your best voice to record on the desktop in a quiet room with a good mic. Open the file in an audio editor (Audacity is a good free one), adjust levels and equalization, edit out unwanted pauses, etc. and then upload to the PBX.

tm1000 · September 21, 2018, 11:08pm

Yes but

That error is happening because it can’t validate the license. It will have to be fixed to not check the license in the code.

Stewart1 · September 21, 2018, 11:23pm

Does that mean that if the license issue were fixed, the G.729 audio from the phone would be converted to slin or wav, then back to G.729 for playing on the trunk? If so, there would be two generation losses of G.729 in what the customer hears. Yuck! One is bad enough.

tm1000 · September 22, 2018, 1:21am

No. That is not what is happening here in this thread, media is passed through Asterisk not PHP. The issue in this thread is about transcoding audio in PHP for playback (you can’t playback g729 in the browser) and because g729 is not licensed there is no valid path to transcode for PHP, to again, playback in the browser only.

Edit: Transcoding a recording through the feature code into g729 also uses PHP and requires a license

Stewart1 · September 22, 2018, 6:33am

But the OP stated:

so it appears that the process of updating the IVR prompt (what he really cares about) is also broken. I would think that if the G.729 audio from the extension was being directly stored, the license shouldn’t matter, just as G.729 pass through to a trunk does not require a license.

tm1000 · September 22, 2018, 6:35am

Edit: Transcoding a recording through the feature code into g729 also uses PHP and requires a license

This statement is just generally incorrect.

Stewart1 · September 22, 2018, 6:47am

If I understand correctly, when a recording is made via the phone, or one is uploaded, it gets converted and stored in various formats. That way, when it is played as an IVR prompt, announcement, etc. it sends whichever format the connected trunk or extension needs, eliminating the need to transcode on the fly and optimizing quality.

If this is working correctly, I’d expect the G.729 audio from the phone making the recording to be used directly as the filename.g729 that the IVR would play on customer calls, which shouldn’t require a license.

tm1000 · September 22, 2018, 6:49am

Transcoding in PHP currently requires a license. Sorry.

Stewart1 · September 22, 2018, 6:54am

So it’s trying to convert to convert the incoming g729 to e.g. ulaw (which requires a license), causing the overall process to fail and leaving the OP without the unconverted g729 version that is all he actually needs?

tm1000 · September 22, 2018, 6:56am

Yes. Because the recording in FreePBX has other codecs enabled. As seen in the code it won’t re-encode the original format it gets to the same format.

github.com

FreePBX/recordings/blob/release/13.0/agi-bin/recordings.agi#L28


      
          $file = preg_replace('/^'.$lang.'\//','',$recfile);
          
          $status = $recordings->fileStatus($file);
          $path = $recordings->getPath();
          if(!empty($status[$lang])) {
          	$agi->verbose("Incoming recording format is ".$format);
          	$filename = $path."/".$recfile;
          	$media->load($filename.".".$format);
          
          	//no need to convert the file as it comes from Asterisk so it's probably 'good'
          	unset($status[$lang][$format]);
          
          	$formats = array_keys($status[$lang]);
          	foreach($formats as $fmat) {
          		if($format === $fmat) {
          			continue; //no need to convert the file as it comes from Asterisk so it's probably 'good'
          		}
          		$media->convert($filename.".".$fmat);
          		$agi->verbose("Converting ".$filename.".".$format." To: ".$filename.".".$fmat);
          	}
          }

In the GUI it is always re-encoded because your definition of what a wav file is is not always what Asterisk wants.

Code is here:

github.com

FreePBX/framework/blob/release/14.0/amp_conf/htdocs/admin/libraries/media/Media/Driver/Drivers/AsteriskShell.php#L79


      
          					//Asterisk 11 should support sln48 but it doesnt, it says it does but then complains
          					//It might be a bug, regardless this is fixed in 13 people should just use it
          					if(version_compare_freepbx($ver,"13.0","lt") && $codec == 'sln48') {
          						continue;
          					}
          					$formats["in"][$codec] = $codec;
          					$formats["out"][$codec] = $codec;
          				}
          			}
          		}
          		$lines = null;
          		exec($loc." -rx 'g729 show licenses'",$lines,$ret);
          		foreach($lines as $line) {
          			if(preg_match('/licensed channels are currently in use/',$line)) {
          				$formats["in"]['g729'] = 'g729';
          				$formats["out"]['g729'] = 'g729';
          			}
          		}
          		$formats["out"]["wav"] = "wav";
          		$formats["out"]["WAV"] = "WAV";
          		$formats["in"]["wav"] = "wav";

Stewart1 · September 22, 2018, 7:06am

Ah, many thanks. So once the license issue gets resolved, it will work properly without any additional quality degradation.

tm1000 · September 22, 2018, 7:09am

I think so. The problem remains (or is worse) when people have downloaded the Digium g729 but don’t have it licensed.

As there are three states of the codec

g729 unlicensed
g729 licensed
g729 open source

It’s hard to tell the difference between the open source and licensed/unlicensed versions.

The open source one is also technically in a grey area, since Digium/Sangoma charge for it’s usage but the internet has an unlicensed version for free, it would seem to violate the agreement between you and Digium when using Asterisk. However, with the merger you probably shouldn’t have to worry about it’s usage anymore*

*I am not a lawyer.

bmartindcs · September 22, 2018, 5:28pm

What you describe makes sense as to WHY. Of course arguing the legality is a topic neither of us have hats for. I also agree with using a better codec like G.711 too, however this specific deployment has bandwidth issues that aren’t being solved anytime soon by the ISP so that was the quick fix.

What about the Linphone/Belledone BCG729 codec? It’s free/open-source and does not use the patented code (which is expired/released now by patent holders anyway) so copyright doesn’t apply here either.

Do you think this php transcode issue will still be present in this case?

Or would simply upgrading to SNG7 eliminate this altogether since g729 is built in?

tm1000 · September 22, 2018, 6:13pm

Yes. The code asks asterisk if it’s licensed. Only the asterisk g729 will work

It’s built in but still isn’t licensed so it wont work

system · September 29, 2018, 6:14pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.