Gmail phone calls from a technical perspective

This week we received good news from google including phone calling support from gmail.   This feature is far from perfect and we expected it to improve a lot yet (specially in voice quality and integration with gmail site), but it is interesting to try to figure out how it works and how is it integrated with the rest of google communications suite.

Gmail phone calls is a service to make outgoing voice calls from gmail website to international mobile and fixed telephone lines.  The charging and the caller id are integrated with google voice (GV) if available for that google account.

From a technical perspective these are VoIP calls from the web client to the server infrastructure terminating the calls in the telephony network.

Client technology
The client is suppose to be the same application they use for the previous gtalk voice and video feature (in fact I hadn't to install anything new to start making calls).   That software is a native browser plugin scriptable from the web page (details of technology behind previus voice and video calls in gmail)
With a quick traffic sniffing during a call we can see that they are using standard protocolos STUN and RTP and probably the existing XMPP infrastructure for signalling (we have seen some gtalk headers in some HTTP requests) using jingle for session establishment.
Regarding the media we have not investigated the codecs being used (although RTP packets size of 172 bytes in one of the calls could be a probe of G711 usage), but Google indicates that they are integrating GIPS technology ensuring high quality algorithms for media management (buffering, echo cancellation...).

Server technology
Taking into account that charging is integrated with GV, probably all the infrastructure to manage calls and termination to the PSTN is exactly the already existent GV infrastructure.

The only missing part here is the integration of the Gtalk XMPP based client application with the server infrastructure.  Knowing that GV includes SIP interfaces (you can connect with a SIP gizmo client and probably they are interconnecting with carriers with SIP) probably they have implemented just a typical XMPP to SIP gateway to translate XMPP jingle to SIP signalling and perhaps even transcoding voice when needed.



What can we expect in next versions of this feature? Some ideas:
  • Real integration in gmail interface (to call the sender when receiving an email or to call from the contacts view)
  • Integration of this feature in GTalk desktop application or a complete new desktop application to replace gtalk application that hasn't evolved a lot recently
  • Voice conferencing to add more participants to a call and mixing voip and PSTN participants
  • Official VOIP support in Android phones replacing existing PSTN dialer and adding support to voip calls to PSTN, voip calls to google contacts and maybe even voip calls to other providers
What are your predictions for the future of this feature?

Comments

Post a Comment

Popular posts from this blog

Bandwidth Estimation in WebRTC (and the new Sender Side BWE)

Image
Bandwidth estimation is probably the most critical component in the video engine of WebRTC. The bandwidth estimation (BWE) module is responsible for deciding how much video* traffic you can send without congesting the network to prevent degradation of the video quality. In the past bandwidth estimation algorithms used to be very rudimentary and based mostly on packet loss. Basically we used to start increasing slowly the video bitrate until we detected packets being lost.  To detect the packet loss you use the standard RTCP feedback mechanisms where the receiver side reports packet loss periodically using RTCP Receiver Report (RR) messages. Modern bandwidth estimation algorithms are more advanced and try to detect congestion before it is bad enough to make routers discard packets. These algorithms predicts congestion analyzing the delay between packets. The idea is that when you start having some congestion, the buffers in the routers will start filling and the delay will be
Read more

Improving Real Time Communications with Machine Learning

Image
When we talk about the applications of Artificial Intelligence / Machine Learning (AI/ML) for Real Time Communications (RTC) we can group them in two different planes: Service Level : There are many features that can be added to a videoconference service, for example identification of the participants, augmented reality, emotion detection, speech transcription or audio translation .  These features are usually based on image and speech recognition and language processing. Infrastructure Level : There are many ways to apply ML that do not provide new features but improve the quality and/or reliability of the audio/video transmission. Service level applications are fun, but they are more for Product Managers and I like technology more, so in the next sections I will try to describe possible applications of AI/ML for Real Time Communications at Infrastructure Level organizing those ideas in five different categories. Optimizing video quality Some of the ML algorithms used fo
Read more

Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

Image
There are cases when we would like to limit the maximum bitrate being transmitted by WebRTC to avoid wasting resources in the user endpoints or save money reducing the bandwidth usage in our servers.   This is because the maximum bitrate by default in Chrome is around 2Mbps and for many use cases a much lower bitrate provides still pretty good quality.   BTW using a lower bitrate can also help with stability of quality in multiparty scenarios by reducing the amount of competition among different streams. There is no simple API to configure the maximum bitrate in WebRTC (although there is one in ORTC) but there are 3 ways to do this by mangling the SDP. 1. U se the standard  b=AS:BITRATE (Chrome) or b=TIAS:BITRATE  (Firefox) attributes in the SDP for the audio or video channel[1] 2. Use codec specific attributes (this work at least for opus audio codec with maxaveragebitrate property) [2] 3. Use the proprietary x-max-bitrate attribute in the video channel of the SDP answer.  For e
Read more