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 (Jay Hennigan)
2. Re: Issues with ISPs blocking SIP 5060 - 5061 (Matt Yaklin)
3. Re: Issues with ISPs blocking SIP 5060 - 5061 (J. Oquendo)
4. Re: Issues with ISPs blocking SIP 5060 - 5061 (Jay Hennigan)
5. Re: Issues with ISPs blocking SIP 5060 - 5061 (Tim Jackson)
6. Re: Issues with ISPs blocking SIP 5060 - 5061 (J. Oquendo)
7. Re: Issues with ISPs blocking SIP 5060 - 5061 (Matt Yaklin)
8. Re: Issues with ISPs blocking SIP 5060 - 5061 (Matthew Crocker)
9. Re: Issues with ISPs blocking SIP 5060 - 5061 (Paul Timmins)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Nov 2013 09:28:01 -0800
From: Jay Hennigan <[email protected]>
To: "J. Oquendo" <[email protected]>, [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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.
--
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
------------------------------
Message: 2
Date: Thu, 21 Nov 2013 12:32:35 -0500 (EST)
From: Matt Yaklin <[email protected]>
To: Jay Hennigan <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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
>
------------------------------
Message: 3
Date: Thu, 21 Nov 2013 11:26:27 -0600
From: "J. Oquendo" <[email protected]>
To: Jay Hennigan <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Thu, 21 Nov 2013, Jay Hennigan wrote:
> 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.
>
Don't you just love that? (All is working except you sux0r).
We had (and have, and sometimes goes back to had) a client
in Fairfield CT. According to the installer, the building
they were in was wretched (wiring, etc.). They'd put in one
T1, we'd slap on VoIP. "Horrible service - you suck!" They'd
move over to another VoIP carrier. Two months later, they'd
move back to us, with another T1 from another carrier to
then come back and tell us: "You suck" (again). This went
on for some time until it finally dawned on them 3 VoIP
carriers later, 4 T1 providers later. "Your infrastructure
is teh suck!"
It becomes difficult in the ITSP/Managed VoIP game to deal
with this. Moreso to find contacts in the carriers who are
willing to even assist when we call on behalf of our clients.
"You're not the client" Moreso, to deal with "networking"
gurus who just seemed to have graduated "Fisher Price My
First Network" academy who fiddle with stuff. Last VoIP
was story...
Two weeks ago. Client with dual connectivity (AT&T Ts and
Comcast)... We fight with getting info into their network
correctly. Wireshark captures galore showed they were
taking IN from AT&T, then sending audio OUT Comcast. We
corrected SIP ALG, NAT, FW garbage on our SBCs. Weeks go
by, all is fine. Client: "Our VoIP is broken you are teh
sucks!"
Gigabytes of Wireshark analysis later... We show then what
is happening which is on their end. Newb IT Guy: "Oh well
the only thing I changed was I turned on IPS for VoIP."
Sigh. I spent about 4-6 hours capturing, analyzing what
was going on (no charge because remember, at the end of the
day it is our fault, since they can still read Twitter).
Painted some nice stick figure captures illustrating the
issue. Result? Still not fixed, kludge was installed to
address their issue.
This was AFTER the initial install where I had already spent
about 3-4 hours trying to assist them with their Astaro FW
cluster^W rules.
--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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
------------------------------
Message: 4
Date: Thu, 21 Nov 2013 09:41:19 -0800
From: Jay Hennigan <[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
On 11/21/13 9:35 AM, Matthew Crocker wrote:
>
>
> I have my SBC configured to listen on port 5060 and a couple other
> non-standard ports. When a customer ISP or firewall ALG gets in the way I
> configure them to use the other ports. It is pretty easy to add additional
> ports to the sip-interface of your acme packet SBC
Sometimes it isn't the port, but the way the CPE deals with UDP,
especially if there's a NAT or firewall you can't tweak.
--
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
------------------------------
Message: 5
Date: Thu, 21 Nov 2013 09:36:24 -0800
From: Tim Jackson <[email protected]>
To: Matt Yaklin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID:
<CAK19Y1e=vnxbzhtmmxhcbmzgxrkqbe_nky2ctzwr4bbdff+...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Nov 21, 2013 at 9:32 AM, Matt Yaklin <[email protected]> wrote:
>
> Will tunneling the sip/rtp packets be more common in the near future
> for SIP phone providers?
>
> matt
>
Why not just run SIP on a nonstandard port?
80/443 seems to work great behind VZW's CGN. This also bypasses 99% of
crappy ALGs in home routers problems for other users.
------------------------------
Message: 6
Date: Thu, 21 Nov 2013 11:31:32 -0600
From: "J. Oquendo" <[email protected]>
To: Matt Yaklin <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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
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
------------------------------
Message: 7
Date: Thu, 21 Nov 2013 12:55:11 -0500 (EST)
From: Matt Yaklin <[email protected]>
To: "J. Oquendo" <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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
>
------------------------------
Message: 8
Date: Thu, 21 Nov 2013 12:35:40 -0500
From: Matthew Crocker <[email protected]>
To: Matt Yaklin <[email protected]>
Cc: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I have my SBC configured to listen on port 5060 and a couple other non-standard
ports. When a customer ISP or firewall ALG gets in the way I configure them
to use the other ports. It is pretty easy to add additional ports to the
sip-interface of your acme packet SBC
-Matt
--
Matthew S. Crocker
President
Crocker Communications, Inc.
PO BOX 710
Greenfield, MA 01302-0710
E: [email protected]
P: (413) 746-2760
F: (413) 746-3704
W: http://www.crocker.com
On Nov 21, 2013, at 12: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
------------------------------
Message: 9
Date: Thu, 21 Nov 2013 13:15:20 -0500
From: Paul Timmins <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131121/37a45e4e/attachment.ksh>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/voiceops/attachments/20131121/37a45e4e/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
End of VoiceOps Digest, Vol 53, Issue 15
****************************************
