ZyXEL → Proper Zyxel USG setup for multiple internal VOIP phones?

Hey everyone,

Has anyone here gotten their USG series device working to allow unfettered and working traffic for desk SIP-based VOIP service hosted in the cloud from providers like Vocalocity and RingCentral? My company is on RingCentral and I have customers on Vocalocity, but cannot seem to get settings on the USG line of firewall right to work with multiple desk phones on an internal LAN.

Zyxel support keeps pushing SIP ALG but this feature works initially and then bombs the entire connection as soon as numerous calls start hitting the box. Then it all turns to h#ll. Both Vocalocity and RingCentral publicly advise AGAINST SIP ALG so I'm not sure what to do here.

Zyxel support also mentioned that we could do static port forwards to each desk phone inside the company with differing ports, but that defeats the whole purpose of going with cloud based VOIP. What a pain in the rear end for both myself and the customer.

I hear Sonicwalls don't have these issues, but I don't want to start recommending another brand if I don't have to.

What have others experienced? How do you get your cloud hosted VOIP service working great with the USG series? I have tried to open the entire range of ports for SIP initiation and payload on the firewall, and also attempted to place all of the phones through a single USG port that was designated as a DMZ. No luck.

What's the trick for this, besides using the non-working SIP ALG feature? Any help would be appreciated. I've got a lot of egg on my face for recommending these USG devices in light of how many VOIP issues we have been having at some locations. SOS!

I dont have any experience, have you talked to Tech support (800) 255-4101 ext 5?

I've spent hours on the phone with support and they pretty much admitted that if SIP ALG doesn't work, we have to "go with a more basic router." They also recommended static IP addresses for the desk phones with port forwards to each phone, but this is a lousy cumbersome workaround... so as a company keeps growing and adding desk phones, every single one they expect us to statically assign and port forward? Just doesn't seem logical.

I really don't think that's the answer that big businesses who use VOIP and Zyxel are accepting. There has to be a way to make this work with less headache. I can't imagine Zyxel is just pushing people off to other vendors, as cloud hosted VOIP isn't getting any less popular in the market.

No but dont most VOIPs run off their own equipment (box behind th router)..... If you run it off a cloud, not sure how that would work. Your asking a VPN firewall router to be a vOIP switch based on a cloud??

Companies too cheap to have regular phones, heck I use magjic jack to make free calls to anyone in NA, oops now JP is going to call me from siberia. I use viber to call people in Europe. What the big draw with VOIP. To be honest I see nothing but headaches with that technology. (waits for howls and the deluge of backlash)

Can't speak for your area, but in mine cloud hosted VOIP is booming. Most customers I work with are ditching PBX to move onto the services. They:

1) Are fairly cheap
2) Great quality/features for the price when they work
3) Require zero maintenance

Not sure why it wouldn't be a good idea. I have other clients not on Zyxel boxes that work just fine with cloud VOIP. Zyxel's USG line seems to be the only one that has such major issues. Perhaps it could be related to the way the USG's handle NAT.

Sonicwalls have a feature called "Consistent NAT" that many people claim is the item that allows cloud VOIP to work so well on their boxes.

No idea if it works, but suggestions:

1. Turn off SIP ALG on the USG
2. Enable STUN/TUN or what its called on your phones/voip devices (done on the admin central side?)
3. On the central side, there probably is something in there to enable support for devices behind NAT.
4. In addition research of there is something for heartbeat/keep alive on the phones/voip devices (maybe on the central admin side again)

What is the design of a VoIP call? Well there are two major items, the first is the SIP signaling and the RTP data.

SIP signaling data includes tons of info that the SIP ALG needs to take care, there are multiple fields in there that needs to be rewritten. SIP ALG usually are flacky, since where the fields are in the data can be implementation specific.
So its better to have the central side make the correction anyway, which it can based on the IP headers and SIP C fields (I do not remember 100%, long time since I looked at SIP)

That way it will only look as normal sessions for the USG.

The RTP I do not remember if it actually has any embedded address fields, but it does, this can be fixed by the central side again.

Now the the phase is ofcourse direct calls between two SIP UAC, without a proxy in the middle, here it can get hairy.
But if there is some intelligence in the equipment, then it should be possible for the SIP server to inform the devices what addresses should be used in the IP headers and the other address fields embedded in the SIP info.

Sorry long time ago since I did serious SIP stuff, details have gone missing due to good whiskey

"Perl is executable line noise, Python is executable pseudo-code."

Thanks for the info. I am going to call the provider to see if they can turn on some of these features you mentioned. My Cisco phones DO indeed have STUN support but it seems you need a STUN server to point to. Guess they should have that info.

Do you think just placing the phones into a DMZ would be the best option?

No, not really, since your still doing NAT on the DMZ interface, I assume.