Netaxis Solutions SIGMA

Transcription

1 Netaxis Solutions SIGMA Product Description 14/04/2018 Page 1 of 13

2 Contact All enquiries related to the features described in this document can be ed to 14/04/2018 Page 2 of 13

3 Contents 1. Overview Audience Pre-requisites Main features Scenario scripting Scenario scheduling Test Campaigns Heavy Load Testing History Alarms Statistics Service Availability Configuration Objects Description Key Concepts Connector SIP Messages Parameters Scenario Configuration Objects Management Console Launch Scenario Launch SIPp Scenario Scheduler Documentation Commercial packages Dimensioning & Performance Disk usage Memory usage Miscellaneous information Data storage Web Interfaces Configuration Security constraints /04/2018 Page 3 of 13

4 1. Overview This document introduces SIGMA (Simulator for General network Management), the Voice over IP testing and monitoring tool developed by Netaxis Solutions. It intends to provide the information needed to understand the features, architecture, and operations of SIGMA Audience This product description is intended for the following audiences: network operators companies managing partially or totally their VoIP network third-party integrators end-users. Typical users of SIGMA are usually members of an operations' team who need a powerful and flexible tool to test their VoIP network and/or monitor the reachability of some equipment/services in their network Pre-requisites In order to operate, SIGMA needs the following items to be available: One or several servers with a Linux distribution supported by SIGMA with a connectivity to the VoIP network. The Linux distributions currently supported are: Debian Squeeze Red Hat / CentOs 6 or 7 preferred SIGMA can also run on: MacOS 10.x Netaxis Solutions can support other Linux distributions on demand. 14/04/2018 Page 4 of 13

5 2. Main features SIGMA is a centralized VoIP simulator able to reproduce any SIP call scenario in a flexible way. It can be installed in various configurations, going from the unitary test tool to a client-server model. SIGMA supports RTP flow generation for codec 711, G729 and DTMF (telephone-event). SIGMA can be accessed by different users via a web GUI. This GUI provides access to all the features of SIGMA such as the definition of a shared SIP messages library, the creation of call scenarios and their execution. Flexibility being one of the main concerns, SIGMA comes with a powerful scenario scripting language and the possibility to modify every bit of the SIP messages, allowing therefore the user to test and emulate SIP call scenarios with almost no limits. For example, this flexibility can be used to generate non-regression test suites but also to test the robustness of a VoIP element. On top of this, SIGMA offers the possibility to schedule periodic calls and to generate statistics about the service availability in the network, to generate alarms when abnormal events are detected, to access to a detailed history of the calls managed by SIGMA and to generate load testing of VoIP platforms. SIGMA offers also the possibility to build test campaigns. The Test Campaign feature allows grouping scenarios together and runs the whole set of scenarios at regular, configurable intervals. Test campaign results are afterwards available, with details about the successful and failed tests. SIGMA is delivered with predefined SIP scenarios for commonly used SIP call flow, for DoS attacks and for SIP torture (RFC 4475 Malformed SIP messages/call flow) Scenario scripting SIGMA scenario scripting allows to create any kind of SIP call flow. The scenario scripting is based on python script for which specific classes and method have been implemented in order to easily create a SIP call flow and to hide SIP complexities like, for example, call-id/branches creation or cseq/rseq sequence. The scenario scripting inherits from every Python features. It goes from the very basic like condition and loop to much more complex features offering unlimited possibilities: Creation of random behaviour (random ringing duration, random call duration random release cause ) Usage of regular expression to validate scenarios and generate alarms if needed Collect information from files (calling, called number, domain, codecs ) Creation of time dependant scenarios (behaviour will be different depending of the time of the day) Shared variable: variable shared amongst different scripts Scenario scheduling Scenario scheduling allows to schedule the initialization of scenarios on a regular basis. This offers the possibility to define the number of scenarios that must be launched (in parallel) and the periodicity of this initialisation. For example: I would like to launch 10 scenarios every 5 minutes. 14/04/2018 Page 5 of 13

