Telepathy Framework Architecture
Version 1.0
RobertMcQueen, Collabora Limited
robert.mcqueen@collabora.co.uk
The aim of the Telepathy system is to provide a D-Bus-based framework that unifies all forms of real time communication, including, but not limited to, instant messaging, IRC and voice and video over IP. It aims to provide a simple interface to client applications allowing them to quickly implement code to make use of real time communication over any supported protocol.
Benefits of this approach include:
- Breaking down previously complicated monolithic applications into simpler components which are concerned with only one group of functionality.
- Providing a standard interface so that 3rd parties can provide connection backends for new protocols, or 3rd party UIs can easily make use of existing connections for IM and voice functions.
- Components implementing certain functionality can be loaded on demand, and do not have to be kept in memory at all times.
- Components are isolated from each other providing greater robustness against failure, and allowing separate security policies to be applied to each.
Architecture of Telepathy Framework shows the components of the overall system, and their interactions.
Connection Managers
Connection managers are responsible for establishing connections to particular IM or VOIP servers. One connection manager may support for one or more protocols, and may support one or more connections, depending upon implementation. The connection managers are started using D-Bus service activation on a well-known bus name, and present a connection manager object to the bus. Method calls on this object can be used to request a connection, which is represented as another object.
The connection object provides simple status signals indicating whether or not it is currently connected to the server, or attempting to connect. Some connections may also provide additional interfaces such as the presence interface, which emits signals detailing the presence of contacts on the connection, and allows you to set your own presence, and the aliasing interface, which indicates that contacts have an alias which they can change via the server.
Most communication with the server and other contacts is carried out with instances of various channel types, and can also implement different interfaces to represent different functionality. The connection object has a method to request channels a given type that implement certain interfaces.
The following channel types are in the specification at the moment:
List Channel Type
Represents a list of people stored on the server, a list channel implements the named and group channel interfaces. The named channel interface gives a channel an immutable name, meaning it can be requested and identified by that name. The group channel interface provides lists of members in the channel, and those pending local and remote approval, provides methods for the user to request changes and emits signals as these change. Using both these interfaces, instances of the list channel type allow you to manage a list stored on the server. Well-known list channel names such as "subscribe", "publish" and "block" allow management of server-stored contact lists, people who can see your presence, and people who are not allowed to message you.
Text Channel Type
A text channel provides methods to send messages, and has signals to indicate that messages have been sent and received. An instance of a text channel might implement the individual channel interface if it is for messaging a single individual, or may implement a combination of group channel interface and named channel interface if it is a multi-user chat room. Some protocols have no concept of an individual channel, so requesting one might result in a group channel being created with the requested contact.
Streamed Media Channel
The streamed media channel is designed to pass contacts' SDP parameters from the protocol implementation in the connection manager to the media implementation in the particular client application. This allows the phone or video streaming implementation to be separated from the underlying protocol, allowing this process to be given real-time capabilities. These channels can also implement the group channel interface to handle multiple call participants.
Client Library
The client library will use the D-Bus glib wrappers to provide an intuitive API for making use of the objects provided by the connection managers. Most of the method calls in this API will merely invoke D-Bus methods on the underlying objects, but some utility code will be provided to make the API more convenient for application developers. There will also be code in the client library to parse files on disk to discover the available connection manager implementations, what protocols they support, and what connection parameters they support. This will allow a client to allow the user to configure accounts on various protocols without having to start any of the connection managers.
Mission Control
Mission control is the only part of the framework which must be persistently loaded. It performs a number of roles important in the user interacting with the framework, and implements the behaviour which is specific to the environment:
Launching connection managers and establishing connections
When the user wishes to go on-line it can read the user's account details a the configuration store and launch the connection managers and log in to the user's IM/VOIP accounts when they wish to go on-line. If the user wanted to always log in to their messenger services when their system was on-line, it could listen to signals from network manager to do this.
Managing the user's presence when on-line
The user interface which allows the user to manage their presence on VOIP and IM services are presented by mission control. When used they can make calls to Galago and set the presence on the objects which represent the user themselves, or in some cases (such as blocking voice calls only) may simply change how incoming channels are handled.
Presenting the appropriate handler for newly-created channels
Mission control is responsible for ensuring that every channel of communication that is created by the connection objects has been presented to the user in the appropriate way. A program such as the contacts application which wants to initiate a chat with a contact will send the a channel request command to the connection object, and mission control might respond to the resulting new channel signal by launching the appropriate client application to present the chat to the user.
Synchronising the address book with server-stored lists
For services which have server-stored "subscribe", "allow" or "deny" lists, mission control must update these lists based on changes made in the address book, both those which are made when their system is not logged into the service, and those which are made when the device is logged in.
Prompting the user about publishing their presence
For services that support managing who is able to view the presence of the user, mission control should watch for requests to join the "publish" list channel and ask the user if they wish to allow or deny the contact's request to monitor their presence.
Streaming Engine (nee voip-engine)
The streaming engine is the background task which implements the handler for the streamed media channel. It interacts with the same streamed media channel object that the phone UI does for a particular call, and handles creating media session and streams for this call. It uses Farsight to enumerate appropriate codecs and streaming elements to connect the incoming and outcoming streams between the hardware and each participant in the call. The phone UI can use the group channel interface on the same channel to invite people to the call (by adding them to the channel), put the call on hold, and transfer members to another channel.