SIP Problems



  • Hi everyone,

    we have two different WAN connections and want to use pfSense to do all the routing and failover and stuff. Currently only one line is hooked up to some standard Linux machine doing NAT.

    The problem is, we also have multiple SIP phones in our local network which work fine with our current setup. However, if we use pfSense every incoming call will be dropped after 32 seconds. No problems for outgoing calls (at least none I have found yet).
    I tried what is described here: https://doc.pfsense.org/index.php/VoIP_Configuration except the siproxd solution since, if I understand correctly, it needs a specific outbound connection. This sounds to me that this would break in case of a network outage on our main WAN connection and would make the automatic failover mostly useless.

    Any errors on my part or any ideas you can come up with?

    Thanks in advance,
    Chris



  • edit-  reread and removed question.

    Firewall Rules-

    Do you have any incoming (WAN) firewall rules from your external sip server?

    I see allot of providers recommending port forwarding on soho routers to people who are having troubles.  The reason for this that its what it takes to open the firewall in these devices.  soho devices without firewalls generally work very well for VOIP.  But also let the rest of the world in as well.

    SIP can find its way through NAT.  SIP was not originally designed for NAT but several additions were added later which actually makes it work very well.  The issue can be the firewall in any device.  Look at it this way…  SIP initiates    RTP (the audio streams) take over.

    If the RTP comes from a different IP address your screwed from the start.  But in your case it sounds like your firewall is closing connections.  This is where incoming firewall rules could help.

    Put your SIP devices all in a general space on your LAN.  Build an incoming rule that uses your SIP server and RTP (2 rules if they are seperate) as the source and your SIP clients as the destination  such as 172.16.10.0/29  or even give the SIP devices a different interface and LAN subnet.

    This is true with Siproxd (WAN rule points at WAN address)  or without Siproxd  (WAN rule points at actual LAN address of device(s)



  • I have tried without any special rules as well as allowing all incoming traffic from anywhere (just to be sure). It does not seem to make a difference.

    I suspect the issue is NAT not seeing any traffic on a previously opened (UDP) connection and closing the mapping down, right before the server sends another packet. But if this were the case the "conservative" setting should do some good, as should port forwarding (tried that as well).

    I have to little knowledge of SIP as a protocol and/or BSD to further debug this. Any hints on what I should look at next?

    Chris



  • Here's some things to look at.

    A packet capture is a real help with SIP.  You'll see your internal IP address in the "From" field.  Unless your SIP device has the capability to add a "VIA" field with your external router address, the far end typically will look at the SIP "from" field and send it there.  Unfortunately, that is the internal private address.

    One of the things Sipproxd does is rewrites that field so the return traffic knows to go back to your router IP address.

    Set your device for options keepalive to say 30 seconds.  This will keep the state up and will allow the incoming traffic in.