Concepts with Symbian OS (779878), страница 52
Текст из файла (страница 52)
Of the possible equipment and switchingnetwork combinations, digital choices have emerged as the most promising for the future. Digital switching has replaced more antiquated step andcross-bar exchanges within the PSTN. A GSM phone is a good exampleof digital phone equipment using a digital connection network; GSM isa frame-based protocol that sends data frames of a fixed size for a fixedtime interval, mixing these frames with others.
The phone must also bea digital device to use the digital network, and may offer the capabilityof being controlled by an external computer to turn it into an advancedMODELING TELEPHONY SERVICES249modem capable of using the digital network on behalf of another device.A Nokia E61, for example, has an infrared port that allows it to acceptcommands from an external device.The communications model of an operating system can be extendedto include telephony as a core feature. How well telephony works withan operating system depends on the operating system architecture and itshistory.In a conventional operating system, working with telephony servicesmeans using system calls to interact with a telephony device.
The operating system usually works with a telephony device in either of twoextremes: a very abstract way or methods that are low-level and concrete.For example, Linux treats a telephony device as any other device andallows ioctl() calls – low-level system calls that can manipulate anydevice – to interact with device drivers and control the telephony device.On the other hand, Microsoft Windows Mobile treats the phone portionof handheld computer as an object and provides a way to work with itthrough the object interface.
For example, in a Windows Mobile application that implements dialing a phone number, you might find code likethis (written in C#):Phone myPhone = new Microsoft.WindowsMobile.Telephony.Phone();myPhone.Talk("555-7341\0");Whether an interface uses high- or low-level manipulation, the controlof the phone device is direct via a kernel-mode driver.In microkernel architectures, devices are controlled by servers thatprovide a high level of abstraction to multiple clients, forcing manipulation of devices to take place through this abstraction. Thus, microkernels use telephony servers to provide telephony services throughstandard client–server relationships with other processes.
Symbian OS,for example, implements an ETel server that provides access to telephonydevices. Applications interested in making a phone call must connectwith this server and send it requests.By way of understanding telephony communication, we examine theSymbian OS telephony subsystem in more detail. This study serves asan example of a microkernel implementation of telephony as well as ofSymbian OS design.Telephony implementations demonstrate what we have been illustrating all through this book: various operating systems do things at variouslevels of abstraction. Linux is perhaps the least abstract while Symbian250TELEPHONYOS is perhaps the most abstract.
Because these abstraction levels are bydesign, we cannot simply ask which one is best. We have to ask whichone is the best in its area of application and its audience of developers.12.2A Structural OverviewThe communications model Symbian OS uses to implement telephony isabstract enough to provide the application programmer with a consistent,standard interface, no matter what kind of telephony device is being used.The Symbian OS telephony subsystem closely models the real-worlduser experience of using telephones (Figure 12.1).The model characterizes telephony as a collection of phones. Eachphone is an abstraction of a telephony device (e.g., a modem or aGSM phone; usually only one exists per phone, which corresponds tothat particular device’s radio hardware setup such as GSM, UMTS orTelephonyserver...phonephonephone......linesphonelines......lineslinescallscallscallscallsFigure 12.1 The ETel phone modelA STRUCTURAL OVERVIEW251CDMA).
Through this abstraction, we can access a device’s status andcapabilities and be notified if changes occur to a device’s properties. Aphone can have one or more lines. An application can access the statusand capabilities of a line, as it can for a phone, and can be notified of anychanges in these features. Lines usually correspond to specific telephonyservices (e.g. voice, fax, circuit-switched data, etc.).The actual connection of a local endpoint through a circuit-switchednetwork to the phone is designated as a call.
A line can have zeroor more active calls. A call can dial a number, wait on a line for anincoming call and be terminated. As with lines, an application can getstatus and capabilities information for a call and be notified of changesto a call’s state.These abstractions are central to the use of the Symbian OS telephonysubsystem through the ETel APIs.TSY Modules in Symbian OSThe heart of this model’s implementation is in the TSY module.
Byintegrating the specific implementation of this model for a particularphone type into a module, Symbian OS designers ensured that the API forthis functionality would remain the same across different phones, and theapplication programmer is free from worrying about the implementationspecifics for a particular phone. When Symbian OS is used with newphone hardware for the first time, a new TSY must be developed.TSY modules are designed to plug into the telephony server and provideaccess to telephony functionality.
Search your Symbian phone or emulator and look for TSY modules provided with the device. In Symbian OSv9, you should find several TSYs that are provided with the distribution,including generic phone TSYs and ones that implement CDMA.The ETel SubsystemThe ETel subsystem has four key constituents (see Figure 12.1): the ETelserver, the Phone abstraction, the Line abstraction, and the Call object.ETel serverThe ETel server manages access to the telephony system. It is accessedusing functions from the RTelServer class. Before telephony can beused by an application, it must connect to the telephony server. This isdone with the Connect() function.
Using this function, applications252TELEPHONYClient applicationClient applicationCore APIExtension APIETel serverTSY APITSY moduleTSY moduleTelephonyhardwareTelephonyhardwareFigure 12.2 ETel structural diagramconnect to the telephony server, specifying how many message slotsare needed. A single message slot is a communication channel in onedirection. The default number of slots assigned is 32. The RTelServerclass is a subclass of the RSessionBase class, and therefore inheritsthe Close() function, which is used to shut down an active telephonyserver session.Once a connection is established, the TSY module that is neededshould be loaded. TSY modules can be manipulated through the LoadPhoneModule() and UnloadPhoneModule() functions.
The firstfunction loads a TSY module, and the second function removes a TSYmodule. These modules are analogous to device drivers (especially inthat they relate to a specific device – in this case, the particular basebandhardware in the phone) and are implemented with logical and physicalcomponents particular to the specific baseband. Recall from Chapter 11A STRUCTURAL OVERVIEW253that device drivers need to be loaded and unloaded; TSYs require thesame handling.Once the appropriate TSY module has been loaded, applications canmake queries about its properties. These queries take the form of telephony server functions, such as the Version() or GetPhoneInfo()functions, and result in requests being sent to, and responses returningfrom, the ETel server.
It is possible to obtain version information, thephone’s name, the type of telephone network it uses, and other information. Information about the TSY itself is also available from the telephonyserver. All TSY modules are assumed to support a minimal set of telephonyfunctionality, but by calling IsSupportedByModule() it is possible todetermine exactly what ETel functions are supported.Let’s take an example: we have a CPhoneCall class that initializes aphone and makes a voice phone call.
The definition for this class mightlook like this:class CPhoneCall : public CActive{enum TCallState {EDialing, EDone, EError};public:∼CPhoneCall();public:// Static constructionstatic CPhoneCall* NewLC();static CPhoneCall* NewL();public:void MakeCall(TDesC& aTelephoneNumber);private:CPhoneCall();void ConstructL();void InitL();void DoCancel();void RunL();RTelServer iTelServer;RPhone iGsmPhone;RLine iPhoneLine;RCall iPhoneCall;TRequestStatus iCallStatus;TCallState iCallState;};Notice that this class is an active object that uses the iCallStatevariable to track its communication state and the iCallStatus variableto monitor its I/O progress.254TELEPHONYNow, consider the definition of the InitL() function as it appliesto the telephony server. Here, we want to deal with a voice call over aGSM phone:void CPhoneCall::InitL(){RTelServer::TPhoneInfo phoneInfo;RPhone::TLineInfo lineInfo;RPhone::TCaps capabilities;RLine::TCaps lCapabilities;TInt result;TInt phones, lines, calls;TFullName name;// Connect to the telephony serverresult = iTelServer.Connect();User::LeaveIfError(result);// Load the right TSY_LIT(KTsyToLoad,"gsmbsc.tsy")result = iTelServer.LoadPhoneModule(KTsyToLoad);User::LeaveIfError(result);// Get information about phones from the serverresult = iTelServer.EnumeratePhones(phones);User::LeaveIfError(result);if (phones == 0) User::LeaveIfError(KErrNotSupported);// other code to init phones, lines and calls}We connect to the telephony server and load the GSM TSY module.
Ifno phones are supported (for example, if no GSM TSYs could be found),this code leaves with an error code.The phone abstractionAfter connecting to the ETel server, a phone supported by the telephonyserver should be selected. Phones are characterized by the RPhone classand are accessed through a subsession established by an RPhone object.As when establishing connections and sessions, we use Open() andClose() functions for this. After opening a phone subsession, notifications can be set up and the phone must be initialized. Changes tothe phone’s state and capabilities are reported to the client application using functions known as notifications. Generally, the client makesA STRUCTURAL OVERVIEW255all the notification requests prior to calling any functions which maychange the state of the telephony device.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
