Phone record : record and monitor VolP solution

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2008

Pedro

Albuquerque

<albuquerque@ua.pt>

PhoneRecord

S

olu¸c˜

ao de

G

rava¸c˜

ao e

M

onitoriza¸c˜

ao

VoIP

PhoneRecord

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2008

Pedro

Albuquerque

<albuquerque@ua.pt>

PhoneRecord

S

olu¸c˜

ao de

G

rava¸c˜

ao e

M

onitoriza¸c˜

ao

VoIP

PhoneRecord

R

ecord and

M

onitor

VoIP S

olution

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 Ant´onio Nogueira and Paulo Salvador, professors of the Department of Electronics, Telecommunications and Informatics in the University of Aveiro.

(4)

(5)

o j´uri / the jury

presidente / president Doutor Armando Jos´e Formoso de Pinho

Professor Associado da Universidade de Aveiro (por delega¸c˜ao da Reitora da Uni-versidade de Aveiro)

vogais / examiners committee Doutor Joel Jos´e Puga Coelho Rodrigues

Professor Auxiliar do Departamento de Inform´atica da Faculdade de Ciˆencias da Engenharia da Universidade da Beira Interior

Doutor Ant´onio Manuel Duarte Nogueira Professor Auxiliar da Universidade de Aveiro (Orientador) Doutor Paulo Jorge Salvador Serra Ferreira

(6)

(7)

People envolved

Supervisor Prof. Antonio Manuel Duarte Nogueira

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

Invited Auxiliar Professor of the University of Aveiro Collaborators Dr. Pedro J. Concei¸c˜ao Belo

CEO of Millennium bcpbank Dr. Manuel Moura Guedes

Senior Vice-President of Millennium bcpbank IT department Eng. Sergio Alonso

Senior Vice-President of Millennium bcpbank IT department Eng. Pedro Rafael de Jesus Soares

Consultor in Millennium bcpbank IT department Eng. Pedro dos Reis Mendes

(8)

(9)

“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 distant vision, that goal or purpose.”

(10)

(11)

acknowledgements In first place, I’d like to thank my supervisors for accepting this project and for all the support given during its development.

A special thank to Pedro Belo, for giving me the opportunity to work at Millennium 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, I dedicate this project to my grandparents, specially to my dear grandmother Avo Olga.

Finally, I devote this project to the most important persons in my life, my family. To my parents and my brother, thank you. Without you, I wouldn’t be what I am today - you are what matter most. I’m really thankful. To all, my sincerest thanks.

(12)

(13)

Palavras-chave VoIP, Grava¸c˜ao, Java, JTAPI, JMF, .NET, CallManager, Cisco, Conferˆencia

Resumo Esta disserta¸cão apresenta o estudo para a grava¸cão e monitoriza¸cão de chamadas VoIP. A solu¸cão PhoneRecord funciona junto com o CallManager da Cisco e faz uso de Java Telephony Application Programming Interface (JTAPI) na gestão de chamadas e da framework Java Media Framework (JMF) para o processamento de áudio. O acesso às configura¸cões do sistema e à lista das chamadas gravadas é conseguido através de um browser web.

(14)

(15)

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

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

(16)

(17)

List of Figures

2.1 CallRex scability [8] . . . 6

2.2 Confiance user interface [6] . . . 6

2.3 THAT-2 Telephone Handset Audio TAP [15] . . . 7

2.4 Voxida server [7] . . . 8

2.5 Solutions comparison chart . . . 9

3.1 VoIP concepts. . . 12

3.2 VoIP protocol stack . . . 14

4.1 Production Network Environment . . . 18

4.2 Treasury Department Environment . . . 19

4.3 Cisco IP Phone . . . 22

4.4 Route Point functionality . . . 22

5.1 JTAPI and CallManager communication . . . 25

5.2 JTAPI - Call model for two-party call . . . 26

5.3 JTAPI - Call model for two simultaneous calls . . . 26

5.4 JTAPI - Call model for two alerting terminals . . . 27

5.5 JTAPI - Call model for conference call . . . 27

