|
The Parlay specification provides easy access to telephony networks via Java, CORBA, and web services.
November 01, 2004
URL:http://www.drdobbs.com/mobile/telephony-the-parlay-specification/184405889
Bogdan is director of software R&D and Mike is senior vice president of R&D at Intervoice. They can be contacted at [email protected] and [email protected], respectively.
Telephone services that go beyond simple call completion and point-to-point connections are typically called "enhanced services." You interact with them when you place an automated collect call, check your voicemail, use directory assistance, or download a ring-tone. Writing such applications has been a difficult task, and until the 1980s, it was the exclusive domain of telephony equipment manufacturers and software providers who wrote applications to the requirements of network operators.
In the 1980s, deregulation created opportunities for other parties to connect to the edges of the telephony network and to provide automated telephony services like interactive voice response (IVR) as well as enhanced services. The challenge, however, was in the huge investment in low-level protocols and middleware stacks to accomplish anything useful at the application layer. The early 1990s saw the deployment of the intelligent networks (IN) infrastructure that partitioned functionality by separating the application from the telephony facing equipment, and allowed network operators to create their own services. Most of the current telephony applications run within IN space.
However, IN was not really designed to support third-party applications. The main challenges are the lack of security features that would protect the network "core" from a malfunctioning application, a high-level application framework that abstracts network details, and the ability to share infrastructure among many different applications. Additionally, significant expertise and knowledge of the underlying network are still required to write anything more than trivial applications.
To address those issues, several telecommunications companies founded the Parlay Group in 1998. A year later, the Parlay specification (http://www.parlay.org/specs/index.asp) was adopted by the 3rd Generation Partnership Project (3GPP) for service creation in 3G mobile networks. 3GPP called it Open Service Access (OSA); hence, the common way of referring to the specification is Parlay/OSA.
The main mission of Parlay is to provide programmers with reasonably easy access to telephony networks. The current Parlay realizations are in Java, CORBA, and web services. The traditional IN interfaces such as SS7 and INAP are not directly visible. That limits the capabilities, but the anticipated payback comes from an expanded developer pool, lower development costs, and the leverage of the installed infrastructure. There are millions of developers with Java and web-services skills. The number of telephony protocol-level developers is estimated to be less then 10,000 worldwide.
Parlay API consists of two main groups:
Most Parlay methods are designed to be asynchronous. This is a good fit for the inherently distributed processing on telephony networks. It also lets applications handle various facets of call processing within a familiar event-processing model. The event notification is accomplished through callback interfaces that the application implements. The specs use UML notation and come with both IDL and WSDL files.
A lot of the functionality that Parlay handles originated in the mobile area. However, Parlay specs do not restrict functions to wireless networks and currently define parameter values that refer to land lines and IP-based telephony. But the initial focus is still on mobile applications.
Interestingly, the Parlay Group was concerned that, despite all the high-level abstractions, the Parlay specification still required a good deal of telephony network understanding. They created a separate specification called "Parlay X," which explicitly defines web services as the API presentation. It also assumes that the authentication and authorization functions are accomplished by the web-services infrastructure instead of a Parlay-specific solution. The Parlay X spec covers about 80 percent of the Parlay capabilities. But, because it is a concrete implementation based purely on web technologies, you can use any client environment that supports web services to develop your application, including .NET and Java.
The latest mobile network technology (known as "3G") promises to provide a few more exotic features (and enough speed to deliver them) than previous generations. In this article, we examine location services and multimedia messaging services as they may be deployed in the 3G network. But first, some background on some of the underlying technologies we will be using:
Multimedia Messaging Service (MMS). Since the early 1990s, the Short Message Service (SMS) has been the most popular form of mobile messaging. (For more information, see "Short Message Services," by Ron Hume, DDJ, October 2001.) SMS is available on GSM networks that dominate outside of the U.S. and are rapidly gaining ground within the U.S. Despite the limit of 160 characters in its basic form, SMS has been widely popular. The latest versions and enhancements overcome the size limitations and piggyback other services on top of it. In 1999, the 3GPP group proposed the new Multimedia Messaging Service (MMS) Standard. MMS is based on Internet multimedia technologies and aims to deliver multimedia experience to mobile devices. MMS content is encoded as a multipart MIME document and can include different media types. The minimum requirement for an MMS-enabled device is support for the text/plain format, but most devices also support audio and images. However, you need to consider the limitations of phone sizes and capacities. For example, screen sizes range from 128×128 pixels, through 176×208, up to 208×320. You can find a higher resolution on devices that look like small game consoles. The total message size is usually limited to somewhere between 30-100 KB, depending on the device.
Location Service. The User Location Service lets applications obtain the geographical location and the status of mobile devices. There is also a separate, specialized functionality to handle emergency calls—911 in the U.S., for example. That distinction helps address privacy concerns by selectively enabling service types and applications. To offer even more control, some handsets also let you disable the location capability through a menu option. When you dial an emergency number, the location capability should be restored automatically.
The horizontal location is encoded as the longitude and latitude. There is also additional information about the accuracy of the position data. For details, see TpGeographicalPosition in the Mobility SCF specification (Part 6 of the Parlay specification set). The encoding follows the World Geodetic System 1984 (WGS 84) specifications.
The location triangulation may depend on network-based measurements, handset-based measurements, or a combination of both. Many of the modern handsets use embedded GPS as the primary location technology. The triangulation methods may provide a backup in places where GPS signals fade.
At this writing, production Parlay environments are not easily accessible in the U.S. Consequently, we used Ericsson's SDK for its Parlay-based Network Resources Gateway, NRG (http://www.ericsson.com/mobilityworld/sub/open/technologies/ parlay/index.html). The NRG SDK, released in March 2004, includes a simulator we used to test the application. It also includes a few sample applications along with source code.
NRG provides CORBA and Java APIs to High-level OSA (H-OSA). H-OSA is Ericsson's superset of the OSA functionality, but the location and MMS services are part of the base Standard. NRG provides a convenient Java framework that simplifies application architecture and deals with more mundane interaction sequences.
TourGuide is a sample Parlay application that implements a service that sends a map of your current location and a list of points of interest at your request. Figure 1 shows the sequence of high-level interactions. (The complete source code for the application is available electronically; see "Resource Center," page 5.)
You request the map by sending SMS to the service number. Upon receiving your SMS, TourGuide issues a query for the position of your mobile device (phone). Once the location is received, a small map of your location is created and a text list of nearby points of interests (POIs) is generated. Those two pieces of information are combined into MMS content displayed on your device. The implementation of the TourGuide application leverages the NRG framework and generally follows the application pattern recommended by Ericsson.
Figure 2 shows the TourGuide class diagram with main classes and relationships. The TourGuide constructor creates Configuration, ServiceLogic, and AdminGui objects. The Configuration object (an extension of java.util.Properties) loads Parlay access configuration parameters and is used in invocations of NRG methods. The ServiceLogic constructor creates a PointsOfInterest object that manages POI information and generates maps on request. ServiceLogic also provides start()/stop() methods that AdminGui uses to satisfy Start and Stop requests issued from the administrator screen (see Figure 3).
On the first start(), ServiceLogic establishes a connection to NRG framework using com.ericsson.hosasdk.utility.framework.FWproxy, obtains references to User Interaction (UI) and User Location (UL) managers, and creates interaction processors (SMSProcessor, MMSProcessor, and LocationProcessor). Listing One presents the code sequence.
Once all NRG framework references have been initialized, the start() operation just needs to enable the notification for SMS messages arriving on the service number. The number can be adjusted through the AdminGui.
The PointsOfInterest constructor loads POI definitions from a configuration file. This is just a simple notation for the purpose of this application. In a production system, you should consider one of the commercial sources of such information; for example, the Microsoft's MapPoint service (http://www.microsoft.com/mappoint/ mls/default.mspx).
Listing Two is a sample PointsOfInterest configuration file. The map covers the physical area of the TourGuide service. The coordinates are within the map rather than real geodesic coordinates. In a real application, you would need to translate them using the map's geodesic coordinates. However, the NRG simulator uses the same relative convention by default and we did not want to complicate the test setup.
Figure 4 illustrates the sequence of events from SMS arrival to MMS transmission. The smsReceived and locationReceived calls are made within NRG callbacks to SMSProcessor and LocationProcessor. Both processors implement appropriate NRG interfaces. The processors are implementations of slightly modified sample code provided with NRG SDK.
The PointsOfInterest.createMimeContent method produces a location map based on provided location coordinates. The other two parameters are the width and height of the desired map image. In our sample application, the image size is set to 320×320 pixels. A real application may query the device capabilities using Parlay's Terminal Capabilities service. If available, the capabilities information is encoded as prescribed in the W3C CC/PP note on user-side capabilities and preferences (http://www.w3.org/TR/NOTE-CCPP/).
PointsOfInterest output is a multipart MIME document with a JPEG map image and text parts with POI names. Figure 5 shows a sample document rendered on a desktop screen. Figure 6 shows how the same content may look on a mobile device. It is obviously important to strike a balance between the amount of information produced and the viewing capabilities of a device.
The TourGuide application has been tested only with the NRG simulator (see the README information included with the TourGuide source download). It would require some tweaks to work in a real network. However, we hope we've demonstrated what can be accomplished with reasonable effort.
The telecommunication industry evolves in a controlled and hierarchical manner. Any new ways of creation and deployment of services are analyzed and researched. A typical title of a presentation for a mobile telecom conference might read: "Determining the roles of the key players in the evolving mobile value chain and the alliances and partnerships required to deliver competitive and differentiated mobile services." This is different from the rapid, "survival of the fittest" evolution of the Internet and its services.
Will Parlay help accelerate changes? It is definitely a step in the right direction. But the gates will really open when mobile operators (or even land-line operators) routinely offer hosting of custom telephony applications. This would enable small, specialized applications to be created and is an approach that would truly allow mobile operators and wireline carriers to take advantage of proven programming models and technology that will accelerate the deployment of the next generation of enhanced services.
DDJ
// Obtaining NRG framework access
itsFramework = new FWproxy(Configuration.INSTANCE);
// Obtaining service manager for User Interactions (UI)
itsHosaUIManager =
(IpHosaUIManager) itsFramework.obtainSCF("SP_HOSA_USER_INTERACTION");
// Obtaining service manager for User Location (UL)
itsHosaULManager = (IpUserLocation) itsFramework.obtainSCF("P_USER_LOCATION");
// Registering individual processors
itsSMSProcessor = new SMSProcessor(itsHosaUIManager, this);
itsMMSProcessor = new MMSProcessor(itsHosaUIManager, this);
itsLocationProcessor = new LocationProcessor(itsHosaULManager,this);
Back to article//------------------------------------------------------- // PointsOfInterest locations for the TourGuide program. //------------------------------------------------------- // POI location format: X-coord Y-coord ID Text // IDs must be unique. // Map coordinates: UL corner=[0,0], BR corner=[1.0,1.0]) // Map: DallasMap.gif // POIs: 0.8504 0.2865 4 "Adam's Mark Hotel" 0.5836 0.5766 5 "Adolphus Hotel" // and so on ...Back to article
The Parlay Group knows of over 50 implementations of Parlay-based systems. Most of them seem to be internal to telephony network operators. However, there have been new announcements that deliver on the promise of opening the networks to external developers. For example, British Telecom (BT) is going to offer a subset of the Parlay X (web services) platform as a part of the 21st Century Network strategy (21Cn); see document (SIN or STIN) number 418 at http://www.sinet.bt.com/. In the U.S., Sprint PCS announced the Sprint Business Mobility Framework. That service is also based on Parlay X, but is more focused on enterprise applications rather than retail services (http://www.parlay.org/docs/may2004mm/Opening_Plenary/05Sprint_IBM.pdf). Both BT and Sprint provide Parlay X web services for external developers and implement them on top of internal Parlay gateways (with CORBA access). Such architectures let application writers use their preferred development environments and gives telephony network operators good protection of their internal assets.
—B.B. and M.P.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.