I don't know if turning off access to a clearly in-progress and not meant for public use SIP project that somehow got stumbled upon means Google hates SIP. I think it means they are working on something and will release it when it is done.

I mean, c'mon, Google is building SIP support directly into their phone OS. They aren't against you. Be patient.

I just reused someone elses' thread title for HN. I don't believe (as the original author might) that Google hates SIP. My concern is that they purchased a company with a functional and well-liked product and are shutting it down before they have any alternative to offer.

> I mean, c'mon, Google is building SIP support directly into their phone OS. They aren't against you. Be patient.

According to this [1], SIP support already exists in Android 2.3. I don't know how far this "support" goes (I suppose it's not hooked up to the Google Voice app, at least). And I wonder how many carriers, once they are shipping Android 2.3, are going to leave that code in place and accessible to the user.

I don't want to be too much of a conspiracy theorist here, but I do wonder if Google is dragging their feet on SIP support because of conflicts of interest with Android.

[1] http://android-developers.blogspot.com/2010/12/android-23-pl...

I don't think the conflict is as strong as it once was. Mobile carriers have already begun to 'pivot' to be data providers instead of phone providers with data on the side. I think they'll find a way to get their margins either way and data, including voip calling, might end up being cheaper for them in the long run anyway. I guess that's contingent on if they can innovate fast enough to keep their networks from being crushed.

Its optional support in that the OEM-MOs can not implemented it in their Android OS distribution..

It wouldn't be so bad if it hadn't happened right after they killed Gizmo, which I was relying on for my primary number.

Salt on a wound; ugh.

I don't know, but I am willing to bet it isn't a coincidence that Gizmo5 is shutting down around the same time as hints of SIP for Google Voice #'s is leaking.

Most people seem to be misunderstanding this, but the recently discovered GV+SIP support is not a replacement for Gizmo SIP accounts. It allows other SIP users to call GV numbers transparently, but it doesn't allow SIP clients to act as GV clients purely over VoIP.

Again, I am just purely speculating, but I suspect that the discovered support was just a small part of a full SIP client.

I would also love to see SIP connectivity for Google Voice. That said, the discussion seems to center around the if, and not the why. I suspect that the reason that Google hasn't offered SIP support already is regulatory:

Some time ago, AT&T accused Google of violating telecom regulations by blocking access to certain high cost numbers[1]. Google was able to defend against the accusation by pointing out that they did not actually provide a telecom service, as usage of Google Voice required a normal phone line[2].

I suspect that if (once?) Google provides SIP support, this distinction can no longer be made. What would be the difference between Google Voice and any other SIP provider?

[1]: http://www.att.com/gen/public-affairs?pid=14048&goback=g...

[2]: http://googlepublicpolicy.blogspot.com/2009/09/response-to-a...

While SIP is widespread and the only commonly accepted VoIP standard (besides death protocols such as H.323) the whole protocol is just one big mess.

Google's open XMPP-based Jingle protocol does a much better job at common use-cases. Unfortunately there are only few applications that support it (although Google released the relevant parts as open-source).

This isn't my field at all so I could be wildly off base here, but it seems like Skype does a lot better in the ugly, consumer, ad-hoc real world using TCP. It feels like this is only becoming an even bigger deal in an unpredictable, soupy carrier grade NAT world of IPv4 exhaustion, or do solutions like STUN and ICE hold up? Are there any IETF type standards tracks that take a Skype like approach and support unmanaged mobility, or are we stuck until IPv6 has a significant presence?

It's not about the protocol construction really. SIP is ok and should deal with most NAT problems with ICE support.

Simply because the SIP protocol looks simple and is easy to inspect... a lot of hardware/software will get it wrong. And I mean wrong like not implementing some feature on the phone thus bringing the common supported feature list down, implementing ICE in a wrong way then dropping the product support, breaking basic SIP transactions in a way that the phone doesn't even work without a NAT, etc.

Then router producers come in saying - we're doing home routers - let's help and solve it by doing SIP-ALG and active rewriting on our side. And they get it wrong again. And then they don't think of implementing a way to disable the SIP-ALG (looking at you speedtouch).

All the protocols are there. As long as you stick to one single manufacturer, it's ok. As long as you don't need custom features, it's ok. It's when you want to be good to everyone and support everything - then SIP networks fail because you simply cannot support everything at the same time.

Noone tries to analyse Skype and they control all the clients and servers. Whatever problems they create - they can solve. That's why they do better in many cases. Because you can't even "try" to fix their traffic.

Thanks. It seems like it's Skype's tunneling prowess that I'm impressed with instead of the protocol itself.

Wouldn't say they are exactly steaming along on this project. It's been OVER 2 YEARS!