6 This capability to play recurrent calls with several calls in parallel makes the Scheduler a perfect tool to generate load tests or endurance tests Test Campaigns The Test Campaigns feature is an additional operation layer, associating Test cases groups made of Test Cases (a named object made of a Connector, a Scenario and a Parameter Set). For each Test Campaign, its Test case groups are executed in a defined order at specified intervals or with user intervention. Plannings allows planning executions of a test campaign at specified intervals ranging from minutes to day of month. Test Campaigns have a specific History page allowing to visualize easily the general test campaign results and to inspect details for every single test case results. The status of a test (failed or passed) is defined in the scenario meaning that we can used the flexibility of the scenario scripting to declare a test case as successful or not. The status of a test case can be based, for example, on SIP messages sequence, received release cause, content of SIP header 2.4. Heavy Load Testing SIGMA offers the possibility to configure specific scenarios (SIPp scenarios) to generate huge traffic for heavy load testing of specific targets, with or without associated RTP stream. Call flow, call duration, exchanged SIP messages parameters, RTP stream type and files may be completely configured by the user in the scenario configuration. The user can see detailed information of the heavy load tests while in progress and control configuration, call rate and status through a simplified and integrated graphical interface, live and in real time. The heavy-load scenarios are perfectly integrated with SIGMA and the results of each execution is stored in the scenario history as any other standard SIGMA scenario. Reports include call statistics in terms of sent/received/retransmitted packets, successful/failed calls, total number of calls, detailed list of call status' results and errors, duration of the calls and much more. The user has also the ability to control the time of start and duration of the heavy load test, possibly setting a specific day/hour of day or an amount of time in seconds since the start of the scenario. Multiple heavy-load scenarios may be run in parallel allowing to configure different call scenarios for a single target or generating traffic for multiple targets at the same time History SIGMA can store in its database the logs of the last Scenario instances that it has executed. The number of Scenarios kept in the DB is configurable. These logs include all the SIP messages exchanged over the network and specific logs that could have been defined in the Scenario itself. It can also include a configurable summary information to indicate the status of the call (success, failure, on-going, ) Alarms SIGMA can be configured to send alarms when specific events occur in a Scenario execution; this is part of the definition of the Scenario. The following are examples of events: 14/04/2018 Page 6 of 13

7 Absence of RTP Presence/absence of SIP header Abnormal call-flow Incorrect number format These alarms can be sent immediately, or the alarm triggers can be accumulated over a period of time; if a configurable threshold has been reached at the end of this period, the alarm will be generated, otherwise it is cancelled. The threshold and the duration of the observation period are configurable individually in each Alarm definition. The statuses of these alarms are stored in DB in order to prevent any lost due to a restart of SIGMA. The alarms can be sent by or using SNMPv2 traps Statistics SIGMA can generate statistical reports on the call distribution: Successful call Not reachable Redirected call Client error Server error Global failure The Statistics are generated by calling specific APIs in the Scenario definition Service Availability The Service Availability feature is implemented using the combination of the Alarms, the Scheduler and the Statistics features. The purpose of the Service Availability is to monitor the availability/reachability of some specific resources by sending regular calls to them. It generates statistics and throws alarms in case of abnormal events. Several common use cases are presented below:: At regular intervals, one SIGMA instance is calling specific numbers in the network that are managed by a robot in auto-answer mode, and generates alarms when this number cannot be reached or answers with an error. o It can be for example a dedicated number inside a IP-PABX. One SIGMA master is installed in the network of the operator and other instances (SIGMA slaves) are installed on several well-known servers that are expected to be always reachable. The SIGMA master is calling all these slaves at regular intervals and generates alarms when some of them cannot be reached. One SIGMA master is installed in the network of the operator and is listening for incoming calls. The operator has installed SIGMA on Raspberry Pi boxes. On demand, the operator connects these Raspberry Pi at different places of his network that should be monitored (either as preventive action or to analyse an existing problem). As soon as SIGMA is connected, it starts trying to call the SIGMA master and generates alarms if it cannot. 14/04/2018 Page 7 of 13

