I recommend enabling Voip ALG on junipers, given u r on a pretty recent os load. Ujjval Karihaloo On Jan 28, 2010, at 6:49 PM, "Carlos Alvarez" <carlos at televolve.com> wrote:

On 1/28/10 12:56 PM, Alex Balashov wrote:

...

What I've seen good salespeople / account reps do, when met noncomprehension of such issues: suggest that the customer bought "cheap" and "consumer-grade" routers that do not support "premium" "voice-grade" services and that they should upgrade to something more "industrial-strength." If the service provider in question happened to resell hardware, it was usually a good upsell opportunity.

Yeah, I guess that's a typical sales person way. However it's unfortunately not true; we see great results with a WRT54G and the most problems are with "enterprise" routers that have SIP-specific junk or hyper-aggressive security that closes ports quickly. We do tell people to turn off the ALG but at some point we run out of potential fixes. Today's fun included explaining why two routers (double NAT) is a Bad Idea, and recurring issues with a supposedly high-end Juniper router.

...

I could never do that because I'm not hardcore. It takes serious gumption to turn an angry customer's conviction that your product is inadequate and deflect it back toward them and convince them that it is their purchasing decisions and ignorance that are, in fact, the essence of what is inadequate here.

I thoroughly enjoy doing that but only when I believe it to be true.

We have wording in our contract about not being liable for their networking issues, but the non-tech users just don't get *what* the network is or even that we use it. We have specifically avoided providing routers because we don't want to own the network and deal with things like companies who want inbound NAT setups and things like that. Maybe what I need is a separate document that customers have to sign off? Dunno.

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

This is a very common case. I actually am more concerned about trying to go through an enterprise-class router than SOHO class Linksys type device because of ALG functions. A misconfigured or default ALG is a sure fire way to mess things up. There was a common case we had along these lines with the Netopia routers ATT was deploying for a long time with its business DSL customers (really anyone with static/multiple IPs). The Netopia had an undocumented SIP ALG that was enabled by default and not mentioned or configurable via the web interface. We had to get into the CLI and disable the ALG every time we tried to set a customer up behind one of these. Basically what happens in the ALG replaces the IPs in the packets with whatever IP is on the router, but didn't translate correctly on the way back in. As for router configurations, there are 3 ways to handle that. Either you manage the router and make the changes for the customer, give them access and say "you break you fix", or segment and pass off a different public IP address to them so they can manage their own firewall. I am big fan of segmentation, but something like that obviously adds complexities and costs. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez Sent: Thursday, January 28, 2010 10:00 PM Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Explaining router/NAT problems to customers On 1/28/10 7:19 PM, Ujjval Karihaloo wrote:

I recommend enabling Voip ALG on junipers, given u r on a pretty recent os load.

I think that's what started the issues on that one. Today the customer finally told us they upgraded the Juniper two weeks ago. Coincidentally around the time the phone issues started. The BYOI model is for the smallest customers so cost is always an issue. We're talking the under 25 handset customer, often 5-10 handsets. At some point I do realize that cheap creates problems. I just have to find the balance. I'm really leaning towards telling these customers that they have to use a router we provide. Like I said, even the WRT has a great track record in this small-company space. The company with the Juniper has ten phones, the Juniper was just a big money-maker for their IT consultants. For those of you who provide a router, what do you tell the customer if they want port forwarding or NAT configurations? -- Carlos Alvarez TelEvolve 602-889-3003 Advanced phone services simplified _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

Ill second the Edgewater recommendation, we have been using them for years now and while I am usually hesitant to describe any product as a silver bullet, when it comes to solving for customer prem issues this is about as close as you can get. That being said, if you are doing residential deployments, or a high volume/low cost model sending our a piece of gear that expensive to every customer just doesn't work and the Edgewater still requires at least some touch to get setup and working right. I have found great success coping with poor CPE and BYOI using a multi-layer approach, such as using non standard ports on adapters and the SBC to dodge ALG's and anti-competitive ISP behavior (if i didn't put the ALG there i don't want it messing with my traffic), a good SBC solution on the access side to handle nat for your now non alg'd traffic, and finally, keeping a STUN server around just for corner cases, such as CPE that still can correctly classify SIP even on non-standard ports, and enforce their ALG, these typically operate on reg-ex replacement of host portion values throughout the packet, so by using stun to pre-mangle in this case you can still dodge the ALG and get your traffic to a known reliable state. I haven't encountered too much in th way of CPE or ISP's that either one or a combination of those techniques wont get around, except just a bad pipe, which there is no cure for except arming the customer with as much info you can provide and sending them to their ISP, and as a result I very, very rarely have to talk a customer up, down or sideways on network gear. On Thu, 2010-01-28 at 19:54 -0500, Scott Berkman wrote:

If they are somewhat technical you can compare to FTP, PPTP, other services that require "ALG", "Fixup", or "Inspection-Policies" on firewalls. The other way you can say it is "firewalls are made to stop attacks, and to some firewalls lots of little RTP (voice) packets look just like an attack" if it's a voice issue.

The better solution is to state BEFORE you ever sell the service that unless you have your own equipment on site that you as the ITSP manage, it's best-effort and that you'll only go so far on support. Doesn't stop them from complaining but at least you can prove it to them if its written into the contract, or pass back off to sales.

For the CPE I'd recommend Edgewater Networks, but the important part is that the device is 1) remotely manageable, 2) allows for signaling captures, and 3) has an ALG that behaves in a predictable (and correct) manner. Then standardize on code and test test test before you ever deploy.

-Scott

-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez Sent: Thursday, January 28, 2010 2:44 PM To: VoiceOps at voiceops.org Subject: [VoiceOps] Explaining router/NAT problems to customers

For those of you who do VoIP services with bring your own internet, I wonder if you have some tips on how to explain to customers that it's their network/router that is causing phones to randomly unregister? I know that from their perspective it's the phone that is broken and we need to fix it. Particularly the less technical ones that really don't even get the fact that these "phones" are just internet devices.

Yes, I understand this is why we "shouldn't" offer BYOI, but we do, and will continue to do so for small customers.