asterisk users - Sep 2019 - 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