5.6 JMF - RTP reception . . . 28

5.7 JMF - RTP transmission. . . 28

5.8 JDBC Architecture . . . 29

5.9 .NET Architecture . . . 30

6.1 Test Network Environment . . . 36

6.2 JTAPI and JMF components . . . 36

6.3 JTAPI - registerProvider() . . . 37

6.4 JTAPI - processMessage() . . . 37

6.5 JTAPI - Create structure and updatePortsStatus() . . . 37

6.6 JTAPI - registerRouteTerminal() . . . 38

6.7 JTAPI - Thread List run() . . . 38

6.8 JTAPI - recordCall() . . . 38

6.9 JTAPI - CiscoMediaOpenLogicalChannelEv . . . 39

6.10 JTAPI - CiscoRTPInputStartedEv . . . 39

6.11 JTAPI - CiscoRTPOutputStartedEv . . . 39

6.12 Codec File Size Comparison . . . 40

6.13 µ-law and a-law Comparison [16] . . . 40

6.14 JMF - startSaving() . . . 41

(20)

6.15 JMF - startTransmitting() . . . 41

6.16 JMF - stopTransmitting() . . . 41

6.17 JMF - stopSaving() . . . 42

6.18 Servers and DataBase schema . . . 46

6.19 Web Page - Check Login in Page Load . . . 47

6.20 Iframe JavaScript Management . . . 47

6.21 Update voice&media server . . . 48

6.22 Executing usp searchCall . . . 51

6.23 Codec G.711 - Practical and Theorical Comparison . . . 51

6.24 Final Solution Schema . . . 52

B.1 Software’s Architecture . . . 61

B.2 CallManager - Change codec in R-CTI Region . . . 65

B.3 CallManager - Configure a location . . . 66

B.4 CallManager - Configure a partition . . . 66

B.5 CallManager - Configure a device pool . . . 67

B.6 CallManager - Configure a DP in phone settings . . . 68

B.7 CallManager - Configure a Route Point . . . 69

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

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

C.1 Login Page . . . 72

C.2 Main Page . . . 73

C.3 Device List Page . . . 73

C.4 Initial Parameters Page . . . 74

(21)

List of Tables

3.1 Codecs Information [22] . . . 14

3.2 Bandwidth Calculations [18]. . . 15

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

A.1 PhoneRecord - components description. . . 57

A.2 PhoneRecord - functional specifications . . . 58

A.3 RecordPhone components . . . 59

(22)

(23)

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.

(24)

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.

(25)

Chapter 1

Introduction

1.1 Motivation

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

In a VoIP call, voice is transformed into digital bits and segmented into packets of data to be routed through the Internet Protocol (IP) network, being reassembled upon arrival at the other end. Actually, there is no actual sound passing through the network at any time because the Personal Computer (PC) or other device which places the VoIP call digitizes voice sound. PSTN traffic is also segmented into digital packets at some point, but such calls are 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 new Internet Phone Software software package. The hardware needed to talk to another computer was a modem, sound card, microphone and speakers.

This technology is being developed since then and, by year 1998, gateways had been established to allow PC-to-phone connections and phone-to-phone connections that used the Internet for voice transmission. These last connections still required a computer to initiate the 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 to VoIP in order to be integrated into digital systems.

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

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

(26)

1.2 Objectives

This dissertation is about developing and implementing a system that is capable of record and monitor calls in VoIP phones within Millennium bcpbank Treasury Department network. The project, called “PhoneRecord”, was born as a solution to meet the proposal requirements of Millennium bcpbank to control the deals made by the Treasury Department and to be possible to make non presential sales (NPS) with costumers. If needed, the Call Center can also 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 and also restricts the access to system boot configuration and database where the files and the profiles of the recorded calls are located. This solution doesn’t want to rival with existing sniffing packets and high-processing conference-based systems, but to create a solution where there is no need to record a high number of phone calls. Another objective, as important as the first one, is to obtain the academic Master degree of Engineering of Electronic and Telecommunications.

1.3 Law terms

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

