MAJOR PROJECT REPORT
Play & Record with Dtmf Service
based on JSLEE

Submitted to: Prof. Dr. –Ing. Ulrich Trick

Submitted by: Piyush Chand (Master Student- 937005)

Date: 31. 04. 2011

Major Project: Play & Record with Dtmf Service based on JSLEE 2

Acknowledgement

I am heartily thankful to my supervisors Patrick Wacht and Armin Lehmann, their guidance,
encouragement, and support from the initial to the final level enabled me to develop an
understanding of the subject.

Lastly, I offer my regards to all of those who supported me in any respect during the completion
of the project.

Piyush Chand


Contents
1. Project Goal………………………………………………………………………………..4

2. Structure of the Report…………………………………………………………………….4

3. Theoretical
Basis……………………………………………………………………………………......4

3.1 Mobicents JSLEE Application Server………………………………………………….4

3.2 Convedia Media Server- 3000………………………………………………………….7

3.3 MSML(Media Sessions Markup Language)…………………………………………...8

3.4 MSML Control Channel ……………………………………………………………….9

3.5 SIP (Session Initiation Protocol)………………………………………………….......11

4. Used Practical Framework ……………………………………………………………….14

5. Developed Service………………………………………………………………………..17

5.1 Initial Service Preparation……………………………………………………………...18

5.2 Establishing the Control Channel Dialog………………………………………………21

5.3 Consuming the Play & Record Service………………………………………………...25

5.4 Functionality of the Service…………………………………………………………….32

5.5 Development and Integration of the Library…………………………………………...42

6. Conclusion…………………………………………………………………………………..52

7. References…………………………………………………………………….. ……………53


1. Project Goal
The goal of the project is to develop a Service based on JSLEE (JAIN Service Logic Execution
Environment) which can utilize the functionality of the CMS (Convedia Media Server). The
service provides the user to play a music file, record a voice, playback a recorded file and also
utilize the DTMF (Dual-Tone Multiple Frequency) functionality of the Media Server.

2. Structure of the Report
The report contains the following chapters:

 Theoretical Basis: In this chapter of the report, the basic functionality of the Mobicents
JSLEE (Jain Service Logic Execution Environment) Application Server and the CMS-3000
(Convedia Media Server -3000) Media Server will be described. An overview of the SIP
protocol and the utilized MSML (Media Server Markup Language) will be provided.

 Used Practical framework: In this chapter of the report the used practical framework will be
described. The Message Sequence Chart related to the service will also be mentioned in this
chapter.

 Developed Service: In this chapter, detailed information about the developed service will be
described. The realization and implementation of the service will be described in detail.

 Conclusion: In this chapter, which value added services can be utilized by this developed
service will be mentioned. Also, a future extension of this service will be described.

3 Theoretical Basis
In this chapter of the report, the basics of the Mobicents JSLEE Application Server and the
Convedia Media Server-3000 will be discussed. Both of these servers are the required framework
for development of the service.

3.1 Mobicents JSLEE Application Servers

Providing more and more services to the end user is the primary object for any developer. In this
respect, one of the most important servers is the application server, which provides a stack of
functionalities to the end user or it can also be mentioned as services for the end user. In this
report the used application server is the Mobicents JSLEE Application Server. The JSLEE based


application server provides a high throughput, low latency event processing application
environment. JSLEE (Jain Service Logic Execution Environment) is the Java standard for SLEE.
JSLEE is designed to allow implementations of the standard to meet the stringent requirements of
communications applications, such as network signalling applications. The JSLEE specification
is designed so that implementations can achieve scalability and availability through clustering
architectures. Below, in figure 3.1.1, the architecture of the JSLEE can be seen. [1]

Figure 3.1.1 JSLEE Architecture [1]

In this architecture, JSLEE consists of four main areas: management, framework, resource
adaptors, and the Component model. The management entities allow the whole JSLEE
environment to be managed through JMX-Mbeans or Jopr i.e. an enterprise management solution
for JBoss middleware projects and other application technologies. The various entities in the
framework support the business logic implemented in distributed components, the so-called
service building blocks, or SBB. The trace entity allows a centralized and single point for
logging, alarms inform external management systems, timers invoke components in pre-defined
intervals, and profiles provide the business logic with information and data during execution.
Among them, the event router routes incoming and newly created events to previously registered
SBBs (Service Building Block) and resources. The event router is more or less the heart of
JSLEE's event routing system.

In this architecture, every area (i.e. management, framework, resource adaptors, and the
Component model) has its own importance. From a developer’s point of view the Component
Model which contains the SBB (Service Building Block) is quite significant.

Functionality of a SBB: [2]


 Event types received and fired by the SBB component.
 Per-instance state.
The per-instance state should be held in Container Managed Persistent (CMP) fields that can
maintain persistent state that should persist across failures.
 Event methods.
The SBB component provides an event handler method for each event type received by the
SBB component. The event handler method contains application logic to process events of a
specific event type. The SBB component also declares a fire event method for each event
type fired by the SBB component.
 SBB local interface methods.
