Persistant Incoming Call Failure Issue

Hello,

Looking for some suggestions for improving our Voipo service reliability.

We've had our number with Voipo since 2009, using a PAP2T ATA connected to an analog input on a DECT 6.0 multi-handset cordless phone.

Over the years, there has always been some level of trouble receiving incoming calls, but over the past few months it has gotten to the point where the majority of our incoming calls fail (defined as fail to establish a two-way audio communication).

Outgoing has never been a problem.

Generally, what we have happen is a call will come in, we can hear the other party, but they can't hear us, so we hang up and dial back.

Our Internet provider also since 2009 has been Verizon FIOS. It has been very trouble-free and reliable, both for TV service as well as network speed and stability.

We are provisioned at the Verizon ONT such that the Internet is delivered directly via an Ethernet connection, and the TV signal is delivered via coax to a Cablecard decoder.

From the ONT, the Ethernet connection goes into a router feeding our home network. The PAP2T ATA is behind this router device.

Over the years, I've had various devices in this "router" position such as a Linksys WAP54g (with and without DD-WRT), a Buffalo WZR-300HP (with and without DD-WRT) and a pfSense box.

All these routers have had the same issue of not receiving incoming calls to one degree or another, no matter what configuration settings were tried.

I've followed the advice given here in the forums, and in the troubleshooting guides on the Voipo site.

The ATA is assigned a static IP (by DHCP) and has ports 5004-65000 forwarded to it. I've also tried placing it in the "DMZ" and disabling SIP ALG, when that option is available.

All the network and phone gear is powered and protected by a UPS and aside from when I manually power-down or reset devices, everything stays continuously running.

Along the same lines, I'm not likely to make changes to the router configuration. Often it is several months to years between logging into the devices or making changes or updating firmware.

I've opened several trouble tickets over the years and tried various things, but nothing ultimately seems to permanently solve this lingering issue.

What I'm looking for advice on is what combination of hardware and/or software can I install that will guarantee we will no longer have incoming call failure?

If possible, I'd like to:

• Keep pfSense (or something like it)
• Keep the phone gear behind the router
• Eliminate the ATA and go directly to the cordless phone base (a Siemens Gigaset S675IP)

Whatever the solution, I don't mind if it's fairly technical or a bit complicated to install, but it needs to be stable and able to run with little to no oversight once put into service.


Thanks!


-Russ

Hi Russ:

Ive successfully used pfSense as my routers in several locations including any customer I have. Right now I use three different numbers here at my house, one at the office and one of my customers has a number from Voipo behind her pfSense router which I admin.

The reason your audio is hit and miss comes down to the way SIP and audio are handled with this system. SIP connects to (in the case of Voipo byod) sip.voipwelcome.com but the audio may be coming direct from one of the carriers that Voipo uses. The great thing about this setup is that your RTP or audio is probably coming from a server very close to your location thus latency is reduced over other setups which might use the same server for SIP and RTP.

The drawback is that firewalls don't like what they feel is unsolicited traffic from a strange server (RTP) and thus they block the traffic.

Your using a PAP2. I have one here as well and it works flawless.

First thing I want you to do is to delete any port forwards to your PAP2.

Delete the WAN rules if they do not automatically delete with your NAT rules. We are going to start over.

You should know your ATA's IP address by heart at this point with all your troubleshooting.

YOU DO NOT NEED TO PORT FORWARD WITH pfSense! All the information the SIP server needs is sent to it via your ATA registration.

1. Create a WAN rule with UDP Source 67.228.182.2 (sip.voipwelcome.com) port 5060 (or whatever your pointed at) Destination (your PAP2 LAN address) port 5060 (or whatever have set under port on the ata).
hint- you can find all the port info on the vpanel under connected devices. And yes I do mean your PAP2 LAN address in case your not familiar with WAN rules with pfSense.

2. Restart the ATA. Try and make a call while watching the firewall logs. You should see blocked traffic trying to reach your ATA's RTP ports Linksys default is 16384 - 16482.
hint- I see some from 174.36.46.0/23 and others from 67.228.190.129/25 here on my router. You might see from others.

3. Create a WAN rule with UDP source 174.36.46.0/23 (sub the RTP server you are seeing try and connect here.) port * Destination (your PAP2 LAN address here) 16384 - 16382.

4. Duplicate the last rule for RTP servers as you find them trying to connect. My guess is your will only find one or two RTP servers trying. Sometimes they do change and you will need to be vigilant or-

You could just open up your RTP source to the whole world by using source any/any but Id recommend locking it down. Just takes a little work. If your need screenshots let me know and Ill post some on my server for you.

In my case I did set outbound NAT for my ATA's as static port. I do not believe you need to do this but it is something to keep in mind.

Hi chpalmer,

Thank you very much for the detailed reply, it's much appreciated!

I had seen an older post (I think from you) on the dslreports forum indicating success with pfSense and voipo, so I had hope that this setup was feasible.

Last night while doing some research into this issue I came across some other discussions that the problem is the result of pfSense by default rewriting the source port on all outgoing packets. This is normally considered a "best practice" for security, but sometimes can cause certain applications to work unreliably.

Not sure if this source port rewrite is the cause of my specific problem, but I followed the advice at https://doc.pfsense.org/index.php/Static_Port and created a Advanced Outbound NAT (AON) rule.

Haven't had a chance to fully test this configuration yet, but inbound calls seem to be getting through better now.

I'd like to try your configuration as well, and would very much like to see a few screen shots for reference when you have a chance to collect some.

Again, thank you very much for your help!


-Russ

Yep- I did in fact to the static port to my adapters that you mention. I don't remember needing to but Im kinda old school and wanted to see the port flow though on the states page.

Ive just had a work counterpart turn on a couple of numbers from Voipo and I will be helping him if there are any issues so this should all be pretty fresh in my mind here in the next few days. 8)