Twelve states require the consent of all parties to a conversation. Those jurisdictions are 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 that can 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 generally accomplished with a verbal notification by the recording party or an automatic, periodic beep tone, indicating that the call is about to be recorded and, while recording, indicating that recording is taking place. There are specific requirements for this tone. According to Voice Logging Recorders (VLR) Communications, the beep tone needs to be a 1260 to 1540Hz tone, lasting 170 to 250 milliseconds, and broadcast for both sides to hear every twelve to fifteen seconds when the call is taking place.

(27)

1.4 Document Outline

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

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

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

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

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

Chapter 5 − Development Tools: This chapter presents all the tools that were used to develop the proposed solution, as well as the network components and environments.

Chapter 6 − PhoneRecord, Project Development: In this chapter, the different paths that were taken to reach the final solution are presented. It also explains how 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.

(28)

(29)

Chapter 2

State-of-Art

2.1 Introduction

Since the arrival of VoIP, many companies have developed and are still developing different approaches 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 sound file. 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 way calls 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 being recorded. 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 the data switch connected to the IP Private Branch eXchange (PBX), then copies them to the CallRex Server which then reassembles all the packets into recorded calls, compresses and stores them for later retrieval. This server works with almost all of the most-known digital PBX, 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). This CallRex solution is already implemented in The U.S. Tire & Exhaust division of U.S. Oil Co., Inc. They wanted to bring better control to dispute resolution at its Customer Service Center, which handles some 4, 000 customer calls a day. Customer Service Center associates have been able to resolve disputed calls by retrieving a recording of the conversation that they can send to the customer as a simple e-mail attachment( [17]). However, this solution does not meet one of the requirements which is to send a “beep” sound every 12 seconds or even to 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 exception of Windows OS. Besides this, a license must be bought for each phone, resulting in a very expensive solution [8].

(30)

Figure 2.1: CallRex scability [8]

2.3 PowerCall CRM

This solution is a package of a computer telephony integration (CTI) server and a client application, which is possible to record all the calls occured in pre-selected IP phones and query 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’s limitations 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 with a specific IP Phone and is installed in every client PC. It registers with any digital PBX in order to control the phone from the PC desktop. However, each client has access to the recorded calls folder and can erase them (figure2.2). However, this solution also doesn’t have the possibility to inform each call participant with a “beep” tone neither includes any initial message.

(31)

2.5 THAT-2

THAT-2 (Telephone Handset Audio Tap) is a hardware solution to be connected between telephone and handset for quick access to audio in and out of the telephone (figure2.3). The THAT-2 is used by radio stations to record and play sound bytes, by computer and telephone companies 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 input and output volume control, has a selector switch for the different types of telephone systems and no batteries or AC are needed [15]. But, as all the previous solutions, it is possible for the client to unplug the hardware. Also, an audio connector is needed for each phone and it’s a 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. The captured phone conversation can then be sent by e-mail or searched and retrieved using a variety of selection criteria. Authorized users across the enterprise can use a browser-based solution to retrieve and replay interactions using search options [4]. Although this solution is powerful, a hardware installation is needed and there is no notification when recording function is being performed.

2.7 Voxida

Accurate Always built the Voxida call recording and quality monitoring solutions to record digital PBX, analog telephone, video and radio communications (figure2.4). Voxida solutions offer simultaneous call recording and playback for long term data-integrity and instant recall of a particular call or transmission. Audio stream and real-time monitor components integrate with the IP network, enabling also full remote access on this client/server platform. Also,

(32)

Voxida’s voice logging solutions provide an optional beep tone, to notify callers that the call is being recorded. It is a suitable solution for high traffic systems where call recording and monitoring in customer contact centers is critical [7]. However, this solution is very expensive for 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 need to develop a personalized tool without high implementation costs. This decision was based on six reviewed products, analyzing and balancing its operation characteristics. All solutions achieve 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 ratio is very high, so this solution is very expensive (needs a hardware implementation) for the bank’s needs. Figure 2.5 shows the relation between the analised solutions and the solution that will be developed in order to answer the three key requirements that were presented by the bank.

