MAPS™ can be configured as server-side application, to enable remote controlling through multiple command-line based clients. Supported clients include Python, Java, TCL, and others. The MAPS™ APIs allows for programmatic and automated control over all MAPS™ platforms. Each MAPS™ server can receive multiple client connections and offer independent execution to each client. Likewise, a single client can connect to multiple MAPS™ servers, including servers running different protocols, permitting complex cross-protocol test cases.
Client provides a simple scripting language, with programming facilities such as looping, procedures, and variables. The Client application includes a MapsClientIfc.dll file, a packaged library that enables communication with the Server from the client environment. The advantage of such communication enables user to control MAPS™ by sending commands and receiving responses in a scripting language already familiar with many users.
Clients can remotely perform all functions such as start testbed setup, load scripts, and profiles, apply user events such as send digits/file/tones, detect digits/file/tones, dial, originate call, terminate call, start and stop traffic and so on. User can also generate and receive calls through commands. This client application is distributed along with MAPS™ Server application.
MAPS CLI Server
MAPS™ CLI Server is an executable which inherits all features of MAPS™ without GUI. It listens to a TCP message socket to receive and execute commands from client and sends the responses back to client.
CLI Server script execution is Event Driven, i.e., Server detects the Events such as Tone, Digits, Tx File Rx File, Signals, etc., and sets or resets predefined Variables.
- Signaling Events: Signaling events are triggered when any protocol signaling messages are detected such as Offhook, OnHook, Seizure, AnswerCall, PlaceCall, Terminate, & so on.
- Traffic Events: Traffic events are triggered when any traffic other than signaling are detected such as Tone, Digits, File, and others.
TCL Client and TCL Scripting
TCL Client application includes a command-line interface (TClsh85.exe) into which client users may key in commands or load commands from previously saved files.
MAPS™ TCL interface includes MapsClientIfc.dll file, a packaged library that acts as an interface between MAPS™ Server and its TCL users.
A sample CAS TCL script (Send_Tone.tcl) and SIP TCL Script (Send_File.tcl).
MAPS™ Integration with TestShell using TCL Client
TCL provides a simple scripting language, with programming facilities such as looping, procedures, and variables. The TCL Client application includes a MapsTclIfc.dll file, a packaged library that enables communication with the Server from a TCL environment.
MAPS™ TCL Client Interface (MAPS Client IFC) application includes a MapsClientIfc.dll file, a packaged library that enables communication with the MAPS™ Server from a TCL environment. The advantage of such communication enables user to control MAPS™ by sending commands and receiving responses in a scripting language already familiar with many users.
A typical application is with QualiSystems' TestShell as the centerpiece for achieving network wide automation for testing telecom services and telecom network equipment. TestShell software framework offers complete Lab Management, Device Provisioning and Test Automation solutions for engineers.
TestShell has a TCL Client built in, with scripting, drag and drop interface. This makes the system compatible with GL's MAPS™ Protocol Emulation software. TestShell / TCL Client runs TCL scripts which executes commands, that instructs the MAPS™ CLI Server to run a particular script that emulates the state machine to place or answer calls for the protocol specified.
Java / Python Client and Scripting
In addition to existing Tcl and VBS APIs, GL is now offering Python and Java APIs for all variants of MAPS. The API is written using an object-oriented coding paradigm, designed to give the user simple and intuitive containers for their messages, calls and regressions.
Java Client acts as User Interface and interacts with MAPS Client IFC. Java client instructs the MAPS CLI-server to run the particular script which performs the particular test like SIP Registration, Call Control, Traffic handling. Whenever Java client executes a particular section in the script it sends the User Event to perform that action and in turn the server sends the result back to the client using Report events so that the client can take appropriate Actions.
Java Client internally invokes APIs, which are segregated into MAPS API (Mapscli includes MAPS GUI related APIs), Protocol Specific API (Mapscli.isdn includes protocol specific APIs), and End Action Specific API (includes call related APIs used at end terminals).
The API is divided into “High” and “Low” level function calls. High level scripts leave the protocol logic to the underlying call control script on the MAPS server. Meaning, for example when receiving a SIP INVITE, the High Level call control script will immediately and automatically respond with a 100 Trying and 180 Ringing, when it eventually sends the 200 OK it will retransmit in accordance with the RFC.
A Low Level call control scripts transplant that logic to the API language, giving the user full control over signaling. This necessarily leads to more complex API scripts but it gives the user complete control over the state machine.
A sample Java/Python Client script (Isup_PlaceCall.zip) can be downloaded here.
Test Setup for Gateway Testing
As depicted in the figure, complete Gateway testing can be performed through MAPS™ CLI environment.
As shown in the Call Flow diagram below,
- MAPS™ SIP Server and MAPS™ CAS Server are connected through Gateway. Both MAPS™ SIP and MAPS™ CAS servers are controlled via single TCL Client.
- TCL Client instructs SIP server to initiate the call and CAS server to wait for incoming call by detecting Station Ringing.
- MAPS™ SIP server initiates the call by sending INVITE message. MAPS™ CAS server on receipt of the incoming call, responds with a Wink on T1/E1 line to Gateway.
- Once call gets connected, client will instruct both the servers to start generation and reception of Traffic.
- After conversation, client instructs server to terminate call by sending appropriate signaling
The call flow depicts the messages exchanged between MAPS™ SIP to MAPS™ CAS via Gateway, thus testing the Gateway (Device-under-Test)
A Typical MAPS™ CAS Test System
As depicted in the figure below, MAPS™ CAS CLI test system consists of the following:
- TCL user communicating over TCP/IP
- MAPS™ Client IFC, MAPS™ CAS CLI Server, T1 Software (including Windows® Client Server software) and a Dual T1 Card
- Analog Hardware with FXO Cards
- A patch panel for RJ-11 connections to the outside world
A Typical MAPS™ SIP Test System
As depicted in the figure below, MAPS™ SIP CLI test system consists of the following -
- TCL user communicating over TCP/IP
- MAPS™ Client IFC, and MAPS™ SIP CLI Server
Voice Quality Testing
MAPS RTP Core offers integrated, packet-based Voice Quality analysis with the optional licenses. The following screen depicts the Voice Quality statistics performed using python client. (Note that Voice Quality analysis feature is also available in the GUI).
The MAPS API is also now fully integrated with GL’s VQT software which delivers PESQ/POLQA scores (i.e. waveform analysis, rather than packet analysis).
Working Principle of MAPS™ CLI
Shown below is the working principle of the MAP™ CLI Test System.
- Client user (Python, Java, TCL, and others) run client scripts which executes the command that instructs the MAPS™ CLI Server.
- MAPS™ Client interface interprets the User Events from Client user to MAPS™ CLI Server and vice versa.
- MAPS™ CLI Server runs the CLI script which emulates the state machine to place/answer the call or send/receive traffic.
- In case of T1 E1 Protocols, MAPS™ CLI Server additionally interacts with the T1 E1 WCS server to perform the requested task. The reports are generated for the event performed and is sent back to Client user .
MAPS™ CLI Working Principle
MAPS CLI system includes three functional modules, which interact with each other to perform as a single entity:
- Client Environment – client environment acts as a user interface. It can be any scripting tool (automation tool) like Python, Java, TCL, and others, which provides simple scripting language with programming facilities such as looping/procedures/variables/For and While loops, making task execution simpler.
The Client script contains built-in commands which instruct MAPS™ CLI Server to Start/Stop Testbed, Start/Stop Scripts, Apply User Events, Apply Global Variables, Load Profiles, Passing values to the variables, and similarly others.
- MAPS Client IFC - MAPS™ Command Line Interface (CLI) includes MapsClientIfc.dll file, a packaged library that enables communication with the MAPS™ Server from a Client environment. The advantage of such communication enables user to control MAPS™ by sending commands and receiving responses. In other words, it acts as an interface between MAPS™ CLI Server and its client Python, Java, TLC and other application.
- It interprets the client commands and forms the appropriate command as understood by MAPS™ CLI Server and vice versa. MAPS Client IFC dll processes commands received from client and sends to MAPS™ Server, and similarly, responses sent from Server are passed to client.
- It also stores the MAPS™ CLI Server responses into Script Information stored in a variable which are accessed by the client.
- Client can fetch the reports using get command
- MAPS™ CLI Server – is an executable which inherits all features of MAPS™ GUI. MAPS™ CLI Server is a script based frame work which emulates/simulates the entity using proprietary MAPS™ scripts. The CLI Server scripts includes a list of instructions to achieve complete protocol State Machine or any simple call scenarios as per the test requirement.
Please Note: The XX in the Item No. refers to the hardware platform, listed at the bottom of the Buyer's Guide, which the software will be running on. Therefore, XX can either be ETA or EEA (Octal/Quad Boards), PTA or PEA (tProbe Units), UTA or UEA (USB Units), HUT or HUE (Universal Cards), and HDT or HDE (HD cards) depending upon the hardware.