[VoiceOps] Explaining router/NAT problems to customers

[anorexicpoodle]

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.
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20100128/4f4d59ec/attachment-0001.html>