(33)

Figure 2.5: Solutions comparison chart

(34)

(35)

Chapter 3

VoIP

3.1 Introduction

In terms of flexibility, cost, variety of products and services, networks and solutions for communication (voice, data and images) based on packet switching and IP protocol are be-coming increasingly competitive when compared to traditional offerings like TDM, Frame Relay 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 transport network, as there is no single reserved path. As a consequence of the underlying unreliable protocol (User Datagram Protocol (UDP)), packets arriving at the destination may come in a 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, the transmission of voice over IP networks presented several additional possibilities.

3.2 Concepts

The architecture of Internet Telephony is identical to old fashioned telephone networks in many ways, but it also has some significant differences. Fundamentally, internet telephony runs over IP networks. The most significant consequence of having this underlying network is that is provides transparent connectivity between any devices on the network, independently of the location. Whereas devices in traditional networks are restricted by communicating with those devices to which they are directly connected, internet telephony can rely on an underlying 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 user resides and some automatic interaction is also possible (voicemail). It can be software or 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.

(36)

• gateway - border element of a VoIP network. It provides inter-operability between IP and 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 speech compression. Pulse-Code Modulation (PCM) is the digital representation of that analog signal where the magnitude of the signal is sampled regularly at uniform intervals, then quantized to 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 indentification of UDP voice packets. Then, after negotiating all initial settings for transmitting, the packets are sent. However, this becomes more complex if the signaling system has to communicate with the gateway that is located between the Internet and PSTN. In case of outgoing calls, the VoIP 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 the calls to it. Finally, at the receiving end, packets have to be disassembled for data extraction in order to put the voice data into the device’s sound card.

(37)

