[146356] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Anyone seen this kind of problem? SIP traffic not getting to

daemon@ATHENA.MIT.EDU (Jared Mauch)
Wed Nov 9 16:40:19 2011

From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAPWAtbJGmc2oKUbHxJF-EHNZ0Y+xa_scp_1BGrZdykHVG8vdhA@mail.gmail.com>
Date: Wed, 9 Nov 2011 16:39:08 -0500
To: Jeff Wheeler <jsw@inconcepts.biz>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Nov 9, 2011, at 2:45 PM, Jeff Wheeler wrote:

> On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura <zeusdadog@gmail.com> =
wrote:
>> So my questions is, is it possible there is some kind of filter at
>> Qwest or Level 3 that is dropping traffic only for udp 5060 for =
select
>> few IPs?  That's the only explanation I can come up with other than
>=20
> I ran into exactly this problem last week with Rogers.  All traffic
> from the client except udp/5060 could be received by us, and udp/5060
> was blocked.  We tested other IP addresses on our (provider) side and
> did not find any blocking there, so we assigned a new IP to the SIP
> gateway.  I hardly think this can be an ordinary malfunction, but good
> luck getting a phone company to troubleshoot a problem with their
> subscribers using mobile data to connect to a third-party voice
> gateway=85

I've seen UDP/5060 be intercepted or blocked by various providers.  This
is common in international markets.  If you are doing VoIP over the =
public
internet, it may be worthwhile to invest in software or hardware that
can VPN either 'back' or 'out' to the internet.  I have a PPTP VPN
solution I use to escape various hotel networks.  You can even do an
install on a Linux box with the poptop/pptpd solution.  (Having a
ssh server on tcp/80 and tcp/443 also can help, and is part of 'being
prepared').

- Jared=


home help back first fref pref prev next nref lref last post