8 3. Configuration Objects Description 3.1. Key Concepts SIGMA relies on four configuration objects to operate. This section describes these objects Connector A Connector is an object defining the IP configuration. It is composed of a source IP address, source port, destination IP address, and destination port SIP Messages The Message configuration object lets you configure SIP messages in text format. Messages are constructed using in-built parameters (e.g. Call-id) or user parameters defined with the Parameter configuration object Parameters The Parameter object defines a list of parameters that the user will use during scenarios execution (e.g. Calling/called number, domain, Payload type ). Grouped together, parameters form Parameters Sets Scenario The Scenario object allows defining the SIP call flow by using the SIP messages that have been previously defined. Scenario definition can be achieved thanks to a very flexible scenario scripting language. When launching a scenario (using the console or the scheduler), the user must associate a Connector and Parameters. Scenarios can be grouped logically using the Library concept (e.g. library for DOS attack, library for PABX testing, library for IMS testing ). They can also be grouped according to any business logic or strategy using the Test Campaigns object Configuration Objects Management SIGMA offers a web-based interface to manage the libraries of elements that will be used by the other features: Creation, edition, removal, importation and exportation of Connectors. o These connectors will be used to define an IP connectivity: Address and port to be used locally for SIP Address and port of the first proxy to be used to send the messages Creation, edition, removal, importation and exportation of SIP Messages. o These messages allow using placeholders that will behave as variables resolved during scenario execution with values coming either from a Parameters Set or from the network. This allows creating generic messages that can be re-used in multiple scenarios with multiple sets of parameters. 14/04/2018 Page 8 of 13

9 o The flexibility offered at this level allows the user to test almost everything in a VoIP network, for example: New SIP headers or parameters still in draft state or coming from the last RFCs Invalid SIP messages (format, values of some parameters, ) to test the robustness of other VoIP elements (gateways, application server, SBC, ) Creation, edition, removal, importation and exportation of SIP Scenarios. o These Scenarios are built around the Python language with classes and methods to easily receive, send and manipulate messages on a Connector and to generate statistics and alarms. o There are very few restrictions in the definition of these Scenarios: the user can generate both valid and invalid scenarios allowing to test the behaviour of the network in various circumstances. Creation, edition, removal, importation and exportation of SIPp Scenarios. o These Scenarios are specific to heavy load testing. Creation, edition, removal, importation and exportation of Parameters Sets: o These parameters sets will be used to fill the placeholders present in the SIP Messages when a Scenario is instantiated. Typically, they will be elements such as the calling and called party s identities. o The usage of different Parameters Sets allows re-using Scenarios and Messages in different contexts. The packaging of SIGMA includes a set of default Connectors, SIP Messages, Scenarios and Parameters Sets that can be used as examples to build new ones Console Launch Scenario The Console is the standard tool to launch the execution of a SIGMA Scenario with a specific set of parameters on a specific Connector. It allows following in real time the execution of the Scenario instance, with instant access to all the SIP messages exchanged over the network for this Scenario instance. The flexibility of this interface also allows modifying only some of the parameters for this Scenario execution, without having to modify durably the Parameters Set. Example: changing 1 digit in the called party number defined in the Parameters Set. The Console also allows the generation of basic endurance testing by specifying several consecutive executions of the Scenario. Another tool (the Scheduler) allows the generation of a real load test Launch SIPp Scenario SIPp Scenarios are specific to heavy load testing. Launching a SIPp scenario involves running the SIPp program with the configuration specified in the selected SIPp scenario Scheduler The Scheduler has the ability to execute periodically a Scenario on a Connector and using a Parameters Set: this is called Scheduling. 14/04/2018 Page 9 of 13

