VoIP Monitoring Environment based on SNMP - VMES

VoIP Monitoring Environment based on SNMP - VMES Fausto Vetter, Trainee, Interoperability Laboratory Interop, NPD/UFSC fvetter@npd.ufsc.br Abstract-- This paper proposes a monitoring environment for Voice over Internet Protocol service. A Management Information Base was created because one was not commercially available. The main reason for monitoring VoIP services was to assure Constant Bit Rate traffic. The solution was to create a simple environment to monitor these services using Simple Network Management Protocol. To do this it was necessary to understand mainly the monitoring protocol and the approach it uses for monitoring network instances. Finally, this paper also proposes an Extensible Agent, which collects information from the VoIP environment and feeds it to the MIB. Index Terms-- AgentX, H.323, MIB, SNMP, VoIP. AgentX: CBR: DNS: DTE: J.AgentX: H.323: MIB: PSTN: SNMP: VMES: VoIP: I. NOMENCLATURE Extensible Agent Constant Bit Rate Domain Name System Data Terminal Equipment Java Extensible Agent Standard protocol for VoIP environments Management Information Base Public Switched Telephone Network Simple Network Management Protocol VoIP Monitoring Environment based on SNMP Voice over Internet Protocol II. INTRODUCTION OICE over Internet Protocol (VoIP) will become an Vimportant aggregated function for organizations in the near future. This kind of service will be running over data networks and, for this reason, competing for the same resources. It will become necessary to monitor the availability of this service. By doing this it will be possible to employ existing monitoring services on data networks for this kind of service. Today, traffic, created by voice and data, flows on different types of network. Voice traffic is carried by Public Switched Telephone Networks (PSTNs), while data streams usually using Packet-Switched Data Transmission Service [1]. Integration of data, multimedia and voice conveying over the same network is a strong trend today. Circuit switched networks are being substituted by packet switched networks as The author thanks for funding help. This work was supported by Núcleo de Processamento de Dados (NPD) / UFSC. the way to offer these types of services. Packet switching does not create a path between Data Terminal Equipments (DTEs) prior to the beginning of a call [1]. So, VoIP service availability takes on an important roll in these conditions. Traffic generated by concurrent types of services will be sharing the same network to send and receive flows. Traffic routing is done independently for each new packet on a current call, which implicates the use of different paths depending on the current state of the network [2]. Monitoring this service is important in order to achieve the desired quality for voice encountered on switched networks, because it requires a Constant Bit Rate (CBR) [2]. Network monitoring is an important tool for pro-active reaction on failures. When moving the voice service to data networks, it is interesting to manage this service using existing tools for data services. The Simple Network Management Protocol (SNMP) is the standard protocol for monitoring TCP/IP networks. SNMP is not only used for network equipment management, but it is also possible to use it to manage services such as hardware features, databases and many others. As this protocol may be used for monitoring services, voice services might be monitored using SNMP. SNMP is based on two basic concepts for monitoring. It uses agents and managers [3]. Agents are data collectors. They collect the information to be managed and organize this information on a Management Information Base (MIB) [4]. A MIB is a formal database organized like a tree. Variables to be monitored are the leaves of this tree. Values of these variables demonstrate the status of a monitored entity. On the other hand, managers talk to agents to get the values of such variables. Based on historical information about what is being monitored, they demonstrate its current status. Based on all of the above facts, this article proposes a standalone MIB as a simple way for monitoring VoIP services. III. PROPOSED MIB This MIB was developed based on information needed by and returned from the tester software for the H.323 protocol. The name of the software is Open H.323 Call Generator [5]. This software runs tests on the VoIP environment and returns information for analysis of the service. A. Defining MIB Objects First thing to be done prior to defining the objects is analyzing the Open H.323 Call Generator command line: 370

