Zfone Developers blog

Finally have a chance to make Zfone3 work with Google Talk.  Always was amazed by Google products. I think, optimizing Zfone3 for Google VoIp products would be fan.  Let’s start…

---

Few outlines to define goals and terms of my experiments

The goal of my experiment is to review  Google Talk technologies and find simple way to encrypt Google Talk calls with  Zfone3. The main Idea is to check, how flexible our Zfone Ping approach is.

We saying that Zfone Ping should help as to detect VoIP calls not depending on type of signaling, network transport protocol and without deep understanding internal structure of the target VoIP agent. Google Talk looks like a good chance to check our theory.

PS: I’m using Mac OSX and as result I’m going to play with web based version of Google Talk, built-in into Gmail.

The check-list to review Google Talk on Zfone3 compliance

Using our new Zfone Ping approach it should be simple. To add Google Talk to list of Zfone3-ready clients we should perform several steps:

1. Confirm RTP transport. Check that Google Talk uses RTP as media transport. (I already know this, just want to create full list of requirements);
2. Review control and utility packets. Check does Google uses RTCP, if so - does they much our RTCP validation sources. If they use some other  type of messages we should find way to encrypt them too;
3. Check Signaling Protocol. Review specification Google Talk signaling protocol (XMPP for voice signaling) to find analogue to SIP BYE. Then I will implement trivial  parser to detect such packets and it should help Zfone to close calls properly.
4. Define list of codecs and appropriate RTP payload types.
5. Define specifics of AV conferences using GoogleTalk widgets and find out how to handle most of them in Zonfe. By “specifics” I assume does Google Talk could put call on hold, start/stopmedia during the call, add video stream to existing audio stream and etc.
6. Review additional services provided by the VoIP client and check possibility to encrypt them.

Some Interesting Observations

Before we  start finding answers our list of requirements, there are few interesting outlines about Jingle. The could be helpful for some reasons.

Libjingle developers Guide review:

• libjingle is a kernel library of Google Talk product.
• Jingle could negotiate any kind of transport protocol: UDP or TCP.   Zfone should watch over both of them!
• libjingle uses STUN packets to check latency and keep firewalls opened.
• “Relay Server” could be used instead of P2P connections (see: Connections section of libjingle Developers Guide )
• libjingle intensively uses ICE;
• Transport objects could keep several different types of connection between endpoint and switch between them during the call. Such approach increases robustness and prevents call from closing if one of the possible transport channels is broken or slowed down (see this section for details). We should reproduce this situation and check how will it affect Zfone. The most interesting question: does they change RTP ssrc on changing the transport? If not, which is more likely, - Zfone should be able to handle this.
• Media packets could be wrapped into some pseudo protocols! The documentation says that Voice and Video data doesn’t have pseudo headers but we should be carefully with this. Wrappers could prevent Zfone from seeing media.

Zfone-ready check-list review

Confirm RTP Transport

Yes, Google Talk (libjingle) uses RTP for Audio/Video media transport. Our quick tests confirmed that  Zfone3 is able to detect and extract libjingle RTP streams. We have to be carefully with different variations of libjingle based products  because RTP media packets could be wrapped into some pseudo protocols!

Review control and utility packets

Google Talk uses STUN intensively, but  we don’t encrypt STUN. To detect RTCP activity we should run tests with new version of Zfone or review libjingle sources. Wireshark see no RTP neither RTCP. In any case, if Google Talk uses RTCP - Zfone3 should find and encrypt it.

Check Signaling Protocol

Google Talk uses Jingle as signaling. It defines following algorithm of terminating the session:

“In order to gracefully end the session (which can be done at any point after acknowledging receipt of the initiation request, including immediately thereafter in order to decline the request), either the responder or the initiator MUST send a session-terminate message to the other party.”

<iq from='juliet@capulet.lit/balcony'    id='bv81gs75'

to='romeo@montague.lit/orchard'

type='set'>

<jingle xmlns='urn:xmpp:jingle:1'

action='session-terminate'

initiator='romeo@montague.lit/orchard'

sid='a73sjjvkla37jfea'>

<reason>

<success/>

</reason>

</jingle></iq>

“Upon receiving session-terminate message, the other party MUST then acknowledge termination of the session:”

<iq from='romeo@montague.lit/orchard'    id='h82bs51g'

to='juliet@capulet.lit/balcony'
type='result'/>

“As soon as an entity sends a session-terminate action, it MUST consider the session to be in the ENDED state (even before receiving
acknowledgement from the other party). ”

The protocol looks pretty simple, especially if considering that we don’t even need to parse and validate entire packet. Signaling BYE  is not a order to Zfone to close the call. It just confirms that call agev been closed if there are no media activity on any detected RTP stream.In other words: we would have no serious problems if mistakenly detecting Jingle “session-terminate” message.

We don’t have XML parser library within z-core and don’t need to implement or use it. Iy should be enough implement few trivial dissectors. As example:

1. check if we have <iq and </iq> pair
2. check if we have <jingle and </jingle> pair
3. check if we have action=’session-terminate’

Gmail Google Talk uses secure signaling. I was unable to find  Jingle messages in tcpdump during Google Talk AV calls sniffing. My assumption is: GoogleTalkPlugin uses some IPC mechanism (pipe as example) to talk to Web based GUI, the GUI uses encrypted ssl connection for all Jabber communications (and Jingle as well). In result Jingle traffic is encrypted and Zfone be unable to detect “BYE” packet. I’m going to review jingle and GoogletalkPlugin sources a little bit later, but looks like my assumptions are correct.

So, how to solve the problem?… My propositions is : let’s allow user Manually Close ZRTP  Calls. How will it work: user finished the call and presses “Hung up” button in GT web GUI . Zfone see no media traffic and switches to “ENCRYPTION INTERRUPTED” state. Activity Indicators turn off, Call status icon gets dark. Then the user may just close the call window and Zfone will destroy the call.

I have created a ticket to implement this feature. It will be  available in next version of Zfone3 (v0.35 for Mac).Ok, now we have solution for closing calls with encrypted signaling, but stand-along Google Talk application for Windows may use non-encrypted signaling and we still should implement Jingle “session-terminated” handler.

Zfone should  use both of these approaches: try to close call automatically by looking for session-terminated packet, or manually, by pressing “Close” button.

Define list of codecs and appropriate RTP payload types

As we can’t extract list of codecs from encrypted  signaling on OSX I’m going to try Google Talk for Windows. So, the codecs are: PCMA, PCMU, G.723, iLBC, and Speex, codecs from Global IP Sound: ISAC, IPCMWB, EG711U, EG711A. More detail description is there, at our developers page.

Define specifics of AV conferences

With Gmail Google Talk Audio or AudioVideo conference can be started.  You can’t extend existing Audio call with Video stream. In result Zfone3 have less problems.

“Mute” option is available, but  when it is active some RTP packets are still flowing and Zfone shouldn’t change it’s behavior (it will not switch to ENCRYPTION INTERRUPTED and will not blink with Activity Indicators.)

Conference calls are not supported by Gmail Google Talk. Several parallel calls are not allowed as well.

Review additional services

Google Talk has chat capabilities (it is actually a jabber client) , but we have not deal with  text messages. Yet…

Conclusions and Test Results.

Looks pretty simple: we will add just few lines of code to Zfone and it should work just fine.  Even without control over signaling Zfone does it’s job well.

Good News! It is done! Zfone encrypts Google Talk calls from Gmail!  One more nice icon at Zfone Preferences panel….