oFono - Open Source Telephony ******************************************************************************* 1.0 Introduction Linux and other open source components are now used extensively on both desktop and mobile embedded devices. They provide networking, power management, database and other core OS infrastructure. However, up to this point no viable open source solution for mobile telephony existed. oFono aims to change that; it is a telephony host stack specifically targeted at both mobile embedded and desktop systems. Launched on May 11, 2009 oFono aims to provide a solid framework for builidng 3GPP GSM/UMTS User Equipment (UE) standard compliant devices. Support for CDMA/EVDO technologies is also planned. The goal of oFono is to provide an easy to use, high-level API for applications. This is accomplished by keeping the core logic within the daemon, taking care of standards compliance and exposing only the need-to-know aspects to the application. The license for oFono was chosen as GPLv2. This means that all core services and plugins for oFono must be Open Source. oFono accepts GPLv2 or any GPL-compatible BSD license. However, since oFono provides a D-Bus API, user interface applications can be of any license. 2.0 Design Philosophy 2.1 Modern oFono aims to be a modern implementation, ready for the 21st century. From the very beginning oFono was designed with support of multiple technologies and device types in mind. It is also designed to support multiple active devices simultenously. This enables greater flexibility and enables usecases not possible with current solutions. oFono explicitly chooses not to support some of the more archaic features of GSM. Specifically only limited use of the SIM for Phonebook support is enabled. SIM storage for incoming and outgoing Short Messages (SMS) is also not supported. The use of these features does not make sense on the current generation of devices, and introduces unnessary complexity. 2.2 Fast and Light One of the main constraints for oFono's design was to make it extremely performant on resource-constrainted embedded devices. This means that high-level languages like Python could not be used and library dependencies had to be kept to a minimum. oFono is thus implemented in C and has minimial dependencies: libdbus, glib. The reference drivers introduce two other library dependencies, gatchat and gisi, which are linked statically. 2.3 Standards Compliant oFono is meant to be used in commercial systems, so standards compliance is a primary consideration from the very beginning. Whenever possible oFono takes care of the gory details. This includes the particulars of SMS decoding, de-fragmentation and duplicate detection; network operator name display; message waiting indicator processing and reporting; emergency dialing numbers, service numbers and subscriber number management; supplementary service control via strings defined in 3GPP TS 22.030. 3.0 Architecture oFono provides a flexible, modular and extensible architecture with four main components: core daemon, oFono atoms, drivers and plugins. 3.1 Core Daemon Core daemon provides base level services within oFono, namely the loading of plugins and drivers; utility APIs for decoding, encoding and fragmentation of binary SMS pdus; utility APIs for reading and writing to the SIM, and interpreting the contents of the low-level Element File (EF) contents; utility APIs for character set conversion; utility APIs for decoding, duplicate detection and pagination of cell broadcasts; and detection of and communication between oFono atoms. A big part of the core daemon is the modem device abstraction. Each device is managed independently, and several devices can be present and active in the system at the same time. The technologies for each device are not restricted in any way, and can be customized via the use of drivers. 3.2 oFono Atoms oFono atoms provide a clear abstraction API for the applications based on D-Bus. There are currently over a dozen atoms within oFono, providing access to core functionality like voice calls, supplementary services, short message service (SMS), cell broadcast (CBS) and sim management. Atoms can detect the presence of other atoms and use information provided by other atoms to provide extra functionality. For instance, the Network Registration atom will read low-level EF files whenever a SIM is present, and provide enhanced operator information if the SIM is thus provisioned. 3.3 Drivers oFono provides a way to integrate multiple device technologies through its driver mechanism. All modem devices and atoms provide an abstract interface for low-level operations. This interface is based on 3GPP TS 27.007 "AT command set for User Equipment" and 3GPP TS 27.005 "DTE-DCE interface for SMS and CBS". oFono assumes that all operations are fully asynchronous. This means that oFono can accommodate a wide variety of devices, including full-featured modems (AT command based and otherwise), data-only cards, and modem like devices (e.g. Bluetooth Handsfree and Sim Access Profile devices, etc.) oFono provides a reference AT command driver, which should work for the majority of AT command based modems in the market. oFono also includes an ISI protocol based driver, which will enable the majority of Nokia devices to be used. Finally a Bluetooth Handsfree Profile (HFP) driver is also planned. 3.4 Plugins Plugins provide a final piece of the puzzle. These are used to provide device drivers and atom drivers. They can also be used to extend oFono or interact with other system services. For example, Moblin uses oFono plugins to store all call history information within Evolution Data Server. 4.0 D-Bus API Much thought has been given to how user interface applications will interact with oFono. The goal of the oFono API is to make the User Interface (UI) application writer's job as easy as possible. This is accomplished in two ways: exposing only the essential details to the application and provide a high level API. To accomplish this, oFono sticks to the following four basic principles of API design: Consistent, Minimal, Complete and Easy to Use. 4.1 Consistent As mentioned previously, each atom provides a high-level D-Bus API, which is referred to as an interface. Each interface has a well-defined set of properties and two special methods for managing them: GetProperties and SetProperty. All names within oFono are CamelCased and this naming convention is strictly enforced. This means that once the application writer is comfortable using one Interface, they should be able to quickly pick up others. 4.2 Minimal & Complete A common pitfal of API design is exposing too much and assuming that the user has the same level of knowledge as the designer. Almost always these assumptions are incorrect and lead to incorrect and inefficient use of the API. This in turn leads to applications that are hard to write, maintain and replace. Instead the API should be minimal; it should make it easy and apparent to the user how to accomplish a particular task he or she is interested in. oFono accomplishes this by doing as much as possible within the core and only exposing the information which is actually required to be shown to the user. 4.3 Easy to Use While the above three principles generally provide good results, a process of refinement can still be applied. oFono works with user interface designers and implementers to continually improve its API. This means that if a particular feature is found to be inefficient in practice, it refined and improved as quickly as possible. 5.0 Conclusion oFono provides a full host protocol stack for telephony aware applications. Today, it enables most of the commonly used features defined by 3GPP standards, including voicecalls, sms, cbs, supplementary services and network registration. Data connections using GPRS and 3G features are being actively worked on. It thus provides a viable, open source solution to system implementors seeking to add telephony capabilities to Linux desktop and mobile devices. 6.0 Resources Website: http://ofono.org Mailing List: ofono@ofono.org IRC: #ofono on freenode