Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Got 2 SIP gateways (ZultysMX250). Sip trunk between them, they are in separate locations, different subnets 192.168.XX and 192.168.YY connected by IPSec VPN.

Some phones work perfectly. But mine... (and I'm the admin.. grrr) is a bit older, and the guys at the other office can all call me OK, but if I call them, they can't hear me, but I can hear them.

Firewall rules on the VPN are identical to the other phones - all the Aastra 53is work, my Zultys 4x4 doesn't.. some of the 2x2s are strangely intermittent... polycom soundstation IP6000 suffers the same problem as well.

Don't suppose anyone can give me an answer, per se - but where should I look next? Could it be a codec issue?

Edit: now been narrowed down to just a particular phone brand (the original Zultys own brand).

share|improve this question
update: eventually had to bin the phone when we vlan'd our voice traffic as it wouldnt do pass-through so well, new phone works fine. Probably every bit of intervening networking has changed since then mind! Oddly none of th eother phones have any problems any more either since we went vlan. – Tom Newton Dec 18 '11 at 11:58

We have run into similar issues before and it is usually due to application layer gateways on the firewall or IPSec devices. These ALGs assist traffic (like SIP or FTP) that use dynamic ports in connecting through NAT devices, and they can also verify that the traffic conforms to protocol specifications.

In my experience, if you are not doing NAT over the VPN (and it looks like you aren't) try disabling ALG's on your firewall/IPSec device.

share|improve this answer

If it was a codec issue, you'd have no audio, because the phones would be unable to send audio between each other.

One way audio is almost always caused by RTP not passing through. Per DLux's statement, turning off SIP ALG or SIP Fixup or SIP Transformation - different routers use different terms for the same thing - is a good first step.

Past that, you'll probably have to capture network traffic using tcpdump or Wireshark to see where the RTP is getting stuck.

You can see what port is being used for audio by looking at the UDP port 5060 traffic. The RTP traffic will typically be in the UDP port range 10000-20000.

share|improve this answer
I'll have to check that. Odd thing is the change in behgaviour depending on "who rings who". Have briefly monkeyed with the RTP starting port on my phone. Will attempt further monkeyage monday. Nothing in firewall logses though :( – Tom Newton May 30 '09 at 22:34
Firewall logs tend to be unreliable, more often then not they show nothing but the firewall still drops (or even works - changes) packets. Capture your traffic, if possible at multiple points. At least you should see if there is any RTP and where it gets lost. Wireshark has some nice tools for SIP & RTP analysis also. – Marie Fischer Jul 24 '09 at 11:58

2 things I would check:

Call setup is handled by the PBX and when the call is established voice traffic is routed directly between handsets... check the network settings on the handset: netmask, default gateway and any additional routes.

MTU size / packet fragmentation. It could be that the VPN or handsets are not liking fragmented packets. Ethernet MTU is 1500 bytes, IPSec VPN will add another 16bytes or so, a DSL line is typically around 1440bytes. From a workstation ping a system at the far network with the "do not fragment" and vary the size down from 1500 until you find a size that works. See Diagnoses and treatment of black hole routers for more info.

share|improve this answer
MTU... could be it. I will give it a shot. Think after that I will have to stick a bridge in front of the sod and tcpdump the traffic. Still working perfectly as long as they cll me -its as soon as I call them that the one-way audio kicks in. – Tom Newton Jun 12 '09 at 7:21
Thanks, this answer saved my day :D, been trying all the alg/sip solutions all day until I found this one and sure, the phones was using static ip and an old obsolete gateway instead of dhcp. – David Mårtensson Sep 21 '15 at 16:27

We've had the issue and the problem was that the PBX (Siemens HG1500) knows one set of codecs and the XLite the other and when XLite called, they negotiated ok, in the other direction not. We've disabled some codecs in the XLite configuration and since that it works.

share|improve this answer
Will give 711 a shot - everyone has that! – Tom Newton May 31 '09 at 11:39

I am not familiar with ZultysMX250. We use Asterisk. But we had a similar one-way audio problem, and the problem was resolved by making sure the Asterisk server had the external IP address listed in its NAT file. As I understand it the SIP protocol carries the IP address to which the return traffic should be passed back. If the NAT firewall is not intelligent enough to alter that in the actual traffic, then the other end tries to send the traffic to an incorrect private address. In the Asterisk server you can enter the IP address to use instead of the local private address in these packets. Also sometimes you have to go into the phone configuration and either enter the external IP address there as well or enter a stun server ip address so that the phone can figure out its own external address.

share|improve this answer

Although an old post there still seems to be no solution to this. This issue is caused by NAT blocking the incoming audio ports. STUN is meant to detect this and modify the SIP packets accordingly. Saying that STUN does not work with a symmetric NAT. There is a way around it though

share|improve this answer

When I've seen this it's always been due to NATing somewhere in the connection. SIP wasn't designed to be NATed and needs various fixups. However this kills all phones and wouldn't explain why some of your phones work and others don't. It might be worth checking there isn't any NATing going on in the connection. Also check that the VOIP module has been configured with the IP address of the phone system. For some reason VOIP modules need to be told what their own IP address is.

share|improve this answer
JR - no NAT whatsoever, we're both on private ranges connected by IPSec VPN. – Tom Newton May 31 '09 at 11:39
Is it possible the VOIP module needs it's own IP address programming in? Apart from that I'm stumped. – John Rennie May 31 '09 at 16:11

I was using Elastix 2.4 and had a very similar problem. Two LANs - one with Elastix in datacenter, two at remote offices. IPSec LAN-LAN VPN between them. If using the LAN-LAN VPN, I would get no audio. However, if the softphone or phone would VPN to the datacenter, then connect, everything was good.

For me, the solution was to go to the FreePBX, and specify the remote LAN segments as "local"

  1. From Elastix menu, select pull down arrow, -> Security, -> Advanced Settings.
  2. Set Enable direct access (Non-embedded) to FreePBX to ON. Save, Return to PBX menu.
  3. Unembedded freePBX -> login -> Tools menu -> Asterisk SIP Settings
  4. Select autoconfigure to populate external IP and local datacenter network.
    Click add local network field (in my case non-datacenter LAN-LAN VPN networks) Add / and /
  5. Save and apply changes
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.