Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Symbian Messaging Protocols

From Wiki
Jump to: navigation, search

This article provides a brief overview of Symbian messaging protocols, including BIO Messaging, Internet Email (SMTP, POP3, IMAP4), Multimedia Service (MMS), Short-Message Service (SMS), and OBEX.

Article Metadata
Created: vasant21 (30 May 2007)
Last edited: hamishwillee (02 Feb 2012)


BIO Messaging

The BIO Messaging component provides a means of handling incoming messages that are intended for processing by the device as opposed to being displayed to a user. Examples of these types of messages include:

  • Internet Access con.guration: automatic updates of Internet settings
  • email settings: update or creation of email accounts
  • vCards: electronic business cards
  • vCals: electronic calendar entries.

Standards for these types of messages are de.ned by the proprietary Nokia Smart Messaging standard, and the Nokia/Ericsson Over The Air Settings Specification. BIO stands for Bearer-Independent Object: this is a reminder that the handling of such a message does not depend on the type of transport (e.g. SMS or email) over which it was received.

The BIO Messaging component can be split into two parts: the BIO framework and the BIO parsers. BIO parsers provide functionality to parse and process particular types of message. It is possible to add new BIO parsers to provide support for different types of BIO message. All parsers derive from a base class CBaseScriptParser. The framework manages a database of BIO message information that can be used to determine the type of the incoming message. A component called the BIO watcher is responsible for watching for new messages that Once a BIO message has been received, the BIO MTM is invoked to parse and process it. The BIO MTM routes the message data to the appropriate BIO parser. The parse and process operations may perform different functions depending on the type of message. Sometimes the message payload may be saved as a file for some other component to process; sometimes the data is processed immediately.


The email MTMs implement a number of different email protocols:

  • SMTP: to create and send new messages, reply to and forward email messages
  • POP3: to download messages, or optionally just message headers
  • IMAP4: to download messages, or optionally just message headers, or just the header and body text. Messages can also be managed (moved, etc.) on a remote Internet IMAP4 server.

Applications can use the client MTM interfaces for these MTMs, together with various utility classes, to perform email operations programmatically.


The SMTP Client MTM, CSmtpClientMtm, provides an API for creation of outgoing email messages. It also provides an SMTP-specific operation, to enable automatic sending of waiting messages either immediately or whenever a dial-up connection is made. Some generic messaging operations, such as receiving messages, are not supported by the MTM. Settings for SMTP connections, such as server address and email address, are defined for each SMTP service entry. Encapsulation of service settings is provided by CImSmtpSettings. For SMTP operations, progress information includes such things as connection state and number of messages sent. Progress information is provided by TSmtpProgress. As mentioned in the earlier overview of the message server, the server keeps an index entry for each message with fields that describe its properties. Email messages have some extra email specific properties: a class TMsvEmailEntry is provided to read these.

POP3 Client MTM

The POP3 Client MTM, Template:CPop3ClientMtm, provides MTM-specific operations for POP3 connections and mail retrieval. Some generic messaging operations, such as creating and sending messages, are not appropriate for POP3 and are not supported by the MTM. In addition, a helper class is provided by CImPOP3GetMail, which encapsulates all the operations required to connect and retrieve mail. Options are available for moving or copying mail, and for getting all mail or selected mail. A POP3 service’s settings define email server and user log-on details. They are encapsulated by CImPop3Settings.

IMAP4 Client MTM

The IMAP4 Client MTM, CImap4ClientMtm, provides IMAP-specific operations, the most important of which are synchronizing with a remote server, or a folder on a remote server. Some generic messaging operations, such as sending messages (for which you should use SMTP), are not supported by the MTM. Extra functions are provided for obtaining and setting IMAP4 service settings.

As for POP3, a helper class is available that wraps up many individual IMAP operations into a single call. A large number of options are available, which fall into the following groups:

  • get mail when already connected
  • connect, get mail and then disconnect
  • connect, get mail and then stay online.

The get mail helper class is CImImap4GetMail. IMAP4 service settings are encapsulated by CImImap4Settings.


The SMS stack provides access to SMS functionality. Messaging’s support for SMS provides a further level that integrates SMS sending, receiving, and storage into the messaging subsystem. Note that where SDKs do not allow the use of the lower-level SMS APIs, the messaging SMS APIs are not available either. The SMS Client MTM, CSMSMtmClient, provides MTM-specific operations for SMS, including accessing a telephone handset’s service center information, and scheduled sending of SMS messages. SMS receiving is normally done automatically by system telephony and messaging components, with received SMS messages placed in the Inbox. Settings for SMS connections, such as service center addresses, are encapsulated by CSmsSettings. For SMS operations, progress information includes such things as type of operation and number of messages processed. Progress information is provided by TSmsProgress.


APIs exist for OBEX over infrared and Bluetooth. An OBEX MTM also exists to integrate OBEX functionality into the messaging framework, so that, for example, an object sent to a phone shows up as an attachment to a message in the user’s inbox. The classes CIrClientMtm and CBtClientMtm provide client-side functionality for OBEX messaging over infrared and Bluetooth respectively. Headers for such messages can be accessed through CIrHeader (infrared) and CBtHeader (Bluetooth).

This page was last modified on 2 February 2012, at 04:18.
45 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.