The SBB component declares the SBB local interface of the SBB component. The SBB local
interface specifies the methods of the SBB component that may be invoked synchronously.
The SBB local interface methods of an SBB component instance can only be invoked by
another SBB component instance within the same SBB component instance tree. The SBB
also provides the implementation of the methods of the SBB local interface.
 Child relations.
The SBB component may be related to zero or more child SBB components. The SBB
component specifies its child SBB component relations. The SBB component identifies each
child SBB component relation through a deployment descriptor element and declares a child
relation successor.

Functionality of the Activity Context:

The SLEE uses an Activity Context to represent and encapsulate an underlying Activity object
within the SLEE. An Activity Context is a logical entity within the SLEE. It does not have a
visible Java API. There is a one-to-one relationship between an Activity object and an Activity
Context.

 An Activity Context is also a store for attributes that may be shared by multiple SBB entities
that interact with the Activity object represented by the Activity Context. These SBB entities
can read and modify attributes stored in the Activity Context.

 An Activity Context is also an event channel that accepts events fired on the Activity
Context and distributes these events to the SBB entities attached to the Activity Context. An
SBB entity can invoke other SBB entities in an asynchronous manner by firing events on the
Activity Context.

 An SBB entity may be attached to one or more Activity Contexts. An SBB entity can only
receive events fired on Activity Contexts that it is attached to. The SLEE does not count the
number of times an SBB entity is attached or detached from an Activity Context. The SBB
entity is either attached to the Activity Context or not. Attaching multiple times
consecutively is the same as attaching once and detaching multiple times is the same as
detaching once.


Whenever any event is fired by the SBB, the SBB is attached to the Activity Context. In this
respect it can be mentioned that the activity context is a main part to initiate the SBB service.
This is a basic concept in the JSLEE architecture, which will be again discussed in the
programming phase of the service.

3.2 Convedia Media Server- 3000

The RadiSys Convedia CMS-3000 media server delivers carrier-class media processing
capabilities for enterprise IP telecommunication services. Increased processing power, including
I/O throughput upgrades, delivers significant performance improvement for Voice XML-based
IVR and messaging applications, while delivering multi-service versatility for numerous
applications including IP PBX, instant video conferencing, IP contact centres, and unified
communication solutions. [3]

Valuable Services related to CMS- 3000:

Tones and Announcements: Audio announcements and ring back tones, Multiple languages
(40+), Variables (e.g. date, time, currency, etc.), Caller–specific announcement volume control.

DTMF: DTMF detection and generation, In band and RFC 2833, Redundant RFC 2833.

Conferencing: Up to 110 3-way conferences, Up to 330 participants per conference mix, N-way
audio mixing, Loudest N mixing and preferred speaker, Independent manual gain, control on all
ports, Automatic Gain Control (AGC), Current speaker notification, Whisper feature,
Personalized mixing for each participant (e.g. for complex call centre mixing models, network,
gaming, voice chat, etc.).

Recording and Playback: Audio and video recording / playback VCR Control (pause/resume,
skip forward, skip back) Internal and external storage (NFS/HTTP).
Audio Recording Formats:
 .wav (G.711, G.729)
 Quick time™ format (G.711)
 3GP format (AMR)
 RTSP 1.0 support for playback (G.711, AMR)

Voice Quality Enhancements (VQE): Packet Loss Concealment, Noise Gating, Noisy line
detection, VQE Statistics, Acoustic Echo Cancellation (AEC), and Noise Reduction.

Stream Connection: CALEA/Lawful intercept support for video and audio streams, Packet
forking, switching, and media replication (fan out).

Video: Video announcements and ring back tones Video recording and playback Interactive
Voice and Video Response (IVVR) Video text overlay, Voice–activated video switching (video
Conferencing), Continuous presence video conferencing.

Fax: Fax Detection & Notification, Embedded Fax Server (Send/Receive), T.38 or G.711 (T.30
Pass-through), TIFF Fax Storage Format.


Speech: Text-to-speech (TTS), Automatic speech recognition (ASR), Speaker verification,
MRCP v1.0 and v2.0.

Among these services, the main implementation of the service will be upon the Recording, Play
Back and also the DTMF.

3.3 MSML (Media Sessions Mark-up Language)

The Media Sessions Mark-up Language (MSML) is an XML (Extension Mark-up Language)
language used to specify and change the flow of media streams within a media server. MSML is
designed for manipulating media services offered by the media server to established media
sessions (established using SIP). MSML specifies how media sessions on the media server
interact, and controls and invokes media services on the media server.

For example, MSML can be used to create conferences and join sessions into conferences.
MSML can also be used with MOML (Media Objects Markup Language) to interact with
individual users or with groups of conference participants, for example applying IVR operations,
called “dialogs,” to sessions or conferences. Using MSML, it is also possible to control advanced
conferencing features on a media server, to modify media while a session is in progress, and to
perform advanced session manipulation such as personalized mixing.

MSML transactions are originated by application domain events. These events can be
independent of any media or user interaction. For example, an application may play an
announcement to a conference warning that its scheduled completion time is approaching.

