I use a softphone with my voipo account. Over the weekend I installed a new router. As a result, the softphone quit working. It took me 3 days to solve the problem. I thought I would post my problem and solution here in hopes that it will help someone with a similar issue and perhaps save them the many hours I have spent searching for a fix.

My old router was a D-Link WBR1310. Once I had my VOIPO device connected all I had to do was install the softphone software and pretty much use the default settings out of the box and I was good to go.

My new router is a Linksys WRT610N.

I installed this new router and set everything up with no issues. VOIPO was working fine. And then I realized that the softphone was not responding to incoming calls nor would it make outgoing calls. I could occasionally get it to "find home" for a few minutes but then it would lose connection. When it was connected latency could be as long as 30 seconds, calls were one-way. Very erratic and basically unuseable.

I tried everything I could imagine. Realizing this is not a VOIPO issue I had exausted everything I could think of, so I asked support if they would take a look at it. Trying different combinations of settings didn't work. I contacted support for the new Linksys router and the had me open the specific default ports for my softphone in a different way than I had tried as well as having up update the firmware. The softphones locked on briefly but once again lost connection. I installed and tried a different softphone, but this exhibited similar problems.

After considerable searching, I found this:

http://www.voip-info.org/wiki/view/Routers+SIP+ALG

As it explains:

Many of today's commercial routers implement SIP ALG (Application-level gateway), coming with this feature enabled by default. While ALG could help in solving NAT related problems, the fact is that many routers' ALG implementations are wrong and break SIP.

There are various solutions for SIP clients behind NAT, some of them in client side (STUN, TURN, ICE), others in server side (Proxy RTP as RtpProxy, MediaProxy). ALG works typically in the client LAN router or gateway. In some scenarios some client side solutions are not valid, for example STUN with symmetrical NAT router. If the SIP proxy doesn't provide a server side NAT solution, then an ALG solution could have a place.

An ALG understands the protocol used by the specific applications that it supports (in this case SIP) and does a protocol packet-inspection of traffic through it. A NAT router with a built-in SIP ALG can re-write information within the SIP messages (SIP headers and SDP body) making signaling and audio traffic between the client behind NAT and the SIP endpoint possible.
SIP ALG problems

The main problem is the poor implementation at SIP protocol level of most commercial routers and the fact that this technology is just useful for outgoing calls, but not for incoming calls:

•Lack of incoming calls: When a UA is switched on it sends a REGISTER to the proxy in order to be localizable and receive incoming calls. This REGISTER is modified by the ALG feature (if not the user wouldn't be reachable by the proxy since it indicated a private IP in REGISTER "Contact" header). Common routers just mantain the UDP "conntection" open for a while (30-60 seconds) so after that time the port forwarding is ended and incoming packets are discarded by the router. Many SIP proxies mantain the UDP keepalive by sending OPTIONS or NOTIFY messages to the UA, but they just do it when the UA has been detected as natted during the registration. A SIP ALG router rewrites the REGISTER request so the proxy doesn't detect the NAT and doesn't mantain the keepalive (so incoming calls will be not possible).

•Breaking SIP signalling: Many of the actual common routers with inbuilt SIP ALG modify SIP headers and the SDP body incorrectly, breaking SIP and making communication just impossible. Some of them do a whole replacing by searching a private address in all SIP headers and body and replacing them with the router public mapped address (for example, replacing the private address if it appears in "Call-ID" header, which makes no sense at all). Many SIP ALG routers corrupt the SIP message when writting into it (i.e. missed semi-colon ";" in header parameters). Writting incorrect port values greater than 65536 is also common in many of these routers.

•Dissallows server side solutions: Even if you don't need a client side NAT solution (your SIP proxy gives you a server NAT solution), if your router has SIP ALG enabled that breaks SIP signalling, it will make communication with your proxy impossible.
The link provides the list of routers with SIP ALG enabled and guess what?... My new router was on the list:

Linksys
Models: WRV200, WRT610N
NAT type: Symmetrical
Issues:

•The ALG replaces the private address in "Call-ID" header (not needed at all). Some phones (as Linksys with latest firmware) encode the "Call-ID" value in the "Refer-To" header (by escaping the dots) so the private IP appearing there is not replaced with the public IP. This causes that the call transfer fails since the proxy/PBX/endpoint will not recognize the dialog info.
To disable SIP ALG: ToDo no ALG related options found via web and telnet. No idea of how to disable it.

To disable SIP ALG on WRT610N: Web Interface: Administration, Management, under side heading 'Advanced Features' SIP ALG, can be disabled.
I disabled the SIP ALG, opened the default ports specific to my softphone on the router and once again, all is well. You would think this information would be provided somewhere closer to the top! Anyway... I hope it will be of benefit to someone here.