Multimode telephony extends the basic telephony interfaces offered by the core telephony API. Similar to the Core telephony API, the Multimode API take client requests and passes them to the ETel server. The server then passes the request to the telephony driver of the device (.TSY module), which manages communications with the telephony hardware itself. Depending on the device, the .TSY may support a single mode for example GSM or be multimode.

The following diagram shows these component relationships:

Figure 1. Multimode ETel component architecture

Much of the functionality defined in Multimode ETel is optional, meaning that a .TSY is not required to support it. Clients should use the capability-checking interfaces supplied by Multimode ETel to ensure that such functionality is available before attempting to use it.


The diagram below shows the key classes in the Core and Multimode APIs and their inheritance relationships. The top package is ETel Core, the lower package is Multimode ETel.

Figure 2. Multimode ETel key classes

The key Multimode ETel classes are R-classes. The purpose of these classes is to communicate with the telephony server. All of the classes shown derive, directly or indirectly, from RTelSubSessionBase, which manages a sub-session to the telephony server.

The classes are summarised below:

  • RMobilePhone encapsulates the properties of the phone that do not relate to a particular line or call, and derives from RPhone interface of the core telephony API. It provides the following:

    • phone capabilities and status

    • network settings and status

    • phone security settings

    • phone-wide settings for a large number of advanced services, such as call forwarding, barring, waiting, and charge information

  • RMobileCall encapsulates information and functionality for a particular call, and derives from RCall interface of the core telephony. It provides the following:

    • call capabilities and status

    • advanced call control, including transferring calls, and putting calls on-hold

    • extended functionality to support data calls, including HSCSD

    • status information and control functions for calls using Call Completion on Busy (CCBS), and User-To-User Signalling (UUS) services of the GSM.

  • RMobileLine derives from RLine interface of the core telephony API, and provides additional line status information, such as if the line is on-hold.

  • RMobileConferenceCall provides functions to manage a collection of calls as a conference call.

  • RMobileSmsMessaging, RMobileBroadcastMessaging, and RMobileUssdMessaging are specialised messaging classes, respectively for SMS, Broadcast messages, and USSD messaging.

  • RMobilePhoneStore and its derived classes provide management for the various types of information that can be stored on the phone and the ICC card including SMS messages, and address book information.

The API also provides a number of list classes, derived from CMobilePhoneListBase, which allow clients to retrieve easily groups of settings and information.

Note on code samples

Many of the functions described in this guide are asynchronous, and are used by an active object. For purposes of conciseness, the code samples do not use active objects, but, unrealistically, synchronously wait for the function to return (using User::WaitForRequest()).

High-level multimode capabilities

A TSY is not required to support all the functionality defined by Multimode telephony although it supports all core telephony functionality. Optional functionality is divided by the API into a number of functional areas, such as, support for Call Waiting, and for SMS messaging. To query a TSY about the functional areas it supports, use RTelServer::IsSupportedByModule().

Flags for the functional areas are defined in enumerations. TMultimodeETelV1Api defines flags for the functional areas. TMultimodeETelV2Api, TMultimodeETelV3Api, and TMultimodeETelV4Api define flags for additional functional areas defined in later releases.

Functional areas have individual query functions that offer detailed capability information on that area. For example, RMobilePhone::GetMultimodeCaps() queries for the phone's supported modes.


The following code tests if the TSY supports multimode telephony API at all, by querying using the KETelExtMultimodeV1 flag. If multimode is supported, then other flags can be used to query for support for particular areas.

The code assumes iTsyName holds the name of the TSY in use.

TInt funcFlags = KETelExtMultimodeV1;
TBool result = EFalse;
iTelServer.IsSupportedByModule(iTsyName, funcFlags, result);
if (result)
    // if MM supported...


Some TMultimodeETelV1Api flags specify areas common to all modes, others to particular modes.

Multimode phone number

A phone number for use with the multimode telephony is stored as a RMobilePhone::TMobileAddress object. This has a buffer that stores the phone number and flags indicating the type of number for example national, international and network specific. It also stores the numbering plan for example national, ISDN and telex formats in which the number is stored.


The following code creates an address object to store an international phone number, formatted using the national number plan. In this example the UK representation of a Swedish number is used.

RMobilePhone::TMobileAddress address;
_LIT(KANumber, "+46 123 4567");
address.iTelNumber = KANumber;    
address.iTypeOfNumber = RMobilePhone::EInternationalNumber;
address.iNumberPlan = RMobilePhone::ENationalNumberPlan;