MSML is designed to be used with other languages. For example, MSML does not set up or tear
down sessions. Instead, MSML uses a transport protocol such as SIP for that purpose. Various
protocols and languages are used to meet the requirements of media applications, so MSML has
been designed to be language-neutral, independent of its transport, and to use either one or many
transport channels. Similarly, MSML does not directly manipulate media resource objects.
Instead, MSML can be used to invoke media processing languages such as Media Objects Mark
up Language.

MSML does not directly constrain the media processing language. However, the current
implementation of MSML on the Convedia Media Server supports only MOML as a media
processing language. While MSML addresses the relationships of media streams (in, for example,
simple and advanced conferencing), MOML is an XML language that addresses the control and
manipulations of media processing operations, such as announcement, IVR, play and record,
AST/TTS, fax, and video. Together, MSML and MOML form general-purpose media server
control protocol architecture. [3]

DTMF Detection, Collection, and Generation
The media server detects, collects, and generates DTMF signals. These can be in band audio
DTMF tones or out-of-band RFC 2833 telephone-events.
DTMF collection can include any of a number of mechanisms supported by the control
protocol/language used by the control agent, including collection grammars. For example, the
control agent can use Speech Recognition Grammar Specifications (SRGSs), which are built-in


language grammars dedicated to specific tasks such as digit sequences or phone numbers, or digit
maps as defined by RFC 3435. The media servers also support long digit detection.
In addition to collection grammars, the media server supports a DTMF type-ahead buffer, as well
as the following optional capabilities:

 Dynamically specified first-digit timers

 Dynamically specified inter-digit timers

 Dynamically specified extra-digit timers

 Definition of a special termination key, such as “#”

The way DTMF is collected depends on media negotiation by the control protocols. For example,
while in band and out-of-band DTMF are supported, only the method negotiated using the control
protocol will be used. This functionality of the DTMF will be used while implementing the
service. [3]

3.4 MSML Control Channel

There are cases where the control agent prefers to set up one or more transport associations
strictly for service control signalling—that is, SIP (Session Initiation Protocol) sessions carrying
MSML and MOML without any associated media stream. To do this, the control agent must still
include SDP in its initial INVITE (otherwise, the media server will initiate an offer instead of
setting up a control channel). [3]
To signal the media server that a control channel is desired. The control agent can do either of the
following:
Figure 3.4.1, shows a call flow setting up an MSML channel strictly for control. Send an
INVITE that contains SDP, but where the SDP does not specify media—it contains no m= line.
This signals the media server that there is no media stream. This does not request a control
channel per se, but the media server understands this as a request to set up a control channel, and
does not initiate an offer/answer sequence. Send an INVITE that contains complete SDP but uses
0.0.0.0 as the connection IP address. In this case, the media server assigns IP/UDP and codec, but
does not send any RTP (Real Time Protocol).


Figure 3.4.1 Call Flow Setting up for a Control Channel [3]

The control channel will be built within the developed service, so as to send MSML as INFO to
the Media Server and then receive a response 200 O.K. from the Media Server.

Figure 3.4.1, shows the example of a MSML, which provides the functionality to record and play
the recorded file. These will be sent to the Media Server within a SIP INFO Message.

Figure 3.4.2 MSML Example for Play and Record [3]


Figure 3.4.2, shows the example of a DTMF functionality based Msml. This will be sent to the
media server.

Figure 3.4.3 MSML Example for DTMF [3]

In both the above mentioned examples you can see, how the MSML and the MOML are bind
together, to make a complete useful snippet which can be used to initiate the response from the
media server.

3.5 SIP (Session Initiation Protocol)

SIP is a protocol for the creation and full control of Multimedia over IP Sessions. SIP fulfils for
Multimedia over IP the same purpose as a signalling protocol in circuit switched
telecommunication (ISDN-DSS1, POTS, SS No. 7). Additional functions of SIP: e.g. short
messaging, state/event monitoring (e.g. monitoring of the online status of a participant) First SIP
specification in 1999 through IETF (Internet Engineering Task Force) in RFC (Request for
Comments) 2543 Realized through the exchange of text-based messages linked to the HTTP
(Hyper Text Transfer Protocol). [5]

Basic functionality of SIP:

 SIP serves in the transferring of signalling and transmission information for Voice over IP or
