MAJOR PROJECT REPORTPlay & Record with Dtmf Service based on JSLEE Submitted to: Prof. Dr. –Ing. Ulrich TrickSubmitted by: Piyush Chand (Master Student- 937005) Date: 31. 04. 2011
Major Project: Play & Record with Dtmf Service based on JSLEE 2 AcknowledgementI 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 anunderstanding of the subject.Lastly, I offer my regards to all of those who supported me in any respect during the completionof the project.Piyush Chand
Major Project: Play & Record with Dtmf Service based on JSLEE 3Contents 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
Major Project: Play & Record with Dtmf Service based on JSLEE 41. Project GoalThe goal of the project is to develop a Service based on JSLEE (JAIN Service Logic ExecutionEnvironment) which can utilize the functionality of the CMS (Convedia Media Server). Theservice provides the user to play a music file, record a voice, playback a recorded file and alsoutilize the DTMF (Dual-Tone Multiple Frequency) functionality of the Media Server.2. Structure of the ReportThe 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 BasisIn this chapter of the report, the basics of the Mobicents JSLEE Application Server and theConvedia Media Server-3000 will be discussed. Both of these servers are the required frameworkfor development of the service.3.1 Mobicents JSLEE Application ServersProviding more and more services to the end user is the primary object for any developer. In thisrespect, one of the most important servers is the application server, which provides a stack offunctionalities to the end user or it can also be mentioned as services for the end user. In thisreport the used application server is the Mobicents JSLEE Application Server. The JSLEE based
Major Project: Play & Record with Dtmf Service based on JSLEE 5application server provides a high throughput, low latency event processing applicationenvironment. 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 ofcommunications applications, such as network signalling applications. The JSLEE specificationis designed so that implementations can achieve scalability and availability through clusteringarchitectures. Below, in figure 3.1.1, the architecture of the JSLEE can be seen.  Figure 3.1.1 JSLEE Architecture In this architecture, JSLEE consists of four main areas: management, framework, resourceadaptors, and the Component model. The management entities allow the whole JSLEEenvironment to be managed through JMX-Mbeans or Jopr i.e. an enterprise management solutionfor JBoss middleware projects and other application technologies. The various entities in theframework support the business logic implemented in distributed components, the so-calledservice building blocks, or SBB. The trace entity allows a centralized and single point forlogging, alarms inform external management systems, timers invoke components in pre-definedintervals, 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 registeredSBBs (Service Building Block) and resources. The event router is more or less the heart ofJSLEEs event routing system.In this architecture, every area (i.e. management, framework, resource adaptors, and theComponent model) has its own importance. From a developer’s point of view the ComponentModel which contains the SBB (Service Building Block) is quite significant.Functionality of a SBB: 
Major Project: Play & Record with Dtmf Service based on JSLEE 6 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 objectwithin the SLEE. An Activity Context is a logical entity within the SLEE. It does not have avisible Java API. There is a one-to-one relationship between an Activity object and an ActivityContext. 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.
Major Project: Play & Record with Dtmf Service based on JSLEE 7Whenever any event is fired by the SBB, the SBB is attached to the Activity Context. In thisrespect 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 theprogramming phase of the service.3.2 Convedia Media Server- 3000The RadiSys Convedia CMS-3000 media server delivers carrier-class media processingcapabilities for enterprise IP telecommunication services. Increased processing power, includingI/O throughput upgrades, delivers significant performance improvement for Voice XML-basedIVR and messaging applications, while delivering multi-service versatility for numerousapplications including IP PBX, instant video conferencing, IP contact centres, and unifiedcommunication solutions. 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-wayaudio mixing, Loudest N mixing and preferred speaker, Independent manual gain, control on allports, 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 linedetection, VQE Statistics, Acoustic Echo Cancellation (AEC), and Noise Reduction.Stream Connection: CALEA/Lawful intercept support for video and audio streams, Packetforking, switching, and media replication (fan out).Video: Video announcements and ring back tones Video recording and playback InteractiveVoice and Video Response (IVVR) Video text overlay, Voice–activated video switching (videoConferencing), Continuous presence video conferencing.Fax: Fax Detection & Notification, Embedded Fax Server (Send/Receive), T.38 or G.711 (T.30Pass-through), TIFF Fax Storage Format.
Major Project: Play & Record with Dtmf Service based on JSLEE 8Speech: 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, PlayBack 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 isdesigned for manipulating media services offered by the media server to established mediasessions (established using SIP). MSML specifies how media sessions on the media serverinteract, 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 withindividual 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 advancedconferencing features on a media server, to modify media while a session is in progress, and toperform advanced session manipulation such as personalized mixing.MSML transactions are originated by application domain events. These events can beindependent of any media or user interaction. For example, an application may play anannouncement 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 teardown sessions. Instead, MSML uses a transport protocol such as SIP for that purpose. Variousprotocols and languages are used to meet the requirements of media applications, so MSML hasbeen designed to be language-neutral, independent of its transport, and to use either one or manytransport channels. Similarly, MSML does not directly manipulate media resource objects.Instead, MSML can be used to invoke media processing languages such as Media Objects Markup Language.MSML does not directly constrain the media processing language. However, the currentimplementation of MSML on the Convedia Media Server supports only MOML as a mediaprocessing 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 andmanipulations of media processing operations, such as announcement, IVR, play and record,AST/TTS, fax, and video. Together, MSML and MOML form general-purpose media servercontrol protocol architecture. DTMF Detection, Collection, and GenerationThe media server detects, collects, and generates DTMF signals. These can be in band audioDTMF tones or out-of-band RFC 2833 telephone-events.DTMF collection can include any of a number of mechanisms supported by the controlprotocol/language used by the control agent, including collection grammars. For example, thecontrol agent can use Speech Recognition Grammar Specifications (SRGSs), which are built-in
Major Project: Play & Record with Dtmf Service based on JSLEE 9language grammars dedicated to specific tasks such as digit sequences or phone numbers, or digitmaps 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 wellas 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 controlprotocol will be used. This functionality of the DTMF will be used while implementing theservice. 3.4 MSML Control ChannelThere are cases where the control agent prefers to set up one or more transport associationsstrictly for service control signalling—that is, SIP (Session Initiation Protocol) sessions carryingMSML and MOML without any associated media stream. To do this, the control agent must stillinclude SDP in its initial INVITE (otherwise, the media server will initiate an offer instead ofsetting up a control channel). To signal the media server that a control channel is desired. The control agent can do either of thefollowing:Figure 3.4.1, shows a call flow setting up an MSML channel strictly for control. Send anINVITE 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 controlchannel per se, but the media server understands this as a request to set up a control channel, anddoes not initiate an offer/answer sequence. Send an INVITE that contains complete SDP but uses0.0.0.0 as the connection IP address. In this case, the media server assigns IP/UDP and codec, butdoes not send any RTP (Real Time Protocol).
Major Project: Play & Record with Dtmf Service based on JSLEE 10 Figure 3.4.1 Call Flow Setting up for a Control Channel The control channel will be built within the developed service, so as to send MSML as INFO tothe 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 playthe 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 
Major Project: Play & Record with Dtmf Service based on JSLEE 11Figure 3.4.2, shows the example of a DTMF functionality based Msml. This will be sent to themedia server. Figure 3.4.3 MSML Example for DTMF In both the above mentioned examples you can see, how the MSML and the MOML are bindtogether, to make a complete useful snippet which can be used to initiate the response from themedia server.3.5 SIP (Session Initiation Protocol)SIP is a protocol for the creation and full control of Multimedia over IP Sessions. SIP fulfils forMultimedia over IP the same purpose as a signalling protocol in circuit switchedtelecommunication (ISDN-DSS1, POTS, SS No. 7). Additional functions of SIP: e.g. shortmessaging, state/event monitoring (e.g. monitoring of the online status of a participant) First SIPspecification in 1999 through IETF (Internet Engineering Task Force) in RFC (Request forComments) 2543 Realized through the exchange of text-based messages linked to the HTTP(Hyper Text Transfer Protocol). 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.
Major Project: Play & Record with Dtmf Service based on JSLEE 12 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 informationSIP Status information (Responses): answering SIP requests on content or confirming receiptThe “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 speechcommunication, video communication etc.).BYE: (Close of an existing SIP Session).ACK: (Acknowledge of receipt of final (not provisional) SIP Status information that follows anINVITE Message (SIP Three-Way-Handshake)).Single SIP Request which is not answered withstatus information.CANCEL: (Notice to cancel the processing of a running SIP Transaction, e.g. of a session buildup).
Major Project: Play & Record with Dtmf Service based on JSLEE 13REGISTER: (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 characteristicsof the SIP Network elements. Following are the list of header message, which is part of every SIPmessage depending upon the type of message to be sent. 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 
Major Project: Play & Record with Dtmf Service based on JSLEE 14 Figure 3.5.2 Example of a header field In Figure 3.5.2, an example of the SIP Message Header can be seen; in this the fields are filled inwith the associated header field.4 Used Practical FrameworkIn this part of the report, the used practical framework is described, and also the MSC( MessageSequence 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).
Major Project: Play & Record with Dtmf Service based on JSLEE 15 Figure 4.1 Used frame work for the implementationFigure 4.1 , shows the used framework of the service, which contains the Mobicents Applicationserver, CMS-3000 server, SIP soft phone on a PC.Figure 4.2, shows the MSC (Message Sequence Chart) of the implementation of the service. Inthis figure, it can be seen that initially the control channel is developed, which is refer as thecontrol 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. ThisINVITE message is then forwarded to the Media server. To the response of the INVITE messagefrom the application server, the media server sends a 200 O.K. to the application server. Thenafter receiving a 200 O.K. from the media server, a 200 O.K. is sent from the application serverto the user agent.To the response of the 200 O.K. from the application server, an ACK is sent to the applicationserver. Then after receiving the ACK from the user agent, the application server sends an ACK tothe media server. Immediately, after an ACK, an INFO message is sent from the applicationserver to the media server. At this point the first INFO message is sent from the applicationserver to the media server. This INFO message contains the MSML+MOML body, which can beseen in the figure 3.4.1, chapter 3.4. After sending the INFO message, a 200 O.K. is receivedfrom the media server. A peer to peer connection between the user agent and the media server isestablished for the RTP.
Major Project: Play & Record with Dtmf Service based on JSLEE 16The second INFO message is sent, while the flow of RTP. This contains the second MSML bodyas shown in figure 3.4.1, chapter 3.4. To the response of the INFO message again a 200 O.K. issent to the Media Server. Figure 4.2 Message Sequence Chart of the implementation
Major Project: Play & Record with Dtmf Service based on JSLEE 17For the closing of the service, the user agent sends a BYE message to the application server. Theapplication sends a BYE message to the media server. The media server sends a 200 O.K. to theapplication server in response to the BYE message, the application server sends a 200 O.K. to theuser 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 asevents. 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 ServiceThis chapter of the report provides the detailed information about the service that has beendeveloped. The service depends upon the MSC described in chapter 4, figure 4.2. The followingdescription of the service will give a much clearer view of how the development is done on theJSLEE application server. In the initial part of this chapter, the basic fundamentals of the JSLEEarchitecture will be discussed and then the implementation of the service will be described. Tomake the development much more understandable, the description is divided into four importantsub chapters.1) Initial Service Preparation2) Establishing the Control Channel Dialog3) Consuming the Play & Record Service4) Service FunctionalityThe Play & Record service depends upon the six methods. These methods make it possible forthe application server to receive and send SIP messages from or to the user agent and also fromor to the Media server. Following are the six methods: OnStartService( ) OnSuccess( )
Major Project: Play & Record with Dtmf Service based on JSLEE 18 OnInvite( ) OnAck( ) OnInfo( ) OnBye( )The functionality of these methods will be explained while explaining the service.5.1 Initial Service PreparationThe initial service preparation provides the base for the service building block SBB, whichincludes the life cycle of the SBB and the invocation of the Sbb Context, which together providesthe basic functionality of the SBB of the JSLEE architecture. Figure 5.1.1: Invoking the used facilities in the JSLEE architectureIn 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
Major Project: Play & Record with Dtmf Service based on JSLEE 19ServiceActivityContextInterfaceFactory, the ActivityContextNamingFacility. Then, to use the SIPprotocol 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 IPaddress of the Call Server or the User Agent. Figure 5.1.2 initializing the required APIsIn figure 5.1.2, line 109, the abstract method for the service activity context is invoked, whichallows the SBB to co relate the service activity context in an abstract approach. From line 119 to
Major Project: Play & Record with Dtmf Service based on JSLEE 20144, the SbbContext method and the related APIs are invoked. The SLEE invokes this methodafter a new instance of the SBB abstract class is created. It uses this method to pass a SbbContextobject 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 theinitializing of the service activity context and the SIP API. Figure 5.1.3 the Life Cycle of the SBBEvery SBB goes through a lifecycle which is a conventional procedure and is followed by everySBB. In figure 5.1.3, line 166 to line 209 and figure 5.1.4, from line 216 to 233, the life cycle ofthe SBB is invoked, at various stages depending upon the state of the SBB, it is an internal part ofthe SBB, which makes it possible for the SBB to implement in a much more procedural way.
Major Project: Play & Record with Dtmf Service based on JSLEE 21 Figure 5.1.4 The Life cycle of the SBBAll these methods will be explained, in detail with respect to the service provided.5.2 Establishing the Control Channel DialogIn this chapter of the report, the creation of the control channel will be discussed. Before sendinga MSML + MOML, the control channel is to be created. The basic principle of developing acontrol channel is discussed in detail in chapter 3.4. In this implementation of the service, thecontrol channel is created in the OnStartService Method.OnStartService( ): This method is invoked to create the control channel between the applicationserver and the media server. In figure 5.2.1, from line 247 to 263, the header fields of the SIPINVITE message, which is to be sent, are created. All the header fields which are described inchapter 2 are used to create the SIP message. This will create the control channel between theapplication server and the media server.No media is used while creating the control channel. So, from line 267 to 273, the SDP with nom-parameter is created.
Major Project: Play & Record with Dtmf Service based on JSLEE 22 Figure 5.2.1 the onStartService Method: Creating the Control ChannelIn figure 5.2.1, from line 275 to 286, the request is created by invoking the sip provider; the sipprovider is a factory of functions by which we can create the header of the SIP protocol asdescribed in chapter 2. In line 289 and 290 in figure 5.2.2, the contact header is created. From
Major Project: Play & Record with Dtmf Service based on JSLEE 23line number 292 to 300, the client transaction is initiated and the SIP INVITE is sent. The activitycontext is invoked which allows the control channel dialog between the application server and themedia server (which is mentioned in the chapter 3.4) to execute. The dialog attaches to theactivity context.After sending the SIP INVITE to the media server, a 200 OK message is received to theapplication server, to complete the threeway hand shake for the control channel, an ACK has tobe 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
Major Project: Play & Record with Dtmf Service based on JSLEE 24 Figure 5.2.3 the onSuccess Method, Sends response to the media serverOnSuccess( ): In figure 5.2.3, from line 396 to 435, the ACK is sent to the media server tocomplete the three way handshake. The control channel dialog (line 412) is invoked and then theACK is sent to the control channel and the from address is to be added to the ACK (line 409).
Major Project: Play & Record with Dtmf Service based on JSLEE 255.3 Consuming the Play & Record ServiceIn this chapter of the report, the implementation of the service will be provided. After creating thecontrol 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 developmentof 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 theSubscriberdialog.The Subscriberdialog is a method in the code, which stores the dialog betweenthe UA and the AS. In figure 5.3.1, the setSubcriberDialog stores the dialog. It stores the dialogas an array list. This array list is also invoked in the activity context. Figure 5.3.1 storing the subscriber dialogThe dialog between the AS and the MS is stored in the MediaServerSubscriberdialaog( ). Thismethod can be seen in figure5.3.2, the dialog is again stored in an array list. This array list is alsoinvoked in the service activity context.
Major Project: Play & Record with Dtmf Service based on JSLEE 26 Figure 5.3.2 Storing the MediaServerSubscriberdialogBoth theses dialogs are linked to create the dialog between the UA and the MS. This dialog isstored in the linkeddialog( ). The method which provides the functionality to link the dialog canbe seen in figure 5.3.3, in this method the dialog is stored as a hash map, which is then invoked inthe activity context. Figure 5.3.3 string the linked dialogThese dialogs will be mentioned while explaining the service.After deploying the service, the control channel between the application server and the mediaserver is established. To use the service, the user agent sends an INVITE message to the AS bythe usage of the correct SIP URI. As soon as the INVITE message is sent to the application serverthe OnInvite Method is invoked.OnInvite( ): This method is invoked, when an INVITE message is sent by the user agent to theapplication server. This method is shown in figure 5.3.4, from line 441 to line 449, creates the
Major Project: Play & Record with Dtmf Service based on JSLEE 27URI which is to be used by the user to initiate the service. After receiving this INVITE messagefrom the user agent, the fields for expecting the ACK from the application server are set with inthe CMP field (i.e. Figure 5.3.4, from line 452 to 465). 5.3.4 onInvite Method, retrieves the invite from the user agentThe INVITE message is to be forwarded from the AS to the MS. So the next part of the methodprovides the functionality to forward the INVITE message from the AS to the MS. In figure5.3.5, from line 472 to 474, the dialog is invoked and then attached to the activity context. Thisdialog is stored as the subscriber dialog, shown on line 476. From figure 5.3.5, line 483 to figure5.3.6, line 525, the INVITE message is created, which is to be forwarded to the MS.
Major Project: Play & Record with Dtmf Service based on JSLEE 28Figure 5.3.5 onInvite method, forwarding the INVITE to the media server
Major Project: Play & Record with Dtmf Service based on JSLEE 29 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 theheader fields are included which makes the INVITE message. On line 525 the contact header iscreated by an independent method, this method can be seen in figure 5.3.7.
Major Project: Play & Record with Dtmf Service based on JSLEE 30 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 thenattaches the dialog to the activity context. The INVITE message is to be sent from the AS to theMS. On line 540 the MediaServerSubscriberDialog dialog is stored. This dialog is then stored tothe LinkedDialolgs( the link dialog provides the functionality to link the user subscriber dialogand 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.
Major Project: Play & Record with Dtmf Service based on JSLEE 31 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. Infigure 5.3.9, the dialog between the UA and the AS is invoked. This is set on line 390. The toHeader 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, line395. To send a 200 O.K. to the UA, the link to the user agent dialog is first initiated. This methodcan be seen in figure 5.3.9. This method is invoked on line 397. After getting this dialog theresponse as 200 O.K. is sent to the user agent.
Major Project: Play & Record with Dtmf Service based on JSLEE 32 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. Theto Header field should be the same when an ACK is to be sent to the User Agent. A hashmapping 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. Againthe hash mapping is created between the two required dialogs. This linked dialog is stored in theService Activity Context.5.4 Functionality of the ServiceIn this chapter of the report, the realization of the service will be described. The methods that areused to develop the functionality of the service will be described in detail. This service providesthe user to record and then play the recorded voice back to the user.
Major Project: Play & Record with Dtmf Service based on JSLEE 33Realization of the Play & Record Service:The realization of the service is done when the INFO message containing the MSML body is sentto the media server; this is described in chapter 3.4 and chapter 3.5 in detail. Figure 3.4.2 and3.4.3 on page 11, shows the example of the MSML+MOML document used to realize thisservice. This MSML body invokes the media server to send a response as a 200 O.K. to theapplication server. After receiving a 200 O.K. from the media server, a 200 O.K. is sent to theuser agent from the application server. This establishes a peer to peer connection between theuser agent and the media server. RTP flows between the user agent and the media server. Duringthe RTP flow, the user can record his or her, own voice and then play the same voice back assoon 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 mediaserver. When a user presses the button 1 on his or her SIP based soft phone, an INFO message issent which contains the MSML body as mentioned in chapter 3.4 and chapter 3.5 to realise theDTMF functionality.In this implementation, when the user presses the button on the SIP based soft phone, the userwill 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.
Major Project: Play & Record with Dtmf Service based on JSLEE 34 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 themedia server. Immediately after sending the ACK, the INFO message is sent to the media serverwhich contains the MSML body.Figure 5.4.2, on line 570, the Sip Provider is invoked. The Sip provider is invoked to create theaddress field from the address factory. From line 573 to 580, the significant dialogs and theheader 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 184.108.40.206) The subscriber dialog is invoked and linked to the media server dialog (Line 576). This is invoked from the method described in figure 220.127.116.11) The stored to header field dialog of the subscriber is invoked (Line 577).This dialog field is invoked from the method described in figure 18.104.22.168) The cseq field for the control channel is retrieved (Line 578). This is invoked from the method described in figure 5.4.8.
Major Project: Play & Record with Dtmf Service based on JSLEE 357) 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, theINFO message is created. While sending the MSML body in the INFO message, the tag fieldshould remain the same. So, on line 591, the tag field is retrieved and then the MSML body issent in the INFO message to media server. On line 619, the contact header field for the Mediaserver is created. This is invoked from the method mentioned in figure 5.4.9.
Major Project: Play & Record with Dtmf Service based on JSLEE 36 Figure 5.4.4, The Control Channel Dialog.Figure, 5.4.4, the control channel dialog is stored. This method again uses the hash mappingbetween 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 byusing 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 usesthe hash mapping between the dialog and the to header.
Major Project: Play & Record with Dtmf Service based on JSLEE 37 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 whilegetting the Cseq value of the Message related to the dialog. It is again stored by using the hashmapping 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 isstored. The Cseq value which is retrieved is incremented and then set, this can be seen in figure5.4.2, line 579.
Major Project: Play & Record with Dtmf Service based on JSLEE 38 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 mediaserver is created. This method contains the mentions the UDP, which is to be used when sendingthe ACK and also the created address “Mobicents SIP AS <sip:as@”. This is actually seen whensniffing the network between the AS and the MS while using wireshark. After knowing thisspecial field, it is used in the code.
Major Project: Play & Record with Dtmf Service based on JSLEE 39 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 theDTMF service is initially retrieved from the onInfo method. This digit is parsed to use it as aninteger 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 issent to the media server. This is shown in figure 5.4.11.
Major Project: Play & Record with Dtmf Service based on JSLEE 40 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 theservice.
Major Project: Play & Record with Dtmf Service based on JSLEE 41 Figure 5.4.12, the onBye Method.OnBye( ): This method is invoked when a BYE message is sent by the user agent to theapplication 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 applicationserver, the dialog between the application server and the media server are detach from the activitycontext, the user is also removed from the control channel. This is shown in figure 5.4.12, fromline 985 to figure 5.4.13, line 1020.
Major Project: Play & Record with Dtmf Service based on JSLEE 42 Figure 5.4.13, shows the complete onbye method of the service.5.5 Development and Integration of the LibraryIn this chapter of the report the development of the library and the integration of the library to theservice will be discussed.The Msml body discussed in chapter 3.4 can be integrated to a service by developing anindependent library. This library will consist of all the methods and functions. These methods canbe invoked while developing a service. In this chapter of the report, some parts of the developedlibrary will be discussed and also the integration of this library to the service will also bedescribed.
Major Project: Play & Record with Dtmf Service based on JSLEE 43The MSML and the MOML are XML schema files which are stored within the CMS-3000server. These Schema files can be parsed to generate java objects. There are many ways ofparsing the xml schema. The technique that has been used in the development is the JAXB (JavaArchitecture for XML Binding). JAXB is basically a parsing technique to convert xml to javaobjects and vice versa. Figure 5.5.1, shows the implementation of the JAXB technique. In thefigure it can be seen that the XML Schema is compiled by using a Binding compiler to generatethe required schema derived classes and interfaces. 5.5.1 JAXB API Technique .The JAXB API in the figure 5.5.1 provides the functionality to use the marshalling andunmarshalling techniques. Unmarshalling an XML document means creating a tree of contentobjects that represents the content and organization of the document. Marshalling is the oppositeof unmarshalling. It creates an XML document from a content tree. 
Major Project: Play & Record with Dtmf Service based on JSLEE 44 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 objectswill be used to create the MSML in the service. The important generated class which is used inthe service is the MSML class. This is shown in the figure 5.5.2. In this figure all the requiredMSML based java objects are created.
Major Project: Play & Record with Dtmf Service based on JSLEE 45 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 thegenerated java objects is used in the library.In the implementation, the XML schema is compiled to generate schema derived classes andinterfaces which are shown in figure 5.5.3 and figure 5.5.2. These classes and interfaces are thenmarshaled to generate the required XML document. In the implementation the XML document is
Major Project: Play & Record with Dtmf Service based on JSLEE 46the MSML document. In figure 5.5.4, line 30 to line number 48, the required package are invokein the code by using these packages the JAXB and the marshalling technique can be used togenerate 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 beconverted into XML documents.
Major Project: Play & Record with Dtmf Service based on JSLEE 47 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 ConvediaMedia Sever. This method is a part of the Library. The Library is integrated to the service as areferenced JAR (Java Archive). A referenced JAR is a bundle of packages, classes and objectswhich can be used while developing a code.
Major Project: Play & Record with Dtmf Service based on JSLEE 48 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 line420, The Marshaller API is invoked which makes it possible for the java objects to be convertedto a xml document or msml document.
Major Project: Play & Record with Dtmf Service based on JSLEE 49 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. Thismethod 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 usedattributes is for the DTMF service.
Major Project: Play & Record with Dtmf Service based on JSLEE 50In figure 5.5.8, the method for the record service is developed. This method includes the requiredattributes to initiate the record service. Figure 5.5.8, The MSML Creator for the play and record service.
Major Project: Play & Record with Dtmf Service based on JSLEE 51 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 theplay and record service is invoked. When this class is invoked the tag field is used to link theMSML body to the required dialog of the service. The tag is the common value which links theINFO message while sending the MSML body. The tag can be determined while sniffing theapplication 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 themethod is invoked to create the Msml instead of including the Msml + xml document.
Major Project: Play & Record with Dtmf Service based on JSLEE 526. ConclusionThe development of the Play & Record Service with the DTMF functionality makes it possiblefor 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 bedeveloped based on this implementation. One interesting future extension to this service can be touse DTMF functionality to control the Energy Harvesting Devices. Based on figure 6.1, the SIPbased end user can use the DTMF functionality based on the CMS- 3000 server and then utilizethis functionality to control the EnOcean Devices. Figure 6.1 Future extension of the service
Major Project: Play & Record with Dtmf Service based on JSLEE 537. References Ivelin Ivanov : Mobicents JSLEE for the People, by the People issued on March 14, 2006available at http://today.java.net/pub/a/today/2006/03/09/mobicents-jslee.html. JAIN SLEE (JSLEE) 1.1 Specification, Final Release, issued in the year 2008, available athttp://jcp.org/aboutJava/communityprocess/final/jsr240/index.html. CONVEDIA MEDIA SERVER: MSML 1.1 INTERFACE REFERENCE issued dateDecember 2009, RELEASE 4.19. CONVEDIA MEDIA SERVER: MOML 1.0 INTERFACE REFERENCE issued date onDecember 2009, RELEASE 4.19. Prof. Dr.- Ing. Ulrich Trick: Methods, Systems and Networks for Digital Communication,Lecture on Next Generation Networks, Voice over IP and SIP. Ed Ort and Bhakti Mehta: Java Architecture for XML Binding (JAXB) issued on March2003 available at http://www.oracle.com/technetwork/articles/javase/index-140168.html