are H.323 and Session Initiation Protocol (SIP). Transmitting media data across the net in real-time requires high network bandwidth. It’s easier to compensate for lost data than to compensate for large delays in data reception. Data transmitted goes through the network as datagrams, where every datagram has a source address, destination address and sequence number. 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 for streaming 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 to turn signalling protocols reliable, where call features performance must be trustable. For voice transmitting, the IP network uses the UDP protocol, where the packet transmission is not reliable. The option for this protocol lays in the fact that in voice transmission, it would be very confusing if the packets had to be re-transmitted and acknowledgements would consume more network bandwidth. So, reliable protocols are not suitable in voice issues because their control mechanisms add transmission delays and voice would not be perceived. For these reasons, 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 packets will arrive in the order that they where sent. The receiver has to be able to compensate for lost data, duplicate packets and packets that arrive out of order. If UDP was a reliable protocol, the audio in a VoIP call would be retransmitted in packet-loss situations, confusing all call participants. Like TCP, UDP is a general transport-layer protocol - a lower-level networking protocol on which more applications or specific protocols are built. RTP is one example of those protocols built over UDP. It provides end-to-end network delivery services for transmission of real-time data. RTP can be used over both unicast and multicast network services. Over a unicast service, separate copies of the data are sent from the source to each destination. Over a multicast network service, the data is sent from the source only once and the network is responsible for transmitting the data to multiple locations, such as video conferences [32]. While RTP does not provide any mechanism to ensure timely delivery or provide other quality of service guarantees, it is augmented by Real-Time Transport Control Protocol (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 audio data according to a given audio file format or streaming audio format. The term codec is a combination of ’coder-decoder’ where its object of a codec algorithm is to represent the high-fidelity audio signal with minimum number of bits while retaining the quality. This can effectively reduce the storage space and the bandwidth required for transmission of the stored audio file [9]. Some of the audio codecs used in telephony are shown in the tables3.1 and 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 Differential Pulse-Code Modulation (ADPCM), Low Delay Code Excited Linear Prediction (LD-CELP), glscsacelp, Multi-Pulse Maximum Likelihood Quantization (MP-MLQ) and Algebraic Code Excited Linear Prediction (ACELP).

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

(38)

Figure 3.2: VoIP protocol stack Name Bitrate (Kbps) Codec Sample Size(Bytes) Encoding Al-gorithm

Delay(ms) Mean Opinion Score (MOS) G.711 64 80 PCM 0.75 4.1 G.723 6.3 24 MP-MLQ 30 3.9 G.726 32 20 ADPCM 1 3.85 G.728 16 10 LD-CELP 3 3.61 G.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 to deliver 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, a wide range of listeners judge the quality of a voice sample on a scale of one (bad) to five (excellent). The scores are averaged to provide the MOS for the codec.

(39)

Name Voice Payload (Bytes) Voice Payload (seconds) Packets per Second (PPS) Bandwidth Ethernet (Kbps) G.711 160 20 50 87.2 G.723 24 30 34 21.9 G.726 80 20 50 55.2 G.728 60 30 34 31.5 G.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 that indicate the traffic behavior. Therefore, the service’s guaranteed offered by these architectures is measured by the quality parameters of those service. The main QoS parameters, from the network 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 requires packet collection and their storage for a enough time so that they can be presented in the correct sequence, which causes a further delay.

• Packet Loss - because of the voice time sensitivity, transmission based on TCP is not appropriate. The packet loss is, then, inevitable and may significantly influence the quality of service for voice on the IP network; it is defined as the percentage of packets sent 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, evdiffer-entually forcing packets to arrive out of order, thus creating a weird conversation.

• Echo - this effect occurs whenever the voice in the microphone is heard in the receiver while 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 VoIP solutions that performs silence detection and echo cancelation, in order to improve the quality of 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 echo from a voice communication in order to improve voice quality on a telephone call. In addition to improving subjective quality, this process increases the capacity achieved through silence suppression by preventing echo from traveling across a network. Echo cancelation involves first recognizing the originally transmitted signal that re-appears, with some delay, in the transmitted 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 using a digital signal processor, but can also be implemented in software. Echo cancelation is done using either echo suppressors or echo cancelers, or in some cases both.

(40)

(41)

Chapter 4

Network Environment

4.1 Introduction

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

Figure4.1presents most of the network components, where only two servers will interact with PhoneRecord and figure4.2shows how Treasury Department network will interact with these components. PhoneRecord will be running where the other servers are located in the DataCenter building, in order to reduce lag between servers’ communications.

As this solution has to work with voice components, special attention must be taken to CallManager and Conference Bridge since they manage both the IP phones and the conference calls in the network. The use of these servers and Cisco IP phones, in detriment of other solutions 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 processing devices, VoIP gateways, and multimedia applications. Also, services such as unified mes-saging, multimedia conferencing, and interactive multimedia response systems interact with the 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] and performs the following primary functions:

• Call processing.

• Signaling and device control.

• Dial plan administration.

• Phone feature administration.

(42)

(43)

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 calls based 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 within an organization.

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

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

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

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

(44)

• CallManager Assistant - CallManager Assistant provides all the call-routing and display capabilities required by busy administrative assistants and their managers in a business environment.

• IP Phone Address Book Synchronizer - Allows users to synchronize Microsoft Outlook or 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 and the Cisco Wave Drivers that TAPI applications to make and receive calls on the Cisco IP Telephony system.

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

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

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

4.3 Media Termination Extensions

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

(45)

4.3.2 CTI Route Point

A CTI Route Point is a virtual device that can receive multiple and simultaneous calls on the same line for application-controlled redirection. Each CTI Route Point may be configured with only one extension and supports a maximum of 34 lines and to support more lines. In JTAPI, a CTI Route Point is known as CiscoRouteTerminal. A CiscoRouteTerminal is a special kind of CiscoTerminal that allows applications to terminate RTP media streams. It may 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 media capabilities. When a call is answered at this route point, CiscoMediaOpenLogicalChannelEv gets sent to the applications. This event occurs whenever media is established. Applications must react to this event specifying the IP address and port number to where they want to terminate media. A schema of its functionality is represented in figure4.4. Note that a Route Point 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 an IP network instead of the ordinary PSTN system. These phones use protocols such as SIP or Skinny 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 PSTN telephone or cordless phone [25]. An example of an IP phone is shown in figure 4.3. This example 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 and monitors the conference call session. It is responsible to save CallManager resources in order to 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 that purpose. Usually, the hardware solution is chosen when the voice network is extensive [10].