Multimedia over IP Sessions (Real-time communications connections in IP Networks.

 Session forms: Point-to-point, conferences with three or more participants.


 Established SIP communications steps are defining SIP transactions (simplified: e.g.
Session-creation, modification, termination).

 SIP Messages can transport other session-relevant information e.g. using SDP (Session
Description Protocol)

SIP Messages: SIP messages can be of two types either SIP request or SIP Status information.

SIP requests: initiate a SIP Transaction e.g. (Simplified)

 Session creation

 Session creation

 Session modification

 Session termination

 Activating of service features

 Transmitting of short messages or presence information

SIP Status information (Responses): answering SIP requests on content or confirming receipt

The “Client-Server Principle” applies (HTTP (Hypertext Transfer Protocol):

 A client (SIP User Agent Client, UAC) sends a request (Request, SIP Message) to a server.

 A server (SIP User Agent Server, UAS) answers a request (Response, SIP-Status
information).

SIP Message Request:
Basic requests (RFC 3261; elementary for the development of particular SIP transactions.

INVITE: (Initiating of a SIP Session (connected-oriented communication state example speech
communication, video communication etc.).

BYE: (Close of an existing SIP Session).

ACK: (Acknowledge of receipt of final (not provisional) SIP Status information that follows an
INVITE Message (SIP Three-Way-Handshake)).Single SIP Request which is not answered with
status information.

CANCEL: (Notice to cancel the processing of a running SIP Transaction, e.g. of a session build
up).


REGISTER: (Registering of an SIP End system of a SIP Registrar Server).

OPTIONS: (Enquiry for features of a SIP End system, no session build up required).

SIP Message Header:
Headers describe each SIP Message, the corresponding SIP Transaction as well as characteristics
of the SIP Network elements. Following are the list of header message, which is part of every SIP
message depending upon the type of message to be sent. [5]

In Figure 3.5.1, a list of used header fields and their characteristics are described.

Figure 3.5.1 Description of the Header field [5]


Figure 3.5.2 Example of a header field [5]

In Figure 3.5.2, an example of the SIP Message Header can be seen; in this the fields are filled in
with the associated header field.

4 Used Practical Framework
In this part of the report, the used practical framework is described, and also the MSC( Message
Sequence Chart) is discussed with respect to the service that is developed.

 Application Server used: Mobicents Media Server, version MMS 2.2.1, it is software
based. It is described in detail in chapter 3.1.

 Media Server used: Convedia Media Server, CMS-3000, explained in detail in chapter 3.2

 Integrated Development Environment (IDE) used: Eclipse, version- Helios 3.6.2

 Network Analyser used: Wireshark. It is a free program for the analysis of network
communication links

 SIP Soft Phone used: PhonerLite. It enables your PC to use it for internet telephony VoIP
(Voice over IP).


Figure 4.1 Used frame work for the implementation

Figure 4.1 , shows the used framework of the service, which contains the Mobicents Application
server, CMS-3000 server, SIP soft phone on a PC.

Figure 4.2, shows the MSC (Message Sequence Chart) of the implementation of the service. In
this figure, it can be seen that initially the control channel is developed, which is refer as the
control channel dialog and then the user agent initiates the service.

When the user starts the service, an INVITE message is sent to the application server. This
INVITE message is then forwarded to the Media server. To the response of the INVITE message
from the application server, the media server sends a 200 O.K. to the application server. Then
after receiving a 200 O.K. from the media server, a 200 O.K. is sent from the application server
to the user agent.

To the response of the 200 O.K. from the application server, an ACK is sent to the application
server. Then after receiving the ACK from the user agent, the application server sends an ACK to
the media server. Immediately, after an ACK, an INFO message is sent from the application
server to the media server. At this point the first INFO message is sent from the application
server to the media server. This INFO message contains the MSML+MOML body, which can be
seen in the figure 3.4.1, chapter 3.4. After sending the INFO message, a 200 O.K. is received
from the media server. A peer to peer connection between the user agent and the media server is
established for the RTP.


The second INFO message is sent, while the flow of RTP. This contains the second MSML body
as shown in figure 3.4.1, chapter 3.4. To the response of the INFO message again a 200 O.K. is
sent to the Media Server.

Figure 4.2 Message Sequence Chart of the implementation


For the closing of the service, the user agent sends a BYE message to the application server. The
application sends a BYE message to the media server. The media server sends a 200 O.K. to the
application server in response to the BYE message, the application server sends a 200 O.K. to the
user agent to close the call and execute the complete SIP protocol.

In Figure 4.2, the arrows are the flow of Messages, which in JSLEE terms can be mentioned as
events.

 The green arrows are the event which are fired from the AS to the MS and also from AS to
the UA.

 The blue arrows are the response to the fired events from the MS to the AS and also the UA
to the AS.

 The red arrows are the events which are fired to the AS, to initiate the service.

 The purple colour shows the INFO messages which carry the MSML body.

5. Developed Service
This chapter of the report provides the detailed information about the service that has been
developed. The service depends upon the MSC described in chapter 4, figure 4.2. The following
description of the service will give a much clearer view of how the development is done on the
JSLEE application server. In the initial part of this chapter, the basic fundamentals of the JSLEE
architecture will be discussed and then the implementation of the service will be described. To
make the development much more understandable, the description is divided into four important
sub chapters.

1) Initial Service Preparation

2) Establishing the Control Channel Dialog

3) Consuming the Play & Record Service

4) Service Functionality

The Play & Record service depends upon the six methods. These methods make it possible for
the application server to receive and send SIP messages from or to the user agent and also from
or to the Media server. Following are the six methods:

 OnStartService( )

 OnSuccess( )


 OnInvite( )

 OnAck( )

 OnInfo( )

 OnBye( )

