The same problem with the Linksys SPA-2102 failing to register cropped up again today. Despite switching from port 5060 to 5061 last week, it stopped working again today.

Switching up to port 5062 solved the problem immediately. I didn’t try switching down to 5060 to see if that was working again, although maybe I should have. I think my VOIP provider listens on all ports between 5060 and 5080, so if they’re not being reopened I’ll have a little while (at one port per week) before I’m in real trouble, but it will eventually become an issue.

I’ve been thinking about ways to test and see whether Comcast really is interfering with outgoing packets on certain ports, but haven’t come up with anything that seems like a really good test. The Java-based SIP test pages, of which there are many versions around, don’t seem to be cutting it. I could run netcat on a remote host somewhere, but unfortunately, most of the computers I have access to are on Comcast’s own network — so it wouldn’t tell me anything if Comcast is performing filtering at their upstream gateway.

hping seems like it might also be of some use, although I haven’t a clue about how to use it.

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.