Anda di halaman 1dari 12

Multimedia System Architectures

IMS Application Servers


Roles, Requirements,
and Implementation Technologies
The IP multimedia subsystem (IMS) defines a generic architecture to support
communication services over a Session Initiation Protocol (SIP) infrastructure.
In the IMS architecture, application servers host and execute the IMS service
logic. These servers can be SIP application servers, open services architecture
(OSA) application servers, or a customized applications for mobile networks
using enhanced logic (Camel) service environment. Some technologies used in
telephony and voice-over-IP (VoIP) application servers are also applicable to
IMS application servers, but such servers have some unique requirements that
could limit the extent to which these technologies can meet them.

T
Hechmi Khlifi he Third-Generation Partnership a customized applications for mobile
Dialexia Project (3GPP)-defined IP Multi- networks using enhanced logic (Camel)
media Subsystem1 is becoming the service environment. This article dis-
Jean-Charles Grgoire de facto standard for real-time multi- cusses the first two server types.
National Institute media communication services. IMS Several technologies to build te-
of Scientific Research, Canada defines a generic architecture for of- lephony and voice-over-IP (VoIP) ap-
fering communication services such as plication servers have been proposed.
multimedia telephony, push to talk, and Some of these technologies are rel-
instant messaging over a Session Initi- evant to IMS application servers and
ation Protocol (SIP)2 infrastructure. can meet their unique requirements.
Among the most important compo- We assume that the reader is familiar
nents of the IMS architecture are the with the SIP protocol and the roles of
application servers, which host and its architectural elements, especially
execute the logic of the IMS services the SIP proxy.
(for example, how services are invoked,
what signaling and media actions are Overview
involved, and how services interact IMS is a set of specifications that defines
with each other). IMS defines three a complete framework for enabling the
types of application servers: SIP ap- convergence of voice, video, and data
plication servers, open services archi- communications over an IP-based
tecture (OSA) application servers, and infrastructure using SIP. The 3GPP

40 Published by the IEEE Computer Society 1089-7801/08/$25.00 2008 IEEE IEEE INTERNET COMPUTING
IMS Application Servers

originally designed IMS for mobile networks. Transport layer. The transport layer is the
Other standards bodies, including the European network-access layer. It lets different IMS de-
Telecommunications Standards Institute,3 have vices and user equipment connect to the IMS
adopted it for fixed networks. It has also be- network. IMS devices connect to the IP net-
come part of the International Telecommunica- work in the transport layer using various tech-
tion Union (ITU) Next-Generation Networking nologies, including fixed access (DSL, cable
(NGN) vision. modems, Ethernet, and so on), mobile access
(wideband code-division multiple access [W-
IMS Benefits CDMA], CDMA-2000, Global Packet Radio Ser-
The IMS architecture has generated a lot of in- vice [GPRS], and so on) and wireless access
terest from both wireline and wireless service (such as wireless local area network [WLAN]
providers. This interest stems from its service or WiMax). The transport layer also lets IMS
delivery framework as well as from the services devices place and receive calls to and from the
themselves. public switched telephone network (PSTN) or
other circuit-switched networks through the
Integrated delivery of multimedia services. media gateway as Figure 1 shows.
IMS, through the use of SIP, brings the Inter- The transport layer establishes the user
nets power to the communication world. It pro- equipments IP connectivity. Once the user
vides a flexible way to build high added-value equipment has an IP address and can exchange
services on top of the common signaling infra- SIP messages (either directly or through a gate-
structure. Service providers can integrate voice, way), it will be responsible for its own IMS
video, and data services and provide them on a interactions, independent of the underlying net-
single platform. work-access technology. For example, K. Daniel
Wong and Vijay K. Varma show how IMS can be
Modular architecture. Because IMS is highly used in Universal Mobile Telecommunications
modular, service providers can integrate dif- System (UMTS) networks.5
ferent components or modules from different
solution providers into the same system. This Control layer. All control-layer functions are
establishes vendor independence and optimiz- specified as part of the IMS architecture. At
es investment. the layers core is the CSCF. Three SIP signaling
servers handle this function: the proxy CSCF
Mobility and roaming. IMS provides access (P-CSCF), the interrogating CSCF (I-CSCF), and
to a users specific set of services, indepen- the S-CSCF mentioned previously.
dently of their location and network-access The P-CSCF is a SIP proxy that is the first
serving operator. point of contact for the IMS terminal. IMS ter-
minals discover their corresponding P-CSCF as
Extra features. Finally, IMS incorporates in- part of their network connectivity procedure
tegrated QoS, security, flexible charging, and (that is, through the Dynamic Host Configura-
lawful intercept mechanisms, making it a tion Protocol [DHCP]). The P-CSCF sits on the
complete service platform for next-generation path of all signaling messages of the IMS ter-
networks. minal and passes SIP registration to the correct
home network (that is, the subscribers admin-
IMS Architecture istrative IMS domain) and SIP session messages
Figure 1 shows the NGN functional architec- to the correct S-CSCF after registration. The P-
ture. It has three main layers: transport, con- CSCF can also perform message compression or
trol, and service. IMS is at the architectures decompression and security enforcement.
core. It consists of several functions (such as The I-CSCF is a SIP proxy located at the ad-
serving call session-control function [S-CSCF], ministrative IMS domains edge. Its IP address is
home subscriber server (HSS), and multimedia published in the domains DNS server, so remote
resource function control [MRFC]), intercon- servers (such as a P-CSCF in a visited domain or
nected through standardized interfaces. We give an S-CSCF in a foreign domain) can find it and
an overview of each layer in the following sec- use it as an entry point for all SIP transactions
tions. An in-depth tutorial appears elsewhere.4 to this domain.