The functionality of these methods will be explained while explaining the service.

5.1 Initial Service Preparation

The initial service preparation provides the base for the service building block SBB, which
includes the life cycle of the SBB and the invocation of the Sbb Context, which together provides
the basic functionality of the SBB of the JSLEE architecture.

Figure 5.1.1: Invoking the used facilities in the JSLEE architecture

In figure 5.1.1, from line number 78 to 92, the used facilities of the JSLEE architecture are used.
This includes the cached objects in the SBB´s environment as the ServiceActivityFactory, the


ServiceActivityContextInterfaceFactory, the ActivityContextNamingFacility. Then, to use the SIP
protocol the SleeSipProvider and the SipActivityContextInterfaceFactory is invoked.

Line number 98 and 99 initialize the Media Server IP address as 192.168.1.186 and also the IP
address of the Call Server or the User Agent.

Figure 5.1.2 initializing the required APIs

In figure 5.1.2, line 109, the abstract method for the service activity context is invoked, which
allows the SBB to co relate the service activity context in an abstract approach. From line 119 to


144, the SbbContext method and the related APIs are invoked. The SLEE invokes this method
after a new instance of the SBB abstract class is created. It uses this method to pass a SbbContext
object to the SBB object. If the SBB object needs to use the SbbContext object during its lifetime,
it should keep a reference to the SbbContext object in an instance variable. This includes the
initializing of the service activity context and the SIP API.

Figure 5.1.3 the Life Cycle of the SBB

Every SBB goes through a lifecycle which is a conventional procedure and is followed by every
SBB. In figure 5.1.3, line 166 to line 209 and figure 5.1.4, from line 216 to 233, the life cycle of
the SBB is invoked, at various stages depending upon the state of the SBB, it is an internal part of
the SBB, which makes it possible for the SBB to implement in a much more procedural way.


Figure 5.1.4 The Life cycle of the SBB

All these methods will be explained, in detail with respect to the service provided.

5.2 Establishing the Control Channel Dialog

In this chapter of the report, the creation of the control channel will be discussed. Before sending
a MSML + MOML, the control channel is to be created. The basic principle of developing a
control channel is discussed in detail in chapter 3.4. In this implementation of the service, the
control channel is created in the OnStartService Method.

OnStartService( ): This method is invoked to create the control channel between the application
server and the media server. In figure 5.2.1, from line 247 to 263, the header fields of the SIP
INVITE message, which is to be sent, are created. All the header fields which are described in
chapter 2 are used to create the SIP message. This will create the control channel between the
application server and the media server.

No media is used while creating the control channel. So, from line 267 to 273, the SDP with no
m-parameter is created.


Figure 5.2.1 the onStartService Method: Creating the Control Channel

In figure 5.2.1, from line 275 to 286, the request is created by invoking the sip provider; the sip
provider is a factory of functions by which we can create the header of the SIP protocol as
described in chapter 2. In line 289 and 290 in figure 5.2.2, the contact header is created. From


line number 292 to 300, the client transaction is initiated and the SIP INVITE is sent. The activity
context is invoked which allows the control channel dialog between the application server and the
media server (which is mentioned in the chapter 3.4) to execute. The dialog attaches to the
activity context.

After sending the SIP INVITE to the media server, a 200 OK message is received to the
application server, to complete the threeway hand shake for the control channel, an ACK has to
be sent to the media server. This will be done in the other method named onSuccess().

Figure 5.2.2 The OnStartService Method, initiates the Control Channel


Figure 5.2.3 the onSuccess Method, Sends response to the media server

OnSuccess( ): In figure 5.2.3, from line 396 to 435, the ACK is sent to the media server to
complete the three way handshake. The control channel dialog (line 412) is invoked and then the
ACK is sent to the control channel and the from address is to be added to the ACK (line 409).


5.3 Consuming the Play & Record Service

In this chapter of the report, the implementation of the service will be provided. After creating the
control channel between the application server (AS) and the Media Server (MS), the user agent
(UA), can consume the services which are associated to the media server.

To provide a logical link among user agent, application server and media server, the development
of the service is linked together by the following dialogs, which are mentioned below:

 The dialog between the user agent and the application server.
 The dialog between the application server and the media server.
 The dialog between the user agent and the media server.

In the service development, the dialog between the UA and the AS is stored in the
Subscriberdialog.The Subscriberdialog is a method in the code, which stores the dialog between
the UA and the AS. In figure 5.3.1, the setSubcriberDialog stores the dialog. It stores the dialog
as an array list. This array list is also invoked in the activity context.

Figure 5.3.1 storing the subscriber dialog

The dialog between the AS and the MS is stored in the MediaServerSubscriberdialaog( ). This
method can be seen in figure5.3.2, the dialog is again stored in an array list. This array list is also
invoked in the service activity context.


Figure 5.3.2 Storing the MediaServerSubscriberdialog

