phonerecord - record and monitor voip solution · keywords voip, record, java, jtapi, jmf, .net,...

Universidade de AveiroDepartamento deElectronica, Telecomunicacoes e Informatica,

2008

PedroAlbuquerque<[email protected]>

PhoneRecord

Solucao de Gravacao e Monitorizacao VoIP

PhoneRecord

Record and Monitor VoIP Solution

Universidade de AveiroDepartamento deElectronica, Telecomunicacoes e Informatica,

2008

PedroAlbuquerque<[email protected]>

PhoneRecord

Solucao de Gravacao e Monitorizacao VoIP

PhoneRecord

Record and Monitor VoIP Solution

Final report presented to the University of Aveiro in partial fulfillment of the re-

quirements for the degree of Master of Science in Engineering of Electronics and

Telecommunications, developed under cientific orientation of Antonio Nogueira and

Paulo Salvador, professors of the Department of Electronics, Telecommunications

and Informatics in the University of Aveiro.

o juri / the jury

presidente / president Doutor Armando Jose Formoso de PinhoProfessor Associado da Universidade de Aveiro (por delegacao da Reitora da Uni-

versidade de Aveiro)

vogais / examiners committee Doutor Joel Jose Puga Coelho RodriguesProfessor Auxiliar do Departamento de Informatica da Faculdade de Ciencias da

Engenharia da Universidade da Beira Interior

Doutor Antonio Manuel Duarte NogueiraProfessor Auxiliar da Universidade de Aveiro (Orientador)

Doutor Paulo Jorge Salvador Serra FerreiraProfessor Auxiliar da Universidade de Aveiro (Co-Orientador)

People envolved

Supervisor Prof. Antonio Manuel Duarte NogueiraAuxiliar Professor of the University of Aveiro

Co-Supervisor Prof. Paulo Jorge Salvador Serra FerreiraInvited Auxiliar Professor of the University of Aveiro

Collaborators Dr. Pedro J. Conceicao BeloCEO of Millennium bcpbank

Dr. Manuel Moura GuedesSenior Vice-President of Millennium bcpbank IT department

Eng. Sergio AlonsoSenior Vice-President of Millennium bcpbank IT department

Eng. Pedro Rafael de Jesus SoaresConsultor in Millennium bcpbank IT department

Eng. Pedro dos Reis MendesAssistant Vice-President of Millennium bcpbank IT department

“All successful people are big dreamers.They imagine what their future could be, ideal in every re-spect, and then they work every day toward their distantvision, that goal or purpose.”

— Brian Tracy

acknowledgements In first place, I’d like to thank my supervisors for accepting this project andfor all the support given during its development.A special thank to Pedro Belo, for giving me the opportunity to work atMillennium bcp bank and for all the back up given while stayed abroad.To Manuel Moura Guedes, Sergio Alonso, Pedro Mendes and Pedro Soares,a sincerest thanks for the day-by-day scientific support and for their friend-ship.To my friends who always helped me in good and not so good times. Also, Idedicate this project to my grandparents, specially to my dear grandmotherAvo Olga.Finally, I devote this project to the most important persons in my life, myfamily. To my parents and my brother, thank you. Without you, I wouldn’tbe what I am today - you are what matter most. I’m really thankful. Toall, my sincerest thanks.

Palavras-chave VoIP, Gravacao, Java, JTAPI, JMF, .NET, CallManager, Cisco, Conferencia

Resumo Esta dissertacao apresenta o estudo para a gravacao e monitorizacao dechamadas VoIP. A solucao PhoneRecord funciona junto com o CallManagerda Cisco e faz uso de Java Telephony Application Programming Interface(JTAPI) na gestao de chamadas e da framework Java Media Framework(JMF) para o processamento de audio. O acesso as configuracoes do sistemae a lista das chamadas gravadas e conseguido atraves de um browser web.

Keywords VoIP, Record, Java, JTAPI, JMF, .NET, CallManager, Cisco, Conference

Abstract This dissertation presents the study to record and monitor VoIP calls. ThePhoneRecord solution works along with Cisco CallManager and makes useof JTAPI to manage calls and JMF to process audio. The access to systemconfiguration and recorded calls list is achieved through a web browser.

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Law terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Document Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 State-of-Art 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 CallRex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 PowerCall CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Confiance Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 THAT-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 Witness Compliance Recording . . . . . . . . . . . . . . . . . . . . . . . . . . 72.7 Voxida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 VoIP 113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Audio Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Network Environment 174.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Call Manager Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2.1 CallManager Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Media Termination Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.1 CTI Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3.2 CTI Route Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 IP Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 Conference Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Development Tools 235.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.1 Eclispe IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

pedro.albuquerque i

5.2.2 JTAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2.3 JTAPI Security . . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2.3 JMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2.3.1 Streaming Media . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.3.2 Receiving Media Streams from the Network . . . . . . . . . . 285.2.3.3 Transmitting Media Streams through the Network . . . . . . 28

5.2.4 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3 .NET Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.3.1 Microsoft Visual Studio 2005 . . . . . . . . . . . . . . . . . . . . . . . 295.3.2 C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4.1 Microsoft SQL Server 2005 . . . . . . . . . . . . . . . . . . . . . . . . 315.4.2 Microsoft SQL Server Management Studio . . . . . . . . . . . . . . . . 31

6 PhoneRecord - Project Development 336.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Architecture Overview: different approaches . . . . . . . . . . . . . . . . . . . 33

6.2.1 Passive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2.1.1 Packet Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2.2 Active Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.2.1 Cisco Unity integration . . . . . . . . . . . . . . . . . . . . . 346.2.2.2 Program-based implementation . . . . . . . . . . . . . . . . . 35

6.3 Architecture Overview: final solution . . . . . . . . . . . . . . . . . . . . . . . 356.3.1 JTAPI component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3.2 JMF component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.4 Data Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.5 WEB Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.6 Results and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Conclusions and Future Applications 53

Bibliography 55

A Application Profile 57

B Installation Manual 61

C Administration Web Page 72

ii

List of Figures

