[VoiceOps] Issues with ISPs blocking SIP 5060 - 5061

[Mike Ray]

We've found with both Bright House and Verizon that at least in Florida they
impose a 5% to 40% packet loss on any PPTP tunnel.  We did migrate several
customers' SIP service to encrypted tunnels, and this is how BH and Verizon
responded.  We have not been able to get them to admit that they are shaping
traffic this way, but we can perfectly see them do it.  Traffic between the
two routers outside the tunnel is 100% perfect, but inside the tunnel
traffic takes this consistent loss.

It seemed like the FCC's Comcast wrist-slapping got reversed, and they are
therefore becoming more bold about doing things like this.

Mike Ray, MBA, CNE, CTE
Astro Companies, LLC
11523 Palm Brush Trail #401
Lakewood Ranch, FL  34202
DIRECT: 941 600-0207
http://www.astrocompanies.com


-----Original Message-----
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Matt
Yaklin
Sent: Thursday, November 21, 2013 12:55 PM
To: J. Oquendo
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061



On Thu, 21 Nov 2013, J. Oquendo wrote:

> On Thu, 21 Nov 2013, Matt Yaklin wrote:
>
>>
>>
>> Will tunneling the sip/rtp packets be more common in the near future 
>> for SIP phone providers?
>>
>> matt
>>
>
>> From the ITSP side (where we provide trunks). Tunnels would
> be a nightmare, so they are a no-no. Now you're throwing in too many 
> variables (Aggressive, Main, set ups, different equipment). Not to 
> mention the overhead it would add to an SBC.
>
>> From the Managed PBX side of the equation... NO, but before
> I ramble on, define tunneling. Tunneling as in VPN? If the



Yes, a VPN tunnel that the CPE/SBC would have to handle and connect back to
a centralized location that the SIP provider controls. Every SIP device
behind the CPE/SBC would have to go through the CPE/SBC.

The reason I mention it was recent SBC installs I did at customer sites had
tunnel options but I am unsure at the moment if it was for site to site
(full mesh setup) connectivity for security reasons or more for getting back
to the provider for alternative reasons.

But the more I think about it... it does add complexity that we would all
like to avoid.

matt



> concern is security, TLS is suitable from the managed PBX side as we 
> can firewall trusted CIDRs on the firewall to prevent 
> recording/tampering.
>
> If you meant VPN tunneling... Would only work on a softphone because I 
> have YET to see any VoIP device (phone, ATA, FXO,
> FXS) have any parameters to set up a tunnel. So I am unsure how one 
> would truly call a VoIP Tunnel in a VPN sense, any kind of true 
> tunneling. (Tunnel in Tunnel maybe, been a while since I dove into 
> CCIP/IE like material.
>
> --
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM
>
> "Where ignorance is our master, there is no possibility of real peace" 
> - Dalai Lama
>
> 42B0 5A53 6505 6638 44BB  3943 2BF7 D83F 210A 95AF 
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF
>
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops