g729:60 on VM and Physical, Recording sounds funny

Hi there.

Ive had this issue for a long time now, and I have googled and have not found a solution

We need to use g729:60 for my provider, and audio is brilliant both directions. It is also specified in the handset section to use g729:60

However, calls being recorded sound stuttering or as Ive heard other people refer to it as sounding underwater.

Ive done RTP Debugs, and the packets arriving at my pabx and leaving my pabx have the right size and ptime is correct aswell

Ive had this issue elsewhere, and doing a plain old monitor and mixing afterwards provides very happy recordings too, but I cant do this in freepbx.

I have this happening on multiple servers. Some are VMs Some are physical servers. None of them have physical timing devices, but dahdi_test seems to be not too bad either.

Can anyone nudge me in the right direction here?

I assume you’re saying that when a call is recorded, the live audio becomes poor. If it’s only the played-back recordings that sound bad, try capturing a call with tcpdump, then using Wireshark to decode and play the call. Report whether it is any better. http://wiki.wireshark.org/HowToDecodeG729

On calls that are not recorded, are you using canreinvite / directmedia, so audio is bypassing Asterisk and flowing directly between handset and provider? If so, this problem may be with Asterisk’s connectivity, unrelated to what codecs are used.

I don’t know whether this is still true, but older Asterisk versions would decode incoming g729 (so it could record it), but then re-encode the linear PCM back to g729 and send it out. This introduces an additional generation loss and additional jitter on recorded calls. If this is happening on your system, a tcpdump will show forwarded RTP packets with different payload (last 60 bytes) from that of the corresponding incoming packets, only when recording is taking place. If your configuration permits, using ulaw or alaw between handset and PBX may reduce degradation of recorded calls.

I have used a command such as
tcpdump -s 0 -C 100 -W 10 -w rbuf -Z root &
to capture all packet in and out of a PBX for debugging. It does not noticeably degrade Asterisk in any way, and with some effort, you can recover and play audio from any call. If you play back recorded audio only very rarely, this might be a usable substitute for recording in Asterisk. Or, you could write some scripts to automate extraction and saving of WAV files.

Please describe the system and problem in more detail:
Is audio from the remote party heard poorly by the handset user? On the recording?
Is audio from the handset user heard poorly by the remote party? On the recording?
How do calls between extensions sound?
If you have any trunks not using g729, do they sound better?
What kind(s) of extensions are you using? How connected to PBX?
How does PBX connect to provider?
Why is g729 required, e.g. satellite connection to provider, 3G cellular connection to handset, insufficient bandwidth for required number of concurrent calls, high cost per megabyte?
Some general info would also be useful, such as what country you’re in, what countries you are calling or receiving calls from, whether a different provider is a realistic option, etc.

Ok, Just to clarify. The calls are themselves perfect. The recording is where its un clear.

If I use g729 (without a ptime of 60) the recordings are fine.
Our issue is it is a pabx with users scattered around the country, and bandwidth per mb is quite expencive.
So our handsets connect inward with a packetsize of 60 and outward with a packetsize of 60 (which is required by the provider in question.
Doing a tcpdump also confirms that the packets are arriving and leaving with the right packetsize.
Ive tried with “free” version of the codec aswell just to confirm its not a bug with the paid version which we use.

To descibe the audio issue, its usually the audio coming from my handsets which sound stuttery or underwater as ive read some people refer to it

Hope that answers your questions?

Start a tcpdump capture and make a test call, with Asterisk recording it also. Listen to Asterisk’s recording and confirm that audio from the handset sounds poor, as you expect. Open the dump in Wireshark, extract the RTP coming from the handset and decode it, as described in my earlier post.

If playing the resulting file sounds good, we can try to determine why Asterisk is decoding it wrong and fix it. If that proves difficult, you may be able to rig a script to automate extracting and decoding the capture, rather than recording with Asterisk.

However, if the decoded tcpdump also sounds bad, I’m very puzzled. Obviously, the provider is somehow decoding the same packets and presenting quality audio to the remote party. (Actually, are you sure that is true? Perhaps your users are judging call quality based only on what they hear.) Do you see anything “wrong” with the RTP (packet loss, excessive jitter, etc.)?

What kind of handset(s) do you use? How are they connected to the Internet?