Both theses dialogs are linked to create the dialog between the UA and the MS. This dialog is
stored in the linkeddialog( ). The method which provides the functionality to link the dialog can
be seen in figure 5.3.3, in this method the dialog is stored as a hash map, which is then invoked in
the activity context.

Figure 5.3.3 string the linked dialog

These dialogs will be mentioned while explaining the service.

After deploying the service, the control channel between the application server and the media
server is established. To use the service, the user agent sends an INVITE message to the AS by
the usage of the correct SIP URI. As soon as the INVITE message is sent to the application server
the OnInvite Method is invoked.

OnInvite( ): This method is invoked, when an INVITE message is sent by the user agent to the
application server. This method is shown in figure 5.3.4, from line 441 to line 449, creates the


URI which is to be used by the user to initiate the service. After receiving this INVITE message
from the user agent, the fields for expecting the ACK from the application server are set with in
the CMP field (i.e. Figure 5.3.4, from line 452 to 465).

5.3.4 onInvite Method, retrieves the invite from the user agent

The INVITE message is to be forwarded from the AS to the MS. So the next part of the method
provides the functionality to forward the INVITE message from the AS to the MS. In figure
5.3.5, from line 472 to 474, the dialog is invoked and then attached to the activity context. This
dialog is stored as the subscriber dialog, shown on line 476. From figure 5.3.5, line 483 to figure
5.3.6, line 525, the INVITE message is created, which is to be forwarded to the MS.


Figure 5.3.5 onInvite method, forwarding the INVITE to the media server


Figure 5.3.6 creating the header of the INVITE message.

In figure 5.3.6, the header field for the INVITE message is created. From line 512 to 523, all the
header fields are included which makes the INVITE message. On line 525 the contact header is
created by an independent method, this method can be seen in figure 5.3.7.


Figure 5.3.7 attaching the dialog to the activity context.

In figure 5.3.7, line 530 to line 537 this part of the method invokes the activity context and then
attaches the dialog to the activity context. The INVITE message is to be sent from the AS to the
MS. On line 540 the MediaServerSubscriberDialog dialog is stored. This dialog is then stored to
the LinkedDialolgs( the link dialog provides the functionality to link the user subscriber dialog
and the MediaServerSubscriberDialog).

Figure 5.3.8 storing the contact header field.

Figure 5.3.8, the method which creates the contact header field of the SIP message is created.
This method is invoked in the onInvite method figure 5.3.6 on line 525.


Figure 5.3.9, Sends response 200 OK to the user agent.

After receiving a 200 O.K. from the MS, a 200 O.K. is to be sent from the AS to the UA. In
figure 5.3.9, the dialog between the UA and the AS is invoked. This is set on line 390. The to
Header field should be the same.

In figure 5.3.10, the to Header field is stored. This method is then invoked in figure 5.3.9, line
395. To send a 200 O.K. to the UA, the link to the user agent dialog is first initiated. This method
can be seen in figure 5.3.9. This method is invoked on line 397. After getting this dialog the
response as 200 O.K. is sent to the user agent.


Figure 5.3.10, stored To Header field.

In figure 5.3.10, an independent method is developed, this method stores the to header field. The
to Header field should be the same when an ACK is to be sent to the User Agent. A hash
mapping is created, with respect to the dialog and the to header.

Figure 5.3.11 Stored Dialog, to link the user agent dialog.

In figure 5.3.11, the subscriber dialog or the dialog between the UA and the AS is stored. Again
the hash mapping is created between the two required dialogs. This linked dialog is stored in the
Service Activity Context.

5.4 Functionality of the Service

In this chapter of the report, the realization of the service will be described. The methods that are
used to develop the functionality of the service will be described in detail. This service provides
the user to record and then play the recorded voice back to the user.


Realization of the Play & Record Service:

The realization of the service is done when the INFO message containing the MSML body is sent
to the media server; this is described in chapter 3.4 and chapter 3.5 in detail. Figure 3.4.2 and
3.4.3 on page 11, shows the example of the MSML+MOML document used to realize this
service. This MSML body invokes the media server to send a response as a 200 O.K. to the
application server. After receiving a 200 O.K. from the media server, a 200 O.K. is sent to the
user agent from the application server. This establishes a peer to peer connection between the
user agent and the media server. RTP flows between the user agent and the media server. During
the RTP flow, the user can record his or her, own voice and then play the same voice back as
soon as the recording is over.

Realization of the DTMF functionality:

For realizing the DTMF functionality of the service, an INFO message is sent to the media
server. When a user presses the button 1 on his or her SIP based soft phone, an INFO message is
sent which contains the MSML body as mentioned in chapter 3.4 and chapter 3.5 to realise the
DTMF functionality.

In this implementation, when the user presses the button on the SIP based soft phone, the user
will hear a music sound from the media server. This can be seen in figure 5.4.1.

Figure 5.4.1, Display of the DTMF example.


Figure 5.4.2 the onAck method.

To realize the service, the onAck method is invoked as in this method the ACK is sent to the
media server. Immediately after sending the ACK, the INFO message is sent to the media server
which contains the MSML body.