MAY/JUNE 2008 41
Multimedia System Architectures

Service layer
SIP
Diameter
Megaco
Camel service environment SIP OSA
CAP application server application server
OSA API
IM-SSF
OSA SCS

Control layer

IMS
HSS
MRFP
S-CSCF
MFRC
SLF

BGCF MGCF
I-CSCF P-CSCF

Transport layer MGW


IP network
Public switched
Radio access network IP connectivity access network telephone network

SIP

PDA Cell IP phone Laptop Telephone


BGCF: Breakout gateway control function MGW: Media gateway
Camel: Customized applications for mobile networks using enhanced logic MRFP: Media resource function processor
CSCF: Call session control function OSA: Open services architecture
HSS: Home subscriber server P-CSCF: Proxy CSCF
I-CSCF: Interrogating CSCF SCS: Service capability server
IMS: IP multimedia subsystem S-CSCF: Serving CSCF
IM-SSF: IP multimedia service switching function SIP: Session Initiation Protocol
MFRC: Multimedia resource function control SLF: Subscriber location function
MGCF: Media gateway control function

Figure 1. Overall Next-Generation Networking (NGN) functional architecture. The NGN architecture has three
layers transport, control, and service with the IP multimedia subsystem (IMS) at the architectures core.

The S-CSCF is the signaling planes central implement the Diameter 6 protocol an authen-
node. It registers users and provides services to tication, authorization, and accounting (AAA)
them. It routes SIP requests, provides billing in- protocol that the other elements of the IMS net-
formation to mediation systems, maintains ses- work can use to upload and download to and
sion timers, and interrogates the HSS to retrieve from the HSS/SLF.
authorization, service-triggering information, The media resource function provides media
and user profiles. functions in the IMS architecture (such as play-
The HSS is the master user database. It sup- ing announcements or recording voicemails).
ports the IMS network entities that handle the The IMS standard decomposes the function into
calls or sessions. It contains subscription-related two elements.
information (that is, user profiles), authenticates The media resource function controller in-
and authorizes users, and can provide infor- terprets information from the S-CSCF (for ex-
mation about users locations. An IMS domain ample, a session for media processing such as
needs a subscriber location function (SLF) when playing announcements and mixing streams).
it uses multiple HSSs. Both the HSS and SLF The S-CSCF uses SIP to communicate with the

42 www.computer.org/internet/ IEEE INTERNET COMPUTING


IMS Application Servers

