Asterisk 13 On Microsoft Azure CentOS 7 Instance Cannot Encode Gsm Via MixMonitor
Hi all
I maintain the above – it was set up by an external party with whom relations have now been severed by my employer.
Quite early after the deployment it became evident that all .gsm audio files produced on this virtual instance at Azure via MixMonitor are corrupt. If you play back the file in an audio player the audio almost sounds reversed and is severely distorted to the extent of being completely unintelligble. You can still convert the file to .wav with SOX, and if you look at the waveform in something like audacity the amplitude all over is near maximum and visually there IS no waveform to see… e. g. apparently the .gsm file itself is valid, but the GSM audio data itself is effectively gibbrerish.
But anyway:
The Asterisk config files and dialplan are identical to 17 other sites where Asterisk 13 is used in the same way as at Azure.
All the other sites are physical bare-metal hardware, and they work fine on the exact same CentOS 7 based setup.
No errors are emitted at any verbosity level (in the Asterisk CLI or the log files) when the Azure CentOS 7 Linux instance is writing corrupt .gsm files.
The problem most definitely is the fact that Asterisk runs in a CentOS 7 instance on a virtual machine in the Azure cloud. Move the exact same config with the same updated CentOS 7 kernel to a physical box, and the corrupt .gsm file problem disappears.
What can possibly be the problem that deploying Asterisk 13 in an Azure instance / VM breaks .gsm encoding?
(I have managed to do a workaround by encoding conversations via MixMonitor to .wav, and then using the MixMonitor hook to convert the .wav back to .gsm with SOX – which works fine.)
Why can SOX on the same Azure instance happily encode .wav to .gsm, but Asterisk “live” via MixMonitor produced corrupt .gsm files, with no errors emitted during encoding?
How can one fix this?
Thanks
Stefan
—
2 thoughts on - Asterisk 13 On Microsoft Azure CentOS 7 Instance Cannot Encode Gsm Via MixMonitor
Hi Stefan,
[snip]
Is the CentOS 7 installation/image the same across your bare-metal hosts and the one on azure? AFAIK there is still no official CentOS 7 image provided by the CentOS Project on the azure marketplace. Instead it’s created by a third party [1]. So there may be differences that could cause issues. On your azure host, check the repo files in /etc/yum.repos.d/. If the mirrorlist/basurl points to openlogic or roguewave than it’s a third-party image. IIRC Amazon and GCP have official CentOS 7 images provided by the CentOS Project. Maybe try one of those to see if the issue persists? Alternatively create your own CentOS 7 VM from the official CentOS 7 repositories using kickstart and try that on azure.
Best, Patrick
[1] https://azuremarketplace.microsoft.com/en-us/marketplace/apps/RogueWave.CentOS76?tab=Overview
—
Hi Patrick
Wow ok thanks. I was not aware of this.
As far as I can determine the Azure VM we’re using was set up on the “stock” CentOS 7 option Azure offers. So you’re correct, it then won’t be an official CentOS 7 image.
The one we are running on our bare-metal hosts IS installed from an official CentOS 7 ISO burned to DVD… then yum updated fully once the base install is done.
This changes things a bit. THANKS!
I’ll try and investigate further. Still wonder what the “RogueWave” or “OpenLogic” repos then have different that -only- GSM encoding doesn’t work in Ast 13.22.0.
Thanks for the help.
Kind regards,
—–Original Message—–
Sent: Friday, 13 September 2019 13:37
From: Patrick Laimbock
To: viljoens@verishare.co.za; asterisk-users@lists.digium.com Subject: RE: [asterisk-users] Asterisk 13 on Microsoft Azure CentOS 7 instance cannot encode gsm via MixMonitor
Hi Stefan,
[snip]
Is the CentOS 7 installation/image the same across your bare-metal hosts and the one on azure? AFAIK there is still no official CentOS 7 image provided by the CentOS Project on the azure marketplace. Instead it’s created by a third party [1]. So there may be differences that could cause issues. On your azure host, check the repo files in /etc/yum.repos.d/. If the mirrorlist/basurl points to openlogic or roguewave than it’s a third-party image. IIRC Amazon and GCP have official CentOS 7 images provided by the CentOS Project. Maybe try one of those to see if the issue persists? Alternatively create your own CentOS 7 VM from the official CentOS 7 repositories using kickstart and try that on azure.
Best, Patrick
[1] https://azuremarketplace.microsoft.com/en-us/marketplace/apps/RogueWave.CentOS76?tab=Overview
—