In order to provide you with the proper perspective for IMS and how it is used, we will offer an introduction to the overall IMS network architecture. We'll consider: What is IMS? Why use it? Who's using IMS? Then we will dive into the core of IMS: ParlayX SOA Web services. We'll look at the function calls that the services provide and how those serivces fit in the IMS world. Finally, we'll give a real-world example that shows how to create a useful telecom service using IMS SOA ParlayX Web services.
IP Multimedia Subsystem (IMS) is a set of specifications that describes the Next Generation Networking (NGN) architecture for implementing IP based telephony and multimedia services. IMS defines a complete architecture and framework that enables the convergence of voice, video, data and mobile network technology over an IP-based infrastructure. It fills the gap between the two most successful communication paradigms, cellular and Internet technology. Do you ever imagine that you can surf the Web, play an online game or join a videoconference no matter where you are using your 3G handheld device? This is the vision for IMS; to provide cellular access to all the services that the Internet provides.
IMS was initially defined by the 3rd Generation Partnership Project (3GPP), which is a collaboration agreement among a number of telecommunications standards bodies, as part of their standardization work for supporting GSM networks and radio technology evolution. IMS was first introduced in 3GPP Release 5, where "Session Initiated Protocol" (SIP), defined by the Internet Engineering Task Force (IETF), was chosen as the main protocol for IMS. It has been further enhanced in Releases 6 and 7 of 3GPP to include additional features like presence and group management, interworking with WLAN and CS based systems, and Fixed Broadband access.
Another standards body, 3rd Generation Partnership Project 2 (3GPP2), also standardized their own IMS. 3GPP2 was born to evolve North American and Asian Cellular Radio-telecommunication Intersystem Operations into a third-generation system. The initial release of 3GPP2 specifications on IMS largely adopts from 3GPP Release 5. The two IMS network defined by two organizations are fairly similar but not exactly the same. 3GPP2 added appropriate adjustments for their specific issues. Nevertheless, the purpose of both organizations is to ensure the IMS applications will work consistently across different network infrastructures.
In addition to the 3GPP and 3GPP2, Open Mobile Alliance (OMA) plays an important role on specifying and developing IMS service standardization. The services defined by OMA are built on top of IMS infrastructure, such as Instant Messaging (IM), Presence service, and Group Management Service.
We've discussed the idea of IMS as a way to offer Internet services everywhere using cellular technology. You may already be very familiar with accessing Internet services like Web access, email, or instant messaging via a 2.5G and 3G cellular phone. As a result, you may wonder why we need IMS.
The benefits of IMS over the existing cellular network infrastructure can be demonstrated in the following four aspects.
- IMS provides a common platform to reduce time-to-market for rolling out new multimedia services: One of the biggest challenges in today's communication network is to improve the long and costly process for creating a new service. Service providers are looking for ways to reduce the time-to-market for rolling out new multimedia services. The IMS infrastructure solves this problem by providing the standardized platform and reusable components. The standardized interface and common features provided by IMS infrastructure enables service providers to easily adopt a service created by third parties and create a service that integrates with many services effectively. In addition, with the standardized interface provided by IMS, the service is no longer solely provided by a single provider; any provider who implements the standardized interface can provide the service. The multi-vendor service creation industry leads to an open market, and allows service providers to choose the most effective way to roll out new services.
- IMS provides multimedia services with Quality of Service (QoS) enablement:: Although the dramatically increased bandwidth in 3G cellular networks provides a much faster and more reliable Internet access compared with 2.5G cellular network, there are no guarantees about the quality of the services. A 3G cellular network provides what is known as "best effort, which means the network will do its best to ensure the required bandwidth, but there is no guarantee it will remain at the same level. Consequently, the bandwidth of a particular connection can vary significantly over time. In order to solve this problem, Quality of Service (QoS) mechanisms were developed in order to provide certain guarantee levels of network bandwidth during transmission instead of the so called "best effort". IMS specifies enablement of Quality of Service within the IP network and takes advantage of th QoS mechanism to improve and guarantee the transmission quality.
- IMS allows operators to charge multimedia session appropriately: If a user uses videoconference over the 3G cellular network, there is usually a large data transfer that consists of audio and video. This is usually expensive since the operator will generally charge by the number of bytes transferred. On the other hand, if the operator is willing to provide a different charging scheme based on the actual service type, it may be more beneficial to the users. The advantage of IMS is that it provides information about the service type being invoked by the user and thus allows the operators to determine how to charge the users based on service types, i.e. they can choose to charge user by the number of bytes transferred, by the session duration (time-based), or perform any new type of charging.
- IMS allows all services to be available irrespective of the users' location: A typical, and particularly annoying problem when working with cellular technology is that some of the services will not be available when the user is roaming in another country. To resolve this problem, IMS uses Internet technologies and protocols in order to allow users to move across the countries and still be able to execute all the services as if they were from their home networks.
IMS architecture supports a wide range of services that are enabled based on SIP protocols. As you can see from Figure 1-1 below, an IMS architecture delivers multimedia services that can be accessed by a user from various devices via an IP network or traditional telephony system. The underlying network architecture can be divided into three layers (Device Layer, Transport Layer, and Control Layer) plus the service layer and will be introduced from bottom to top respectively.
- Device Layer: The IMS architecture provides a variety of choices for users to choose end-point devices. The IMS devices such as computers, mobile phones, PDAs, and digital phones are able to connect to the IMS infrastructure via the network. Other types of devices, such as traditional analog telephone phones, although they are not able to connect to an IP network directly, are able to establish the connection with these devices via a PSTN Gateway.
- Transport Layer: The transport layer is responsible for initiating and terminating SIP sessions and providing the conversion of data transmitted between analog/digital formats and an IP packet format. IMS devices connect to the IP network in the transport layer via a variety of transmission media, including WiFi (a wireless local area networks technology), DSL, Cable, SIP, GPRS (General Packet Radio Service is a mobile data service), and WCDMA (Wideband Code Division Multiple Access, a type of 3G cellular network). In addition, the transport layer allows IMS devices to make and receive calls to and from the PSTN network or other circuit-switched networks via the PSTN gateway.
- Control Layer: The Call Session Control Function (CSCF), which is a general name that refers to SIP servers or proxies, is one of the core elements in the control layer. CSCF handles SIP registration of the end points and process SIP signal messaging of the appropriate application server in the service layer. Another element in the control layer is the Home Subscriber Server (HSS) database that stores the unique service profile for each end user. The service profile may include a user's IP address, telephone records, buddy lists, voice mail greetings and so on. By centralizing a user's information in HSS, service providers can create unified personal directories and centralized user data administration across all services provided in IMS.
- Service Layer: On top of the IMS network architecture, we have the service layer. The three layers described above provide an integrated and standardized network platform to allow service providers to offer a variety of multimedia services in the service layer. The services are all run by application servers. The application servers are not only responsible for hosting and executing the services, but also provide the interface against the control layers using the SIP protocol. A single application server may host multiple services, for example, telephony and messaging services run on one application server; one advantage of this flexibility is to reduce the workload of the control layer. There are many application servers providing different services, and three core application servers of IMS will be highlighted below.
- Presence server: A "Presence server" provides the services to collect, manage and distribute the real time availability and the means for communicating among users. It allows users to both publish their presence information and subscribe to the service in order to receive notification of changes by other users.
- Group List Management server: A "Group List Management server" provides services that allow users or administrators the ability to manage, create, modify, delete and search the network-based group definition and the associated lists of members. It also maintains the access permissions and other specific properties associated with the groups and the members. It is also used to provide buddy lists for instant messaging or other services.
- Instant Messaging Server: An "Instant Messaging server" provides a communication service that allows users to send and receive messages instantly. Users are able to deliver the messages containing rich text, images, audio, video, or the combination of these over an IP network. It has been widely used in today's Internet community, and IMS will bring the same service experience into the mobile world.
Figure 1-1. IMS Architecture Diagram
Service providers are eager to allow their customers to be able to develop and implement services that leverage the existing the service resources described above. However, many enterprise application developers may have an IT background but are not familiar with those complex telephone protocols (e.g. SIP, ISDN, SS7 etc.); and they need a simple API for services creation and development. It then falls to Parlay X SOA (Service-Oriented Architecture) Web services, which have been defined by Parlay Group in 2003 in order to provide a set of simple-to-use, high-level, telecom-related Web services. The idea with Parlay X is to provide Web services in a context that is already widely adopted and understood by a large number of developers and programmers, and to do so in an environment where there are a variety of development tools available. With the Parlay X SOA Web services interfaces, the application developers can access and leverage the existing IMS services more easily through Web services. The Parlay X SOA Web services are connected to the telecommunication network either via the Open Services Access - Gateway (OSA-GW) or directly through data service components over IP Protocols.
The details of the Parlay X SOA Web services are explained in the next section.
2. IMS SOA Parlay X Web Services
At this point, you should have a basic knowledge of IMS. It is analogous to a rich toolbox with a variety of tools for the Telecom industry, and SOA Parlay X Web services is among one of the most serviceable of the resources in this toolbox. In this section you will learn what SOA Web services are at your disposal.
Figure 2-1 depicts a high-level view of the Parlay X SOA web services within the IMS architecture:
Figure 2-1. How Parlay X SOA Web services fit into the IMS world
Before we get into the details, we need to understand more about Parlay. Parlay is a non-profit standard body that was established in 1998. It consists of numerous companies. Its principal objective is to formulate a common set of APIs (Application Programming Interfaces) specifically for the telecom industry to create innovative services. Because of the sky-rocketing popularity of Web services, in 2000 the Parlay 4.0 APIs were updated to become Web services, with the intention of enabling the creation of a SOA (Service Oriented Architecture). We call the product of this migration ,SOA Parlay X Web Services. With the birth of SOA Parlay X Web Services, IT developers with no telematic knowledge can now manipulate with telecom services as if calling any ordinary Web service: just make a simple function call from your Java program, and you can tap into the perplex telecom world in a simple and straightforward way.
There are 17 Parlay X Web services in Parlay 4.0; it's richness enables developers to create a vast ocean of innovative telematic services, the possibility is limited only by a developer's imagination:
- Common
- Third Party Call
- Call Notification
- Short Messaging (SMS)
- Multimedia Messaging (MMS)
- Payment
- Account Management
- Terminal Status
- Terminal Location
- Call Handling
- Audio Call
- Multimedia Conference
- Address List Management
- Presence
- Message Broadcast
- Geocoding and Mapping
- Application driven Quality of Service (QoS)
We will introduce some of the most essential and interesting services in depth, and briefly touch on the remaining services. Let's get started!
2.1 Parlay X Web service- Third Party Call
Simply put, a Parlay X Third Party Call Web service allows you to initiate a call connection between two phones. Through the exposed high-level Web service interface, a developer is empowered to setup a phone call between two arbitrary callers from a Java program, whether it is an application, servlet, or even EJB (Enterprise Java Bean). A makeCall(Agent1, Agent2, ...) sets up the call connection between agents 1 and 2, this is shown in figure 2-2:
Figure 2-2. Third Party Call function: makeCall(Agent1, Agent2, ...)
If you successfully established the SIP call between the two parties, a CallIdentifier will be returned representing this specific call session. Passing the CallIdentifier into the function getCallInformation(CallIdentifier), you can retrieve information relevant to this call session, such as the call status, the duration of the session, the call start time, and termination cause, if the session has been terminated. This is shown in figure 2-3:
Figure 2-3. Third Party Call function: getCallInformation(CallIdentifier)
Suppose you wish to end the SIP call session between Agent 1 and Agent 2; you can issue an endCall(CallIdentifier) function call on the Third Party Call Web service. Similarly, the CallIdentifier parameter you passed uniquely represents a specific call session. This is depicted in figure 2-4:
Figure 2-4. Third Party Call function: endCall(CallIdentifier)
The last operation that Third Party Call gives a developer is the ability to cancel a call, using a cancelCall(CallIdentifier) function. The difference between a cancel call and a stop call is that the former is used during the time period when the session has NOT been fully established after the makeCall() request, while the latter is used AFTER the session has already been successfully establish with the makeCall request().
2.2 Parlay X Web Service- Presence
A Parlay X Presence Web service allows your application to subscribe to a presentity, and synchronously query a presentity's current presence information. It then asynchronously receives a notification when the presentity changes its status, and unsubscribes to a presentity. A presentity is an entity whose presence information is of interest. For instance, you can use a Presence Web sevice to subscribe to your own car's OBU (On-Board Unit) using the Web services function subscribePresence(Presentity, Attributes,...), the Presentity parameter should be the URI pointing to the location of your OBU, such as a SIP URI. After a successful subscription, you then can issue a getUserPresence(Presentity, attributes) to retrieve the latest presence information of your car's OBU synchronously. This is depicted in figure 2-5:
Figure 2-5. Retrieving Presence information synchronously using getUserPresence(Presentity, Attribute)
At this point, you may wonder, how does the Presence Web service know the latest presentity information of your car? This is achieved through another service call made by your Car's OBU on the Presence Web service: the publish(Presence) method. The publish(Presence) function allows your car OBU to periodically publish its presence information, such as its location, status, current activity, preferred communication type, or privacy level to the Presence web service, which in turn is stored via the backend Presence Server into a database. This flow is shown in figure 2-6 below:
Figure 2-6. publish your presentity information periodically for later retrieval using publish(Presence)
Now that you've seen how to publish presentity information, and how to retrieve the information synchronously, you should know that there is also the option to retrieve the information asynchronously. For example, this can be done if you want to get a notification asynchronously when your car changes its location. You will need to first call the Web service function startPresenceNotification(Presentity, Attrributes ...), and if the location status changes for your car, you will receive a notification with the latest modified changes. See figure 2-7:
Figure 2-7. receive notification on presentity's status change asynchronously
When you call startPresenceNotification(), you will also pass in a Correlator as a parameter. This correlator serves one important purpose: to later end this notification request. Through the endPresenceNotification(Correlator) Web service call, your program can terminate the notification request specified by the correlator, thus you will stop receiving future notifications.
2.3 Parlay X Web Service- Terminal Status
The Parlay X Terminal Status Web service provides similar functionalities as the Presence Web service, only it is simpler and solely allows you to query the status of an IMS terminal device. On the other hand, the Presence Web service provides a rich and complete set of presentity information, sometimes TOO rich and too resource-consuming for a simple application that only cares whether a certain cell phone is currently on-line or off-line.
By calling on the Terminal Status Web service's getStatus(TerminalAddr) function, you can retrieve the current status of a IMS terminal synchronously. An IMS terminal might take the form of, say, a 3G phone. The status returned has exactly three types: Reachable, Unreachable and Busy. Figure 2-8 shows a sequence diagram on how this works:
Figure 2-8. using getStatus(TerminalAddr) to retrieve the current status of an IMS terminal, such as a 3G phone
You can also obtain the status of an entire group of IMS terminals with one method Web service call, with the getStatusForGroup(TerminalAddr[]) function. By passing in an array of Terminal devices' addresses, these devices' status can be queried, processed, and returned with a single call. For instance, we have an array A of SIP URIs consisting of sip:phone1@parlay.com, sip:phone2@parlay.com and sip:phone3@parlay.com, we now pass array A into this method call, such as getStatusForGroup(A), the return value will be another array B consisting of something like [Busy, Busy, Reachable], indicating that phones 1 and 2 are busy at the moment, while phone 3 is reachable. This scenario is illustrated in figure 2-9:
Figure 2-9. using getStatusForGroup(TerminalAddr[]) to retrieve multiple IMS terminals' status
![using getStatusForGroup(TerminalAddr[]) to retrieve multiple IMS terminals' status](figure2-9.gif)
Finally, as in the Presence Web service, you are also allowed to receive notification asynchronously when the status of a specific IMS terminal changes, you do this using a startNotification(..., TerminalAddrs, Correlator, ...) function call to Terminal Status web service. Likewise, you use another endNotification(Correlator) to terminate any future notifications.
2.4 Parlay X Web Service- Payment
As noted in the beginning of this section, IMS can be seen as a huge toolbox filled with a great deal of tools for the Telecom industry, and as they become adopted, you'll need a payment mechanism to offer integrated billing. The Parlay X PaymentWweb service supports payment and billing for contents in an open and Web service-based fashion.
There are two modes for charging with the Payment Web service: charge by amount and charge by volume. As the name implies, the former allows you to charge by quantity, while the latter allows you to charge by, say, time. A request on the Web service operation chargeAmount(endUserID, ChargeInfo, ...) allows you to charge to endUserID, which usually is a SIP URI such as sip:user@parlay.com. Another call to refundAmount(endUserID, ChargeInfo, ...) allows you to refund a certain amount from the previous charge.
Similarly, if you wish to charge a user by time, such as the time a user uses his cellular phone to watch video over 3G, you can issue a chargeVolume(endUserID, Volume, ...) request. And later refund using refundVolume(endUserID, Volume, ...).
A common scenario for you to use a Payment service is when your client uses a Web-based SMS (Short Messaging Service) or MMS (Multimedia Messaging Service). When the user successfully sents out a SMS or MMS, Payment web service will then be invoked and the user will be charged and billed.
2.5 Parlay X Web Service- MMS and SMS
According to Forrester Research Inc., text and multimedia messaging revenue in the Telematics market will exceed $4.3 billion by the end of 2006; it's easy to see that an ambitious service provider should not omit the innovations spawned from SMS (Short Messaging Service) or MMS (Multimedia Messaging Service). IMS Parlay X MMS and SMS Web services provides Web service based interfaces for your application to invoke, send and receive SMS or MMS messages.
Let's begin with the simpler one: SMS. The function calls are relatively intuitive. If you wish to send out a SMS, you can invoke the Web service method sendSms(Addresses, SenderName, ..., Message). The Addresses indicate a list of recipients for this message, while the Message parameter contains the message body itself. A SmsID. will be returned by the call to sendSms(), representing this sepcific SMS request. This is depicted in figure 2-10:
Figure 2-10. sending a SMS message
After calling sendSms(), you can invoke getSmsDeliveryStatus(SmsID) to confirm the delivery, the delivery status will be one of the following:
- DeliveredToNetwork
- DeliveryUncertain
- DeliveryImpossible
- MessageWaiting
- DeliveredToTerminal
Apart from the traditional sendSms(), you are also allowed to send Ringtones and Logos using methods sendSmsRingtone(Addrs, Ringtone, ...) and sendSmsLogo(Addrs, Image, ...) respectively. Note that the Ringtone should be in RTX format (a XML file that contains the ringtone name and the definition of the ringtone) while the image should be in JPEG, GIF or PNG format.
MMS works more or less in the same fashion, with sendMessage() for sending MMS messages and getMessageDeliveryStatus() for confirming the develivery. MMS messages are attached as a SOAP message with attachment, which is beyond the scope of this article. MMS messages include multimedia contents such as video, image or audio, which formed the basic services provided by most 3G operators.
2.6 Other Parlay X Web services
We've seen how to use 6 of the Parlay X SOA Web services, the rest of the Web services work in the same scheme, which allows your program to invoke a Web service call, each with different functionalities.
Here we've organized a chart descirbing what the rest of the Parlay X Web services empowers. with regard to your application:
Table 2-1. full list of Parlay X SOA Web Services and their functionalities
| IMS Parlay X SOA Web services | Description |
|---|---|
| 1. Common | Common infrastructure and XML definitions used by all the other services |
| 2. Third Party Call | See section 2.1. Connect call between two IMS terminals using your application. |
| 3. Call Notification | Sends a status notification to your application when a caller makes a call, ends a call. |
| 4. Short Messaging (SMS) | See section 2.5. Allows your application to send out a SMS, receive a SMS. |
| 5. Multimedia Messaging (MMS) | See section 2.5. Allows your application to send out a MMS, receive a MMS. |
| 6. Payment | See section 2.4. Online charging Mechanism. |
| 7. Account Management | Support account query, management, account direct recharge or charge with vouchers. |
| 8. Terminal Status | See section 2.3. Provide you with the status of an IMS Terminal. |
| 9. Terminal Location | Provide you with the location of an IMS terminal |
| 10. Call Handling | Allows your application to decide how to handle a call. Block a call, forward a call, accept all calls, play audio for the incoming call...etc. |
| 11. Audio Call | Provides a flexible way for the delivery of audio contents. E.g. VoiceXML, WAV, Text. |
| 12. Multimedia Conference | Allows your application to create a multimedia conference, dynamically manage participants and manage the media used. |
| 13. Address List Management | Manage groups and members. Create, delete, manage access rights...etc. |
| 14. Presence | See section 2.2. Provide you with detailed location and presentity of an IMS Terminal. |
| 15. Message Broadcast | Allows your application to broadcast a message to all the IMS terminals within a specified geographical range. |
| 16. Geocoding and Mapping | Transform the coordinates of a IMS terminal into a geographical location, such as an human readable address. |
| 17. Application driven Quality of Service (QoS) | Application controlled Quality of Service |
At this point you should have an understanding of what each of the Parlay X SOA Web services do, and what role Parlay X Web services play in the IMS world. In the next section, we'll actually utilize a few of the Parlay X Web services introduced above to create an innovative and useful real world application.
3. Real World application using IMS Parlay X Web Services
Let's consider an automotive company that wants to implement their customer service infrastructure by using IMS parlayX Web services, and installs a device that has the parlayX Web service capability on each automobile. One of the Parlay X Web services that they could use is the "third party call" feature. For example, the automotive company could input customer's mobile phone number when the customer registers his/her car. So, at any time, when the customer has questions, he or she would just need to click on the "customer service" button, the "makeCall" operation will initiate a call between the customer and customer service center. At any time during the call, the customer may click the "cancel" button to invoke the "cancelCall" or "endCall" operation to cancel or terminate the call identifier respectively.
Figure 3-1. auto-contacting customer center by using the Third Party Call web service
Another case could be giving a mechanic an easy way to call a customer's cell phone when his/her car's maintenance has been completed. The customer provides a cell phone number when dropping off the car for the first time. When the mechanic completes the maintenance, he or she uses "makeCall" to initiate a call to the customer, and a prerecorded message indicates that the car is ready for pickup. The mechanic doesn't have to spend time looking up the customer's phone number, dialing the phone, or talking to the customer. If the call cannot be completed, the "getCallInformation" operation allows an automated system to retry failed numbers or indicate the customer needs to be contacted another way.
For telemetrically-enabled cars, the Parlay X Web service for sending and receiving SMS messages could be used to transmit the data between the customer and the service center. For example, the vehicle's key systems such as engine, antilock brakes, and remaining oil life are checked every month, and the data is sent back to the customer service center by using the "sendSms" operation. The customer can receive an automatic email report on his/her car's status. Between monthly reports, if the car is malfunctioning, the customer could push the "diagnostics check" button, forcing the system to invoke a "sendSms" operation to send the data to the service center. Based on the data received, the technician could quickly assess the problem and "makeCall" to the customer. The "sendSms" operation also can used to send short messages to the customer to alert him or her of any abnormal vehicle status or to remind him or her that scheduled maintenance is due.
In addition to customer service support, the Parlay X Web service may add futuristic feature to an automobile. For example, a service provider could use IMS Parlay X Web service technology to implement a service infrastructure platform to provide many services, such as traffic status, points of interest, on-sale information, restaurant locations, and other services. When car engine is started, the Palay X Web service device could "publish" its active status to the service infrastructure platform via the Presence Supplier interface of the Presence Parlay X Web service. Each automobile could use "sendSms" to send the current driving speed of the car to the service provider. The driver may "subscribePresence" for the things that he/she is interested in.
Figure 3-2. obtaining POIs using Presence Web service
This is not simply pure imagination; using IMS SOA Parlay X Web services, these scenarios can be implemented right into your very own car!
IMS is a state-of-the-art technology toolkit for the Telecom industry and is analogous to a rich toolbox with a variety of tools for your application to tap easily into the telematics world. Simply put, IMS uses Internet technologies to provide vast services and mobile technology to provide ubiquity. In the first section of this article, you got a chance to see IMS from a macroscopic view -- what it is, why it's important and how it can be used. In the second section, we introduced SOA Parlay X Web services, one of the most serviceable tools in this toolbox. We looked at some of the most interesting Parlay X Web services and how they work and what they empower you to do. In the last section, we composed an innovative real-world telematic application using some of the Parlay X Web services we introduced in the second section.
IMS is, and will continue to be an important part of the Telecom industry. It is far too extensive to be looked at thoroughly in a single article. In our next installment, we'll introduce you to another crucial component of IMS.
Learn
- Read the Wall Street Journal article "Text Messages Sent by Cellphone Finally Catch On in U.S."
- A whitepaper from Ericsson, "IMS: IP Multimedia Subsystem" (PDF) outlines how IMS enables a secure service-driven approach to moving all traffic to the packet switched domain and Session Initiation Protocol (SIP) logic.
- A whitepaper from 3G Americas, "IP Multimedia Subsystem IMS Overview and Applications" outlines the benefits and multiple applications of IMS.
- Lucent's whitepaper "IP Multimedia Subsystem (IMS) Service Architecture" (PDF) presents an overview of the IP Multimedia Subsystem (IMS) architecture.
- Gonzalo Camarillo and Miguel a. Garcia-Martin's book "The 3G IP Multimedia Subsystem, Merging the Internet and the cellular worlds" offers a comprehensive view of IMS.
- Read the Wikipedia entry on the IP Multimedia Subsystem.
- Stay current with developerWorks technical events and Webcasts.
Discuss
- Participate in developerWorks blogs and get involved in the developerWorks community.
Rebecca Chen is a staff software engineer at IBM China Development Lab in Taipei, Taiwan. She joined IBM in 2000 and has experience in software design, development, and testing. She holds a Master degree in Computer Science and Information Engineering from National Dong Hwa University. Her areas of expertise include Global Security Toolkit, WebSphere Application Server, WebSphere Everyplace Access, WebSphere Everyplace Deployment, pervasive computing, and networking. She currently focuses on IBM IMS (IP Multimedia Subsystem) Solutions. She has Cisco Certified Network Associate (CCNA) Certification and is also a certified Project Management Professional.
Elisa Su is a staff software engineer at China Software Development Lab, IBM Taiwan on the IBM IMS GVT team. She is the testing leader for the Globalization Verification Testing against Message and Data Services component of IMS. Prior to that, she was the development leader for the IBM worldwide technical support site. Her areas of expertise include J2SE/J2EE programming, Web application development, content management, and project management.
Victor Shen received a Masters degree from National Chiao-Tung University, Dept. of Computer Information Science, and was selected as a honorable member of the Phi-Tau-Phi Scholarlistic Society. He joined IBM China Software Development Lab in 2005 and was responsible for the development of IBM Enterprise LAS middleware applications and currently focuses on IBM IMS (IP Multimedia Subsystem) solutions. He is also a Sun certified Programmer, Sun certified Business Component Developer and IBM certified On Demand Business Solution Designer.
Yi-Hong Wang is a software engineer at the China Software Development Lab. He joined the IBM worldwide technical support project from 2004 to 2006. Currently he is responsible for the IMS Performance test project. He has worked on Java programming in the J2SE/J2EE environment, including WebSphere Application Server and DB2.
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
