The Symbian OS (779886), страница 80
Текст из файла (страница 80)
Analogously with CSY serial communications modules,TSY telephony modules were defined as the abstractions for actual hardware and a similar framework architecture to the serial communicationssystem was adopted. Depending on what hardware was available tothe system (and what application was requested) the TSY would eitherinterface directly to the hardware (the baseband–built-in modem case)TELEPHONY381or access the hardware through the serial communications system (forexample, a TSY sending AT commands to a true Hayes modem or to aGSM phone presenting an AT interface, over infrared or a cable serialconnection).The ETel architecture closely followed the tried and tested architectureof the Comms services.
A classic Symbian OS client–server interfaceshares access to telephony services and hardware between multipleclients. A framework architecture provides for a core API which isextensible in two directions by plug-ins; horizontally, ETel extensions addricher functionality to the basic core set with extensions for fax, packetdata for GPRS and 3G, the Multimode extensions for CDMA2000, andSIM toolkit extensions; vertically, plug-in TSY adapter modules, modeledon the Comms CSY modules, that are loaded on demand interface theabstracted ETel APIs to the actual hardware available.ETel therefore interacted closely with the serial communications systemand, in fact, did so through the generic mechanism of the Socket Server(requesting a serial socket connection, for example).
Looked at fromthe other direction, ETel equally became a socket provider, providingtelephony sockets to serial or networking components.The communications design analogy was an obvious starting point,especially because the design was proven and had shown itself to be bothextensible and flexible. In effect, the whole communications architecturewas elaborated horizontally so that the telephony system was created asClientsClient-side APICore ServerPlug-in frameworkAdapter plug-insFigure 15.6ETel design mirrored the design of the serial comms server382JUST ADD PHONEa peer of the networking and serial communications systems.
The serialsystem was ‘first among equals’, primarily because, in the use cases thatdrove the design, serial communications via modem always provided thephysical access to the network (phone or Ethernet).With hindsight, however, the PDA or two-box use case dominatedover the built-in phone use case. ETel started with a design goal whichit met admirably, but which was rapidly overtaken by the change incontext.
Symbian OS in a phone has different telephony requirements toSymbian OS in a modem-connected PDA.Andy Cloke:Our early design assumptions were not really true any more; modem wasn’tthe primary use case. And certainly the primary use case that we’re dealingwith now is a phone that has a single baseband, and consequently ETel hasmorphed into a baseband abstraction.The more complex question is whether ETel’s design supports theneeds of an abstracted baseband or simply provides an API for applicationaccess to the baseband.In design terms, ETel is a classically good example of object-orientedabstraction.
Its three key concepts are phones, lines and calls. Clientsrequest an RPhone session, from within which an RLine subsession canbe opened and a further RCall subsession can be created.The TSY instantiates corresponding derived classes from the framework: CPhoneBase, CLineBase and CCallBase. In turn, these objectscreate AT commands, instantiated as objects derived from CATBase,which are then sequenced through the TSY’s command sequencer, whichcontrols a communications port requested through a serial communications session owned by the TSY. The communications port in questionprovides a direct (docking-style), infrared or serial-cable connection toan actual phone, which responds to the AT commands.Andy Cloke:I wish in hindsight I had spent more time looking at the ISDN specs, standardwireline phone specs, and the GSM standards.
I think Phone and Call arestill quite valid abstractions, but I think Line was a bit of a waste of our time.It was there originally because, on a single GSM phone in the GSM specs, youcan have a different telephone number for voice calls, data calls and fax calls.TELEPHONY383Fax, indeed, turned out to be troublesome.Andy Cloke:Fax over GSM is tricky because of timing issues.
You have to spoof packetson the base-station side to stop the fax machine timing out because thetransmission delays are too long over GSM. Well, and then it all gets morecomplex because of the alternate numbers. But anyway, I think I would havedropped the Line abstraction.Another, subtle, design assumption that proved a problem comes backagain to assumptions about the nature of the modem that is providingaccess to the phone network.Andy Cloke:That’s something else that ETel was predicated on, that the modem wouldbecome completely commoditized, and while it is slowly moving in thatdirection, with the advent of 3G and all the different services on there andall the different ways that packet data works and some of the services work,that is not true yet.
And coming you have HSDPA and HSUPA – High-SpeedDownlink and High-Speed Uplink Packet Access – which will be the nextservice that will be required. It’s already being referred to as 3.5G. So thesesorts of forces stop the modem software – I’m using these words, modem andbaseband, interchangeably – they stop that software becoming a commoditybecause it just moves on and on, it’s moving so fast.
How many non-proprietary3G signaling stacks are there out there that have any kind of market credibility?I think the answer is as small as three or four, ones where you’re going to buyoff the shelf, so it’s certainly not yet a commodity item.The Problem With ETelCharles Davies:We did a telephony API, whereas what we needed was a distributed computingsolution with a baseband. Or to put it another way, it was not so much atelephony API we needed as a subsystem that does more than telephony, butof which telephony is one application.The more general case of supporting data communications, includingabstracting the baseband, is the direction in which Charles Davies isheading.
With hindsight, the requirement was not to provide abstract384JUST ADD PHONEcontrol for a phone, because outside the two-box context that is notwhat devices require. What devices really require are high speed dataconnections between the application side and the phone baseband. AsDavies puts it, something much more like what he calls ‘a distributedcomputing solution with a baseband.’Charles Davies:What that really means is that you supply a reliable by-value RPC mechanismbetween the two sides which is independent of the application you are doingit from, and then telephony would be one of the applications.On the question of the importance of telephony, Charles Davies iseven more radical.Charles Davies:You can debate how important a telephony API really is anyway.
Manyother APIs are much more important from the point of view of the operatingsystem, in the sense that connections to packet data are more important,because telephony is only needed by one application, although it certainly isan important application. But it’s all the rest of it that allows a phone to bebuilt.Andy Cloke takes a more sanguine line.Andy Cloke:With hindsight we would have preferred to establish a narrower API uponwhich Symbian would have built its services, in other words, data calls,establishment of PDP contexts and secondary contexts, transmission of SMSs,reception of SMSs, these sorts of things. It’s very important that we have anAPI which works well there, a downward, hardware-adaptation-interface-styleAPI.The Danger of the Thin APIFor Andy Cloke, the real lesson here is a more general one about APIdesign in the case where both the application-level API clients and thehardware-level adapters are extrinsic to the operating system, and theoperating system has the role of defining a thin, stable API against whichpartners can develop their value-adding components.
In this case, twobig issues arise: how thin can a thin API be and still be sustainable? And,TELEPHONY385how do you manage the design and development process to ensure thatthe API is viable and the right one?Andy Cloke:ETel today is a baseband abstraction layer and suffers because it tries to providean abstraction for the whole of the baseband. Not just modem functionality,but also the ability to make calls, put calls on hold, do multiparty calls and allthat stuff, and it also contains all the supplementary services, call forwarding,notifications that somebody else has put you on hold, so all of this kind ofLayer Three GSM signaling, all these notifications need to come through. Aswell as that, it also has to be able to transmit SMS messages, which are actuallya reasonably complex beast when you dig down because there are variousdifferent levels of ACK-ing that occur in the SMS protocol stack, and then thereis USSD too, the unstructured service data.Symbian does not build the telephony application above ETel, and we donot own the TSY below ETel.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
