Editing Documentation/Maemo 5 Developer Guide/Architecture/RTCOM

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

The RTCom domain provides both services and applications for real time Internet communications, such as Voice Over IP / Video calls and Instant Messaging, and also cellular/CS communications on Maemo platform. It also provides and distributes presence information within the system.

The architecture consists of a few major components; connection managers which abstract implementation details of different protocols to a common API, mission control to handle transient events and enforce system policies, and user interfaces to present information to the user. There is also a streaming server to handle actual media streaming communications. It is not conceptually a separate architectural element of the framework, but more like one UI implementation. Farsight interface is used to manage media pipelines.

==System decomposition view==

The diagram below shows the entities of the RTCOM subsystem, dependencies between them, provided interfaces and required external interfaces. The client applications are shown as packages without the fill-color. Different UI components (Messaging, Call, Log Viewer, Desktop Elements, Control Panel Applets) provide user interface layer to the system.

On intermediate layer, there’s a Mission Control package, which handle transient events and enforce system policies, providing application logic services, and libtelepathy-glib component providing <code>GObject</code>-style access to the Telepathy D-Bus interfaces.

On lowest level, there are Streaming Engine to handle actual media streaming communications, and Connection managers that abstract implementation details of different protocols to a common API. The interface is modular and platform  includes Jabber (instant messaging) and SIP (voice and video calls).

The Telepathy framework is used to handle real time communication related signaling and abstracting all protocol dependencies to a single D-Bus interface.

