<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept xml:lang="en" id="GUID-95A4DB2E-77CB-5151-8D7C-948C30348E13"><title>Architecture</title><shortdesc>The telephony server plug-in is the interface between the telephony server and the baseband. This topic describes the architectural relationship between the telephony server plug-in components. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>The CTSY inherits its base class from the <xref href="GUID-C1795E41-CB12-3116-8F57-51ADDD6A264D.dita"><apiname>telephony</apiname></xref> Server. The server can be <xref href="GUID-E0BA28A0-5546-3378-A330-ECF27BA81035.dita"><apiname>CCallBase</apiname></xref>, <xref href="GUID-38F19E7C-A1BC-3E8B-805B-3944775B2D63.dita"><apiname>CPhoneBase</apiname></xref> or <xref href="GUID-78926205-95F5-332B-9B94-0611AA084B4D.dita"><apiname>CLineBase</apiname></xref>. CTSY has two main APIs: </p> <p><b>TSY plug-in API </b> </p> <p>This API is used for communication with the telephony server. The telephony client sends the request to the telephony server for any communication that requires baseband connection. The telephony server forwards these requests to the LTSY through TSY plug-in API. </p> <p><b>Common TSY plug-in API </b> </p> <p>This interface is used for the communication between the CTSY and the LTSY. The CTSY forwards the telephony client request to the LTSY using the Common TSY plug-in API as CTSY messages. The CTSY messages are converted to baseband requests by the LTSY. </p> <p>The CTSY is implemented as a static <codeph>DLL</codeph> and it is loaded during device boot time by the telephony server. The telephony server and the CTSY run in the same thread. Since it is a static DLL, the initialisation will not fail. </p> <fig id="GUID-08D9122B-F7B8-5B90-AC7E-B8FF222657BF"><image href="GUID-9DCD62DF-C523-5D00-85CD-5AC82C9E9F02_d0e59389_href.png" placement="inline"/></fig> <p>There are two variants of Common TSY: </p> <ul><li id="GUID-A21A18D2-11D8-5895-ADD0-4421091D2C5C"><p>Common TSY without Dispatcher </p> </li> <li id="GUID-8AF22528-A9B6-5465-A817-0E2CDBE13EE0"><p>Common TSY with Dispatcher </p> </li> </ul> <section id="GUID-2B86BD4F-66D5-514A-9EA3-17A711B02DE8"><title>Common TSY without Dispatcher</title> <p>Telephony clients send requests which can be mode specific or mode independent. The mode can be GSM or UMTS. These requests are passed on to CTSY by the telephony server (ETel). The mode independent requests are handled by CTSY and the mode specific requests are handled by the extension modules such as <xref href="GUID-6412C1AF-CD93-3AE4-87CA-0CA8C37EBCE0.dita"><apiname>CMmPhoneGsmWcdmaExtInterface</apiname></xref>. A mode specific extension module may process the requests related to specific technologies such as GSM or UMTS. </p> <fig id="GUID-701013DE-D163-5952-87AA-B6599A47E0C6"><title>
             Common TSY without Dispatcher 
          </title> <image href="GUID-7A6FFAD1-5358-5050-9728-5C51B5B225AF_d0e59421_href.png" placement="inline"/></fig> <p>The CTSY is independent of the LTSY and the baseband. The generic interface allows licensees to modify the LTSY and baseband, but allows easy integration. The phone engine is the main user of the CTSY but other processes such as the SIM Application Toolkit (SAT) can also use the CTSY. The phone engine is created by the telephony server when the phone boots. The phone engine initialises the CTSY and the LTSY when a first request call is made by one of the clients. The CTSY creates the message manager and the message router proxy. The LTSY creates a message router and message handlers. </p> <p id="GUID-20F2C7C0-C290-5D38-8075-E8A82E45CA6C"><b>Message manager</b> </p> <p>The message manager separates the CTSY from the LTSY. Telephony client requests are all processed by the message manager and passed to the LTSY using the message router. <xref href="GUID-AC6F8F0B-1B08-3A02-B82E-0E5D9222325C.dita"><apiname>CMmMessageRouterBase</apiname></xref> provides the required implementation for routing the client request to the LTSY. When the requests are acknowledged, the message manager forwards the response message to the client. Each client is identified by a unique IPC number. LTSY should use the <xref href="GUID-9BD0D6D7-60F2-36BB-982E-7FA557BF3A28.dita"><apiname>MmMessageManagerCallback</apiname></xref> interface to respond to the telephony clients. </p> <p>The requests passed from CTSY to LTSY should be sent as a packaged data using the <xref href="GUID-1394910A-F1D8-315D-B0B3-9B34C89940CB.dita"><apiname>CmDataPackage</apiname></xref> template. The template class allows packing of two parameters together. </p> <p id="GUID-1CE2A549-33F7-5B9C-9DC8-D7FCE2A6C7B6"><b>Message router proxy</b> </p> <p>The message router proxy handles the response from the baseband to the CTSY. Message router proxy implements the <xref href="GUID-A80C1727-0165-3A3A-BDE6-A8AD50688535.dita"><apiname>MmMessageMangerCallBack</apiname></xref> which is used by the LTSY to respond back to the CTSY request messages using the <xref href="GUID-564D8ECF-A70E-30CC-9C68-F6BECBCBAC6E.dita"><apiname>Complete()</apiname></xref> method. </p> </section> <section id="GUID-0F0C43F2-471D-5E89-8F2A-C59777B8D904"><title>Common TSY with Dispatcher</title> <p>In the second variant of the CTSY a new layer is provided to decrease the development time of the LTSY. This new layer, between the CTSY and the LTSY, is known as the dispatch layer. The dispatch layer provides a simple interface to be implemented in the LTSY. The dispatch layer handles the packing and unpacking of messages between the CTSY and LTSY. The LTSY is responsible for the implementation of the functions defined in the dispatcher classes and translating the requests to baseband commands. </p> <fig id="GUID-5F413A61-3346-5710-848C-E48177D34DBD"><image href="GUID-2F48BCBA-9256-50B6-A8D1-02617655FEED_d0e59474_href.png" placement="inline"/></fig> <p><b>CTSY</b> </p> <p>The CTSY implements the message manager. The message manager processes the incoming client requests and pass them to appropriate dispatcher class through the message router. The acknowledgements from the dispatcher class are passed back to the clients through the telephony server. </p> <p><b>Dispatcher</b> </p> <p>The dispatch layer provides the following: </p> <ul><li id="GUID-98C9CEF6-7C04-55ED-BC19-F9335F9AABD7"><p> <b>LTSY factory classes</b>  </p> <p>The factory classes creates the required interfaces for communication between the LTSY and the CTSY. </p> </li> <li id="GUID-5288D29B-DD65-5F46-BF32-54228195CB53"><p> <b>Message router</b>  </p> <p>The message router is responsible to call the appropriate dispatcher class function. </p> </li> <li id="GUID-CB3EB222-6C3B-5DA6-A91F-0714B846ABCF"><p> <b>Dispatcher classes </b>  </p> <p>The <xref href="GUID-B89575A8-5F36-59FA-9FA3-48E2985E54C9.dita#GUID-B89575A8-5F36-59FA-9FA3-48E2985E54C9/GUID-162746DD-E2E2-548F-8026-5C4281BF0CC5">dispatcher classes</xref> are grouped according to the functional areas. </p> </li> <li id="GUID-4E850C80-6CF0-5770-A915-F3B2ED58E3F2"><p> <b>Call-back functions</b>  </p> <p>The LTSY uses the call-back function to acknowledge previous request or to notify an event. </p> </li> </ul> <p> <i>Note:</i> Some of the functions may not be implemented in the LTSY. When the dispatcher receives a request for an unsupported function it returns <codeph>KErrNotSupported</codeph> to the clients. </p> </section> </conbody></concept>