[asterisk-users] Asterisk 13 on Microsoft Azure Centos 7 instance cannot encode gsm via MixMonitor

[Stefan Viljoen]

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