Contents |
Telephony and Instant Messaging subsystem includes development of realtime communications such as voice (CS calls, VoIP audio calls), video (VoIP video calls), presence information, SMS and instant messaging.
Supported protocols include Jabber, XMPP, Jingle/Google Talk, SIP, and cellular telephony (SMS and CS call).
Note that CS video would also fall to this domain, but it is not in the current roadmap.
Summary of the most important features:
Telepathy is a flexible, modular communications framework that enables real-time communication via pluggable protocol backends using a unified D-Bus API. It allows multiple applications to reuse protocol connections in order to to access contact information, request a communications channel, or collaborate contact-to-contact. Binding libraries for GLib and Qt4 are provided to simplify using the API by applications.
The real-time communication capabilities supported by each protocol, such as presence, contact lists, text chat, voice and video over IP, file transfer, etc. are implemented by protocol-specific connection managers. The user's configured IM accounts are managed by Mission Control, which also deals with launching appropriate user interface components to handle incoming or outgoing communication channels.
The Telepathy framework itself does not provide any user interface components; these are platform-specific and depend on a particular UI framework and other platform facilities. Each backend and client runs in a separate process, improving resilience to errors in each component, including separating UI components from network components potentially exposed to remotely-exploitable bugs.
For cross-platform developer offering in UI development, Qt Mobility (QtM) APIs are being developed by the Qt project. The domains of interest are Messaging, Presence, and Telephony. Current version of QtM Messaging API does not support IM. QtM Telephony and QtM Presence APIs are under development.
Full-featured call and messaging applications are suggested to be implemented based on the Telepathy interface bindings and utilities library for Qt (telepathy-qt4).
The control points for sending SMS and making CS calls are guarded by a security policy.
| Interface name | Interface type | Interface state | Required credentials | Description |
|---|---|---|---|---|
| telepathy | D-Bus | Stable | Cellular (only for sending SMS/MMS and making cellular calls) | Telepathy D-Bus interface |
| telepathy-qt4 | Qt/C++ | Stable | none | Qt client-side bindings to Telepathy D-Bus interface. API reference |
| telepathy-glib | C | Stable | none | glib-based client and service-side bindings to Telepathy D-Bus interface. API reference |
| farsight2 | C | Stable | none | RTP streaming implementation. Project page API reference |
| telepathy-farsight | C | Stable | none | Handles Telepathy media streaming interfaces using Farsight. API reference |
| libnice | C | Stable | none | Implementation of ICE and STUN. Project page API reference |
| libcommhistory | Qt/C++ | Unstable | TBD | Communication history access library using a Tracker-backed storage ontology. |
A Telepathy connection manager (or CM) provides the implementation of text and voice functionality for a particular protocol to the Telepathy framework. It presents a service object on D-Bus, with a method to request a connection to establish a protocol-defined connection to a communication service. In turn, clients can request channels of various types (such as Text, StreamedMedia, FileTransfer, etc.) from a connection, and incoming events are represented by the connection announcing unrequested channels. The interfaces implemented by each object are defined by the Telepathy D-Bus interface specification, abstracting the differences between protocols as much as possible; the objects implement different combinations of interfaces depending on the features supported by the underlying protocol. CMs may be thought of as the protocol plugins of the Telepathy framework, bearing in mind that each CM is a separate process.
For calls, connection managers primarily handle the signalling protocol. In the case of a VoIP call, media session negotiation is performed by the connection manager, while the actual payload streaming is handled by client-side media handlers.
Connection managers available in MeeGo include:
| Name | Description |
|---|---|
| telepathy-gabble | Jabber connection manager |
| telepathy-sofiasip | SIP connection manager |
| telepathy-ring | Cellular connection manager using oFono |
See the Telepathy wiki for more information.
Mission Control is the Telepathy component responsible for managing user account configuration (which, in MeeGo, is stored in the system-wide account database), establishing connections when needed, dispatching incoming communication channels and client-initiated channel requests to the components registered to handle them, launching them if necessary. This allows each Telepathy connection to be shared between several different applications, and removes the need for each application to store account details and credentials.
When an application wishes to start, for example, a VoIP call with a contact, it asks Mission Control to create a channel with certain properties. Mission Control relays that request to the relevant connection served by a connection manager; when the channel is created, Mission Control resolves the client application to handle the channel, launching it if required. Similarly, when a new conversation is initiated by a remote contact, Mission Control dispatches the channel announced by the connection to the relevant handler application. In all such scenarios, Mission Control is only involved in the inital setup of the conversation: thereafter, the handler communicates directly with the channel.
Mission Control handles network connectivity, starting and stopping connection managers as necessary, following a defined policy. It can also enact platform- or product- specific policies (e.g. relating to emergency calls, low memory conditions, and protecting access to cellular functionality), through a plugin system.
Clients communicate with Mission Control using telepathy-qt4 or telepathy-glib, which use the AccountManager and ChannelDispatcher APIs defined in the Telepathy D-Bus interface specification.
For more details on Mission Control, see the Telepathy wiki.
commhistory-daemon works as a Telepathy client with the role of Observer and listens to Telepathy channels (text channels for messages and stream channels for call events). It stores the communication events in the Tracker data store. When the store is updated by commhistory-daemon, it sends D-Bus signals to inform clients using libcommhistory and subscribed to these signals. It also provides a private D-Bus interface for activating notifications, so that when the user taps on notification, it opens the related application using configured action strings (via MRemoteAction of MeegoTouch). It will become open source.
The Mission Control process normally needs to be started on the session bus to monitor accounts and manage automatic connections.
Connection managers are started on demand based on the requested protocol connections.
Service accounts are configured using the Accounts and Single Sign On framework, and accessed by Mission Control.
Communication History uses the Tracker store to keep communication events.
By design, connection managers do not store any important data locally. They are permitted to use local caches — for example, Gabble caches some contact capability data in ~/.cache/telepathy/gabble — but they must be able to function without these caches, rebuilding them as needed. These temporary data need no backup.
The Telepathy D-Bus interfaces are public, in order that 3rd party developers could implement new connection managers for integrating support for new protocols. This applies to both open source and proprietary protocol implementations.
Functionality of many Telepathy connection managers depends on local environment, such as network configuration. For telepathy-ring, cellular network support has to be either provided or emulated by oFono and underlying hardware. Some media-related features, such as video, may not be available in emulation or test environments due to lack of codec support or adequate hardware facilities.