Centralized addressbook is provided by the [[Documentation/Maemo 5 Developer Guide/Architecture/Data Management#Contacts (Addressbook)|Contacts subsystem]] and used by the RTcom subsystem for all contact information storage and lookup purposes and it also stores transient contacts/states.

==RTCOM  framework==

In Fremantle, RTCom framework provides the following functionality:
*Support for comprehensive logging
*SSO related components
*Support for heartbeat
*Device presence profiles
*Support for BT HFP
*Location support for presence

===telepathy-glib===

;Purpose
: Provides GObject abstraction of Telepathy D-Bus interfaces
;Source packages
: telepathy-glib, librtcom-telepathy-glib
;Licenses
: LGPL and Nokia Proprietary
;Interfaces used
: libglib, libdbus, libdbus-glib
;Interfaces provided
: [http://maemo.org/packages/view/libtelepathy-glib-dev/ libtelepathy-glib], [http://maemo.org/packages/view/librtcom-telepathy-glib-dev/ librtcom-telepathy-glib]

===telepathy-mission-control===

;Purpose
: Provides a way for “end user” applications to abstract some of the details of connection managers to provide a simple way to manipulate a bunch of connection managers at once and remove the need to have in each program the account definitions and credentials.
;Source packages
: telepathy-glib, librtcom-telepathy-glib
;Licenses
: LGPL and Nokia Proprietary
;Interfaces used
: libglib, libdbus, libdbus-glib
;Interfaces provided
: [http://maemo.org/packages/view/libtelepathy-glib-dev/ libtelepathy-glib], [http://maemo.org/packages/view/librtcom-telepathy-glib-dev/ librtcom-telepathy-glib]

===osso-mission-control===

;Purpose
: Mission control filters
;Source packages
: telepathy-mission-control
;Licenses
: Nokia
;Interfaces used
: libmissioncontrol, libosso, libconic, libebook, libhildon1 (libhildon-desktop), mce, libxml2, librtcom-eventlogger, librtcom-eventlogger-plugins, libsignon-glib
;Interfaces provided
: None

===osso-accounts===

;Purpose
: Provides a set of libraries, UIs and applets for account management.
;Source packages
: osso-accounts, osso-accounts-plugin-nokia-chat
;Licenses
: Nokia
;Interfaces used
: libgtk2, libhildon1 (libhildon1, libhildonfm2, hildon-control-panel, libhildonmime, libhildonhelp), libosso-abook, libglade2, libconic, libmcclient
;Interfaces provided
: [http://maemo.org/packages/view/libaccounts-dev/ libaccounts], [http://maemo.org/packages/view/libaccounts-glade/ libaccounts-glade]

===rtcom-eventlogger===

;Purpose
: Provides general purpose event log database system.
;Source packages
: rtcom-eventlogger
;Licenses
: Nokia
;Interfaces used
: libglib, libsqlite3, libdbus
;Interfaces provided
: [http://maemo.org/packages/view/librtcom-eventlogger-dev/ librtcom-eventlogger]

===rtcom-eventlogger-plugins===

;Purpose
: Provides plugins for the event logging system.
;Source packages
: rtcom-eventlogger-plugins
;Licenses
: Nokia
;Interfaces used
: libglib, libsqlite3, librtcom-eventlogger
;Interfaces provided
: None

==Connection Managers==

Connection managers can be thought of as a kind of protocol plugins of the system. They conform to Telepathy D-Bus interface specification and provide D-Bus interface abstraction of some protocol. Each connection manager usually provides support for one protocol. The provided interfaces depend on the capabilities of the connection manager and protocol.

Connection managers only signaling protocols. In case of a media streaming session, SDP or similar negotiation signaling is done in Connection Manager using the signaling protocol, but actual payload streaming is handled by Streaming Engine (Eg: telepathy-stream-engine).

===Functionalities provided===

*Support for Skype integrated into Telepathy framework

===telepathy-ring===

;Purpose
: Connection manager for cellular calls and SMS messaging
;Source packages
: telepathy-ring
;Licenses
: Nokia
;Interfaces used
: libglib, libdbus, libdbus-glib, libtelepathy-glib
;Interfaces provided
: None

===sofia-sip===

;Purpose
: SIP-stack implementation
;Source packages
: sofia-sip
;Licenses
: LGPL
;Interfaces used
: libglib, libssl
;Interfaces provided
: [http://maemo.org/packages/view/libsofia-sip-ua-dev/ libsofia-sip-ua], [http://maemo.org/packages/view/libsofia-sip-ua-glib-dev/ libsofia-sip-ua-glib]

===telepathy-sofiasip===

;Purpose
: SIP connection manager
;Source packages
: telepathy-sofiasip
;Licenses
: LGPL
;Interfaces used
: libglib, libdbus, libdbus-glib, libsofia-sip-ua, libsofia-sip-ua-glib, libtelepathy-glib, libssl
;Interfaces provided
: None

===loudmouth===

;Purpose
: XMPP-stack implementation
;Source packages
: loudmouth
;Licenses
: LGPL
;Interfaces used
: libglib, libssl, libcertman (libcst)
;Interfaces provided
: [http://maemo.org/packages/view/libloudmouth1-dev/ libloudmouth]

===telepathy-gabble===

;Purpose
: XMPP connection manager
;Source packages
: telepathy-gabble
;Licenses
: LGPL
;Interfaces used
: libglib, libssl
;Interfaces provided
: [http://maemo.org/packages/view/libglib2.0-dev/ libglib], [http://maemo.org/packages/view/libdbus-1-dev/ libdbus], [http://maemo.org/packages/view/libdbus-glib-1-dev/ libdbus-glib], [http://maemo.org/packages/view/libloudmouth1-dev/ libloudmouth], [http://maemo.org/packages/view/libtelepathy-glib-dev/ libtelepathy-glib]

==Streaming Engines==

Media engines handle media streaming needs for multimedia communication methods like voice and video conversation. Generic telepathy-stream-engine provides voice and video streaming capabilities over RTP protocol. If there is a need for other kind of media streaming for some connection manager, it might be reasonable to provide separate media engine for that purpose.

Independent of possible other uses, libjingle is used to provide NAT traversal using STUN, GTalk relay and ICE technologies for the GTalk service. libnice provides fully standards compliant ICE implementation.

===Functionalities provided===

*Support for fully standards compliant ICE through libnice.
*Support for H.264
*Support for BT HFP.
*Support for Skype in Telepathy framework.

===gst-plugins-farsight===

;Purpose
: GStreamer plugins specific to Farsight.
;Source packages
: gst-plugins-farsight
;Licenses
: LGPL
;Interfaces used
: libglib, gstreamer (libgstreamer-pligins-base), libjingle, libgonf2
;Interfaces provided
: None

===farsight2===

;Purpose
: The Farsight project is an effort to create a framework to deal with all known audio/video conferencing protocols. On one side it offers a generic API that makes it possible to write plugins for different streaming protocols, on the other side it offers an API for clients to use those plugins. This package provides the core Farsight 2 library.
;Source packages
: farsight2
;Licenses
: LGPL
;Interfaces used
: libglib, gstreamer (libgstreamer-plugins-base, libgstreamer-plugins-good, libgstreamer-plugins-bad), libnice, libnice-gstreamer, gupnp
;Interfaces provided
: [http://maemo.org/packages/view/libgstfarsight0.10-dev/ libgstfarsight]

===telepathy-farsight===

;Purpose
: Glue betweeen Telepathy and Farsight2
;Source packages
: telepathy-farsight
;Licenses
: LGPL
;Interfaces used
: libglib, libdbus (libdbus, libdbus-glib), libgstfarsight, libtelepathy-glib
;Interfaces provided
: [http://maemo.org/packages/view/libtelepathy-farsight-dev/ libtelepathy-farsight]

===libnice===

;Purpose
: ICE NAT-traversal implementation 
;Source packages
: libnice
;Licenses
: MPL / LGPL
;Interfaces used
: libglib, gstreamer (libgstreamer, libgstreamer-plugins-base)
;Interfaces provided
: [http://maemo.org/packages/view/libnice-dev/ libnice], [http://maemo.org/packages/view/libnice-gstreamer0.10/ libnice-gstreamer]

===telepathy-stream-engine===

;Purpose
: Media streaming engine for Telepathy, mostly used for standard RTP-over-UDP streaming. 
;Source packages
: telepathy-stream-engine
;Licenses
: LGPL
;Interfaces used
: libglib, libdbus (libdbus, libdbus-glib), libgstfarsight, gstreamer (libgstreamer-plugins-base), libtelepathy-farsight, libgtk2

==telepathy-glib==

Telepathy Library’s role is to provide common GObject-based C-language API for applications. It wraps Telepathy D-Bus interfaces to GObjects and also provides some utility functions for accessing and enumerating D-Bus interfaces. It’s code is mostly autogenerated from D-Bus interface specification.

;Purpose
: C API for Telepathy D-Bus interfaces.
;Responsibilties
: Provides GObject based C-language API to the Telepathy D-Bus interfaces along with some utility functions.
;Notes
: Most of Telepathy’s functionality is distributed as D-Bus objects where the actual functionality doesn’t necessarily reside within any specific component, but as an abstract object in the D-Bus network.''
;License
: LGPL

{| class="wikitable"
|+ Interfaces used by libtelepathy-glib
|-
! Interface name !! License !! Dependency !! Description
|-
| Telepathy || LGPL || glib, D-Bus || RTCom Interface
|}

==Mission Control==

Communication system policies are usually dependent on application and environment, thus some method external to framework has to exist for handling those. Mission Control thus enforces communication system policies. It also handles configuration information storage, network connectivity from policy point of view and is thus responsible for starting and stopping connection managers and engines. While starting up connection managers and engines, it provides the configuration information.

In case of network side event like presence subscription or start of communication session, Mission Control handles these transient events based on system policy and possibly starts associated UI components.
Misson Control employs plugin methods to provide possibility to add special event handlers called “mission control filters”. These plugins can provide special device or system dependent function handling.

;Purpose
: Enforces policies, handles startup/connectivity and transient events.
;Responsibilities
: Enforces system policies. Handles Connection Managers, Engines and UI startups. Also handles transient and network side events. Also responsible for connectivity management.
;Packages
: curlpp, osso-mission-control, osso-rtcom-oma, telepathy-mission-control
;License
: LGPL, Nokia Proprietary

==User Interfaces==

===Messaging UI===

;Name
: rtcom-messaging-ui
;Purpose
: Messaging application.
;Source Packages
: rtcom-messaging-ui
;Licenses
: Nokia
;Interfaces Used
: libglib, libosso, libgtk2, libhildon1 (libhildon1, libhildon-mime, libhildonfm2), libgconf2, libtelepathy-glib, librtcom-telepathy-glib, libmcclient, libosso-abook, libebook, mce, maemo-launcher, librtcom-eventlogger, librtcom-eventlogger-ui, librtcom-eventlogger-plugins, browser-neteal

Messaging UI is a user interface component for instant messaging sessions. It handles all kinds of non-media streaming communications like text chat.

===Event logger===

;Name
: rtcom-eventlogger-ui
;Purpose
: Event logger widgets.
;Source Packages
: rtcom-eventlogger-ui
;Licenses
: Nokia
;Interfaces Used
: libglib, libgtk, libdbus, librtcom-eventlogger, librtcom-eventlogger-plugins, libosso, libosso-abook, libhildon1, libmcclient
;Interfaces Provided
: [http://maemo.org/packages/view/librtcom-eventlogger-ui-dev/ librtcom-eventlogger-ui]

Logger is a database engine built into a library for logging all kinds of events. It’s particularly powerful for logging messages (optionally with attachments), calls and network events.

===Notification UI===

;Name
: rtcom-notification-ui
;Purpose
: Notification UI, plugin for the Hildon Status Menu.
;Source Packages
: rtcom-notification-ui
;Licenses
: Nokia
;Interfaces Used
: libglib, libosso, libgtk2, libhildon1 (libhildon1, libhildondesktop1, libhildonmime), mce, libtelepathy-glib, libosso-abook, libebook, librtcom-telepathy-glib

This is a Hildon Status menu plugin for RTCom related notifications.

===Presence UI===

;Name
: rtcom-presence-ui
;Purpose
: Accounts presence UI.
;Source Packages
: rtcom-presence-ui
;License
: Nokia
;Interfaces Used
: libglib, libosso, libgtk2, libhildon1 (libhildon1, libhildondesktop1), libmcclient, maemo-launcher, liblocation, libnavigation, libcanberra, libosso-abook

This is the presence user interface.

==Single-Sign-On (SSO)==

SSO subsystem is a separate subsystem providing credential storage and a client library for applications. This way, user is not requested to login or enter credentials as he’s navigating between different service types within single service provider. In case of wide ticket-based system like OpenID (reference) , user can even use the same credential between different service providers as long as service provider accepts tickets from external providers.

;Purpose
: Provides Single-Sign-On functionality.
;Responsibilities
: Provides authentication services and tokens for applications.

;Name
: libsignon-glib
;Purpose
: GObject interface to SSO functionality.
;Source Packages
: signon
;Licenses
: Nokia
;Interfaces Used
: libglib, libxml2
;Interfaces Provided
: [http://maemo.org/packages/view/libsignon-glib-dev/ libsignon-glib]

;Name
: libsignonui
;Purpose
: UI elements of the SSO functionality.
;Source Packages
: signon
;Licenses
: Nokia
;Interfaces Used
: libglib, libgtk2, libhildon1, libaccounts, libosso-rtcom-accounts, libsignon-glib
;Interfaces Provided
: libsignonui

;Name
: signond
;Purpose
: SSO daemon, handling credential storate and authentication.
;Source Packages
: signon
;Licenses
: Nokia
;Interfaces Used
: libglib, libxml2, libcurl (libcurl3-openssl), libssl (libcrypto)
;Interfaces Provided
: [http://maemo.org/packages/view/signond-dev/ signond] (ipc)

SSO-subsystem consists of server, here called “signond” and application libraries libsignon-glib and libsignonui. Server stores credentials in optionally encrypted database. It is running under different user id than applications. Application library accesses the storage over IPC mechanism.

==Protocol Stack==

Realtime communication framework connects to services using protocol plugins. Currently, XMPP/Jabber and SIP are the officially supported protocols. There’s also support for media extension of Jabber called Jingle. As described earlier, each of the protocol plugins create abstraction of some protocol to a common D-Bus protocol.

GoogleTalk uses Jingle protocol to handle voice streaming.

Standard Jabber communication always goes through persistent TCP connection to the server. SIP protocol uses either UDP or TCP protocol for signaling. UDP is older and established method, while TCP is more recommended nowadays, mainly due to some particular message size and NAT traversal problems associated with UDP use. Together with SIP, standard RTP is always used for the media.

[[Category:Development]]
[[Category:Documentation]]
[[Category:Fremantle]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/RTCOM"

Personal tools

Navigation

Views

Editing Documentation/Maemo 5 Developer Guide/Architecture/RTCOM

@@ Line 358: / Line 358: @@
 ==Single-Sign-On (SSO)==
-SSO subsystem is a separate subsystem providing credential storage and a client library for applications. This way, user is not requested to login or enter credentials as he’s navigating between different service types within single service provider. In case of wide ticket-based system like [http://openid.net/ OpenID], user can even use the same credential between different service providers as long as service provider accepts tickets from external providers.
+SSO subsystem is a separate subsystem providing credential storage and a client library for applications. This way, user is not requested to login or enter credentials as he’s navigating between different service types within single service provider. In case of wide ticket-based system like OpenID (reference) , user can even use the same credential between different service providers as long as service provider accepts tickets from external providers.
 ;Purpose