Google Voice or Google Talk

Note: this post contains a lot of technical details and aimed to show why do we technically prefer Google Talk over Google Voice. Please be aware that we go deep into protocols, codecs and other technical aspects of voice communication.

Legal disclaimer: Legally Google Voice is “Call Enhancement Service” provided by Google, Inc. It does not provide 911 routing (emergency calling functionality). TalkMe.IM, Inc is not affiliated with Google, Inc.

Technologies are invited to improve our lives. Some of them are doing it better than others, but not necessarily are most popular among users. In order to become most popular great technology should meet great product. It doesn’t happen very often. And it’s pretty rare for a technology to stay on top for many years and even decades.

Google Voice product was introduced in US less than two years ago and brought regular phone communications much closer to the world of computers and Internet. It’s based on GrandCentral which launched in 2005 and acquired in 2007. It lacks several very key features such as 911 routing and cannot replace actual phones, but overall won hearts of millions.

Google Talk product exists since 2005 and today became on of the most popular instant messaging platforms, which uses an open protocol – XMPP. In late 2008 voice and video chat features were added. Later on Google introduced ability to forward calls from Google Voice to Google Talk.

Working with both products we learned underlying technologies. Technically we prefer Google Talk over Google Voice. In our opinion Google Talk is more superior when it comes to media (audio) streams.

Google Talk allows choice of couple dozens audio codecs to use and we picked legacy G711(every VoIP app has to support at least one of its two variations: uLaw or aLaw – we support both), iLBC and Speex. We also introduced tweaked version of Speex with added redundancy, so Talkatone-to-Talkatone calls which use Google Talk can enjoy better clarity and tolerate higher packet loss. Google Voice only supports pure old G711 uLaw.

Is there anything wrong with uLaw (also known as μLaw)? Well, not really. It’s almost uncompressed audio. Actually, just logarithm of PCM which allows it to use 8bits per sample instead of 16bits. It sounds at least as good as normal telephone line. Life is good “on paper” until it meets real usage and biggest problem in VoIP: packet loss. You may know that some network packets may be lost in transit, so other end needs to do something about it. G711 takes an approach of “do nothing” (e.g. play silence instead of missing packet) which leads to clicks or “static noise” during conversation in the best case. However, more advanced codecs such as iLBC and Speex can recover some information from missing packet and provide smoother conversation. Ex. our redundant version of Speex can recover full information from single missing packet.

How bad is the packet loss problem? Lets start with this fact: Even WiFi is considered as bad connection in VoIP world because it leads to packet loss rates around 1%-5%. Yes, such rate can significantly degrade call quality. Packet loss on 3G can easy go above 25%. Call using uLaw codec sounds terrible when packet loss goes above 5%. Words have lots of missing fragments and you barely can hear and understand what the other party says.

One more reason on why uLaw doesn’t perform great is bitrate – payload alone takes 64kbps each way. Include all headers (RTP, UDP and transport layer) and you will be looking in the 80-90+ kbps range, which totals to about 1.2 Megabytes of 3G bandwidth per minute. Not everybody in the world, and we have users in multiple countries, have such fast link. And also, not everybody has unlimited 3G data plans. Speex and iLBС offer way smaller bitrate maintaining comparable quality and exceeding it when it comes to packet loss.

That said, when you are making a VOIP call using 3G network ideally we would always recommend using Google Talk over Google Voice, simply because of sound quality. Well, this world is not perfect. And more often than we’d like it to see Google Voice will be your only choice.

About talkatone
Talkatone marketing