callgen323.exe -g <gatekeeper> -u <callingnumber> <callednumber> -i <callingipaddress> -r <calltimes> -O file.wav Fig. 1. Open H.323 Call Generator command line Upon analyzing the command line above, it becomes clear that it is important that the following variables be present in the MIB: Gatekeeper; Calling Number; Called Number; Calling IP address; Call times. It is also important to clarify why the sound file, the -O file.wav in the command line, was not considered central in this implementation. The purpose of this is not to allow customized calls, but to perform tests over the operating environment, thus the message sent on a call is not relevant. After having the information to run the test, key information from the results that showed up were considered for this accomplishment. The output line information is shown in figure 2: D:\>callgen323.exe -g gatekeeper.voip.ufsc.br -u 01234567 98765432 I 192.168.0.1 r 10 -O D:\file.wav Listening on: Listener[ip$192.168.0.1:1720] Using outgoing message file: D:\file.wav Not saving incoming audio data. Local capabilities:... Local username: "01234567" Registering with gatekeeper "gatekeeper.voip.ufsc.br"... Gatekeeper set to "GKUFSC@gatekeeper.voip.ufsc.br" Endpoint starting 1 simultaneous call 10 times, grand total of 10 calls. 1: Initial delay of 0.130 seconds Press ENTER at any time to quit.... All call sets completed. Total calls: 10 attempted, 10 established Fig. 2. Results from Open H.323 Call Generator Upon analyzing the output, only two variables were considered more relevant: total calls attempted and established. The cause for choosing just these two variables is because from these two it is possible to know just in time information gathered and being aware of the actual status from the VoIP service. From these variables, it was created other historical variables shown below: Total calls count; Total success calls count. Other variables considered were: Test code; Test executions count; Last call time. B. MIB Organization The MIB created from the information gathered was organized like figure 3: Enterprises.UFSC.NPD.projetos.voip.caller - cladd - clremove - clset - cltable - clentry - clcode - clgatekeeper - clcallednumber - clcallingnumber - clcallingipaddress - clexeccount - cllastcalltime - cllastcallcount - cllastcallsuccesscount - cltotalcallcount - cltotalcallsuccesscount - clcalltimes Fig. 3. VoIP MIB hierarchy Observing the hierarchy created above for this MIB, it is significant to explain the need of three auxiliary variables for this MIB: 1. cladd: this variable is needed because SNMP does not have a way by itself to add a new line on a table [5]. One way to achieve this, it is having a variable, which is associated to a create command to add the new line after a set command. 2. clremove: the same reason as adding a line to a table is applicable when removing a line from a table. 3. clset: this variable is used to identify which line is going to be modified on an set operation. Prior doing an update, it is needed to set this variable to the line number. Variables are identified by Object Identifiers (OIDs) in SNMP. OIDs are unique identifiers for each object. It is forbidden to reuse an identifier after publishing it. The MIB tree variables have the OIDs listed at Table I: TABLE I OID VOIP MIB HIERARCHY OID Object.1.3.6.1.4.1.7687.2.1.1 voip.1.3.6.1.4.1.7687.2.1.1.1 caller.1.3.6.1.4.1.7687.2.1.1.1.1 cladd.1.3.6.1.4.1.7687.2.1.1.1.2 clremove.1.3.6.1.4.1.7687.2.1.1.1.3 clset.1.3.6.1.4.1.7687.2.1.1.1.4 cltable.1.3.6.1.4.1.7687.2.1.1.1.4.1 clentry.1.3.6.1.4.1.7687.2.1.1.1.4.1.1 clcode.1.3.6.1.4.1.7687.2.1.1.1.4.1.2 clgatekeeper.1.3.6.1.4.1.7687.2.1.1.1.4.1.3 clcallednumber.1.3.6.1.4.1.7687.2.1.1.1.4.1.4 clcallingnumber.1.3.6.1.4.1.7687.2.1.1.1.4.1.5 clcallingipaddress.1.3.6.1.4.1.7687.2.1.1.1.4.1.6 clexeccount.1.3.6.1.4.1.7687.2.1.1.1.4.1.7 cllastcalltime.1.3.6.1.4.1.7687.2.1.1.1.4.1.8 cllastcallcount.1.3.6.1.4.1.7687.2.1.1.1.4.1.9 cllastcallsuccesscount.1.3.6.1.4.1.7687.2.1.1.1.4.1.10 cltotalcallcount.1.3.6.1.4.1.7687.2.1.1.1.4.1.11 cltotalcallsuccesscount.1.3.6.1.4.1.7687.2.1.1.1.4.1.12 clcalltimes Each variable created has a different meaning on the MIB context. Some are for identification, testing, historical, or resulting purposes. The meanings of such variables are shown below at Table II: TABLE II VARIABLES MEANINGS Variable Purpose Meaning clcode Identification Codes a test. clgatekeeper Testing Gatekeeper on a test (IP or DNS name). clcallednumber Testing Called party on a test. clcallingnumber Testing Calling party on a test. clcallingipaddress Testing Calling IP address party on a test. clexeccount Historical Count test executions. cllastcalltime Resulting Time of last test. cllastcallcount Resulting Number of calls on last test. cllastcallsuccesscount Resulting Number of success calls on last test. cltotalcallcount Historical Number of calls on all tests. cltotalcallsuccesscount Historical Number of success calls on all tests. clcalltimes Testing Identify number of calls 371

