Ind twss-pdf

Integrating IBM WebSphere Telecom Web
Services Server with media server
A system and method for handling calls in an NGN network

Skill Level: Intermediate

Dhandapani Shanmugam (dshanmug@in.ibm.com)
Senior Staff Software Engineer
IBM

Raghu Juluri (raghu.juluri@oracle.com)
Senior Member Technical Staff
Oracle

13 Jan 2011

This article introduces IBM WebSphere® Telecom Web Services Server, discusses
integrating its call handling features with media server, and demonstrates how IBM
products serve the end-to-end requirements for next generation network’s (NGN)
telecommunications infrastructure in handling calls on the IP based-network.

Why do we need integration between WebSphere Telecom
Web Services Server and media server?
In today's world, we often perform multiple tasks such as attending telephone calls,
attending conferences, sending multimedia messages, and maintaining more than
one telephone number per person. Because of this multi-tasking, we cannot always
address incoming telephone calls immediately, which can cause disappointment for
the rejected callers and frustration for the intended recipients.

This article addresses these types of scenarios in an IP-based telecommunications
network and exhibits on how integrating the capabilities of WebSphere Telecom
Web Services Server with media server can help.

Integrating IBM WebSphere Telecom Web Services Server with media server Trademarks
© Copyright IBM Corporation 2011. All rights reserved. Page 1 of 12

developerWorks® ibm.com/developerWorks

What is WebSphere Telecom Web Services Server?
IBM WebSphere Telecom Web Services Server allows telecommunications service
providers (TSPs) to expose high-level web service interfaces to network services for
third parties.

Third parties are typically telecommunications service providers or organizational
divisions wanting to develop new services that integrate with their network
infrastructures.

Web service interfaces provide access to service capabilities in a
technology-independent way, using programming languages. Each web service
interface has multiple backend implementations for connecting with a service
provider's environment. For example, a web service interface may connect to the
network through the Session Initiation Protocol (SIP), the Parlay gateway using the
Parlay Connector, the native protocols, or by using the custom integrated services.

As depicted in Figure 1, WebSphere Telecom Web Services Server consists of the
following: access gateway, service policy manager (SPM), service platform
components, and service implementation.

Figure 1. Overview of WebSphere Telecom Web Services Server


ibm.com/developerWorks developerWorks®

The access gateway provides policy-driven traffic monitoring, message capture,
authorization, and management capabilities. These services are provided at the
application layer and are enforced for each web service request using knowledge of
the requester, target service, and invoked operation. This component consists of
many mediation primitives where each mediation primitive provides a dedicated
functionality (shown as MP1 through MPn in Figure 1). For more details, refer to the
WebSphere Software for Telecom Information Center (see Resources).

The service policy manager provides management, storage, and retrieval functions
for the policy configuration data and the runtime data used to customize service
delivery for a given requester. An enterprise-level administrator can use the SPM to
manage definitions of third-party requesters, service definitions, and service
relationships. Using policy management capabilities, administrators can personalize
the services that are provided to groups and to individual requesters in a way that is
scalable.

The service platform components provide common service implementation functions
such as admission control, traffic shaping and usage record. These common,
reusable functions are used by the service implementations and can be utilized to
support custom built services. For more details, refer to the WebSphere Software for
Telecom Information Center (see Resources).

WebSphere Telecom Web Services Server supports a large number of web service
implementations (SI1 through SIn in Figure 1), many of which are based on Parlay X
2.1. Terminal location, terminal status, short messaging, and call handling are
examples of the services. For more details, refer to the WebSphere Software for
Telecom Information Center (see Resources for the link).

What is the call handling service implementation?
The call handling service implementation (call handling SI) is a Parlay X web service
allowing third party web services-based applications to establish routing and call
handling rules which the service executes when receiving a SIP network-initiated
call. The call handling SI provides a mechanism for an application programmer to
specify how calls are to be handled for a specific mobile number or a group of
mobile numbers without requiring a lot of telecommunications knowledge.

These are the operations supported by the call handling SI:

• Set rules: This operation sets the call handling rules for the mobile
number. If a set of rules is already in place for the address or mobile
number, then this operation will replace the old rules with the set provided
in the operation. Please refer to Scenario 1 depicted in Figure 2 for the
details of this operation.



