Send VoiceOps mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/voiceops
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of VoiceOps digest..."
Today's Topics:
1. Re: Issues with ISPs blocking SIP 5060 - 5061 (Ryan Delgrosso)
2. Re: Issues with ISPs blocking SIP 5060 - 5061 (Mike Ray)
3. Re: Issues with ISPs blocking SIP 5060 - 5061 (Ryan Delgrosso)
4. Re: Issues with ISPs blocking SIP 5060 - 5061 (Marco Teixeira)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Nov 2013 10:54:05 -0800
From: Ryan Delgrosso <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
We see this with alarming regularity. Often it conveniently corresponds
with a marketing push from the MSO for triple play offerings. I recall
this happened at my home when I was with one of those players, and
suddenly my home line on my network stopped being able to talk to my
border elements. The MSO support played the "well youll need to talk to
your ITSP about that, OR you could just switch to our phone service"
card at which point I explained I was my ITSP and then it magically
started to work...
Eventually we just abandoned the usual ports completely. When this
happens to the customer the perception is you suck and the MSO has their
act together because THEIR phone works. Not worth the fight, since you
will have it every promotional cycle and evidence is VERY difficult to
collect.
On 11/20/2013 03:51 PM, David Thompson wrote:
>
> Has anyone been having problems lately with ISPs' actively blocking
> UDP 5060 -- 5061? I'm having problems with Road Runner in Hawaii
> apparently blocking those ports preventing me from communicating with
> the customers PBX. My customer has a ticket open with them but we
> aren't confident that we'll get anywhere with them. If we don't is
> there an authority that we can speak with that can make them open
> those ports or face sanctions?
>
> David Thompson
> Network Services Support Technician
> (O) 858.357.8794
> (F) 858-225-1882
> (E) [email protected] <mailto:[email protected]>
> (W) www.esi-estech.com <http://www.esi-estech.com>
>
>
>
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131121/0eaec4cb/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 21 Nov 2013 13:23:12 -0500
From: "Mike Ray" <[email protected]>
To: "'Matt Yaklin'" <[email protected]>, "'J. Oquendo'"
<[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <0bae01cee6e6$bdeb3ce0$39c1b6a0$@com>
Content-Type: text/plain; charset="us-ascii"
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:[email protected]] On Behalf Of Matt
Yaklin
Sent: Thursday, November 21, 2013 12:55 PM
To: J. Oquendo
Cc: [email protected]
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
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
Message: 3
Date: Thu, 21 Nov 2013 11:17:13 -0800
From: Ryan Delgrosso <[email protected]>
To: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Ditto. We have gone down this path but a few things to be aware of we
have learned.
1: When switching from UDP to TCP for sip you introduce a failure point
on the access side (tcp session). Devices that are rebooted etc will
begin a new TCP session and thus create a new registration. If you are
using a forking proxy this will create an additional registration
orphaning the previous. Depending on your network config rapid reboots
of CPE can have subscribers hitting a cap on concurrent registrations
where under UDP, after reboots they would have resumed the existing one
since there wasnt session state to deal with.
2: You can almost as effectively hide the sip traffic by using different
ports (this also prevents your endpoints from getting slammed regularly
by sipvicious)
On 11/21/2013 10:15 AM, Paul Timmins wrote:
> I keep wanting to just deploy SIP/TLS and SRTP for this. You can't SIP
> ALG what you can't see.
>
> On Thu, 11/21/2013 12:55 PM, Matt Yaklin <[email protected]> wrote:
>
> 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
> [email protected] <mailto:[email protected]>
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131121/92564c8f/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 21 Nov 2013 17:41:52 +0000
From: Marco Teixeira <[email protected]>
To: Matt Yaklin <[email protected]>
Cc: VoiceOps <[email protected]>
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID:
<cad7smbjd3xxbo724t8x95p7apotbtgdo7wkm-e7umzsc2z3...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I thought you might find this usefull:
http://wiki.snom.com/Networking/Virtual_Private_Network_(VPN)
It's a good way to make sure you don't have issues like these, also avoid
bad NAT ALGs and the usual stuff...
The alternative is to use CISCO phones. With recent 9.x firmware, you can
get them to build a VPN to an ASA that could be next to your SIP server.
The licence price for this feature is a "litle" high.
I don't work for neither of them.
---
Cumprimentos / Best regards
Marco Teixeira
email/gtalk/msn: [email protected]
skype: admin-marcoteixeira.com
---
Did you know that Marco Teixeira is an independent, industry expert, senior
consultant ? His expertise is available for hire.
---
On Thu, Nov 21, 2013 at 5:32 PM, Matt Yaklin <[email protected]> wrote:
>
>
> On Thu, 21 Nov 2013, Jay Hennigan wrote:
>
> On 11/21/13 5:36 AM, J. Oquendo wrote:
>>
>> "Getting the carrier..." We try not to inherit
>>> any of the network unless we are managing it. This frees us
>>> from any liabilities associated with say a Doctors office
>>> doing some whacky VPN to a hospital or other. Would take us
>>> too long to perform a network assessment, and make sense of
>>> a client's business needs, especially for free.
>>>
>>
>> It's a balancing act, to be sure. Your customer will of course say that
>> the rest of the Internet works fine, it's just your VoIP service that is
>> failing. "I can get to Google and Yahoo, so there's nothing wrong with
>> my Internet, but your phone doesn't work."
>>
>> For one-off remote phones, setting SIP transport to TCP is often a good
>> workaround by the way.
>>
>>
> Will tunneling the sip/rtp packets be more common in the near future
> for SIP phone providers?
>
> matt
>
>
>
> --
>> Jay Hennigan - CCIE #7880 - Network Engineering - [email protected]
>> Impulse Internet Service - http://www.impulse.net/
>> Your local telephone and internet company - 805 884-6323 - WB6RDV
>> _______________________________________________
>> VoiceOps mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>> _______________________________________________
> VoiceOps mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131121/9f8fe20a/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
End of VoiceOps Digest, Vol 53, Issue 16
****************************************
