Contents |
The VQManager configuration wizard appears when the user logs into the VQManager client for the first time. This wizard helps to set the initial configurations needed to have VQManager report on the call statistics and call quality information.
The first screen that opens up is the Configuration Wizard Welcome screen with a brief on the three ways of getting your network’s VoIP call traffic details into VQManager.
There are three ways of getting data input into VQManager so as to report on your VoIP call traffic. Each method differs in how quickly the VoIP calls in your environment are reported on by VQManager. The default and recommended option is using the in-built VQManager sniffer.
Using the in-built VQManager sniffer
This is a real-time approach to monitoring VoIP call activity and QoS. VQManager reports & displays packet-level details of VoIP call traffic monitored in this method, thus enabling in-depth diagnosis and troubleshooting of call quality degradations or failures.
By importing Call Detail Records(CDRs) from call servers
This method is not real-time and call statistics and quality information displayed by VQManager will depend on the information contained in the imported Call Detail Records. CDRs are best used for reporting on VoIP traffic from geographically distant locations whose traffic cannot be brought to the VQManager sniffer interface(NIC).
By importing the Call Detail Records as syslog messages
Similar to importing CDRs, this method allows automation of the import process and thus allows quicker 'almost real-time’ reporting on VoIP call traffic.
VQManager can ‘sniff’ traffic through the Network Interface Card(NIC) of the machine that has VQManager installed. You will need to ensure that all your VoIP traffic is directed to the NIC of the VQManager machine. One way of getting this done is by enabling port-mirroring in a managed switch. This link has information on configuring port-mirroring in a number of managed switches like 3Com, Cisco Systems, Linksys, NETGEAR, Avaya etc..
On selecting the sniffing method to report on VoIP call traffic, you will be led to a screen that helps to set various configurations found under two headings: “Protocol Settings” and “Advanced Settings”
VQManager supports monitoring of SIP, H.323, Cisco Skinny(SCCP), RTP and RTCP protocols. Of these, you can choose which protocols you need monitored by selecting the appropriate radio buttons next to the listed protocols. The signaling protocols are globally assigned specific ports and VQManager is set by default to monitor protocol traffic from these standard ports:
SIP: 5060(SIP over UDP only supported)
H.323(H.225 call signaling): 1720 and
Cisco Skinny(SCCP): 2000
You can change these port numbers if your call servers have assigned different ports for the protocols. For each protocol, you can also configure VQManager to listen on “all ports” if the protocols in your environment are using multiple ports. Listening on multiple ports will affect the VQManager server performance and it is advised to set VQManager to listen on one port only for each protocol if such is the case in the environment.
In the “SIP information” section, there is also an option to enable storing of SIP registrations. By storing these, you can have VQManager report on details of registration and unregistration requests made by the phones to the SIP call servers. The registration request details can be found in the “Endpoints” tab of the product’s User Interface. These come in handy when troubleshooting non-availability issues of endpoints.
VQManager can calculate QoS metrics from the RTCP streams, RTP streams and also by taking the QoS values from the "Connection Statistics Response" packets in the case of Cisco Skinny(SCCP) calls.
RTCP(Real Time Control Protocol) packets are generated and transmitted by the endpoints and these provide feedback on the Quality of Service being provided by the RTP(Real Time Transport Protocol)/voice streams. Thus, QoS calculation from RTCP packets provides efficient and accurate QoS reporting as these are from the endpoints themselves. Thus this option requires that the endpoints in the network are enabled with RTCP packet generation.
VQManager can also calculate QoS statistics from the RTP(Real Time Transport Protocol) streams. For complete QoS reporting by this method, it is necessary that RTP packets from both participants of a call are available at the listening interface(NIC).
Note: As endpoints themselves generate RTCP packets, enabling the "RTCP based QoS calculations" will allow VQManager to report closer to user quality experience as compared to calculation of QoS metrics from the RTP packets. It is advised to keep both “RTCP based QoS calculations" and “RTP based QoS calculations" enabled when you are unsure on whether all the endpoints in the network generate the RTCP packets. When both options are enabled, higher precedence is given to RTCP based calculations. In the presence of "Connection Statistics Response" packets in Cisco Skinny calls, these packets are given highest precedence for QoS calculations.
|
This option need not be enabled if your IP Phones are behind a NAT server and the phones have STUN(Simple Transversal of UDP through NATs) to resolve their external IP address. If the phones do not have STUN, then enable this option in VQManager so as to have proper, complete reporting of the QoS metrics.
Enable this option if you want the raw, detailed SIP, Skinny and H.323 packets to be stored and displayed by VQManager. Raw packet information help in troubleshooting call problems.
Promiscuous mode refers to the state when the chosen interface(NIC) sniffs all information in the interface regardless of the destination of the individual packets. In normal mode, the interface sniffs packets/information destined for itself alone. By default, "Promiscuous Mode" is enabled. If you want to disable this, deselect the checkbox
By default, sniffing is enabled to monitor VoIP call traffic in real-time using the in-built sniffer. In case, you wish to use other methods to obtain call information such as parsing the Call Detail Record (CDR) log files generated by call servers or Parsing the CDR logs sent as Syslog Message, you can disable this.
You can provide the pcap filter string here to ensure required packets are only processed by the VQManager sniffer. This filter string expression can be provided in similar syntax as that in the case of WinPcap or Pcap filters. By default, the filter string is tcp || udp || vlan. This filter string allows only tcp, udp and vlan packets to be processed by the VQManager sniffer; all other packets are not processed.
Choose "Log Level" for the messages generated by the sniffer from the drop-down. One of the three levels - DEBUG, SEVERE & INFO can be chosen. The default level is INFO. For VQManager sniffer problem troubleshooting, this can be changed to higher options.
This setting is used to configure VQManager to handle calls whose RTP flow has been stopped for "x" duration of time. Provide the desired duration(in seconds) in the text field. By default, if RTP flow for any call has not been received for more than 30 seconds, this call is considered ended and the call flow diagram will depict "media transmission stopped" as the last packet. These type of calls can be distinguished by status code "8100". To prevent VQManager from terminating RTP interrupted calls, provide '0' seconds as the time duration in the text field.
This setting is used to configure VQManager to handle calls whose signalling flow has been stopped for "x" duration of time. Provide the desired duration(in seconds)in the text field. By default, if signaling flow for any call has not been received for more than 60 seconds, this call is moved to the "Unmonitored" calls category. These calls can be distinguished by status code "8003". To prevent VQManager from categorizing such calls as "Unmonitored", provide '0' seconds as the time duration in the text field.
After saving the protocol settings and other advanced settings, the configuration wizard will auto-detect the interfaces (NICs) present in your machine. The wizard will also look for the available protocols in each interface. Once all available protocols are listed at each interface, you will need to select one interface that the VQManager sniffer will listen to.
Tips: If there are no protocols detected on any interface:
|
After selecting an inteface to monitor on, save the settings. You will then see the summary of all settings configured for the VQManager sniffer. You can also go back and re-configure from this summary screen.
Call Detail Records(CDRs) are files that are generated by call servers/ callmanagers/ gateways or other call routing devices. These files have a record of all the calls that have happened in the network. CDR files can be of many formats like .xls, .csv, .xml etc. By importing these CDR files, VQManager can report on the call information and quality statistics present in these files. Since these files are generated after the calls having taken place, this method of call traffic reporting by VQManager will not be in real-time and the information displayed will depend on that available in the CDRs.
This method of reporting is best used for reporting on VoIP traffic from geographically distant locations whose traffic cannot be brought to the VQManager sniffer interface(NIC).
VQManager supports .csv formats of the following CDR types:
Vocal CDR Format
Cisco CallTracker CDR Format
Asterisk CDR Format
Cisco Call Manager 4.x and 5.x CDR
Cisco Call Manager 5.0 CDR/CMR
Shoretel 6.1
Swyx 6.0
Tekelec 5.6
PortaOne
On clicking the CDR import option, you will be led to a screen inside the product that helps you to import the CDR files either from the local machine, or on a remote machine:
In the UI that opens, click the link "Import CDR File" icon available in the top-right corner
If the CDR log file is available in your local computer, just browse to the file location and click "Import". This is suitable for the processing of small size files
If the CDR log file is available in a remote machine, you can configure the server to download the CDR log files periodically from a remote location using FTP
Click "Remote Location" and fill-in the details such as the hostname and IP of the machine, username and password to access the system
Browse to the location of the file or the directory in which the CDR files are present, specify the periodic time interval (in seconds) during which the files are to be parsed and uploaded automatically and then click "'Import". This is suitable for large files that need to be processed periodically. VQManager can identify new CDR log files in a directory and will automatically import the new content
A log of all the imported CDR logs will be displayed as a list below
VQManager can be configured as a syslog server to receive CDRs as syslog messages from a call server eg. the CallManager Express can be configured to send the CDRs as syslog messages to VQManager. This method automates the sending of CDRs to VQManager and also enables one to have 'almost real-time' reporting of call traffic by configuring the sending of syslog messages(CDRs) in very short intervals. A syslog port (in the VQManager machine) listens to the syslog messages. The call server is configured to send the CDRs as syslog messages to this port.
On choosing this method you will be led to a screen that helps set VQManager as a syslog server:
Click on the “Add Syslog Server” icon seen on the right hand side.
Provide a “Name” to the Syslog Server you wish to configure
Provide the “Port” number through which you want the VQManager product to listen on for the syslog messages. By default the product listens for syslog messages on port 514.
The “IPAddress” displayed is the default IP Address of the system in which the VQManager server is installed in. As VQManager listens on ANY address, no change would be required to be done on this field.
Click on the " Add" button to configure the Syslog server.
The Syslog servers list is displayed as a list with columns “Name”, “IPAddress”, “Port”, “Status” and “Action”.
You can stop a Syslog server by clicking on the " Stop" icon under the “Action” column of the list. You can get the same Syslog server to start again by re-clicking the same icon, which would now be showing ‘Play’.
Syslog Servers can be deleted by clicking on the dustbin "Delete" icon under the "Action" column of the list.
|
Next Section covers ....
|
Copyright © 2008, AdventNet Inc. All Rights Reserved.