Figure 5.4.2, on line 570, the Sip Provider is invoked. The Sip provider is invoked to create the
address field from the address factory. From line 573 to 580, the significant dialogs and the
header fields are invoked. These are mentioned below respectively.

1) The server transaction dialog is invoked. (Line 573)

2) The from address header field is created from the Address Factory. (Line 574)

3) The control channel dialog is invoked with respect to the from address (line 575).The dialog
is invoked from the method mentioned in figure 5.4.4.

4) The subscriber dialog is invoked and linked to the media server dialog (Line 576). This is
invoked from the method described in figure 5.4.5.

5) The stored to header field dialog of the subscriber is invoked (Line 577).This dialog field is
invoked from the method described in figure 5.4.7.

6) The cseq field for the control channel is retrieved (Line 578). This is invoked from the
method described in figure 5.4.8.


7) The increment is provided to the cseq field, this is a convention while sending an INFO
message to the Media Server. (Line 579)

8) After the increment of the cseq field, the cseq field is set (Line 580). This is invoked from
the method described in figure 5.4.9.

Figure 5.4.3, Shows the MSML body to be sent in the INFO message.

In figure 5.4.3, the Msml + Moml body is described as a String data. From line 607 to 619, the
INFO message is created. While sending the MSML body in the INFO message, the tag field
should remain the same. So, on line 591, the tag field is retrieved and then the MSML body is
sent in the INFO message to media server. On line 619, the contact header field for the Media
server is created. This is invoked from the method mentioned in figure 5.4.9.


Figure 5.4.4, The Control Channel Dialog.

Figure, 5.4.4, the control channel dialog is stored. This method again uses the hash mapping
between the address and the dialog. This is also invoked in the service activity context.

Figure 5.4.5, The Link dialog to the MS dialog.

In figure 5.4.5, the linked dialog to media server is created. This method stores the dialog by
using the hash mapping between the required dialog for the service.

Figure 5.4.6, The stored to header for the dialog.

In figure 5.4.6, the to header for the dialog is stored, this header is stored in a method which uses
the hash mapping between the dialog and the to header.


Figure 5.4.7, The stored Cseq field for the dialog, to get it from the dialog.

In Figure 5.4.7, the method which stores the Cseq field is shown. This method is invoked while
getting the Cseq value of the Message related to the dialog. It is again stored by using the hash
mapping between the dialog and the variable long.

Figure 5.4.8 the stored CSeq field for the dialog, to set it for the dialog.

In figure 5.4.8, the Cseq value which is to be sent while sending an ACK to the media server is
stored. The Cseq value which is retrieved is incremented and then set, this can be seen in figure
5.4.2, line 579.


Figure 5.4.9, The contact header field for the MS.

In figure 5.4.9, the method which creates the contact header field that is to be sent to the media
server is created. This method contains the mentions the UDP, which is to be used when sending
the ACK and also the created address “Mobicents SIP AS <sip:as@”. This is actually seen when
sniffing the network between the AS and the MS while using wireshark. After knowing this
special field, it is used in the code.


Figure 5.4.10, the onInfo method for the service.

In figure 5.4.10, the Info method is invoked, from line 754 to line 772. The required digit of the
DTMF service is initially retrieved from the onInfo method. This digit is parsed to use it as an
integer within the implementation. The parsing is done from line 760 to line 772.

The digit is referred to the number that is pressed on the SIP based soft phone. So, for example if
“1” is pressed then the digit will be set to 1.

As soon as the digit 1 is pressed again an INFO message including the Msml +Moml document is
sent to the media server. This is shown in figure 5.4.11.


Figure 5.4.11 The INFO message sent to the MS, after pressing “1”.

In figure 5.4.11, the INFO message is sent to utilize the DTMF functionality related to the
service.


Figure 5.4.12, the onBye Method.

OnBye( ): This method is invoked when a BYE message is sent by the user agent to the
application server. In figure 5.4.12 from line 970 to line 978 defines the user agent.

In this method all the dialogs which includes the dialog between the user and the application
server, the dialog between the application server and the media server are detach from the activity
context, the user is also removed from the control channel. This is shown in figure 5.4.12, from
line 985 to figure 5.4.13, line 1020.


Figure 5.4.13, shows the complete onbye method of the service.

5.5 Development and Integration of the Library

In this chapter of the report the development of the library and the integration of the library to the
service will be discussed.

The Msml body discussed in chapter 3.4 can be integrated to a service by developing an
independent library. This library will consist of all the methods and functions. These methods can
be invoked while developing a service. In this chapter of the report, some parts of the developed
library will be discussed and also the integration of this library to the service will also be
described.


The MSML and the MOML are XML schema files which are stored within the CMS-3000
server. These Schema files can be parsed to generate java objects. There are many ways of
parsing the xml schema. The technique that has been used in the development is the JAXB (Java
Architecture for XML Binding). JAXB is basically a parsing technique to convert xml to java
objects and vice versa. Figure 5.5.1, shows the implementation of the JAXB technique. In the
figure it can be seen that the XML Schema is compiled by using a Binding compiler to generate
the required schema derived classes and interfaces.