MRFC, which uses Megaco/H.248,7 a master initial SIP request to a given application server.
slave media-control protocol, to control the me- The decision it makes is based on filter informa-
dia resource function processor (MRFP). tion received from the HSS. The HSS stores and
The breakout gateway control function (BGCF) conveys this filter information on a per-applica-
determines the next hop for routing SIP mes- tion-server basis for each user.
sages that cant be routed by the S-CSCF. It se- When the HSS transfers the name and ad-
lects a media gateway control function (MGCF) dress of more than one application server, the
that will route the call to the PSTN through a S-CSCF must contact each application server in
media gateway. the order provided. The S-CSCF uses the first
application servers response as input to the
Service layer. The transport and control layers second application server.
provide an integrated and standardized network The application server uses filter rules to
platform to let service providers offer various decide which of the many services deployed on
multimedia services in the service layer. Ap- the server should handle the session. During the
plication servers host and execute the services service logics execution, the application server
and provide the interface with the control layer can communicate with the HSS to get additional
using the SIP protocol. As we stated previously, information about a subscriber or to learn about
IMS defines three types of application serv- changes in the subscribers profile.
ers: the SIP application server, OSA application The application server (SIP application
server, and the Camel service environment. server or the OSA SCS) uses the Diameter pro-
The Camel service environment is a set of tocol to communicate with the HSS. Diam-
mechanisms that let mobile network operators eter transports user-profile-related data, but
provide subscribers with operator-specific ser- can also transport transparent data that is,
vices, even when theyre roaming outside their data for which the exact representation of in-
home network service environments. In the IMS formation isnt understood by the HSS or the
architecture, the IP multimedia service switch- protocol (for example, service-related data or
ing function interface translates requests be- user-related information).
tween SIP and the Camel application part. The
implementation of the Camel service environ- An Example IMS Application
ment is outside this articles scope. To illustrate the interactions between key ele-
ments of the IMS architecture and the IMS ap-
IMS Application Servers plication servers, we implemented a small IMS
An IMS application provides a specific service audioconference application.
to the end user. IMS end-user services include To join a conference, a participant calls the
multiparty gaming, videoconferencing, mes- service identified by its uniform resource identi-
saging, community services, presence, and con- fier (URI) for example, sip:ConfServiveURI@
tent sharing. emt.inrs.ca. When the service receives the
Depending on its implementation, an IMS call, it plays a greeting and asks the caller to
application server can host one or many IMS enter the conference code. If the code is valid, it
applications. In both cases, the application asks the caller to enter his or her PIN. If the PIN
server handles and interprets the SIP mes- is also valid, the service lets the caller join the
sages forwarded by the S-CSCF (either directly conference; otherwise, it asks the caller to retry.
or through the OSA service capability server
[SCS]) and translates end-user service logic into SIP Application Servers
sequences of SIP messages, which it sends to the SIP application servers can act as redirect serv-
parties involved, again through the S-CSCF. ers, proxy servers, originating user agents,
The IMS architecture lets an IMS service terminating user agents, or back-to-back user
provider deploy multiple application servers in agents. They have SIP signaling capabilities
the same domain. Different application servers and are directly involved in the calls signal-
can be deployed for different application types ing flow. They receive SIP messages from the S-
(for example, telephony or presence application CSCF and parse them. Similarly, they generate
servers) or different groups of users. The S-CSCF SIP messages and send them to the S-CSCF.
decides whether it should forward an incoming The application server translates an IMS

MAY/JUNE 2008 43
Multimedia System Architectures

SIP
Caller S-CSCF application S-CSCF MRF
server For simplicity, the figure doesnt show some
INVITE provisional SIP messages, such as 100 Trying
INVITE
INVITE and 180 Ringing.
MSCML When the SIP application server receives the
INVITE
MSCML first invite from the caller, it creates a new SIP
session with the MRF. The body of the invite
200 OK
200 OK asks the MRF to play a greeting to the caller and
200 OK
200 OK ask the caller to enter the conference code. The
RTP Interactive MRF forwards the conference code received from
Voice Response the user to the application server in an info SIP
INFO (Code) request. If the code is valid, the SIP application
200 OK server sends an info request back to the MRF,
INFO (Ask For PIN) asking it to ask the caller to enter his or her PIN.
200 OK The SIP application server and the MRF thus
INFO (PIN) continue to exchange SIP messages until the au-
200 OK thentication process ends, and the callers user
INFO (Add to conference) agent starts receiving the media stream from
200 OK other participants input. As Figure 2 shows, all
RTP (Mixed) SIP messages transit through the S-CSCF.

MSCML: Media Server Control Markup Language


OSA Application Servers
RTP: Real-Time Transport Protocol OSA application servers can provide the same
SIP: Session Initiation Protocol services as the SIP application server but have
S-CSCF: Serving call session control function no signaling capabilities and arent directly in-
volved in the SIP calls signaling flow. They com-
Figure 2. The audioconference services call flow, managed by a municate with the S-CSCF through the OSA SCS,
SIP application server. This server invokes the multimedia resource which maps SIP messages into invocations of the
function controls capabilities using SIP. OSA API (also called Parlay) and back. From an
S-CSCF perspective, the SIP application server
and the OSA SCS exhibit the same behavior.
services execution in the SIP application serv- The OSA application server also has access
er into a sequence of SIP procedures, such as to the HSS data, but only through the SCS. The
sending invite requests and reacting to SIP SCS implements the Diameter protocol, so it can
responses. For services requiring media inter- read and update data records based on the OSA
action, the SIP application server invokes the application servers requests.
multimedia resource function control (MRFC) The OSA application server mainly imple-
capabilities. The IMS specifications dont ex- ments external services that could be located in
plain exactly how to perform this invocation, a visited network or a third-party platform. Fig-
but several proposals exist for letting the SIP ure 3 shows the call flow of the audioconference
application server use SIP to control the MRFC service managed by an OSA application server.
(for example, basic network media services with The interactions between the OSA SCS and the
SIP,8 Media Server Control Markup Language MRF are similar to those of the SIP application
[MSCML],9 Media Objects Markup Language, server and MRF. However, the OSA application
and Media Sessions Markup Language). server tells the OSA SCS which action to perform
Figure 2 shows the audioconference ser- (for example, using sendInfoReq()method calls),
vices call flow when managed by a SIP applica- and the OSA SCS notifies the OSA application
tion server. We assume that the MRFC and the server of the events reported by the MRF (for ex-
MRFP are colocated in the same entity (MRF in ample, using sendInfoRes()method calls).
the figure). We also assume that media control
messages are transported in the body of the SIP IMS Application Server
invite and info requests. (An info request is Implementation Technologies
a SIP request used to carry session-related con- The IMS specifications dont define the appli-
trol information generated during a session.) cation servers internal architecture. To un-

