This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Entire telecommunications industry has undergone massive changes over the last two decades. Starting with PSTN Public Switched Telephone Network the technology used for communications over a long period of time, which supports the circuit-switched voice communication. It basically uses the fixed line analog telephone systems. Now it is almost entirely digitized and includes both mobile and fixed telephones [15, 16].
Before PSTN, telephones do not have any kind of network, where end points are connected in pairs. Later, all the telephones are connected to a local telephone exchange, and exchanges are connected together with trunks (start of PSTN). Initially, telephone exchanges were operated manually, which was automated later with mechanical switching followed by analog switching. PSTN had to evolve regularly to provide quality of service to increasing customers, calls and distribution to other countries.
Once entire call handling and switching is automated, focus is directed onto data services over PSTN. In 1970s telecommunications industry started implementing data services using X.25 protocol, using the already existing end-to-end equipment of PSTN. Later in 1980s the industry has began planning for digital services . By mid 1990s internet had a widespread deployment, and in late 90s with the advance of internet and attention of academia and commercial research labs Internet Telephony came into existence, where voice is digitized and transported as discrete packets over internet .
There is a gradual shift in telecommunications industry from the circuit-switched PSTN to packet-switched internet. Factors responsible for shift in the industry are:
Widespread availability of network in the form of internet.
Increase in computing power to encode and decode voice packets in real time, even in handheld devices.
Knowledge in real-time transport of delay sensitive data (voice packets), by uniting a set of standards RTP, SDP, ITU-T's H.323 and SIP that could be implemented by telecommunication vendors.
Telecommunications Deregulation act of 1996, forcing the providers to share their equipment and network .
The most popular form of Internet Telephony is VoIP (Voice over Internet Protocol), which has the ability to packetize the voice and other media (like video), over the internet. But VoIP is not equivalent to Internet Telephony, which has additional features for enhanced communication experience using the services of network .
Session Initiation Protocol:
SIP is a signalling protocol for Internet Conferencing, telephony, presence, events notification, and instant messaging. It is an open standard signalling protocol developed by the IETF (Internet Engineering Task Force), to manage (like create, modify and terminate) sessions with one or more participants in an IP network. A session can be a straightforward two-way phone call or it can be a multi-media conference session with many persons participating .
Many protocols are developed to handle real-time media like voice, video or text. SIP is an application layer control protocol. SIP is very agile and its functionality is independent of underlying transport protocols and the type of session that is being established. SIP works along with the existing protocols to build a complete multimedia architecture.
SIP can add/remove participants and media to/from existing sessions. SIP does not provide any services, but provides primitives to implement different services . A single primitive can be used to provide different kinds of services. SIP is an extensible protocol, which enables to incorporate services into communication sessions. Many services like internet conferencing, IP telephony, instant messaging, presence, voice and video communication, data collaboration, online gaming, application sharing are available through SIP.
SIP telephone systems deliver features that enhance users' mobility and productivity, while securing substantial cost-saving advantages. SIP makes it easy to connect various components of overall communication system, rapidly deploy applications, reduce costs, and improves customer service and employee productivity by simplifying organization's communication architecture .
Since SIP messages and the sessions pass through different networks, SIP cannot, and does not, provide any network reservation capabilities. SIP is a text-based protocol and uses the UTF-8 charset. SIP is based on an HTTP-like request/response transaction model. SIP message is either a request from client to server or a response from server to client. Each transaction consists of a request that invokes a particular method/function on the server and at least one response. SIP header fields are similar to HTTP header fields in both syntax and semantics.
VOIP in Business Prospect:
Voice over Internet Protocol (VoIP) is the most popular voice communications technology over IP networks like the internet or packet-switched networks. VoIP allows making free or very low cost telephone calls over the internet. VoIP unleashes the power of internet and technologies (like SIP) and provides various kinds of services (like music on hold, voicemails, and call diverts etc) which are impossible or highly expensive using traditional telephone technologies .
VoIP phone can either be a soft phone or an ordinary phone converted into an internet phone. VoIP clients allow users to make calls to telephones on any network anywhere in the world. Soft phone clients (like skype) are available for free over the internet, which allow free calls to users on internet. Ordinary phone clients for home users are also available from different service providers, but are available at cheaper prices [11, 3].
Many clients provide full range of VoIP solutions, for businesses and individual customers. VoIP services are suitable for both business and individual clients, because calls within the network are free, and international calls and calls to other networks are cheap when compared to traditional telephone systems. VoIP provides ever improving quality of calls by investing in internet and managed IP networks .
VoIP is also available for mobile phones, where it uses the data plan or Wi-Fi connection to make calls. Another implementation of VoIP is to use a gateway to bridge SIP and RTP into mobile networks. But network operator's revenue depends on voice communication through the network, using data plan (an additional service) to make calls will have a negative impact on the revenue of network operators.
Mobicents is the first open source VOIP platform certified for JSLEE 1.1 and SIP Servlets 1.1 compliance. Mobicents communication platform enables the creation, deployment and management of services and applications. It provides the infrastructure to build next generation applications integrating voice, video and data across wide range of networks with multiple end points (devices) .
2. Literature Review
A new standard is required for developers and network operators that reduces cost and increases performance in developing communication applications . Mobicents is the open standard communication platform that provides the infrastructure to build next generation applications integrating voice, video and data across wide range of networks with multiple end points (devices).
Fig: . Mobicents Infrastructure
[Image courtesy: Mobicents User Guide]
Core components involved in setting up mobicents as Service Delivery Platform (SDP) for telecommunications applications. Mobicents provides:
Integrated JSLEE and J2EE environment for developing communications applications.
A network abstraction layer for application developers to hide the underlying communications network.
A set of APIs for network management and development of new services.
A SIP Servlets container to provide a rapid application development platform for SIP applications.
Media Server component to support all major media protocols and provide a set of features like media playback, Interactive Voice Response (IVR), conferencing, voice recording, and better media processing .
Mobicents enable the composition of Service Building Blocks (SBB) such as call control, billing, and user provisioning, administration, presence sensitive features. The JAIN SLEE specification allows popular protocol stacks to be plugged in as Resource Adapters (RA). The SLEE SBBs have many similarities to EJBs .
Mobicents has an extensible architecture with integration points for enterprise applications like web, CRM and SOA end points. Mobicents is suitable for a variety of platform domains which require EDA for high volume and low latency signalling. JMX and SNMP interfaces are used for monitoring and management of mobicents components, which makes an easy choice for telecom Operations Support Systems (OSS) and Network Management Systems (NMS).
Mobicents uses the following components:
JBOSS Micro container for core service IoC and management.
JNDI for SLEE service registration.
JTA for Transaction Management.
JBOSS cache for high availability state replication .
Mobicents is distributed under GNU General Public License (GPL), the most popular Free Open Source Software (FOSS) license. Users can contribute to the development of mobicents through subscribing to firstname.lastname@example.org.
2.1.2. JBoss Communications Platform (JBCP):
Combining assets of both JBoss and mobicents, Red Hat has developed the JBoss Communication Platform for telecommunications industry. JBCP can be used as a standalone product and can be integrated with other application platforms from network equipment providers (NEP), and others [www.jboss.com].
JBoss Microcontainer environment hosts higher level containers. It provides service registration, configuration, dependency management, class loading isolation control and many other fundamental building blocks necessary for highly scalable, fault tolerant middleware servers.
2.1.3. Why only Mobicents Platform?
Mobicents is the first and only open source communication platform with JAIN SLEE complement and other implementations. Mobicents JAIN SLEE is built on top of the JBoss Application Server (AS), an open source AS i.e. Mobicents JAIN SLEE complement JAIN SLEE with JEE 5 container features. This allows convergence of different application models, for featuring rich communication services. For example, the Web and SIP can be combined to achieve a more sophisticated and natural user experience. As Mobicents is built on top of JBoss Application Server, it inherits quality management features and tools from JBoss AS, such as JMX Console, Jopr plugins and SNMP Adaptor [Mobicents JAIN SLEE User Guide].
Mobicents Media Server and Mobicents SIP Servlets are also implemented along with Mobicents JAIN SLEE, providing unique value and features, when compared to all other platforms. Mobicents JAIN SLEE implements wide variety of Resource Adaptors, which help in development of different application models.
Mobicents Presence Server and Diameter are the new services that are developed for mobicents platform. These services bring out a new dimension in application development for mobicents. Several tools like ANT tasks, Maven2 plugins and an Eclipse plugin, named EclipSLEE, are also available [http://mobicents.org] to encourage developers in choosing the platform.
2.2. JAIN SLEE:
A SLEE is an Application server, or service container, which defines a component model, designed and optimized for event driven applications (applications which receive requests in the form of events). In addition to the component model, SLEE also defines management interfaces used to administer the container, components within the environment, and a set of standard facilities .
Fig: . SLEE Components 
[Image Courtesy: http://mobicents.org ]
JAIN SLEE is the open java standard for SLEE and is designed to allow implementations of the standard to meet the stringent requirements of communications network signalling applications. It is the only industry standard developed for communications applications, so that the application can be just written once and run on any application environment which implements SLEE . JAIN SLEE is a component model like EJB. JSLEE is built on the components of J2EE, for event driven applications and it can be implemented independent of J2EE. JSLEE is not a component of J2EE and is not equivalent to J2EE .
An event represents an occurrence that requires application processing. Event may originate either from an external resource or within the SLEE or an application running in the SLEE . Events are routed to respective components depending on type of the event. Each event type is handled by its own event handler.
Generally applications will have an active thread of execution, but event driven applications define methods that are invoked when events are delivered to the application. These methods will inspect and handle the event. The application code may invoke the resource that generated the event or other resources or even it can trigger new events or update the application state. Event handling can be done by a single event handler method which inspects the events and forwards it to correct method; otherwise, each event is handled by its own event handler method, which enforces a well-defined event interface .
Applications can access resources and protocols over multiple networks from within the JAIN SLEE environment. JAIN SLEE enables to host the applications as a collection of reusable components . These components are called as Service Building Block (SBB) components. These components can receive and handle events and also has interface to invoke methods. At runtime, instances of components are created and instances that are no longer useful are deleted .
Communications applications need resources (like protocol stacks and databases) that are external to SLEE. The SLEE architecture defines how to interact with and implement these resources, through Resource Adaptors (RA). A RA consists of a set of java classes to implement the interface of a particular RA type. RA is provided either by a resource vendor or by SLEE vendor for resource implementation in SLEE [8, 13].
A service in JSLEE is a managed field replaceable unit. Life cycle of a service is managed by the administrator of JSLEE, which is achieved through the standard management services provided by JSLEE .
SLEE specification defines a provisioned service, which is represented as a profile. Provision service contains the subscriber data that can be managed through interfaces provided by profile. Provisioned data from profile is needed for an application to perform its function .
2.2.2. Factors Influencing the Design of JAIN SLEE:
Importance of Reliable Software:
A communication service requires continuous availability of service, and is achieved only if the time to detect and recover from failure is low. The complexity of a system depends on the services provided. So to address the software issues/failures software architecture is needed.
Next Generation Services:
Increase in communications over internet and telephony networks requires next generation services, which can accommodate features of both the networks. Problems in the development of next generation services:
Secure network access
To meet the performance and availability requirements of applications, the programmer must have access to APIs that allow application logic to:
Functions through host and process failure
Execute independent of particular computing nodes
Rely on a defined failure model in order to simplify application behaviour through process and host failure
Do not need to explicitly manage concurrency
Can have their state replicated
Have clearly defined state synchronization points
Manages concurrent execution of application components
Allows application components to be updated whilst active
Migrates application components between processing nodes in the system as particular processes and nodes may failure
Prevents faulty application components from affecting other independent application components.
Event based model, asynchronous, support for composition
Container manages component state and garbage collection of components
Transaction boundaries for demarcation and semantics of state replication
Third party event driven components
Strongly typed event handling signatures
Management of life cycle of Server, Services, Provisioned state
Independent of network technologies/ protocols/ elements through resource adaptor architecture
Simple and Object Oriented programming model
Application server manages application state
Support for third party application components and applications
Support for independent units of work
Possible to naturally model asynchronous systems
Using open standard APIs hide the complexity of networks from the application layer and having a low-cost infrastructure for telecommunications will enable the development of new services.
Rather than using new architecture for each network type, it is better to develop an application environment that can implement different network resources and protocol stacks. This will reduce the cost of network operators to develop a new architecture on adaption of new technologies.
Network equipment providers and Network Operators have different hardware and operating system platforms. But the applications must run on all platforms without any modifications to the source code and has to work independent of hardware architecture and system level APIs.
2.2.3. Application Characteristics of JSLEE Design:
Different implementations of application environments have different architectures and provide applications with different characteristics. Comparison of requirements of applications from different environments is shown in the figure below.
Fig: . Requirements comparison of event-driven and enterprise applications
[Image courtesy: David. F et al., Open Cloud]
2.3. Mobicents Media Server:
Media Server is a network device that processes media streams (simple definition). "In the world of telephony, a media server is a computing component that processes the audio and/or video streams associated with telephone calls or connections" - [Mobicents Media Server user guide].
Media Server performs functions like playing Announcements, processing media streams for DTMF detection and transcoding, and also recording.
"Functionality of Media Server:
Control of RTP Media Streams
Video fast update and flow control using RTCP feedback
Mixing of incoming media streams
Media Stream Source (for multimedia announcements)
Media Stream Processing (e.g.: transcoding, DTMF detection)
Media Stream Sinks (for multimedia recordings)" [RFC 5567]
Media Server can be a Hardware Media Server or Software Based. The Hardware Media Server uses the hardware components for processing audio/video. Each hardware component is assigned to a specific job. In case of Software based Media Server, entire media processing is carried out by software, where specific hardware components are not required for processing.
"Factors encouraging the usage of Software Based Media Server:
Lowering initial costs
Lowering development costs
Handling multiple media types
Lowering the costs of deployment and maintenance
Enabling rapid time to market" [http://redhat.com]
Application Server (AS) is a logical entity that is capable of running one or more instances of a communication application. An MS supplies one or more media processing functionalities to an AS. Depending on the media service required by the call the AS will forward onto the specific MS. The type of processing that a MS performs on media streams is specified and controlled by an AS. Application Servers uses SIP to establish control channels between themselves and Media Servers. They use SIP Third Party Call Control to establish, maintain, and tear down media streams from those SIP User Agents to a Media Server - [RFC 5567].
Fig: . Basic signalling architecture for session between AS and MS
[Image courtesy: RFC 5567]
"Media streams go directly between SIP User Agents and Media Servers and Media Servers supports multiple media types. This architecture must support a many to many relationship between AS and MS. Most services have interactions between the AS and MS during a call or conference. The type of interactions can be generalized as follows:
Commands from an AS to an MS to request the application or configuration of a function.
Responses from an MS to an AS reporting on the status of particular commands.
Notifications from an MS to an AS that reports results from commands or notify changes to subscribed status.
Commands, responses and notifications are transported using one or more dedicated channels between the AS and the MS. Dedicated control channels provide reliable, sequenced, peer-to-peer transport for Media Server control interactions.
Implementations must support the Transport Control Protocol (TCP) and may support the Stream Control Transmission Protocol (SCTP). As MS control requires sequenced reliable delivery of messages, unreliable protocols such as the User Datagram Protocol (UDP) are not suitable" - [RFC 5567].
The Mobicents Media Server is the first and only open source media server for delivering:
Media gateway functionality at high quality
Meeting the demands of converged services on different platforms
Increasing flexibility to support a wide variety of call control protocols
Mobicents Media Server is developed on top of java technologies and also has JSR-309 standard API implementation to control media servers irrespective of underlying protocol used. Hence applications developed on any platform can control Mobicents Media Server using JSR-309 API [Mobicents Media Server Guide].
"MMS is developed using the JBoss Microcontainer kernel. The JBoss Microcontainer provides:
Configure, and deploy, Plain Old Java Objects (POJOs) into a Java Standard Edition runtime environment.
Manage the lifecycle of applications used with the MS.
Convert internal, fixed subsystems into stand-alone POJOs.
Introduces the Service Provider Interface (SPI) throughout the base server" - [http://redhat.com]
2.3.2. Media Server Architecture:
Media services have played an important role in the traditional Time Division Multiplexing (TDM) - based telephone network. As the network migrates to an Internet Protocol (IP)-based environment, media services are also moving to new environments. MMS is built on top of java, which is ideal for network computing. Modularization in MS is supported by using Java Management Extension (JMX) and SLEE container. High degree of modularity benefits the application developers in many ways. Mobicents uses SLEE for implementing its own communication capabilities. [www.jboss.com]
Media Server Architecture assumes that call control capabilities are outside the scope of MS and are handled by call control procedures from protocols like MGCP, MEGACO or MSML and others. Each control module can be plugged into the environment directly as a standard deployable unit. A call control application logic deployed on JSLEE platform can be used for call handling. So it is unnecessary for developers to configure low-level transaction details and APIs [MMS User Guide].
Fig: . Media Server basic architecture
[Image courtesy: http://groups.google.com/group/mobicents-public/ ]
The Mobicents Media Server core is based on software components only. This property allows easy scale from development environment on a single server to production deployment in a distributed network environment" [MMS User Guide].
Components and Factories: Each component is associated with a unique identifier, and a name decided by its factory, which is shared among components from same factory. To create any component Media Server needs a suitable factory.
Endpoint Composition: Each endpoint created in Media Server is a composition of Media source/sink and also depends on how these components are ordered.
Channel: A channel is not a media component but is used to connect two media components or with other channel. Channel will construct media flow path by joining components using pipes [MMS User Guide].
2.3.3. Components of Mobicents Media Server:
High level Components in MMS are: End points and Controllers. Other important components of MMS are:
Integrating these individual components into Mobicents Media Server provides many key features. This can be done by using the generic Service Provider Interface.
Fig: . High level Components of Mobicents Media Server
[Image courtesy: http://groups.google.com/group/mobicents-public/ ]
Endpoint: Consider a media gateway as a set of endpoints. An endpoint is a logical representation of a physical entity such as an analog phone or a channel in trunk. A physical endpoint requires a hardware component, but with software a virtual endpoint is established. Each endpoint has a set of resources that provide media-processing functionality. It manages the connection of media streams between resources and arbitrates flow of data between them [www.redhat.com].
Announcement Access Point: This provides access, intuitively, to an announcement server. The announcement server plays a particular announcement, on receiving a request from the call agent. These endpoints are capable of playing announcement signals, but cannot do transcoding. Packet Relay must be used to achieve transcoding.
IVR Access Point: An IVR endpoint provides access to an IVR service. On obtaining a request from call agent, the IVR server plays announcements and tones, and listens for responses from client (like DTMF keypad input or voice message). An IVR endpoint cannot support more than one connection at a time. IVR just plays and records media in the same format as it is stored and received, because it cannot do transcoding.
Conference Access Point: This endpoint is used to provide access to a specific conference. Media gateways can establish several connections between the endpoint and packet networks or between endpoints in same gateway. Signals originating from these connections are dependent on connection mode.
Packet Relay Access Point: This endpoint is a special form of conference bridge endpoint that allows only two connections. These can be found in connection between a secure and an open network, or in transcoding servers used to provide interoperation between incompatible gateways, gateways which operate over different transmission networks.
Loopback: This is also called as echo, which is mostly used for testing. This endpoint returns audio signal coming from an endpoint back to the same endpoint, creating an echo effect.
Signalling and Control or Controllers: Controllers allow external interfaces to be implemented for the Media Server. Each controller module implements an industry standard control protocol, and uses a generic SPI to control processing components or endpoints. One such controller is MGCP [www.jboss.com].
MGCP - Media Gateway Control Protocol
Java Media Control API(JSR-309)
Timer: It is the only thread among the Media Server components. It provides time, much like a crystal oscillator. All Media Sources and Sinks synchronize with the Timer.
Buffer: It is a media data container that carries media data from one processing component to other. Properties of Buffer:
Data: The internal data object that holds the media chunk (byte[ ]).
Offset: The Offset of data array where valid data begins.
Length: Length of valid byte data.
Format: The format of data.
Sequence number: The sequence number of this buffer.
Timestamp: The timestamp of the buffer.
Duration: The duration of this buffer.
Media Source and Media Sink: Media Source is the one that generates media (Audio player), while Media sink is the one that takes media (Recorder). To achieve modularity every component in Media acts as either a Media Source or Media Sink.
Resource Group: Resource Group is not a Media Source or Sink, but acts as a container for both Media Source and Sink. Each endpoint will have Media Sink or Media Source or both declared. If not, the endpoint needs to declare a Resource Group.
Inlet: Inlet is a special media component, which is not a Media Sink but provides an access to the Media Sink.
Outlet: Outlet is also a special media component similar Inlet, which is not a Media Source but provides an access to the Media Source.
2.3.4. Technical Specifications of Mobicents Media Server:
Media and Coders supported by Mobicents Media Server (MMS):
G711 (a-Law, u-Law)
DTMF (RFC 2833, INBAND)
Media file formats supported by MMS are:
2.3.5. Media Server in Real World:
Media Servers are widely used around the world in many fields. A live example is the usage of MS by the Mobile/PSTN service provider, where MS is used to play announcements, to record voice messages, store and play them back to user on request. Even IVR applications are used by a lot of companies in handling customer calls. Consider Banking Sector which uses IVR service for checking balance, and verify transactions through the phone line.
Developing such converged applications has now become very easy with the availability of Open Source Mobicents platform and Media Server. There is no limitation for developing any kind of converged application using Mobicents Media Server, as it supports any network. Even it can support in developing applications for Next Generation Network - IP based Multimedia Subsystem (IMS). To make cost effective and flexible applications to meet customer requirements and reduce marketing time the transaction must happen between the SS7 network and IMS. To support this, MMS will act as IMS - Media Resource Function (MRF) that caters the needs of IP based home networks and MMS can also be deployed as PSTN gateway that converts the SIP signalling into SS7 signals [Mobicents SIP Servlets User Guide].
Fig: . Typical MMS Deployment Scenario
[Image courtesy: http://groups.google.com/group/mobicents-public/ ]
This is the typical deployment scenario of combining both IMS and SS7 using MMS. Where MMS handles the IMS media on one side and uses PCM (Pulse Code modulation) time slots to connect to the SS7 network.
2.4. SIP Servlets Server:
2.4.1. Introduction to SIP Servlet:
SIP Servlet is a Java-based application component which is managed by a SIP Servlet container and which performs SIP signalling. Like other Java-based components, servlets are platform independent Java classes that are compiled to platform neutral bytecode that can loaded dynamically into and run by a java enabled SIP application server [A. Kristensen, 2003].
SIP Servlets are similar to HTTP Servlets and interacts with clients using request and response messages through the servlet container. Servlet container is a part of application server, which contains and manages servlets through their lifecycle [c. Boulton et. al. 2009]. Servlet container provides network services by sending and receiving requests and responses. It also provides other services like security to servlets, by placing security restrictions on the environment, where servlets are executed.
Fig: . SIP Servlet and Servlet container interaction
[Image courtesy: http://voxeo.com ]
The above diagram shows the relationship between SIP Servlet, Servlet container, Application server and Java Virtual Machine (JVM). SIP Servlets run on application servers that support SIP. The servlet container manages the lifecycle of servlet from loading servlet class, instantiating, invoking and destroy the servlet. Servlet container uses the service() method to handle the messages in the form of ServletRequest and ServletResponse objects. Servlet container enables the destroyed servlet to be garbage collected. SIP Servlet containers also manages other resources like listening points, session state and application components.
2.4.2. Relationship with HTTP Servlet API:
"SIP Servlet supports SIP where as HTTP Servlet supports HTTP.
Both HTTP Servlet API and SIP Servlets API are defined under same package, i.e. javax.servlet.
HTTP services are explicitly hosted on HTTP origin servers i.e. on a web server. But SIP services are hosted on servlet container and SIP applications require intelligent request routing.
HTTP is not a peer-to-peer protocol as is SIP.
Web applications never originate requests, but SIP Servlet API has to support the following capabilities:
Generate multiple response
Proxying requests, possibly to multiple destinations
Receive responses as well as requests
Application entry point used by SIP and HTTP Servlets is same, i.e. service method. But SIP Servlet API slightly differs from HTTP. SIP Servlet API method is: void service(ServletRequest request, ServletResponse response). When SIP traffic is processed one of the request and response objects is set to null, but not both.
HTTP Servlet API is synchronous whereas SIP Servlet API is asynchronous.
HTTP Servlet API has to select only a single application to process each incoming request, but multiple services can be applied to an incoming SIP request" - [A. Kristensen, 2003].
Converged SIP and HTTP Applications:
SIP Servlet API can be implemented independently of the HTTP Servlet API, but on combining both will provide many interesting services and applications from both the environments. This requires a converged container to provide feature of both HTTP and SIP Servlet APIs. Some of the converged applications are telephony, Web, email, presence and instant messaging. To support applications which include both SIP and HTTP components, a converged container that supports both the APIs is needed [A. Kristensen, 2003].
2.4.3. Mobicents SIP Servlet Server (MSS):
Mobicents SIP Servlets delivers a consistent, open platform on which to develop and deploy portable and distributable SIP and converged JEE services. It is the first open source certified implementation of SIP Servlets 1.1 (JSR 289) that run on top of tomcat or JBoss containers [http://mobicents.org].
Telecommunication applications require High Availability, fault tolerance, scalability, and performance. High Availability of applications is achieved through clustering technology. Clustering is a complex technology, which uses techniques like state replication, load balancing, and failover capabilities to provide high availability and scalability of applications and services [MSS User guide].
Features of Mobicents SIP Servlet Server:
The first certified SIP Servlet v1.1 (JSR 289) implementation.
A current call rate of 100 calls per second over a 24-hour duration: 8,640,000 total calls.
Load balancing, cluster and failover support.
Merged SIP and HTTP session Management.
A browser-based Management Console.
A bundled JSLEE/SIP interoperability demonstration application for MSS for JBoss.
Built-in Media support.
Extensions such as SUBSCRIBE/NOTIFY, among others.
Concurrency and Congestion control.
2.5. SIP Presence Server:
Presence service is to find out location of the users by using their mobile phones. This enables customers to find out their own or others current location. This service can be used by an individual customer or a group of customers for office use. An example for this service is Find Friends by AT&T Wireless. This enables cell phone users to find out location of other users. After two people locating each other, they can find a location to meet and directions to the location. Presence service is provided by enhancing SIP with spatial location capabilities for supporting personalized telecommunication services [Wilson Wu, et al.].
The presence system allows customers register to other users and notify them on change of state. The presence service has two clients, PRESENTITY and WATCHER. Presentity is a client whose location information is captured, stored and distributed. Watcher is a client who receives location information of others [Day, et al. 2000]. To receive location information, one must be added as a watcher for the client. A client can hide the location information, by removing a selected user or entire group from the list of watchers.
2.5.2. Mobicents SIP Presence Server:
The JBCP SIP Presence Service offers presence functionalities to SIP-based networks using standards developed by the IETF, the Open Mobile Alliance (OMA), the 3rd Generation Partnership Project (3GPP) and the European Telecommunications Standards Institute (ETSI) [Mobicents SIP Presence Service User Guide].
Fig: . JBCP SIP Presence Service servers
[Image courtesy: http://redhat.com]
SIP Presence Service is provided by using three interconnected servers.
SIP Presence Server: It is an entity that receives stores and distributes SIP Presence Information. Functions of SIP Presence Server:
Periodically receives and updates location information of presentities from one or more presence sources.
Manages subscriptions of watchers to the service and notifies them on information changes, by retrieving presence authorization rules from XDM server.
Manages subscriptions from watcher information subscribers to watcher information and notifies about watcher information changes.
XML Document Management Server (XDMS): It is a functional element of next-generation IP communications networks is in charge of handling the management of user XML documents stored on the network side. These include authorization rules, static presence information, contact and group or resource lists, policy data and many more.
Resource List Server (RLS): The RLS manages subscriptions to presence lists. It creates and manages back-end subscriptions to all resources in the presence list and this list is retrieved from XDM Server [Mobicents SIP Presence Service User Guide].
Fig: . JBCP SIP Presence Integrated server
[Image courtesy: http://redhat.com ]
The main advantage of the JBCP SIP Presence Service is that, each server can be deployed separately, or all servers can be integrated on the same host [http://redhat.com].
2.6. Mobicents Diameter Service:
Diameter is a computer networking protocol for Authentication, Authorization and Accounting (AAA) defined in RFC 3588 [A. Mendonca, et al]. AAA protocols like TACACS and RADIUS were deployed initially to provide dial-up PPP and terminal server access. With growth of Internet and newly emerged access technologies routers and network access servers (NAS) have increased in complexity and demands, putting new demands on AAA protocols [Calhoun, et al, 2003].
Network access requirements for AAA protocols include:
Diameter service addresses all the requirements and also provides support for additional services like:
Peer discovery and configuration
Core components in the Diameter Architecture:
Stack: It is the primary component of the Diameter service. It administers the mechanisms that control message sending and receiving, peer management, and session management through State Machines.
Multiplexer (MUX): It acts as a wrapper to the stack, which includes a simplified API. It provides the ability to register listeners to applications, which allows multiple applications share the same stack instance. Main components of MUX are:
Validator and Dictionary: Diameter Validator provides message validation in accordance with industry standards. The main use of validator is to detect malformed messages. The Dictionary is used by the MUX to create and retrieve correctly configured messages and Attribute value pairs (AVP) like bit flags and AVP types [A. Mendonca et al].
2.7. Interactive Voice Response (IVR): IVR is a technology that automates interactions with telephone calls [http://voxeo.com], by voice recognition and dual-tone multi-frequency signalling (DTMF) keypad inputs detection. IVR is employed by companies with high call volumes, to reduce cost of sales, service, collections, inquiry and support calls to and from their company and for better customer service experience. IVR applications are generally used in telephone banking, credit card transactions, bill payments and more. IVR services enable companies to provide services even outside the business services.
Historically, IVR services have used pre-recorded voice prompts and menus to present information and options to callers, and DTMF keypad input to gather responses. Modern IVR solutions also enable input through voice recognition [http://voxeo.com]. IVR service is provided by many companies. Some of the leading service providers are:
Comsys services & solutions for Voice, Web and mobile
Voxeo IVR platforms
IVR not only uses pre-recorded voice messages, but also uses a dynamically generated audio. Audio is dynamically generated by using the Text-To-Speech (TTS) feature.
Typically IVR applications are created and deployed on IVR platforms with significant caller usability, back end integration, and development complexity limitations.
Design & Development
This project is to develop an application for SIP user to read out web content by web grabbing. Web grabbing can be called as Screen Scraping which often meant capturing information from the text-based interfaces of terminal applications to repurpose them for use in web applications [James Governor et al., 2009]. This chapter discusses about the development and methodology of the project.
A SIP-based VoiceXML browser allows a SIP user to take part in application-specific IVR systems [K. Singh et al., New York]. Even a normal telephone user can also use this browser through SIP-PSTN gateway, and have the advantages of VXML technology. A SIP-VoiceXML browser is similar to a web browser for a telephone instead of a desktop PC. The browser fetches the VoiceXML pages or pre-recorded media files from a web server and presents an interactive dialog to the telephone user [K. Singh et al., New York]. But project is to develop a similar application on mobicents communication platform.
The application should handle the calls from clients/users, and establish connection with Media Server, and fetch VXML pages to present an interactive dialog to users. The application provides services like news headlines, sports headlines and weather report for a selected city from the list of cities provided. Interactive Voice Response (IVR) is used to detect DTMF keypad input from clients. Client is prompted for selection of service; upon service selection content from respective web pages is grabbed and filtered out to generate VXML code from PHP. To execute PHP code, mobicents platform has to work along with web sphere (a web server), where VXML code is generated and forwarded onto Media Server for playback to user.
To start with project, idea about SIP, mobicents platform, web sphere, VXML and PHP. After gaining knowledge about mobicents tryout the examples provided to understand how the application works and how it interacts with the application platform and how resources are implemented.
Upon clear idea of how applications run on mobicents platform make a clear sketch of how to develop application. First develop the PHP code for grabbing content from web and generate VXML code to read out the content grabbed. Later develop VXML code part which prompts the client for selection of input. After completion of both VXML and PHP coding part develop program for mobicents platform to handle the call and inscribe VXML code into the application. The application invokes the PHP file on the web server and obtains the output in VXML code format (which can be used instantly for execution).
Exploiting Mobicents Media Server capabilities through Demo Application:
Demo applications are provided with mobicents to understand the features and capabilities of servers and resource adapters on mobicents platform. To understand the capabilities of Media Server and Media Server Resource Adaptors mms-demo application is used. This demo application demonstrates the following services:
Packet Relay Endpoint
The following is a sequence diagram describing step by step procedure for call establishment in Call-SBB. This block is used to handle calls irrespective of the service selected.
Fig: 4. Step by step procedure for Call SBB.
[Image Courtesy: http://groups.google.com/group/mobicents-public ]
Flow chart for Demo Application:
Flow chart describing DTMF service from demo application is shown in the figure below and program flow is almost same for other services as well and the only change will be the functions used to invoke the services and how to use them.
Fig: 5. Flow Chart for Media Server example with DTMF recognition
Sequence Diagram for IVR example:
Fig: 6. Sequence Diagram for IVR Example
[Image Courtesy: http://groups.google.com/group/mobicents-public ]
Component Diagram for MMS demo example:
Fig: . Component Diagram for MMS Demo DTMF service