`
`John H. Mock, W.Thomas Miller
`University of New Hampshire, ECE Department
`Kingsbury Hall, Durham, NH 03824
`
`
`Abstract- While
`duties,
`their
`performing
`emergency service personnel in mobile units from
`various departments need to communicate with
`each other. Currently, unless every department has
`identical radios, this is impossible due to lack of
`radio interoperability.
`
`This research addresses the need for these non-
`interoperable mobile units to communicate with
`one another. It is not financially possible for these
`agencies to each purchase new, matching radios;
`instead a solution is being developed using Voice
`Over IP (VoIP). This solution involves establishing
`a network consisting of a single central server and
`clients
`located at each of
`the departments.
`Interfaced to each client
`is a radio that
`is
`compatible with
`the
`individual department’s
`mobile radio units. Each client runs an H.323
`compliant application that was developed using
`Microsoft’s Telephony Application Programming
`Interface 3.0 (TAPI 3.0).
`A prototype system has been developed and
`preliminary testing has proven the system operates
`successfully. Further
`testing methods
`for
`determining voice quality are being evaluated.
`I. INTRODUCTION
`Project54 is a collaborative research and development
`effort between the University of New Hampshire and
`the New Hampshire Department of Safety and is
`supported by the U.S. Department of Justice. The goal
`of the project is to apply high technology to law
`enforcement so that officers can perform their duties
`more safely and efficiently [1].
`While performing their duties, police officers and
`other emergency service personnel in mobile units
`from various departments need to communicate with
`each other. Currently, unless every department has
`identical radios, this is impossible due to lack of radio
`interoperability.
` The motivation for
`the work
`presented here was
`the need
`for
`these non-
`interoperable mobile units to communicate with one
`another. It is not financially possible for these
`agencies to each purchase new, matching radios;
`instead a solution is being developed using Voice
`Over IP (VoIP). This solution involves establishing a
`statewide VoIP network consisting of a single central
`server and a client located at each of the participating
`departments.
`
`The authors wish to thank the US DOJ for
`funding Project54 through grant #1999-DD-
`BX-0082
`
` The central server will host a voice conference that
`follows the H.323 standard for audio, video, and data
`communications across
`the
`Internet. A H.323
`compliant
`application was
`developed
`using
`Microsoft’s Telephony Application Programming
`Interface 3.0 (TAPI 3.0) to run on a desktop computer
`at the client side. A radio that is compatible with the
`individual departments’ mobile radio units will be
`interfaced to the desktop computer at the client.
`
`When a mobile unit wishes to communicate with a
`mobile unit from a different agency, instead of doing
`so directly,
`the
`transmission will
`traverse
`the
`established network. A voice conference must first be
`created on the server if there is not one present. All
`clients have the ability to perform conference creation
`or deletion. Transmission will begin at the mobile unit
`and travel to its base station. At its base station, the
`transmission will be processed by the client and sent
`to the conference on the server. The server will then
`distribute the transmission to whoever has joined the
`conference. Each client computer at the different
`agencies then sends the transmission out using a radio
`compatible with its mobile units. The entire system
`described is depicted in Fig.1.
`II. SYSTEM DESCRIPTION
`
`
`In keeping with the goal of being cost-effective, this
`system is being designed using mostly off-the-shelf
`components. The hardware used to host the voice
`conference is a server-class computer. The server
`uses
`First Virtual Communications’
`(FVC)
`Conference Server software based multipoint control
`unit (MCU). Conference Server enables the hosting
`of multiple simultaneous conferences with audio and
`video mixing [2]. The video features are not currently
`used; buy may be incorporated into the system in the
`future. While Conference Server supports the H.323,
`SIP, and T.120 conferencing standards, only H.323
`endpoints will be used. H.323 is a recommendation
`from the International Telecommunications Union
`(ITU)
`that
`sets
`standards
`for multimedia
`communications over IP based networks that do not
`provide a guaranteed Quality of Service (QoS), such
`as the Internet [3]. To counteract the effects of
`network latency and lack of guaranteed QoS, H.323
`uses the Real-time Transport Protocol (RTP) as a
`foundation.
`
`0-7803-7467-3/02/$17.00 ©2002 IEEE.
`
`1338
`
`Google 1031
`U.S. Patent No. 9,445,251
`
`
`
`Voice Conference
`Server
`
`
`
`
`
`
`
`
`
`
`
`
`
`Internet
`
`
`PC Class Voice Servers
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` RTP is an application layer protocol that provides a
`degree of QoS over IP based networks. The
`conference server collects audio streams from all
`connected clients and mixes them into a single
`stream. Each client can choose to receive this mixed
`stream or choose a stream from a single selected
`endpoint. Conference Server supports the following
`audio codecs: G.711, G.723, and G.729A. The
`mixing of these during a conference is also supported
`which means that every endpoint is not required to
`use the same codec. When the incoming audio
`streams are mixed and retransmitted,
`they are
`encoded using the same codec as the destination
`endpoint. Most endpoints will choose to use either
`the G.723 or G.729A codecs because their maximum
`bit rate is much lower than that of G.711, 6.3 kbit/sec
`and 8 kbit/sec for G.723 and G.729A respectively
`versus 64 kbit/sec for G.711 [4]. Sound quality is
`better using G.711 over an error free channel with
`guaranteed bandwidth, but the Internet rarely meets
`these constraints. The lower bit-rate codecs perform
`much better when errors are present and bandwidth is
`restricted [5]. Conference management is performed
`by using either a set of Telnet commands or an
`administration web page. This gives clients the
`ability to perform conference management.
`
`Mobile Unit
`
`Mobile Unit
`Figure 1- System for voice Over IP solution for mobile radio interoperability
`
`
`
`
`
`
`Application Programming Interface 3.0 (TAPI 3.0).
`The TAPI objects used in this application are shown
`in Figure 2. The TAPI object is the applications
`entry point to TAPI 3.0. This object represents all
`telephony resources to which the local computer has
`access, allowing an application to enumerate all local
`addresses. An ADDRESS object represents the
`origination or destination point for a call. The
`application uses the ADDRESS object to create an
`outgoing CALL object. The CALL object represents
`the connection between the local address and a
`remote address; in our case this is the client and
`server, respectively.
` All call control, such as
`connecting and disconnecting, is done through the
`CALL object. The TERMINAL object represents the
`sink, or renderer, at the termination or origination
`point of the connection. In our application the
`TERMINAL object is mapped to hardware, such as
`the speakers and microphone, but can also be mapped
`to a file [6].
`
`TAPI
`
`ADDRESS
`
`
`
`CALL
`
`TERMINAL
`
`
`
`Figure 2 - TAPI objects
`
`The hardware used on the client-side consists of a
`desktop computer.
` An H.323 compliant voice
`conferencing
`application
`(Project54
`Voice
`Conference Application) was developed and is used
`on the client-side desktop computer. The application
`was developed using Microsoft’s Telephony
`
`
`
`0-7803-7467-3/02/$17.00 ©2002 IEEE.
`
`1339
`
`
`
`The window-based graphical user interface (GUI) of
`the application provides a simple interface for joining
`conferences. Figure 3 shows the GUI used by the
`Project54 Voice Conference Application. In order to
`join a conference, the following information must be
`known a priori; the IP address or name of the
`conference server and the names of the conferences
`that are available. The clients can view available
`conferences by using
`the Conference Server
`administration web-based GUI. In the Destination
`address type field the user chooses to use either a
`domain name or IP address to connect to the
`conference server. In the Conference Name field, a
`valid conference name must be entered before
`connecting to the server. When all fields are filled
`with valid entries, the Connect button is used to
`establish the connection with the server. The
`Disconnect button is used to leave a conference and
`disconnect from the server. While participating in a
`conference, it is not possible to join a different
`conference without disconnecting from the server.
`Once disconnected, the Conference Name field may
`be changed and a new connection to the server can
`then be established. Future enhancements to the
`client software may add the functionality of querying
`the server for the names of available conference.
`Future enhancements will also add the capability to
`create and delete conferences, but currently these
`functions are also performed through the web-based
`GUI.
`
`
`Figure 3 - Graphical user interface
`
`
`
`
`
`
`
`III. VERIFICATION AND TESTING
`The testing of this prototype system was performed
`using a NIST Net Router to emulate real network
`conditions. The NIST Net network emulator is a
`general-purpose
`tool for emulating performance
`dynamics in IP networks [7]. The tool is designed to
`allow controlled, reproducible experiments with
`network performance sensitive/adaptive applications
`and control protocols in a simple laboratory setting.
`By operating at the IP level, NIST Net can emulate
`the critical end-to-end performance characteristics
`
`imposed by various wide area network situations.
`NIST Net is implemented as a kernel module
`extension to the Linux operating system and an X
`Window System-based user interface application.
`The tool allows an inexpensive PC-based router to
`emulate numerous performance scenarios, including:
`tunable packet delay distributions, congestion,
`bandwidth
`limitation, and packet
`reordering
`/
`duplication. The configuration of the testing system
`is shown in Figure 4. Clients A and B are configured
`to use the NIST Net router to reach client C and
`likewise client C is configured to use the router to
`reach clients A and B.
`
`
`Figure 4 - Prototype system test setup
`
`
`Preliminary testing of this prototype system consisted
`of ensuring basic audio conferencing functionality
`among three endpoints and subjectively testing audio
`quality under limited bandwidth conditions. All of
`the preliminary testing was performed with all clients
`using the G.729A audio codec. The bandwidths used
`for testing are: 10,000, 100, 57.6, 38.4, 28.8, 19.2,
`and 9.6 (all values have units of kilobits per second).
`This testing has proven successful.
` All three
`endpoints were able to join a conference hosted by
`the Conference Server application and audio quality
`remained acceptable with bandwidth restrictions
`imposed.
`
`
`IV. FUTURE WORK
`
`
`Before this system can be deployed, further testing
`must be performed. Future testing will introduce the
`following network impairments into the system:
`delay, congestion, and packet reordering. The goal is
`to simulate the conditions the final system will face
`when operating over the Internet. In addition to
`subjective, objective testing of voice quality will be
`performed. The objective testing algorithms that are
`currently being evaluated for use are: Measuring
`Normalized Blocks (MNB) [8], Perceptual Speech
`Quality Measure (PSQM) [9], Perceptual Evaluation
`
`0-7803-7467-3/02/$17.00 ©2002 IEEE.
`
`1340
`
`
`
`[3] “Packet Based Multimedia Communications
`Systems,” ITU-T Recommendation H.323,
`November 2000
`[4] R.J.B. Reynolds, A.W. Rix, “Quality VoIP –
`an engineering challenge,”,BT Technology
`Journal, April 2001, pp. 24
`[5] S. Yamarthy, “Subjective and objective
`evaluation of voice quality over internet
`telephony,” MS Project, ECE Department,
`University of New Hampshire, 2000
`[6] “IP telephony with TAPI 3.0,” MSDN
`library, April 2000
`[7] www.antd.nist.gov/itg/nistnet/
`of
`[8] “Objective
`quality measurement
`telephone-band
`(300-3400 HZ)
`speech
`codecs,” ITU-T Recommendation P.861
`Appendix II, February 1998
`of
`[9] “Objective
`quality measurement
`telephone-band
`(300-3400 HZ)
`speech
`codecs,” ITU-T Recommendation P.861
`Appendix II, February 1998
`[10] “Perceptual evaluation of speech quality
`(PESQ), an objective method for end-to-end
`speech quality assessment of narrow-band
`telephone networks and speech codecs,”
`ITU-T Recommendation P.862, February
`2001
`
`
`
`
`
`of Speech Quality (PESQ) [10]. If testing of the
`prototype system is successful, an interface to the
`client-side desktop computers will be developed and
`the mobile radios will be incorporated into the
`system. This completed system will then be put
`through the same tests as the prototype. Once testing
`is complete and the system is found to perform
`adequately under real-world conditions, it will be
`deployed across the state of New Hampshire.
`
`
`V. CONCLUSION
`
` A
`
` prototype system has been developed to address
`the issue of mobile radio interoperability. A server
`class computer with FVC Conference Server
`software based MCU
`is used
`to host voice
`conferences. A TAPI based voice conferencing
`application with a user-friendly GUI was developed
`for use on the client-side desktop computer. A test
`network for the prototype system was developed with
`the ability to introduce the following conditions:
`• Packet delay;
`• Congestion;
`• Packet reordering/duplication.
`
`
`Initial testing, which included ensuring basic audio
`conferencing functionality among three endpoints
`and subjectively testing audio quality under varied
`bandwidth conditions, has proven successful.
`
`
`
`
`REFERENCES
`
`[1] A. L. Kun, W. T. Miller, W. H. Lenharth,
`“Modular
`System
`Architecture
`for
`Electronic Device Integration
`in Police
`Cruisers,”
`IEEE
`Intelligent Vehicle
`Symposium, Versailles, France, June 18-20,
`2002
`technical
`[2] “CUseeMe Conference Server
`overview,” CUseeMe Networks, 2001
`
`0-7803-7467-3/02/$17.00 ©2002 IEEE.
`
`1341
`
`