44 www.computer.org/internet/ IEEE INTERNET COMPUTING


IMS Application Servers

OSA
Caller S-CSCF OSA SCS S-CSCF MRF
application server
INVITE
INVITE
reportNotification()
createCallLeg()
routeReq()
INVITE
INVITE
200 OK
200 OK
200 OK
200 OK
RTP
routeRes()
createUICall()
sendINFOReq()
INFO(welcome, code?)
200 OK
INFO(code)
200 OK
sendINFORes()
sendINFOReq()
INFO(PIN?)
200 OK
INFO(PIN)
200 OK
sendINFORes()
attachMediaReq()
INFO(Add)
200 OK
RTP

OSA: Open services architecture


RTP: Real-Time Transport Protocol
S-CSCF: Serving call session control function

Figure 3. The audioconference services call flow, managed by an OSA application server. The OSA
service capability server (SCS) maps SIP messages into invocations of the OSA API (also called Parlay)
and back .

derstand how to build application servers and families: SIP programming techniques, APIs,
deploy IMS applications and end-user services, and service execution environments.
we must examine the technologies that we could
use to build them. SIP Programming Techniques
Existing technologies for building IMS ap- SIP programming techniques let application pro-
plications arent all equivalent. Some can be grammers access basic SIP functionalities to pro-
used to implement a complete application serv- gram the SIP applications. The two techniques
er, others can be used to implement just a layer in this category are the SIP common gateway
of the application server. Some of them are SIP- interface (SIP CGI)10 and the SIP servlet.11 These
dependent, so they can be used only to build techniques are SIP-dependent, so they can only
SIP application servers. Others are protocol in- be used for SIP application servers.
dependent, so they can be used to build both
SIP and OSA application servers. We classify SIP-CGI. SIP CGI was inspired by HTTP CGI, a
these application server technologies into three tool for creating dynamic content for the Web.

MAY/JUNE 2008 45
Multimedia System Architectures

CGI program
SIP servlet. The SIP servlet API is a Java ex-
CGI tension API for SIP servers, inspired by the
Session Initiation
Protocol (SIP) request SIP request HTTP servlet concept. A SIP servlet is a Java-
based application component thats managed
Server function
SIP response SIP response by a container and performs SIP signaling.
These containers, sometimes called servlet en-
gines, are server extensions that provide serv-
Figure 4. CGI-based SIP application server. When a server receives let functionality. Servlets interact with SIP
a SIP request, it invokes a SIP CGI script. The script performs the clients by exchanging request and response
required processing and generates signaling instructions for the messages through the servlet container. The
server to execute. container passes objects representing SIP mes-
sages to the servlet. The servlet has access to
all the SIP messages headers through those
objects and, with this information, decides
init()
how to respond to a message. Servlets can an-
doRequest()
Servlet service() swer or proxy requests, create or forward re-
SIP
doResponse() sponses, and initiate new SIP transactions. The
message destry() container provides many services that the SIP
Session Rules doInvite()
Initiation servlet can exploit, such as automatic retries,
Protocol .. message dispatching and queuing, forking and
(SIP) merging, and state management.
client doInfo()
SIP
Servlet The servlet itself only manages high-level
doProvisionalResponse() message handling and service logic. Figure 5
message
. shows the relationship between the servlets and
Servlet the container as well as the different methods
doErrorResponse() of the servlet interface.
An IMS servlet-based SIP application server
Figure 5. Servlet-based SIP application server. The container passes is a SIP servlet container. IMS applications are
objects representing SIP messages to the servlet. The servlet has SIP servlets (or a group of SIP servlets). When
access to all the SIP messages headers through those objects and, the server receives a new request, it applies
with this information, decides how to respond to a message. some preconfigured rules to select the serv-
let (the application) to process the request. The
servlet executes the service logic and invokes
When a server receives a SIP request, it invokes the container capabilities to send and receive
a SIP CGI script. The server passes the message SIP messages.
body to the script through its standard input
and sets environmental variables containing APIs
information about the message headers, user in- Several APIs for building communication ap-
formation, and server configuration. The script plication servers can be used as part of an IMS
performs some processing and generates signal- application server. These APIs wrap up network
ing instructions for the server to execute. The and protocol functionalities into an easy-to-use
SIP CGI script can instruct the server to gener- abstract software component.
ate a SIP response, proxy a request, create a new The APIs provide high-level object-orient-
request, or change a requests headers. Figure 4 ed interfaces that let programmers implement
shows the functional model of a CGI-based SIP communication applications. Figure 6 shows
application server. an API-based IMS application server. When
In a CGI-based IMS SIP application server, the API and application reside on different ma-
IMS end-user services are written as CGI scripts. chines, a remote-procedure call mechanism can
The server calls a CGI script for each incoming allow interaction between them.
call. The script runs the service logic and re- Parlay (www.parlay.org) is a set of API spec-
turns to the server a list of actions to perform ifications for managing network services such
on the SIP request. Using IMS terminology, we as call control, messaging, and content-based
can consider the CGI scripts IMS applications. charging. The Parlay group first proposed it for