on a test. IV. MONITORING ENVIRONMENT Any service, which needs SNMP monitoring, needs to implement a SNMP agent to gather the information from what is being monitored. So, it is not different for VoIP. The architecture of VMES is shown at figure 4: Fig. 4. Agent Architecture The reason for choosing the above architecture is because it would be easier on implementation, just needing to implement Create Line, Subagent and Collect Information sub-modules. Core Agent module used was J.AgentX [6]. A. Core Agent Module The Core Agent Module implements both SNMP standard MIBs and the VoIP standalone MIB proposed in this paper. Besides it, this module answers to Get, Set and Trap SNMP commands. This module was implemented using J.AgentX, an extensible agent created by University of Coimbra [6]. This module has the architecture seen in figure 5: Fig. 5. Core Agent Architecture This architecture follows the defined Agent Extensibility Protocol version 1. This protocol stands an Extensible Agent Module, which implements pattern MIBs like MIB II and implements the basic functions of Set, Get and Trap for defined Read and Write Communities, which talk to the manager [7]. The second sub-module, the Subagent, is responsible for defining an extended MIB, which is not on the SNMP standard just like the VoIP MIB proposed on this paper [7]. It is also defined Set, Get and Trap procedures for variables on the implemented MIB in this second sub-module [7]. B. Starter Module The Starter Module implements the function of adding a new line to the table called cltable of the VoIP MIB. This module is composed by a single sub-module which is the Create Line. SNMP does not have a way of creating a new line on an SNMP table by itself, so the solution found was setting an auxiliary variable [5]. When the auxiliary variable cladd is set by a SNMP Set command, it triggers an adding command into the table on the Subagent module. This command is very simple. It just sets new leaves on the MIB using SNMP Set commands. It is important to notice one thing: this module just sends a SNMP Set command to the cladd variable in the MIB, and the adding function is actually implemented on the Subagent module. This solution was also used when removing a line from the table, but this uses the auxiliary variable clremove. And also, when updating information into the MIB, the auxiliary variable clset is set to an existing line of the table, and then, the responsibible to update the variables value is the VoIP agent administrator. It is significant to notice remove and update procedures are not implemented in the Create Line sub-module. To do this it should use a MIB browser or something like that. C. Collector Module This module is responsible to gather the information from a VoIP test and to update it into a MIB record. This module is divided in two sub-modules: the Collect Information and the Caller Sub-modules. The Caller sub-module is actually an existing VoIP tester sofware, the Open H.323 Call Generator [5]. It just executes a number of calls between two VoIP numbers. These numbers are defined on two MIB variables: clcallednumber and clcallingnumber. The clcallednumber defines the called partner. Opposite, the clcallingnumber defines the calling partner. The returned information is the numbers of accomplished calls, and also, successful ones. The Collect Information sub-module is actually the one which triggers a call test on the caller sub-module based on existing information in the MIB. After the test is finished, it interprets the results from the Caller sub-module and updates the information into the MIB. D. Modules Interaction Sequence The communication flow among modules is an important factor to be considered on this implementation. This defines how the agent will start and make the tests on the VoIP environment. The two main sequences are shown in this paper: the first referring to how it starts and the second referring to how it collects information from tests and save the results into the VoIP MIB table. It is shown the agent starting sequence at figure 6: 372

