<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.1">
</HEAD>
<BODY>
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. <BR>
<BR>
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. <BR>
<BR>
On Thu, 2010-01-28 at 19:54 -0500, Scott Berkman wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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: <A HREF="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</A> [<A HREF="mailto:voiceops-bounces@voiceops.org">mailto:voiceops-bounces@voiceops.org</A>]
On Behalf Of Carlos Alvarez
Sent: Thursday, January 28, 2010 2:44 PM
To: <A HREF="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</A>
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.
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>