46 www.computer.org/internet/ IEEE INTERNET COMPUTING


IMS Application Servers

Application
telephone networks, and the 3GPP later adopted Interface
it as the OSA API to give the OSA application
server access to the IMS network functional-
Interface
ities. The Parlay API supports all call-control API
functionalities that previous telephony APIs
provided and offers some new features such as
mobility, presence, and data session control. Session Initiation Protocol
Moreover, Parlay is the only API that includes
VoIP and SIP systems in its specifications.
Two versions of the OSA API exist: Figure 6. API-based IMS application server. The
API wraps network and protocol functionalities
the standard version, a simple API specifi- into an easy-to-use abstract software component.
cation that can be programmed using any
object-oriented programming language; and
the Web service-based version, or Parlay X. tionalities. The API implementation notifies the
application of events occurring in the network
Although the IMS documentation implies and instructs the network components to ex-
that the OSA API is for building OSA applica- ecute the applications commands.
tion servers only, nothing prevents a SIP appli- Even though these three APIs can theoreti-
cation server from being Parlay-based. In this cally be used to build IMS SIP application serv-
case, the Parlay API will likely reside on the ers, theyve stirred little interest because the
same machine as the application server and will new features and capabilities that SIP provides
be invoked locally. have superseded them. Of course, you cant use
In addition to Parlay, developers can use any of them to build an OSA application server
three well-known APIs for information technol- because such servers require the OSA API.
ogy and PSTN integration to build an IMS ap-
plication server: Service Logic Execution Environments
A service logic execution environment (SLEE)
Telephony API (TAPI), introduced in 1993 by is a high-throughput, low-latency event-
Microsoft and Intel and limited to Windows- processing application environment designed
based systems; for communication applications that can be
Telephone services API (TSAPI), developed used to build IMS application servers.
by Novell and Lucent Technologies; and Jain SLEE (http://jainslee.org) is the Java
Java telephony API (JTAPI), a specifica- specification of the SLEE concept. To our
tion for Java-based computer-telephony knowledge, its the only industry standard
applications. specification of a SLEE. It specifies the runtime
execution environment, called a container, and
TAPI, TSAPI, and JTAPI all define methods communication services internal architecture.
that let telephony applications set up and tear A Jain SLEE service is a collection of reusable
down calls, monitor progress, perform iden- object-oriented components service building
tification, and activate features such as hold, blocks (SBBs) running inside the container.
transfer, conference, call park, and call pickup. Figure 7 shows the architecture of a Jain SLEE-
They can redirect and forward calls, answer based application server.
and route incoming calls, and generate and de- An SBB is a software component that sends
tect DTMF signals. and receives events and performs computation-
All three APIs hide network details and pro- al logic. An external resource, such as the com-
tocols from application programmers and pro- munications protocol stack, the SLEE container,
vide them with an easy programming interface or another SBB event can generate events.
with which to build sophisticated telephony A Jain SLEE application server interacts with
services. These APIs specify a set of packages, external resources, such as network protocols
classes, and methods, which network elements and TAPIs, through resource adapters, which
should expose and applications should invoke adapt resources to SLEE requirements.
to let the applications access network func- An IMS SLEE-based application server is a

MAY/JUNE 2008 47
Multimedia System Architectures

Service
building
block nents from different vendors while main-
Service taining interoperability.
Service building
building
Jain SLEE Universal service access. Users must be able to
block container
block access services independently of the physical
Service location and types of terminals being used.
building
block
These requirements are rooted in the Telecom-
Resource adapter
munications Information Networking Architec-
To the network
ture Consortiums work, the most in-depth work
on communication service architectures to date
(see www.tinac.com). Because of the require-
Figure 7. Jain service logic execution environment ments generic character, researchers have used
application server. A Jain SLEE service is a them beyond their original scope in intelligent
collection of reusable object-oriented components networks for example, to discuss Internet
service building blocks (SBBs) running inside telephony service architectures12 so we feel
the container. strongly that they can also apply to IMS.
To relate the IMS application server require-
ments to the technologies presented, we studied
Jain SLEE container, and IMS applications are which of the requirements are intrinsically met
SBBs. Jain SLEE isnt related to any signaling by the SIP application server and OSA applica-
protocol. It can be used for both IMS SIP appli- tion server, which can be met using the present-
cation servers and OSA application servers. For a ed technologies, and which require the use of
SIP application server, it needs a resource adapt- other technologies.
er for SIP, and for an OSA application server, it
needs a resource adapter for the OSA API. Support for a Wide Range of Services
Both the SIP and OSA application servers can
IMS Application Server Requirements provide any SIP-based communication service.
IMS application servers should fulfill several The OSA API, however, lacks some capabilities
requirements: that are available in SIP, such as call forking.
The absence of these capabilities might prevent
Support for a wide range of end-user services. the OSA application server from supporting
By supporting a wide range of services, ap- some services. 3GPP and Parlay working groups
plication servers can provide a single sol are addressing these issues.
ution platform.
Rapid service creation and deployment. Rap- Rapid Service Creation and Deployment
id service creation is crucial to success in Using SIP CGI or SIP servlets to program the
the marketplace. Service providers should be SIP application server services requires knowl-
able to rapidly specify, design, test, and in- edge of the SIP, which makes it relatively dif-
stall new services. ficult. Still, using the SIP servlet approach has
Easy service customization and tailoring. some advantages over using the CGI approach:
Service providers must be able to change the
service logic rapidly and efficiently. Custom- Containers ease application development by
ers also demand control of their own servic- handling some of the SIP complexity (au-
es to meet their individual needs. tomatic retrial, provisional responses, and
Independent evolution of services and net- so on).
work infrastructure. Services should be de- The API approach provides more convenient
fined independently of a specific network access to various structures (such as SIP
technology (SIP). Conversely, the service URLs and contact addresses) by representing
architectures flexibility should facilitate the them as abstractions rather than untyped
exploitation of new technologies. strings.
Support for multiplayer (or open) environ- The servlets have ready access to a wide va-
ments. The application server should support riety of Java APIs, such as directories, data-
services, software, and hardware compo- bases, and security algorithms.

48 www.computer.org/internet/ IEEE INTERNET COMPUTING


IMS Application Servers

Servlet deployment is more convenient because Like CCXML, CPL can be used in both SIP and
it uses well-defined XML files, whereas the OSA application servers and is designed for
deployment of CGI scripts isnt standardized. telephony services.
Finally, using CPL and CCXML requires
Programming OSA application server ser- interactions between the application server
vices requires only general programming skills; technology and the CCXML or CPL scripts
no protocol knowledge is needed. This facilitates and, as far as we know, is usually done in an
service creation in the OSA environment. Also, ad hoc manner.
in the SIP application server, adopting a layered
programming approach that hides SIP details Independent Evolution of Services
from service programmers could ease service and Network Infrastructure
creation. You could do this using, for example, The SIP application server has signaling capa-
TAPI or Parlay. Parlay would be the best choice bilities and is directly involved in the calls sig-
because it supports SIP functionalities. Using naling flow. So, it doesnt meet the requirement
Parlay will result in a SIP application server of independent evolution of services and net-
that is similar to the OSA application server. work infrastructure. This limit restricts the ser-
With Jain SLEE, which can be used for both vices provided to the SIP technology. Changes
SIP and OSA application servers (but requires re- in SIP might imply modifications to the services
source adopters), service creation and deployment on the SIP application server, and the migration
is easy because services are created as standalone to another network protocol (such as H.323 or
SBBs and deployed in a standard manner. any future protocol) will imply the reimplemen-
tation of these services. The OSA application
Easy Service Customization and Tailoring server doesnt have this restriction.
Easy service customization is an important re- A layered programming approach can sat-
quirement for service providers. Scripting is a isfy the rapid service creation and deployment
good approach to ensure a high customization requirement.
level of IMS services. Generally, solution pro-
viders offer proprietary scripting languages. Support for a Multiplayer Environment
However, the Voice Browser Call Control lan- The IMS architecture is modular and lets ser-
guage,13 an XML-based language, offers an vice providers integrate different elements from
alternative. CCXML was proposed to script the different vendors. We can push this modularity
logic of telephony applications and has poten- further if the application server software archi-
tial in both SIP and OSA application servers. It tecture is also standardized. Using Jain SLEE,
provides a standard way for controlling rout- for instance, would let services providers run
ing, bridging, outbound calling, and confer- different services from different vendors in the
encing actions, as well as for executing Voice same Jain SLEE containers.
Extensible Markup Language (VoiceXML)14 di- The TAPIs and Parlay also provide a certain
alogs. Unfortunately, CCXML is only designed multilayered environment support for the SIP
for telephony, so you cant use it to customize application server. They split the application
other IMS services, such as presence and in- server into two software layers that different
stant messaging. vendors can provide. Similarly, using the SIP
The application server should also provide servlet approach to build a SIP application server
a mechanism for customers to set and mod- allows for the deployment of services from dif-
ify their preferences. Most approaches use ferent vendors into the same servlet container.
Web interfaces and interactive voice response
menus to do so. However, you could also use Universal Service Access
scripting languages such as the Call Process- Both SIP and OSA application servers meet this
ing Language15 for this purpose. CPL is an requirement. SIP-based terminals can access,
XML-based scripting language that lets users independently of their physical location, the
control their Internet telephony services. End services both server types provide.
users can use CPL to describe their preferenc-
es, such as call forwarding based on time of Analysis
day or call rejection based on caller identity. As Table 1 shows, from a purely technical per

MAY/JUNE 2008 49
Multimedia System Architectures

Table 1. Comparison of application server implementation technologies.


Service logic execution
SIP programming techniques Programming interfaces
Feature environments
CGI Servlet Telephony Parlay Jain SLEE
Support for a wide range
Yes Yes Limited Yes Yes
of services
Rapid service creation Yes
No Medium Yes Yes
and deployment (but high learning curve)
Easy service customization
Possible Possible Possible Possible Possible
and tailoring
Independent evolution of services
No No Yes Yes Yes
and network infrastructure
Support for a multiplayer
No Limited Medium Medium High
environment

Universal service access Yes Yes Yes Yes Yes

spective, the Jain SLEE architecture most terminology) using SIP and MSCML. We de-
closely meets the TINA-C requirements. How- ployed the servlet that manages the confer-
ever, the programming community perceives ence service ConfServlet in the same
it as complex, which will certainly negatively container as the other services servlets,
affect its adoption. Moreover, large-scale adop- such as the BasicCallServlet, IVRServlet, and
tion of Jain SLEE would require standardizing VoiceMailServlet.
a Parlay resource adapter for OSA application In our application, calling a specific URI
servers and a SIP resource adapter for SIP triggers the ConfServlet. For calls coming
application servers. This leads us to a second from the PSTN, the gateways must map the
point that the SIP application server should external phone number called to the specific
also be built over Parlay. A Parlay-based SIP conference URI.
application server both closely meets the TINA- SIP servlets are powerful and easy to im-
C requirements and lets service providers de- plement for programmers with HTTP servlet
ploy the same applications on both SIP and experience and SIP knowledge. However, they
OSA application servers when necessary. introduce the risk of mixing front-end func-
Some of the application server technologies tions with business logic. The SIP servlet en-
that weve presented, such as Parlay and Jain vironment lacks a rigid component model that
SLEE, are complementary and can be used to- separates call control from the business logic
gether. For example, Figure 8 shows how you classes and persistence layer (similar to the
can build a SIP application server using Jain MVC frameworks used in Web development).
SLEE and Parlay. In addition, the choice of an Finally, unit testing SIP servlet code (as well
IMS application server implementation tech- as any SIP application server code) isnt easy
nology doesnt depend on the service to be because it requires simulating the communica-
built over it. You can use all the technologies tion protocol. Alleviating this inconvenience
weve presented (except TAPIs) to build any will require frameworks similar to those used
IMS service. for HTTP.

