

Why Does Google Hate SIP? - tdfx
http://www.google.com/support/forum/p/voice/thread?tid=286b02abe37dd4cf&hl=en

======
Kylekramer
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.

~~~
rwl
> 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...](http://android-
developers.blogspot.com/2010/12/android-23-platform-and-updated-sdk.html)

~~~
Pyrodogg
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.

------
ChrisOstler
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...](http://www.att.com/gen/public-
affairs?pid=14048&goback=group01&article=home)

[2]: [http://googlepublicpolicy.blogspot.com/2009/09/response-
to-a...](http://googlepublicpolicy.blogspot.com/2009/09/response-to-at-letter-
to-fcc-on-google.html)

------
gst
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).

~~~
trotsky
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?

~~~
viraptor
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.

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

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

