Some browser plugins for playing back audio/video can not properly manage when the "Content-Encoding: gzip" which then enables HTTP Chunking, because the original Content-Length provided by PHP is no longer going to be the new Content-Length.
The problem is the streaming audio playback module only places the first HTTP chunk of data it received (or at least only the first few seconds of data).
So this URL /admin/config.php?display=cdr&action=cdr_play&module=cdr&file=cdr_audio.php should ensure that the output is not processed by any Content-Encoding filters setup in Apache.
Browsers that do not support "Content-Encoding: gzip" or those that support it correctly are not affected by this bug. But there are a lot of audio playback implementations out there and a lot of browsers out there that potentially have issues. There is also the matter that different plugins use different browser C/C++ APIs to hook into getting the downloaded data (for example Netscape Plugins, Chrome Pepper, IE ActiveX).
For example FireFox 20 with Apple Quicktime 7.7.3 do not support this correctly.
Affected file: ./modules/cdr/cdr_play.php
commenting out the line in /etc/httpd/conf.d/freepbx.conf:26 "SetOutputFilter DEFLATE" fixes the issue. But impacts global use of the deflate/g-zip module.
Ideally the cdr_play.php should inform Apache not to perform any Content-Encoding or Vary processing on the data.
This will make the feature more robust and it is unlikely that GZIP will improve compress of audio file types anyway, that is why audio domain specific codecs exist. Yes we understand that WAV is not an example of a compression codec.