Implementation Experience
As noted, we implemented an audioconference
service. Although we didnt originally design
our media server and SIP application server for
W e can deduce two important points from
this review. The first is the absence of an
abstract standard internal architecture for IMS
IMS (we describe an early version of the media application servers. The different technologies
server elsewhere16), their migration to IMS is have different visions. Second, from a purely
well under way. technical perspective, we believe that the Jain
We implemented our SIP application server SLEE architecture can become the standard IMS
using Java servlet technology and the inter- application server architecture.
action with the media server (MRF in IMS These points notwithstanding, we note that

50 www.computer.org/internet/ IEEE INTERNET COMPUTING


IMS Application Servers

Service
building
the SIP servlet approach is currently the most block
popular application server technology. Both the Service
Web and open source communities are encour- Service building Jain SLEE
building block
aging its adoption, so it will likely be the major block
container
platform for at least the first generation of IMS Service
building
SIP application server services.
block
However, the technologies we presented arent
SIP application server
an end point in the evolution of SIP service en- Parlay resource adaptor
vironments. In future work, we plan to inves- Parlay interface
tigate the use of OSGi (www.osgi.org) to build
IMS application servers. OSGi is a successful Parlay
(local or remote)
architecture with a high level of modularity
and easy service deployment that can be suc- Parlay interface
cessfully applied to communication systems. Signaling engine

References Session Initiation Protocol (SIP)


1. Third Generation Partnership Project, Technical
Specification Group Services and System Aspects; IP
Multimedia Subsystem (IMS), Stage 2 (Release 7.5.0), Figure 8. Jain SLEE/Parlay integration. Parlay and Jain SLEE
Sept. 2006. are complementary and can be used together to build a SIP
2. M. Handley et al., SIP: Session Initiation Protocol, IETF application server.
RFC 3261, June 2002; www.ietf.org/rfc/rfc3261.txt.
3. ETSI, Telecoms and Internet Converged Services and
Protocols for Advanced Networks (TISPAN): NGN ML Version 1.0, World Wide Web Consortium (W3C)
Functional Architecture Release 1, Aug. 2005; http:// recommendation, June 2005; www.w3.org/TR/ccxml.
portal.etsi.org. 14. S. McGlashan et al., Voice Extensible Markup Lan-
4. G. Camarillo and M.A. Garcia-Martin, The 3G IP Mul- guage (VoiceXML) Version 2.0, World Wide Web Con-
timedia Subsystem (IMS): Merging the Internet and the sortium (W3C) recommendation, Feb. 2003; www.
Cellular Worlds, John Wiley & Sons, 2nd ed., 2006. w3.org/TR/voicexml20.
5. K.D. Wong and V.K. Varma, Supporting Real-Time 15. J. Lennox, X. Wu, and H. Schulzrinne, Call Process-
IP Multimedia Services in UMTS, IEEE Comm., Nov. ing Language (CPL): A Language for User Control of In-
2003, pp. 148155. ternet Telephony Services, IETF RFC 3880, Oct. 2004;
6. P. Calhoun et al., Diameter Base Protocol, IETF RFC www.rfc-editor.org/rfc/rfc3880.txt.
3588, Sept. 2003; www.rfc-editor.org/rfc/rfc3588.txt. 16. H. Khlifi and J.C. Grgoire, Design and Performance
7. F. Cuervo et al., Megaco Protocol Version 1.0, IETF RFC of a Stand-Alone Media Server, Proc. 2005 Systems
3015, Nov. 2000; www.rfc-editor.org/rfc/rfc3015.txt. Comm., IEEE CS Press, 2005, pp. 147152.
8. E. Burger, J. Van Dyke, and A. Spitzer, Basic Network
Media Services with SIP, IETF RFC 4240, Dec. 2005; Hechmi Khlifi is a consultant with Ericsson Canada. His
www.rfc-editor.org/rfc/rfc4240.txt. research interests include Internet real-time applica-
9. E. Burger, J. Van Dyke, and A. Spitzer, Media Server tions, voice over IP, and telecommunications service
Control Markup Language (MSCML) and Protocol, IETF engineering. Khlifi has a PhD in telecommunications
RFC 4722, Nov. 2006; www.rfc-editor.org/rfc/rfc4722. from the National Institute of Scientific Research, Uni-
txt. versity of Quebec. Contact him at khlifi@emt.inrs.ca.
10. J. Lennox, H. Schulzrinne, and J. Rosenberg, Common
Gateway Interface for SIP, IETF RFC 3050, Jan. 2001; Jean-Charles Grgoire is a professor at the Energy, Mate-
www.rfc-editor.org/rfc/rfc3050.txt. rials, and Telecommunications Center of the National
11. JSR Expert Group, SIP Servlet API Specification Institute of Scientific Research, Canada. His research
Version 1.0, Feb. 2003; http://jcp.org/aboutJava/ interests include all aspects of telecommunication
communityprocess/final/jsr116/. systems engineering, including protocols, distributed
12. R.H. Glitho, Advanced Services Architectures for In- systems, network design, and performance analysis.
ternet Telephony: A Critical Overview, IEEE Network, Grgoire has a PhD in technical sciences from the Fed-
July 2000, pp. 3844. eral Polytechnic School, Lausanne, Switzerland. Con-
13. R.J. Auburn et al., Voice Browser Call Control: CCX- tact him at jean-charles.gregoire@emt.inrs.ca.

MAY/JUNE 2008 51