10 This could be seen as redundant with the Console, but there are a few major differences: The Scheduler runs automatically: as long as SIGMA is running and a Scheduling is active, it will generate calls. This also applies in case of restart of SIGMA. On the contrary, the Console requires a user interaction to start the execution of the Scenario. The Scheduler can run several instances of a Scenario in parallel, while the Console can only run one. The Console can override the value of some parameters of the Parameters Set; this behaviour is not implemented in the Scheduler. 14/04/2018 Page 10 of 13

11 4. Documentation In addition to this Product Description, SIGMA is provided with a User Guide describing in detail the interfaces implementing the features explained in this document. Users of SIGMA are invited to consult it as the help system for SIGMA operations. 14/04/2018 Page 11 of 13

12 5. Commercial packages SIGMA is made of four modules: 1 mandatory module (Basic) and 3 optional ones (Test Campaign, Advanced Monitoring, Load Test) Basic Module: this module includes one-shot scenarios, scheduling, limited load testing and basic statistics/call logs Test Campaign: this module gives the possibility to create a test list (set of scenarios). SIGMA generates a summary of the successful/failed test cases and a possibility to visualize the call flow. Advanced Monitoring: this is the integration with NEMO. All calls generated by SIGMA are monitored by NEMO from where we can get advanced call tracing,.pcpa download, media replay... Load Test: specific module based on SIPp to perform load testing. (Basic call logging and Advanced Monitoring are not possible together with Load Testing). 6. Dimensioning & Performance 6.1. Disk usage SIGMA software with its environment is relatively small: Around 75MB for the SW (including all web browser files) Around 10 MB for the log file. The size of its DB is difficult to estimate as all the objects involved have a variable size. However, except if the operator configures SIGMA to keep thousands of calls in the History, this should remain with values not higher than the SW. This point should only be studied carefully if SIGMA is deployed on a system with very limited HW resources Memory usage The root process of SIGMA is reserving around 27MB of RAM. This memory increases according to the number of Scenarios that are currently executed. In order to improve the performances, the messages displayed in the log of the console are kept in memory. It could therefore increase significantly the RAM used by SIGMA. In order to limit this increase on systems with small amount of RAM, it is possible to configure SIGMA to display only the N last messages by Scenario instance (and therefore the number of messages kept in memory). 14/04/2018 Page 12 of 13

13 7. Miscellaneous information SIGMA is a single multi-threaded process using a database to store its messages library Data storage SIGMA is natively integrated with two databases: SQLite and PostgreSQL. PostgreSQL is the recommended DB for its performance and robustness capabilities. However, for deployment on small devices, PostgreSQL could be too greedy in terms of hardware resources. Therefore, the simple SQLite DB is also supported for these deployments. The user must be aware that it is less reliable than PostgreSQL. This DB is running on the same server as SIGMA. The usage of a remote PostgreSQL DB is also possible but it has impacts on the performance. In project mode, SIGMA could be integrated with other SQL databases on customer request Web Interfaces SIGMA offers a web interface for its complete management in HTTP. It is compatible with the major web browsers, namely Internet Explorer, Firefox and Chrome. It should be also compatible with any other web browsers but without commitment. These web interfaces are described in detail in the User Guide of SIGMA Configuration The core configuration of SIGMA is currently done using a configuration file. Its content is described in detail in the User Guide of SIGMA Security constraints SIGMA has some constraints in terms of ports availability that must be taken into consideration if a firewall is protecting the server where it is installed: It offers a web interface, but the port can be freely configured. It opens UDP ports for SIP messages sending and reception. o The ports are defined in the Connectors. It opens dynamic UDP ports for RTP flows. o The range of ports is configurable. In this range, SIGMA will use only even ports for RTP (RFC3261). o The operator can also force some specific port usage in the SIP Messages or in the Parameters Set, but in that case the simultaneous calls feature of the Scheduler will not work. It can send s. It can send SNMPv2 traps. Netaxis team can assist customer s network architects for these aspects. END OF DOCUMENT 14/04/2018 Page 13 of 13