(46)

(47)

Chapter 5

Development Tools

5.1 Introduction

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

5.2 Java

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

5.2.1 Eclispe IDE

Eclipse Integrated Development Environment (IDE) is an environment used to develop voice&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 with a built-in incremental Java compiler and a full model of the Java source files. The IDE also makes use of a workspace, allowing external file modifications as long as the corresponding workspace resource is refreshed afterwards. The Visual Editor project allows interfaces to be created interactively, hence allowing Eclipse to be used as a rapid allocation development (RAD) tool [11].

(48)

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 softsoft-ware 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 changes slowed and it seems to have reached a stable version. Most of all changes occurred between versions 1.0 and 1.1 of the API. The biggest changes between version 1.1 and version 1.2 involved the renaming of the core package from java to javax, the removal of a large number of exceptions thrown and the introduction of dynamic capabilities. As this solution uses Cisco CallManager, it will be used Cisco JTAPI implementation that expose the CallManager’s features to applications [31].

5.2.2.3 JTAPI Security

The JTAPI security model is based on Java sandbox model which provides a very restricted environment to run untrusted code obtained from the open network. This means that the sandbox model is like a capsule where downloaded untrusted remote code can access only the limited 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 implementation through the JtapiPeer object. The connection between JTAPI application and CallManager Server is TCP/IP based and it is known as Computer Telephone Interface Quick Buffer Encoding (CTIQBE), shown in figure5.1.

5.2.2.4 Architecture

(49)

tele-Figure 5.1: JTAPI and CallManager communication

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

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

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

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

• A Call object is created for each call.

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

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

An example of a call with two participants is shown in figure5.2. This representation is important for the seamless extension to the case of a conference call model, which is the basis call control scenario for this project. As this interface provides third-party view, the model is 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 Terminal object of the user who has two calls exist once but are attached to two Connection and TerminalConnection objects.

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

(50)

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 other terminal is disconnected (in terms of the call model, the TerminalConnection object goes into a disabled state).

For a conference call with three participants, the call model causes the separation of Connection objects from Call objects (figure 5.5). It turns out to be a third extension of

(51)

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-time media streams. To send and receive a media over an IP network, the application must be able 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 the stream without having to wait for the complete stream to download. In fact, the stream might not even have a predefined duration. The term streaming media is often used to refer both this technique of delivering content over the network in real-time and the real-time media

(52)

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 to transmit 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). The reception of an incoming stream is handled by a RTPManager. RTPManager is used to coordinate an RTP session, keeping the track of the session participants and the streams that are being transmitted. Also, it is capable to enable PhoneRecord to initialize and start participating in a session, remove individual streams created by the application and close the entire session. To receive and save a single stream from an RTP session to a file, a MediaLocator is used, describing that describes the session to construct a Processor. A MediaLocator for an RTP session is constructed with the source IP, port and content-type stream. Then, the processor will treat the stream and save it to a file, using an appropriate codec. Because Cisco JTAPI does not provide any kind of control packets, the RTCP protocol will 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 call participants with a beep sound. This can be made transmitting the file data through the network (figure5.7). A RTPManager is used to initialize and control the session. The data is acquired from a Processor and the data will be encoded into RAW RTP stream. Then, this stream is sent through the network [19].

(53)