2.1 CallRex scability [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Confiance user interface [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 THAT-2 Telephone Handset Audio TAP [15] . . . . . . . . . . . . . . . . . . 72.4 Voxida server [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Solutions comparison chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 VoIP concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 VoIP protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Production Network Environment . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Treasury Department Environment . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Cisco IP Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.4 Route Point functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 JTAPI and CallManager communication . . . . . . . . . . . . . . . . . . . . . 255.2 JTAPI - Call model for two-party call . . . . . . . . . . . . . . . . . . . . . . 265.3 JTAPI - Call model for two simultaneous calls . . . . . . . . . . . . . . . . . 265.4 JTAPI - Call model for two alerting terminals . . . . . . . . . . . . . . . . . . 275.5 JTAPI - Call model for conference call . . . . . . . . . . . . . . . . . . . . . . 275.6 JMF - RTP reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.7 JMF - RTP transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.8 JDBC Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.9 .NET Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1 Test Network Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2 JTAPI and JMF components . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 JTAPI - registerProvider() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.4 JTAPI - processMessage() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.5 JTAPI - Create structure and updatePortsStatus() . . . . . . . . . . . . . . . 376.6 JTAPI - registerRouteTerminal() . . . . . . . . . . . . . . . . . . . . . . . . . 386.7 JTAPI - Thread List run() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.8 JTAPI - recordCall() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.9 JTAPI - CiscoMediaOpenLogicalChannelEv . . . . . . . . . . . . . . . . . . . 396.10 JTAPI - CiscoRTPInputStartedEv . . . . . . . . . . . . . . . . . . . . . . . . 396.11 JTAPI - CiscoRTPOutputStartedEv . . . . . . . . . . . . . . . . . . . . . . . 396.12 Codec File Size Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.13 µ-law and a-law Comparison [16] . . . . . . . . . . . . . . . . . . . . . . . . . 406.14 JMF - startSaving() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

pedro.albuquerque iii

6.15 JMF - startTransmitting() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.16 JMF - stopTransmitting() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.17 JMF - stopSaving() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.18 Servers and DataBase schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.19 Web Page - Check Login in Page Load . . . . . . . . . . . . . . . . . . . . . . 476.20 Iframe JavaScript Management . . . . . . . . . . . . . . . . . . . . . . . . . . 476.21 Update voice&media server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.22 Executing usp searchCall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.23 Codec G.711 - Practical and Theorical Comparison . . . . . . . . . . . . . . . 516.24 Final Solution Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B.1 Software’s Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61B.2 CallManager - Change codec in R-CTI Region . . . . . . . . . . . . . . . . . 65B.3 CallManager - Configure a location . . . . . . . . . . . . . . . . . . . . . . . . 66B.4 CallManager - Configure a partition . . . . . . . . . . . . . . . . . . . . . . . 66B.5 CallManager - Configure a device pool . . . . . . . . . . . . . . . . . . . . . . 67B.6 CallManager - Configure a DP in phone settings . . . . . . . . . . . . . . . . 68B.7 CallManager - Configure a Route Point . . . . . . . . . . . . . . . . . . . . . 69B.8 CallManager - Configure an extension to Route Point (1) . . . . . . . . . . . 70B.9 CallManager - Configure an extension to Route Point (2) . . . . . . . . . . . 71

C.1 Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72C.2 Main Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73C.3 Device List Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73C.4 Initial Parameters Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74C.5 Search Call Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

iv

List of Tables

3.1 Codecs Information [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Bandwidth Calculations [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6.1 Codec G.711 Practical and Theoretical values . . . . . . . . . . . . . . . . . . 49

A.1 PhoneRecord - components description . . . . . . . . . . . . . . . . . . . . . . 57A.2 PhoneRecord - functional specifications . . . . . . . . . . . . . . . . . . . . . 58A.3 RecordPhone components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

pedro.albuquerque v

Acronyms

ACD automatic call distributor.ACELP Algebraic Code Excited Linear Prediction.ADPCM Adaptative Differential Pulse-Code Modulation.API application programming interface.

BAT Bulk Administration Tool.

CDR Call Detail Record.CTI computer telephony integration.CTIQBE Computer Telephone Interface Quick Buffer Encoding.

FTP File Transfer Protocol.

HTTP Hypertext Transfer Protocol.

IDE Integrated Development Environment.IIS Internet Information Services.IP Internet Protocol.IVR interactive voice response.

JDBC Java Database Connectivity.JMF Java Media Framework.JS2E Java Server Second Edition.JTAPI Java Telephony Application Programming Interface.JVM Java Virtual Machine.

LAN local area network.LD-CELP Low Delay Code Excited Linear Prediction.

MAC medium access control layer.MOS Mean Opinion Score.MP-MLQ Multi-Pulse Maximum Likelihood Quantization.MPEG-1 Moving Picture Experts Group Phase 1.

pedro.albuquerque vii

NPS non presential sales.

OS Operating System.

PBX Private Branch eXchange.PC Personal Computer.PCM Pulse-Code Modulation.PPS Packets per Second.PSTN Public Switched Telephone Network.

QoS quality of service.

RAD rapid allocation development.RMI remote method interface.RTCP Real-Time Transport Control Protocol.RTMT Real-Time Monitoring Tool.RTP Real-Time Transport Protocol.

SCCP Skinny Client Control Protocol.SDK Software Developer’s Kit.SIP Session Initiation Protocol.SQL Structured Query Language.

T-SQL Transact Structured Query Language.TAPI Telephony API.TAPS Tool for Auto-Registered Phone Support.TCP Tansmission Control Protocol.

UDP User Datagram Protocol.

VLR Voice Logging Recorders.VoIP Voice over Internet Protocol.

WAVE Waveform audio format.

XML eXtensible markup language.

viii

Chapter 1

Introduction

1.1 Motivation

The global wide spread growth of telecommunications networks, Internet Industry andestablished telecommunications industry has increased the interest and demand on differentapplications. Voice over Internet Protocol (VoIP) reveals itself as an important revolutionarytechnology which has become a potential alternative to the traditional telephony systems overthe Public Switched Telephone Network (PSTN), providing a versatile and flexible solutionto speech communications.

In a VoIP call, voice is transformed into digital bits and segmented into packets of datato be routed through the Internet Protocol (IP) network, being reassembled upon arrival atthe other end. Actually, there is no actual sound passing through the network at any timebecause the Personal Computer (PC) or other device which places the VoIP call digitizesvoice sound. PSTN traffic is also segmented into digital packets at some point, but such callsare digitized and then converted into sound waves far deeper into the telephone system [24].

The first computer to computer voice connection was made in 1995, developed into a newInternet Phone Software software package. The hardware needed to talk to another computerwas a modem, sound card, microphone and speakers.

This technology is being developed since then and, by year 1998, gateways had beenestablished to allow PC-to-phone connections and phone-to-phone connections that used theInternet for voice transmission. These last connections still required a computer to initiatethe call, but once the connection was established, the callers could use a regular phone set [5].

Nowadays, moving from analog lines to VoIP seems inevitable and so telephone applica-tions too. Call recording, still currently used in analog call centers, needs to migrate also toVoIP in order to be integrated into digital systems.

Recordings calls are very important when a telephone conversation involves agreements ofhigh amounts of money, buy or selling orders, evaluation and verification, dispute resolutionor even provision information with customers.

Both business and its customers are increasing the use of phone calls to a wide rangeof agreements. But when one party breaks the agreement, the calls may have a key role inresolving disputes, even in courts. When this happens, it is obviously far easier to resolvematters if the company has recorded calls, or followed them up with a clear and agreed writtenstatement of what was discussed.

pedro.albuquerque 1

1.2 Objectives

This dissertation is about developing and implementing a system that is capable of recordand monitor calls in VoIP phones within Millennium bcpbank Treasury Department network.The project, called “PhoneRecord”, was born as a solution to meet the proposal requirementsof Millennium bcpbank to control the deals made by the Treasury Department and to bepossible to make non presential sales (NPS) with costumers. If needed, the Call Center canalso use this solution. The developed system is capable of recording a call automatically(without pressing any button), permits the pre-selection of extensions to be recorded andalso restricts the access to system boot configuration and database where the files and theprofiles of the recorded calls are located. This solution doesn’t want to rival with existingsniffing packets and high-processing conference-based systems, but to create a solution wherethere is no need to record a high number of phone calls. Another objective, as importantas the first one, is to obtain the academic Master degree of Engineering of Electronic andTelecommunications.

1.3 Law terms

There are important law issues that must be addressed. Both federal and state statutesgovern the use of electronic recording equipment. The unlawful use of such equipment cangive rise not only to a civil suit by the ”injured” party, but also to criminal prosecution. TheU.S. federal law allows recording of phone calls with the consent of at least one party. Thismeans that if the call is being initiated, the other party does not need to be notified that thecall is being recorded.

Twelve states require the consent of all parties to a conversation. Those jurisdictionsare California, Connecticut, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana,Nevada, New Hampshire, Pennsylvania and Washington. Since Treasury should not be re-stricted to deal in specific states because of call recording, it was looked for a solution thatcan accommodate the bank’s needs as well as legal requirements [2].

Prior to recording, it is needed to notify that a call is going to be recorded. This is generallyaccomplished with a verbal notification by the recording party or an automatic, periodic beeptone, indicating that the call is about to be recorded and, while recording, indicating thatrecording is taking place. There are specific requirements for this tone. According to VoiceLogging Recorders (VLR) Communications, the beep tone needs to be a 1260 to 1540Hztone, lasting 170 to 250 milliseconds, and broadcast for both sides to hear every twelve tofifteen seconds when the call is taking place.

2

1.4 Document Outline

This report is divided into six chapters. The following will be a small exhibition of whatwill be mentioned throughout each chapter:

Chapter 1 − This chapter presents an introduction to the project, as well as the lawrequirements to validate the way calls are being recorded. It also includesthe document structure to turn its search easier.

Chapter 2 − State of the Art: This chapter shows the study of the State of the Artrelated to the Record and Monitor VoIP application.

Chapter 3 − VoIP: This chapter presents the VoIP protocol, describing its concepts andtechnology used.

Chapter 4 − Network Environment: This chapter presents the production networkwhere the solution has to be implemented.

Chapter 5 − Development Tools: This chapter presents all the tools that were usedto develop the proposed solution, as well as the network components andenvironments.

Chapter 6 − PhoneRecord, Project Development: In this chapter, the different pathsthat were taken to reach the final solution are presented. It also explainshow the system works.

Chapter 7 − Conclusions and Future Applications: This chapter presents the main con-clusions about the developed solution and some of its possible future ap-plications.

3

Chapter 2

State-of-Art

2.1 Introduction

Since the arrival of VoIP, many companies have developed and are still developing differentapproaches to record and monitor VoIP calls. Almost all of them are based in packet sniffing,where they can capture each packet, decode it and analyze it without modifying its content.There is another way to record calls, which is saving Real-Time Protocol media into a soundfile. This approach is capable of deciding which streams are received and saved. However,when companies are dealing with costumers, there are some mandatory issues in the waycalls are recorded. Most of the existing solutions don’t have the “automatic record” service,the “beep tone” or the initial message, informing the call participants that the call is beingrecorded. The next sections will briefly present some of the existing solutions.

2.2 CallRex

CallRex, from TelRex, monitors VoIP by port mirroring every packet transmitted on thedata switch connected to the IP Private Branch eXchange (PBX), then copies them to theCallRex Server which then reassembles all the packets into recorded calls, compresses andstores them for later retrieval. This server works with almost all of the most-known digitalPBX, like 3Com NBX, Cisco CallManager, Mitel ICP, Nortel BCM, Artisoft Televantage,Avaya IP Office, Siemens HighPath, NEC NEAX, Shortel Shorewave, and Zultsys MX250.This solution also provides an application programming interface (API) to work with VoIP-based call center applications, enabling real-time computer monitoring (figure 2.1). ThisCallRex solution is already implemented in The U.S. Tire & Exhaust division of U.S. OilCo., Inc. They wanted to bring better control to dispute resolution at its Customer ServiceCenter, which handles some 4, 000 customer calls a day. Customer Service Center associateshave been able to resolve disputed calls by retrieving a recording of the conversation that theycan send to the customer as a simple e-mail attachment( [17]). However, this solution doesnot meet one of the requirements which is to send a “beep” sound every 12 seconds or evento play an initial message, notifying all the participants that the call will be recorded. Also,as CallRex is not java based, it cannot be implemented in other platforms with the exceptionof Windows OS. Besides this, a license must be bought for each phone, resulting in a veryexpensive solution [8].

pedro.albuquerque 5

Figure 2.1: CallRex scability [8]

2.3 PowerCall CRM

This solution is a package of a computer telephony integration (CTI) server and a clientapplication, which is possible to record all the calls occured in pre-selected IP phones andquery the database to get information about the calls’ profiles. It is possible to email the files,task, reminders and schedule appointments. In spite of this, this solution has the CallRex’slimitations and needs to be installed in every PC [14].

2.4 Confiance Recorder

A Confiance IP Solution, this VoIP software is a client application which registers witha specific IP Phone and is installed in every client PC. It registers with any digital PBXin order to control the phone from the PC desktop. However, each client has access to therecorded calls folder and can erase them (figure 2.2). However, this solution also doesn’t havethe possibility to inform each call participant with a “beep” tone neither includes any initialmessage.

Figure 2.2: Confiance user interface [6]

6

2.5 THAT-2

THAT-2 (Telephone Handset Audio Tap) is a hardware solution to be connected betweentelephone and handset for quick access to audio in and out of the telephone (figure 2.3). TheTHAT-2 is used by radio stations to record and play sound bytes, by computer and telephonecompanies to show their computer voice services using a powered speaker. The THAT-2,which is a passive handset interface with professional and consumer jacks, separates inputand output volume control, has a selector switch for the different types of telephone systemsand no batteries or AC are needed [15]. But, as all the previous solutions, it is possible forthe client to unplug the hardware. Also, an audio connector is needed for each phone and it’sa very expensive solution, rounding $225 for only one THAT.

Figure 2.3: THAT-2 Telephone Handset Audio TAP [15]

2.6 Witness Compliance Recording

This solution provided by Witness Systems is capable of capturing, indexing and retriev-ing customer/caller interactions in both traditional and IP Telephony environments. Thecaptured phone conversation can then be sent by e-mail or searched and retrieved using avariety of selection criteria. Authorized users across the enterprise can use a browser-basedsolution to retrieve and replay interactions using search options [4]. Although this solutionis powerful, a hardware installation is needed and there is no notification when recordingfunction is being performed.

2.7 Voxida

Accurate Always built the Voxida call recording and quality monitoring solutions to recorddigital PBX, analog telephone, video and radio communications (figure 2.4). Voxida solutionsoffer simultaneous call recording and playback for long term data-integrity and instant recallof a particular call or transmission. Audio stream and real-time monitor components integratewith the IP network, enabling also full remote access on this client/server platform. Also,

7

Voxida’s voice logging solutions provide an optional beep tone, to notify callers that the callis being recorded. It is a suitable solution for high traffic systems where call recording andmonitoring in customer contact centers is critical [7]. However, this solution is very expensivefor the bank’s requirements, which needs only few phones to be recorded.

Figure 2.4: Voxida server [7]

2.8 Conclusions

After a market study for solutions capable of meeting the bank’s needs, there was a needto develop a personalized tool without high implementation costs. This decision was basedon six reviewed products, analyzing and balancing its operation characteristics. All solutionsachieve the central objective of this thesis, which is call recording, but only one (Voxida)answers to all requirement points for the intended implementation. Besides, costs/needs ratiois very high, so this solution is very expensive (needs a hardware implementation) for thebank’s needs. Figure 2.5 shows the relation between the analised solutions and the solutionthat will be developed in order to answer the three key requirements that were presented bythe bank.

8

Figure 2.5: Solutions comparison chart

9

Chapter 3

VoIP

3.1 Introduction

In terms of flexibility, cost, variety of products and services, networks and solutions forcommunication (voice, data and images) based on packet switching and IP protocol are be-coming increasingly competitive when compared to traditional offerings like TDM, FrameRelay or ATM. There is a growing demand for both simple access to services for virtual pri-vate networks (IP VPNs) carrying voice, data and images. VoIP is a packet switched network,the most recent step of telephony evolution. It transports Voice over Internet Protocol pack-ets through an IP network. Each packet may travel with a different route in the transportnetwork, as there is no single reserved path. As a consequence of the underlying unreliableprotocol (User Datagram Protocol (UDP)), packets arriving at the destination may come ina different sequence than they were sent and there is no guaranteed bandwidth. Originally,VoIP was supposed to provide only PSTN, like voice calls, faxes or mailboxes. However, thetransmission of voice over IP networks presented several additional possibilities.

3.2 Concepts

The architecture of Internet Telephony is identical to old fashioned telephone networks inmany ways, but it also has some significant differences. Fundamentally, internet telephonyruns over IP networks. The most significant consequence of having this underlying network isthat is provides transparent connectivity between any devices on the network, independentlyof the location. Whereas devices in traditional networks are restricted by communicatingwith those devices to which they are directly connected, internet telephony can rely on anunderlying infrastructure which provides these capabilities automatically.

There are four basic elements of a VoIP system ( 3.1):

• terminal - communication endpoint where a call is terminated. It is where the end userresides and some automatic interaction is also possible (voicemail). It can be softwareor hardware based.

• server - system’s central point. Terminals are registered here and their information(location, IP) is stored. It provides routing mechanisms for the call and sets up authen-tication and performing for accounting operations.

pedro.albuquerque 11

• gateway - border element of a VoIP network. It provides inter-operability between IPand PSTN networks.

• conference bridge - provides functionality for multi-point communication. It is sep-arated from the server, as it demands high resource requirements.

In order for VoIP to work, those devices have to interact with each other in many ways.Initially, at the source, analog input (voice) is converted into digital signals, occuring a speechcompression. Pulse-Code Modulation (PCM) is the digital representation of that analog signalwhere the magnitude of the signal is sampled regularly at uniform intervals, then quantizedto a series of symbols in a numeric (usually binary) code. After converting voice packets,Real-Time Transport Protocol (RTP) is used for time stamping and content indentificationof UDP voice packets. Then, after negotiating all initial settings for transmitting, the packetsare sent. However, this becomes more complex if the signaling system has to communicatewith the gateway that is located between the Internet and PSTN. In case of outgoing calls, theVoIP phone captures the phone number and the IP address of the gateway. For incoming calls,the gateway has associated a telephone number with the device’s IP address and forwards thecalls to it. Finally, at the receiving end, packets have to be disassembled for data extractionin order to put the voice data into the device’s sound card.

Figure 3.1: VoIP concepts

3.3 Protocols

The Internet telephony services are built in an hierarchy of packet switching protocols(figure 3.2), where signalling protocols includes resource reservation, call acceptance, ad-dress translation, call establishment, call management and billing. These signalling protocols

12

are H.323 and Session Initiation Protocol (SIP). Transmitting media data across the net inreal-time requires high network bandwidth. It’s easier to compensate for lost data than tocompensate for large delays in data reception. Data transmitted goes through the networkas datagrams, where every datagram has a source address, destination address and sequencenumber. Each datagram is independently routed across the network and they are reassem-bled at the receiving end. Consequently, the protocols used for static data don’t work well forstreaming media. The Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP)protocols are based on Tansmission Control Protocol (TCP). TCP is a transport-layer pro-tocol designed for reliable data communications on low-bandwidth, high-error-rate networks.When a packet is lost or corrupted, it’s retransmitted. Also, TCP protocol is responsible toturn signalling protocols reliable, where call features performance must be trustable. For voicetransmitting, the IP network uses the UDP protocol, where the packet transmission is notreliable. The option for this protocol lays in the fact that in voice transmission, it would bevery confusing if the packets had to be re-transmitted and acknowledgements would consumemore network bandwidth. So, reliable protocols are not suitable in voice issues because theircontrol mechanisms add transmission delays and voice would not be perceived. For thesereasons, underlying protocols different from TCP are typically used for streaming media.Usually, the UDP protocol is used. UDP is unreliable, it does not guarantee that the packetswill arrive in the order that they where sent. The receiver has to be able to compensatefor lost data, duplicate packets and packets that arrive out of order. If UDP was a reliableprotocol, the audio in a VoIP call would be retransmitted in packet-loss situations, confusingall call participants. Like TCP, UDP is a general transport-layer protocol - a lower-levelnetworking protocol on which more applications or specific protocols are built. RTP is oneexample of those protocols built over UDP. It provides end-to-end network delivery servicesfor transmission of real-time data. RTP can be used over both unicast and multicast networkservices. Over a unicast service, separate copies of the data are sent from the source to eachdestination. Over a multicast network service, the data is sent from the source only onceand the network is responsible for transmitting the data to multiple locations, such as videoconferences [32]. While RTP does not provide any mechanism to ensure timely delivery orprovide other quality of service guarantees, it is augmented by Real-Time Transport ControlProtocol (RTCP) that enables control and identification mechanisms for RTP transmissions.

3.4 Audio Codecs

An audio codec is a computer program that compresses or decompresses digital audiodata according to a given audio file format or streaming audio format. The term codec isa combination of ’coder-decoder’ where its object of a codec algorithm is to represent thehigh-fidelity audio signal with minimum number of bits while retaining the quality. Thiscan effectively reduce the storage space and the bandwidth required for transmission of thestored audio file [9]. Some of the audio codecs used in telephony are shown in the tables 3.1and 3.2. These codecs use many types of encoding algorithms, which will encode the dig-ital signal for transmission, in order to save bandwidth, like PCM, Adaptative DifferentialPulse-Code Modulation (ADPCM), Low Delay Code Excited Linear Prediction (LD-CELP),glscsacelp, Multi-Pulse Maximum Likelihood Quantization (MP-MLQ) and Algebraic CodeExcited Linear Prediction (ACELP).

In tables 3.1 and 3.2, some terms are used to describe a codec:

13

Figure 3.2: VoIP protocol stack

Name Bitrate(Kbps)

Codec SampleSize(Bytes)

Encoding Al-gorithm

Delay(ms) Mean OpinionScore (MOS)

G.711 64 80 PCM 0.75 4.1G.723 6.3 24 MP-MLQ 30 3.9G.726 32 20 ADPCM 1 3.85G.728 16 10 LD-CELP 3 3.61G.729 8 10 CS-ACELP 10 3.92

Table 3.1: Codecs Information [22]

• Codec Bit Rate (Kbps) - Number of bits per second that need to be transmitted todeliver a voice call.

• Codec Sample Size (Bytes) - Number of bytes in each codec sample interval.

• MOS - A system of grading the voice quality of telephone connections. With MOS, awide range of listeners judge the quality of a voice sample on a scale of one (bad) tofive (excellent). The scores are averaged to provide the MOS for the codec.

• Voice Payload Size (Bytes) - The voice payload size represents the number of bytes (orbits) that are filled into a packet. The voice payload size must be a multiple of thecodec sample size.

• PPS - represents the number of packets that need to be transmitted every second inorder to deliver the codec bit rate.

3.5 QoS

Providing a level of quality that, at least, equals to the conventional telephony is seen asa basic requirement. The quality of service (QoS) refers to voice loyalty, network availability

14

Name Voice Payload(Bytes)

Voice Payload(seconds)

Packets perSecond (PPS)

BandwidthEthernet(Kbps)

G.711 160 20 50 87.2G.723 24 30 34 21.9G.726 80 20 50 55.2G.728 60 30 34 31.5G.729 20 20 50 31.2

Table 3.2: Bandwidth Calculations [18]

and scalability. The QoS offered by the networks can be represented by the parameters thatindicate the traffic behavior. Therefore, the service’s guaranteed offered by these architecturesis measured by the quality parameters of those service. The main QoS parameters, from thenetwork perspective, are:

• Delays - voice transmission into packets contributes to new problems as voice buffering,leading to higher end-to-end delays.

• Jitter - is a time variation between the packets arrivals. Removing the jitter requirespacket collection and their storage for a enough time so that they can be presented inthe correct sequence, which causes a further delay.

• Packet Loss - because of the voice time sensitivity, transmission based on TCP is notappropriate. The packet loss is, then, inevitable and may significantly influence thequality of service for voice on the IP network; it is defined as the percentage of packetssent by the origin host that did not arrived to the destination host.

• Sequence Errors - The congestion in packet networks can force packets to take differ-ent routes to their destinations, eventually forcing packets to arrive out of order, thuscreating a weird conversation.

• Echo - this effect occurs whenever the voice in the microphone is heard in the receiverwhile a call is taking place.

If there is no efficient mechanism for QoS to ensure a dedicated bandwidth to these calls,the users will get a deteriorated sound in the statement. There are techniques in some VoIPsolutions that performs silence detection and echo cancelation, in order to improve the qualityof the call. Silence detection is an algorithm implemented to reduce bandwidth consumption,causing the absence of sound in the environment because silence is discarded from voice pack-ages. The term echo cancelation is used in telephony to describe the process of removing echofrom a voice communication in order to improve voice quality on a telephone call. In additionto improving subjective quality, this process increases the capacity achieved through silencesuppression by preventing echo from traveling across a network. Echo cancelation involvesfirst recognizing the originally transmitted signal that re-appears, with some delay, in thetransmitted or received signal. Once the echo is recognized, it can be removed by ’subtract-ing’ it from the transmitted or received signal. This technique is generally implemented usinga digital signal processor, but can also be implemented in software. Echo cancelation is doneusing either echo suppressors or echo cancelers, or in some cases both.

15

Chapter 4

Network Environment

4.1 Introduction

The implementation of a solution for an IP network involves its integration with othersystems. Hence, a study was made on network’s components which will work with thatsolution. Since this is a critical network, this solution must not interfere with its normalfunctioning. So, this chapter makes an introduction to the bank’s environment, describes theTreasury Department network for whom this solution will be implemented and also makes anintroduction to the network components.

Figure 4.1 presents most of the network components, where only two servers will interactwith PhoneRecord and figure 4.2 shows how Treasury Department network will interact withthese components. PhoneRecord will be running where the other servers are located in theDataCenter building, in order to reduce lag between servers’ communications.

As this solution has to work with voice components, special attention must be taken toCallManager and Conference Bridge since they manage both the IP phones and the conferencecalls in the network. The use of these servers and Cisco IP phones, in detriment of othersolutions like Asterisk, was a bank imposition due to the contract with Cisco.

4.2 Call Manager Server

Call Manager is the call-processing and managing server of the Cisco Unified Communi-cations System. It extends telephony features to devices such as IP phones, media processingdevices, VoIP gateways, and multimedia applications. Also, services such as unified mes-saging, multimedia conferencing, and interactive multimedia response systems interact withthe IP telephony solution through Cisco CallManager APIs. It provides signaling, call con-trol services to integrated telephony applications as well as third-party applications [20] andperforms the following primary functions:

• Call processing.

• Signaling and device control.

• Dial plan administration.

• Phone feature administration.


Figure 4.1: Production Network Environment

• Directory services.

• Operations, administration, maintenance, and provisioning.

• Programming interface to external voice-processing applications such as SoftPhone, IPInteractive Voice Response, Personal Assistant, and CallManager Attendant Console

18

Figure 4.2: Treasury Department Environment

4.2.1 CallManager Services

CallManager has a suite of integrated voice applications and utilities to be used by ad-ministrators for troubleshooting issues and to control performance and device status infor-mation [3]. These services, which integrate this solution as bundled software, are:

• CallManager server - Windows server-based call-processing and call-control application.

• Configuration database - Contains system and device configuration information, includ-ing dial plan.

• Auto-Attendant - Ad-hoc conferencing application.

• Call Detail Record (CDR) Analysis and Reporting Tool - Provides reports for callsbased on CDRs.

• Bulk Administration Tool (BAT) - Allows the administrator to perform bulk add, delete,and update operations for devices and users.

• Attendant Console - Allows a receptionist to answer and transfer/dispatch calls withinan organization.

• Real-Time Monitoring Tool (RTMT) - A client tool that monitors real-time behaviorof the components in a CallManager cluster.

• Trace Collection Tool - Collects traces for a CallManager cluster.

• Conference Bridge (software) - Provides software conference bridge resources that canbe used by CallManager.

• Customer Directory Configuration Plug-in - Guides the system administrator throughthe configuration process for integrating CallManager with Microsoft Active Directoryand Netscape Directory Server.

19

• CallManager Assistant - CallManager Assistant provides all the call-routing and displaycapabilities required by busy administrative assistants and their managers in a businessenvironment.

• IP Phone Address Book Synchronizer - Allows users to synchronize Microsoft Outlookor Outlook Express address books with Cisco Personal Address Book.

• CallManager Locale Installer - Provides user and network locales for CallManager.

• CallManager JTAPI Client- This plug-in is installed on all computers that host appli-cations that interact with CallManager with the JTAPI.

• Telephony Service Provider - Contains the Telephony API (TAPI) service provider andthe Cisco Wave Drivers that TAPI applications to make and receive calls on the CiscoIP Telephony system.

• Tool for Auto-Registered Phone Support (TAPS) - Loads a preconfigured phone settingon a phone.

• Dialed Number Analyzer - Serviceability tool that analyzes the dialing plan for specificnumbers.

The only critical software that needs to be installed on the Voice&Media server is theCallManager JTAPI Client.

4.3 Media Termination Extensions

The media termination feature allows applications to transmit and capture the contentsof a call, for example, audio or video. This is usually referred to as rendering and recording orsourcing and sinking media. Media termination concerns the data that flows between devicesin a call, remaining distinct from call control. For instance, on one hand an automatic calldistributor (ACD) uses call control to route calls among available users but does not terminatemedia. An interactive voice response (IVR) application, on the other hand, uses call controlto answer and disconnect calls and uses media termination to interact with callers. Thereis no telephony applications interested in media termination though this feature always getsused in combination with call control [23].

4.3.1 CTI Port

In Cisco JTAPI, software-based media termination is possible by using CTI ports. Theyinclude one or more extensions that can be used to make or receive calls. However, theyneed a controlling application to provide the source and sink of the media, usually called bysoftPhone. This application registers its interest in the media termination port with the CiscoCallManager. The Cisco CallManager then delivers all the events that relate this device tothe application [20]. In Cisco JTAPI, CTI Ports get referred to as CiscoMediaTerminals.

20

4.3.2 CTI Route Point

A CTI Route Point is a virtual device that can receive multiple and simultaneous calls onthe same line for application-controlled redirection. Each CTI Route Point may be configuredwith only one extension and supports a maximum of 34 lines and to support more lines. InJTAPI, a CTI Route Point is known as CiscoRouteTerminal. A CiscoRouteTerminal is aspecial kind of CiscoTerminal that allows applications to terminate RTP media streams. Itmay be associated with any application that desires to route calls and also terminate media,specifying the IP Address and port number for each call or whenever media is established.In order to use this feature, applications must register the route point by supplying mediacapabilities. When a call is answered at this route point, CiscoMediaOpenLogicalChannelEvgets sent to the applications. This event occurs whenever media is established. Applicationsmust react to this event specifying the IP address and port number to where they want toterminate media. A schema of its functionality is represented in figure 4.4. Note that a RoutePoint is not hardware but a virtual object [23].

4.4 IP Phone

An IP phone is a telephone that uses VoIP to convert voice into IP packets and vice versa.This device, after being registered in a digital PBX, allows telephone calls to be made over anIP network instead of the ordinary PSTN system. These phones use protocols such as SIP orSkinny Client Control Protocol (SCCP). IP phones can be simple software-based Softphones,controlled by a desktop application or hardware devices that appear like an ordinary PSTNtelephone or cordless phone [25]. An example of an IP phone is shown in figure 4.3. Thisexample of an IP phone is constituted by:

• display screen.

• key for scrolling on screen.

• information button.

• soft keys.

• services button

4.5 Conference Bridge

A Conference Bridge is a voice component that connects multiple callers together andmonitors the conference call session. It is responsible to save CallManager resources in orderto take all conference calls and manage them. This component can be hardware or software.If is software, it is installed in CallManager server; if is hardware, it is used a server in thatpurpose. Usually, the hardware solution is chosen when the voice network is extensive [10].

21

Figure 4.3: Cisco IP Phone

Figure 4.4: Route Point functionality

22

Chapter 5

Development Tools

5.1 Introduction

There are many available tools to help make PhoneRecord development quicker and moreproductive. They have a central role for its construction and implementation, where theycan greatly increase development speed, reduce debugging and testing time, and improvequality of the output. This chapter describes all the developing tools that were used, fromprogramming languages and their APIs to platforms where this solution has been developed.The reasons why they were chosen are explained in chapter 6.

5.2 Java

Java is a programming language originally developed by Sun Microsystems, released in1995 as a core component of Sun Microsystems’ Java platform. The language derives muchof its syntax from C and C++ but has a simpler object model and much more high-levelfacilities. To illustrate the cross-platform benefits of the Java, this language is known by theslogan Write once, Run everywhere. This means that a programmer can develop code on aPC and expect it to run on every Java Virtual Machine (JVM). That’s why Java is the mostused worldwide programming language between programmers.

5.2.1 Eclispe IDE

Eclipse Integrated Development Environment (IDE) is an environment used to developvoice&media server in Java programming language. It was used the Eclipse Software Devel-oper’s Kit (SDK), which includes the Eclipse Java Development Tools, offering an IDE witha built-in incremental Java compiler and a full model of the Java source files. The IDE alsomakes use of a workspace, allowing external file modifications as long as the correspondingworkspace resource is refreshed afterwards. The Visual Editor project allows interfaces tobe created interactively, hence allowing Eclipse to be used as a rapid allocation development(RAD) tool [11].


5.2.2 JTAPI

5.2.2.1 Introduction

JTAPI “acts as a portable and object-oriented API for call control computer telephony soft-ware development, designed to ease platform-independent telephony software development”, 1.There are three reasons to focus on the usage of JTAPI:

• is implemented in Java. It is is able to operate with software written in other program-ming languages.

• JTAPI is written for vertical markets, where holds the promise of reuse and not previ-ously achieved software.

• the API has standardized domain objects, which simplifies telephony programming.

5.2.2.2 Specification

Since its first version, JTAPI has gone through some revisions. However, these changesslowed and it seems to have reached a stable version. Most of all changes occurred betweenversions 1.0 and 1.1 of the API. The biggest changes between version 1.1 and version 1.2involved the renaming of the core package from java to javax, the removal of a large numberof exceptions thrown and the introduction of dynamic capabilities. As this solution uses CiscoCallManager, it will be used Cisco JTAPI implementation that expose the CallManager’sfeatures to applications [31].

5.2.2.3 JTAPI Security

The JTAPI security model is based on Java sandbox model which provides a very restrictedenvironment to run untrusted code obtained from the open network. This means that thesandbox model is like a capsule where downloaded untrusted remote code can access only thelimited resources provided inside the virtual machine [1]. In addition to following this model,a simple username and password is used to gain access to Cisco’s provider implementationthrough the JtapiPeer object. The connection between JTAPI application and CallManagerServer is TCP/IP based and it is known as Computer Telephone Interface Quick BufferEncoding (CTIQBE), shown in figure 5.1.

5.2.2.4 Architecture

The purpose of JTAPI is to serve as an interface between a Java application and a tele-phone system. The point where this interface is located determines the type of control that anapplication has. In first-party call control, the interface is located at an end-point (terminal).A terminal represents a physical telephone and its main attribute is the terminal address. Ina third-party call control scenario, the interface is located inside the telephone system andit does not distinguish between the local end and the remote end of a call, working withthese two ends as they were symmetrical. Depending on the telephone system, this scenarioprovides the application usually with more control capabilities than a first-party call controlscenario. The call model describes the call as well the call parties. Altogether, it defines

1in Graf M., An Introduction to the Java Telephony API (JTAPI), March 2000

24

Figure 5.1: JTAPI and CallManager communication

five based classes (two of them describes call parties where their objects are persistent andindependent of calls):

• A user is represented by an Address object. The main attribute of the Address objectis the user identifier.

• A telephone terminal is represented by a Terminal object. The main attribute of theTerminal object is the telephone medium access control layer (MAC) address (terminal’saddress).

Three other classes describes a call. Their object are not persistent, but created dynamicallyduring a call:

• A Call object is created for each call.

• A Connection object is created for each user participating in the call. It connects theuser’s Address object with the Call object.

• A TerminalConnection object is created for each terminal participating in the call. Itconnects the terminal’s Terminal object with the Connection object.

An example of a call with two participants is shown in figure 5.2. This representation isimportant for the seamless extension to the case of a conference call model, which is the basiscall control scenario for this project. As this interface provides third-party view, the modelis completely symmetric (it does not distinguish between local and remote entities).

For two simultaneous calls on the same terminal, the example is shown in figure 5.3,where all call-related objects have their number in double. The Address object and Terminalobject of the user who has two calls exist once but are attached to two Connection andTerminalConnection objects.

An example of a two-party call with two alerting terminals is shown in figure 5.4. In thiscase, it causes the separation of TerminalConnection objects from Connection objects. Inthe example, when User 2 is called, several terminals are ringing. The multiline appearanceis represented by the two TerminalConnection objects that attach to the Connection object

25

Figure 5.2: JTAPI - Call model for two-party call

Figure 5.3: JTAPI - Call model for two simultaneous calls

of User 2, one for each terminal. When one of the terminals answers the call, the otherterminal is disconnected (in terms of the call model, the TerminalConnection object goes intoa disabled state).

For a conference call with three participants, the call model causes the separation ofConnection objects from Call objects (figure 5.5). It turns out to be a third extension ofthe basic call with two participants. This model simply adds a third leg with Connection,Address, TerminalConnection and Terminal objects for the third participant [29].

5.2.3 JMF

The JMF is a Java Library that enables audio, video and other time-based media to beadded to Java applications and applets. This package which can capture, playback, stream,and transcode multiple media formats, extends the Java Platform Standard Edition and allowsdevelopment of cross-platform multimedia applications. JMF abstracts the media with intoDataSources (for media being read) and DataSinks (for data being exported out). Although

26

Figure 5.4: JTAPI - Call model for two alerting terminals

Figure 5.5: JTAPI - Call model for conference call

JMF provides all of these capabilities, PhoneRecord is only focused to work with real-timemedia streams. To send and receive a media over an IP network, the application must beable to receive and transmit media streams in real-time.

5.2.3.1 Streaming Media

When media content is streamed to a client in real-time, the client can begin to play thestream without having to wait for the complete stream to download. In fact, the stream mightnot even have a predefined duration. The term streaming media is often used to refer boththis technique of delivering content over the network in real-time and the real-time media

27

content that is delivered.Because Cisco JTAPI does not provide any kind of control packets, this protocol will not

be focused in this project. PhoneRecord will work also as a media server and will have totransmit and receive media over the network.

5.2.3.2 Receiving Media Streams from the Network

PhoneRecord will be able to save incoming streams locally to a file (figure 5.6). Thereception of an incoming stream is handled by a RTPManager. RTPManager is used tocoordinate an RTP session, keeping the track of the session participants and the streamsthat are being transmitted. Also, it is capable to enable PhoneRecord to initialize and startparticipating in a session, remove individual streams created by the application and closethe entire session. To receive and save a single stream from an RTP session to a file, aMediaLocator is used, describing that describes the session to construct a Processor. AMediaLocator for an RTP session is constructed with the source IP, port and content-typestream. Then, the processor will treat the stream and save it to a file, using an appropriatecodec. Because Cisco JTAPI does not provide any kind of control packets, the RTCP protocolwill not be used by PhoneRecord.

Figure 5.6: JMF - RTP reception

5.2.3.3 Transmitting Media Streams through the Network

Similarly to media reception, PhoneRecord will have the responsibility to notify all callparticipants with a beep sound. This can be made transmitting the file data through thenetwork (figure 5.7). A RTPManager is used to initialize and control the session. The data isacquired from a Processor and the data will be encoded into RAW RTP stream. Then, thisstream is sent through the network [19].

Figure 5.7: JMF - RTP transmission

5.2.4 JDBC

Java Database Connectivity (JDBC) is an API for the Java programming language thatdefines how a client may access a database. The JDBC API contains two major sets of

28

interfaces: the first is the JDBC API for application writers where it provides methods forquerying and updating data in a database, and the second is the lower-level JDBC driver APIfor driver writers. JDBC technology drivers fit into one of four categories. Applications canaccess databases via the JDBC API using Java JDBC technology-based drivers, where driverconverts JDBC calls into the network protocol used directly by DataBases, allowing a directcall from the client machine to the DataBase server as shown in figure 5.8. JDBC API and itsStructured Query Language (SQL) JDBC driver is used in JMF component of voice&mediaserver in order to insert each recorded call profile into T VOICE RECORDS table [12].

Figure 5.8: JDBC Architecture

5.3 .NET Platform

It is not easy to briefly describe the .NET development platform concept into few words(figure 5.9). It is a revolutionary platform that uses open internet protocols, including frame-works and services that impulse the way software is developed. This platform also creates anew environment to develop and execute applications, turning the creation of web services indifferent programming languages very different.

5.3.1 Microsoft Visual Studio 2005

Microsoft Visual Studio is the main IDE from Microsoft. In this solution, it will be used todesign the web page and to program the web server, along with Windows Forms applicationsand web services in both native code as well as managed code for platforms supported byMicrosoft Windows and .NET Framework [27].

29

Figure 5.9: .NET Architecture

5.3.2 C#

C#, pronounced C sharp, is the most used language in .NET platform and will be usedin the PhoneRecord solution. This language developed by Microsoft, is similar to Java andis C/C++ based. The main objective of this language is to simplify, as opposed to the bruteforce strategy, turning the code stable and productive [28]. The advantages of this languageare:

• Simplicity

• Consistent

• Modern

• Object-oriented

5.4 SQL

SQL is a database computer language designed for the retrieval and management of datain relational database management systems, database schema creation and modification, anddatabase object access control management. For the development of this project, it was usedTransact Structured Query Language (T-SQL), a Microsoft’s proprietary extension to theSQL language. T-SQL is the primary means of programming and managing SQL Server. It

30

exposes keywords for the operations that can be performed on SQL Server, including creatingand altering database schemas, entering and editing data in the database as well as monitoringand managing the server itself. This choice was made because it was used a Microsoft basedenvironment, where Microsoft SQL Server 2005 was database server.

5.4.1 Microsoft SQL Server 2005

Microsoft SQL Server 2005 is a relational database management and analysis systemfor e-commerce, line-of-business and data warehousing solutions. This server includes en-hanced eXtensible markup language (XML) support, integration of .NET Framework objectsin databases and integration with Microsoft Visual Studio, as well as analysis, reporting anddata integration services. This will be the server installed in web server component.

5.4.2 Microsoft SQL Server Management Studio

Microsoft SQL Server Management Studio is an integrated environment for accessing,configuring, managing, administering and developing all components of SQL Server. Thissoftware combines a broad group of graphical tools with a number of rich script editors toprovide access to SQL Server to developers and administrators. Also includes the featuresof Enterprise Manager, Query Analyzer and Analysis Manager into a single environment. Inaddition, SQL Server Management Studio works with all components of SQL Server such asReporting Services, Integration Services, SQL Server Compact Edition and Notifications. Thisenvironment is used in the PhoneRecord solution in order to configure VOICE RECORDSdatabase and its stored procedures [21].

31

Chapter 6

PhoneRecord - ProjectDevelopment

6.1 Introduction

This chapter describes the PhoneRecord project and its implementation. In the firstsection, Architecture Overview: different approaches, it is exposed the confrontation betweentwo possible implementations, with the description of the choices that were made to reachthe final solution. The Architecture Overview: final solution describes the system particularcharacteristics and configurations; also explains how each server component works and howthey manage their tasks. In the next section, DataBase, the connections between each tablewithin the VOICE RECORDS DataBase are studied. The final section is Web Application,that presents the administrator interface with the voice&media server and the way the recordcalls are listened.

6.2 Architecture Overview: different approaches

The major restriction for this project was that it had to be Cisco based. Most of allnetwork routers, switches and voice components were Cisco; so, the solution had to workaside with Cisco CallManager. Beyond this, it was available for integration another Ciscovoice component, the Cisco Unity. With these work tools, it was time to planify the way toreach the final solution.

With two alternatives to record VoIP calls, either sniffing the RTP packets or usingconference-based solutions, it was necessary to choose one of these implementations to use inthe final solution.

6.2.1 Passive Mode

6.2.1.1 Packet Sniffing

Packet sniffing is “the act of capturing packets of data flowing across a computer network”1

and can be done with a Packet Sniffer. Packet Sniffer can record all packets that travel

1in Colasoft R© Network Analysis Software, http://www.colasoft.com/resources/packet_sniffing.php


http://www.colasoft.com/resources/packet_sniffing.php

through a network. It can be used to troubleshoot network problems and, for this situation,is capable of sniffing all RTP packets related to VoIP technology [13].

For the sniffing packets mode, it is needed:

• some time of local area network (LAN) capture package.

• dynamically start a sniffing session.

• work out an appropriate capture filter.

• capture the packets.

• store them to a file.

• deal with duplicate packets.

• mix the two streams (in-going and out-going).

• work out the encoding (G.711 or others).

• convert from U-LAW to linear.

• mathematically mix the samples before converting back to U-LAW for storage.

Besides being a challenge to work with captured packets (most of the solutions describedin Chapter 2 are already implemented this way), this implementation works as a passiverecording mode. Passive recording mode is understood as not interfere with the conditions ofthe call and act as a listener. So, one of the requirements is not being achieved which is the“beep” sound injection to notify all party-call and an active-call solution had to be designed.

The other way to record call is to implement a conference-based solution, also known asactive recoding mode. This mode is understood as a solution capable of interact activelywith the call. However, implementing this project this way will demand additional networkresources like bandwidth and conferencing facilities. This kind of implementation can be doneby two ways, either using Unity integration or developing a JTAPI server.

6.2.2 Active Mode

6.2.2.1 Cisco Unity integration

Cisco Unity, a voice mail server solution, can be used to implement this record solution.It has integrated the Unity Live Record feature which allows users to record conversationswhile they talk to costumers. When a call is active in the user’s line, the user has to dialthe Live Record Route Point extension. Then the record conversation is stored as a messagein the user’s mailbox and the recorded call can be reviewed later or redirect it to anotheruser or group of users. This implementation is capable of notify all participants in a call byconfiguring the live record beep settings such as Conversation - Live Record Beep Intervaland Conversation - Live Record Beep Duration, customizing how often Cisco Unity plays abeep as a call is recorded and how long the beep plays [30]. But using Cisco Unity has somecons:

• expensive voice component.

34

• solution based in Unity cannot be integrated in an environment with only CallManager.

• record calls are sent to users’ mailbox instead of being stored in a restricted accessserver.

• user has to call the Live Record Extension.

These characteristics did not meet some bank’s requirements as security and integrationbecause the user can be capable to decide which call wants to record as well as has access tomanage recorded calls. Therefore, another solution had to be planned in order to meet theseconditions.

6.2.2.2 Program-based implementation

With this implementation, it was planned a Java-based solution. It will be developed aserver where contains JTAPI and JMF components. They will act as a phone and mediaserver, where can put, automatically, any call in conference, record it and inject the “beep”sound into the network. Besides being also a conference-based solution which consumes someresources as bandwidth and CallManager conference facilities, this one is capable of restrictingaccess to record calls and the way the calls are recorded is done automatically. In addition,a web page for administration will be designed in ASP.NET and published by the InternetInformation Services (IIS).

6.3 Architecture Overview: final solution

With three possible implementations, it was decided, in the detriment of sniffing packetstechnology and Cisco Unit integration, to develop a Java-based server. The choice of Javalanguage for programming due to the fact that Cisco provides a Java Telephony API. Otherimportant features of Java, in terms of telephony programming, are its packages, interfaces,its clean thread model, its built-in portability, the Reflection API, Java Events, the remotemethod interface (RMI), and its support for native methods. It also provides inheritancethrough the extends keyword. However, this solution can only be implemented in Cisco-based networks, using CallManager for digital VoIP PBX. The database had to be developedin T-SQL with Microsoft SQL Server and the administration web page in C# using MicrosoftVisual Studio and no other database technology, since all servers are Microsoft-based. It wasa choice restriction for the project, but as these technologies are very powerful, they seem tobe the more adequate to develop PhoneRecord solution.

Then, it was time to plan the entire system to be developed. To create an environmentsimilar to the production network, it was necessary to design a test network (figure 6.1). First,we installed a CallManager server, added several IP phones and a development desktop. Forthe CallManager, a 4.2 version was used, a more advanced version than that of the productionCallManager (v4.1) which involves its update when running on it. The IP phones were 7940series and the development PC was a MacBook 2.0 GHZ intel, 2GB RAM, 120GB HD, runningMicrosoft Windows XP SP2 environment.

The first objective of this solution is the development of a voice&media server to worktogether with CallManager, which will manage all calls issues concerning devices (address andterminal), as well as the ability to receive and store an audio file of all received voice data and

35

Figure 6.1: Test Network Environment

to notify all call participants with a beep sound. This server will consist of two components,JTAPI and JMF, schematically in figure 6.2.

Figure 6.2: JTAPI and JMF components

6.3.1 JTAPI component

The JTAPI component will be responsible for dealing with all aspects related to themanagement of calls and the communication with the CallManager, and provides the datanecessary for JMF component to be initialized at each call. The system is booted in classPhoneEngine, where an initial reading of the parameters contained in the table T INIT PARAMSof VOICE RECORDS database is made. This reading is only possible after the server readthe text file conf.txt, that contains a string to connect VOICE RECORDS database via JDBC.After reading all the parameters, the server register JTAPI client in CallManager Service andcreate Provider object with the function registerProvider() (figure 6.3). The Provider objectwill act as the main point of contact between JTAPI server and CallManager, serving as arepository that contains the entire collection of call model objects, addresses, terminals andcalls, controllable at any time by the server.

36

Figure 6.3: JTAPI - registerProvider()

A socket listener is also created. This socket will receive XML commands to update theterminals and extensions list into server, as well as to be integrated in the user telephonydesktop interface already implemented in the bank network (in this interface, a record buttonwas added and the user just has to press it to begin recording the call). For each new TCP/IPconnection, the socket launches a thread that will process this command with the functionprocessMessage() (figure 6.4).

Figure 6.4: JTAPI - processMessage()

With the parameters initialized, the server will instantiate the object callsRec from Call-sRecorder class, passing as parameters the values read from T INIT PARAMS table. Thisobject will manage the entire section of call processing and start the reception and trans-mission, respectively, of the call audio and the recording notification sound. Even in systemstartup, the server gets the devices from table T DEVICE LIST to be recorded by the func-tion updatePortsStatus(), combines various observers to each device and creates a structurewhich will store all the parameters for each call (figure 6.5).

Figure 6.5: JTAPI - Create structure and updatePortsStatus()

Finally on this early stage, it is necessary to register one of the solution key points: theCisco Route Point, also known as Cisco Route Terminal (figure 6.6). This device, described

37

in chapter 5 has to be initialized, configured with the parameters necessary to a properfunctioning and have an observer member. One observer is an interface associated with athread that is capable of reacting to all events of the device, for instance, indicating its stateand where and when to transmit and receive RTP data.

Figure 6.6: JTAPI - registerRouteTerminal()

By now, the server is fully booted and ready to respond to all events detected by eachobserver associated with Cisco Route Terminal and devices in this recording list. If a devicereceives or makes a call, beyond all the events associated, the CallCtlConnEstablishedEv (CallControl Connection Established Event) event occurs. In this event, the JTAPI component isscheduled to launch a thread which calls the function recordCall() (figure 6.7).

Figure 6.7: JTAPI - Thread List run()

The function recordCall() aims to transform the initial call into a conference call betweenthat initial call participants and Cisco Route Terminal; thus, this is a conference-based so-lution (figure 6.8). The Cisco Route Terminal will be responsible to make a bridge betweenthe CallManager server and JMF server voice&media component.

Figure 6.8: JTAPI - recordCall()

The Cisco Route Point will have events reported by observers associated with it. Theevents to take care are:

• CiscoMediaOpenLogicalChannelEv (figure 6.9). Local IP and local port configurationfor receiving audio.

• CiscoRTPInputStartedEv (figure 6.10). Indicates that the Cisco Route Point is receivingaudio through those local settings.

• CiscoRTPOutputStartedEv (figure 6.11). This event returns the remote IP and remoteport for transmitting audio.

After these three events, the conference call is now completely created and callsRec objectis able to launch two threads: one for receiving audio and save it to a file and the other oneis responsible to transmit audio through the network.

38

Figure 6.9: JTAPI - CiscoMediaOpenLogicalChannelEv

Figure 6.10: JTAPI - CiscoRTPInputStartedEv

Figure 6.11: JTAPI - CiscoRTPOutputStartedEv

Its threads are stopped whenever the CallCtlConnDisconnectedEv event is detected fromCisco Route Point. This event means that a call at this device has ended and is no morevalid. Therefore, when those threads are stopped, they call its methods to stop saving andtransmitting audio.

6.3.2 JMF component

The second server voice&media component is responsible to capture and transmit RTPpackets into the network. To work with this component, a CTI Route Point and its audiocodec (chapter B) were configured in CallManager. As described in chapter 4, this device willwork as a router redirecting received calls to a termination point (PC), defining an IP and aport. The IP will be the same for all calls, changing only the port. Meanwhile, the receptionof these streams will be managed by component JMF. Those RTP packets contain audio,encoded in some possible codecs 3.1. In order to choose which codec will be used by JMF, acodec comparison graph (figure 6.12) was made, where it is possible to analyze their impactswith server’s hard disks space. These values are theoretical, calculated by multiplying theirbitrates per some time stamps in seconds.

After analyzing the graph, the codec G.711 was chosen because disk space is not an issueand more voice quality is always welcome. However, bandwidth resources can be affected bythe use of this codec and, consequently, the bank’s network well-functioning due to the numberof calls done in the Treasury Department. Everyday, the Treasury Department makes about

39

10 deals lasting 15 minutes and, as the number of calls is directly proportional to bandwidthconsumption, this issue is not anymore an obstacle for this implementation. Codec G.711has two companding algorithms, mu-law and a-law, whose purpose is to reduce the dynamicrange of an audio signal (figure 6.13). In this solution, the algorithm to use will the mu-lawdue to the fact that it is used in the North America and the a-law is used in Europe.

0

200

400

600

800

1000

0 20 40 60 80 100

File

Siz

e (K

B)

Duration (s)

VoIP Audio Codec Comparison

G.711G.723G.726G.728G.729

Figure 6.12: Codec File Size Comparison

Figure 6.13: µ-law and a-law Comparison [16]

Upon booting the server, structures for storing data similar to those created in JTAPI

40

component are created, both for the transmission class as for the audio receiving class, andobjects of these two classes are also instantiated. These threads launched by callsRec will calla method of these two objects:

• recorder da classe JMFSave

• transmit da classe JMFTransmitter

The thread responsible for the audio capture, by calling the function startSaving() (fig-ure 6.14), creates a local SessionAddress and a RTPManager associated with that session.Thus, a listener on the server side is created to react to any audio detection from Cisco RoutePoint. If audio is detected from the expected source, a processor will be created to treat thereceived audio and to record it to an audio file. The audio files are saved with *.wav extensionusing codec Waveform audio format (WAVE), because if saved in *.mp3 using codec MovingPicture Experts Group Phase 1 (MPEG-1) Audio Layer 3, the sound quality would be verylow. This variation in quality due to a different bit rate in audio compression; codec MPEG-1was used at 32 Kbit/s and codec WAVE at 64 kbit/s bit rate.

Figure 6.14: JMF - startSaving()

Regarding the audio transmission, the method startTransmitting() (figure 6.15) startsto create a processor to treat the audio from the beep file. This processor will transformdata from beep file into RTP packets to turn its injection into the network possible. Thena RTPManager is instantiated and configured, capable of creating a remote SessionAddressand send the RTP stream.

Figure 6.15: JMF - startTransmitting()

These threads stop when CallCtlConnDisconnectedEv event is returned. It implies, there-fore, that the threads run some final methods even before they are destroyed. For the audiotransmission thread, it calls the stop() method (figure 6.16) which only has the responsibilityto stop the processor and dispose the RTPManager.

Figure 6.16: JMF - stopTransmitting()

41

About the audio capture thread, it calls the stopSaving method (figure 6.17). This functionperforms a series of steps:

• disposes the RTPManager, as well as stops the processor.

• closes the audio file.

• invokes a stored procedure to insert the structure values into table T VOICE RECORDS.

• sends the audio file via FTP to the web server.

Figure 6.17: JMF - stopSaving()

Thus, the call cycle of voice&media for a call ends. This cycle can be run simultaneouslyto a maximum of 34 calls since this limit is imposed by using only one Cisco Route Point.To run this solution as a Windows Service, the Java Service Wrapper application was used.The Java Service Wrapper is an open-source application which makes it possible to installa Java Application as a Windows NT Service. Windows Service is understood as a long-running executable that performs specific functions and which is designed not to require userintervention. They can be configured to start when the operating system is booted and runin the background as long as Windows is running, or they can be started manually whenrequired.

6.4 Data Base

This section presents the VOICE RECORDS database model necessary to manage in-formation and is the result of the interaction between the CallManager server, voice&serverserver and web server. Eight tables have been built to store the initial parameters and theywill be used to insert the information collected throughout server operation.

• T INIT PARAMS

Responsible for providing the initial parameters to boot the voice&media server. Itcontains data to access on CallManager and FTP server (included in the web server)and has the following fields:

– os user: administrator network id.

– ip cm: CallManager IP.

– ip cm sub: CallManager sub IP.

42

– ip conf bridge: Conference Bridge IP.

– username: CallManager username.

– password: CallManager password.

– rec name: Cisco Route Point name.

– rec extension: Cisco Route Point extension.

– num calls: maximum number of simultaneous calls.

– start port rx: starting port for receiving audio.

– start port tx: starting port for transmitting audio.

– path file: folder where recorded calls are stored.

– path beep: file system path where beep sound is stored.

– length loop: silence duration between beep sounds, in milliseconds.

– webserverftp ip: web FTP server IP where file is uploaded to.

– webserverftp port: web FTP server port.

– webserverftp username: web FTP server username.

– webserverftp password: web FTP server password.

• T INIT PARAMS HISTORY

Each time an initial parameters modification occurs, this table is updated with theold values of the T INIT PARAMS table, the user who changed those values and theoperation post date. It has the following fields:

– post date: date and time when these fields where inserted.


– ip cm: CallManager IP.

– ip cm sub: CallManager sub IP.

– ip conf bridge: Conference Bridge IP.

– username: CallManager username.

– password: CallManager password.

– rec name: Cisco Route Point name.

– rec extension: Cisco Route Point extension.

– num calls: maximum number of simultaneous calls.

– start port rx: starting port for receiving audio.

– start port tx: starting port for transmitting audio.

– path file: folder where recorded calls are stored.

– path beep: file system path where beep sound is stored.

– length loop: silence duration between beep sounds, in milliseconds.

– webserverftp ip: web FTP server IP where file is uploaded to.

– webserverftp port: web FTP server port.

43

– webserverftp username: web FTP server username.

– webserverftp password: web FTP server password.

• T DEVICE LIST

This table contains the devices (address and terminal) which will be recorded by theserver voice&media. The administrator can add or remove any of those devices fromthe list. It has the following fields:

– address: IP phone extension.

– terminal: IP phone MAC address.

• T DEVICE LIST HISTORY

Each time an administrator makes any modification to table T DEVICE LIST, this ta-ble records the performed operation, the associated devices and which user was involved.It has the following fields:



– operation: operation performed in the web page.



• T VOICE RECORDS

This table is responsible for storing the information related to the calls recorded. Itincludes the address that was recorded, its terminal, the external address, the start andend instants and audio file path in the file system. It has the following fields:

– record id: record sequence number.



– ext address: external IP phone extension.

– day start: date and time when call record started.

– day stop: date and time when call record stopped.

– file path: file system path where recorded audio file is stored.

• T SESSION LOGS

This table was already built in the bank database. It controls all the applicationsoperations and their session logins. It is used for bank monitor purposes. It has thefollowing fields:

– log id: log sequence number.



44


– comments: operation description.

• T LOGIN

Contains the access logins to enter web application. It has the following fields:


– name: administrator name.

• T ACTION LOGS

This table stores all performed operations in the web application. It merges all logtables in order to concentrate the monitor information. The other log tables are usefulto query the information more easily. It has the following fields:




– comments: operation description.

To facilitate interaction between servers and tables, a set of stored procedures was devel-oped. A stored procedure is understood as a subroutine that is available for applications toaccess database system. Furthermore, stored procedures are used to consolidate and central-ize logic that was originally implemented in applications. Large or complex processing thatmight require the execution of several SQL statements is moved into stored procedures andall applications have only to call the procedures.

Everytime this solution needs information or has to store some data in the database, ituses stored procedures. The following stored procedures also log the activity in the web pageinto log tables.

• usp getLogin: used by web page to check if the user ID has permission to access theapplication.

• usp createLogin: this stored procedure is only used outside this solution. It is accessedonly with SQL Management Studio in order to increase security.

• usp deleteDeviceList : it is called when the administrator deletes a device from T DEVICE LISTtable in the web page.

• usp getDeviceList : list the devices to be recorded.

• usp insertDeviceList : add one address and one terminal to T DEVICE LIST table.

• usp getInitParams: get the PhoneRecord initial parameters.

• usp insertInitParams: update T INIT PARAMS table with the new values.

• usp displayValues: display all recorded calls details.

45

• usp insertValues: insert new recorded details into T VOICE RECORDS whenever acall ends.

• usp searchCall : display record calls details depending on criteria fields.

• usp insertLog : insert web page log into T ACTION LOGS.

The servers and table relationship schema is described in figure 6.18.

Figure 6.18: Servers and DataBase schema

6.5 WEB Page

The web page works as an interface between the user, the voice&media server and also thedatabase tables. With this page, the user is able to configure the server initial parameters,the devices which will be recorded and also query the database to listen recorded calls. Butbefore any configuration , the user has to do a login as shown in figure 6.19 and figure C.1.

Only registered users in T LOGIN table have permission to access the application. Theusername and password to login must be the same as they are in the bank network. T LOGIN

46

table has only the users allowed to navigate into the web page, but it does not contain anykind of passwords. Those passwords are stored in another table managed by supervisors. Ifthe login is not correct, the page returns an error message. If the login was successful, theuser is redirected to the main page (figure C.2).

The main page welcomes the user with a Millennium bcpbank logo and with three links.Inside the page skeleton, there is an iframe which will change depending on those links. Themanagement to load the iframe is a JavaScript script function in the main client-side code(figure 6.20).

Figure 6.19: Web Page - Check Login in Page Load

Figure 6.20: Iframe JavaScript Management

47

• Insert Device (figure C.3)

This page allows the user to manage the device list. Here, the devices can be added orremoved. To show the device list, the stored procedure usp getDeviceList is called andthe result set is put into a GridView web form. Whenever a user adds or removes adevice from the list, the stored procedures usp insertDeviceList and usp deleteDeviceListare called. To delete a device, the user just has to check the check button field and pressthe red button. In order to add a device, the user has to fill the address and terminalfields and press the green button. The button Update Server updates the device listinto server voice&media without the need to restart it. This update into voice&mediaserver is made through a XML message, containing the commands that are necessaryto perform it (figure 6.21) [26].

Figure 6.21: Update voice&media server

• Initial Parameters (figure C.4)

In this page, the user is able to edit the initial system configuration. Everytime thepage loads, the stored procedure usp getInitParams is called to list the current initialparameters into a DetailsView web form. To change them, the web control calls thestored procedure usp insertInitParams. When the user is performing these changes inthe web form, it is only on the client-side; the server only enters in action when theuser updates the whole information and not when each field is modified. However, thewindows service needs to be restarted in order to boot with those values.

• Search Call (figure C.5)

With this page, the user makes a database query to get the interested record calls.There are five fields the user can fill to search for calls, which are the address, terminal,external address and start and stop day/time. When the query is made by pressing

48

G.711 Practical Values G.711 Theoretical Values

Call Dura-tion(s)

File Size (KB) Call Dura-tion(s)

File Size (KB)

1 8 1 82 17 2 163 25 3 244 34 4 3217 138 17 13621 168 21 16824 189 24 19228 221 28 22431 249 31 24833 262 33 26436 289 36 28837 294 37 29649 389 49 39265 523 65 520100 797 100 800

Table 6.1: Codec G.711 Practical and Theoretical values

the query button, those fields and the audio file path in system file are returned into aGridView web form. This is only possible by running stored procedure usp searchCall(figure 6.22), which accepts as parameters the search criteria fields. To listen to recordedcalls, the user just need to move the mouse over the desired row and press the imagebutton on the left; this button will activate the media embedded player in the page andthe play will start automatically. Notice that everytime a user listens to a call it is alsobeing tracked into those log tables.

Figure 6.24 shows the whole system schema and the interactions between each componentand server. The application profile and installation manual are in the Appendix.

6.6 Results and Conclusions

This solution had to be tested in order to be approved by the Quality Department beforegoing into production network. Some quality tests were made, and every possible exceptionwas catched. Regarding the quality issue, the G.711 codec was chosen. This project layson this codec because, as already said in section 6.3.2, the disk size is not an obstacle forits use. This codec is also the one with the highest bitrate and, therefore, the highest voicequality. The voice quality is a very important issue, since this solution permits the disputeresolution or even provision information with customers into courts. In order to verify thesound quality in audio files, some calls were made with durations of up to 100 seconds. Thesetests where made just to prove that the server had received voice encoded in G.711 codec(figure 6.23 and table 6.1). The practical and theoretical values for the file size differ inmaximum of 4KB because the time was measured with a media player, which does not showthe decimal seconds. An audio file, for instance, can have 10.4 seconds and the player onlyshows 10 seconds. Those 4 decimal seconds are responsible for a difference in the practicaland theoretical values.

The bank’s network well-functionality was not affected because call’s frequency is not tohigh to introduce delays on servers and clients’ communications. However, this solution can

49

be scalable to a higher number of telephones which will, definitely, affect the network’s actualperformance. To prevent this to happen, the solution can loose voice quality in order to gainperformance using a lower bitrate codec.

The architecture chosen for the development of this project proved to be suitable forthe intended application. The system is already in production, concluding that the mainobjectives of this project were completed. As was intended, the system is able to record auto-matically the pre-defined each call terminals and extensions pre-defined to be recorded. Also,the web page prevents unauthorized accesses to system configurations and to recorded calls’profiles. The solution, taken into consideration the high costs of existing market solutionsand the bank’s requests, was developed from scratch. Through the work on this project, itwas found that is possible to implement a solution that fullfils the desired objectives, thatis cheaper than existing solutions, but is also efficient with regard to the environment of thenetwork.

The functional, technical and manual details that support this solution are described inchapters A and B. The development of this project had some mishaps, mainly because theplug-in JTAPI Client and CallManager server didn’t have the same version. This differenceon versions prevented the communication between this application and Cisco Route Point,which led to a possible change of direction in steering the Cisco Unity’s solution. It was foundthat the problem was the plug-in used when a SoftPhone was installed without success, sinceit also interacts with the CallManager’s CTI Manager.

Another issue found on this project development was that it is not possible to have twosimultaneous calls being recorded in the same terminal’s extension. Cisco Develop Depart-ment was contacted in order to find some problem to this issue, but their support was veryunresponsive.

50

Figure 6.22: Executing usp searchCall

0

100

200

300

400

500

600

700

800

900

0 20 40 60 80 100

File

Siz

e (K

B)

Duration (s)

G.711 Comparison

G.711 PracticalG.711 Theorical

Figure 6.23: Codec G.711 - Practical and Theorical Comparison

51

Figure 6.24: Final Solution Schema

52

Chapter 7

Conclusions and FutureApplications

This work studied the implementation of a system capable of recording and monitoringVoIP calls. The process of developing the proposed system was based on the market analysisand subsequent choice of several options. In this context, this work was split up into twoparts: first, there was a study on the theoretical market solutions, the network existing inthe bank and the development tools to use; secondly, all concepts studied in the theoreticalanalysis were used to develop a system for recording calls. The theoretical study startedin the second chapter, which concluded that there is only one solution on the market thatmeets all the bank’s requirements: notification, restricted access and automatic recording. Inthe third chapter, there is a description of the bank’s network, describing all the componentsthat interact with the proposed solution. In the fourth chapter, the development tools used toimplement this solution were presented, including the technologies used. The bank impositionsand components used in the network resulted in the choice of these tools. Chapter 4 also makesa description of JTAPI and JMF technology and of all platforms used.

The second part of the work is described in the fifth chapter. This chapter describesthe development of a system capable to record and monitor calls in an IP network, and thecreation of an administrator application. The choice has been to develop a server in Java,including the components JTAPI and JMF, where CallManager already provides a telephonyAPI in Java. The use of a database was imperative to record all details concerning theoperation of the solution, and in response to this need, the Microsoft SQL Server was used.The application that allows the administrator accesses to the system configuration and therecorded calls, the .NET platform from Microsoft was used. In this application a log wascreated for every action the administrator does, from login to recorded call listened.

These two shares are the central part of the work. In short, the system focuses on theplanned schedule of a Java-based server and in a .NET application. This system can manageand record the calls to be monitored, and makes the upload of the audio files via FTP to theIIS server where lies the administrator application, achieving all the requirements imposedby the bank.

This solution serves as a starting point for the development of a digital IVR system in aVoIP network. However, there are some improvements and features that can be added to thesystem. To facilitate its installation, this solution should use only one server that containsboth voice&media and web components. This solution avoids various aspects such as the


transfer of files via FTP from voice&media server to the web server and the creation of usersin the database and in IIS. Another application would be to develop video support for the newvideo phones and the use of Cisco IP Phone Services SDK to send an information message toeach user specifying the state of a recording call instead of the typical conference message [25].Also, the integration of more CTI route points enables more phones to be recorded.

This first experience in a business environment was an added value in author’s professionalterms and the fact that this solution was developed abroad, also enriched him in personalterms.

54

Bibliography

[1] Java security architecture, 1999. http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html.

[2] Can we tape? and, a legal website directory, 2003. http://www.rcfp.org/taping/.

[3] Cisco CallManager Features and Services Guide. 2004.

[4] Witness compliance recording, 2005. http://www.manx-telecom.com/pdf/Witness_Compliance_Recording.pdf.

[5] A brief intro to voip, 2006. http://www.voip-4u.de/eng/b-A-Brief-Intro-To-VoIP__17.02.2006.html.

[6] Confiance ip solutions, 2006. http://www.confianceinc.com/index.jsp?id=irecordertutorial.

[7] Call center recording with voxida, 2007. http://www.accuratealways.com/voxida.

[8] Callrex voip recording & monitoring for ip pbxs, 2007. http://www.telrex.com/callrex.htm.

[9] Audio codec, 2008. http://en.wikipedia.org/wiki/Audio_codec.

[10] Conference call, 2008. http://en.wikipedia.org/wiki/Conference_call.

[11] Eclipse.org home, 2008. http://www.eclipse.org/.

[12] Jdbc overview, 2008. http://java.sun.com/products/jdbc/overview.html.

[13] Packet sniffing, 2008. http://www.colasoft.com/resources/packet_sniffing.php.

[14] Powercall crm products, 2008. http://www.telecom911.co.za/downloads/powercall%20CRM%20manual1jan08.pdf.


http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html

http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc1.html

http://www.rcfp.org/taping/

http://www.manx-telecom.com/pdf/Witness_Compliance_Recording.pdf

http://www.voip-4u.de/eng/b-A-Brief-Intro-To-VoIP__17.02.2006.html

http://www.confianceinc.com/index.jsp?id=irecordertutorial

http://www.accuratealways.com/voxida

http://www.telrex.com/callrex.htm

http://en.wikipedia.org/wiki/Audio_codec

http://en.wikipedia.org/wiki/Conference_call

http://www.eclipse.org/

http://java.sun.com/products/jdbc/overview.html

http://www.colasoft.com/resources/packet_sniffing.php

http://www.telecom911.co.za/downloads/powercall%20CRM%20manual1jan08.pdf

http://www.telecom911.co.za/downloads/powercall%20CRM%20manual1jan08.pdf

[15] That-2, 2008. http://www.jkaudio.com/assets/pdf/JK_Audio_THAT-2_datasheet.pdf.

[16] mu-law, April 2008. http://en.wikipedia.org/wiki/M-law.

[17] A callrex / mitel case study, February 2005. http://downloads.telrex.com/PDF/callrex_us_oil.pdf.

[18] Voice over ip - per call bandwidth consumption, February 2006. http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml.

[19] JavaTM Media Framework API Guide. November 1999.

[20] Smith A. Alexander J., Pearce C. Cisco CallManager Fundamentals. Cisco Press, 2005.

[21] Hamilton B. Programming SQL Server 2005. O’Reilly, 1 edition, 2006.

[22] Igor Barkov. Some aspects concerning ip-telephony (part i), 2008. http://www.digit-life.com/articles/aspectsiptelephony/index.html.

[23] Cisco Systems, Inc. Cisco Unified JTAPI Developer Guide for Cisco Unified CallMan-ager, 2006.

[24] Bennahum D. How to tap a voip call, 2004. http://www.slate.com/id/2095777/.

[25] Smith A. Deel D., Nelson M. Developing Cisco IP Phone Services. Cisco Press, 2002.

[26] Kanalakis J. Developing .NET Enterprise Applications. Apress, 1 edition, 2003.

[27] Hurwitz D. Liberty J. Programming ASP.NET. O’Reilly, 1 edition, 2002.

[28] MacDonaldo B. Liberty J. Learning C# 2005. O’Reilly, 2 edition, 2005.

[29] Graf M. An Introduction to the Java Telephony API (JTAPI). March 2000.

[30] Gonzalez M. Morgan B. Cisco Unity Fundamentals. Cisco Press, 2004.

[31] Roberts S. Essential JTAPI - Design Telecom Projects with Java. Prentice Hall PTR, 1edition, 1999.

[32] Henning Schulzrinne. Rtp: About rtp and the audio-video transporting work group, 2008. http://www.cs.columbia.edu/~hgs/rtp/.

56

http://www.jkaudio.com/assets/pdf/JK_Audio_THAT-2_datasheet.pdf

http://en.wikipedia.org/wiki/M-law

http://downloads.telrex.com/PDF/callrex_us_oil.pdf

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml

http://www.digit-life.com/articles/aspectsiptelephony/index.html

http://www.slate.com/id/2095777/

http://www.cs.columbia.edu/~hgs/rtp/

Appendix A

Application Profile

Overview

This document supports the current version of the Phone Record application and de-scribes all the functional and technical details that support this solution. The document isorganized into two different sections that cover the Functional and Technical specifications.This is a Technical document designed for Technical Personnel that implement changes tothe application and for everyone who needs to understand the application.

Functional Architecture

This section describes the functionalities that have been implemented into this solution.The first section describes the main application components while the remaining ones describein detail each of the functionalities.

Component DescriptionV oice&Media Manages all the functionalities related to phones and media.Server Also inserts into the database information about recorded calls.WebServer Provide several visual components to the front-end in order to configure

all the necessary conditions to run the application and also to search forrecorded calls.

DataBase Stores all the information related to the recorded calls and to thenecessary functionality of the server into VOICE RECORDS table.

Table A.1: PhoneRecord - components description


Functional Specifications

# Description: Web Page#1 When the application opens, the user is presented with a login page.#2 After logged in, the user is presented with a page listing three tabs where

one can navigate and the Millennium bcpbank logo.#3 In Device List, the user is presented with a list of devices which are being

recorded. One is able to change that list, adding or removing devices.Then, there is a button where the admin user can update the server list.

#4 In Init Params, it is possible to edit server initial parameters.Note: windows service needs to be restarted.

#5 Search Call permits the user to query for a recorded call and listen tothe media file, pressing just the button aside the address which was recorded.

# Description: Windows Service#1 For each extension in IP Phone, only one call can be recorded simultaneously.#2 To record a call in one extension, that extension must not have any active

call.#3 For each extension in his IP Phone, only one call can be recorded

simultaneously.#4 If the other party call hangs up first, the user must end call with PhoneRecord

CTI Phone (just press End Call on Phone).#5 For conference call issues, the treasury officer must be the conference

controller. Only he can add other phones to the conference call.

Table A.2: PhoneRecord - functional specifications

58

Application Authorization Model

This section describes the application authorization model: for each type of user, there isa list of functionalities that they can perform. The table below describes the existing profiles,the type and the functionalities that can be performed.

Profile Type FunctionalitiesTreasury Officer User - For each extension in his IP Phone, only one

call can be recorded simultaneously.- To record a call in one extension, thatextension must not have any active call.- To end call, just press ’End Call’ on Phone.- If the other party call hangs up first, the usermust end call with Phone Record CTI Phone(just press ’End Call’ on Phone).- For conference call issues, the treasury officermust be the conference controller. Only he can addother phones to the conference call.

Information Security Administrator - View server logs to report errors to IT.Officer - View website log table to monitor application.

- Add or remove Phones and Extension to berecorded.- Change server initial parameters.- Search for any call recorded.- Play recorded call media file.

Table A.3: RecordPhone components

59

Appendix B

Installation Manual

This section describes the installation procedures to effectively install this Software Prod-uct into a new environment.

Architecture

The figure B.1 is an overview of the Software’s Architecture identifying the several com-ponents that need to be installed and where they are installed.

Figure B.1: Software’s Architecture

Front-End

This section describes the steps required to install all the components required for theuser interface.

Server Requirements

• Hardware

– Dual Core Intel R© Xeon R© 5110 (1.60GHz, 1066 FSB) Processor

– 2GB Memory

– 320 GB Disk Space

• Operating System (OS)

– Windows Server 2008

– IIS


– .Net Framework 2.0

The following installation instructions must be performed on the WebServer on the ServerFarm.

Costumer Front-End

To install the Phone Record front-end component, please follow the following steps:

• Open IIS.

• Create a new web site called PhoneRecord.

• Copy \\Install\Front-End\Website\contents to Phone Record web folder. Be carefulnot to overwrite \\InetPub\wwwroot\PhoneRecord\calls folder.

• Edit the web.config file in the Phone Record web folder and configure the parametersto match the current web site.

• Restart ”Phone Record” web site.

To uninstall this component, please follow the following steps:

• Just remove PhoneRecord from IIS. Be careful not to delete \\InetPub\wwwroot\PhoneRecord\callsfolder.

Voice&Media Server

This section describes the steps required to install all the components required for theVoice&Media Server.

Server Requirements

• Hardware


– 2GB Memory


• OS


– Java Server Second Edition (JS2E)

The following installation instructions must be performed on the voice&media server onthe Server Farm.

62

PhoneRecord Service

To install the Phone Record front-end component, please follow the following steps:

• Install Cisco JTAPI Client from Call Manager Plug-ins

• Edit the \\PhoneRecord\bin\conf.txt file and configure JDBC string connection tomatch the current database and server host.

• Edit \\PhoneRecord\conf\wrapper.conf and configure Windows Service parameters.

• Install Windows Service by running \\PhoneRecord\bin\InstallPhoneRecord-NT.bat.

• Start Phone Record Windows Service by running \\PhoneRecord\bin\StartPhoneRecord-NT.bat.


• Run \\PhoneRecord\bin\StopPhoneRecord-NT.bat.

• Run \\PhoneRecord\bin\UninstallPhoneRecord-NT.bat.

DataBase

This section describes the steps required to install all the components required for theDatabase. The following installation instructions must be performed on all Databases on theDatabase Cluster.

Server Requirements

• Hardware


– 2GB Memory


• OS


– SQL Server 2005

The following installation instructions must be performed on the voice&media server onthe Server Farm.

63

DataBase

To install the Database component, please follow the following steps:

• Import VOICE RECORDS database into SQL Server from Develop Server.

• Configure user and password to have access to that database.

• Edit \\PhoneRecord\bin\conf.txt with respective server login, database, user and pass-word.


• Delete VOICE RECORDS from SQL Server

• Delete user created for this application.

Cisco CallManager

This section describes the steps required to configure settings for the Cisco CallManager.

• Create a region called R-CTI Region.

– Change codec in R-CTI Region (within this region) and R-MOH to G.711 (fig-ure B.2)

• Create a location called L-CTI Location (figure B.3).

• Create a partition called P-CTI Partition (figure B.4).

• Create a device pool called DP-CTI Device Pool (figure B.5).

• Change Device Pool of each phone to be recorded into DP-CTI Device Pool (figure B.6).

• Create a CTI Route Point (figure B.7).

• Associate an extension line to CTI Route Point (figure B.8 and figure B.9).

• Use CallManager transcode service to encode a beep file into G.711 µlaw.

64

Figure B.2: CallManager - Change codec in R-CTI Region

65

Figure B.3: CallManager - Configure a location

Figure B.4: CallManager - Configure a partition

66

Figure B.5: CallManager - Configure a device pool

67

Figure B.6: CallManager - Configure a DP in phone settings

68

Figure B.7: CallManager - Configure a Route Point

69

Figure B.8: CallManager - Configure an extension to Route Point (1)

70

Figure B.9: CallManager - Configure an extension to Route Point (2)

71

Appendix C

Administration Web Page

This section presents the administration web page’s figures.

Figure C.1: Login Page


Figure C.2: Main Page

Figure C.3: Device List Page

73

Figure C.4: Initial Parameters Page

Figure C.5: Search Call Page

74

phonerecord - record and monitor voip solution · keywords voip, record, java, jtapi, jmf, .net,...

Documents