• Set rules for group: This operation is a super set of the set rules operation
where call handling rules can be set for a group of numbers. If rules are
already in place for any of the addresses, then this operation will replace
the old rules with the set provided in the operation.
• Get rules: Use this operation to retrieve the rule set for a single mobile
number. The operation does not support a group of mobile numbers.
Please refer to the Scenario 2 depicted in Figure 3 for the details of this
operation.
• Clear rules: Clears the call handling rules associated with the specified
mobile numbers. It accepts a single number as well as a group of mobile
numbers.
This is a list of the rules supported by the call handling web service:

• Call accepting: Only accept calls from a list of mobile numbers (which are
specified when setting the rule).
• Call blocking: Block calls for the mobile numbers which are in the block
list.
• Conditional call forwarding: Route the destination of a call to another
mobile number for a specific calling number.
• Unconditional call forwarding: Route the destination of a call to another
mobile number regardless of the calling number.
• Play audio: Initiate audio with the caller by routing the call to a media
server or by retrieving the audio files from a repository.

Scenario 1: Set a rule
Look at the example of setting a rule in Figure 2.

Figure 2. Set rule



Here are the steps for setting a rule in this example:

1. Raghu wants to set a rule for handling incoming calls to his mobile phone.
The possible rules are accept call, block call, call forward, or play custom
audio messages.

2. He accesses the web application exposed by the TSP from the mobile
phone via the GPRS (General Packet Radio Services) connection or from
a computer through the Internet connection. The web application collects
the data required to set the rule.

3. The web application makes a web service call to the call handling SI.

4. The call handling SI sets the rule and stores it in the database against
Raghu’s number.

Scenario 2: Retrieve the rule and act (accept call)
Look at the example of retrieving and acting upon a rule in Figure 3.

Figure 3. Retrieve rule



Figure 3 depicts the scenario of retrieving the rule and accepting the call.

1. Dhandu is attempting to call Raghu.

2. TSP network routes the call request to the call handling SI.

3. Call handling SI performs a lookup for the rules already set to handle the
call. The rule in place is “accept call”.

4. The call handling SI checks Raghu’s status and his current status is
available. Since Dhandu’s number is in the “accept call” category, the call
handling SI will route the call to Raghu via TSP network.

5. The TSP establishes a call session between Dhandu and Raghu.

What is a media server and its role in telecommunications?
In general, a media server is a dedicated computer in the distributed computer
network for storing and sharing various digital media such as digital videos, movies,
audio, music, and picture files.

In a telecommunications domain, a media server is the processing system that
handles the audio and video streams associated with telephone calls or connections.



A media server is responsible for processing digital audio and video data. The
telecommunications wireless systems are moving toward 4G systems where they
will be predominantly based on IP technologies namely voice over IP (VOIP) and
SIP. In this environment, the concept of media servers is becoming more attractive
in the telecommunications world.

Example media servers are:

• MXF media server bundles video, audio, and programmed data, such as
text – together termed essence – along with metadata and places them
into a wrapper. This enables increased flexibility, performance and cost
savings through the use of an IBM open standard.
• IBM Content Manager VideoCharger delivers audio and video media by
pushing them over the network to the client. The audio and video content
is streamed (that is, delivered in real time) and does not require that the
file be downloaded or saved before being played by the client. For more
information, see Resources.

Integration of WebSphere Telecom Web Services Server with
media server
The call handling SI has features for handling the telephone calls made to any
number based on the status (busy, no answer, and not reachable) of the called
number. Media server is used for providing a predefined audio and video status
message to WebSphere Telecom Web Services Server for handling the incoming
calls.

A practical scenario: Retrieve the rule and act (play custom audio message)

Figure 4 shows the steps when playing audio.

Figure 4. Retrieve the rule and play audio



Here are the steps for retrieving the rule and playing a custom audio message:

1. Dhandu is attempting to call Raghu.

2. The TSP network routes the call request to the call handling SI.

3. The call handling SI performs a look up for the rules already set to handle
the call. The rule in place is “play custom audio message” when Raghu's
phone status is busy.

4. The call handling SI attempts to check Raghu’s status by interacting with
TSP network.

5. The TSP network retrieves Raghu’s latest status; the status is busy.

6. Since Dhandu’s number is in the “play audio upon busy” category, the call
handling SI will route the call to the media server.

7. The media server plays the customized audio as a live stream to Dhandu.

Message flow



Figure 5 shows the messages flowing among the phones, the call handling SI, and
media server.

Figure 5. Message flow