interfaces: the first is the JDBC API for application writers where it provides methods for querying and updating data in a database, and the second is the lower-level JDBC driver API for driver writers. JDBC technology drivers fit into one of four categories. Applications can access databases via the JDBC API using Java JDBC technology-based drivers, where driver converts JDBC calls into the network protocol used directly by DataBases, allowing a direct call from the client machine to the DataBase server as shown in figure5.8. JDBC API and its Structured Query Language (SQL) JDBC driver is used in JMF component of voice&media server 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 (figure5.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 a new environment to develop and execute applications, turning the creation of web services in different 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 to design the web page and to program the web server, along with Windows Forms applications and web services in both native code as well as managed code for platforms supported by Microsoft Windows and .NET Framework [27].

(54)

Figure 5.9: .NET Architecture

5.3.2 C#

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

• Simplicity

• Consistent

(55)

exposes keywords for the operations that can be performed on SQL Server, including creating and altering database schemas, entering and editing data in the database as well as monitoring and managing the server itself. This choice was made because it was used a Microsoft based environment, 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 system for e-commerce, line-of-business and data warehousing solutions. This server includes en-hanced eXtensible markup language (XML) support, integration of .NET Framework objects in databases and integration with Microsoft Visual Studio, as well as analysis, reporting and data 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. This software combines a broad group of graphical tools with a number of rich script editors to provide access to SQL Server to developers and administrators. Also includes the features of Enterprise Manager, Query Analyzer and Analysis Manager into a single environment. In addition, SQL Server Management Studio works with all components of SQL Server such as Reporting Services, Integration Services, SQL Server Compact Edition and Notifications. This environment is used in the PhoneRecord solution in order to configure VOICE RECORDS database and its stored procedures [21].

(56)

(57)

Chapter 6

PhoneRecord - Project

Development

6.1 Introduction

This chapter describes the PhoneRecord project and its implementation. In the first section, Architecture Overview: different approaches, it is exposed the confrontation between two possible implementations, with the description of the choices that were made to reach the final solution. The Architecture Overview: final solution describes the system particular characteristics and configurations; also explains how each server component works and how they manage their tasks. In the next section, DataBase, the connections between each table within 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 record calls are listened.

6.2 Architecture Overview: different approaches

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

With two alternatives to record VoIP calls, either sniffing the RTP packets or using conference-based solutions, it was necessary to choose one of these implementations to use in the 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 1_{in Colasoft}° Network Analysis Software,R _{http://www.colasoft.com/resources/packet_sniffing.php}

(58)

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 described in Chapter 2 are already implemented this way), this implementation works as a passive recording mode. Passive recording mode is understood as not interfere with the conditions of the 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 as active recoding mode. This mode is understood as a solution capable of interact actively with the call. However, implementing this project this way will demand additional network resources like bandwidth and conferencing facilities. This kind of implementation can be done by 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 conversations

(59)

• 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 access server.

• user has to call the Live Record Extension.

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

6.2.2.2 Program-based implementation

With this implementation, it was planned a Java-based solution. It will be developed a server where contains JTAPI and JMF components. They will act as a phone and media server, 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 some resources as bandwidth and CallManager conference facilities, this one is capable of restricting access 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 Internet Information Services (IIS).

6.3 Architecture Overview: final solution

With three possible implementations, it was decided, in the detriment of sniffing packets technology and Cisco Unit integration, to develop a Java-based server. The choice of Java language for programming due to the fact that Cisco provides a Java Telephony API. Other important 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 remote method interface (RMI), and its support for native methods. It also provides inheritance through 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 developed in T-SQL with Microsoft SQL Server and the administration web page in C# using Microsoft Visual Studio and no other database technology, since all servers are Microsoft-based. It was a choice restriction for the project, but as these technologies are very powerful, they seem to be the more adequate to develop PhoneRecord solution.

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

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

(60)

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 figure6.2.

Figure 6.2: JTAPI and JMF components

6.3.1 JTAPI component

(61)

Figure 6.3: JTAPI - registerProvider()

A socket listener is also created. This socket will receive XML commands to update the terminals and extensions list into server, as well as to be integrated in the user telephony desktop interface already implemented in the bank network (in this interface, a record button was added and the user just has to press it to begin recording the call). For each new TCP/IP connection, the socket launches a thread that will process this command with the function processMessage() (figure6.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. This object 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 system startup, 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 structure which will store all the parameters for each call (figure6.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: the Cisco Route Point, also known as Cisco Route Terminal (figure6.6). This device, described

(62)

in chapter 5 has to be initialized, configured with the parameters necessary to a proper functioning and have an observer member. One observer is an interface associated with a thread that is capable of reacting to all events of the device, for instance, indicating its state and 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 each observer associated with Cisco Route Terminal and devices in this recording list. If a device receives or makes a call, beyond all the events associated, the CallCtlConnEstablishedEv (Call Control Connection Established Event) event occurs. In this event, the JTAPI component is scheduled to launch a thread which calls the function recordCall() (figure6.7).

Figure 6.7: JTAPI - Thread List run()

The function recordCall() aims to transform the initial call into a conference call between that initial call participants and Cisco Route Terminal; thus, this is a conference-based so-lution (figure6.8). The Cisco Route Terminal will be responsible to make a bridge between the 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. The events to take care are:

(63)

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 from Cisco Route Point. This event means that a call at this device has ended and is no more valid. Therefore, when those threads are stopped, they call its methods to stop saving and transmitting audio.

6.3.2 JMF component

The second server voice&media component is responsible to capture and transmit RTP packets into the network. To work with this component, a CTI Route Point and its audio codec (chapterB) were configured in CallManager. As described in chapter4, this device will work as a router redirecting received calls to a termination point (PC), defining an IP and a port. The IP will be the same for all calls, changing only the port. Meanwhile, the reception of these streams will be managed by component JMF. Those RTP packets contain audio, encoded in some possible codecs3.1. In order to choose which codec will be used by JMF, a codec comparison graph (figure6.12) was made, where it is possible to analyze their impacts with server’s hard disks space. These values are theoretical, calculated by multiplying their bitrates per some time stamps in seconds.

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

(64)

10 deals lasting 15 minutes and, as the number of calls is directly proportional to bandwidth consumption, this issue is not anymore an obstacle for this implementation. Codec G.711 has two companding algorithms, mu-law and a-law, whose purpose is to reduce the dynamic range of an audio signal (figure6.13). In this solution, the algorithm to use will the mu-law due 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 Size (KB) Duration (s)

VoIP Audio Codec Comparison

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

(65)

component are created, both for the transmission class as for the audio receiving class, and objects of these two classes are also instantiated. These threads launched by callsRec will call a 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 Route Point. If audio is detected from the expected source, a processor will be created to treat the received audio and to record it to an audio file. The audio files are saved with *.wav extension using codec Waveform audio format (WAVE), because if saved in *.mp3 using codec Moving Picture Experts Group Phase 1 (MPEG-1) Audio Layer 3, the sound quality would be very low. This variation in quality due to a different bit rate in audio compression; codec MPEG-1 was 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) starts to create a processor to treat the audio from the beep file. This processor will transform data from beep file into RTP packets to turn its injection into the network possible. Then a RTPManager is instantiated and configured, capable of creating a remote SessionAddress and 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 audio transmission thread, it calls the stop() method (figure6.16) which only has the responsibility to stop the processor and dispose the RTPManager.

Figure 6.16: JMF - stopTransmitting() 41

Phone record : record and monitor VolP solution

Pedro

Albuquerque

PhoneRecord

S

olu¸c˜

ao de

G

rava¸c˜

ao e

M

onitoriza¸c˜

ao

VoIP

PhoneRecord

Pedro

Albuquerque

PhoneRecord

S

olu¸c˜

ao de

G

rava¸c˜

ao e

M

onitoriza¸c˜

ao

VoIP

PhoneRecord

R

ecord and

M

onitor

VoIP S

olution

Contents

List of Figures

List of Tables

Acronyms

Chapter 1

Introduction

1.1

Motivation

1.2

Objectives

1.3

Law terms

1.4

Document Outline

Chapter 2

State-of-Art

2.1

Introduction

2.2

CallRex

2.3

PowerCall CRM

2.4

Confiance Recorder

2.5

THAT-2

2.6

Witness Compliance Recording

2.7

Voxida

2.8

Conclusions

Chapter 3

VoIP

3.1

Introduction

3.2

Concepts

3.4

Audio Codecs

Chapter 4

Network Environment

4.1

Introduction

4.2