g729 strange problem

Hi all,

I have just installed FreePBX from the easy ISO.

Everything is working and we have since installed 11 g729 codecs.

The strange problem i’m having is that if I call IN, the g729 audio seems to work.

Peer User/ANR Call ID Format Hold Last Message Expiry Peer
xx.xx.xx.xx xxxxxxxxx 476ee91046fcb93 0x0 (nothing) No
192.168.10.254 777 24c4ab957bd6a4a 0x100 (g729) No Tx: ACK 777
192.168.10.254 xxxxxxxxxx 35f01a884b727a9 0x100 (g729) No Rx: ACK

pbx01*CLI> g729 show licenses
0/2 encoders/decoders of 11 licensed channels are currently in use

Anyway, the problem happens when I make the OUTBOUND call via VoipTALK. I see no errors in the logs but do see the below:

Peer User/ANR Call ID Format Hold Last Message Expiry Peer
192.168.10.254 777 96240a70-22d039 0x100 (g729) No Rx: ACK 777
xx.xx.xx.xx xxxxxxxxxx 1eebfc28785c2f8 0x100 (g729) No Tx: ACK VoipTalk

pbx01*CLI> g729 show licenses
0/1 encoders/decoders of 11 licensed channels are currently in use.

I can’t for the life of me work out why it’s only happening the one way… it’s really strange!!

From what I can tell NAT is working as it should because when I make an inbound call, both sides of the audio is working, hopefully this is the correct assumption.

The phones I am using are Cisco SPA 525G and SPA 504G, they are both set to only use G729a, in both phone config, trunk config and extension config.

The Phones are on my LAN, VPN to another office and PBX is NAT’d that end.

192.168.80.* (Phones) | VPN | 192.168.10.* (PBX)

The f/w has ports 10000-20000 UDP and 5060 open and is registered with VOIPTALK.

I’m pretty sure it’s a codec setting as using g711 works fine.

my SIP trunk settings are :

username=xxxx
type=peer
secret=xxxx
insecure=yes
host=voiptalk.org
nat=yes
disallow=all
allow=g729
canreinvite=yes

It worked ONCE quickly and now does not allow me to do on the next call.

Update.

It’s definately codec, changing all trunk/extension and SIP client settings to G711U/A allows traffic flow both ways.

For anybody else that has this problem when operating behind a Cyberoam Firewall.

They come as standard with a SIP module loaded into their framework, this has to be disabled for RTP packets to pass through properly.

From the CLI (on the Cyberoam) run :

cyberoam system_modules sip unload