Home / server / Questions / 15116
In Process
Tom Newton
Asked: 2009-05-30 12:39:50 +0800 CST

One way audio on SIP phone on one call direction.. where to look next?

  • 772

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).

site-to-site-vpn sip

8 Answers

  1. 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.

    • 3

  2. 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.

    • 2

  3. 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.

    • 1

  4. 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.

    • 0

  5. 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.

    • 0

  6. 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.

    • 0

  7. 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

    • 0

  8. 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 192.168.8.0 / 255.255.255.0 and 10.243.250.0 / 255.255.255.0
    5. Save and apply changes
    • 0