Concepts with Symbian OS (779878), страница 54
Текст из файла (страница 54)
For example, one contactmanager client may be responsible for setting up a data call while anotherclient is responsible for data transfer.Call termination, that is, ‘hanging up’ the phone, is accomplishedthrough the HangUp() function. This function initiates termination ofthe call. Depending on the network, hang-up functions may behavedifferently.
For example, for GSM networks, it takes time for the call tobecome idle (hence the hanging-up state) but it is not possible to reconnect a call once this request has been made. On some wired networksit is possible to hang up and then, if the remote party has not terminatedthe call, retrieve the call again.12.3Voice over IP TelephonyTo fully appreciate the telephony model that Symbian OS implements, itis useful to consider a new form of telephony: voice over IP (VoIP). UnlikeGSM (which is circuit-switched), VoIP calls are packet-based transfers ofdigital data, but the medium of transfer is a computer network. First, let’stake a brief look at how VoIP works, as shown in Figure 12.3.TCPPublic-switchedtelephone networkFigure 12.3 Simplified diagram of VoIP connectionsVOICE OVER IP TELEPHONY261Several different phone types can be used with VoIP.
Conventional,analog phones need to have an analog telephone adapter (ATA) thatconnects to a network; mobile phones with network capability canconnect through wireless networks; digital phones connect directly toa network.In all cases, the phone unit connected to a network may begin the callby using Session Initiation Protocol (SIP). SIP is a protocol that createssessions and handles many of the logistics of finding the endpoint (mobilephone or digital phone) to which the phone call will eventually connect.Usually, calls are initiated by engaging in SIP with a VoIP provider.
Thisprovider provides mapping services to map the locator information (e.g.,a telephone number) to an IP address on the network or a destinationon a public-switched telephone network (PSTN). If the service finds thedestination on the network, it informs the caller where the destinationis and the caller forms a peer-to-peer relationship with the destination,exchanging data packets that represent the voice conversation. If thedestination is on a PSTN, the server becomes the destination and a proxy,relaying voice traffic from the network over the PSTN.For our purposes, VoIP provides an illustration of how telephonymodels work. In a conventional operating system such as Linux, a completely different model must be used to implement VoIP. The old modelwas a low-level one: phone equipment was controlled by interactingwith it over a wired connection with control functions.
VoIP would beimplemented as part of the networking communications stack, not withcontrol functions. SIP is an application protocol that uses TCP to transport its packets. So a VoIP application interacts with sockets and TCPconnections, sending SIP packets and receiving responses. While theconcept of send-and-receive is the same, different media means differentimplementations.Modular models, such as the one in Symbian OS, also require newcoding to implement new technologies such as VoIP, but the changeshappen in a modular fashion supplied by the system. In Symbian OS, VoIPcan be implemented by a new TSY module.
In fact, in our CPhoneCallexample, the only change to our code would be to change which TSYmodule was loaded in CPhoneCall::InitL(). The remainder of thecode can remain intact because of the structure of the Symbian OStelephony model.Smartphones that have access to any packet-based network can provideVoIP implementations. Devices that support Symbian OS v9 and abovehave the capability of supporting wireless network access as well, which262TELEPHONYcan be used to implement VoIP in addition to (or even instead of) accessover a more traditional cellular network.As an example, consider Nokia S60 3rd Edition phones, which runSymbian OS v9. The Nokia E61 implements VoIP in two parts: the SIPcomponent that engages a VoIP provider’s server and the network callingsettings that determine which SIP settings to use. After these are configured, the phone can make calls over GSM or over a network medium.Look for these types of implementation in Symbian OS phones withTCP/IP network access built-in.12.4SummaryIn this chapter, we have taken a look at how operating systems supporttelephony.
We summarized how conventional systems allow telephonyto be manipulated as low-level devices and protocols. We then spentconsiderable time looking at how Symbian OS views telephony in termsof four key constituents: an ETel telephony server, a phone abstraction,phone line abstractions defined for a specific phone, and finally a callmade over one such phone line. We reviewed how to set up the structureso that we can use phone calls and we looked at making and answeringcalls.
We defined how applications can be notified when changes inthe phone system and settings are made. We concluded the chapter bylooking at voice over IP and how it fits into telephony models.Exercises1.If a phone is used as a modem, is that considered telephony? Does itfit into the telephony model?2.Why does Linux force programmers to use such primitive methods toaccess system services?3.Why does Symbian OS force programmers to use such high-levelmethods to access telephony services?4.How might a Linux application address VoIP?5.In Symbian OS, does a phone call take up a lot of memory? Does ittake up a lot of CPU time?6.Consider making a phone call in Symbian OS while using other partsof the operating system (such as making a calendar entry). Make aguess as to how much of the system resources the phone call wouldtake up in comparison to other tasks.13MessagingIn addition to telephony, which we covered in Chapter 12, messagingis an area that smartphones do well.
It is their basic functionality toallow communication: both voice and data. As we did with telephony,discussing messaging provides us with a way to compare and contrastoperating system approaches while showing off areas in which certainoperating systems shine.Through experience, most people understand that messages can takemany forms. There are verbal and non-verbal messages; messages arewritten on paper and heard via audio devices; messages can be notespassed in secret or signs on a billboard. Delivery of messages is animportant but sometimes chancy thing (if you have ever had to rely onanother person to deliver a message, you know what I mean). Even withthis wide assortment of message types and delivery functions, humansare able to send and receive messages fairly easily. We have, in fact,developed a system that processes different message types using the samemethods implemented by tools specialized to each message.Electronic messaging is a very diverse area.
There are many electronicmessage types and delivery takes many different forms. For example,email messages can be delivered over a wireless network connection andSMS messages can come through a GSM connection to a mobile phone.So it should come as no surprise that designing a single model that characterizes and works with all message forms is quite a challenge. Operatingsystems approach this area in different – yet predictable – ways.This chapter gives an overview of the message framework implementedby operating systems, with a special emphasis on Symbian OS.
We start264MESSAGINGwith a survey of messaging components and requirements. We then lookat Symbian OS and its messaging framework. We wrap up the chapter bycomparing the approach of Symbian OS to that of Linux.13.1The Character of MessagingLet’s start by stepping back for a moment and taking an overview ofmessaging. Messaging systems need to put together a generic frameworkthat can handle the components of many different message types. Thisframework is likely to view all messages as composed of generic components.
Through the use of abstraction, each different message type canbe handled by a separate implementation of those generic components.Then this abstract message-handling system needs to be built on top ofexisting models and systems.As we look at messages and their components, it is important to notewhere these messages originate on the computer system. All devices havea central message store. This store contains the messages received by andcreated on the device on which it resides. In some operating systems (e.g.,Symbian OS), this message file has a specialized, hierarchical format. Inother systems (e.g., Linux), it is simply a text file that can be parsedin several different ways.
This store can usually reside on any storageaccessible to a device; message applications can usually change wherethis store resides.Let’s look at the messaging framework by pulling apart a message, sowe can build a framework from its component parts.Dissecting a MessageMessages are self-contained data objects sent between two devices. Theyare self-contained in the sense that they do not depend on the sender’s orthe receiver’s environment. They are data objects because they may takeone of a number of forms, and their definition is open-ended.
Messages aretypically used to relay specific pieces of information between machines,as well as humans.Messages have several common characteristics.• A sender : each message originates from somewhere, either from aperson or a computing device. The identity of the sender is usuallyincluded with the message, although that identity can rarely be trusted.THE CHARACTER OF MESSAGING265The sender can be one of many entities. Messages can be originalperson-to-person communication or generated by a computer.• An intended destination : messages can be sent to a single destinationor to a group. At some layer in the transport system, messages arealways sent device-to-device.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