Fig. 8. UFSC VoIP environment Fig. 6. Agent Starting Sequence Following it is displayed the VoIP testing sequence at figure 7: It was possible to assure MIB browser works appropriately on VMES environment and VoIP MIB proposed. An overview of a MIB browser may be seen at figure 9: Fig. 9. WhatsUp Mib Browser Besides a MIB browser, which shows just in time variables value, historical information might be collected using integration with MRTG [9]. This incorporation permits the administrator to supervise availability of the VoIP service over time. An overview may be seen at figure 10: Fig. 7. VoIP Testing Sequence V. STUDY CASES The main cases of success using this environment were when integrating it with MibBrowser [8], MRTG [9] and WhatsUp [8]. The main study case adopted on testing the proposed environment was done at Núcleo de Processamento de Dados (NPD) of Universidade Federal de Santa Catarina (UFSC). The VoIP infrastructure of UFSC is shown in figure 8: Fig. 10. MRTG Graphs 373

The VoIP environment was also integrated with WhatsUp [8]. This union helps network managers to discover the actual status of VoIP service. Managers may define any desired quality to measure the service depending on different network conditions. This integration may be seen in figure 11: [4] M. Rose, K. McCloghrie. Concise MIB Definitions. Network Working Group. Request for Comments: 1212. March 1991. [5] OpenH323 Project. Open H.323 Call Generator. Copyright OpenH323 Project. Available: http://www.openh323.org/ [6] University of Coimbra. J.AgentX. Copyright 2000 University of Coimbra, Portugal. Available: http://eden.dei.uc.pt/agentx/ [7] M. Daniele, B. Wijnen, M. Ellison, D. Francisco. Agent Extensibility (AgentX) Protocol Version 1. Network Working Group. Request for Comments: 2741. January 2000. [8] IpSwitch, Inc. What s Up Gold Version 8.03HF1. Release: 12/19/2003. Copyright 1996-2003 Ipswitch, Inc. Available: http://www.ipswitch.com/ [9] Multi Router Traffic Grapher (MRTG). Available: http://people.ee.ethz.ch/~oetiker/webtools/mrtg/ X. BIOGRAPHIES university. Fausto Vetter was born in Videira, Brazil, on September 20, 1984. He is a graduating student of Computer Information Systems at Universidade Federal de Santa Catarina (UFSC). His employment experience includes working at Núcleo de Processamento de Dados (NPD) of UFSC. His work is on monitoring the network environment of Fig. 11. WhatsUp Services VI. FUTURE WORK The author proposes a better study on the VoIP MIB structure and on the caller module, because it is possible to obtain more information for enhanced monitoring. Another significant module for VMES would be a user interface to add, update or delete VoIP tests. Finally, an important improvement would be a better integration among the modules. VII. CONCLUSION VoIP will be running on enterprises very soon. It is going to be necessary monitoring and having a fast way to solve problems for guaranteeing a good service. This tool showed in this paper is the beginning to do this. It also permits a better way to monitor the conditions of VoIP. It will not just help network administrators, but also companies, summing better quality on served services. VIII. ACKNOWLEDGMENT The author gratefully acknowledges the contributions of E. Melo, S. Moller, G. Rhoden, F. K. Martins, and F. Cerutti for their work on studies for creating the environment and for the original version of this document. Also, a special thanks for M. Schmidt, J. Escudero and M. Vetter for reviewing this paper. IX. REFERENCES [1] The Institute for Telecommunications Sciences, Glossary of Telecommunications Terms. Available: http://glossary.its.bldrdoc.gov/fs-1037/ [2] W. Stallings, ISDN and Broadband ISDN with Frame Relay and ATM, Prentice Hall, 3 rd Edition, 1995. [3] J. Davin, J. Galvin, K. McCloghrie. SNMP Administrative Model. Network Working Group. Request for Comments: 1351. July 1992. 374