Here are the messages in sequence:

1. Dhandu attempts to call Raghu. A SIP Invite request is routed to the call
handling SI by the TSP network infrastructure.

2. The call handling SI returns a 100 trying sip response to Dhandu.

3. The call handling SI attempts a SIP Invite to Raghu.

4. Since Raghu’s number is busy, the 486 busy SIP response is returned
to the call handling SI.

5. The call handling SI performs a lookup for the rules already set on
Raghu’s number. Since Dhandu’s number is in the “play audio upon busy”



category, the call handling SI will route the call to the media server, and
send a 181 forward (call is being forwarded) session progress
response to Dhandu.

6. The media server sends a 180 - ringing SIP response to the call
handling SI, which then routes the response to Dhandu.

7. The media server sends a 200 - OK SIP response to the call handling SI
which routes the response to Dhandu.

8. Dhandu sends an ACK SIP response as an acknowledgement response to
the media server.

9. A session is established between Dhandu and the media server. The
media server plays the customized audio as a live stream to Dhandu.

10. Dhandu sends a Bye SIP response to the media server to terminate the
session after the audio message has been sent.

11. The media server sends a 200 - OK SIP response to Dhandu as an
acknowledgement.

Conclusion
In this article, we introduced the IBM WebSphere Telecom Web Services Server,
and the role of a media server in the context of a telecommunications domain. We
have discussed how a recipient in the IP telecommunications network can set up
rules, such as, accept list, block list, call forward, play audio, and how the configured
rules can be retrieved and applied when a user attempts to call the recipient. We
also looked at a practical scenario of how customized audio messages can be
stored in the media server and played as a live stream to the caller based on the
recipient’s rule setting.



Resources
Learn
• IBM WebSphere software for Telecom Information Center: Read the product
documentation for IBM telecommunications products.
• IBM WebSphere Telecom Web Services Server product documentation: Find
product documentation for this IBM product.
• Media server: Learn more about media servers.
• IBM Content Manager VideoCharger: Access several product manuals and all
the support information for this product.
• IBM Service Provider Delivery Environment Framework Industries: Explore this
open, scalable, flexible telecom industry framework.
• IBM developerWorks Industries: Find the latest industry-specific technical
resources for developers.
• developerWorks podcasts: Listen to interesting interviews and discussions for
software developers.
• developerWorks technical events and webcasts: Stay current with
developerWorks technical events and webcasts.
Get products and technologies
• IBM trial software: Evaluate IBM software products in the method that suits you
best. From trial downloads to cloud-hosted products, developerWorks features
software especially for developers.
Discuss
• developerWorks blogs: Get involved in the developerWorks community.

About the authors
Dhandapani Shanmugam
Dhandapani Shanmugam is a solution architect in the Industry
Solutions Communication Sector team in IBM India Software Labs,
Bangalore. With over 10 years of IT experience, Dhandapani has
worked on many IBM middleware products for the Telecom domain
including IP Multimedia Subsystems/WebSphere Software for Telecom,
WebSphere Everyplace Server for Telecom, WebSphere Everyplace
Access, and WebSphere Everyplace Mobile Portal. He holds patents in
the functional areas of Mobile, Telecommunications, Enterprise



Middleware Application Servers, and XML. He has co-authored an IBM
Redbook on Telecom Web Services Server, and has authored
developerWorks articles for Pervasive solutions. Dhandapani holds a
Master of Science degree in Software Systems from Birla Institute of
Technology & Science, Pilani, and a Bachelor of Engineering degree in
Electronics & Communication Engineering from Bhartiyar University,
Coimbatore.

Raghu Juluri
Raghu Juluri is a Senior developer in Oracle India Development Center,
working on the Oracle Beehive collaboration platform. Prior to this, he
worked as a developer for WebSphere Software for Telecom products
in the IBM India Software Labs, Bangalore. He has three years of IT
experience. He is a certified Oracle Java Business Component
Developer and a SUN Java Certified Programmer, and has worked on
WebSphere Business Services Fabric, and Telecom Content packs.
Raghu holds a Masters degree from Birla Institute of Technology &
Science, Pilani, and a Bachelor of Engineering degree in Electronics &
Communication Engineering from Jawaharlal Nehru Technological
University, Hyderabad.


Ind twss-pdf

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Ind twss-pdf

Ähnlich wie Ind twss-pdf (20)

Ind twss-pdf