Technology / Voip /
02 Feb 2009
Comcast Blocking Port 5060?
Earlier today I ran into a problem with my Linksys SPA-2102 VOIP ATA that strongly suggests Comcast may be intermittently blocking outgoing connections on port 5060, the most common port used for SIP signaling.
The problem stems from the Linksys failing to ‘register’ with the VOIP termination provider, meaning that there’s no dialtone, no way to make outgoing calls, and all incoming calls get forwarded to my backup number. In the 2102’s logs (via syslog running on a separate machine), the following messages are repeated over and over, at about 30s intervals:
Feb 1 06:28:14 192.168.1.150 RSE_DEBUG: unref domain, _sip._udp.callcentric.com
Feb 1 06:28:14 192.168.1.150 RSE_DEBUG: last unref for domain _sip._udp.callcentric.com
Feb 1 06:28:44 192.168.1.150 RSE_DEBUG: reference domain:_sip._udp.callcentric.com
Feb 1 06:29:16 192.168.1.150 RSE_DEBUG: getting alternate from domain:_sip._udp.callcentric.com
Feb 1 06:29:16 192.168.1.150 [0]Reg Addr Change(0) cc0bc025:5080->cc0bc017:5080
Feb 1 06:29:16 192.168.1.150 [0]Reg Addr Change(0) cc0bc025:5080->cc0bc017:5080
Feb 1 06:29:48 192.168.1.150 RSE_DEBUG: getting alternate from domain:_sip._udp.callcentric.com
Feb 1 06:29:48 192.168.1.150 [0]RegFail. Retry in 30
On the surface, this looks like it might be a DNS problem; something
with the SRV records not resolving right. But that can easily be
tested using utilities like dig – and everything checked out fine,
using both my ISP’s DNS servers and publicly-available ones.
Everything seemed to resolve right, and my VOIP provider (Callcentric)
claimed everything was working okay on their end.
Turning on SIP logging in the 2102 gave me some additional information to work with. This feature (called ‘SIP Debug’ and enabled on the ‘Line’ tab when looking at the advanced configuration menus of the 2102) shows the content of the SIP packets being sent out or received by the ATA. As soon as I turned this on, it became clear that there were packets going out every few seconds to the correct addresses, and those packets had the correct information in them (my WAN address) for replies, but nothing was coming back in from Callcentric.
This, at the very least, is pretty suspicious. Unfortunately, it’s
difficult to test and determine exactly where the packets are being
dropped. Sending ICMP “echo request” packets, as the ping utility
does, tests the path to a particular host, but does not test for
port-based filtering along the route.
After several hours of fruitless messing around, and several messages back and forth to Callcentric’s support team (who advised me to update the firmware on the Linksys, to no effect beyond enabling a few options that weren’t there before), I decided to try changing the SIP port. The default – and the one I was using – was port 5060.
As soon as I changed the port from 5060 to 5061, like magic, everything suddenly started working. The Linksys registered, the messages stopped, and I got dialtone.
Nothing within my LAN would have been blocking port 5060, either incoming or outgoing – the Linksys was in the DMZ and the only specifically forwarded ports are in the under-500 range – certainly nothing would have been blocking 5060 but not 5061. (No other port forwards, no UPnP rules, etc.) From all the information I can gather on my end, it certainly looks as though something was stopping the SIP registration packets on port 5060 from getting through, meaning my ATA was sending them out endlessly without getting any response, but wasn’t blocking 5061. This explains why everything ‘just worked’ as soon as I made the change.
It may be that there’s a perfectly reasonable explanation for the blocking, but I can’t think of too many, while I can think of a lot of nefarious ones. Comcast has its own VOIP service, and it would make sense for them to impair the reliability of other offerings in order to make their own – which runs over dedicated channels on the cable infrastructure – seem superior. Googling for “comcast port 5060” shows that I’m not the only one who suspects this. It’s clear they’re not doing it everywhere, but from time to time they seem to decide to close off a particular port to a user without any warning. (Giving them the benefit of the doubt: maybe they have some sort of overzealous automatic system that’s to blame?)
The obvious way to resolve the question would be to call Comcast and see if they’ll admit to blocking anything, but given that it’s a Sunday and that dealing with Comcast always feels like it takes years off my life, I’m probably not going to bother unless 5061 stops working, too. Plus, to really implicate Comcast I’d need to eliminate any possibility of my router being the source of the dropped packets, by connecting the VOIP ATA directly to the cable modem. But that would involve too much disruption for me to really consider it, just to sate my curiosity.
However, if anyone out there is running into the “unref domain” registration-failure error, and it’s clear that it’s not a DNS or LAN/gateway issue, I’d suggest changing the SIP port and seeing if that fixes the problem.
This entry was converted from an older version of the site; if desired, it can be viewed in its original format.