5.5.1 JAXB API Technique [6].

The JAXB API in the figure 5.5.1 provides the functionality to use the marshalling and
unmarshalling techniques. Unmarshalling an XML document means creating a tree of content
objects that represents the content and organization of the document. Marshalling is the opposite
of unmarshalling. It creates an XML document from a content tree. [6]


5.5.2 Generated MSML based java objects.

In Figure 5.5.2, the java objects are generated, which are used in the library. These java objects
will be used to create the MSML in the service. The important generated class which is used in
the service is the MSML class. This is shown in the figure 5.5.2. In this figure all the required
MSML based java objects are created.


5.5.3 DTMF based generated java objects.

In figure 5.5.3, the java objects generated from the DTMF based xml is created. This part of the
generated java objects is used in the library.

In the implementation, the XML schema is compiled to generate schema derived classes and
interfaces which are shown in figure 5.5.3 and figure 5.5.2. These classes and interfaces are then
marshaled to generate the required XML document. In the implementation the XML document is


the MSML document. In figure 5.5.4, line 30 to line number 48, the required package are invoke
in the code by using these packages the JAXB and the marshalling technique can be used to
generate the required XML and the required API is invoked to marshal the classes.

5.5.4 Marshalling code.

The marshalling is done in the code shown in figure 5.5.4. This code allows the java objects to be
converted into XML documents.


Figure 5.5.5 method which generates the DTMF MSML.

Figure 5.5.5 shows the method developed to use the MSML functionality based on the Convedia
Media Sever. This method is a part of the Library. The Library is integrated to the service as a
referenced JAR (Java Archive). A referenced JAR is a bundle of packages, classes and objects
which can be used while developing a code.


Figure 5.5.6, the extension of figure 5.5.5.

Figure 5.5.6, is the extension of the method mentioned in figure 5.5.5. In this figure from line
420, The Marshaller API is invoked which makes it possible for the java objects to be converted
to a xml document or msml document.


Figure 5.5.7, The MSML Creator Class for the DTMF functionality.

After the integration of the JAR to the service, the msml attributes is used in a method. This
method is shown in figure 5.5.7, in the figure the class MSML Creator contains the createplay()
method. This method contains the required attributes for the service. In figure 5.5.7, the used
attributes is for the DTMF service.


In figure 5.5.8, the method for the record service is developed. This method includes the required
attributes to initiate the record service.

Figure 5.5.8, The MSML Creator for the play and record service.


Figure 5.5.9, Integration of the library to the Service.

In figure 5.5.9, on line 594 and 595, The Msml Creator class is invoked and the method for the
play and record service is invoked. When this class is invoked the tag field is used to link the
MSML body to the required dialog of the service. The tag is the common value which links the
INFO message while sending the MSML body. The tag can be determined while sniffing the
application server and the media server by using wireshark.

This figure is very much same to the figure 5.4.3 on page 35; the only difference is that the
method is invoked to create the Msml instead of including the Msml + xml document.


6. Conclusion
The development of the Play & Record Service with the DTMF functionality makes it possible
for the SIP based end user to use various kinds of value added services.

Some value added services which can be utilized from the developed service are as follows:

1. Announcement call: In this service an announcement can be made to the end user.

2. Play voice call: In this service the user can record his or her, own voice and then play it back
after a few seconds.

3. Play music service: In this service the user can press a button on the SIP based phone and
then music will be played back to the user.

This service can further be extended depending upon the MSML which are based on CMS- 3000.
Some services like developing a music box, IVR (Interactive Voice Response) system can be
developed based on this implementation. One interesting future extension to this service can be to
use DTMF functionality to control the Energy Harvesting Devices. Based on figure 6.1, the SIP
based end user can use the DTMF functionality based on the CMS- 3000 server and then utilize
this functionality to control the EnOcean Devices.

Figure 6.1 Future extension of the service


7. References
[1] Ivelin Ivanov : Mobicents JSLEE for the People, by the People issued on March 14, 2006
available at http://today.java.net/pub/a/today/2006/03/09/mobicents-jslee.html.

[2] JAIN SLEE (JSLEE) 1.1 Specification, Final Release, issued in the year 2008, available at
http://jcp.org/aboutJava/communityprocess/final/jsr240/index.html.

[3] CONVEDIA MEDIA SERVER: MSML 1.1 INTERFACE REFERENCE issued date
December 2009, RELEASE 4.19.

[4] CONVEDIA MEDIA SERVER: MOML 1.0 INTERFACE REFERENCE issued date on
December 2009, RELEASE 4.19.

[5] Prof. Dr.- Ing. Ulrich Trick: Methods, Systems and Networks for Digital Communication,
Lecture on Next Generation Networks, Voice over IP and SIP.

[6] Ed Ort and Bhakti Mehta: Java Architecture for XML Binding (JAXB) issued on March
2003 available at http://www.oracle.com/technetwork/articles/javase/index-140168.html

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Mehr von Piyush Chand

Mehr von Piyush Chand (11)