Understanding the Classes

Libjingle ships with a few different components to handle different features. The base component is mostly helper classes and utilities for the details of handling networking, encryption, and threading. The classes in the base component are used and extended in p2p and session, which provide further classes for establishing peer-to-peer connections and for maintaining P2P sessions. Finally, xmpp is a simple implementation of the XMPP spec used in the examples to provide basic XMPP-related functionality, like logging in to servers and sending messages to other clients.

There are hundreds of classes intertwined here, and touching on all of them would be impractical, but we'll take a look at some of the most important.

For threading, the main class is, of course, Thread. This class is used throughout the library to provide the ability to give the ability, for example, to send messages asynchronously.

cricket::Thread* thread = new cricket::Thread();
thread->Start();

The Task class provides the basis for the XmppTask class, itself the superclass of a few others. It provides the ability to encapsulate and monitor the status of various types of tasks, such as connecting to a server and sending messages.

     cricket::SessionSendTask* sender =
       new cricket::SessionSendTask(parent, client);
     sender->Send(stanza);
     sender->Start();

On the networking side, NetworkManager represent the networking configuration of the current machine, and in combination with BasicPortAllocator enables the allocation of a port for communications. The BasicPortAllocator enables the SessionManager from the p2p component to connect to the client and establish a session over a given SocketAddress:

cricket::NetworkManager manager 
     = new cricket::NetworkManager();
cricket::SocketAddress stun 
     = new cricket::SocketAddress("stun IP", some_port);
cricket::SocketAddress relay 
     = new cricket::SocketAddress("relay IP", relay_port);
cricket::BasicPortAllocator allocator 
     = new cricket::BasicPortAllocator(manager, stun, relay);

cricket::Thread connectThread = new cricket::Thread();
cricket::SessionManager sessionManager 
     = new cricket::SessionManager(allocator, connectThread);
sessionManager->SignalRequestSignaling.connect(
     clientInstance, &signalingCallbackFunction);
sessionManager->OnSignalingReady();

The stun instance above is how libjingle finds a way to connect to the other Jingle client you'd like to exchange data with. A STUN (Simple Traversal of UDP over NATs) server is a means for two clients, each behind NAT firewalls, to initiate communications. It's like a virtual online meeting place, where the two clients can find each other, exchange information about available ports, and then initiate the appropriate type of communication to successfully negotiate both NATs. Once this negotiation is complete, communication would exclusively be P2P.

The relay instance above is optional and is only needed when two clients cannot negotiate a successful connection. If provided, this would be the address of a relay server to be used should a connection not be able to be established using STUN. This relay server is a computer that exists in the publicly addressable domain; it provides a commonly accessible link between those two clients. The relay in this case is just shuffling messages, enabling the two clients to connect at the cost of adding another link to the chain.

Once you have your session, it's PhoneSessionClient that actually handles the voice communication. This class also handles finding the appropriate media codec on both ends to properly encode and decode audio. PhoneSessionClient maintains a ChannelManager that, with access to a Session, can create, maintain, and destroy voice channels for exchanging audio data over sockets.

This is where the windows compatibility issues start to come into play. An interface called MediaEngine abstracts the codecs and the actual capture and playback hardware on the machine. The only implementation delivered with libjingle uses Linphone, a library that, at least in the implementation provided with libjingle, is not usable under Windows. It would be entirely possible to write a wrapper for a Windows-based media engine and modify the library to utilize it; but as it stands, Windows developers are left out in the cold.

Much Promise

Libjingle has the potential to do for VOIP what GAIM and Trillian, and later protocols like XMPP, did for the IM world. Instead of having to install Skype and Google Talk and ICQ and a dozen other IMs to call all your friends for free, in the not too distant future each will be able to talk with the other, and so you'll only need one. Of course, Google hopes that one will be Google Talk.

There's quite a lot of potential, but quite a lot more work will be needed before we get there.