13 Responses to Google Voice or Google Talk

  1. Cole Mickens says:

    I am very interested to understand more of what is going on behind the scenes with Talkatone. Specifically, are you suggesting that pure VoIP calls can be made via Google Voice at the moment? I am aware that Google Talk via Gmail can call out via Google Voice, but that appears to be making an audio call using the GTalk protocol still…

    • talkatone says:

      Yes, we are saying that we make pure Voice over IP calls at this moment.
      The term “Voice over IP” refers that your voice (audio media) is transmitted over data (IP-based) protocol. It does not refer to signalling method used, it refers to media method used (e.g. we use plain RTP, no tricks here).
      You are probably aware that despite SIP (for signaling) is most popular protocol among developers but it is NOT most popular among consumers. So we do not use SIP either (as consumer do not care how signaling is routed).

      In addition, Talkatone establishes connection directly to Google cloud. And you are probably aware that their cloud is very sophisticated and very often one server wears multiple hats – e.g. may be handling Google Voice and Google Talk and just plain Google search at the same time – you never can tell through which server your media is coming.

      And, btw, Google Voice (Grandcentral back then) was always VoIP. They just didn’t have consumer-facing VoIP interface until recently :)

  2. Tze says:

    So I have been trialing talkatone on AT&T 3G network and find that call quality is worse than running skype over the same network and call locations –

    Understand that 3G is worse than a WIFI/hard connection, but was surprised that the google cloud/protocols were not as good as skype –

    Is there a difference in operation here?

    • talkatone says:


      Google Voice is using only uncompressed audio. However Google Talk can do better then Skype. Way better. Skype is using only iLBC and Speex with redundancy should offer better voice quality with lower bandwidth requirements and better tolerance to 3G loss.

      • Tze says:

        Interesting to know – I am trying to understand whether it is G Talk or G Voice that is in use with Talkatone. So I am clear, if I:

        1. Make a call from Talkatone over 3G to a landline – this is using Google Voice?

        2. Receive a call from Talkatone by diverting by Google Voice number to Google Talk (where I call the Google Voice number) – is this therefore using the Google Talk protocols you mention above?

        Oops sorry – 2. is Diverting Google Voice to Google Chat per your FAQ
        Great product by the way!! -

      • talkatone says:


        What it matters – the codec negotiated. And as long as codec negotiation happens with Google Voice (this way or another) the only one codec Google Voice agrees upon is G711/uLaw. This covers scenarios both outbound and inbound calls to/from landlines.

        Pure Google Talk calls are calls to GMail web chat and another Talkatone (and here is important that call does not go through GV, e.g. you dial as chat friend, not as phone number) can use better codecs. (Note: some very well known 3rd party GTalk clients support only G711 for GTalk calls which degrades call quality over 3G).

      • Tze says:

        Understood – thanks! –

        What I still don’t understand though is how do the codecs that talkatone uses differ to Skype in making calls to a landline/cell, or receiving a call from landline/cell

        Talkatone in the above scenario = G711/uLaw
        Skype = ?

        Reason being is that there is a huge difference between Talkatone and Skype in the above application; and yours could be improved by leveraging off how Skype is coded?

      • talkatone says:


        Skype is using probably iLBC for everything.
        We DO support iLBC and moreover, we do support Speex and redundant Speex which offer way better quality.
        But the problem is that the other party needs to support it (e.g. Google Voice termination to phone line).

        E.g. we cannot “parle France” if other party knows “English only”. In situation when we control both sides we can pick whichever “language” (codec) fits better.

  3. Al says:

    Wow, this is fantastic info here. Can you tell me, does other voip companies like fring, truphone, or freecall use the same protocol as skype? My honest humble opinion is that in theory we could have been using voip over internet long time ago but it disturbs monopolists to do their business. It reminds of Tesla’s free ether energy vs big electric monopolist. :)
    Again, I am thankful for your service.

    • talkatone says:


      The call consist from 2 portions:

      1. Signaling. E.g. How 2 phones are finding each other. Most popular (among developers) protocol here is SIP. Which is very easy on server, but not so easy on client. SIP is UDP-based and this means that keep alive packets should be sent every few seconds (while TCP connection requires keep alives once in several hours). Having SIP/UDP based client in background will drain the battery fast. VERY fast.

      Yes, there is SIP/TCP extension but the problem with it is that it’s not so well tested and supported as regular SIP/UDP and still has some drawbacks. For example, we had seen reports that FaceTime is using SIP/TCP.

      Notable exception here is Skype which is NOT using SIP. They use highly-prorpietary protocol for signaling and sued everybody who tried to touch it in any matter. So we will not comment on them in this area.

      2. Real-time media (audio) which usually flows using different channel than signaling (signaling is WAY to expensive to deliver audio packets every 20ms).
      There is only one protocol used by everybody – RTP (except Flash which uses RTMP, but fortunately there is no Flash for iPhone :) ). This is UDP and ideally flows peer-to-peer (but in many cases requires relay server if both caller and callee are behind corporate-grade firewalls/NATs).

      RTP allows “payload” to be encoded using different codecs – such as G711 (aLaw and uLaw – both usually “a must”). Actual codec used for the call is usually negotiated in signaling (e.g. to find “common language” between caller and callee).

      Codecs supported may vary – some a free, some still require royalty payments. For example, there were reports that Skype is using iLBC 30ms and sends 2 audio packets in one network packet (we don’t know if they do it for redundancy or to reduce headers overhead). But namely iLBC is Constant Bit Rate codec which is not optimal for voice conversation – both packet with silence and packet with speech has same size. But regular phone conversation is usually “semi-duplex” (e.g. one person talks, another listens and sends just silence). That’s why we prefer Speex as it has Variable Bit Rate mode which has significant advantage in bandwidth usage over iLBC and in addition it has better packet loss reconciliation algorithm built-in (e.g. speex is predicting very well what was supposed to be in lost packet).

  4. Al says:

    Hey, thats really informative and grasping! Today I have been talking through Whistle and Talkatone and pretty much understood that is written above me. If there are less than 3 bars, your competitor gets more static (actually the whole conversation had some static). I am definitely using your service and will tell others to be involved. Hopefully your server (if there is one) will handle all of us.
    Best regards.

    • talkatone says:


      We really appreciate if you spread the world and no need to worry – Google has great relay servers located very close to end-users and they can handle A LOT of load (it appears that their code is semi-opensourced, so based on what we had seen those servers scale really well).

  5. Pingback: New big update is coming – testers wanted « Talkatone Blog


Get every new post delivered to your Inbox.

Join 233 other followers

%d bloggers like this: