mvts pro 1.9.0-21 administrator's manual eng

MVTS Pro 1.9.0-21 Administrator's manual © 2015 SwitchRay Inc. Document type: Administrator's manual Release date: 02.03.2015 Document status: Released Document version 1.9.0-21 Copyright © 2007-2015 SwitchRay Inc. All rights reserved. SwitchRay Inc. reserves the right to change any information contained in this document without prior notice. COPYRIGHT INFORMATION The information contained in this document is the property of SwitchRay Inc.. No part of this publication may be reproduced or copied in any form or by any means - graphic, electronic or mechanical including photocopying, recording, taping, or any other information storage and retrieval system - without written consent of SwitchRay Inc.. No third party, organization or individual, is authorized to grant such permission. Contents 3 Contents 1 Intoduction 10 ........................................................................................................................ 10 1.1 Document profile ........................................................................................................................ 10 1.2 Audience ........................................................................................................................ 10 1.3 Notational conventions ........................................................................................................................ 10 1.4 Documentation 10 1.5 Names,........................................................................................................................ Phone Numbers and Network Addresses ........................................................................................................................ 11 1.6 Terms and acronyms 2 System overview 14 14 2.1 System........................................................................................................................ make-up ........................................................................................................................ 14 2.2 API 3 Security requirements 15 4 MVTS Pro Web interface 16 ........................................................................................................................ 16 4.1 What you see on the screen ........................................................................................................................ 17 4.2 Standard procedures .......................................................................................................................................................... 17 4.2.1 Accessing TM’s GUI .......................................................................................................................................................... 18 4.2.2 Pop-up menu .......................................................................................................................................................... 19 4.2.3 Use of filters .......................................................................................................................................................... 26 4.2.4 Sorting table data .......................................................................................................................................................... 26 4.2.5 Re-arranging table columns 27 4.2.6 Table.......................................................................................................................................................... autorefresh .......................................................................................................................................................... 27 4.2.7 Editing multiple table records 28 4.2.8 Data .......................................................................................................................................................... export .......................................................................................................................................................... 29 4.2.9 Component version view 30 4.2.10 Menu.......................................................................................................................................................... for tree's items .......................................................................................................................................................... 30 4.2.11 Creating objects in the web-interface 5 Operating TM 32 ........................................................................................................................ 32 5.1 Administration .......................................................................................................................................................... 32 5.1.1 System users 33 5.1.2 Web.......................................................................................................................................................... authentication .......................................................................................................................................................... 34 5.1.3 Roles 34 5.1.4 Role .......................................................................................................................................................... settings .......................................................................................................................................................... 35 5.1.5 System user creation wizard 37 5.1.6 Web.......................................................................................................................................................... realms ........................................................................................................................ 38 5.2 Equipment .......................................................................................................................................................... 39 5.2.1 Equipment Page 3 Administrator's manual 4 .......................................................................................................................................................... 59 5.2.2 Default gateway endpoints .......................................................................................................................................................... 61 5.2.3 Zones .......................................................................................................................................................... 61 5.2.4 Codecs .......................................................................................................................................................... 64 5.2.5 Codec groups .......................................................................................................................................................... 65 5.2.6 Codec group setup 67 5.2.7 CPS .......................................................................................................................................................... limitation .......................................................................................................................................................... 67 5.2.8 Balancing groups .......................................................................................................................................................... 68 5.2.9 Media groups 68 5.2.10 RPS .......................................................................................................................................................... limitation .......................................................................................................................................................... 69 5.2.11 Redirect reason translations ........................................................................................................................ 69 5.3 Termination .......................................................................................................................................................... 70 5.3.1 Pre-routing translations .......................................................................................................................................................... 74 5.3.2 Dial peers .......................................................................................................................................................... 79 5.3.3 Routing policies 82 5.3.4 Tree .......................................................................................................................................................... of Dial Peers (DPs) .......................................................................................................................................................... 83 5.3.5 SIP-routing groups .......................................................................................................................................................... 84 5.3.6 Meter Pulse Message Tariffs (MPM Tariffs) ..................................................................................................................................................................... 84 5.3.6.1 Tariffs ..................................................................................................................................................................... 85 5.3.6.2 Tariff setup ........................................................................................................................ 85 5.4 Debugging .......................................................................................................................................................... 86 5.4.1 Call simulation .......................................................................................................................................................... 87 5.4.2 Call debugging rules .......................................................................................................................................................... 89 5.4.3 Debug calls .......................................................................................................................................................... 92 5.4.4 Debug registrations 93 5.5 Traffic ........................................................................................................................ Switch .......................................................................................................................................................... 93 5.5.1 TS CLASS 4 conferences .......................................................................................................................................................... 93 5.5.2 TM CLASS 4 calls .......................................................................................................................................................... 94 5.5.3 TS CLASS 5 legs .......................................................................................................................................................... 94 5.5.4 TS incoming registrations .......................................................................................................................................................... 95 5.5.5 TM incoming registrations .......................................................................................................................................................... 95 5.5.6 Nodes .......................................................................................................................................................... 96 5.5.7 Active nodes .......................................................................................................................................................... 97 5.5.8 SS7 calls 97 5.5.9 ISUP.......................................................................................................................................................... circuits .......................................................................................................................................................... 99 5.5.10 MGCP endpoints .......................................................................................................................................................... 100 5.5.11 M3UA associations .......................................................................................................................................................... 100 5.5.12 Reserved circuit groups 5.6 CDRs ........................................................................................................................ 101 .......................................................................................................................................................... 106 5.6.1 CDRs scheduled export ..................................................................................................................................................................... 107 5.6.1.1 Scheduled export settings ..................................................................................................................................................................... 112 5.6.1.2 Scheduled export algorithm ..................................................................................................................................................................... 112 5.6.1.3 Correspondence of exported file fields and CDR fields Page 4 Contents 5 5.6.1.4 Configuring authentication by SSH keys when unloading ..................................................................................................................................................................... 120 CDRs to SFTP server ..................................................................................................................................................................... 121 5.6.1.5 Examples of exported files .......................................................................................................................................................... 123 5.6.2 Export interval .......................................................................................................................................................... 123 5.6.3 Export debugging 123 5.6.4 CDR.......................................................................................................................................................... post-processing .......................................................................................................................................................... 123 5.6.5 Inaccurate CDRs ..................................................................................................................................................................... 123 5.6.5.1 Table of inaccurate CDRs ..................................................................................................................................................................... 125 5.6.5.2 Scheduled transfer ..................................................................................................................................................................... 126 5.6.5.3 Duplicate CDRs ........................................................................................................................ 128 5.7 Statistics .......................................................................................................................................................... 128 5.7.1 Reports .......................................................................................................................................................... 132 5.7.2 Charts ........................................................................................................................ 135 5.8 Global settings .......................................................................................................................................................... 136 5.8.1 System global settings 139 5.8.2 Web.......................................................................................................................................................... settings .......................................................................................................................................................... 141 5.8.3 Disconnect codes .......................................................................................................................................................... 141 5.8.4 ISUP national standards .......................................................................................................................................................... 142 5.8.5 ENUM-servers 144 5.8.6 DNS.......................................................................................................................................................... servers .......................................................................................................................................................... 144 5.8.7 Areas 144 5.8.8 Area.......................................................................................................................................................... specifics .......................................................................................................................................................... 145 5.8.9 Calling party’s categories 145 5.8.10 CPC.......................................................................................................................................................... translations .......................................................................................................................................................... 146 5.8.11 Capacity groups .......................................................................................................................................................... 147 5.8.12 Number capacity groups .......................................................................................................................................................... 148 5.8.13 Model codecs .......................................................................................................................................................... 148 5.8.14 Model RADIUS attributes 150 5.8.15 CDR.......................................................................................................................................................... tables .......................................................................................................................................................... 151 5.8.16 Custom views .......................................................................................................................................................... 152 5.8.17 Custom languages .......................................................................................................................................................... 152 5.8.18 Custom translations 5.9 Logs ........................................................................................................................ 153 153 5.9.1 Web.......................................................................................................................................................... authentication history 154 5.9.2 Web.......................................................................................................................................................... activity log 5.10 Import........................................................................................................................ 154 ........................................................................................................................ 158 5.11 RADIUS settings .......................................................................................................................................................... 158 5.11.1 RADIUS global settings .......................................................................................................................................................... 161 5.11.2 RADIUS servers .......................................................................................................................................................... 163 5.11.3 RADIUS attributes .......................................................................................................................................................... 168 5.11.4 RADIUS accounting packets .......................................................................................................................................................... 170 5.11.5 RADIUS accounting profiles .......................................................................................................................................................... 173 5.11.6 RADIUS groups Page 5 Administrator's manual 6 .......................................................................................................................................................... 173 5.11.7 An example of RADIUS accounting configuration ..................................................................................................................................................................... 173 5.11.7.1 RADIUS server declaration ..................................................................................................................................................................... 174 5.11.7.2 Using predefined or custom profiles ..................................................................................................................................................................... 175 5.11.7.3 RADIUS attributes configuration ..................................................................................................................................................................... 175 5.11.7.4 RADIUS packet configuration ..................................................................................................................................................................... 176 5.11.7.5 RADIUS profile configuration ........................................................................................................................ 177 5.12 SS7 Call Agent node configuration 177 5.12.1 SS7.......................................................................................................................................................... Call Agent nodes .......................................................................................................................................................... 179 5.12.2 Node parameters ..................................................................................................................................................................... 179 5.12.2.1 List of invalid records ..................................................................................................................................................................... 179 5.12.2.2 Wizards 179 5.12.2.2.1Copy ......................................................................................................................................... the settings of the current node ......................................................................................................................................... 181 5.12.2.2.2 Signaling gatew ay ................................................................................................................................... 181 Add a signaling gatew ay ................................................................................................................................... 185 Edit a signaling gatew ay ................................................................................................................................... 187 Delete a signaling gatew ay 188 5.12.2.2.3Media......................................................................................................................................... gatew ay ................................................................................................................................... 188 Add media gatew ay ................................................................................................................................... 191 Edit media gatew ay ................................................................................................................................... 191 Delete media gatew ay 5.12.2.2.4 Station......................................................................................................................................... 192 ................................................................................................................................... 192 Add a station ................................................................................................................................... 194 Delete a station 5.12.2.2.5Trunk......................................................................................................................................... 194 ................................................................................................................................... 194 Add trunk ................................................................................................................................... 196 Delete trunk ..................................................................................................................................................................... 197 5.12.2.3 M3UA 197 5.12.2.3.1SCTP......................................................................................................................................... endpoints ......................................................................................................................................... 197 5.12.2.3.2 Associations ......................................................................................................................................... 198 5.12.2.3.3Signaling processes (SP) ......................................................................................................................................... 198 5.12.2.3.4 Signaling gatew ays (SG) ......................................................................................................................................... 199 5.12.2.3.5Routing contexts ......................................................................................................................................... 199 5.12.2.3.6Application servers (AS) ......................................................................................................................................... 200 5.12.2.3.7Routing keys ......................................................................................................................................... 200 5.12.2.3.8Routing key's elements list ......................................................................................................................................... 200 5.12.2.3.9Remote node's elements list 201 5.12.2.3.10Local ......................................................................................................................................... nodes ......................................................................................................................................... 201 5.12.2.3.11Remote nodes ......................................................................................................................................... 202 5.12.2.3.12 Netw ork appearance ......................................................................................................................................... 202 5.12.2.3.13SS7 netw orks 203 5.12.2.3.14 M3UA......................................................................................................................................... configuration ..................................................................................................................................................................... 203 5.12.2.4 MGCP Page 6 Contents 7 204 5.12.2.4.1MGCP......................................................................................................................................... endpoints 204 5.12.2.4.2 MGCP......................................................................................................................................... endpoints groups 205 5.12.2.4.3Media......................................................................................................................................... gatew ays 206 5.12.2.4.4 MGCP......................................................................................................................................... local instances ..................................................................................................................................................................... 207 5.12.2.5 ISUP/Call Control 5.12.2.5.1Timers......................................................................................................................................... 207 ......................................................................................................................................... 207 5.12.2.5.2 ISUP Connections ......................................................................................................................................... 210 5.12.2.5.3Circuits ........................................................................................................................ 210 5.13 Support of SS7 national standard of Finland .......................................................................................................................................................... 210 5.13.1 Configuration of SS7 gateway .......................................................................................................................................................... 211 5.13.2 Configuration of SIP-T/I gateway ..................................................................................................................................................................... 211 5.13.2.1 Configuration of SIP-T/I gateway for outgoing call ..................................................................................................................................................................... 211 5.13.2.2 Configuration of SIP-T/I gateway for incoming call 6 MVTS Pro Redundancy 212 ........................................................................................................................ 212 6.1 Continuous services and correct entry of CDRs ........................................................................................................................ 212 6.2 Two-server redundancy configuration ........................................................................................................................ 213 6.3 Four-server redundancy configuration ........................................................................................................................ 214 6.4 Control links interval settings 215 6.5 Node ........................................................................................................................ behaviour during crashes .......................................................................................................................................................... 215 6.5.1 Media Node .......................................................................................................................................................... 215 6.5.2 Signaling node .......................................................................................................................................................... 216 6.5.3 Scripting node .......................................................................................................................................................... 216 6.5.4 Balancer node 216 6.5.5 SS7.......................................................................................................................................................... Call Agent node .......................................................................................................................................................... 217 6.5.6 Synchro node .......................................................................................................................................................... 217 6.5.7 Database ........................................................................................................................ 217 6.6 License Management node redundancy ........................................................................................................................ 218 6.7 SS7 Call Agent node redundancy ........................................................................................................................ 218 6.8 DB and WEB interface server redundnacy ........................................................................................................................ 218 6.9 Configuring pacemaker for TS redundancy schemes ........................................................................................................................ 219 6.10 Redundancy scheme with one active node .......................................................................................................................................................... 219 6.10.1 General information .......................................................................................................................................................... 221 6.10.2 Scheme functioning .......................................................................................................................................................... 223 6.10.3 Description of failover protection and scheme restrictions 224 6.10.4 How.......................................................................................................................................................... to configure scheme ..................................................................................................................................................................... 226 6.10.4.1 Command scripts for primary server ..................................................................................................................................................................... 227 6.10.4.2 Command scripts for backup server ........................................................................................................................ 229 6.11 Redundancy scheme with several active nodes .......................................................................................................................................................... 229 6.11.1 General information .......................................................................................................................................................... 230 6.11.2 Configuring general scheme ..................................................................................................................................................................... 232 6.11.2.1 Command scripts for primary server ..................................................................................................................................................................... 232 6.11.2.2 Command scripts for backup server Page 7 Administrator's manual 8 .......................................................................................................................................................... 233 6.11.3 Configuring scheme for several network interfaces/VLAN ........................................................................................................................ 237 6.12 Transit from heartbeat to pacemaker ........................................................................................................................ 238 6.13 DB backup and recovery .......................................................................................................................................................... 238 6.13.1 DB specifics affecting backup policy .......................................................................................................................................................... 238 6.13.2 Backup tools and utilities .......................................................................................................................................................... 238 6.13.3 Configuring SSH public key authentication .......................................................................................................................................................... 239 6.13.4 Configuring DB backup .......................................................................................................................................................... 240 6.13.5 Launching backup .......................................................................................................................................................... 240 6.13.6 Unattended backup arrangements .......................................................................................................................................................... 240 6.13.7 DB recovery procedure ........................................................................................................................ 240 6.14 DB Replication .......................................................................................................................................................... 241 6.14.1 Replication types .......................................................................................................................................................... 241 6.14.2 Replication configuration 7 Appendix A. Metacharacters, regular expressions and number transformation 244 244 7.1 Use of........................................................................................................................ metacharacters in search 244 7.2 Use of........................................................................................................................ regular expressions in search ........................................................................................................................ 246 7.3 Number transformation ........................................................................................................................ 247 7.4 Tips and tricks for regular expressions 248 7.5 Valid ........................................................................................................................ characters is phone number fields 8 Appendix B. Codec list generation in MVTS Pro 249 249 8.1 Codec........................................................................................................................ matching rules 251 8.2 Proxy........................................................................................................................ policies 9 Appendix C. Default gateways 253 10 Appendix D. System limitations 254 254 10.1 Cases........................................................................................................................ of possible losing CDRs ........................................................................................................................ 254 10.2 SS7 Call Agent node limitations 256 10.3 Other........................................................................................................................ limitations 11 Appendix E. MVTS Pro – RADIUS interaction 257 ........................................................................................................................ 257 11.1 Procedure for dispatching packets to the RADIUS server ........................................................................................................................ 257 11.2 Registering endpoint authorization ........................................................................................................................ 259 11.3 Pre-routing call authorization ........................................................................................................................ 262 11.4 Accounting request .......................................................................................................................................................... 262 11.4.1 Accounting Start record .......................................................................................................................................................... 264 11.4.2 Accounting Interim-Update record .......................................................................................................................................................... 267 11.4.3 Accounting Stop record ........................................................................................................................ 270 11.5 AccessRequest structure for RADIUS-aided routing .......................................................................................................................................................... 274 11.5.1 Field XPGK-XROUTING-ROUTING (old format) .......................................................................................................................................................... 275 11.5.2 Field XPGK-XROUTING-ROUTING (new format) Page 8 Contents 9 ........................................................................................................................ 276 11.6 Authentication of registering devices on a RADIUS-server .......................................................................................................................................................... 276 11.6.1 H.323 ID-based authentication (standard RADIUS authentication) 277 11.6.2 MD5.......................................................................................................................................................... Authentication .......................................................................................................................................................... 277 11.6.3 CHAP Authentication .......................................................................................................................................................... 278 11.6.4 Digest authentication ........................................................................................................................ 279 11.7 Call disconnect upon Packet of Disconnect arrival 12 Appendix F. Removing CDRs from the DB 281 13 Appendix G. NAT traversal 282 14 Appendix H. Managing endpoints in MVTS Pro 283 15 Appendix I. External routing over SIP/H.323 284 15.1 H.323 ........................................................................................................................ 284 15.2 SIP ........................................................................................................................ 284 16 Appendix J. Call routing according to SIP URIs 287 17 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 292 18 Appendix M. Dial peer generation and selection 304 19 Appendix N. Media groups 306 20 Appendix O. Call Disconnection Causes 307 21 Appendix P. List of DB alarms 318 Page 9 Intoduction 1 Intoduction 1.1 Document profile This document provides a description of the MVTS Pro software, a carrier-grade VoIP switch for efficient policy routing and management of VoIP traffic. 1.2 Audience This document is intended for system administrators responsible for deployment, configuration, operation and maintenance of MVTS Pro. Readers of this document are expected to have knowledge of UNIX-like operating systems and be familiar with regular expressions. 1.3 Notational conventions The conventions used in this document are described in the table below. Conventions 1.4 Example Convention Text of note Important information deserving special attention void Examples of source code, program output, contents of log and configuration files. [N] Reference to a document. Ulimit File and directory names Registration Configuration parameters in MVTS Pro GUI Documentation The complete set of documents for MVTS Pro comprises the following documents. List of documents 1.5 Ref. No. Document title [1] MVTS Pro. Administrator’s manual (this document) [2] MVTS Pro. Functional specification [3] MVTS Pro. Traffic Switch administration [4] MVTS Pro. Installation and update manual Names, Phone Numbers and Network Addresses All IP addresses, user logins and phone numbers used for the purposes of the present document are fictitious and any resemblance or similarity to real-life objects and/or individuals is purely accidental. Page 10 Intoduction 1.6 Terms and acronyms ACD Average Call Duration. ACD is one of the operational parameters registered in MVTS Pro. ACD allows the evaluation of dial peer performance. ARQ Admission Request ASR (standard) Standard or conventional ASR (answer seizure ratio), calculated as: ASR = total number of non-zero duration calls/total calls * 100 ASR Answer Seizure Ratio. ASR is one of the operational parameters registered in MVTS Pro, allowing the evaluation of dial peer performance. In MVTS Pro ASR is calculated in two ways: using the common method (see ASR (standard) 11 and using the intrinsic MVTS Pro method (see ASR (MVTS Pro) 11 ). ASR (MVTS Pro) ASR calculated by the MVTS Pro intrinsic method. MVTS Pro ASR (answer seizure ratio) is calculated as: ASR = successful calls/total calls * 100 where a successful call is either a non-zero duration call or a call with a successful disconnect reason code. CDR Call detail record. Set of data fields (call ID, call start and termination time, disconnect reason, etc.) used for accounting and billing. CHAP Challenge Handshake Authentication Protocol. CPC Calling Party Category CPS Calls Per Second or Call arrival rate expressed in calls per second. CSV Comma Separated Values – text format used to represent data in tabular form. Each string in the file is a row of the table. The values of each column is separated by a delimiter, for example, a comma (,), semicolon (;) or a tab symbol. Text values are embraced in double quotes ("); if the text value itself contains double quotes – they are represented by two double quotes following each other. CUG Closed User Group DB Database DBMS DataBase Management System DNS Domain Name System DP Dial peer. In terms of MVTS Pro a dial peer is a potential destination for the MVTS Pro’s egress traffic characterized by the equipment (gateways) that receives traffic from MVTS Pro, number transformation rules and some other data important for call routing DTMF Dual Tone Multi-Frequency DST Destination EMA Exponential Moving Average Page 11 Intoduction ENUM TElephone NUmber Mapping. Protocol stack to link E.164 telephone numbering standard to DNS addressing system, used in Internet. Erlang 1 erlang — 3600 seconds of calls in one channel or local rate, efficient for channel loading within 1 hour. See the link to the CISCO document, describing the method of calculation of traffic in erlangs for VoIP-calls, Traffic analysis for voice over IP. GK A gatekeeper is a hardware used for IP-telephony management. Zone controller managing calls in a VoIP network, ensuring number translation and network access. GUI Graphical User Interface GW Gateway HTTPS HyperText Transfer Protocol, Secure ITSP Internet Telephony Service Provider LAN Local Area Network LRQ Location Request MVTS Multiprotocol VoIP Tandem Softswitch NAT Network Address Translation Network indicator This indicator associates SS7 signaling points with different types of SS7 networks: national or international. NGN Next-Generation Networks NIC Network-Interface Card Payload type An integer, identifying a codec or codec group. There are static payload types (with numbers from 0 to 95 inclusive) and dynamic payload types (with numbers from 96 to 127 inclusive). A static payload type is a number, which is defined in the standard and which identifies a codec or codec group for all calls. A dynamic payload type is a number, which identifies a codec for one particular call. PDD Post Dial Delay, interval between dialling the last digit of the called number and hearing the ringback tone. MVTS Pro registers PDD as an interval between the receipt of the CONNECT packet from the call originator and the receipt of the ALERT, CONNECT or ProgressIndicator with value 8 (ProgressInbandInformationAvailable) packets from the terminator. The calculation of PDD is EMA-based, measured in milliseconds; Point code A unique address of a signalling point in the SS7 network. PSTN Public Switched Telephone Network. This abbreviation is used to designate traditional legacy telephony and contrast it with VoIP telephony. QoS Quality of Service. MVTS Pro calculates QoS as a ratio of packets lost to total packets transferred, i.e. the smaller is the calculated QoS value, the better is QoS. Page 12 Intoduction RADIUS Remote Authentication Dial-In User Server/Service. Protocol of user authentication, authorization and accounting according to RFC 2138. RAS Registration, Admission, Status. Protocol for interoperation with remote devices. RAS user Registering device. RBT Ring-Back Tone RTP/RTCP Real-Time Protocol / Real-Time Control Protocol. SBC Session Border Controller. A device used in some VoIP networks to exert control over the signaling and usually also the media streams involved in setting up, conducting, and tearing down calls. The word Border in Session Border Controller refers to a point of demarcation between one part of a network and another. As a simple example, at the edge of a corporate network, a firewall demarks the local network (inside the corporation) from the rest of the Internet (outside the corporation). It is the job of a Session Border Controller to assist policy administrators in managing the flow of session data across these borders. SCD SETUP-CONNECT Delay. The stretch of time between the SETUP and CONNECT message. If there is no CONNECT message the CDR-field SCD will be empty. SIP Session Initiation Protocol. Service indicator Service indicator is used to associate signalling data, exchanged through the SS7 network, with a user subsystem. For example, the value 5 (0101 in binary notation) means that the signaling data is intended for the ISUP user part. Signaling data link Physical layer for transferring data (bitstream) between two SS7 signaling points. A signaling data link is made up of two channels, transmitting signaling together in opposite directions with the same speed. The signaling data link is controlled by the MTP1 layer protocol. Signaling link An SS7 signaling link is a signaling data link (as a transmission medium) plus a signaling endpoint (as a controlling device). The signaling link ensures reliable exchange of signaling messages between two directly interconnected signaling points. The signaling link is controlled by the MTP2 layer protocol. TM Traffic Manager TNS Target NameSpace TS Traffic Switch TTL Time-To-Live, limit on the period of time or number of iterations or transmissions in computer and computer network technology that a unit of data (e.g. a packet) can experience before it should be discarded. VoIP Voice over Internet Protocol (IP) WAN Wide Area Network Page 13 System overview 2 System overview MVTS Pro is a system for comprehensive management of IP telephony traffic flowing across the ITSP’s network. MVTS Pro is designed to efficiently handle big amounts of simultaneous call sessions through application of adaptive call authorization and routing policies. MVTS Pro integrates the functionality of a class 4 switch with the capability of a session border controller. The main intent of the MVTS Pro system is concentration and switching of VoIP streams for increased assurance of connectivity even between networks with different signaling standards (SIP, H.323 and ITU ISUP/ ISUP-R). MVTS Pro is designed for establishment of a highly efficient switching center on the carrier’s packet switching networks. MVTS Pro can bring connectivity to a patchwork collection of equipment both on the operator’s network and in trans-network operation. MVTS Pro assures network security, QoS control and provides a single point of user authorization, statistics and billing. MVTS Pro is a next-generation tandem switch application that takes over from the legacy MVTS softswitch. The major strengths of MVTS Pro include kernel support of SIP and ITU ISUP/ISUP-R/ MGCP, high rates of traffic handling and a modular architecture that allows for boundless enhancement of performance. The MVTS Pro modular design and geographical distribution of the system components add a lot to the system operational flexibility and reliability. The ease of deployment and operation are additional merits of MVTS Pro. 2.1 System make-up The information on the MVTS Pro make-up is included into the Functional specification [2] for the system. 2.2 API The API is an interface that enables gathering data about the System settings and allows the external applications to dispatch requests to the System over various protocols. For further information about the API see the “MVTS Pro. API ENG” document. Page 14 Security requirements 3 Security requirements To protect the System from unauthorized access, it is advisable to configure the firewall to block access to the System from all IP addresses, except those absolutely necessary for System functioning. Specifically, it is advisable to: Change the manufacturer-provided password immediately after the first logon to the system. Specify equipment registration passwords which are different from registration usernames. Restrict access to the balancer node from the external network from all addresses, except those from which the System receives and to which the System directs traffic. Restrict the availability of MySQL TCP port 3306 from the external net. Only the scripting node, the Centrex logic of the Class 5 component, and the web GUI need to access the port. Allow access to the command line node over the telnet protocol from authorized IPs only (used by the SwitchRay Inc. technical support and the System owner). Allow ssh access to the System servers from authorized IPs only (used by the SwitchRay Inc. technical support and the System owner). Configure interoperation of the nodes (TS nodes, first) on the addresses from the intranet. If it is impossible, configure the firewall to block access to the corresponding ports. Using default TCP-ports (9000, 7000, 5000) from the System configuration examples is not recommended. Page 15 MVTS Pro Web interface 4 MVTS Pro Web interface The web server provides a friendly graphic interface for convenient configuration and administration of TM. 4.1 What you see on the screen The screenshots below illustrate the web GUI elements and the terms used in this manual to refer to the objects that the TM software deals with. TM objects and GUI elements GUI elements Page 16 MVTS Pro Web interface 4.2 Standard procedures This chapter explains standard procedures that the user performs when working with the TM GUI. 4.2.1 Accessing TM’s GUI To establish a link with the web server, enter the IP address or DNS name of the host on the address line of the web browser you are using. The MVTS Pro web interface is available directly through the following addresses: http://web-server-address:8082/ https://web-server-address:8445/ https://web-server-address/ Enter your login and password (note that the login and password check is case-sensitive), and click Login. In case you are using your IP address as the authentication parameter simply click Login. Logon dialog box If the logon credentials provided by you are correct you will see the main window of the web interface. The left part of the window shows the tree of object categories. The right pane is a working area which displays the information on the currently selected object. Web interface main view Use the Rows on page combo box located below the table to control the number of rows displayed in the tables (10, 25, 50 or 100). Use the buttons Use the buttons / / to view the next (or previous) portion of data. to go to the last or first view. To quicken search of the necessary information you can use search filters. Refer to section Use of filters 19 for information about the use of search filters. Page 17 MVTS Pro Web interface 4.2.2 Pop-up menu The pop-up menu comprises a list of control options used in administration of the MVTS Pro system. Left-click on the record of interest in the table you are viewing, to invoke a pop-up menu. The content of the pop-up menus is contextual, that is, differs from table to table and depends on the user’s permissions. The figure below presents an example of the pop-up menu invoked from the table Users. Pop-up menu The full version of the contextual menu is comprised of the following items: Add – this command allows you to add new records to the table; It is advisable not to use string 'Null' as record names. Clone – this command is instrumental when you need to use a copy of the existing record to create a record that differs from the existing one just slightly. View – opens a record viewing window. To return to the tabular view click the OK button. Edit – opens a record editing dialog box. When you are through with editing the record parameters, click OK to confirm or Cancel to discard the changes. Delete – use this command to delete the record you selected. Marked – this command allows you to perform operations over the selected records. When hovering the mouse over the options, a new menu will be displayed with three commands - Edit, Edit (do not check for equal settings) and Delete. The Edit command allows you to edit marked records. Mark the required records and click Marked -> Edit. You will see a dialog comprising an additional column with checkboxes for each field unlike the dialog invoked by a simple Edit command. Activate the checkbox for the fields that require modification, alter the field values and click OK. The changes will be applied to all marked records. If the number of records subject to editing is large, the process of opening the dialog box can take some time. If you are not interested in identical settings, use the Edit (do not check for equal settings) command. The Delete command allows you to delete marked records. To mark the records, select the respective check boxes in the leftmost column of the table. To mark all the records in the list simply select the checkbox in the header of the table. When the required records are marked, invoke the pop-up menu and click Marked -> Edit. Filter - invokes a filter dialog box (for information how to use filters consult section Use of filters 19 ). When the button is clicked, and new menu will be shown with two commands – By cell (filter the table Page 18 MVTS Pro Web interface by the value of the selected cell) and By cell (add to existing filter) (add the value of the selected cell to the existing filter). Filtered – this command allows you to perform operations over the filtered records. When hovering the mouse over the options, a new menu will be displayed with three commands - Edit, Edit (do not check for equal settings) and Delete. The Edit command allows you to edit all or several records. If a filter was applied to the table, only the records satisfying the filter criteria will be changed. Mark the required records and click Marked -> Edit. You will see a dialog comprising an additional column with checkboxes for each field unlike the dialog invoked by a simple Edit command. Activate the checkbox for the fields that require modification, alter the field values and click OK. The changes will be applied to the filtered records. If the number of records subject to editing is large, the process of opening the dialog box can take some time. If you are not interested in identical settings, use the Edit (do not check for equal settings) command. The Delete command allows you to delete all records from the table. If a filter was applied to the table, only the records satisfying the filter criteria will be deleted. Arrange columns – enables you to arrange the table columns according to your preference (see section Re-arranging table columns 26 ); Export data – use this command to unload data from the tables into CSV-files (for information about data export refer to section Data export 218 ). Filter related tables – a list of tables associated with the table you are working with. The table opened by this command contains information related only to the item selected in the source table. For example, left-click a record of interest in the System users table and select Authentication history on the pop-up menu. The system will display the Web authentication history table with information about the selected user only. 4.2.3 Use of filters The use of filters allows you to limit the amount of information displayed onscreen and view only the records that meet certain criteria. The application allows for creation of complex filters that are helpful when there are several conditions that records of interest must meet. Filtering conditions (i.e. search criteria) can be combined with the help of the following logical operators: AND – a search will return records that meet all the specified conditions only OR – a search will return records that meet at least one of the specified conditions; NOT (AND) – a search will return records that meet none of the specified conditions only; NOT (OR) – a search will return records that do not meet at least one of the specified conditions; To create a filter, invoke the pop-up menu, select Filter and Add to configured. The system will display a filter dialog similar to the one shown in figure below. Page 19 MVTS Pro Web interface Filter construction dialog The displayed filter dialog has the following controls: Filter construction dialog controls Control Description This control applies the constructed filter to the table contents. The upper Apply button is used to apply the newly constructed filter while the lower button serves to apply filters saved earlier. Use this button to delete saved filters This control appears on the filter dialog after the application of the filter only. Use it to cancel the filter application Use this control to save the constructed filter for future use. Deletes a filtering condition Adds a new line for filtering condition A drop-down list of logical operators integrated with a menu for adding/deleting groups and conditions. The look of this dynamic control element varies with the selected logical operator Page 20 MVTS Pro Web interface Control Description Dynamic control element for selection of comparison operators. The make-up of this drop-down list varies with the selected logical operator. The operators Like and Not Like allow the use of meta-characters ‘%’ and ‘_’ in constructed search patterns. The operator “RegExp" shows that what follows is a regular expression. Refer to supplement A for detailed information about meta-characters and regular expressions. Combo box with drop-down list of saved filters. For a more illustrative explanation suppose you need to filter the contents of the table Gateways so that it includes records of active terminating gateways pertaining to networks 192.168.131.0/24 and 192.168.132.0/24 only. When put into words the filter structure can be construed by the following table The required records must… Remarks …be enabled, …represent termination gateways, AND …belonging to network 192.168.131.0/24 Use meta-characters in search … belonging to network 192.168.132.0/24 Use meta-characters in search OR By this means it is necessary to create a filter that includes: two conditions and a group of conditions united by the operator “AND”. two grouped conditions with the operator “OR”. The resulting filter may look like the one shown below. Page 21 MVTS Pro Web interface Target filter To construct the necessary filter, proceed as explained below: 1. Add the first filtering condition. To do it, click , next to the control *AND* or click *AND* and select Add Condition on the appearing pop-up menu. Select Enabled in the newly added combo box and select the check box to the right of the equal sign "=". Filter construction. Step 1 2. Repeat Step 1, to add another condition combo box. In the drop-down list of conditions select “Allow termination” and select the check box to the right of the equal sign "=". Filter construction. Step 2 3. Add a group of conditions by clicking the control * AND * and selecting the Add group option Page 22 MVTS Pro Web interface in the appearing menu . Note, that *AND* is a default logical operator for groups of conditions. Filter construction. Step 3. Adding group 4. Change the logical operator in the newly added group clicking the * AND * control and selecting OR in the appearing pop-up menu. Filter construction. Step 4 5. Start adding conditions to the group. To add a condition, click , next to the control * OR * or click the * OR * control and select Add Condition on the appearing pop-up menu. Page 23 MVTS Pro Web interface Filter construction. Step 5 6. Select Term. IP address for the condition. Click the control “=” and select the option Like on the drop-down menu. Enter network pattern 192.168.131.% in the rightmost field. Filter construction. Step 6 7. Repeat steps 5 and 6 to add a similar condition for gateways belonging to network 192.168.132.0/24. This step completes the filter creation procedure. To apply the filter to the contents of the table click the upper button Apply. Page 24 MVTS Pro Web interface Filter construction. Step 7 With a filter applied the table displays the icon next to its heading to indicate that what you are viewing is not the complete table content. If you place the cursor over the filter icon, you will be displayed with a pop-up tip showing the filter structure. To cancel the filter, click the icon. For the user’s convenience the system remembers the filter applied last. The add-record dialog boxes invoked from the tables with a filter applied automatically include data the table was filtered by. For example, if a table of dial peers is filtered by the routing policy, the invoked dialog box will automatically have the same routing policy. In addition the user can save created filters for future use. To save a handy filter, click the Save button on the filter, enter the filter’s name in the appearing dialog and click the OK button. Saving a filter for future use To make use of an earlier saved filter, invoke the filter dialog, select the required filter in the combo box Saved filters and click the Apply button to the right of the combo box. To delete the saved filter click Delete. Selecting an earlier saved filter There is also a possibility to save the filters you create and use them again whenever you need. To save the filter after you have applied it to the table, click the Save button (if you want to make this filter accessible to other users select the As public checkbox). In the invoked dialog type in a name for the filter you are saving and click OK. You can also save filters as custom table views, which are very convenient for work with large amounts of data. To save a view, select the As view check box and click Save. Table views are saved individually for each System user. If a table has a saved view, there is a plus sign next to the table name in the object tree. Page 25 MVTS Pro Web interface Click the plus sign to expand the list and open the required view (see the figure below). Also, the Filter command found on the pop-up menu includes two options: By cell. By cell (add to existing filter). For example, if you select By cell and click over a cell Enabled with the value “Yes” in the table of Equipment, the System will hide all the records pertaining to disabled devices. And if then you select By cell (add to existing filter) and click over a cell Protocol, the System will apply the “AND” condition and display only the enabled equipment records with the selected protocol. 4.2.4 Sorting table data The System allows you to sort the contents of the table columns. To sort data in a column, click the column header. The first click causes the column contents sorting in the descending order with the sort order indicated by a down arrow next to the column header. To reverse the sort order, click the column header once again. The third click clears the sort of the column contents. The system also allows you to perform more complex types of sort affecting the contents of several columns. In this case the last sorting you apply becomes the main sorting criterion. The sort precedence is indicated by the number appearing next to the arrow sort indicator at the column header. With data sorted in one or several columns, the sort indicator click on this icon removes the sort from all columns. 4.2.5 appears next to the table name. A Re-arranging table columns For the sake of convenience, the system allows you to display, conceal and re-arrange table columns according to your preference. Click Arrange columns on the pop-up menu. The system will display a dialog box similar to the one shown in the figure below. Page 26 MVTS Pro Web interface Re-arranging table columns The right box presents the list of the columns as they appear in the table from left to right. To conceal a column, select it and click the the button. Use the right box to the left and vice versa. The and right, respectively. button. To display a column, select it in the left box and click and buttons to move all the column names from the buttons allow you to move the columns in the table to the left or to the Besides, you can make use of the table layout saved earlier, by selecting the name of the required layout in the drop-down list Saved layouts. Click the Apply button when you are through with configuring the table. The new column layout will be applied to the table. You will also see the icon next to the table name. To save the table layout you configured, use the Save button in the bottom part of the window. Enter the name of the layout in the invoked dialog window and press OK. To delete the saved layout, select it in the drop-down list and press Delete. If you do not save your settings, the system will still remember the table layout you configured and the next time you log in it will display the table in accordance with the changes you made. To restore all the table columns in their initial layout, click the 4.2.6 icon. Table autorefresh The MVTS Pro’s web interface allows you to configure periodic updating of the data in the table. To configure the table contents updating, invoke the pop-up menu and select the item Configure autorefresh. The appearing autorefresh dialog allows the selection of auto updating frequency. Selecting auto update period To start periodic updating, click on the Start button. The ongoing periodic updating is indicated by the autorefresh icon , appearing next to the table name. To stop periodic updating, click on the autorefresh icon or invoke the pop-up menu, select the Configure autorefresh option and press the Stop button on the autorefresh dialog. 4.2.7 Editing multiple table records The button Switch to edit mode appearing over every table brings up a dialog box that allows you to edit all the records currently displayed simultaneously. The figure below illustrates such multiple-edit dialog box invoked from the table “Codec group setup”. Page 27 MVTS Pro Web interface Editing multiple table records When through with record editing, click OK to confirm or Cancel to discard the made changes. 4.2.8 Data export There is a possibility to export data from viewed tables to CSV files for use in other applications. To export data proceed as follows: Left-click the table you are working with and select the Export data option on the pop-up menu. In the invoked dialog box, click Save. Page 28 MVTS Pro Web interface You will see the Save as dialog box. Use the Save in combo box to indicate the device and folder where you want to save the file. Enter the file name in the field File name. In the Save as type combo box select Microsof t Of f ice Excel Comma Sep arated Values File and click Save. 4.2.9 Component version view To view the versions of the System components in the web interface click the hyperlink with System name and version in the bottom right corner of the web interface window. A new dialog with the System component version will be displayed. Page 29 MVTS Pro Web interface Viewing the System component versions in the web interface The following designations are used: Centrex - not used in MVTS Pro. Logic – the version number of the scripting node software. TS – the Traffic Switch version number. WEB+DB – the version number of the web interface and the database. MVTS Pro – the System version. 4.2.10 Menu for tree's items In order to simplify System configuration, in particular the operations over tables containing a large number of records, the user is able to use a pop-up menu invoked on the item in the category tree. Invoking a popu-up menu on a tree item This menu allows the user to make certain actions over the table without loading its contents which can significantly speed up interaction with the System holding a large amount of data. 4.2.11 Creating objects in the web-interface You can create objects in the web-interface not only by invoking the pop-up menu 18 and selecting the Add 18 option in it. For your convenience, it is possible to add an object while editing the related table. For this, in the table click the link Add (see the example below) next to the object. Suppose, while editing the table Area specifics an area. For this, do the following: 144 (Configuration -> Area specifics) you need to add 1. Switch to the editing mode. Page 30 MVTS Pro Web interface 2. Click the link Add. 3. In the displayed dialog, enter the name of the area in the Name* field and click the OK button. After that the created object (Area) will appear in the drop-down list in the table Area specifics (the column Area). Page 31 Operating TM 5 Operating TM 5.1 Administration 5.1.1 System users The table of users (Administration > System users) presents information about personnel who have access to and operate the MVTS Pro system. To add a new user account, left-click the mouse on the table to invoke the pop-up menu and select the option Add. Add-user dialog Enter the following data in the displayed dialog . The fields marked with an asterisk are required fields: * User name – type in the user’s name. * Language – use this combo box to select the language that the user will use when working with the web interface. * Role – from the combo box select the role to be assigned to the user. For the description of roles configuration see sections Roles 34 and Role settings 34 . Enable – select the checkbox to make the record active. When through with entering data, click OK to submit the newly made record. The program assigns the record an automatically generated ID and adds it to the table System users. To edit, delete or view a record in an individual window select the appropriate item in the pop-up menu. Your next step in configuring the user’s account in the System is entering the user’s authentication data that enables web access to the System (see section Web authentication 33 ). Page 32 Operating TM 5.1.2 Web authentication This table presents user authentication and authorization data used during logon to the System. TM can perform user authentication by any attribute defined in the authentication record – the login name, password or IP address – and any combination thereof. There can be one or several authentication records configured for one user. During authentication the System performs the AND operation on the authentication parameters configured in the user authentication record and uses the OR condition in case of multiple authentication records existing for the same user.. Let us explain how the System authentication process is organized using the following example. Assume a user wants flexible access to the System information and wishes to be able to view traffic statistics both from the office tabletop computer with a trusted IP and any other IP (laptop) when on the move. To ensure this, the user must have two authentication records – one configured for login and IP address authentication and another with just a login name and password. When accessing the system from the office computer the user will be granted access to the System even without having to enter password or with password mistyped. (password verification will fail, but IP authentication will prove successful.) Wishing to access the System from any other place the user will have to provide correct logon credentials (login name and password) as IP verification will fail. To configure logon credentials for a new user, select Add in the pop-up menu. Web authentication dialog box Enter the user’s logon credentials filling out the fields of the brought up Web authentication dialog box. The fields marked with an asterisk are required fields. * User – use the drop-down list to select the user whose logon credentials you are configuring. * Realm – select the GUI realm, available to the user, from the drop-down list. * Login – enter the user’s login name here. Note that all user logins configured in the DB must be unique. Password – enter the user's password. The System allows the administrator to limit password validity period using the parameters Password validity period, days and Password queue length (see section Web settings 139 );If it is necessary that a user changes the password when logging in next time, select the checkbox Change password at next logon. IP address – enter the IP-address (or a list of IP-addresses) from which the web-interface can be accessed. In order to configure the user's password to never expire (regardless of the value of the parameter Password validity period, days), do not leave this field empty. To add an IP-address, press . Enabled – select the checkbox, to make the record active. When changing the user login or p assword, the System f orces re-log in f or all af f ected users. Relogin will take p lace af ter the exp iry of the timeout, conf igured by user_reauth_time in Page 33 Operating TM Config.php, since the last web p age up date. To submit the configured authentication record click OK. Click Cancel to discard the changes or abort the procedure. If you don't use the web-interface within 24 hours, to log in the System you will have to enter your login name and password again. 5.1.3 Roles The object Roles allows you to create and compile roles. To create a new role, invoke the pop-up menu and select the Add option. Creating a new role Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields: * Parent role – select the parent role for the role being created in the combo box. The scop e of GUI access rights of the child role cannot be greater than that of the p arent role. The role Administrator with the rights to view, modify and delete all GUI objects is created automatically during the software installation. * Name – enter the name of the new role; Description – enter any information relevant to the role. When done, click the OK button. Once the role is created, assign the rights to the role (see section Role settings 34 ) and compile it. Role compilation is also required every time any changes are done in the role settings. During the role compilation process all GUI elements are updated in accordance with new role settings, so that users assigned to this role could gain access to the GUI elements. The new role ready to be compiled To compile the role press the button. If the role is compiled successfully, the System will show Yes in the Compiled column of the role record. 5.1.4 Role settings The Role settings dialog is used to make a list of rights characteristic of the created user role. To make a set of rights for the role, invoke the pop-up menu and select the Add option. Page 34 Operating TM Role construction window Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields: * Role – select the role, for which the set of rights is being built. * Filter – select a category or an object, used as a filter. The Object list will show the GUI element itself and all its child elements. This allows you to discard unwanted GUI objects (the access rights to which should be left unchanged) from the Object list. * Object – select a category, object or a parameter, to which the access rights are granted. The list comprises the GUI object itself (the root element) and its child elements (if any). It is possible to set roles only for static objects, that is why dynamic objects, like the nodes from Nodes 95 and SS7 Call Agent node configuration 177 , will be unavailable in the list Object. Both lists have the following designations in the names of the GUI elements: [M] – category. [T] – object (table). [C] – parameter (table column). [W] - wizard. [UIP] - procedure. Include all child objects – select the checkbox, if you want to assign the access rights not only to the GUI element, selected in the * Object combo box, but also to all its child elements. Actions – select the checkboxes, corresponding to the actions, which the user may perform on the selected GUI elements. View – viewing elements. Update – modifying the element value. Insert – creating new element. Delete – deleting the element. Execute – executing the element (valid for wizards and procedures, such as call simulation and CDR scheduled export). When done, click the OK button. After any changes in the role settings, the role should be recompiled. (see section Roles 34 ). 5.1.5 System user creation wizard System user creation wizard allows you to facilitate the process of creating new user accounts in MVTS Pro. Click the System user creation wizard to start creating an account. To navigate through the user creation steps, use Back and Next Buttons. The fields, marked with an asterisk, are required fields. The password is case-sensitive. Page 35 Operating TM Add User Wizard dialogue box Click Next button. User account dialogue box In the User account dialogue box enter the name of the new user account in the field * User name. Select the GUI language from the drop-down list * Language. Select the role in the Role field. Click the Next button. Authentication dialogue box Enter the following parameters in the Authentication dialogue box: * Realm – select the GUI realm available for the user from the drop-down list. * Login – enter the user’s login name here. Note that all user logins configured in the DB must be unique. Password, IP address – use these fields to enter respective user authentication attributes (see section Web authentication 33 ). Click Next. Page 36 Operating TM Create user final dialogue box Check the correctness of the specified data in the Create user dialogue box. Return to the previous stages, using the Back button, and revise the information if required. To complete user creation click Finish. 5.1.6 Web realms The division of the GUI into distinct realms is an MVTS Pro security measure that provides for differentiation of user GUI access rights. A realm is an isolated area of the web-interface. A user belonging to a specific realm has no access to authentication records of users associated with other realms. The inaccessibility of authentication records of users belonging to a different realm prevents the possibility of password guessing and password hacking attacks. Defining a realm is a must during configuration of any user authentication record. Initially, TM has a single pre-configured public realm called Users with the unique ID “users”. By default, any newly added authentication record belongs to the realm “users”. The Realms table shows the realms configured in the system. For better security, you may wish to create a private realm, accessible to the System administrators only. To create a private realm, invoke the pop-up menu and select the ‘Add’ item. Adding a new realm Fill out the fields of the Realms dialog box (the fields marked with an asterisk are required fields): * ID – enter the unique ID of the realm, which can be any word of your choice, for example, “admin”. The unique ID of a web realm is one of the conf iguration p arameters of the PHP-ap p lication (see below) . * Realm name – enter the name of the realm (for example, “admins”). Description – you can enter any appropriate information in this text box. When finished with filling out the configuration form, click OK. The newly configured record will be added to the table. Now you can create a copy of the web-server that will be accessible to the System administrators only. For example, you can do it as follows: 1. Create a subdirectory in the directory /var/www/rtu, the directory of the web-server files. 2. Copy all the files of the directory /var/www/rtu to the newly created subdirectory. 3. In the newly created directory, edit the configuration file Config.php, by defining the unique ID of the private realm. Page 37 Operating TM Entering the ID of a new realm into Config.php Now in case the public web realm is accessible for the users via www.<providername>.com, to log onto the private web realm the address www.<providername>.com/<directoryname> will be used, where <directoryname> is the name of the subdirectory comprising the copies of the web-server files, known only to the System administrators. To enhance the system security, you can also use Apache server tools to configure the web interface so that it will listen only to intranetwork IP address (refer to the Listen directive of the Apache configuration), or deny or allow access from specified networks or IP addresses (refer to Allow from/ Deny from directives of the Apache configuration). 5.2 Equipment The category equipment comprises information about the equipment, MVTS Pro interoperates with, zones and codecs. Page 38 Operating TM 5.2.1 Equipment The table Equipment displays information about the equipment that MVTS Pro interoperates with. List of configured gateways To add a new record to the table, invoke the pop-up menu and select Add. Configuring a gateway record Fill out the fields of the displayed form. The fields marked with an asterisk are the required parameters. Enabled – select the checkbox to make the record active. * Name – enter the name of the device being configured. Description – you can enter any descriptive information in this field. * Equipment type – select the type of gateway from the combo box: Gateway – this gateway is a trunk gateway. Page 39 Operating TM Gatekeeper – this gateway acts as a gatekeeper. Default gateway – this gateway acts as a default template gateway, for the devices not configured in MVTS Pro. Routing server (RADIUS) – this gateway acts as an external routing server over RADIUS protocol 270 . When Routing server (RADIUS) is selected in the Equip ment ty p e p arameter the System will disp lay no f ields excep t Enabled, Name, Descrip tion, Equip ment ty p e, Valid f rom and Valid till. ENUM server - the device being configured is expected to use ENUM servers 142 for external routing. Note that that ENUM-aided routing is possible for SIP devices only. To establish a connection, the system uses the SIP port specified in the parameter Term. port SIP. Endpoint – this object is an individual piece of equipment (a subscriber’s terminal) with a phone number assigned to it. For each endpoint the System implicitly creates a dial peer with the name <endpoint name>-epdp. (see Appendix H. Managing endpoints in MVTS Pro 283 ). When adding an obj ect of Endp oint typ e the System automatically creates an imp licit dial p eer f or it that doe not show up in the Dial peers table. To see the dial p eer f or such an obj ect op en the Dial peers tree (section Tree of dial p eers 82 ) . Routing server (SIP) – this gateway acts as an external routing server over SIP protocol with the help of 30x messages (for more details see section Appendix I. External routing over SIP/ H.323 284 ). URI Resolver - terminating device, operating according to RFC3263. Using the unified resource identifier, the URI Resolver defines a transport protocol (only the SIP protocol is used) and an IP-address of the terminating device. For that, the URI Resolver applies to the external server of the Domain Name System. In response, the System receives several IP-addresses and generates a route for each of them. For more information refer to Appendix J. Call routing according to SIP URIs 287 . The external routing algorithm is described in the chapter Termination 69 . * Endpoint number – the phone number of the endpoint that is sent by the endpoint equipment. This parameter is valid, if the Endpoint option is selected from the Equipment type. Allow origination – select the checkbox to allow the device to operate as a call originator. Allow termination – select the checkbox to allow the device to operate as a call terminator. * Protocol – specify the signaling protocol supported by the device. If the option H.323 or SIP was selected and the gateway acts as a terminator, the System will transmit data to this gateway under the protocol (H.323 or SIP), used by the originator. If the originator operated under a protocol, different from SIP or H.323, the Term. default protocol will be used to transmit data to the terminator. If it is necessary to receive a call from another balancing group or transfer a call to another balancing group, select the Internal option. The SIP-T p rotocol also means sup p ort of the SIP-I p rotocol. Register equipment – select the checkbox to register the equipment with MVTS Pro. If the Default gateway is selected in the Equipment type list, the gateway will always be registered. Zone - select zones (see section Zones 61 ) to be used simultaneously for calls originated by the device and calls terminated to the device. In case the SS7 protocol is used, the SS7 zone is used to address the gateway. Move the selection to the right window by clicking the right-arrow button . To remove a zone from the list, select the zone in the right-hand window and click the leftarrow button Use the versa. . Holding down a Shift or a Ctrl key allows you to select several zones at once. and buttons to move all records from the right box to the left one and vice The sequence of zones is of no importance. If no zones are selected, the System considers all zones to be selected. If Register equipment is enabled, the System displays this parameter and hides the parameters Orig. zone and Term. zone. Page 40 Operating TM * Term. default protocol – the signaling protocol for communicating with the terminator, if the originator used protocol other than H.323 or SIP. The parameter is valid if the H.323 and SIP option was selected in the Protocol parameter and the equipment acts as a terminator. Balancing group – select the balancing group from the list box (see section Balancing groups 67 ) from which the call comes or where it goes to. The parameter is displayed when the Internal option is selected in the Protocol parameter. Max. call duration, sec. – define the maximum allowed duration of a call originated or terminated by the device. Allowed values: 0-4294967295.Enable statistics – select the check box to enable statistics accumulation for this gateway, which will later be used to plot graphs. Valid from/Valid till – use this controls to define the beginning and end of the record validity term. Category Origination settings. This group of parameters is intended for configuration of origination devices. The parameters are valid only with the Allow origination checkbox selected. Orig. IP address list – define the list IP addresses used by the device for call origination (you can use the CIDR format for IP addresses). MVTS Pro will receive calls from the specified addresses. In case the SS7 protocol is used or the equipment does not register with the System, this parameter is invalid. Orig. port – specify the signaling port of the origination device for the purpose of caller identification. In case the SS7 protocol is used or the equipment does not register with the System, this parameter is invalid. Allowed values: 1-65535. It is imp ortant that you enter the number of the signaling p ort only when several gateways use the same IP address and the call originator can be distinguished solely by the signaling p ort number. Otherwise, leave this f ield emp ty. Orig. NAT address – specify the address of the NAT device if the configured gateway is sitting behind a network address translator. In case the SS7 protocol is used or the equipment does not register with the System, this parameter is invalid. * Orig. Zone – select zones (see section Zones 61 ) to be used for calls originated by the device. In case the SS7 protocol is used, the SS7 zone is used to address the gateway. Move the selection to the right window by clicking the right-arrow button . To remove a zone from the list, select the zone in the right-hand window and click the left-arrow button key allows you to select several zones at once. Use the records from the right box to the left one and vice versa. . Holding down a Shift or a Ctrl and buttons to move all The sequence of zones is of no importance. If no zones are selected, the System considers all zones to be selected. * Orig. proxy policy – define the media proxy mode to be used when the device acts as a call originator: Use terminator's proxy mode — use the policy that was established on the terminator; Proxy media — always proxy media. Do not proxy media — disallow proxying; Orig. codec group – select the group of codecs allowed for the device when it acts as a call originator (for more information about codec groups refer to section Codec groups 64 ). The codec group f or the originator should comp rise not more than 1 video codec, otherwise the System will be unable to handle calls f rom such originator. SRC Capacity group – select the name of the common capacity group from the drop-down list. The gateway will belong to the selected capacity group. For more information about capacity groups see section Capacity groups 146 . Max. incoming calls – the maximum number of incoming calls the device can handle simultaneously. If the field is empty or zero is entered, the number of calls is unlimited. Allowed values: 0-4294967295. The maximum number of incoming calls is counted separately for each device registered with the System through the default gateway; Orig. groups – enter the names of the gateway groups to which calls originated by the group devices are related. Such group names can be used for call routing and number translation process when Page 41 Operating TM entered in such fields as Allowed SRC groups and Disallowed SRC groups. Orig. allowed SRC numbers – enter a regular expression that determines the pattern for allowed source numbers. This parameter is invalid if the Default gateway is selected in the Equipment type parameter. The value should not exceed 65,535 symbols (64 KB). For more information refer to Tips and tricks for regular expressions 247 . You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com; To set up a device with several analog sockets (FXS p orts) , create a gateway record f or each socket and sp ecif y the resp ective socket (p ort) number, conf igured on the device, in the Orig. allowed SRC numbers p arameter f or each gateway. Orig. allowed DST prefixes – enter a regular expression that determines the pattern for allowed destination numbers. This parameter is invalid if the Default gateway is selected in the Equipment type parameter. The value should not exceed 65,535 symbols (64 KB). For more information refer to Tips and tricks for regular expressions 247 . You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com; Orig. disallowed DST prefixes – enter a regular expression that determines the pattern for disallowed destination numbers. Disallowed numbers override the allowed ones. This parameter is invalid if the Default gateway is selected in the Equipment type parameter. The value should not exceed 65,535 symbols (64 KB). For more information refer to Tips and tricks for regular expressions 247 . You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. URI match pattern for SRC number - enter a regular expression that determines the URI pattern in SRC number. You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example \.com. URI match pattern for DST number - enter a regular expression that determines the URI Equipment 42 pattern in DST number. You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Orig. allowed types of SRC numbers – specify the list of the allowed types of SRC numbers. For this, in the left window, double-click a desired type of numbers or select it and click . To remove a type from the list of allowed types, in the right window, double-click its name or select it and click . Holding down a Shift or a Ctrl key allows you to select several types at once. Use the and buttons to move all records from the right box to the left one and vice versa. Orig. disallowed types of SRC numbers – specify the list of the diallowed types of SRC numbers. For this, in the left window, double-click a desired type of numbers or select it and click . To remove a type from the list of disallowed types, in the right window, double-click its name or select it and click the versa. . Holding down a Shift or a Ctrl key allows you to select several types at once. Use and buttons to move all records from the right box to the left one and vice Disallowed typ es of SRC numbers override allowed ones. SRC Codec pass policy – from the drop-down list select the policy for transmitting codecs, used by the originator: Do not pass changes – the changes in codecs on one leg (incoming) are not transmitted to the other leg. Thus, different codecs may be used on the two legs. In case the codecs do not coincide, codec conversion takes place if possible. Pass changes of media type – the System passes changes in type of media used from one leg (incoming) into the other (for example, when the originator switches from audio to fax). If the changes in codecs are restricted to one media type and the System is able to convert these codecs (for example, when switching from one audio codec to another), then the changes are not communicated to the other leg. If the other party is unable to support the changes, the call Page 42 Operating TM legs revert to the original state. Pass changes for G.711 – same as Pass changes of media type, but besides changes are communicated to the other leg if one of the parties tries to switch to or from the G.711 codec. The G.711 codec may be used to transmit faxes and establish modem connections. Pass all changes – all changes in codecs are communicated from one leg into the other. These politics are applied during call setup, when the System receives information about codecs available to the originator and terminator, as well as during the call itself, when the equipment tries to change the codec used. For further information about codec policies see Appendix B. Codec list generation in MVTS Pro 249 . SRC Number capacity group – select the number capacity group for the SRC numbers. For further information about number capacity groups see section Number capacity groups 147 . Always use TS ConfID instead of Protocol ConfID – select the checkbox to use Conf ID generated by the TS instead of the Conf ID taken from the signaling protocol. This Conf ID will be displayed in Protocol conference ID CDR parameter. Orig. Media group - select the originator's media group. Media groups are defined in the table Media groups 68 . Orig. Consider CUG in ISUP for origination – choose a policy of checking ISUP messages received from the originator for a closed user group (CUG) interlock code: Do not analyze CUG – ignore information about a closed user group; Allow only for calls with CUG – the equipment may be used for origination, if only there is information about a closed user group; Allow only for calls without CUG – the equipment may be used for origination, if only there is no information about a closed user group. This parameter is visible, if the SIP-T/I or SS7 option is selected in the Protocol parameter. Category Termination settings. This group of parameters is intended for configuration of termination devices. The parameters are valid only with the Allow termination checkbox selected. Term. IP address list – specify the list of IP addresses (delimited with ";") used by the device for call termination. In case the SS7 protocol is used or the equipment registers with the System, this parameter is invalid. The System adds a route for every address specified in this list. Term. port H.323 – define the port number to be used for call termination under H.323. In case the SS7 protocol is used or the equipment registers with the System, this parameter is invalid. Allowed values: 1-65535. Term. port SIP – define the port number to be used for call termination under SIP. In case the SS7 protocol is used or the equipment registers with the System, this parameter is invalid. Allowed values: 1-65535. * Term. zone - use the combo box to select the zone (see section Zones 61 ) to be used for calls sent to the device. In case the SS7 protocol is used, the SS7 zone is used to address the gateway. * Term. proxy policy – define the media proxy policy to be used when the device acts as a call terminator. For further information about proxy policies see section Proxy policies 251 . * Term. codec group – select the group of codecs allowed for the device when it acts as a call terminator (for more information about codec groups refer to section Codec groups 64 ). * Term. codec sorting – select a codec list generation method, which is used when the gateway is the call terminator. All codec list sorting methods apply to media codecs only, as data codecs are always placed after media codecs in the list in accordance with their precedence setting in the DB (except when the No sorting mode is selected) (see section Codec group setup 65 ). No sorting – return the terminator’s list of codecs as it is in the DB without any modifications. The order of codecs in the list is determined by the codecs’ precedence settings. Matching codecs first – sort the list moving terminator’s codecs matching those of the originator to the beginning of the list. The order of codecs in the subset of common codecs is defined by the order of the codecs, received from the originator. The order of the codecs Page 43 Operating TM outside the subset is determined by the attribute Precedence of each codec. For further information about the actions of the System depending on the proxy mode and codec sorting settings, see Appendix B. Codec list generation in MVTS Pro 249 . DST capacity group – select the name of the common capacity group from the drop-down list. The gateway will belong to the selected capacity group. For more information about capacity groups see section Capacity groups 146 . Max. outgoing calls – the capacity value is the maximum number of outgoing calls the device can handle simultaneously. If the field is empty or zero is entered, the number of calls is unlimited. Allowed values: 0-4294967295. The maximum number of outgoing calls is counted separately for each device registered with the System through the default gateway DST Codec pass policy – from the drop-down list select the policy for transmitting codecs, used by the originator: Do not pass changes – the changes in codecs on one leg (outgoing) are not transmitted to the other leg. Thus, different codecs may be used on the two legs. In case the codecs do not coincide, codec conversion takes place if possible. Pass changes of media type – the System passes changes in type of media used from one leg (outgoing) into the other (for example, when the originator switches from audio to fax). If the changes in codecs are restricted to one media type and the System is able to convert these codecs (for example, when switching from one audio codec to another), then the changes are not communicated to the other leg. If the other party is unable to support the changes, the call legs revert to the original state. Pass changes for G.711 – same as Pass changes of media type, but besides changes are communicated to the other leg if one of the parties tries to switch to or from the G.711 codec. The G.711 codec may be used to transmit faxes and establish modem connections. Pass all changes – all changes in codecs are communicated from one leg into the other. These politics are applied during call setup, when the System receives information about codecs available to the originator and terminator, as well as during the call itself, when the equipment tries to change the codec used. For further information about codec policies see section Codec matching rules 249 . DST Number capacity group – select the number capacity group for the DST numbers. For further information about number capacity groups see section Number capacity groups 147 . Term. Media group - select the terminator's media group. Media groups are defined in the table Media groups 68 . Ignore own routes – this parameter is intended for configuring authentication records of the providers who act both as a customer and a termination partner. Select the checkbox to instruct the System to exclude the routes affiliated to the provider from the list of terminating options when handling calls originated by the provider. Term. Consider CUG in ISUP for routing – choose a policy of using the equipment for termination depending on the presence of a closed user group (CUG) interlock code in incoming ISUP messages: Do not analyze CUG – ignore information about a closed user group; Allow only for calls with CUG – the equipment may be used for termination, if only there is information about a closed user group; Allow only for calls without CUG – the equipment may be used for termination, if only there is no information about a closed user group. This parameter is visible, if the SIP-T/I or SS7 option is selected in the Protocol parameter. Category Registration settings This group of parameters is intended for configuration of registering gateways. The parameters are valid only if Register gateway option is selected from the Registration type list. Registration username – enter a registration name, received from the device. This parameter is invalid if the Default gateway options was selected in the Equipment type list. Page 44 Operating TM Registration password – specify a registration password. This parameter is invalid if the Default gateway options was selected in the Equipment type list. In order to p rotect the equip ment f rom p assword brute-f orcing, sp ecif y the registration p assword dif f erent f rom the registration username. Max registration time, sec – set the interval between full re-registration of the device in seconds. Allowed values: 0-4294967295. Registration keep-alive time, sec – set the registration updates interval for the RAS-users registered with MVTS Pro, in seconds. Allowed values: 0-4294967295. Registration address list – enter a list of IP addresses allowed for registration with MVTS Pro delimiting them with semicolons. Leave the field blank to allow the device to register from any IP address. NAT keepalive time, sec – sets a keepalive interval for NAT devices. Allowed values: 0-4294967295. Registration logging – select the checkbox to record registration attempts into the Debug registration log. Use port from registration request as Orig. port – when the gateway registers with the System, select the checkbox to use the port from registration request as the Orig. port. This allows the System to differentiate between the among several SIP terminals behind a NAT device. This means that the INVITE message must originate from the same port as the REGISTER message, otherwise the call will be rejected. If the checkbox is deselected, the INVITE after registration may originate from any port. The parameter is valid if the Register equipment checkbox is activated and SIP, SIP-T or H.323 and SIP protocol are selected. When several registrations arrive they are sorted by arrival time and only the last one is considered active. Af ter the exp iry of the last registration the p revious registration becomes active (if it has not exp ired by that time) etc. Terminate through Balancer – select this checkbox only if you need to make calls through the balancer node i.e. through the entry point where the terminating equipment is registered, otherwise some call handling issues may occur as the reply to the registration request from the terminating equipment will be sent to the address in the header Contact. Category Number translation rules Orig. SRC number translation – enter a regular expression that determines source number modification rules for the cases when the device is the call originator (for detailed information about number regular expressions and translation rules refer to Appendix A. 244 ). The value should not exceed 65,535 symbols (64 KB). Orig. DST number translation – enter a regular expression that determines destination number modification rules for the cases when the device is the call originator. The value should not exceed 65,535 symbols (64 KB). For more information refer to Tips and tricks for regular expressions 247 . The p arameters are valid only with the Allow origination checkbox selected. Term. SRC number translation – enter a regular expression that determines source number transformation rules for the cases when the gateway is a termination device. The value should not exceed 65,535 symbols (64 KB). For more information refer to Tips and tricks for regular expressions 247 .The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. to translate the number 1234 into sip:user@example.com write the following translation rule: ^1234$/ sip:user@example.com. Term. DST number translation – enter a regular expression that determines destination number modification rules for the cases when the gateway is a termination device. The value should not exceed 65,535 symbols (64 KB). For more information refer to Tips and tricks for regular expressions 247 .The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. to translate the number 1234 into sip:user@example.com write the following translation rule: ^1234$/ sip:user@example.com. The p arameters are valid only with the Allow termination checkbox selected. Page 45 Operating TM The above conf igured number transf ormation rules will be ap p lied to the numbers bef ore the call routing p rocedure starts. For more information on using regular expressions refer to Number transformation 247 . Category Origination signaling settings This group of parameters is intended for configuration of the gateway properties when the gateway is an origination device. The parameters are valid only with the Allow origination checkbox selected. Orig. force alerting timeout, sec – use this parameter to set a time interval (in milliseconds), after which the system will send a neutral Alerting message to the origination gateway. Allowed values: 0255. Orig. Incoming SETUP - CONNECT timeout, msec - define the waiting period between the arrival of the SETUP message from the originator and the arrival of the CONNECT message from the terminator, in milliseconds. Allowed values: 0-65535. When the period expires, the call will be aborted (reason: no response to CONNECT message). Orig. drop call on alerting timeout - select the checkbox to drop calls when the timeout, after which the ALERTING message should come from the originator, expires. Orig. enable RBT – select the checkbox to enable the RBT (ring-back tone) emulation function when proxying media-traffic. If the checkbox is enabled, specify the file with RBT in the Orig. RBT file parameter. Orig. RBT timeout, sec – define the wait period (in seconds) before the System starts RBT emulation in the absence of RBT from the call terminator. Recommended value of the parameter is 60-90 seconds. Lesser values of the timeout may lead to false activation of the timer and call break during fax transmission; Orig. RBT file – enter the name of the audio file (.wav file) to be used for RBT emulation. The path to the audio file is configured in the settings of the media-node. The parameter is not visible, if the Orig. enable RBT parameter is disabled. Orig. RTP timeout, sec – serves to set the length of a time interval for checking the established link for the presence of RTP packets from the call originator. The first check interval starts upon the arrival of CONNECT. After the defined period lapses, the System checks if there were RTP packets exchanged during the period. The call is aborted if no RTP packets came from the originator during the time. Allowed values: 0-255. Orig. CallProceeding timeout, msec – set the packet forwarding delay in milliseconds, during which the call setup packets exchange with the origination device is suspended. During call setup packets arriving from the termination device are stored in the TS buffer, whose content will be forwarded further to the call originator only when the delay time specified in this field is over. Such organization of the call setup and look-ahead routing procedure is needed for devices that can handle one CallProceeding message only. Hence, if a CallProceeding message is occasionally followed by a Release_Complete message, further interoperation (call setup and call rerouting) with such a device intolerable to repeated CallProceeding messages may become impossible. Allowed values: 0-65535. This parameter is invalid if the ENUM server option was selected in the Equipment type parameter. The next four parameters are valid only if the H.323 protocol is selected in the Protocol combobox. Orig. Method of sending DTMF over H.323 – select the method of transmitting DTMF over H.323. This parameter is valid, if H.323 or SIP and H.323 options are selected in the Protocol parameter. Orig. faststart – from the drop-down list select the applicable mode of using FastStart procedure for the originator: Disabled – do not use the FastStart procedure; Enabled – use the FastStart procedure; This parameter is invalid if the ENUM server option was selected in the Equipment type parameter. Orig. response FastStart in messages – select the appropriate checkbox to define which message will include the FastStart packet. The possible options include: Call Proceeding Alerting/Progress Page 46 Operating TM Connect This parameter is invalid if the ENUM server option was selected in the Equipment type parameter. Orig. tunneling – select this checkbox if the device is supportive of Tunneling (H.245 encapsulation). Orig. start H.245 after – use this combo box to define the message, upon receipt of which the H.245 control channel is opened: Call proceeding Alerting/Progress Connect This parameter is invalid if the ENUM server option was selected in the Equipment type parameter. SRC Calling party’s category – to save the calling party’s category, received from the originator unmodified, select the blank option. To change the calling party’s category select the desired category from the list. Orig. use SRC number from encl. ISUP packet – select the checkbox to use the “SRC alias” parameter from the ISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. Orig. use DST number from encl. ISUP packet – select the checkbox to use the “DST alias” parameter from the ISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. Orig. use original DST number from encl. ISUP packet – select the checkbox to use the “Diversion” parameter from the ISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. Orig. use CPC from encl. ISUP packet – select the checkbox to use the “CPC” parameter from the ISUP, but not SIP headers. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. Early ACM timeout – defines a timeout after which the System sends ACM message. The parameter is defined in milliseconds. The range of available values - from 20000 to 30000 milliseconds (by default – 30000 ms). The parameter is valid only if the SIP-T protocol was selected in the Protocol combobox. Echo control device – the checkbox governing the “Echo control device” parameter in the outgoing IAM, ACM, CPG and CON messages. By default, the checkbox is deselected, which means that the parameter is “false”. The parameter should have the same value as the parameter on the media gateway. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. Category Termination signaling settings This group of parameters is intended for configuration of the gateway properties when the gateway is a termination device. The parameters are valid only with the Allow termination checkbox selected. The following parameters are valid only if the H.323 protocol is selected in the Protocol combo box. * Term. SRC type of number – specify the type of source numbers supported by the device using the drop-down list of this combo box: Same as on the incoming leg Unknown International number National numer Network specific number Subscriber number Abbreviated number * Term. SRC numbering plan – define the numbering plan supported by the device using the dropdown list of this combo box: Same as on the incoming leg Unknown Page 47 Operating TM ISDN telephony numbering plan (Recommendation E.164) Data numbering plan (Recommendation X.121) Telex numbering plan (Recommendation F.69) National standard numbering plan Private numbering plan * Term. DST type of number – specify the type of destination numbers supported by the device using the drop-down list of this combo box: Same as on the incoming leg Unknown International number National numer Network specific number Subscriber number Abbreviated number If the blank op tion is selected, the typ e of destination numbers sup p orted by the device will be the f ollowing: - Same as on the incoming leg (f or all gateways excep t ENUM) ; - International number (f or ENUM gateways,if the number received f rom ENUM starts with "+") ; - National number (f or ENUM gateways,if the number received f rom ENUM does not start with "+") . * Term. DST numbering plan – define the numbering plan supported by the device using the dropdown list of this combo box: Same as on the incoming leg Unknown ISDN telephony numbering plan (Recommendation E.164) Data numbering plan (Recommendation X.121) Telex numbering plan (Recommendation F.69) National standard numbering plan Private numbering plan Term. type of redirecting number - specify the type of the redirecting number (the last one in the list of redirecting numbers) to be dispatched to the outgoing call leg. This parameter may be overridden with a respective parameter of the dial peer. Term. numbering plan of redirecting number - specify the numbering plan of the redirecting number (the last one in the list of redirecting numbers) to be dispatched to the outgoing call leg. This parameter may be overridden with a respective parameter of the dial peer. Term. method of sending DTMF over H.323 – select the method of transmitting DTMF over H.323. This parameter is valid, if H.323 or SIP and H.323 options are selected in the Protocol parameter. Term. faststart – from the drop-down list select the applicable mode of using FastStart procedure for the originator: Disabled – do not use the FastStart procedure; Enabled – use the FastStart procedure; Enabled whenever possible – use the FastStart procedure if possible, if not - use slow start without switching into proxy mode; Term. tunneling – select this checkbox if the device is supportive of Tunneling (H.245 encapsulation). Term. start H.245 after – use this combo box to define the message, upon receipt of which the H.245 control channel is opened: Call proceeding Page 48 Operating TM Alerting/Progress Connect * Term. SRC Presentation indicator – select the value of the presentationIndicator field in the SETUP packet. For more information on presentationIndicator field see Q.931 and Q.951. Select the value from the drop-down listbox: Same as for the incoming leg Octet 3a not present Presentation allowed Presentation restricted Number not available due to interworking * Term. SRC Screening indicator – select the value of the screeningIndicator field in the SETUP packet. For more information on screeningIndicator field see Q.931 and Q.951. Select the value from the drop-down listbox: Same as for the incoming leg Not screened User-provided, not screened User-provided, verified and passed User-provided, verified and failed Network provided The following three parameters are valid only if the SIP protocol is selected in the Protocol combobox. * Term. Dispatch redirecting numbers to the out. leg – this combo box determines if the System should dispatch the incoming list of redirecting number to the outgoing leg. This parameter may be overridden by the dial peer settings. No (in other words, no redirecting numbers will be sent to the outgoing call leg). Yes. URI Scheme for Diversion - select the URI format of the diversion header: tel-uri - tel URI (by default) sip-uri - SIP URI <sip:[number]@[RTU address]>. This scheme applies only when the number is identified as digits. If the number is identified as URI, the SIP URI format will be used. Example: tel-uri The number is identified as URI: Diversion:<sip:12345@uas1.test.com;user=phone>;reason=do-notdisturb E.164 number: Diversion: <tel:8123456789>;reason=unconditional sip-uri The number is identified as URI: Diversion:<sip:12345@uas1.test.com;user=phone>;reason=do-notdisturb E.164 number: Diversion:<sip:8123456789@192.168.1.2:5061>;reason=unconditional * Term. SIP privacy method – use this combo box to select the privacy method to be used when the SIP protocol is involved: Cisco RemotePartyID (for more information about this method refer to http://www.cisco.com/ en/US/products/sw/iosswrel/ps1839/ products_feature_guide09186a0080110bfb.html#wp1050768). RFC 3325 PAssertedID (for more information about this method refer to http://www.ietf.org/ Page 49 Operating TM rfc/rfc3325.txt). Term. SIP redirect address list – enter a list of IP-networks (delimiting them with semicolons without spaces or using only spaces), to which calls can be forwarded when the equipment operates as a termination endpoint. Calls are forwarded when the following messages are received in response to the INVITE message: 1) 301 or 302, which contain a redirect address. If this address refers to one of the allowed IP-networks, then the call will be forwarded to it. 2) 200, which in the field Contact contains the address, different from the address to which the call was sent initially. If the terminating equipment is not behind the NAT and if the address from the field Contact is specified in the list of allowed IP-networks, then all further requests will be sent to the address from the field Contact. The parameter Term. SIP redirect address list displays, if Equipment list -> Gateway, Default gateway, ENUM server, URI resolver or Endpoint equipment, and Protocol -> SIP or SIP-T/I (or H.323 и SIP, if the protocol on the outgoing leg is SIP or SIP-T/I). If the list is empty, the call cannot be forwarded to any IP-network within this route, but an alternative route can be selected for such call. Term. H.323 First answer timeout, sec – define the wait period for the SETUP message answer in seconds. If the specified time expires and the termination device has not answered to the SETUP message, the system aborts the call. Allowed values: 0-65535. Term. SIP First answer timeout, sec – define the wait period for the INVITE message answer in seconds. If the specified time expires and the termination device has not answered to the INVITE message, the system aborts the call. Allowed values: 0-65535. Term. Connect message timeout, sec – define the wait period for the Connect message answer in seconds. If the specified time expires and the termination device has not answered to the Connect message, the system aborts the call. Allowed values: 0-65535. Term. Outgoing SETUP - CONNECT timeout, msec - define the waiting period between the dispatch of the SETUP message to and the arrival of the CONNECT message from the terminator, in milliseconds. If the period expires, the equipment is considered unavailable and the System proceeds with the next route. Allowed values: 0-65535. Term. RTP timeout, sec – serves to set the length of a time interval for checking the established link for the presence of RTP packets from the call terminator. The first check interval starts upon the arrival of CONNECT. After the defined period lapses, the System checks if there were RTP packets exchanged during the period. The call is aborted if no RTP packets came from the termination party during the time. This parameter is valid, if the Allow termination checkbox is selected and any option other than Do not proxy media is selected in the Term. proxy policy parameter. Recommended value of the parameter is 60-90 seconds. Lesser values of the timeout may lead to false activation of the timer and call break during fax transmission; DST Match CPC for translation – make the list of calling party’s categories to be translated. If the gateway receives the call with a CPC from the list, this CPC will be translated into a CPC, defined in the DST Translation for matched CPC parameter.If the parameter DST Match CPC for translation is empty, all categories will be translated. Select the desired CPC and move it to the right window by clicking the right-arrow button . To remove a category from the list in the right-hand window, select the appropriate category and click the left-arrow button categories at once. Use the the left one and vice versa. . Holding down a Shift or a Ctrl key allows you to select several and buttons to move all categories from the right box to DST Translation for matched CPC – select the category, which will substitute the categories from the DST Match CPC for translation list. If you want to leave the category unchanged, select the blank option. Page 50 Operating TM * DST CPC method – select the method used to transmit the calling party’s category to the terminator. None – calling party’s category is not transmitted to the terminator. This option must be used for the H.323 protocol (as the H.323 protocol does not support CPC) or the SS7 protocol (as the CPC is transmitted under SS7 in any case). SIP ISUP OLI – the category is transmitted via SIP in the “isup-oli” parameter of the “From” field. The category is transmitted according to the OLI standard. SIP CPC – the category is transmitted via SIP in the “cpc” parameter of the “From” field. The category is transmitted according to the OLI standard. For further information see The Calling Party's Category tel URI Parameter. SIP Category – the category is transmitted via SIP in a separate header “Category”. The category is transmitted according to the CPC standard. SIP CPC-RUS – the category is transmitted via SIP in a “cpc-rus” parameter of the “From” field. SIP CPC-NUM - the calling party's category is sent as a number substituted in the SIP From field. The CPC standard is used. Term. use display name of incoming leg – select the checkbox to pass the ‘Display-Name’ parameter from the incoming leg to the outgoing leg. * ACM No indication reaction – the parameter defines the System’s reaction to the receipt of an ACM with DC=00 and I=1. This parameter is valid only when using the SS7 protocol. the parameter defines the System’s reaction to the receipt of an ISUP message ACM with the parameters "called party status=no indication" and "interworking indicator=interworking encountered" in the section BCI (Backward call indicators). Theoretically, such ACM message does not constitute a notification about the necessity to dispatch an Alerting (Progress) message. However, certain SS7 devices report their readiness to send an RBT in such a non-standard manner and send respective media further on. Available values: Do not respond - do not react to an ACM with the status "No indication". Send Alerting with readyForRBT=false - emulate an Alerting (Progress) message for the originator without getting ready for receiving RBT from the SS7 switch. Send Alerting with readyForRBT=true - an Alerting (Progress) message for the originator and get ready for receiving RBT from the SS7 switch. This parameter is valid only when using the SS7 or SIP-T/I protocols. Do not require SIP-T support – select the checkbox if the terminator does not support SIP-T/SIP-I. In such a way the System will be able to operate over SIP-T/SIP-I with an equipment supporting SIP only. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. Transmission Medium Requirement – the value sent in the “Transmission medium requirement” field in the IAM message. Valid values – 0-3 (by default - 0). The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. Add end of dialing symbol to the DST number – select the checkbox to add the ST symbol (#, code 0x0f) to the DST number, if the DST number comprises no such symbol. The checkbox is valid only if the SIP-T protocol was selected in the Protocol combobox. DST SIP-T/I ISUP standard - select the applied national ISUP standard. The parameter is displayed, if Equipment type is Gateway and Protocol is SIP-T/I. Possible values: ITU FICORA (for more information refer to Support of SS7 national standards of Finland 210 ). Category LAR settings LAR allow (Q.850) – make a list of Q.850 disconnect codes that are expected to trigger rerouting for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). LAR deny (Q.850) – make a list of Q.850 disconnect codes that will prevent further routing for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). Page 51 Operating TM LAR allow (SIP) – make a list of SIP disconnect codes that are expected to trigger rerouting for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). LAR deny (SIP) – make a list of SIP disconnect codes that will prevent further routing for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). LAR allow (TS) – make a list of TS disconnect codes that are expected to trigger rerouting for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). LAR deny (TS) – make a list of TS disconnect codes that will prevent further routing for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). LAR allow (TM) – make a list of TM disconnect codes that are expected to trigger rerouting for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). LAR deny (TM) – make a list of TM disconnect codes that will prevent further routing for the call. The codes are delimited through “;”, spaces or EOLs (end-of-line). LAR allow (RTU Class 5) – this parameter is not used in MVTS Pro. LAR deny (RTU Class 5) – this parameter is not used in MVTS Pro. In case no disconnect code is specified, rerouting attempts will take place in any case. If any code is specified in the parameters of type LAR allow (...), this automatically means that all other codes of the same type (H.323, SIP, etc.) are denied, and vice versa - if any code is specified in the parameters of type LAR deny (...), this automatically means that all other codes of the same type (H.323, SIP, etc.) are allowed. If both parameters of the same type are defined, the parameter LAR allow (...) has the top priority. The checks if rerouting is possible are made individually for each pair of the LAR allow (...)/ LAR deny (...) parameters. Use LAR code numbers from the table Disconnect codes 141 , selecting relevant Namespace and Code. Category RADIUS Enable RADIUS authentication – select the checkbox to send device authentication requests to the RADIUS server. The checkbox is invalid if the gateway does not register with the System. Enable RADIUS authorization – select the checkbox to send call authorization requests to the RADIUS server. RADIUS authorization is valid only for the call originator. The System sends authorization requests only for the first route in the dial peer. Enable RADIUS accounting – select the checkbox to send billing and accounting information to RADIUS server. RADIUS username – enter the username to be included into the packets sent to the RADIUS server in cases when the device being configured originates calls. By default for static gateways MVTS Pro uses the IP address of the call origin. The string $ani$ in the field is replaced with the outgoing SRC number. The $ani$ metasymbol is invalid, if the gateway registers with the System. The parameter is valid if the gateway uses RADIUS authentication, authorization or accounting. RADIUS password – enter the password to be included into the packets sent to the RADIUS server in cases when the device being configured originates calls. By default for static gateways MVTS Pro uses the “xpgk” string. The parameter is valid if the gateway uses RADIUS authentication, authorization or accounting. Filling out User-Name and User-Password fields sent to the RADIUS server Values of RADIUS username and RADIUS password System reaction The equip ment registers with the System RADIUS username = not defined The User-Name and User-Password fields are filled out with Registration username and Registration password values respectively. RADIUS username = $ani$ The User-Name and User-Password fields are filled out with Registration Page 52 Operating TM username and Registration password values respectively. RADIUS password = not defined The User-Password is set to the xpgk string. RADIUS username = $ani$IP The User-Name is set to the IP string. RADIUS username = IP The User-Name is filled out with the IP address of the equipment. RADIUS username = any other value The User-Name is filled out with the RADIUS username value. The UserPassword is filled out with registration data (tokens), received by the System upon the equipment’s registration. RADIUS password = * In case of SIP the User-Password is not sent to the RADIUS server; instead the Digest-Realm, Digest-Nonce, DigestURI, Digest-Method, Digest-Response attributes are sent, together with the Digest-Username that holds the UserName value. In case of H.323 and CHAP authentication the User-Password is not sent to the RADIUS server; instead the CHAP-Password and CHAPChallenge fields are sent. RADIUS username = any other value RADIUS password = any other value The User-Name and User-Password are filled out with RADIUS username and RADIUS password values respectively. The equip ment does not register with the System RADIUS username = not defined The User-Name is filled out with the IP address of the equipment. RADIUS password = not defined The User-Password is set to the xpgk string. RADIUS username = IP The User-Name is filled out with the IP address of the equipment. RADIUS username comprises the $ani$ string The User-Name is filled out with the RADIUS username value, the $ani$ string is replaced with the SRC number after the gateway SRC number translation is applied (defined by the Orig. SRC number translation). RADIUS username = $ani$IP The User-Name is filled out with the RADIUS username value, the $ani$ string is replaced with the SRC number after the gateway SRC number translation is applied (defined by the Orig. SRC number translation). The IP string remains unchanged. Page 53 Operating TM RADIUS username = any other value RADIUS password = any other value The User-Name and User-Password are filled out with the RADIUS username and RADIUS password values respectively. Force "Telephony" in h323-call-type – select the checkbox to replace the "h323-call-type=VoIP" with "h323-call-type=Telephony" in the outgoing leg packets (Accounting-Start Originate and Accounting-Stop Originate). Cisco-NAS-Port value – the value of this parameter (if defined) will be put into the VSA Cisco-NASport field in the Accounting Stop Originate packets (i.e. for the outgoing call leg). The field will be added to the packet if the checkbox Force "Telephony" in h323-call-type is activated. Dispatch original IP address in User-Name - select the flag to make the System use the value of realip as the registration name during call authorization. The value is located in the field From of the incoming SIP INVITE message. The field User-Password will be absent in the RADIUS authorization packet in this case. The parameter is displayed if the checkboxes Allow origination and Enable RADIUS authorization are enabled and the checkbox Register equipment is disabled. RADIUS group - select the group of RADIUS servers from the drop-down list (see section RADIUS groups 173 ). The System will dispatch all RADIUS packets for this equipment to the RADIUS servers from the group only. If a blank item is selected, RADIUS groups no longer limit interoperation with RADIUS servers. During the call RADIUS p ackets are disp atched f or the originator only,. RADIUS settings of the terminator bear no imp ortance. Note that the maximum duration f or all attemp ts to deliver the p acket should not exceed 5 secs, otherwise the TS drop s the call with the code "Traf f ic Manager timeout". Category Redial settings Term. call retries – define the maximum number of redial attempts. Allowed values: 0-255. Term. retry interval, sec – define the interval between redial attempts in second. Allowed values: 0255. Redial codes (Q.850) – make a list of H.323 disconnect codes that will cause the redial procedure. Delimit the codes using ";", spaces or EOLs (end-of-line). Redial codes (SIP) – make a list of SIP disconnect codes that will cause the redial procedure. Delimit the codes using ";", spaces or EOLs (end-of-line). Redial codes (TS) – make a list of TS disconnect codes that will cause the redial procedure. Delimit the codes using ";", spaces or EOLs (end-of-line). Redial codes (TM) – make a list of TM disconnect codes that will cause the redial procedure. Delimit the codes using ";", spaces or EOLs (end-of-line). Redial codes (Class5) - make a list of Class5 disconnect codes that will cause the redial procedure. Delimit the codes using ";", spaces or EOLs (end-of-line). Category URI Resolver parameters Allowed DST networks pattern - set a pattern of IP-addresses, allowed for a call. The parameter is used to identify an IP-address of the terminating device among several IP-addresses, received from the Domain Name System. Disallowed DST networks pattern - set a pattern of IP-addresses, disallowed for a call. The parameter is used to identify an IP-address of the terminating device among several IP-addresses, received from the Domain Name System. Category Gatekeeper settings The following parameters should be used in case the device being configured is a remote gatekeeper. Page 54 Operating TM The parameters are valid if the Gatekeeper option was selected in the Equipment type list. Use GK – select the checkbox in case the device being configured is a gatekeeper. MVTS Pro interoperates with remote gatekeepers with the help of the ARQ/LRQ requests. GK ID – enter the gatekeeper ID that will be used in the ARQ/LRQ requests. GK IP address – enter the gatekeeper IP address. Use GK alias – select the checkbox to allow the System to use the aliases received from the gatekeeper in case they differ from those sent to the gatekeeper by the System. Use GK IP address for billing – in case you select this checkbox CDR records will include the IP address of the gatekeeper and not of the gateway through which the call was actually terminated. Category SIP-router's parameters This category comprises parameters designed to configure SIP routing server. The parameters are valid if the SIP routing server option is selected in the Equipment type combobox: SIP-router’s IP address list – list of addresses of SIP routing servers in the form of <IP:port>. In case of unsuccessful response from the first SIP-server the System sends a request to the next address from the list. SIP-router's first response timeout, msec – define the timeout in milliseconds after which the System no longer waits for the response from the SIP router and proceeds with call handling further. Allowed values: 0-4000. Note that the maximum duration f or all attemp ts to deliver the p acket should not exceed 5 secs, otherwise the TS drop s the call with the code "Traf f ic Manager timeout". Request sender’s name sent to SIP router - define the identify that will be used by the SIP router to detect the request's source and match it to the System. SIP-router's zone - select the IP zone where the SIP router is located. Send initiator's name to SIP-server - select the checkbox, if it is necessary to send the initiator's name to the SIP-server in the INVITE message. By default the checkbox is clear. Drop route containing DST number with invalid symbols - select the checkbox, if it is necessary to drop the route with the DST number containing invalid symbols (you can use figures and symbols "-", ".", "*", "#", "A", "B", "C", "D", "p" and "w"; the number can start with symbol "+"). If the checkbox is clear, such route will be considered as correct and the System will route the call using the translated number received from the initiator as the DST number. By default the checkbox is clear. URI match pattern for DST number received from SIP-server - using a regular expression, set the pattern to define URIs in the number received from the SIP-server. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. The category of parameters Routing control contains lists of codes sent by the SIP-server or TS in cases when external routing is not possible. Depending on the received codes, the System shall either continue or stop the routing. SIP codes to continue routing - codes sent by the SIP-server. Upon arrival of these codes the routing will be continued. SIP codes to stop routing- codes sent by the SIP-server. Upon arrival of these codes the routing will be stopped. TS codes to continue routing - codes sent by the TS. Upon arrival of these codes the routing will be continued. TS codes to stop routing - codes sent by the TS. Upon arrival of these codes the routing will be stopped. Use code numbers from the table Disconnect codes 141 , selecting relevant Namespace and Code. Note that if the SIP-server is unavailable upon the specified network address, code 45 shall be sent to the TS. Page 55 Operating TM If no codes are specified, the routing will be continued. If any routing allowing codes are specified, the System shall stop the routing upon arrival of other codes of the relevant type (SIP or TS). If any routing prohibiting codes are specified, the System shall continue the routing upon arrival of other codes of the relevant type (SIP or TS). If both parameters of one type are specified, then the routing-allowing parameter has the priority. The System shall check if the routing can be continued for each pair of the parameters separately. If routing is stop p ed up on arrival of SIP or TS code, then Call terminated along the "stop " route will be written in the CDR f ield LAR f ault reason 104 . Category Default gateway settings The parameters are valid only if the Default gateway option is selected in the Equipment type combobox. For further information about the default gateways see Appendix C. Default gateways 253 . Default gateway precedence – a positive integer (0-2147483647) that defines the default gateway preference over the other default gateways configured in the System. At every instance of time the System interoperates with one default gateway of the highest priority only. Should such gateway be inaccessible, the System switches to the default gateway with the next preference value. (the greater the precedence integer is, the greater is preference). Method of endpoint authentication - select the endpoint authentication method from the drop-down list. RADIUS - the registration parameters of an endpoint will be dispatched to a RADIUS server for authentication. The table Default gateway endpoints remains unused. Default gateway endpoints table - the registration parameters of an endpoint will be matched to the parameters defined in the Default gateway endpoints table. The System checks for matching endpoint username and number. Allowed registration username patterns – regular expression, that defines registration names of devices allowed to register to the System through the default gateway. Use semicolons to delimiter individual elements if you enter a list of regexp name patterns. Disallowed registration username patterns – regular expression, that sets a pattern for names of devices disallowed to register to the System through the default gateway. Use semicolons to delimiter individual elements if you enter a list of regexp name patterns. FAS Settings (settings are available if the gateway acts as a terminating device) Early CONNECT timeout, msec - interval between dispatch of Setup/Invite to a terminating device and arrival of Connect from it. Allowed values: 0-65535. A call ends with local code TS, 162 Early CONNECT timeout, if 3 following conditions are met: - the interval doesn't equal zero; - Connect is received during this interval; - no Alerting/Progress. Early Alerting timeout, msec - interval between dispatch of Setup/Invite to a terminating device and arrival of Alerting/Progress from it. Allowed values: 0-65535. A call ends with code TS, 161 Early Alerting timeout, if 2 following conditions are met: - the interval doesn't equal zero; - Alerting/Progress is received during this interval. Early Alerting CONNECT timeout, msec - interval between arrival of Alerting/Progress and Connect from a terminating device. Allowed values: 0-65535. A call ends with local code TS, 163 - Early Alerting CONNECT timeout, if 2 following conditions are met: - the interval doesn't equal zero; - Connect is received after Alerting/Progress during this interval. By default all these parameters have zero values and the System processes calls as usual. Page 56 Operating TM When adding or editing FAS settings of the equipment, make sure that: 1) Value of Early Alerting CONNECT timeout, msec is less than Term. Connect message timeout, sec 50 . Note: 1 sec = 1000 msec. 2) Value of Early CONNECT timeout, msec is less than Term. Outgoing SETUP-CONNECT timeout, msec 50 . 3) Value of Early Alerting timeout, msec и Early Alerting CONNECT timeout, msec is less than Term. Outgoing SETUP-CONNECT timeout, msec 50 . Category Miscellaneous ACM No Indication reaction – defines the System reaction on receipt of the ACM message with DC=00 and I=1. The parameter is valid if the gateway uses the SS7 protocol. Common capacity for incom. and outgoing calls – select the checkbox to sum the maximum possible incoming and outgoing calls when calculating the available capacity of the gateway. If the checkbox is deselected, the available capacity of the gateway is calculated separately for incoming and outgoing calls. SIP Query gateway – select the checkbox to allow MVTS Pro to monitor the serviceability of SIP gateways by periodically sending them the OPTIONS request as long as the gateways are handling calls. The parameter is valid, if the SIP or SIP and H.323 option was selected in the Protocol field. SIP Gateway query interval, sec – define the interval between repetitive OPTIONS requests (in milliseconds). Allowed values: 0-65535. The parameter is valid, if the SIP or SIP and H.323 option was selected in the Protocol field. H.323 TCP connect timeout, msec – use this parameter to set tcp-connect wait time (in milliseconds). A failure to establish an H.225 session within the specified time results in call disconnection. Allowed values: 0-65535. The parameter is valid, if the SIP or SIP and H.323 option was selected in the Protocol field. H.323 TCS response timeout, msec - use this parameter to set TCS response timeout. The default value is 9000 msec. Allowed values: 0-65535. The parameter is applied for H.323 gateways. Flags – this parameter allows configuration of the gateway functional peculiarities. The parameter value is a bit mask defined by a hexadecimal number (8 figures). Possible values include: 0x00000001 – always send SIP response 180, as the device is incapable of digesting SIP response 183. 0x00000002 – send DTMF as INFO rather than according to RFC2833. 0x00000004 – device is capable of fax transmission under the codec G.711. 0x00000008 – obsolete H.323 device (Vocaltec) requiring CISCO behavior emulation. This means: 1. TS presents itself as a CISCO device, not as MERA TS of the respective versions in the signaling messages comprising the field h225::EndpointType. 2. The message RCS is generated as similar to that dispatched by CISCO devices as possible. 3. The parameter terminalType in the message MSD gets the value TT_TERMINALONLY instead of TT_GATEWAYONLY. 4. The sequence of channel re-opening: the OLC will not be dispatched until the CLCAck arrives. The flag is more important for outgoing calls. For incoming calls CISCO emulation is enabled when the remote device gets identified as the Vocaltec device by the h225::EndpointType parameter in the SETUP message. 0x00000010 – forcefully disable RBT emulation after the receipt of repeated Alerting. 0x00000040 – in compliance with RFC5347 emulate 2 media circuits. This mode is required to interoperate with devices, that put 2 ‘m=’ strings into SDP as per T.38 specification. 0x00000080 – do not respond to a repeated INVITE with a SIP 100 message. Page 57 Operating TM 0x00000100 – allow a media node to automatically redirect the media stream to the actual port from which the equipment sends RTP packets, if the port differes from the port, indicated in the signaling messages. 0x00000200 – do not start the MSD exhange procedure during the second and subsequent TCS exhanges. 0x00000400 – enable recognition of inband DTMF from the endpoint equipment. 0x00000800 - enable correction of invalid timestamps in incoming RTP stream. 0x00001000 - include PRACK method into the list of supported methods for outgoing SIP messages and declare 100rel support. However, if the terminator requires PRACK in its response, the TS will send PRACK despite the disabled flag. For SIP-T/SIP-I calls the TS always acts as if the flag is enabled despite its actual setting. 0x00002000 - enable repacketization of outgoing RTP packets. 0x00004000 - disable dispatch of SIP OPTIONS as TCS to the remote equipment. Does not affect pinging of the remote equipment with OPTIONS. 0x00008000 - reject a route on receipt of a ACM/CPG message with the parameter Cause Indicator (valid for SIP-T / SIP-I / SS7 terminators only). 0x00010000 - with the checkbox selected the TS will always be master-server in masterslave determination in H.323. 0x00020000 - do not send SIP INFO messages with attached XML-files (picture fast update) according to RFC5168 during video calls - for the equipment which does not support such messages. 0x00080000 - remember the address used for equipment behind NAT for the last time and use it for next media-circuits change. The checkbox applies on the following condition: after changing media-circuits the equipment does not change address and port of the media-circuits. 0x00200000 - ignore DTMF signals received by the SS7 node from a SS7 gateway (Audiocodes Mediant) in messages MGCP NTFY, if there is no RFC2833 in the list of allowed codecs. 0x01000000 - allow incrementing of the Satellite indicator value in the required parameter Nature of Connection Indicators in ISUP Initial Address Message (IAM) in SIP-T/SIP-I calls. If you want to set several flags simultaneously, enter the sum of the required flags. ENUM - The list of configured ENUM servers is in the left window (see section ENUM servers 142 ). Select an ENUM server intended for use as an external routing means and move the selection to the right window by clicking the right-arrow button . To remove a server from the list of ENUM routers in the right-hand window, select the appropriate server name and click the left-arrow button . Holding down a Shift or a Ctrl key allows you to select several servers at once. Use the and buttons to move all records from the right box to the left one and vice versa. By shifting the servers names up and down in the list, using the and , buttons, you can change the ENUM-server query order. If the first server in the list is not available, the next server will be queried, till the system finds an available server to be used for external routing. The ENUM server selection tool is valid only when the ENUM server option is selected from the Equipment type combobox. Deny use of dynamic payload types for standard codecs – select the checkbox, if the H.323 gateway is not capable of redefining payload types for regular codecs for which data types are determined by the standard. * SIP Reason policy – from the combobox select the method for generating SIP Reason headers. Write all disconnect codes – write all disconnect codes to the SIP Reason headers without any modifications. Write all disconnect codes and add Q.850 – write all disconnect codes to the SIP Reason Page 58 Operating TM headers without modifications and add a respective Q.850 code. Write Q.850 only – write one SIP Reason with a respective Q.850 code only. Do not use SIP Reason field – do not add Reason headers. * Q.850 reason source – select the source of Q.850 disconnect codes if the SIP-T/SIP-I protocol is used: SIP Q.850 reason – use codes from SIP headers. ISUP Q.850 reason – use codes from ISUP headers. IP ToS for RTP-packets – define the value of Type of Service field for RTP packets sent to the gateway. The valid values range from 0 to 255. Force start of H.245 on the other leg upon TCS receipt – select the checkbox if on receipt of TCS (the list of codecs supported by the equipment) on one call leg, the System should open an H.245 channel on the other leg. This parameter is valid, if H.323 or SIP and H.323 options are selected in the Protocol parameter. ISUP T6 timer value - timeout for RES message arrival (originated by the network) after the receipt of SUS message (originated by the network). Valid values 90 - 180 secs, default value - 180 secs. This parameter is valid, if SIP-T option is selected in the Protocol parameter. CauseLocation value in outgoing REL messages - "CauseLocation" value that will be put into the outgoing REL messages. Values are defined according to Q.850. Default value - RLN. This parameter is valid, if SIP-T option is selected in the Protocol parameter. Can update media channel before connect – select the checkbox if the device being configured is capable of receiving repeated FastStart messages. This parameter is invalid if the ENUM server option was selected in the Equipment type parameter. When through with filling out the form, click the OK button to add the new record to the table. To edit or delete a record from the table, select the appropriate command on the pop-up menu. 5.2.2 Default gateway endpoints This table comprise registration and authentication data for the endpoints that register with the System through default gateways (refer to Appendix C. Default gateways 253 ). To add a new endpoint record, invoke the pop-up menu and select Add. Page 59 Operating TM Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields. Enabled – select the check box to make the record effective. * Name – enter the name of the endpoint. Description – you can use this text box to enter whatever explanatory information you find appropriate. Valid from/Valid till – use this controls to define the beginning and end of the record validity term. * Endpoint number – the endpoint number that is matched to the number from the registration request. * Registration username – endpoint registration name that is matched to the registration name from the registration request. Registration password – endpoint registration password. In order to p rotect the equip ment f rom p assword brute-f orcing, sp ecif y the registration p assword dif f erent f rom the registration username. Override max registration time, sec – define the period for a complete endpoint re-registration period (0-4294967295). This parameter overrides the value of Max. registration time, sec parameter defined in the default gateway to which the endpoint pertains. Override registration keep-alive time, sec – define the interval (0-4294967295) between dispatching keep-alive packets (required to maintain endpoint registered state). This parameter overrides the value of Registration keep-alive time, sec of the default gateway to which the endpoint pertains. Override registration address list – enter a list of IP addresses allowed for registration with MVTS Pro for this endpoint. Delimit the addresses with semicolons. This parameter overrides the Registration address list parameter of the default gatewau to which the endpoint pertains. Override NAT keep-alive time, sec – sets a keepalive interval for NAT devices (0-4294967295). This parameter overrides the value of the NAT keep-alive time, sec parameter of the default gateway, to which the endpoint pertains. When done, click the OK button. The newly added record is assigned an automatically generated ID. To edit or delete a record, invoke the pop-up menu and select the necessary option. To edit or delete a record, invoke the pop-up menu and select the necessary command. Page 60 Operating TM 5.2.3 Zones The table Zones presents information about IP and SS7 zones involved in TS call routing. For more detail on the intent of IP zones refer to document [3]. Table of configured zones To add a new zone record, invoke the pop-up menu and select Add. Add zone dialog box Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields. * Zone name – enter the name of the IP zone as it is defined in the TS configuration file, section zones, or enter the name of the SS7 zone as it is defined in the SS7 Call Agent node configuration file, section ss7zone. It is mandatory that the IDs of zones in the web-interf ace are identical to their names in the system conf iguration f iles. Description – you can use this text box to enter whatever explanatory information you find appropriate. Zone type - select the type of zone (IP or SS7) from the combo box. Click OK to add the record to the table. To edit or delete a record, invoke the pop-up menu and select the necessary command. 5.2.4 Codecs The table Codecs keeps information about codecs configured in the DB. A codec means a specific implementation of media data encoding standard bundled with specific required parameters. Table “Codecs” To create a new codec record, invoke the pop-up menu and select Add. Page 61 Operating TM Adding a codec Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields. * Name – codec name. * Codec type – select a codec family to which the codec belongs. The codec family implements a certain media encoding standard. Voice activity detection – select this check box if the codec provides built-in voice activity detection (VAD). * Sample rate, Hz – number of samples per second (or per other unit) taken from a continuous signal to make a discrete signal. Frames per packet – specify the number of frames per packet transmitted when the codec is in use. Allowed values: 0-255. Preferred payload type – specify a preferred payload type by entering a positive integer in the range of 96 through 127. The presence and contents of the parameters are defined by the codec family, selected in the Codec type field. The table below shows the codec types for which these parameters are available. Parameters for various codec types Codec type Parameters g.729 Modes speex Description Basic The codec corresponds to G.729 plain Annex A The codec corresponds to G.729a Modes 1, 2, 3, 4, 5, 6, Any Refer to The Speex Codec Manual for information about the Speex codec parameters. Flags Percep tual enhancement Perceptual Enhancement VBR Variable Bitrate Refer to The Speex Codec Manual for information about the Speex codec parameters. Refer to The Speex Codec Manual for information about the Speex codec parameters. ilbc Modes Page 62 Operating TM amr 30 ms f rame The codec corresponds to iLBC-13k3 20 ms f rame The codec corresponds to iLBC-15k2 Modes 4.75, 5.15, 5.9, 6.7, 7.4, 7.95, 10.2, 12.2 (Display format of flags: bit rates) The bandwidth of the media stream in real time, i.e. a minimum circuit bandwidth (in kbit/s) that is required to pass this stream without delays. For further information refer to 3GPP TS 26.073 — AMR speech Codec. Mode0, Mode1, Mode2, Mode3, Mode4, Mode5, Mode6, Mode7 (Display format of flags: numeric) Flags Octet-aligned mode g.726 For further information refer to RFC 3267. Modes 16, 24, 32, 40 kbit/s The bandwidth of the media stream in real time, i.e. a minimum circuit bandwidth (in kbit/s) that is required to pass this stream without delays. Flags AAL2 p acking g.722.1 Modes 16-48 (multip le kbit/s) amr-wb codeword Select the flag if you need to pack codewords in line with AAL2 format. Otherwise X.420 packing format will be used. For further information refer to RFC 3551. of kbit/s The bandwidth of the media stream in real time, i.e. a 400 minimum circuit bandwidth (in kbit/s) that is required to pass this stream without delays. Flags 6.6, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, 23.85 (Display format of flags: bit rates) The bandwidth of the media stream in real time, i.e. a minimum circuit bandwidth (in kbit/s) that is required to pass this stream without delays. For further information refer to 3GPP TS 26.073 — AMR speech Codec. Mode0, Mode1, Mode2, Mode3, Mode4, Mode5, Mode6, Mode7, Mode8 (Display format of flags: numeric) opus Octet-aligned mode For further information refer to RFC 3267. Additional flags by default not selected Page 63 Operating TM Stereo If the flag is selected, stereo sound is used; if not - mono sound. MVTS Pro does not support stereo, but can decode it to mono during transcoding. Constant bit rate If the flag is selected, constant bit rate is used; if not variable bit rate. In-band FEC If the flag is selected, the receiving party will use FEC (forward error correction). DTX If the flag is selected, DTX (Discontinuous Transmission and silence suppression) will be used. Other parameters Max. p layback rate, Range of values: 8000-48000. Hz Default value: 48000. drop-down list Max. Range of values: 3-120 (multiple of 2.5 and rounded up to p acket time, ms the next full integer value). Default value: 120. drop-down list Min. Range of values: 3-120 (multiple of 2.5 and rounded up to p acket time, ms the next full integer value). Default value: 3 drop-down list Мax. Range of values: 6000 - 510000. average bitrate, bp s Default value: 40000. flag Viber sup p ort not selected by default (displayed only if Viber is enabled) flag Set number of enabled by default channels Match with any codec of the same type – this flag indicates that this codec matches any codec with the same codec type irrespective of matching flags, modes and voice activity detection indicators. In other words if the checkbox is deselected two codecs are considered to be matching (for example, when checking if the codec is allowed during origination), if both codecs have the VAD indicator selected or deselected and their modes/flags are the same. If this flag is selected, this codec is considered to be matching any other codec with the same codec type. Linksys p hones can p rovide calls with satisf actory voice quality over G.726 only if AAL2 codeword packing is selected and Match with any codec of the same type is deselected f or the Lynksys codec group , while AAL2 codeword packing is deselected f or the codecs def ined f or the other equip ment. When done, click the OK button. The newly added record is assigned an automatically generated ID. To edit or delete a record, invoke the pop-up menu and select the necessary option. 5.2.5 Codec groups The table Codec groups keeps information about codecs groups configured in the DB. Individual codecs may be united under one codec group. Page 64 Operating TM Table “Codec groups” To create a new group, invoke the pop-up menu and select Add. Adding a codec group Enter the following data in the displayed dialog. The fields marked with an asterisk are required fields. * Codec group name – enter the name of the group. Description – you can enter any information pertaining to the group being configured in this field. When done, click the OK button. The newly added record is assigned an automatically generated ID. To edit or delete a record, invoke the pop-up menu and select the necessary option. Your next step is to configure codecs that make up the group (see section Codec group setup 5.2.6 65 ) Codec group setup The table Codec group setup presents a general view of available codec groups and their make up. Use this table to change codec groups make up and configure other codecs’ essential parameters. Table of codecs To add a codec to the group, left-click the mouse on a table record and select Add in the pop-up menu. Page 65 Operating TM Configuring codec groups Enter the following data in the displayed dialog (the fields marked with an asterisk are required fields): * Codec group – specify the group the codec will be related to using the drop-down list of this combo box (the drop-down list is populated with the names of groups from the table Codec groups, see section Codec groups 64 ). * Codec – specify the codec using the drop-down list of this combo box. Precedence in group – this parameter allows the operator to define the codec precedence in the list of codecs sent to Traffic Switch. By default all codecs are assigned the precedence value “1”. The greater the precedence value is the higher is precedence. Category Advanced settings Use matching pattern for incom. SDP rtpmap – select the checkbox, if you want to use the Matching pattern for incom. SDP rtpmap parameter for matching the codec indicated in the * Codec field with the incoming codec from the equipment. Otherwise the System will not match the codecs against the SDP rtpmap. Matching pattern for incom. SDP rtpmap – specify a regular expression, used to match the codec indicated in the * Codec field with the incoming codec from the equipment, when the incoming codec has a nonstandard mime type in the SDP rtpmap parameter. If the check box Use matching pattern for incom. SDP rtpmap is selected, but no regular expression is entered, the SDP should contain no rtpmap attribute for the System to match these codecs. Use matching patterns for incom. SDP fmtp – select the checkbox, if you want to use the Matching pattern for incom. SDP fmtp parameter for matching the codec indicated in the * Codec field with the incoming codec from the equipment. Otherwise the System will not match the codecs against the SDP fmtp. Matching patterns for incom. SDP fmtp – enter a regular expression, used to match the codec indicated in the * Codec field with the incoming codec from the equipment, when the incoming codec has nonstandard SDP fmtp parameters. If the check box Use matching patterns for incom. SDP fmtp is selected, but no regular expressions are entered, the SDP should contain no fmtp parameters for the System to match these codecs. The regular exp ression must comp ly with Python Regular Expression Syntax and should not contain “^” and “$” symbols. The regular exp ression is comp ared against the whole rtp map f ield but not its substrings. This means that a regular exp ression G\.729[a]? will match rtp map with the value G.729 or G.729.a, but not with the values XG.729 or G.729ab, though it matches some of their substrings. Substitution string for out. SDP rtpmap – specify a mime type sent to the gateway in the SDP rtpmap Page 66 Operating TM attribute. Substitution strings for out. SDP fmtp – specify strings sent to the gateway as SDP fmtp parameters. Unlike in RFC 3555, by def ault the System recognizes the G.729 codec with no AnnexB p arameter as G.729 p lain and not G.729B. If the sup p ort of equip ment that f ollows RFC 3555 and does not send AnnexB is required, select the Use matching patterns for incom. SDP fmtp check box and leave the Matching patterns for incom. SDP fmtp f ield blank. When through with entering data, click OK to add the record to the table. To edit or delete a record, invoke the pop-up menu and select the necessary option. In a similar fashion you can add other codecs to the groups. 5.2.7 CPS limitation This table allows the user to limit incoming CPS from a specific IP address. To add a limitation, leftclick the mouse on a table record and select Add in the pop-up menu. Adding new incoming CPS limitation Enter the following data in the displayed dialog (the fields marked with an asterisk are required fields): * Subnetwork address – IP address or subnet mask from which the CPS is limited. * Max CPS – maximum incoming CPS from the IP address specified. Allowed values: 0-65535. When through with entering data, click OK to add the record to the table. To edit or delete a record, invoke the pop-up menu and select the necessary option. In a similar fashion you can add other codecs to the groups. 5.2.8 Balancing groups This table comprises a list of balancing groups, defined in the System. To create a new balancing group record, invoke the pop-up menu and select Add. For further information about the balancing groups refer to document [3]. Declaring a balancing group Enter the following information in the displayed dialog (the parameters marked by the asterisk symbol «*», are required fields): * Balancing group name – define the name of the balancing group. The name should match a name specified in the balancing section of TS configuration. Description – you can use this text box to enter whatever information you deem pertinent. Page 67 Operating TM 5.2.9 Media groups The table contains a list of all media groups defined in the System. To create a new media group, invoke the context menu and select Add. For more information refer to Appendix N. Media groups 306 . Declaring a configured media group Enter the following information in the displayed dialog (the parameters marked by the asterisk symbol «*», are required fields): * Balancing group name – define the name of the media group. The name should match a name specified in the balancing section of TS configuration. Description – you can use this text box to enter whatever information you deem pertinent. 5.2.10 RPS limitation This table allows the user to limit the number of incoming registrations per second (RPS) from a specific IP address or a subnet. To add a limitation, left-click the mouse on a table record and select Add in the pop-up menu. Adding new incoming RPS limitation Enter the following data in the displayed dialog (the fields marked with an asterisk are required fields): * Subnetwork address – IP address or subnet mask from which the RPS is limited. * Max RPS – maximum incoming RPS from IP addresses of the specified subnet. Allowed values: 065535. * Drop method - method for dropping registrations that exceed the limit. drop - the System ignores the registration (valid for SIP and H.323). reject - the System sends a 480 message with a Retry-After parameter, comprising a random value (valid for SIP). SIP registrations which were responded with a 401 message are accepted without limitations and are not counted for RPS calculations. When through with entering data, click OK to add the record to the table. To edit or delete a record, invoke the pop-up menu and select the necessary option. In a similar fashion you can add other codecs to the groups. Page 68 Operating TM 5.2.11 Redirect reason translations This table allows the user to define translations for redirect reason codes. The translations are applied to the the whole list of codes before the list is dispatched to the outgoing leg. To add a new translation rule invoke the context menu and select Add. Adding a new redirect reason translation rule Enter the following data in the displayed dialog (the fields marked with an asterisk are required fields): * Source namespace - select the source group of redirect reasons from the drop-down list. * Source code - select the redirect reason code to be subjected to translation from the drop-down list. * Target namespace - select the target group of redirect reasons from the drop-down list. * Target code - select the redirect reason code, into which the source code will be translated, from the drop-down list. When through with entering data, click OK to add the record to the table. To edit or delete a record, invoke the pop-up menu and select the necessary option. Once the record is created it is not p ossible to edit Source namespace, Source code and Target namespace. 5.3 Termination General algorithm of external routing: 1. Firstly, a set and order of dial peers is defined (refer to Dial Peers 74 , Routing policies 79 , Appendix M. Dial peer generation and selection 304 ). After that, a general list of routes is made (the order of dial peers is preserved). 2. Then a list of routes is made for each dial peer based on the value of the parameter Balancing method 74 : - if the value no balancing 74 is selected, routes are listed according to the order of the equipment specified in the parameter Equipment list 74 . - if any other value is selected (i.e. balancing is on), then the gateways will be sorted according to the statistics within this dial peer. 3. If the equipment type is an external routing server (RADIUS-server 40 , SIP-server 40 , ENUMserver 40 or URI-resolver 40 ), then the number or ID of this router will be added to the general list of Page 69 Operating TM routes. Then, the list of routes, received from the corresponding router, will be inserted instead of this ID. If no routes are received from the external router, the corresponding ID is deleted from the general list of routes. The order of responses from the external routing servers does not influence the order of routes. Example: Suppose, the System has a dial peer with 3 SIP-servers of external routing and 2 static gateways, configured in the following order: [gw1, sip1, sip2, gw2, sip3]. The call is directed only to this dial peer. If in response the first SIP-server sent a list of 2 routes (sip1-1 and sip1-2), the second server sent nothing, and the third server sent a list of 3 routes (sip2-1, sip2-2, sip2-3), then the general list of routes will be the following: [gw1, sip1-1, sip1-2, gw2, sip2-1, sip2-2, sip2-3] Thus, the routes, received during external routing, are inserted instead of the corresponding IDs, preserving the order. Note that in RADIUS-routing this case the call is ended. 270 MVTS Pro can receive AccessReject from the RADIUS-server. In When interacting with external routing servers, the components of the System process the requests and the responses to them differently: - In SIP-routing 284 the request is made by the signaling node; the result from the response SIP 302 Moved Temporary in the field Contact is sent to the scripting node, that forms a list of routes based on the received data. - In RADIUS-routing 270 the request is made by the scripting node, that processes the data from the fields xpgk-routing-routing in the message Access-Accept from the RADIUS-server and makes a list of routes. - In H.323-routing 284 the balancing node sends an LRQ request to the gatekeeper, then after receiving LCF, the signaling node sends a call to the received address. The rest of the route parameters are set in the gatekeeper's account. H.323 routing takes place after the scripting node sends the list of routes to the signaling node. - In ENUM-routing 142 the request is made by the scripting node, that uses the data, received from NAPTR from the ENUM-server's response, for a call. The rest of the route parameters are set in the ENUM-server's account. 5.3.1 Pre-routing translations The object Pre-routing number transformation serves to configure number transformation rules that allow number modification with the end to assure dial peer search and route hunting. Number transformation may involve several steps (removal of the prefix, city code, etc.) which may require a number of successively applied rules. The order in which number transformation rules are applied is determined by the rule precedence. To see if the number needs transformation, it is checked against regular expression patterns. The number is subject to transformation if it matches the pattern defined in the fields Allowed SRC numbers pattern, Allowed DST numbers pattern, Allowed SRC groups and Allowed CPC and mismatches the pattern defined in Exclude SRC numbers, Exclude DST numbers, Disallowed SRC groups and Disallowed CPC. In addition, the object Pre-routing number transformation is used to define name transformation rules for groups of registering gateways. Page 70 Operating TM Table of pre-routing number transformation rules To create a new rule, invoke the pop-up menu and select Add. Dialog box for pre-routing translation rules Enter the following information in the displayed dialog (the parameters marked by the asterisk symbol «*», are required fields): * Rule name – enter the rule name. Description – you can use this text box to enter whatever information you deem pertinent. Enable – select the checkbox to make the rule effective. * Precedence – specify the rule precedence entering a positive integer in this field. The greater the entered value, the more precedence the configured rule takes. The precedence of rules defines the order in which number transformation rules are applied. Rules with a greater Precedence value are applied earlier. The list of configured rules is browsed by the system successively which means that prior to performing a DP search (route hunting) the system applies the number transformation rules one by one in the order of their precedence. Allowed values: 0-2147483647. Allowed SRC numbers pattern – enter a regular expression that determines what calling numbers require transformation. You can enter several regular expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which Page 71 Operating TM are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Allowed DST numbers pattern – enter a regular expression that determines what called numbers require transformation. You can enter several regular expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Allowed redirecting numbers pattern – enter a regular expression that determines what redirecting numbers require transformation. You can enter several regular expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Exclude SRC numbers – enter a regular expression that determines what calling numbers do not require transformation. You can enter several regular expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). Disallowed numbers override the allowed ones. You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Exclude DST numbers – enter a regular expression that determines what called numbers do not require transformation. You can enter several regular expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). Disallowed numbers override the allowed ones. You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Exclude redirecting numbers – enter a regular expression that determines what redirecting numbers do not require transformation. You can enter several regular expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). Disallowed numbers override the allowed ones. You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Allowed SRC groups – enter the name of the call origination RAS-user group that needs transformation. You can enter several names delimiting them with «;» (for more information refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). Disallowed SRC groups – enter the name of the call origination RAS-user group not subject to transformation. You can enter several names delimiting them with «;» (for more information refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). Disallowed groups override the allowed ones. SRC number translation – enter a regular expression for transformation of the calling number (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. SRC number translation (billing) – enter regular expressions for modification of calling numbers as required for the purposes of billing (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. DST number translation – enter a regular expression allowing the transformation of the called number (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. DST number translation (billing) – enter regular expressions for modification of called numbers as required for the purposes of billing (for more information refer to Tips and tricks for regular Page 72 Operating TM expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Redirecting number translation – enter a regular expression allowing the transformation of the redirecting number (for more information refer to Tips and tricks for regular expressions 247 ).The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to quote the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. For more information on using regular expressions refer to Number transformation 247 . Group name translation – enter a regular expression for transformation of the group name. Allowed CPC - enter a list of calling party’s categories that determines what calls require transformation. Disallowed CPC – enter a list of calling party’s categories that determines what calls do not require transformation. Disallowed categories override the allowed ones. CPC translation – select the category which replaces the CPC in the call, if the call matches this translation rule. If you want to leave the CPC unchanged, select the blank option. If you select the record with empty CPC, all CPCs will be replaced by the empty ones. * Action – use the combo box to select a required post-transformation action: Next. Next means a transition to the next number transformation rule if any. Stop. Stop means stoppage of the transformation process and call abortion with the local disconnect code configured in the field Quit with disconnect code. If no code is selected in the field Quit with disconnect code, the translation process stops, though the call handling process continues. Again. Again means re-start of the same transformation but applied to the number or group name obtained as a result of the just performed transformation. The re-started transformation is a recursive procedure applied to the result of the previous iteration. Quit with disconnect code – use this combo box to select a disconnect code that the System will provide when aborting a call in response to the * Action option Stop. This p arameter is valid only when the op tion Stop is selected in the f ield * Action. Scheduling - specify the translation rule activity period with the help of checkboxes. A respective control, located below, will be enabled upon activation of a specific combobox. Time of day - a Time of day control will be activated. Specify DP scheduling during every day in this control. Day of week - Monday - Sunday controls will be activated. Specify DP scheduling for the respective day of week in each control. Day of month - a Day of month control will be activated. Specify the DP scheduling for days during every month in this control. Day of year - a Day of year control will be activated. Specify the DP scheduling for every year in this control. Once a control is activated, you can add new schedule records using the schedule record click the button. button. To delete a Several schedules on the same level are joined together. For example if you specify two schedules in Time of day field - from 0:00 till 6:00 and from 12:00 till 14:00, the translation rule will be active every day from 0:00 till 6:00 AND from 12:00 till 14:00. For schedules on different levels (e.g., Day of year and Day of month) the System searches for overlapping intervals. For example, if you define a schedule by Day of year - from 5th April 0:00 till 5th June 0:00, and simultaneously by Day of month - from the 1st day 0:00 till the 10th day 0:00, then in April the translation rule will active only from the 5th to the 10th, and in June from the 1st till the 5th. The Day of week schedules override the Time of day schedules. For example, if you specify a Time of day schedule from 9:00 till 18:00 and simultaneously a Day of week - Monday schedule from 6:00 till 8:00, then the translation rule will be active from from 6:00 till 8:00 on Monday, and from 9:00 till 18:00 Page 73 Operating TM on other days. When done with entering data, press the button OK to add the configured record to the table. The System will generate a unique ID for the record displaying it in the respective column of the table. To view, edit or delete a table record, select the appropriate item on the pop-up menu. 5.3.2 Dial peers In terms of MVTS Pro a dial peer is an addressable object to which the call can be routed. According to the parameters of the incoming call (SRC and DST numbers, routing groups, calling party category, etc.) the DP defines a routing path of the call, call settings for this path and a list of terminating devices, to which within this path the call may be sent. For each routing path the administrator can create either one or several dial peers which are alternative (backup) variants of call routing. Main and alternative routes are defined by the sorting criteria. Therefore, the table of dial peers can be regarded as a dial plan comprised of records with information about possible routing paths for calls originated by static gateways and RAS users. Table of DPs Dial peers can be created one of the following ways: 1) manually - You can create dial peers on the page Dial peers, then add them to the dial plan (static DP). 2) automatically - The System generates a dial peer every time the equipment item with Equipment type=Endpoint equipment is added. 3) dynamically - A dial peer appears every time a subscriber’s terminal operating through the default gateway registers with the RADIUS server and disappears correspondingly when the terminal is no longer registered. (dynamic DP). Refer to Appendix C. Default gateways 253 . Manually created (static) dial peers can be viewed in the dial plan (Table of DPs). Dial peers, automatically generated by the System or appearing at the moment of registration of the equipment on the server, may be viewed only on the page Tree of Dial Peers (refer to Tree of Dial Peers (DPs 82 ). When routing a call, the best route is defined considering the priority and routing policy of DPs, and also considering whether or not the called number matches the DST-number prefix match pattern. Information necessary for call establishing is taken from the DP selected during the routing. For more information on DP selection method refer to Appendix M. Dial peer generation and selection 304 . While handling a call, the system searches for the best routing path taking into account the length of the matching number prefix and the dial peer precedence. The record of the dial peer selected during route hunting provides information necessary for call set up. For further information about DP selection refer to Appendix M. Dial peer generation and selection . 304 To add a dial peer record, invoke the pop-up menu and select Add. Page 74 Operating TM Add dial peer dialog Enter the necessary data in the fields of the displayed form (the asterisk symbol marks the required parameters): Enabled – select the checkbox to make the record valid. * Name – enter the DP name. Description – use this text box to provide whatever information or comments concerning the record that you believe pertinent. Precedence – enter a positive integer that determines the DP precedence over other suitable for the call. The integer may be any number in the range of 0 through 65535. A greater number means greater precedence. The default value is 100. If two precedence values are equal, the order of selecting dial peers is undefined. Routing policy – select the routing policy applied to the dial peer. For further information on routing policies see section Routing policies 79 . * DST prefix allow patterns – use a regular expression to enter a pattern for destination number prefixes allowed for the DP. When entering several expressions delimit them with semicolons (refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). In this parameter, you can specify an URI pattern in the format: proto:username@domain, where the symbol “:” is required (it will serve as the URI indicator). If there is no “@” character, the part between characters “:” and “;” will be interpreted as a user name. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Note that URIs may contain different parameters that should be also taken into account when making the match pattern. For further information about DST prefix patterns refer to Appendix M. Dial peer generation and selection 304 . * Redirecting number prefix allow patterns – use a regular expression to enter a pattern for redirecting number prefixes allowed for the DP. When entering several expressions delimit them with semicolons (refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. DST prefix deny patterns – use these fields to enter regular expressions that define called numbers disallowed to use the DP. You can enter several expressions delimiting them with «|» (refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). Disallowed numbers override the allowed ones.You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. Redirecting number prefix deny patterns – use these fields to enter regular expressions that define redirecting numbers disallowed to use the DP. You can enter several expressions delimiting them with «|» (refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). Disallowed numbers override the allowed ones.You can specify URI in this parameter. It is Page 75 Operating TM necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. user@example.com should be written as .*:user@example\.com. For more information on using regular expressions refer to Number transformation 247 . * Equipment list – make a list of gateways available for use when the DP is selected for call termination. To add a gateway to the list, select its name in the left window pane and click to move the GW name to the right window. To remove a gateway from the list, highlight its name in the right window pane and click . The buttons between the windows in one click. Use the buttons one line up or down in the list. and serve to move all records and to move the gateway name If the Balancing method parameter is set to No balancing, MVTS Pro attempts to set up a call sequentially starting with the first gateway on the list during routing procedure. Otherwise, the order, in which the System establishes a connection with the gateways, is determined by the Balancing method. The external routing algorithm is described in the chapter Termination 69 . Balancing method – use the combo box to select a method of load balancing that the System will use when distributing traffic between multiple gateways of the dial peer being configured. The available options include: No balancing means no call balancing by whatever criterion. Round-robin balancing means that every new call is forwarded to the next gateway in turn. Balancing by absolute load means that every new call is forwarded to the gateway that currently handles the least number of calls. Balancing by load-to-capacity ratio means that every new call will be sent to the gateway that currently displays the least ratio of ongoing calls to gateway capacity. Scrip ting nodes have indep endent gateway cap acity counters. These counters are not synchronized. That’s why when calls p ass through dif f erent scrip ting nodes, the scrip ting nodes may indep endently select the same gateway. Capacity group – select the name of the common capacity group from the drop-down list. The gateway will belong to the selected capacity group. For more information about capacity groups see section Capacity groups 146 . Capacity – specify the maximum number of simultaneous calls that the DP can handle. If the field is empty or zero is entered, the number of calls is unlimited. Allowed values: 0-4294967295. Override number capacity group – select the number capacity group for the SRC numbers. For further information about number capacity groups see section Number capacity groups 147 . Enable statistics – when selected, this checkbox enables call statistics keeping for the DP, the data of which can be later used in graph plotting. Valid from – specify a start date of the record validity period. Valid till – specify an end date of the record validity period. You can leave the f ields Valid f rom and Valid till emp ty. In this case the validity p eriod of the dial p eer will be unlimited. Meter Pulse Message policy (MPM Policy) - select an MPM policy (Meter Pulse Message, for more information refer to Support of SS7 national standard of Finland 210 ). Meter Pulse Messages are transmitted only from the terminating device to the originating one, that is why there are 3 ways to process incoming Meter Pulse messages: Don't send pulses; Pass pulses from outgoing leg; Generate pulses. Page 76 Operating TM By default – Don't send pulses. Before you select the policy Generate pulses, it is necessary to add a tariff in the table Tariffs 84 . Category Number translation rules SRC number translation/DST number translation – enter regular expressions for desired modification of calling and called numbers respectively (refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. to translate the number 1234 into sip:user@example.com write the following translation rule: ^1234$/ sip:user@example.com. Redirecting number translation – enter regular expressions for desired modification of the redirecting number (the last one in the list of redirecting numbers) respectively (refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. to translate the number 1234 into sip:user@example.com write the following translation rule: ^1234$/sip:user@example.com. SRC number translation (billing)/DST number translation (billing) – enter regular expressions for modification of calling and called numbers as required for the purposes of billing (refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. to translate the number 1234 into sip:user@example.com write the following translation rule: ^1234$/sip:user@example.com. Category Advanced settings Allowed SRC number patterns – use a regular expression to enter a pattern for calling number prefixes suitable for this DP. You can enter several expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. to translate the number 1234 into sip:user@example.com write the following translation rule: ^1234$/sip:user@example.com. Denied SRC number patterns – use these fields to enter regular expressions that define calling numbers disallowed to use the DP. You can enter several expressions delimiting them with «|» (for more information refer to Tips and tricks for regular expressions 247 ). The value should not exceed 65,535 symbols (64 KB). Disallowed numbers override the allowed ones. You can specify URI in this parameter. It is necessary to use quoting for the characters which are metacharacters in regular expressions, i.e. to translate the number 1234 into sip:user@example.com write the following translation rule: ^1234$/sip:user@example.com. Allowed SRC groups – gateway groups that are allowed call origination. The value should not exceed 65,535 symbols (64 KB). Disallowed SRC groups – gateway groups that are disallowed call origination. Disallowed groups override the allowed ones. The value should not exceed 65,535 symbols (64 KB). Stop route hunting after this DP – with the checkbox selected, searching for routes will be stopped after this DP is found. For further information about the checkbox refer to Appendix M. Dial peer generation and selection 304 . Override equipment proxy mode – this combo box allows you to override the proxying settings of the terminator for situations when MVTS Pro interoperates with the DP being configured. For further information about proxy policies see section Proxy policies 251 . Page 77 Operating TM If the empty line is selected, media proxy settings of the termination gateway will be applied. Allowed CPC - enter a list of calling party’s categories that determines what calls will be routed to this DP. Disallowed CPC – enter a list of calling party’s categories that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones. CPC translation – select the category which replaces the CPC in the call, if the call is routed to this DP. If you want to leave the CPC unchanged, select the blank option. Override dispatching of redirecting numbers – select the method of dispatching the redirecting numbers for all gateways of this dial peer. Use gateway settings - each gateway will use its respective parameter Term. Dispatch original redirecting number. Dispatch. Do not dispatch. Allowed SRC types of numbers – enter a list of SRC number types (NAI) that determines what calls will be routed to this DP. Disallowed SRC types of numbers – enter a list of SRC number types that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones. Allowed DST types of numbers – enter a list of DST number types (NAI) that determines what calls will be routed to this DP. Disallowed DST types of numbers – enter a list of DST number types that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones. Allowed types of redirecting numbers - enter a list of types of the redirecting number (the last one in the list of redirecting numbers) that determines what calls will be routed to this DP. Denied types of redirecting numbers – enter a list of type of the redirecting number (the last one in the list of redirecting numbers) that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones. Override equipment SRC type of number – select the type of number which replaces the SRC number type of the call, if the call is routed to this DP. If you want to leave the SRC number type unchanged, select the blank option. Override equipment DST type of number – select the type of number which replaces the DST number type of the call, if the call is routed to this DP. If you want to leave the DST number type unchanged, select the blank option. Override type of redirecting number - select the type of number which replaces the number type of the redirecting number (the last one in the list of redirecting numbers), if the call is routed to this DP. If you want to leave the number type unchanged, select the blank option. Allowed SRC screening indicators – enter a list of SRC screening indicators that determines what calls will be routed to this DP. Disallowed SRC screening indicators – enter a list of SRC screening indicators that determines what calls will not be routed to this DP. Disallowed categories override the allowed ones. Override equipment SRC screening indicator – select the screening indicator value which replaces the SRC screening indicator of the call, if the call is routed to this DP. If you want to leave the SRC screening indicator unchanged, select the blank option. Override equipment SRC numbering plan – select the numbering plan which replaces the SRC numbering plan of the call, if the call is routed to this DP. If you want to leave the SRC numbering plan unchanged, select the blank option. Override equipment DST numbering plan – select the numbering plan which replaces the DST numbering plan of the call, if the call is routed to this DP. If you want to leave the DST numbering plan unchanged, select the blank option. Override numbering plan of redirecting number - select the numbering plan which replaces the numbering plan of the redirecting number (the last one in the list of redirecting numbers), if the call is routed to this DP. If you want to leave the numbering plan unchanged, select the blank option. Page 78 Operating TM Override equipment SRC presentation indicator – select the presentation indicator value which replaces the SRC presentation indicator of the call, if the call is routed to this DP. If you want to leave the SRC presentation indicator unchanged, select the blank option. Override codec change policy - select the codec change policy if the call is routed to this DP. If you want to leave the codec change policy unchanged, select the blank option. Category Schedule Scheduling - specify the DP's activity period with the help of checkboxes. A respective control, located below, will be enabled upon activation of a specific combobox. Time of day - a Time of day control will be activated. Specify DP scheduling during every day in this control. Day of week - Monday - Sunday controls will be activated. Specify DP scheduling for the respective day of week in each control. Day of month - a Day of month control will be activated. Specify the DP scheduling for days during every month in this control. Day of year - a Day of year control will be activated. Specify the DP scheduling for every year in this control. Once a control is activated, you can add new schedule records using the schedule record click the button. button. To delete a Several schedules on the same level are joined together. For example if you specify two schedules in Time of day field - from 0:00 till 6:00 and from 12:00 till 14:00, the DP will be active every day from 0:00 till 6:00 AND from 12:00 till 14:00. For schedules on different levels (e.g., Day of year and Day of month) the System searches for overlapping intervals. For example, if you define a schedule by Day of year - from 5th April 0:00 till 5th June 0:00, and simultaneously by Day of month - from the 1st day 0:00 till the 10th day 0:00, then in April the DP will active only from the 5th to the 10th, and in June from the 1st till the 5th. The Day of week schedules override the Time of day schedules. For example, if you specify a Time of day schedule from 9:00 till 18:00 and simultaneously a Day of week - Monday schedule from 6:00 till 8:00, then the DP will be active from from 6:00 till 8:00 on Monday, and from 9:00 till 18:00 on other days. Press the OK button, when through with data entering,. The newly configured DP record will be added to the table of DPs with a unique ID generated by the System and the record creation date displayed in the column Timestamp. To edit, view or delete a record, select the respective item in the pop-up menu. 5.3.3 Routing policies The table “Routing policies” presents a list of route hunting policies based on statistical data for dial peers. Page 79 Operating TM Table with a list of available routing policies Policy routing, as implemented in the MVTS Pro system, is based on statistical data that characterize the path the call will take to get to its final destination. The MVTS Pro standard route hunting is based on the destination number of the call. The softswitch selects several dial peers the regexp destination number patterns of which match the destination number of the routed call and sorts the selected path alternatives by the degree to which the destination number pattern matches the called number. As a result DPs with the destination number pattern best matching the destination number of the call are in the beginning of the sorted list. When it is necessary to take into account additional properties of a potential route the list of selected dial peers is additionally sorted in the ascending order by the numerical value that reflects the statistics taken into account (ASR or PDD, for example). I.e. the dial peers with the smaller result of the routing policy expression are put to the top of the dial peer list. If it is necessary to sort the DP list in the descending order (so that the DPs with the greater result of the routing policy go to the beginning of the list), use the following formula: 1/(f(x)+0.00000000001), where f(x) - the original expression in the routing policy. Therefore, to define a statistics-based routing policy means to define a statistical parameter by which the list of potential routing paths will be additionally sorted. The list of statistical parameters that can be used in policy routing and their symbolic representations is given in the table below. Note that the parameters apply only to the dial peers where these parameters were used as part of a routing policy. Symbolic representation of statistical data used in configuring routing policies. Symbolic representati Parameter on priority DP precedence setting qos Quality of service. MVTS Pro calculates QoS as a ratio of packets lost to total packets transferred, i.e. the smaller is the calculated QoS value, the better is QoS. Unit of measure - percent (0-100). pdd Post Dial Delay. MVTS Pro calculates PDD as the time interval between the receipt of SETUP from the originator and the moment the ALERT, CONNECT or ProgressIndicator = 8 (i.e. ProgressInbandInformationAvailable) is received from the terminating party. Unit of measure - millisecond. asr Standard or conventional ASR (answer seizure ratio). The standard ASR is calculated as the ratio of the total number of non-zero duration calls to total number of calls. Unit of measure - percent (0-100). acd Average Call Duration. Unit of measure - millisecond. scd SETUP-CONNECT Delay. The stretch of time between the SETUP and CONNECT message. Unit of measure - millisecond. cps Calls per Second.. maxActCalls Peak number of active calls totalCallsDur Aggregate duration of all calls ation Page 80 Operating TM normalCalls Number of successful calls failedCalls Number of failed calls totalCalls Aggregate number of all calls outBytes Total number of bytes sent during all calls inBytes Total number of bytes received during all calls actCalls Number of active calls To define a routing policy right-click the mouse to invoke the contextual menu and select Add. Fill out the displayed form entering the policy name in the edit box * Name and an expression that returns a numerical value for the policy in the edit box * Expression. The values that you enter in the field * Expression must conform to the format <dp.parameter_name> where parameter_name is one of the symbolic representations from the table above. Expressions entered in the field * Expression must be a valid expression of the programming language Python. For example, the ASR-based rouing policy is defined by entering dp.asr in the field * Expression while the routing policy based on total number of sent and received bytes for all calls can be defined by the expression dp.inBytes + dp.outBytes. In the formulas, the following trigonometric functions and logarithms are allowed: acos, asin, atan, atan2, ceil, cos, cosh, degrees, e, exp, fabs, floor, fmod, frexp, hypot, ldexp, log, log10, modf, p, pow, radians, sin, sinh, sqrt, tan, tanh; e and pi are constants. These functions invoke similarly named functions from the Python standard library (follow the link http://docs.python.org/library/math.html to see their description). The formula which contains any invalid lexemes is not uploaded from the DB. Once invalid formula is found, the notification is sent to the DB by email (see Appendix P. List of DB alarms 318 ) and this event is recorded to the phoenix.log and the scripting node log. Routing policy form The table “Routing policies” allows verification of entered expressions. Press the Check expression button appearing to the right of the just entered value to see if the expression is a valid one. A successful validation results in the the expression font changing to green and the validity flag Yes appearing next to the expression. Mistyped expression requiring a validity check To correct a mistyped expression switch to edit mode, make the necessary correction and press the Page 81 Operating TM Check expression button again. Corrected expression after validity check 5.3.4 Tree of Dial Peers (DPs) A dial peer tree visually represents the routing patterns for all dial peers specified in the System whether these dial peers are explicitly declared in the Dial peer table, or implicitly generated by the System once an endpoint is created (gateway Equipment type = Endpoint), or created automatically upon equipment registration with the System The initial view of the tree is shown in the figure below. Dial peer tree view To visualize the required branch of the dial peer tree use the Prefix text field. The valid characters for the text field are digits and the # character. If any other character was entered into the DST prefix allow patterns, the System will stop displaying this branch of the tree. In the drop-down list Scripting node select the scripting node which will be used to build a tree of dial peers. Once the digits are entered in the Prefix field and the scripting node is selected, click the Find the part of dial peer tree by entered prefix. The selected branch will be expanded up to the position of the last digit in the prefix. Expanded dial peer tree Page 82 Operating TM To achieve the same effect consecutively expand the tree by pressing the ‘+’ icon next to the prefix digits. Once the prefix is fully entered the System will show a fully expanded tree branch. The vertex of the branch will display the dial peers corresponding to the prefix; their number, associated gateways or endpoints, as well as hyperlinks to their records. The vertex of an expanded DP tree branch Click Dial peers tree to reload the tree and hide all subnodes. For URIs the DP tree is constructed differently (for more information refer to Appendix J. Call routing according to SIP URIs 287 ). Using the links next to the object names in the tree, you can go to dial peer, gateway or endpoint tables. 5.3.5 SIP-routing groups SIP-routing groups are groups of termination gateways from the Equipment table. MVTS Pro can receive names of such groups from external SIP-routing servers. If an obtained group name exists in the SIP-routing groups table, the System sends a call to a gateway from this group using a configured balancing method. For details about external SIP-routing, refer to Appendix I. External routing over SIP/H.323 284 . The table of SIP-routing groups To add a SIP-routing group, invoke the pop-up menu and select Add. Page 83 Operating TM Adding a SIP-routing group Enter the necessary data in the fields of the displayed form: Name of SIP-routing group – name of the routing group to be compared with the value of the tgrp parameter in the SIP 3xx response from an external routing server. Equipment list – list of termination gateways. To add a gateway to the list, select its name in the left window pane and click to move the GW name to the right window. To remove a gateway from the list, highlight its name in the right window pane and click and . The buttons serve to move all records between the windows in one click. Use the buttons and to move the gateway name one line up or down in the list. To quickly find a required GW, start typing its name in one of the Quick search... text boxes. Balancing method – method of distributing traffic between gateways of the group being configured. The available options include: No balancing means no call balancing by whatever criterion. Round-robin balancing means that every new call is forwarded to the next gateway in turn. Balancing by absolute load means that every new call is forwarded to the gateway that currently handles the least number of calls. Balancing by load-to-capacity ratio means that every new call will be sent to the gateway that currently displays the least ratio of ongoing calls to gateway capacity. Scrip ting nodes have indep endent gateway cap acity counters. These counters are not synchronized. That’s why when calls p ass through dif f erent scrip ting nodes, the scrip ting nodes may indep endently select the same gateway. Press the OK button, when through with data entering,. The newly configured SIP-routing group record will be added to the table with a unique ID generated by the System and the record creation date displayed in the column Timestamp. To edit, view or delete a record, select the respective item in the pop-up menu. 5.3.6 Meter Pulse Message Tariffs (MPM Tariffs) 5.3.6.1 Tariffs To add a tariff, invoke a pop-up menu and select Add. Page 84 Operating TM Fill in the following fields: Tariff ID - enter a tariff ID. Tariff description - enter a tariff description. Number of pulses before answer - enter an amount of pulses before the connection (cost of call attempt). If it is not required, enter a zero value. Allowed values: 1-100. 5.3.6.2 Tariff setup Use the page Tariff setup to enter necessary settings: The tariff may consist of one or several periods. Tariff ID - add a tariff identifier for a certain tariff. Number of period - enter an ordinal number of a tariff period. Allowed values: 0-4294967295. Period length, msec - set the length of a period in milliseconds. Allowed values: 0-4294967295. If the tariff period is expected to expire upon the call end, you can leave this field empty or enter a zero value. Number of pulses at the beginning of a period - specify the necessary amount of pulses upon connection, which shall be sent each time the tariff period is switched. Allowed values: 1-100. Timeout before dispatch of periodic pulses, msec - specify a timeout before periodic pulses are sent, in milliseconds. Allowed values: 0-4294967295. If the fields Number of periodic pulses and Timeout before dispatch of periodic pulses, msec have zero values, then no pulses shall be sent. Number of periodic pulses - specify the amount of periodic in one packet for dispatch. Allowed values: 1-100. Interval of pulse dispatch, msec - enter an interval at which pulses shall be sent, in milliseconds. Allowed values: 0-4294967295. 5.4 Debugging The category of objects Debugging comprises four tables – Call simulation, Call debugging rules, Debug calls and Debug registrations. Page 85 Operating TM 5.4.1 Call simulation The object Call simulation allows you to simulate calls with the end to check the System configuration and during troubleshooting in situations when customers or partners complain of improper System functioning. Call simulation dialog To simulate a call enter the following parameters in the Call simulation dialog: * Scripting node – select the scripting node, which will be used to simulate the call. Zone – select a zone from the drop-down list from which the call will arrive. Balancing group – if you simulate calls over Internal protocol, from the dropdown list select the balancing group that will be used as an originator’s address. This dropdown list is invalid for other protocols. SRC protocol - select the signaling protocol from the dropdown list. * Orig. IP address - specify the IP address of the origination gateway. SRC number and * DST number - enter a calling and called number in respective edit boxes. Type of SRC number and Type of DST number - specify the type of calling and called numbers respectively. Redirecting number - enter the redirecting number. Type of redirecting number - enter the type of redirecting number. SRC numbering plan, DST numbering plan, Redirecting numbering plan - specify the numbering plan for SRC, DST and redirecting numbers respectively. These parameters are displayed when H.323, SS7 or Internal protocols are selected in the SRC protocol parameter. Set IAM fields - activate the checkbox if IAM fields should be used during call simulation. This option may be used for SIP-T/SIP-I protocol only. The following fields become active in this case: ISUP SRC number Type of ISUP SRC number ISUP SRC numbering plan ISUP DST number Type of ISUP DST number Page 86 Operating TM ISUP DST numbering plan ISUP redirecting number Type of ISUP redirecting number ISUP redirecting numbering plan ISUP Calling party's category When the System simulates passing of data about the codec from the TS to the TM (see Appendix B. Codec list generation in MVTS Pro 249 ), the Media format and other associated parameters are used. If any codec type, other than unknown, is specified in the Media format, this simulates transmission info about a fully or partially identified codec to the TM. The degree of identification is determined by the Media format not full parameter. If the checkbox is deselected, the codec is considered completely identified. If the checkbox is selected, the codec is considered partially identified. If the parameter Media format has unknown type specified, the checkbox is always selected and the codec is considered unidentified. If the codec is considered completely identified, it is possible to specify its parameters. The codec parameters are determined by its type. The description of these parameters can be found in the Codecs 61 section. If the Media format not full checkbox is activated, the System displays the parameters String for SDP rtpmap and String for SDP fmtp. Specify the data to be placed into SDP rtpmap and SDP fmtp parameters. Though rtpmap and fmtp are written as follows in the SDP: a=rtpmap:18 G729/8000 a=fmtp:18 annexb=true only the part in italics is defined in the String for SDP rtpmap and String for SDP fmtp parameters. In case several fmtp parameters are required, delimit them with commas in the String for SDP fmtp. The procedure for codec identification is described in Appendix B. Codec list generation in MVTS Pro 249 . Orig. NAT address - specify the NAT address, if the origination device sits behind NAT. SRC codecs – by moving codec names from the left window to the right, define the list of codecs used by the call originator. Calling party’s category – select the calling party’s category as if it were present in the incoming leg. Press OK. Call simulation results Results of the call simulation will be displayed in the field Routes. 5.4.2 Call debugging rules This page allows you to configure rules according to which you can define calls for logging. Page 87 Operating TM To add a rule, select the corresponding item in the context menu. The following form will open: In the form, set the following criteria: Enable - select the checkbox to enable this rule. *Name - enter the name of the rule. Description - specify any relevant information. Conference ID of first suitable call - conference ID (conference = incoming leg + outgoing leg) of the first call, which matches the rule. Valid from - specify time and date when the validity period of the rule starts. By default the current time is written to the field. Valid till - specify time and date when the validity period of the rule ends. By default the current time + 1 hour is written to the field. Originators - specify the list of call originating devices. Terminators - specify the list of call terminating devices. Dial peers - specify the list of dial peers participating in the call. Orig.addresses - specify the list of addresses of gateways, from which the call was received (IP[:port]). Term.addresses - specify the list of addresses of gateways, by which the call was received (IP[:port]). Orig.zones - specify the list of zones from which the call was received. Term.zones - specify the list of zones to which the call was sent. Orig.protocols - specify the list of signaling protocols which were used by the device on the incoming call leg. Term.protocols - specify the list of signaling protocols which were used by device on the outgoing call leg. Incoming SRC number pattern - specify the certain number or the pattern of allowed calling numbers Page 88 Operating TM with the help of regular expression. Incoming DST number pattern - specify the certain number or the pattern of allowed called numbers with the help of regular expression. Logging sip-server messages - select the checkbox to debug additional SIP-server messages. With this checkbox selected, the additional information is written to the database in case the System interacted with the SIP-server, even if the call does not match the rule. If no p arameter is sp ecif ied f or call debugging (the f ields Valid f rom and Valid till do not count) , then such rule is not considered active. The System applies the debugging rules to each call. It is considered that a call matches the rule if it corresponds to all the parameters specified in this rule. The record of such call is written to the table Debug calls 89 . If the outgoing leg parameters are specified and at least one route corresponds to them, it is considered that such call matches the rule. If the outgoing leg parameters are specified and routes are not formed (failed call), it is considered that such call does not match the rule. When the System finds the first call which matches at least one rule, the field Conference ID of first suitable call is filled. Other rules from the table are also applied to this call, if the field Conference ID of first suitable call in the settings of these rules is not filled yet. If this field is filled, you can go to the table with the necessary calls (for that, in the menu select Filter related tables -> Debug calls received under this rule). When the debug rules are applied to calls, the parameter Logging sip-server messages is not taken into account. The amount of debug rules is limited by the parameter Max.active debug rules in System global settings 139 . With the help of the debug rules, you can configure call debugging not only according to the gateways and dial peers participating in the call but according to other parameters as well. Due to that, the volume of the input data can be significantly decreased, so you can economize your resources and analyze the received information faster. 5.4.3 Debug calls The table Debug calls presents a list of call logs. To view an individual call log record, select the View item on the pop-up menu. Page 89 Operating TM Call progress log header when viewed from table Debug calls The parameters of the debug call are identical to those present in the CDR table (see section CDRs ). 101 ID – unique ID of the record. Incoming SRC number – calling number as received from the call source. Incoming DST number – destination number as received from the call source. Outgoing SRC number – calling number after transformation according to the configured number translation rules. Outgoing DST number – destination number after transformation according to the configured number translation rules. Remote orig. signaling address – signaling IP address and port of the call originator. Remote term. signaling address – signaling IP address and port of the call terminator. Setup time – timestamp of the call setup. Conference ID – unique identifier of the conference the call was a party to (conference = incoming call leg + outgoing call leg). ID of rules – IDs of rules from the table Call debugging rules 87 . To view the call log of interest invoke the pop-up menu and select the Get call log item in the Special function section. Page 90 Operating TM Invoking the call log for viewing You will be displayed the call log page that presents the call log header followed by a table of packets exchanged during the call. Call progress log view Click the Expand all control to spread out the list of packets and examine their contents in detail. Use the partial expansion control than spread out the entire packet. when you intend to view a small portion of the packet rather Page 91 Operating TM Using partial expansion control for contents viewing The time in Debug call log is a monotonically increasing time, emp loyed to p reserve the order of p ackets receip t and disp atch. This time may dif f er f rom the timestamp s, sp ecif ied in CDRs, which are used f or billing, as they are based on the server time. 5.4.4 Debug registrations The table Debug registrations contains records about debug registrations of regestering equipment. The maximum number of records in the tables is defined by the global setting Max. debug call/ registration sessions (see section System global settings 136 ). If the number of entries is large, use a filter to find necessary records. ID – unique ID of the record. Registration username – login of the registered device. Phone number – name/number/alias of the registered device. Signaling address – originator’s IP address, used for signaling. Signaling protocol - protocol used by the registered device. Registration time – date and time of the registration. Registration ID – TS registration ID. Page 92 Operating TM 5.5 Traffic Switch This subcategory of objects allows real-time monitoring of the System operation and provides information about equipment registrations, currently handled calls, system sockets, etc. The operator can view summarized information or detailed information about the operation status of every System component. For more information about Traffic Switch and its configuration, refer to document [3]. 5.5.1 TS CLASS 4 conferences The table TM CLASS 4 conferences contains information about CLASS 4 calls currently handled by the TS. Each record provides the following data: Connect time – timestamp of the call connect. In-call time – current call duration. Incoming leg call ID – call ID on the incoming leg. Remote SRC signaling address – signaling IP address and port of the call originator. Incoming leg protocol – signaling protocol used on the incoming call leg. Incoming SRC number – calling number as received from the call source. Incoming DST number – destination number as received from the call source. Outgoing leg call ID – call ID on the outgoing leg. Remote DST signaling address – signaling IP address and port of the call terminator. Outgoing leg protocol – signaling protocol used on the outgoing call leg. Outgoing SRC number – calling number after transformation according to the configured number translation rules. Outgoing DST number – destination number after transformation done according to the configured number translation rules. The user is also able to cancel calls in the web interface. Invoke the context menu on the required conference record and select the Delete option. The respective call will be terminated. 5.5.2 TM CLASS 4 calls The table TM CLASS 4 calls comprises data on the current CLASS 4 calls, handled by the TM. The table contains information collected from all scripting nodes. Each record comprises the following information: TS Conference ID – Conf ID, generated by the TS. Protocol Conference ID – Conf ID, obtained from the protocol messages. Call State – current call state. Originator ID – ID of the originator DB record. Originator name – name of the originator in the DB. Page 93 Operating TM Incoming leg protocol – signaling protocol on the incoming leg. Incoming SRC number – SRC number on the incoming leg, before number translations. Incoming DST number – DST number on the incoming leg, before number translations. SETUP time – time of SETUP message arrival. CONNECT time – time of CONNECT message arrival. In-call time, sec – general call duration. Dial peer – dial peer, through which the call was routed. Terminator ID – ID of the terminator DB record. Terminator name – name of the terminator in the DB. External routing server - name of the external routing server used in case of routing over RADIUS, ENUM, SIP-server. Outgoing leg protocol – signaling protocol on the outgoing leg. Outgoing SRC number – SRC number on the outgoing leg, after all number translations. Outgoing DST number – DST number on the outgoing leg, after all number translations. The user is also able to cancel calls in the web interface. Invoke the context menu on the required call record and select the Delete option. The respective call will be terminated. 5.5.3 TS CLASS 5 legs The table TS CLASS 5 legs is not used in MVTS Pro. 5.5.4 TS incoming registrations This object comprises data on the devices registered with the TS. Each record comprises the following information: Registration ID – unique registration ID, assigned by the TS. Protocol – protocol that the registered device uses. Username – name of the registered device. Address – IP address of the device; State – registration state: Initial (the registration process has started, but not yet completed). Passed (registration completed, the gateway is registered). Re-registration (complete re-registration of the devices is pending). Unknown (gateway registration status is unknown). Page 94 Operating TM Unregistering (gateway is unregistering). TTL, sec – timeout after which the complete re-registration takes place. Aliases – names/numbers, received in the registration message. Expiration – time when the registration expires. 5.5.5 TM incoming registrations This object comprises data on the devices registered with the TM. The table contains information collected from all scripting nodes. Each record comprises the following information: Registration ID – registration ID. Gateway ID – database record ID of the registering gateway. Gateway name – name of registering gateway in the DB. Protocol – protocol that the registered device uses. Username – name of the registered device. Node – scripting node that received the registration message. 5.5.6 Nodes This subcategory provides detailed information about operation status of the TS nodes distributed by separate subcategories. The number of subcategories depends on the number of the running nodes. The names of the subcategories correspond to the names of the nodes configured in the TS configuration file(-s). For brevity sake let us consider a system with one module of each type running (imaginary names of modules are in angle brackets). All modules have the following objects: IP zones - sockets that are open on the node. Protocols - protocols used to connect this node with others. Counters – information about system counters (refer to document [3]). The object IP zones includes the following information: Remote node – name of the remote node, to which this node is connected. Zone - shows the name of IP zone to which the open socket belongs. Zones are configured in system.conf. Local address – IP address of the local socket, which establishes a remote connection. Remote address – IP address of the remote socket, receiving connection from the locally connected socket. If the remote address is 0.0.0.0, this means that the local socket is waiting for an incoming connection. The object Protocols includes the following information: Protocol - the name of protocol under which the node operates Page 95 Operating TM Local address – IP address of the local socket, which establishes a remote connection. Remote address – IP address of the remote socket, receiving connection from the locally connected socket. If the remote address is 0.0.0.0, this means that the local socket is waiting for an incoming connection. The object Counters includes the following information: Name – the name of the system counter. Value – the value of the system counter. <Management> This sub-directory includes the objects IP zones, Protocols and Counters that deliver statistical information pertaining to the Management node. <Signaling> This object provides statistical information about the signaling node. In addition to the common objects IP zones, Protocols and Counters it shows: TS CLASS 4 conferences – data on the current CLASS 4 calls handled by the node (see TS CLASS 4 conferences 93 ). TS CLASS 5 legs – data on the CLASS 5 call legs, handled by the node (see TS CLASS 5 legs 94 ). <Balanacer> This object is a repository of statistical information about the H.323 gatekeeper/balancer module. Apart from the common objects IP zones, Protocols and Counters, the object includes the table Registrations showing information about registered devices. Registrations – data on the registered devices (see TS incoming registrations 94 ). <Media> This folder contains operational statistics pertaining to the Media node and includes the objects IP zones, Protocols and Counters. <Scripting> This folder contains operational statistics pertaining to the Scripting node and includes the objects IP zones, Protocols and Counters. Registrations – data on the registered devices, handled by the specific scripting node (see TM incoming registrations 95 ). Calls – data on the calls handled by the specific scripting node (see TM CLASS 4 calls 93 ). <Synchro> This folder displays the Synchro node operational statistics contained in the objects IP zones, Protocols and Counters. <SS7-node> This folder contains operational statistics pertaining to the SS7 Call Agent node and includes the common objects IP zones, Protocols and Counters. 5.5.7 Active nodes The table Active nodes comprises the names of all active nodes in the system (column Name) and their uptime (column Uptime). Page 96 Operating TM 5.5.8 SS7 calls This table comprises the information about the SS7 calls, passing through a SS7 Call Agent node. Each record includes the following fields: SS7 calls Call ID – unique identifier of the call. Conference ID – unique identifier of the conference the call was a party to (conference = incoming call leg + outgoing call leg). Calling Party ID – ID of the calling party. Called Party ID – ID of the called party. Circuit ID – ID of the media circuit in an E1 trunk in the form of <hw_id>-<span_id>-<timeslot>, where <hw_id> - media gateway ID, to which the E1 circuits are connected, <span_id> - ID of an E1 trunk as part of the ISUP connection, <timeslot> - timeslot of in the E1 trunk. Circuit group ID – ID of a circuit group, to which the current media circuit belongs. SS7 zone – a SS7 zone to which the call (call leg) belongs. 5.5.9 ISUP circuits This table comprises the information about the state of media circuit, which is a part of an ISUP connection. Each record includes the following fields: ISUP circuits Call ID – unique identifier of the call. Conference ID – unique identifier of the conference the call was a party to (conference = incoming call leg + outgoing call leg). Circuit ID – ID of the media circuit in an E1 trunk in the form of <hw_id - circuit_id - connection_id>, where hw_id - media gateway ID in the table Media gateways 205 , circuit_id - circuit ID in the table Circuits 210 , connection_id - connection ID in the table ISUP connections 207 . ISUP circuit label – circuit label in the form <NodeId - RPC - CIC>, where NodeId - ID of local node in the table MGCP local instances 206 , RPC - remote point code, CIC - media circuit code. Incoming connection – shows if the circuit is used for incoming traffic. Page 97 Operating TM Outgoing connection – shows if the circuit is used for outgoing traffic. Circuit state - ISUP circuit state: Blocked Unblocked Offline cause - reason why the ISUP circuit is unavailable: DPC is unavailable Remote User Part is unavailable Remote maintenance is blocked Remote hardware is blocked Local block (User) Local block (MGCP) The columns Circuit state and Offline cause are filled as follows: 1. The System checks the DPC state. If it is other than Available, then the Circuit state is Blocked, the Offline cause is DPC is unavailable 2. If the DPC is Available, the System checks the state of the Remote User Part (RUP). If it differs from Available, then the Circuit state is Blocked, the Offline cause – Remote User Part is unavailable. 3. In case DPC and RUP are available, the System checks the state of the remote block in the columns Remote circuit block state (maintenance) and Remote circuit block state (hardware). If the value of the Remote circuit block state (maintenance) differs from Unblocked, then the Offline cause is Remote hardware is blocked. If the Remote circuit block state (hardware) is Unblocked, and the value of the Remote circuit block state (maintenance) is other than Unblocked, then the Offline cause is Remote maintenance is blocked. 4. In case DPC and RUP are available and if there is no remote block, the System checks the state of the local block in the column Local circuit block state. If its value differs from Unblocked, the Circuit state is Blocked, the Offline cause is Local block (User) or (MGCP) depending on the value of Local block initiator. 5. Otherwise the Circuit state is Unblocked, the column Offline cause is empty. Circuit state – current state of the circuit. The values are the following: Idle, Out of service, Waiting RLC in reply RSC, Continuity phase out, Waiting RLC in reply REL, Waiting ACM, Waiting ANM, Call suspended: SUS-message sent, Call active, Waiting release response, Waiting alerting, Alerting, Waiting reset end, Page 98 Operating TM Waiting call accept, Process incoming IAM, Call suspended: SUS-message received. Remote point code state - state of the remote point code. Local circuit block state (maintenance) – state of the local media circuit block of type maintenance oriented. Local block initiator - initiator of ISUP circuits block: User - manual block of circuits MGCP - automatic block of circuits in case of unsuccessful audit of the MGCP endpoint Local circuit block state (hardware) – state of the local media circuit block of type hardware oriented. Remote circuit block state (maintenance) – state of the remote media circuit block of type maintenance oriented. Remote circuit block state (hardware) – state of the remote media circuit block of type hardware oriented. Reservation subsystem state – shows if the circuit is reserved. Zone – SS7 zone to which the media circuit pertains. To change the state of the circuit invoke the pop-up menu on the required record and select the desired procedure. Available procedures: Block – locally blocks the circuit using the maintenance oriented block type. Unblock – locally unblocks the circuit using the maintenance oriented block type. Reset state – sets the circuit state to Idle and sends a Reset Circuits message to a remote SS7 switch . 5.5.10 MGCP endpoints This table comprises the information about the MGCP endpoints. Each record includes the following fields: MGCP endpoints SS7 media gateway ID – ID of the MGCP gateway. E1 trunk ID – ID of the E1 trunk, connected to the media gateway. Endpoint ID – ID of the MGCP endpoint. Endpoint state – state of the MGCP endpoint. Endpoint name – name of the MGCP endpoint. Call ID – unique identifier of the call. Displayed endpoint state - displayed state of the MGCP endpoint. Page 99 Operating TM 5.5.11 M3UA associations This table comprises the information about the M3UA SCTP associations. Each record includes the following fields: M3UA associations M3UA association ID – ID of the M3UA SCTP association. Association status – status of the SCTP-association. Local endpoint ID – ID of the local SCTP endpoint. Remote endpoint ID – ID of the remote SCTP-endpoint. Number of incoming SCTP-streams – number of incoming SCTP streams. Number of outgoing SCTP-streams – number of outgoing SCTP streams. 5.5.12 Reserved circuit groups This table comprises information about reserved circuit groups. Each record includes the following fields: Group ID – the ID of the reserved circuit group. Number of elements – number of elements in the group. Circuit hunting policy – the method for selecting an unassigned circuit for the outgoing call. State – state of the circuit group. Page 100 Operating TM 5.6 CDRs The subcategory CDRs includes six tables that display call detail records (CDRs) used in metering and billing. In the table Last 1000 CDRs only the last 1000 call detail records are stored, which can decrease interface latency in case of a large DB. The table Inaccurate comprises CDRs created after a signaling or scripting node crash. When the f ree sp ace in the DB and on the local HDD is exhausted, the System stop s handling calls. To avoid such a situation, remove obsolete CDRs f rom the DB. A method to remove CDRs f rom the database is described in Ap p endix F. Removing CDRs f rom the DB 281 . Besides the System features an ability to create CDRs not after call termination or call attempt, but also while the call passes through the System. Such interim CDRs are entered into the DB at specified intervals. To enable this feature, set the CDR interims enabled parameter in the System global settings to 1 and specify the period for creating interim CDRs in the Interims period parameter. However, this mode causes additional load to the DB what reduces general system performance. Select View from the pop-up menu to conveniently view the required CDR. You can also use the popup menu to export the table data into a CSV-file (see section Data export 28 ). Page 101 Operating TM Viewing a CDR record CDRs may contain the following information: ID – the unique identifier of the record. CDR date – date of the record creation. The value of the CDR date f ield dep ends on the Value f or "Date" f ield in CDR: 1 - Setup time, 2 Disconnect time p arameter in the Global settings obj ect. If the p arameter is equal to 1, then value of the CDR date means the setup time of the call; if it is equal to 2, the value of the CDR date means the disconnect time of the call. Record type – if the CDR is an intermediate one, the parameter comprises its type: Start – the CDR created at the beginning of the call. Interim <number> – interim CDR and its number. Such CDRs are created at regular intervals defined by the Interims period parameter. Final – final CDR created at the end of the call. If the System is configured not to create CDRs, the CDRs will have Final type. Incoming SRC number – calling number as received from the call source. Incoming DST number – destination number as received from the call source. Outgoing SRC number – calling number after transformation according to the configured number translation rules. Outgoing DST number – destination number after transformation according to the configured number translation rules. Billing SRC number – calling number used for the purposes of billing. Billing DST number – destination number used for the purposes of billing. Signaling node – name of the signaling node that handled the call. Page 102 Operating TM Remote orig. GK address – IP address of the originating gatekeeper. Remote orig. signaling address – signaling IP address and port of the call originator. Remote term. signaling address – signaling IP address and port of the call terminator. Remote orig. media address – media IP address and port of the call originator. Several addresses may be stored. Remote term. media address – media IP address and port of the call terminator. Several addresses may be stored. Local orig. signaling address – IP address and port of the signaling node used on the incoming leg. Local term. signaling address – IP address and port of the signaling node used on the outgoing leg. Local orig. media address – IP address and port of the media node used on the incoming leg. Several addresses may be stored. Local term. media address – IP address and port of the media node used on the outgoing leg. Several addresses may be stored. Incoming leg protocol – signaling protocol of the incoming leg. Outgoing leg protocol – signaling protocol of the outgoing leg. TS Conference ID – unique identifier of the conference the call was a party to (conference = incoming call leg + outgoing call leg), generated by the TS. TS Incoming leg call ID – call ID, generated by the TS, on the incoming leg. TS Outgoing leg call ID – call ID, generated by the TS, on the outgoing leg. Protocol Conference ID – unique identifier of the conference the call was a party to (conference = incoming call leg + outgoing call leg), received in the protocol messages. Protocol Incoming leg call ID – call ID, received in the protocol messages, on the incoming leg. Protocol Outgoing leg call ID – call ID, received in the protocol messages, on the outgoing leg. Orig. registration username – registration username of the call originator. Term. registration username – registration username of the call terminator. RADIUS username – username sent to the external RADIUS server. Origination gateway – name of the origination gateway. Termination gateway – name of the termination gateway. External routing server - name of the external routing server used in case of routing over RADIUS, ENUM, SIP-server. Dial peer – name of the dial peer. Orig. in-call time – call duration in seconds or milliseconds (depending on the value of the parameter "In-call time" representation method in CDR-tables: 1-sec, 2-msec 138 in System global settings) for incoming leg. The field remains blank if the call failed to establish. Term. in-call time – call duration in seconds or milliseconds (depending on the value of the parameter "In-call time" representation method in CDR-tables: 1-sec, 2-msec 138 in System global settings) for outgoing leg. The field remains blank if the call failed to establish. Orig. setup time – timestamp of the call setup for incoming leg. Term. setup time – timestamp of the call setup for outgoing leg. Orig. connect time – timestamp of the call connect for incoming leg. Term. connect time – timestamp of the call connect for outgoing leg. Orig. disconnect time – timestamp of the call disconnect for incoming leg. Term. disconnect time – timestamp of the call disconnect for outgoing leg. Disconnect code – call disconnect code. Incoming leg codecs – list of codecs received from the call originator. Outgoing leg codecs – list of codecs received from the call terminator. Page 103 Operating TM SRC Faststart present - “Yes” indicates that the origination gateway declared the use of the FastStart mechanism. DST Faststart present – “Yes” indicates that the termination gateway accepted the use of the FastStart mechanism. SRC Tunneling present – “Yes” indicates that the origination gateway declared the use of the tunneling mechanism. DST Tunneling present – “Yes” indicates that the termination gateway accepted the use of the tunneling mechanism. Proxy mode – media proxy mode. LAR fault reason – reason for call routing interruption. Routing retries – number of routing retriesstarting with 1. 0 - if the call was ended before connection attempts on the routes. Orig. SCD, msec – time in milliseconds that elapsed between the receipt of SETUP and CONNECT for incoming leg. With no CONNECT message the field will be empty, but only if the value of the parameter Fill the SCD parameter in CDR even if connection was not established in the global settings is 0. Term. SCD, msec – time in milliseconds that elapsed between the receipt of SETUP and CONNECT for outgoing leg. With no CONNECT message the field will be empty, but only if the value of the parameter Fill the SCD parameter in CDR even if connection was not established in the global settings is 0. Orig. PDD, msec – time interval between receipt of SETUP from the call originator and receipt of Alert or Connect or ProgressIndicator=8 (ProgressInbandInformationAvailable) from the terminating party for incoming leg. Term. PDD, msec – time interval between receipt of SETUP from the call originator and receipt of Alert or Connect or ProgressIndicator=8 (ProgressInbandInformationAvailable) from the terminating party for outgoing leg. Media group - media group used to route the call. Orig. media bytes in – number of ingress bytes received from the call originator. Orig. media bytes out – number of egress bytes sent to the call originator. Term. media bytes in – number of ingress bytes received from the call termination party. Term. media bytes out – number of egress bytes sent to the call termination party. Orig. media packets – quantity of media packets received from the call originator. Term. media packets – quantity of media packets received from the call termination party. Orig. media packets late – number of late packets received from the call originator. Term. media packets late – number of late packets received from the call termination party. Orig. media packets lost – amount of packets not received from the call originator. Term. media packets lost – amount of packets not received from the call termination party. Orig. min. jitter buffer size (packets) – minimum jitter buffer size when receiving packets from the call originator. Orig. max. jitter buffer size (packets) – maximum jitter buffer size when receiving packets from the call originator. Term. min. jitter buffer size (packets) – minimum jitter buffer size when receiving packets from the call termination party. Term. max. jitter buffer size (packets) – maximum jitter buffer size when receiving packets from the call termination party. Last CDR – «Yes» in this field means that this record is the last one among all records associated with the specific call. CDRs are written f or all call attemp ts irresp ective of their success, and the state of this f lag gives a p ossibility to determine if this record should be f ed into the billing system. Page 104 Operating TM Q.850 Reason – disconnect reason code from the SIP Reason header. The code is received from a H.323 gateway, sitting behind a SIP device. Incoming leg CPC – the calling party category as received by the System from the calling gateway. Outgoing leg CPC -the calling party category sent by the System to the called gateway. When transf orming the calling p arty category f rom one standard into another (e.g. CPC into OLI or vice versa) , this p arameter stores the category bef ore such transf ormation occurs. Orig. zone – zone of the gateway from which the call originated. Term. zone – zone of the gateway where the call was terminated. Disconnect initiator – the party which initiated call disconnect. Incoming SRC number type – incoming type of the SRC number. Incoming DST number type – incoming type of the DST number. Outgoing SRC number type – outgoing type of the SRC number. Outgoing DST number type – outgoing type of the DST number. Incoming redirecting number – incoming redirecting number. Outgoing redirecting number – outgoing redirecting number. Aux. SRC disconnect codes – auxiliary disconnect codes sent to the incoming call leg. Aux. DST disconnect codes – auxiliary disconnect codes sent to the outgoing call leg. ExtraData - additional field, which is filled, if the CDR was generated for the route, received within the external routing. The value of the field is taken from the parameter extra (for the old format of the field xpgk-xrouting-routing - see the section Field xpgk-xrouting-routing (old format) 274 ) or extraData (for the new format of the field xpgk-xrouting-routing - see the section Field xpgk-xrouting-routing (new format) 275 ). RADIUS Group - name of the group of RADIUS servers from the originator settings, to which authorization and accounting packets are sent. Fields Incoming SRC screening indicator, Incoming SRC presentation indicator, Outgoing SRC screening indicator, Outgoing SRC presentation indicator when exported have digital values, and when they are viewed through the web-interface they have the format: <digital code> - <decoding> (1 - User-provided, verified and passed, 0 - Presentation allowed, etc.). Presentation Indicator: PRESENTATION_ALLOWED = 0 PRESENTATION_RESTRICTED = 1 NOT_AVAILABLE = 2 Screening Indicator: USER_PROVIDED_NOT_SCREENED = 0 USER_PROVIDED_VERIFIED_AND_PASSED = 1 USER_PROVIDED_VERIFIED_AND_FAILED = 2 NETWORK_PROVIDED = 3 The parameters Pulses sent (FICORA) and Pulses received (FICORA) are used for accounting of received and sent pulses (for more information refer to Support of SS7 national standards of Finland 210 ). Pulses sent (FICORA) - amount of pulses, sent to the originating device. If no pulses were sent (the policy "Do not transfer" 76 was selected), the field shall be empty. Pulses received (FICORA) - amount of pulses, received from the terminating device. If no pulses were received (the gateway configuration does not support operation under Ficora), the field shall be empty. SIP routing group - group of termination gateways received from an external SIP-routing server (see SIP-routing groups 83 ). Page 105 Operating TM Using the special function of the context menu it is possible to invoke a debug call log for this CDR. If the CDR was entered into the DB while debug logging was turned on, you will be able to view all messages pertaining to the call in the debug call log. 5.6.1 CDRs scheduled export The object Scheduled export in the category Export CDRs allows you to configure unattended export of call detail records by means of the cron scheduler. CDR export is possible in a plain-text and CSV file. To configure unattended export of CDRs, open the Export CDRs form (CDRs > Scheduled export) and enter the parameters 107 necessary for creation of a cron job. CDRs scheduled export form When through with filling out the form click OK to create a cron job. If the checkbox Enable is selected, the cron task will be created for the www-data user with the help of the crontab command. You can view the created cron-task (if the export is enabled) using the following command: crontab -l -u www-data See also: Scheduled export settings 107 Scheduled export algorithm 112 Correspondence of exported file fields and CDR fields 112 Configuring authentication by SSH keys when unloading CDRs to SFTP server 120 Page 106 Operating TM Examples of exported files 5.6.1.1 121 Scheduled export settings This section described parameters which appear in the Export CDRs form. Enable – use this checkbox to enable/disable the scheduled CDR export function. Clear export data – select this checkbox, if it is necessary to delete the service data of the CDRs export. Running time for the script is set with the help of the tab Autoexport schedule. The cron-task is formed according to the Autoexport schedule parameters. When the scheduled export is started, the System exports all CDRs starting from the moment of the last export up to the present moment. If the scheduled export is started for the first time, the System exports the CDRs starting from the moment specified in the parameter Starting date. The group of settings Autoexport schedule contains 4 parameters (checkboxes): Every minute Every hour Every day Every month In order to modify the schedule, clear the checkbox with the corresponding unit of time. If you clear the checkbox Every minute or Every hour, the dropdown list Schedule setting method will appear. Select one of the values: specifying ordinal number (you can specify minutes and hours when the task will be carried out) specifying repeat pattern (you can specify a repeat pattern for the task, for example, if you specify 5, the task will be performed every 5 minutes) If you clear the checkbox Every day, the dropdown list Specification of days will appear. Select one of the available values: days of week (you can specify the day of week when the task will be carried out) days of month (you can specify the day of month when the task will be carried out) With the checkbox Every month cleared you can specify months when the task will be carried out. Page 107 Operating TM * Timezone – choose the desired time zone that will be used for CDR selection during scheduled export. The System selects CDRs for export by the DB date, which may not coincide with the System date in the web-interface. Def ault DB time zone is UTC. Starting date – the date prior to which no CDRs are exported. If CDRs are exported for the first time, the export is started from the moment specified in this parameter. The value is specified considering the selected timezone. Ap p lying new exp ort p arameters does not trigger immediate attemp t to exp ort CDRs. The exp ort will take p lace only when current settings make it p ossible. Export fields – windows that allow you to change the content of exported CDRs and the arrangement of data in them. Making up a list of exported CDR data The left window displays all data fields and their arrangement in a CDR (top lines data appear in the Page 108 Operating TM beginning of the CDR). If you wish to customize the makeup and arrangement of information in exported CDRs, select the necessary data and click the left-arrow button to transfer the selected items to the right window. The double-arrow button serves to move all items indiscriminately between the windows. The and buttons allow arrangement of data items in CDRs. Moving an item one line up corresponds to moving the data item one position closer to the start of the CDR. Conversely, moving a data item one line down means moving the data piece one position closer to the end of the record. * Save to – indicates the location where exported CDR files will be saved. Two possible options include: file system locally. This option allows file saving to the HDD or external media mounted on the file system of the DB server. FTP server. This option provides for saving exported CDRs to a remote FTP machine. Export directory – sets a directory where CDR files will be saved. When sp ecif ying a directory f or CDR f iles the administrator must remember that the www-data user in the name of which f ile saving is done must p ossess reading, writing and access rights f or that directory (the directory should have the rights set to 777) . Export CDRs - select the type of exported CDRs: All CDRs - export all CDRs. Native CDRs - export CDRs that were created on this server only. All CDRs except native - export CDRs that were received from another server as part of the replication process. If the mode Native CDRs is selected, then the p ref ix of f iles' names should be unique f or each server, involved in the exp ort. For that it is necessary to sp ecif y dif f erent values f or the p arameter CDR f ilename p ref ix on the main and redundant servers. * Export format – allows you to control the format of exported CDRs. Two possible options include: MVTS-1. When this export format is selected CDRs are written to a plain text file as a set of several lines (1 CDR per a line) formatted like (FIELD_NAME_IN_CAPITALS1=data1[delimiter] FIELD_NAME_IN_CAPITALS2=data2[delimiter]... etc.). CSV. With this data export format selected, CDRs will be written to a conventional CSV file viewable in Microsoft Excel™. Enable post-processing – activate checkbox to enable the post-processing of the exported CDRs. See section CDR post-processing 123 for details. Category General settings Date format – defines format for dates. Entries should be done in MySQL notation, for example, the entry «%Y-%m-%d %H:%i:%s» corresponds to a date of the type «YYYY-MM-DD HH:MM:SS». * Delimiter – specifies a separator symbol for data fields in export CDRs. Each CDR starts on a new line. It is not recommended to use semicolon as a delimiter during CDR exp ort if there is no value in the p arameter CSV. Quotation marks. This may result in misp laced columns in the resulting f ile. Export zero duration CDRs – select the checkbox to export CDRs representing zero duration calls. * Show call duration in – select a method of presenting call duration in exported CDRs from the combo box. Max. number of CDRs per file – sets maximum permissible quantity of CDRs per file. If actual values hap p en to be in excess of those def ined in the f ields Max. number of CDRs p er f ile the system creates additional exp ort f iles with index _1,_2 etc in the f ilename. For examp le, [f ilename] _1.csv(or .txt) , [f ilename] _2.csv(or .txt) ; Export IP addresses with ports – select the checkbox to export IP addresses of the originator and Page 109 Operating TM terminator with ports used for signaling. Category MVTS-1 format settings MVTS-1. Leading distinguisher – this field allows you to enter a distinctive character string that will precede all CDRs in the export file (MVTS 1 format). MVTS-1. Put date in the beginning – activate the checkbox to export CDRs with the date in the beginning (MVTS-1 format). MVTS-1. Export blank fields – activate the checkbox to export fields that can not be filled out in the exported CDRs. (Valid when using MVTS-1 format). Category CSV format settings Include headers in CSV file – selection of this checkbox causes inclusion of data fields headers in exported CDRs. This setting is valid only when CSV is selected as the exp ort f ormat, that is the p arameter Exp ort f ormat is set to CSV. CSV. Quotation marks – allows selection of single or double quotes (or none at all) that enclose CDR data in the export file.The default value is " (double quotes); CSV. Use for empty fields – sets a string used in export CDRs to identify empty data fields. Category Substitution settings Find in fields – specify the string to be searched for in the exported CDR fields. This string will be replaced by the value of the Replace with parameter. Replace with – specify the string which will replace the string of the Find in fields parameter. For example, if the Find in fields parameter = 111 and the Replace with parameter = 222, during the export procedure the System will replace 111 with 222 in the exported fields of the call detail records. Category File settings * Compression – allows the choice of compression methods (bzip2 or gzip) for export CDR files. Save empty files – with this check box selected an empty file will be saved if no new CDRs have been generated since the latest launch of the cron export job. CDR filename prefix – a character string used for generation of filenames for exported CDRs files. CDR filename postfix – a string of characters that will be concatenated to the filename, extension included. Add sequence number – select the checkbox to add a unique sequence number to the file name. The sequence number is incremented even when the checkbox is deselected. When the number exceeds 999999 it is reset to 000000 and the incrementation process starts anew. The sequence number is inserted after the postfix and separated from the latter by an underscore "_". For filename use timestamp of – allows selection of a time stamp for generation of the export file name (see below). Two available options include: first CDR. Use the time stamp of the first CDR in the file in filename generation. last CDR. Use the time stamp of the last CDR in the file in filename generation. Filename template– defines the template of filenames for exported CDRs. By default, the value is “%Y %m%d_%H%i%s” which corresponds to a date of the type “YYYY-MM-DD HHMMSS”. The table below shows the list of allowed specifiers. Filename format specifiers Page 110 Operating TM Specifier Description %d Day of the month, numeric (00..31) %H Hour (00..23) %i Minutes, numeric (00..59) %j Day of year (001..366) %k Hour (0..23) %m Month, numeric (00..12) %s Seconds (00..59) %u Week (00..53), where Monday is the first day of the week %w Day of the week (0=Sunday..6=Saturday) %Y Year, numeric, four digits %y Year, numeric (two digits) The line can also take an underscore "_", a hyphen "-" and a space. The name of the file to which exported CDRs are saved is generated in the format PDS, where P - character string entered in the field CDR filename prefix. D - timestamp of export, formatted in keeping with Filename template field. S - character string, entered in the field CDR filename postfix. When no new CDRs have appeared since the latest cron job execution and the checkbox Save empty files is selected, the time stamp for the D part of the file name is the system time of the server. File mask – file access rights, specified as 4 octal digits. Category FTP settings (valid only when the "FTP server" export option is selected in the "Save to" combo box) FTP server: address – name of FTP server and directory for saving CDR files (e.g. ftp:// cdr.storage.machine/CDRs/export). FTP server: login – login name for access to the FTP server. FTP server: password – access password for the FTP server. FTP passive mode – select this checkbox to enable interworking with the FTP server in the passive mode. Category SFTP settings (valid only when the "SFTP server" export option is selected in the "Save to" combo box) Authentication method – method of authentication used for accessing the remote SFTP server: By keys – authentication is performed by SSH keys (for details, see Configuring authentication by SSH keys when unloading CDRs to SFTP server 120 ). By password – standard authentication method by login name and password. SFTP server: address – name of SFTP server and directory for saving CDR files (e.g. sftp:// cdr.storage.machine/CDRs/export). SFTP server: login – login name for access to the SFTP server. Page 111 Operating TM SFTP server: password – access password for the SFTP server. The FTP/SFTP-server should be conf igured the f ollowing way: - the f ile should be available f or reading only af ter it is comp letely transf erred to the server. - in case of the connection with the server f ails, the f ile, which is transf erred p artially, should be deleted automatically by the server. Examp le: in order to conf igure the server p rof tp d accordingly, use the p arameters HiddenStores and DeleteAbortedStores. The parameters of the group Export data (Last export date in UTC=0, Cron string, ID of last exported cdr (in case of replication - ID of last exported cdr of server ... for all servers) are filled according to the results of the previous exports of CDRs and serve for debugging. 5.6.1.2 Scheduled export algorithm The f ield ID in the CDR tables is auto-increment, that is why the order of the ID f ields corresp onds to the order in which the CDRs were saved to the DB. 1. If the replication is not configured The start boundary is defined according to the ID of the last CDR from the previous export or, if it is the first export, according to the export start time (the value of the parameter Starting date). Then the CDRs for the selected period are exported. 2. If the replication is configured In case of exp ort of CDRs simultaneously on two servers, where DB rep lication is conf igured, exp orted CDRs will signif icantly dif f er. For correct CDR exp ort in such scenarios disable rep lication of mvts_cdr_exp ort table by adding the directive replicate-ignore-table = <DB name>.mvts_cdr_export to the f ile /etc/mysql/conf.d/rtu-repl.cnf. ID of CDRs should be formed according to ID of each server. Server ID is a number which will be automatically added to the value of the ID field in the CDR table. Auto-increment is configured in MySQL with the help of two parameters: auto-increment-increment (step) and autoincrement-offset (shift) (for more information refer to Replication configuration 241 ). Examples: For server 1: auto-increment-increment = 10 auto-increment-offset = 1 For server 2: auto-increment-increment = 10 auto-increment-offset = 2 For each server the System remembers the last ID of CDR which is divisible by the identifier of this server according to which the start boundary is defined. The last ID is calculated the same way it is calculated when there is no replication. Then the System exports CDRs with IDs, divisible by the found identifiers in the specified range for each server. 5.6.1.3 Correspondence of exported file fields and CDR fields The correspondence of field names in the exported files to the field names in the CDRs is listed in the following table. Unless stated otherwise, a field in the exported file always has a value. Correspondence of the file fields and CDR fields Field name in the Field name in the CDR Value type (max Valid values Page 112 Operating TM file length) cdr_id ID Integer cdr_date CDR date Date/time in_ani Incoming SRC number String (100) Non-empty unless the parameter had no value in the call. in_dnis Incoming DST number String (100) Non-empty unless the parameter had no value in the call. out_ani Outgoing SRC number String (100) Non-empty unless the parameter became blank after all translations. out_dnis Outgoing DST number String (100) Non-empty unless the parameter became blank after all translations. bill_ani Billing SRC number String (100) Non-empty unless the parameter became blank after all translations. bill_dnis Billing DST number String (100) Non-empty unless the parameter became blank after all translations. sig_node_name Signaling node String (100) src_gatekeeper_addr Remote ess address orig. GK String (21) Non-empty if the protocol was H.323 and the call was received through a gatekeeper. remote_src_sig_addr Remote orig. signaling String (21) ess address Non-empty for all protocols but SS7 and internal. remote_dst_sig_add Remote term. signaling String (21) ress address Non-empty if there was an attempt to establish an outgoing call leg. remote_src_media_a Remote orig. media String (100) ddress address One or several IP addresses delimited with a semicolon ";". Non-empty if media streams were opened. remote_dst_media_a Remote term. media String (100) ddress address One or several IP addresses delimited with a semicolon ";". Non-empty if media streams were opened. local_src_sig_addre ss Local orig. signaling String (21) address Non-empty for all protocols but SS7. local_dst_sig_addre Local term. signaling String (21) ss address Non-empty if there was an attempt to establish an outgoing call leg. Page 113 Operating TM local_src_media_add Local orig. ress address media String (100) One or several IP addresses delimited with a semicolon ";". Non-empty if media streams were opened. local_dst_media_ad dress Local term. address media String (100) One or several IP addresses delimited with a semicolon ";". Non-empty if media streams were opened. in_leg_proto Incoming leg protocol String h323 - H.323 sip - SIP sip-t - SIP-T/SIP-I ss7 - SS7 internal - Internal out_leg_proto Outgoing leg protocol String h323 - H.323 sip - SIP sip-t - SIP-T/SIP-I ss7 - SS7 internal - Internal Non-empty if there was an attempt to establish an outgoing call leg. conf_id TS Conference ID String (100) in_leg_call_id TS Incoming call ID String (100) out_leg_call_id TS Outgoing call ID String (100) Non-empty if there was an attempt to establish an outgoing call leg. src_user Orig. registration String (100) username Non-empty if registration was used and registration name was specified dst_user Term. registration String (100) username Non-empty if registration was used and registration name was specified radius_user RADIUS username String (100) Non-empty if RADIUS authorization or authentication was used src_name Origination gateway String (100) dst_name Termination gateway String (100) Non-empty if there was an attempt to establish an outgoing call leg. dp_name Dial peer String (100) Non-empty if there was an attempt to establish an outgoing call leg. Page 114 Operating TM elapsed_time In-call time incoming leg for Integer setup_time Setup time incoming leg for Date/time connect_time Connect time incoming leg for Date/time disconnect_time Disconnect time for Date/time incoming leg disconnect_code Disconnect code Integer Universal disconnect code from Disconnect codes table in_leg_codecs Incoming leg codecs String (100) Non-empty if media streams were opened. out_leg_codecs Outgoing leg codecs String (100) Non-empty if media streams were opened. src_faststart_presen SRC Faststart present t Boolean 0 or 1 dst_faststart_presen DST Faststart present t Boolean Non-empty if the connection was established. Non-empty if the protocol was H.323 and the scripting node acknowledged the call. 0 or 1 Non-empty if the protocol was H.323 and the scripting node acknowledged the call. src_tunneling_prese SRC nt present Tunneling Boolean dst_tunneling_prese DST nt present Tunneling Boolean proxy_mode Non-empty if the connection was established. 0 or 1 Non-empty if the protocol was H.323 and the scripting node acknowledged the call. Proxy mode 0 or 1 Non-empty if the protocol was H.323 and the scripting node acknowledged the call. Boolean 0 or 1 Non-empty if the scripting node acknowledged the call. lar_fault_reason LAR fault reason Integer 0 - Call succeeded 1 - No more routes 2 - Unable channels to update media 3 - LAR denied in the last route 4 - System crashed 5 - Call terminated before routing 6 - Call terminated CONNECT received before 7 - ISUP attachments exchanged on the last route Page 115 Operating TM 8 - Call terminated by TS before first route used 9 - Call terminated as processed call for too long TM Non-empty if the connection was not established. route_retries Routing retries Integer scd SCD for incoming leg, Integer msec Non-empty if the connection was established. pdd PDD for incoming leg, Integer msec Non-empty if the connection was established or upon ALERTING arrival. media_group Media group Contains the name of the mediagroup, through which the call passed. String (100) Non-empty if media circuits were established. src_media_bytes_in Orig. media bytes in Integer Non-empty if media streams were opened. src_media_bytes_ou Orig. media bytes out t Integer Non-empty if media streams were opened. dst_media_bytes_in Integer Non-empty if media streams were opened. dst_media_bytes_ou Term. media bytes out t Integer Non-empty if media streams were opened. src_media_packets Orig. media packets Integer Non-empty if media streams were opened. dst_media_packets Term. media packets Integer Non-empty if media streams were opened. src_media_packets_l Orig. media packets Integer ate late Non-empty if media streams were opened. dst_media_packets_l Term. media packets Integer ate late Non-empty if media streams were opened. src_media_packets_l Orig. media packets Integer ost lost Non-empty if media streams were opened. dst_media_packets_l Term. media packets Integer ost lost Non-empty if media streams were opened. src_min_jitter_size Orig. min. jitter buffer Integer size, msec Non-empty if media streams were opened. src_max_jitter_size Orig. max. jitter buffer Integer size, msec Non-empty if media streams were opened. dst_min_jitter_size Term. min. jitter buffer Integer Non-empty if media streams Term. media bytes in Page 116 Operating TM size, msec were opened. dst_max_jitter_size Term. max. jitter buffer Integer size, msec Non-empty if media streams were opened. last_cdr Last CDR Boolean 1 or blank q850_reason Q.850 Reason Integer Non-empty if the System received a message with such code. in_cpc Incoming leg CPC Integer Code from Calling categories settings party's Non-empty if a CPC was present in the incoming call leg. out_cpc Outgoing leg CPC Integer Code from Calling categories settings party's Non-empty if a CPC was present in the outgoing call leg. in_zone Orig. zone String (100) Zone from Zones table out_zone Term. zone String (100) Zone from Zones table Non-empty if there was an attempt to establish an outgoing call leg. disconnect_initiator Disconnect initiator Integer 0 - Traffic Switch 1 - Call originator 2 - Call terninator diversion Diversion String (100) Non-empty if the parameter was present in the call. The f ield is unavailable f or exp ort starting f rom version 1.7.3-01. in_ani_type_of_num Incoming SRC number Integer ber type -1 - Same as for incoming leg 0 - Unknown 1 - International number 2 - National number 3 - Network specific number 4 - Subscriber number 6 - Abbreviated number Non-empty if the parameter was present in the incoming call leg. in_dnis_type_of_nu Incoming DST number Integer mber type -1 - Same as for incoming leg 0 - Unknown 1 - International number 2 - National number 3 - Network specific number Page 117 Operating TM 4 - Subscriber number 6 - Abbreviated number Non-empty if the parameter was present in the incoming call leg. out_ani_type_of_nu Outgoing SRC number Integer mber type -1 - Same as for incoming leg 0 - Unknown 1 - International number 2 - National number 3 - Network specific number 4 - Subscriber number 6 - Abbreviated number Non-empty if the parameter was present in the outgoing call leg. out_dnis_type_of_n Outgoing DST number Integer umber type -1 - Same as for incoming leg 0 - Unknown 1 - International number 2 - National number 3 - Network specific number 4 - Subscriber number 6 - Abbreviated number Non-empty if the parameter was present in the outgoing call leg. src_in_leg_conf_id Protocol conference ID String (100) src_in_leg_call_id Protocol incoming call String (100) ID src_out_leg_call_id Protocol outgoing call String (100) ID in_orig_dnis Incoming original DST String (100) number Non-empty if the parameter was present in the incoming call leg. out_orig_dnis Outgoing original DST String (100) number Non-empty if the parameter was present in the outgoing call leg. src_disconnect_cod es Aux. SRC disconnect String (100) codes A list of universal disconnect codes from Disconnect codes tables, delimited with ";". Non-empty if there were disconnect codes that did not coincide with the main one. dst_disconnect_cod Aux. SRC disconnect String (100) es codes A list of universal disconnect codes from Disconnect codes tables, delimited with ";". Non-empty if there were Page 118 Operating TM disconnect codes that did not coincide with the main one. pass_from Pass "From" to Term. GW Integer record_type Record type String (100) extradata field ExtraData String (256) term_elapsed_time In-call time for the Integer outgoing leg term_setup_time Setup time for the Date/time outgoing leg term_connect_time Connect time for the Date/time outgoing leg 1 or blank. The f ield is unavailable f or exp ort starting f rom version 1.7.3-01. Non-empty if the CDR was generated for the route, received within external routing. Non-empty if the connection was established. Non-empty if the connection was established. term_disconnect_tim Disconnect time for Date/time e the outgoing leg term_scd SCD for outgoing leg, msec Integer Non-empty if the connection was established. term_pdd PDD for outgoing leg, msec Integer Non-empty if the connection was established or upon ALERTING arrival. external_router External routing server String (100) Name of external routing server. Non-empty for calls routed over RADIUS, ENUM, SIP-server. radius_group RADIUS group Non-empty if the group of RADIUS servers is used. in_ani_screening ScreeningIndicator for Integer the incoming leg Non-empty, if the parameter was present in the incoming leg. 0 - User-provided, not screened 1 - User-provided, verified and passed 2 - User-provided, verified and failed 3 - Network provided in_ani_presentation PresentationIndicator for the incoming leg Non-empty, if the parameter was present in the incoming leg. String (100) Integer 0 - Presentation allowed 1 - Presentation restricted 2 - Number not available due to interworking out_ani_screening ScreeningIndicator for Integer the outgoing leg Non-empty, if the parameter was present in the incoming leg. Page 119 Operating TM 0 - User-provided, not screened 1 - User-provided, verified and passed 2 - User-provided, verified and failed 3 - Network provided out_ani_presentatio n PresentationIndicator for the outgoing leg Integer Non-empty, if the parameter was present in the incoming leg. 0 - Presentation allowed 1 - Presentation restricted 2 - Number not available due to interworking 5.6.1.4 Configuring authentication by SSH keys when unloading CDRs to SFTP server Before unloading CDRs onto external SFTP server with authentication by SSH keys you need to create a pair of SSH2 keys without passphrase and with default names, for example id_dsa and id_dsa.p ub (all commands are executed under root): 1. On the MVTS Pro server, launch the key generation wizard using the ssh-keygen utility: ssh-keygen -t dsa The ssh-keygen utility will ask you to define a path where the keys should be saved: Enter file in which to save the key (/home/<username>/.ssh/id_dsa): 2. Enter /var/www/rtu/uploads/ssh_keys/id_dsa, press Enter and agree to rewrite. The utility will ask you to enter a passphrase: Enter passphrase (empty for no passphrase): 3. Press Enter twice. The utility will inform you about the created keys: Your identification has been saved in /var/www/rtu/uploads/ssh_keys/ id_dsa. Your public key has been saved in /var/www/rtu/uploads/ssh_keys/ id_dsa.pub. The key fingerprint is: 02:ae:12:ca:1d:0b:1d:a2:b3:e5:de:81:3d:b1:a5:01 root@mvtspro 4. Grant permissions to read keys for the www-data user: chown chown chmod chmod www-data:www-data /var/www/rtu/uploads/ssh_keys/id_dsa www-data:www-data /var/www/rtu/uploads/ssh_keys/id_dsa.pub 600 /var/www/rtu/uploads/ssh_keys/id_dsa 600 /var/www/rtu/uploads/ssh_keys/id_dsa.pub 5. On the MVTS Pro server, execute the following command to copy the public key (id_dsa.p ub) on the remote SFTP server: scp /var/www/rtu/uploads/ssh_keys/id_dsa.pub <remote_username>@<remote_server_address>:.ssh/authorized_keys For example: scp /var/www/rtu/uploads/ssh_keys/id_dsa.pub customer@example.com:.ssh/ authorized_keys 6. On the remote SFTP server, change rights to access the directory of .ssh/authorized_keys: Page 120 Operating TM chmod 600 ~/.ssh/authorized_keys The configuration is complete. To check the SSH connection between MVTS Pro and the remote SFTP server, under the local user run the following commands: cp -R /var/www/rtu/uploads/ssh_keys/ /home/<local_username>/.ssh/ chmod 600 /home/<local_username>/.ssh/id_dsa chmod 600 /home/<local_username>/.ssh/id_dsa.pub chown <local_username>:<group_name> /home/<local_username>/.ssh/id_dsa chown <local_username>:<group_name> /home/<local_username>/.ssh/ id_dsa.pub ssh <remote_username>@<remote_server_address> For example: cp -R /var/www/rtu/uploads/ssh_keys/ /home/user/.ssh/ chmod 600 /home/user/.ssh/id_dsa chmod 600 /home/user/.ssh/id_dsa.pub chown user:usergroup /home/user/.ssh/id_dsa chown user:usergroup /home/user/.ssh/id_dsa.pub ssh customer@example.com If the configuration settings were made correctly, the connection will be established without a password. 5.6.1.5 Examples of exported files Below are the examples of CDRs exported in MVTS-1 and CSV format (one of each): MVTS-1 format CDR CDR export settings: Filename prefix = prefix_ Quotation marks = “ Mark empty fields = \N Delimiter = ‘,’ Export format = MVTS-1 ======= Start of file prefix_20080118.txt_095202 ======== CDR_ID="200801000000001028",CDR_DATE="2008-01-18 09:52:02",IN_ANI="3",IN_DNIS="999",OUT_ANI="9004",OUT_DNIS="9595",BILL_ANI="9004",BILL_D NIS="9005",SIG_NODE_NAME="\N",REMOTE_SRC_SIG_ADDRESS="192.168.130.149:5060",REMOTE _DST_SIG_ADDRESS="192.168.130.47:1720",REMOTE_SRC_MEDIA_ADDRESS="192.168.130.149:1638 6",REMOTE_DST_MEDIA_ADDRESS="\N",LOCAL_SRC_SIG_ADDRESS="192.168.131.12:5060",LOCA L_DST_SIG_ADDRESS="192.168.131.12:35765",LOCAL_SRC_MEDIA_ADDRESS="192.168.131.12:12088 ",LOCAL_DST_MEDIA_ADDRESS="\N",IN_LEG_PROTO="sip", OUT_LEG_PROTO="h323",CONF_ID="e588717494785300@192.168.130.149",IN_LEG_CALL_ID="e58871 7494785300@192.168.130.149",OUT_LEG_CALL_ID="b4805c00bc76901080000017a48b7a95",SRC_USE R="", DST_USER="\N",RADIUS_USER="\N",SRC_NAME="tel_linksys",DST_NAME="tel_panasonic",DP_NA ME="9005",ELAPSED_TIME="\N",SETUP_TIME="2008-01-18 09:51:49",CONNECT_TIME="2008-01-18 09:52:02",DISCONNECT_TIME="2008-01-18 09: 52:02",DISCONNECT_CODE="262631",IN_LEG_CODECS="PCMU Page 121 Operating TM (type=[audio],transport=[rtp],vad=[disable],fpp=[0],flags=[0x0]);PCMU (type=[audio],transport=[rtp],vad=[disable],fpp=[20],flags=[0x0]);",OUT_LEG_CODECS="\N",SRC_FASTS TART_PRESENT="0",DST_FASTSTART_PRESENT="\N",SRC_TUNNELING_PRESENT="1",DST_TUN NELING_PRESENT="\N",PROXY_MODE="1",LAR_FAULT_REASON="\N",ROUTE_RETRIES="2",SCD ="\N",PDD="\N",PDD_REASON="\N",SRC_MEDIA_BYTES_IN="10568",SRC_MEDIA_BYTES_OUT="9 0123",DST_MEDIA_BYTES_IN="90123",DST_MEDIA_BYTES_OUT="9160",SRC_MEDIA_PACKETS=" 65",DST_MEDIA_PACKETS="453",SRC_MEDIA_PACKETS_LATE="0",DST_MEDIA_PACKETS_LAT E="0",SRC_MEDIA_PACKETS_LOST="0",DST_MEDIA_PACKETS_LOST="0",SRC_MIN_JITTER_SIZ E="0",SRC_MAX_JITTER_SIZE="0",DST_MIN_JITTER_SIZE="0",DST_MAX_JITTER_SIZE="0",SRC_ CENTREX_ID="3",DST_CENTREX_ID="3",COOKIE="84168533",DVO="0",CALL_TYPE="\N",USER_BI LLING_ID="29",USER_LINE_NAME="office phone" ======= End of file prefix_20080118.txt_095202 ========= CDR exported to a CSV file: CDR export settings: Filename prefix = prefix_ Quotation marks = Mark empty fields = \N Delimiter = ‘,’ Export format = CSV ======= Start of file prefix_20080117.csv_134728 ========= cdr_id,cdr_date,in_ani,in_dnis,out_ani,out_dnis,bill_ani,bill_dnis,sig_node_name,remote_src_sig_address,remote_ dst_sig_address,remote_src_media_address,remot e_dst_media_address,local_src_sig_address,local_dst_sig_address,local_src_media_address,local_dst_media_addr ess,in_leg_proto,out_leg_proto,conf_id,in_leg_cal l_id,out_leg_call_id,src_user,dst_user,radius_user,src_name,dst_name,dp_name,elapsed_time,setup_time,connect _time,disconnect_time,disconnect_code,in_leg_code cs,out_leg_codecs,src_faststart_present,dst_faststart_present,src_tunneling_present,dst_tunneling_present,prox y_mode,lar_fault_reason,route_retries,scd,pdd,p dd_reason,src_media_bytes_in,src_media_bytes_out,dst_media_bytes_in,dst_media_bytes_out,src_media_pack ets,dst_media_packets,src_media_packets_late,dst_media_ packets_late,src_media_packets_lost,dst_media_packets_lost,src_min_jitter_size,src_max_jitter_size,dst_min_ji tter_size,dst_max_jitter_size,src_centrex_id,dst _centrex_id,cookie,dvo,call_type,user_billing_id,user_line_nam 200801000000000527,2008-01-17 13:47:28,5488,5223,5222,5489,5222,5223, \N,192.168.131.134:5061,192.168.131.135:5061,192.168.131.134:5004,192.168.131.135:41000, 192.168.131.12:5060,192.168.131.12:5060,192.168.131.12:10048,192.168.131.12:10060,sip,sip,100c7ad88683a8c0-13c5-3e1243f1-78704c0b-3e1243f1@aloenetworks.ru,1 00c7ad8-8683a8c0-13c5-3e1243f1-78704c0b3e1243f1@aloenetworks.ru,de5e90005b5c8f1080000017a48b7a95@192.168.131.12,,\N,\N,Moolio's AudioCodec,Moolio's D-Link,5 223,50631,2008-01-17 13:47:05,2008-01-17 13:47:08,2008-01-17 13:47:59,65546,PCMA (type=[audio], transport=[rtp], vad=[disable], fpp=[0], flags=[0x0]);PCMA (t ype=[audio], transport=[rtp], vad=[disable], fpp=[20], flags=[0x0]);,PCMA (type=[audio], transport=[rtp], vad=[disable], fpp=[0], flags=[0x0]);PCMA (type=[audio], transport=[rtp], vad=[disable], fpp=[20], flags=[0x0]);,0,0,1,1,1,\N,0,1043,449, \N,185204,115200,35324,49800,997,590,0,0,163,10,0,74,0,5,3,3,19199054,0 ,\N,8,Moolio 5222 UL ======= End of file prefix_20080117.csv_134728 ========= Page 122 Operating TM 5.6.2 Export interval The object Export interval in the category Export CDRs allows you to perform immediate export of call detail records matching the specified interval. In the * Starting date and * Ending date parameters specify the time frame, to which the exported CDRs pertain. In the * Save parameter, select one of the following values: to file system locally, to FTP server or with browser. All other parameters correspond to the parameters of the Scheduled export object (see section CDRs scheduled export 106 ). To invoke the export procedure click OK. 5.6.3 Export debugging To enable the debugging of scheduled export and export of CDRs for the specified interval, specify $trace = true in the configuration file /var/www/rtu/extensions/cdr_export/ CDRExport_Config.php. When the task is performed next time, the directory /var/www/rtu/ extensions/cdr_export/traces will be created, to which the task logs will be written. If the folder /var/www/rtu/extensions/cdr_export/traces was created manually, make sure that the user www-data possesses reading and writing rights. 5.6.4 CDR post-processing The post-processing of exported CDRs adds flexibility of the CDR export. You can adjust any parameters that are exported according to your own wishes. To use this feature do the following: Activate the Enable post-processing checkbox in the Scheduled export settings. Put executable files into the /var/www/rtu/extensions/cdr_export/process.d directory. These files will do the post processing. With the checkbox enabled the System will save the exported CDRs into a temporary file and apply the executable files from the /var/www/rtu/extensions/cdr_export/process.d directory to the exported CDRs consecutively, in the alphabetical order. Non-executable files in the directory are ignored. These executable files act as filters; that means they take data from the STDIN stream (original exported CDRs or the result of processing by the previous filter), process them according to their rules and output them into the STDOUT stream. When all filters are applied, the final CDR file is moved to the Export directory, saved on the FTP server or displayed in the browser. The f inal outp ut should not be null. This rule is valid f or any scrip ting language. It is possible to use the special OS environment variables in the executable files. These variables correspond to the parameters of the Scheduled export in the web interface. The variables are listed in the /var/www/rtu/extensions/cdr_export/process.d/readme.txt file. An example of a filter in Perl is shown in the /var/www/rtu/extensions/cdr_export/ process.d/disconnect_code.pl file. 5.6.5 Inaccurate CDRs 5.6.5.1 Table of inaccurate CDRs To transfer CDRs from the table of inaccurate CDRs to the table All CDRs do the following: 1.Click on Transfer all CDRs to the main table (see the picture below). Page 123 Operating TM It is not p ossible to transf er several selected CDRs to the main table. Transf er all inaccurate CDRs at once. With the help of the setting Transf er all inaccurate CDRs (even if there are some dup licates), you can reduce the consump tion of System resources (f or more inf ormation ref er to 6.8.1 System global settings 138 ) . 2. In the form Transfer CDRs settings, fill out the necessary fields: CDR transfer settings CDRs are transferred in groups. In the field CDRs in a group specify the amount of CDRs in a group. In the field Interval between transfers of groups of CDRs, sec enter the period (in seconds) between transfers of groups of CDRs. 3. Then click "Begin transfer". After the transfer, the System will display the results with the corresponding Status, the fields Inaccurate CDRs transferred, Partially duplicate CDRs detected, Duplicate CDRs deleted will contain the corresponding data. Please note that in terms of this document absolutely identical CDRs are called Duplicate CDRs, having 6 corresponding fields: TS Conference ID (conf_id) - conference ID, generated by TS. TS Outgoing call ID (out_leg_call_id) - outgoing call ID, generated by TS. Record type (record_type) - CDR type (interim, Final,..). Disconnect code (disconnect_code) - disconnect code. Orig. in-call time (elapsed_time) - in-call time (incoming leg). Term. in-call time (term_elapsed_time) - in-call time (outgoing leg). Partially duplicate CDRs are the CDRs which have 3 corresponding fields: TS Conference ID (conf_id) - conference ID, generated by TS. TS Outgoing call ID (out_leg_call_id) - outgoing call ID, generated by TS. Record type (record_type) - CDR type (interim, Final,..). Page 124 Operating TM Inaccurate CDRs can be transf erred to the main table, only if the time sp ecif ied in the p arameter Max. call duration, seс has p assed since their generation. If any duplicated CDRs were found during the transfer, go to the page Duplicate CDRs. 5.6.5.2 Scheduled transfer Inaccurate CDRs can be transferred to the main table automatically with the help of the scheduled cron-task. By default the scheduled transfer is disabled. With the help of the setting Transf er all inaccurate CDRs (even if there are some dup licates), you can reduce the consump tion of System resources (f or more inf ormation ref er to 6.8.1 System global settings 138 ) . The page Scheduled transfer of inaccurate CDRs contains 2 groups of parameters: Schedule Transfer settings The group of settings Schedule contains 2 parameters (checkboxes): Every minute (by default the checkbox is clear, the value is 00 minutes), Every hour (by default the checkbox is selected). If you clear the checkbox Every minute or Every hour, the dropdown list Schedule setting method will appear. Select one of the values: specifying ordinal number (you can specify minutes and hours when the task will be carried out), specifying repeat pattern (you can specify a repeat pattern for the task, for example, if you specify 5, the task will be performed every 5 minutes). See the description of other settings in the section Table of inaccurate CDRs 123 . After you finish the settings, click Carry out scheduled transfer on this server. After that the status Scheduled transfer is configured on this server will be displayed and two buttons will appear: Disable scheduled transfer and Apply scheduled transfer settings. If you click Disable scheduled transfer, the status will change to Scheduled transfer is not configured. If you click Apply scheduled transfer settings, the status will not change. Page 125 Operating TM The cron-task will be carried out according to the schedule. If partially duplicate CDRs are found while transferring inaccurate CDRs to the main table, the System will send the correspondent notification with the amount of such records to the user. Errors which occur while running the scenario are recorded to the log file /var/log/mvts3g/ mvtspro-webdb/cdr_autotransfer.log. If the inaccurate or remaining duplicate CDRs are transferred to the main table while running the script, the record saying that it is impossible to continue running the script will be written to the specified log file. 5.6.5.3 Duplicate CDRs Duplicate CDRs detected during manual or automatic transfer are stored in the table (on the page Duplicate CDRs). If partially duplicate CDRs are found during the automatic transfer of inaccurate CDRs, the user will receive the correspondent notification. Page 126 Operating TM Two types of records are displayed in the table Duplicate CDRs: - records, copied from the main table, - records, transferred from the table of inaccurate CDRs. Type of the records is shown in the column Source CDR table (Main or Inaccurate). The records from the main table can be neither deleted nor transferred. They are displayed only for information while there are any inaccurate CDRs in the group of partially duplicated CDRs (the group containing only main CDRs is deleted). The records from the table of inaccurate CDRs can be either deleted or transferred to the main table. After the record is transferred to the main table, in the table Duplicate CDRs it is displayed with the value Main in the column Source CDR table, with the ID given to it in the main table. If the action Delete is selected, the records will be exported (if the checkbox Export deleted duplicate CDRs is selected) and then deleted. To modify the settings of CDRs export, press Settings. If you select the checkbox Export deleted duplicate CDRs, the duplicates of deleted CDRs will be exported to the directory, specified in the field Export directory (which appears with the checkbox Export deleted duplicate CDRs selected). When sp ecif ying a directory f or CDR f iles the administrator must remember that the www-data user in the name of which f ile saving is done must p ossess reading, writing and access rights f or that directory (the directory should have the rights set to 777) . It is impossible to perform several CDRs transfer procedures simultaneously. If the process of CDRs transfer has been started, the status CDR transfer is forbidden. Another process is running will be displayed on the page. Page 127 Operating TM 5.7 Statistics The category of objects Statistics allows generation of area traffic reports. 5.7.1 Reports The object Reports is a GUI page that allows to create and view DP traffic transit reports. To create a report, in the dialog Create report (Statistics > Reports) enter a name for the future report, type a regular expression in the field Pattern for DP name (LIKE) that defines a name(s) for DPs, and in the Grouping list select the criteria for grouping CDRs. Creating a report Grouping – move attributes, by which CDRs will be grouped during report generation, from the left to the right box. The precedence of grouping is determined by the position of the grouping attribute in the list. Change the order of grouping by moving grouping attributes in the list up and down using and buttons. Initially, CDRs are grouped by the topmost attribute on the list, then the records within the resulting groups are grouped by the second attribute in the list, and so on. * Time unit – this parameter selects a measure of time used in record grouping. The process of report creation is described below in detail. The parameter is valid if the Grouping list contains Date. * From date/To date – set the date range used to select CRDs for the report. Pattern for SRC GW name (LIKE) – enter the originating gateway name pattern to include data pertaining to the specified originating gateway only. Pattern for DP name (LIKE) – enter the DP name pattern to include data pertaining to the specified DP only. Page 128 Operating TM Pattern for DST GW name (LIKE) – enter the termination gateway name pattern to include data pertaining to the specified termination gateway only. LIKE op erator indicates that mySQL syntax is used f or name p atterns. Disconnect code – enter a disconnect code to include the calls with the specified disconnect code only. Area – select the prefix from the dropdown list to include those calls into the report that have the specified prefix in the telephone number. The newly generated report will be added to the table Report contents and to the table All reports to complement earlier generated reports. To view the contents of any report from the table All reports, invoke the pop-up menu and select Filter related tables -> Report contents. Tables "Report contents" and "All reports" Report generation unfolds as follows: 1. CDRs are selected by the date that fits in the date range defined in the Create report dialog. The CDR date value dep ends on the Value for "Date" field in CDR: 1 - Setup time, 2 Disconnect time p arameter. 2. When a regexp pattern for the DP name, name of the originating or terminating gateway are available, the CDRs are additionally filtered by the name matching the regexp entered in the field Pattern for DP name (LIKE), Pattern for SRC GW name (LIKE) or Pattern for DST GW name (LIKE). 3. The selected CDRs are then grouped by attributes specified in the Grouping list. The order of grouping is determined by the precedence of the grouping attributes in the list. If the Grouping list includes Data, then the CDRs are additionally sub-grouped by date using the time option selected in the Time unit combo box. By way of example, if the Grouping list includes two attributes – Region and Date, where Region is the first attribute and Date is the second, the CDRs will be first grouped by Region, and then by Date. Suppose, the Time unit parameter is set to Hour, then report records in region groups within the defined date range are further grouped in hourly sub-groups. When a created subgroup contains no calls - it is discarded; otherwise it occupies a line in the generated report. 4. The statistical data calculated for each group of CDRs are as follows: Orig. total minutes – total duration of all calls (incoming leg) in minutes (taking into account all records in the group), rounded up or down to the nearest whole minute. Term. total minutes – total duration of all calls (outgoing leg) in minutes (taking into account all records in the group), rounded up or down to the nearest whole minute. Page 129 Operating TM Total calls – total number of call arrivals (that is the number of connections between the originator and the System). In other words – the number of CDRs with the Last CDR parameter equal to “Yes”. Orig. traffic, Erlang - load rate on incoming leg in erlangs. Calculated as Orig. total minutes divided by Time unit. Term. traffic, Erlang - load rate on outgoing leg in erlangs. Calculated as Term. total minutes divided by Time unit. Traf f ic in erlangs is calculated as f ollows: total duration of all calls f or a sp ecif ied p eriod is divided by 3600 seconds (1 hour) . See the link to the CISCO document, describing the method of calculation of traf f ic in erlangs f or VoIP-calls, Traf f ic analysis f or voice over IP. In MVTS Pro, however, traf f ic in erlangs is calculated by dividing the total duration of all calls not by 3600 seconds, but by the time interval, f or which the string of the detailed rep ort is generated, i.e. by the value of the p arameter Time unit. The same f ormula is ap p lied f or calculation of the load rate f or a certain gateway, if the group ing of records is done according to the gateway (attributes Orig. gateway or Term. gateway ) . For calculation of Orig. traf f ic, Erlang and Term. traf f ic, Erlang, values of Orig. total minutes/ Ter. total minutes and Time unit should be taken in seconds. Successful calls – number of successful calls. Successf ul calls are calls comp leted with call disconnect reason codes marked as Successf ul (see section Disconnect codes 141 ) or with non-zero duration. Connected calls – number of calls with a voice session (that is calls of non-zero duration). Total attempts – total number of attempts to establish a call (number of the System connection attempts to the terminator). Successful attempts – successful number of attempts to establish a call. Connected attempts – number of attempts with a voice session (that is attempts of non-zero duration). The data on the number of calls (total, successf ul and with voice sessions) is necessary to assess the quality of services, p rovided by the terminating op erator. The data on the number of attemp ts (total, successf ul and with voice sessions) is necessary to assess the quality of termination services, p rovided to MVTS Pro op erator by other op erators. ASR (calls), % – answer seizure ratio calculated by the MVTS Pro intrinsic method (see ASR (MVTS Pro) 11 ). Std. ASR (calls), % – standard answer seizure ratio calculated conventionally (see ASR (std) 11 ). ASR (attempts), % - answer seizure ratio for calls forwarded for termination by other operators; the ratio is calculated by MVTS Pro intrinsic method (see ASR(MVTS) 11 ). Std. ASR (attempts), % - answer seizure ratio for calls forwarded for termination by other operators; calculated conventionally (i.e. ASR = total number of non-zero duration calls/total calls). Orig. ACD, sec – average call duration for non-zero length calls (incoming leg). Term. ACD, sec – average call duration for non-zero length calls (outgoing leg). Orig. Avg. PDD, sec – average post dial delay, calculated for calls with PDD > 0 (incoming leg). Term. Avg. PDD, sec – average post dial delay, calculated for calls with PDD > 0 (outgoing leg). Orig. Avg. SCD, sec – SCD average, calculated for calls with SCD > 0 (incoming leg). Term. Avg. SCD, sec – SCD average, calculated for calls with SCD > 0 (outgoing leg). First CDR date – SETUP time of the earliest call in the group. Last CDR date – SETUP time of the latest call in the group. Page 130 Operating TM First CDR ID – the CDR unique ID of the first call in the specified period. Last CDR ID – the CDR unique ID of the last call in the specified period. Incoming media bytes - the aggregate byte count, received from the originator and the terminator. Outgoing media bytes - the aggregate byte count dispatched to the originator and the terminator. Incoming media bytes from terminator - byte count received from the terminator. Incoming media bytes from originator - byte count received from the originator. Incoming media packets from terminator - packet count received from the terminator. Incoming media packets from originator - packet count received from the originator. Received media packets - the number of received media packets. Lost media packets - the number of lost media packets. Min jitter buffer, msec - the minimum jitter buffer size. Max jitter buffer, msec - the maximum jitter buffer size. Avg. jitter buffer, msec - the average jitter buffer size. To view a report, invoke the pop-up menu and select View. The f ields Period start time and Period end time are rounded to the start and end of the selected time unit resp ectively. For examp le, if Time unit = Hour and From date = 14:07, the f ield Period start time will be 14:00 though the System will select CDRs with the date equal to or more than 14:07 f or the rep ort generation. Page 131 Operating TM Viewing report contents You cannot remove individual CDRs from a report; you can only remove the entire report form the table All reports. 5.7.2 Charts The object Charts allows an illustrative representation of the System statistics in real-time. To enable statistics collection globally, set the Enable statistics (Global settings -> System global settings) parameter to 1. To include data about individual gateways and dial peers into the statistics, select the checkbox Enable statistics in configuration forms of respective GWs or DPs. If statistics collection is disabled globally (Global settings -> System global settings -> Enable statistics = 0) the Enable statistics setting of individual gateways and dial peers is ignored. Page 132 Operating TM Charts To add a new chart click . A new dialog will appear where you can configure the parameters of the chart being created. Creating a new chart From the drop down list Object type select an object, to which the chart pertains. The list options include: Originator – plot a chart for origination gateway. Terminator – plot a chart for termination gateway. Gateway – plot a chart for the gateway that is both originator and terminator. Dialpeer – plot a chart for the DP as a whole (including all gateways pertaining to it). In the Object name field type the first characters of the object to be monitored and the select the object from the drop-down list. In Systems with multiple scripting nodes, select the checkboxes of those scripting nodes that should be taken into account during graph plotting. To create a new chart click OK. The screen will show a new chart area. To add a new curve for a specific parameter to the chart, on the right panel select the checkbox next to the parameter name. You can monitor the following parameters, calculated as exponential moving average. To plot a statistics chart: ASR – Answer seizure ratio (MVTS-specific). ASR (std.) – Conventional ASR. ACD – Average call duration. Page 133 Operating TM PDD – Post-Dial Delay. SCD – SETUP-CONNECT Delay. QoS – Quality of Service. CPS – Call arrival rate Calls – total number of calls being handled To change the curve options for each parameter, click on the parameter name on the right panel. Configuring a curve To select the curve color, click on the field next to the Line color label. Select the desired curve thickness in pixels from the Line weight combo box. Select the desired curve form from the Line type combo box – Spline and Polygon. To apply new parameters, click OK. Set a desired chart update rate selecting a value from the drop-down list Refresh period. Define the chart horizontal scale using the Scale slider. To stop plotting of all curves press . To edit the chart parameters press . When several scripting nodes are selected, the plot value is calculated as a weighted average with regard to the CPS value for every selected node. Suppose, you want to display an ASR chart for the dial peer DP1 and your System has two scripting nodes – ScrN1 and ScrN2. The ASR statistics for ScrN1 is 80 and 40 for ScrN2. Simultaneously, the CPS data for ScrN1 equals 15 calls per second and is 5 calls/sec. for ScrN2. The weighted average ASRavg is then calculated as: ASRavg = (ASRScrN1 * CPS ScrN1 + ASR ScrN2 * CPS ScrN2)/(CPS ScrN1 + CPS ScrN2), that is ASRavg = (80*15 + 40*5)/(15 + 5) = 70. If CPS or Calls are the main chart parameter, the plotted value is just the sum of CPS or Calls values respectively from all selected scripting nodes. You can add new charts by pressing chart list window. To remove the chart, click . The new chart will appear at the top of the in its right-upper corner. Page 134 Operating TM 5.8 Global settings The subcategory Global settings comprises objects pertaining to system global settings, web settings, call disconnect codes and interoperation with RADIUS, ENUM and DNS servers. Page 135 Operating TM 5.8.1 System global settings The view System global settings displays a list of the system global parameters. Table of global configuration parameters The global configuration parameters currently accessible to the MVTS Pro administrator include: Max. call duration, sec – maximum call duration for all calls. Among the parameters limiting maximum call duration, defined on the originator, terminator, RADIUS server and in the global settings, the parameter with the lowest value is selected (Zero means no limitation). Number of routes sent to TS at a time – number routes selected by the scripting node that are sent to the TS at a time. This parameter allows you not send all routes simultaneously, thus enhancing the performance. Interims period, sec – the interval between sending Interim packets to the RADIUS server/creating Interim CDRs in the DB, in seconds. Data update period for the DP balancing method – the number of calls serving as a period for updating data of the DP Balancing method parameter. When the specified number of calls gets routed through a DP, the data gets updated and the call counter zeroes. Thus if you specify a large number in the parameter, the data update frequency reduces and System performance increases. The exact System actions on data update depend on the Balancing method: Round-robin balancing – new gateway will be selected for call routing after N calls are routed to the DP, where N is specified in Data update period for the DP balancing method parameter. Balancing by absolute load – the number of calls on gateways gets updated after N calls are routed to the DP, where N is specified in Data update period for the DP balancing method parameter. Balancing by load-to-capacity ratio – the “load/capacity” ratio of every gateway in the DP gets updated after N calls are routed to the DP, where N is specified in Data update period for the DP balancing method parameter. Page 136 Operating TM EMA coefficient for calculating average incom. call handling time - this parameter is used to calculate the average incoming call handling time. As the TS rejects all calls if they were handled by the scripting node for more than 5 seconds, this time is used to determine if the scripting node can finish call handling in time and thus if it should try to process it. Specifically, if the time, when the scripting node received a call for handling, + avg. call handling time is more than SETUP time + 5 secs, the scripting node will reject the call without processing. The average call processing time is calculated using the EMA method. The formula is: where - the average call handling time. - a moment of time. - a timestamp. - a the amount of time the System used to process a call. - the EMA coefficient, as defined by the EMA coefficient for calculating average incom. call handling time parameter. The greater the coefficient, the more accurate will be the averaging. Max. time of call handling by the scripting node, msec - the amount of time the scripting node allocates for handling one call. When the time expires the call will be terminated. As the TS waits for the scripting node to process the call for 5 seconds and then terminates it anyway, it is pointless to set the parameter to more than 5 seconds. Presently the time is averaged to seconds. Default RTP period, sec - the default value of the parameters Orig. RTP timeout, sec and Term. RTP timeout, sec. Write alerting time upon receipt of SIP 183 - with this parameter enabled the alerting time written into CDRs will be the time of receipt of the SIP 183 message. Note that enabling of the parameter affects the results of PDD calculation. Valid values: 1—enables the feature, 0 (default) – disables the feature. Use common sort for dial peers - if the checkbox is selected, the found dial peers are joined into one group and sorted according to the results of the routing policy (if the routing policy is the same for all dial peers) or according to the priority (if the DP routing policies are different or missing, or if the statistics is disabled in the DP settings). With the checkbox selected, all found dial peers are sorted regardless of their groups. The System behaviour with the checkbox clear is described in Appendix M. Dial peer generation and selection 304 . Use Contact from registration for call to registered SIP-gateway - defines whether the field Contact from a REGISTER request shall be used when calling to the registered equipment of the Gateway type under the signaling protocol SIP. If the value of the parameter is 1 (by default), then under the protocol SIP/SIP-T the value of the field Contact from a REGISTER request shall always be passed to the outgoing call leg. If the value of the parameter is 0, then when registering the equipment under the SIP/SIP-T protocol the System performs as follows: 1. If the type of the equipment is not Gateway, then the contact which arrived in a REGISTER request will be passed to the outgoing call leg. 2. If the type of the equipment is Gateway and the REGISTER request arrived not from behind a NAT router, then the value of the Contact field from a REGISTER request will not be passed to the outgoing call leg. 3. If the type of the equipment is Gateway and the REGISTER request arrived from behind a NAT router, a new URI-contact of the following format will be passed to the outgoing call leg: dnis@sigAddress;adrnatb, where Page 137 Operating TM dnis - DST-number sigAddress - signaling address, adrnatb - the parameter adrnatb from the URL, which arrived in RegistrationStart.contacts. Changing the value of the parameter Use Contact from registration for call to registered SIP-gateway will affect only new registration of equipment. DNS cache size, amount of records - sets the maximum amount of records, received from the DNS, for caching in the Class 4 modules (each module has its own cache). 0 means that no caching is done. A cache record is valid, until the TTL period from the DNS-server response expires. When changing the value of the parameter, remember that RAM size is limited. When the cache is full, new records replace the least recently used records. It is not possible to define how much RAM is occupied by one record, it depends on the size of data received from DNS. Ignore URI, if the pattern for its definition is not specified - defines whether URI shall be used as an incoming SRC or DST number, if there is no pattern for it in the settings of the originating equipment (see the parameter URI match pattern for SRC number 42 or URI match pattern for DST number 42 correspondingly). Possible values: 0 - use URI, but only if there is no digits alias, 1 - not to use URI. The value 1 is used by default. Fill the SCD parameter in CDR even if connection was not established - defines whether the fields Orig. SCD, msec 104 and Term. SCD, msec 104 should be filled with not established connection. Enable FICORA support - specify 1, if you wish to enable support of SS7 national standard of Finland 210 . By default the value is 0. Enable statistics – toggle collection of statistical data, which is used to plot charts. Number of calls for EMA calculation – defines the number of calls used for calculation of exponential moving average of the following parameters: ASR (MVTS), ASR (std), ACD, PDD, SCD and QoS. Amount of seconds for calculation of CPS according to EMA formula - defines the number of seconds used for calculation of exponential moving average of the parameter CPS; Value for "Date" field in CDR: 1 - Setup time, 2 - Disconnect time – determines the way of filling in the Date field in CDRs. 1 means the call setup time will be recorded, 2 means the call disconnect time will be recorded. "In-call time" representation method in CDR-tables: 1 - sec, 0 – msec – determines the units in which the CDR In-call time parameter is represented. 0 – in milliseconds, 1 – in seconds. CDR interims enabled – 0 – do not create interim CDRs, 1 – create interim CDRs. Backup CDR notification timeout, sec - specify the period for dispatching notifications on creation of temporary CDR files (see the Alarm ID LO4CDR002 in the section of Appendix P. List of DB alarms 318 ). Threshold for disabling new call/registrations logs - the number of debug calls/registrations in the queue waiting to be inserted into the DB, when the System should disable logging. Threshold for enabling new call/registrations logs - the number of debug calls/registrations in the queue waiting to be inserted into the DB, when the System should enable logging. Number of call/registration log records to be inserted into DB - the number of debug calls/ registrations to be saved into the DB as part of one INSERT operation. CDRs storage period, days - defines the period for storing tables with CDRs, in days. The CDR tables for which the storage period is expired will be automatically removed from the DB. CDRs availability period, days - defines the period during which CDRs can be viewed through the web-interface. This parameter also defines the amount of tables with CDRs which should be converted when updating MVTS Pro, if the structure of the CDRs in the new version differs from their structure in the current version. Transfer all inaccurate CDRs (even if there are some duplicates) - defines whether or not the System shall search for duplicates when transferring inaccurate CDRs to the main table. By default the value is 0. If you specify 1, the consumption of System resources will be reduced. This setting can be used only if your billing system traces duplicate CDRs itself. Page 138 Operating TM Debug data lifetime, days defines the maximum retention time for debug call and debug registration data. As the size of debug data files may grow prohibitively large, set this parameter so as to prevent hard disk overflow. Enable logging for unknown calls – determines if the System should log calls from unknown gateways (i.e. gateways with no record in the DB, including records of default gateways). Enable logging for unknown registrations – determines if the System should log registrations from unknown gateways (i.e. gateways with no record in the DB, including records of default gateways). Max. active debug rules - defines the maximum amount of active debugging rules in the table Call debugging rules 87 . If the value of the parameter is less than the amount of current active rules, the corresponding error message will be displayed. The default value is 2. Click the button Switch to edit mode to configure the parameters of the Traffic Manager. 5.8.2 Web settings The table Web settings includes parameters essential for GUI management, which are as follows: Table of GUI parameters Default GUI Language - sets the GUI default language: 1 for English, 2 – for Russian. Possible number of rows on page – use this parameter to define the size of a table page expressing it in a number of rows per page. A list of decimal numbers delimited with commas. For example, 10, 20, 30, 50. Default number of rows on page – use this parameter to define the default table page size, i.e. the number of rows a table will display when first accessed for viewing. Maximum number of rows displayed in GUI tables – use this parameter define the maximum number of table records displayed in GUI. Should the actual number of records in the DB exceed the specified table size limit apply a filter to view the table data. The parameter serves to expedite the display of tables with large amounts of data (for example, tables of CDRs). If the parameter is not defined, the error “General error: 126 Incorrect key file for table” may occur, when trying to display a table with a large number of entries. CSV date format – this parameter allows the user to define a date format applied to exported data. CSV fields delimiter – you can use this parameter to select a symbol to be used to delimit data fields in data export files, for example “,” or “;”. CSV fields quote – serves to define a symbol to enclose data fields in data export files, for example, quotes. CSV null value – serves to define a symbol or symbols that will be used to fill empty data fields in data export files. Enable/disable logging of user activity – two possible values for this parameter are 0 and 1. 1 enables user GUI activity logging, 0 disables user activity logging. Page 139 Operating TM Enable/disable logging of view actions – allows two values 0 and 1. 0 disallows logging of user viewing activity. 1 enables logging of all user actions, including object viewing . If Enable/disable logging of user activity = 0, the view activity logging parameter is ignored. Maximum storage time for user activity log (days) - sets a retention time for web activity log records (days). Records, the age of which exceeds the value defined by this parameter, are subject to deletion form the log. Note that to avoid excessive server load records will be deleted with some delay. Enable/disable authentication history – allows two possible values - 0 and 1. 0 disables user authentication logging, 1 enables authentication logging. Maximum storage time for authentication history (days) - sets a retention time for authentication history records (days). Records the age of which exceeds the value defined by this parameter are subject to deletion form the log. Note that to avoid excessive server load records will be deleted with some delay. Initial values from filter – set the parameter to 1, if you want to initialize parameters of a freshly added record with values of the filter currently applied to the table. Enable/disable top banner – toggles the display of top MVTS Pro banner. 0 – do not show banner. 1 – show banner. Exported file encoding – set the encoding of the file exported through a pop-up menu. The list of available encodings: UTF8 UTF16 UTF32 CP1251/WINDOWS1251 KOI8R Add BOM to exported files – set the parameter to 1 if it is necessary to place Byte Order Mark (BOM) at the beginning of the exported file. The BOM defines a correct byte order for Unicode encodings. Password validity period, days - specify the validity period of the user's password (1-90). Regardless of the value of this parameter the user's password will never expire, if the user's account settings contain the IP-address (see Web authentication 33 ). Password queue length - the number of previously changed passwords. The System stores expired passwords in a queue. The passwords in the queue should not coincide. Check password strength - the default value is 1 (the function is enabled: the password must contain at least 2 Latin letters (lower-case and upper-case) and consist of at least 8 characters). To disable this function, enter 0. To configure a parameter point the mouse to the desired record in the table. Left-click to invoke the pop-up menu and select Edit. Setting the parameter Maximum number of rows displayed in GUI tables Type the required parameter value in the edit field Value and click the OK button. To discard the made Page 140 Operating TM changes click Cancel. Time zone is defined separately in a combobox: Time zone – use this parameter to specify the default time zone for the GUI objects (objects CDRs, Reports, Debug calls and Debug registrations). 5.8.3 Disconnect codes The table Disconnect codes presents a listing of call disconnect codes. To quicken search of the necessary information you can use search filters. Refer to section Use of filters 19 for information about the use of search filters. Table of call disconnect codes The table presents the following information: The table presents the following information: Universal code – the disconnect code number used in communication between the TS and the TM. Namespace – type of the disconnect code: H.323. SIP. TS (Traffic switch). TM (Traffic Manager). Code – call disconnect code. Reason – disconnect reason that corresponds to the code. Q.850/SIP code mapping – this columns present the disconnect codes, which will be sent to the calling and called parties, instead of local TS and TM disconnect codes. The equipment supportive of Q.850 will receive the code from the column Q.850 code mapping, the SIP endpoints will receive the code from the column SIP code mapping. Successful – when selected this checkbox indicates that the calls completed with this disconnect reason code should be considered successful during ASR evaluation. Default Q.850/SIP code mapping – original translations of universal codes into Q.850/SIP codes. These columns is for information only. Generate CDRs for failed attempts - generate a CDR for each failed route that was rejected with the present disconnect code. 5.8.4 ISUP national standards With the help of the table ISUP national standards, on the stage of processing of incoming calls from the SIP-T/I gateway you can define under which RTU-supported standard the gateway operates (it is defined according to the presence or absence of the Content-Type: application/isup heading in the INVITE message). The table contains the rules of identification of the INVITE message according to Page 141 Operating TM its attributes. Each record in the table contains the information on the basis of which the standard is defined: ISUP version – defines under which standard the incoming message shall be processed if it matches the rules from the record; Network address – used for identification of the packet according IP. The record 0.0.0.0/0 shall be always present and least prioritized – that corresponds to processing of the packet by default. This field should not be empty. Pattern of field "version" и Pattern of field "base" – used for additional identification of packets (in case IP-address is not enough) according to the contents of the specified fields, contained in the heading Content-Type: application/isup of the INVITE message. Optional fields. Pattern of field "User agent" – used for additional identification of packets according to the contents of this heading. Optional field. Priority – defines the order in which the rules shall be applied to the received packet. This field should not be empty. The higher the value of the record, the higher the priority. When finished, press OK. The added rule shall display in the table. 5.8.5 ENUM-servers The table «ENUM-servers» displays information about ENUM servers configured in the system. The object ENUM servers is intended for configuring connection with ENUM servers that allow conversion of conventional E.164 telephone numbers into URIs. Further, URIs are converted into IPPage 142 Operating TM addresses with the help of the DNS. Thus, the ENUM-servers can be used as an external means of call routing. The call routing procedure will be the following: 1. A list of NAPTR records is requested for each domain, specified in the settings of the ENUMserver. 2. The received record is selected as a possible direction of the call under the following conditions: - the record contains an URI and can be selected (for that there must be a checkbox «u» in the record); - the record defines the correspondence between the E.164 number and the URI for SIP (see service keys «E2U» and «SIP»); - the DST number matches the number pattern, specified in the record. 3. For the domain name, defined in the URI, a list of IP-addresses is requested from the DNS server. If an IP-address is specified in the URI, a request is not sent to the DNS server and the specified IPaddress is used. 4. A route is made for each IP-address. The priorities of the routes are defined in the order in which domains follow each other in the settings of the ENUM-server, and then according to the priority specified in the NAPTR record. 5. When a call is routed, the port is taken from the equipment settings, where this ENUM-server is specified. For more information please refer to the section Equipment 39 . Refer to RFC 3761 for more detailed information about ENUM. Note that DDDS (Dynamic Delegation Discovery System) is not supported at the moment. External routing by means of ENUM servers is p ossible under SIP signaling only. The external routing algorithm is described in the chapter Termination 69 . To add a ENUM server, invoke the pop-up menu and select Add. ENUM server properties form In the dialog that opens enter the following data (the parameters marked with an asterisk character are required parameters): * Name – name that identifies the ENUM server. Description – you can enter any descriptive information or comments pertaining to the record being created in this field. Enable – select this checkbox to validate the record. * Address – specify the IP address in this edit box. Domains – define the domain where the ENUM server belongs. When through with filling out the ENUM servers form, click OK to add the newly configured record. You can specify the configured ENUM server as an external routing means when configuring gateways. If you wish to modify the record, select the Edit item on the pop-up menu. Page 143 Operating TM 5.8.6 DNS servers The table “DNS servers” allows you to overview the domain name servers used for resolution of URIs received from ENUM servers. To add a DNS server, invoke the pop-up menu and select Add. Entering DNS server data Fill out the DNS servers form and click OK to add the newly configured record. The required fields on the form are marked by an asterisk ’*’. The required fields on the DNS servers form are *Name (the server name assigned by the administrator) and *Address (the server’s IP) only. The parameter Precedence shows the DNS server preference. The greater the parameter value the greater the server’s preference. Select the Enable checkbox to validate the record. If you wish to modify a record select the Edit item on the pop-up menu. 5.8.7 Areas The table Areas presents information about geographical names for traffic transfer locations. Adding a new area record To add a new record to the table, invoke the pop-up menu and click the Add item. Enter the name of the area in the * Name edit field and click the OK button. A unique ID for the record will be generated automatically. 5.8.8 Area specifics The table Area specifics displays information about area number prefixes and minimum or/and maximum lengths of numbers in areas. Invoke the pop-up menu and select Add, to add another record to the table. Page 144 Operating TM Area specifics dialog Enter the following data in the displayed dialog (the required fields are those marked with asterisk ‘*’): * Area – select the area name from the dropdown list of this combo box. * Prefix – enter the telephone number prefix for the area. Min. number length – enter the decimal integer showing the minimum length of telephone numbers in the area. Max. number length – enter the decimal integer showing the maximum length of telephone numbers in the area. Click OK to add the record to the table. 5.8.9 Calling party’s categories The table Calling party’s category contains reference information about the calling party’s categories. Table "Calling party's category" The table presents the following data: ID – ID of the category. CPC type – name of the standard, which defines the category. Namespace – shows belonging to the international (CPC) or American (OLI) standard. Code – code of the category. Description – description of the category. In the table, there is also a record for empty category of calling party.. 5.8.10 CPC translations The table CPC translations presents information about correspondences between the international (CPC) and American (OLI) calling party’s categories. Page 145 Operating TM Table "CPC translations" The table presents the following information: Namespace – shows belonging to the international (CPC) or American (OLI) standard. Code – code of the category. CPC code mapping – if the category belongs to the OLI standard, this field shows the corresponding code in the CPC standard. If the correspondence is not defined, the System uses the value from parameter Default CPC code mapping. Default CPC code mapping – if the category belongs to the OLI standard, this field shows the default corresponding code in the CPC standard. OLI code mapping – if the category belongs to the CPC standard, this field shows the corresponding code in the OLI standard. If the correspondence is not defined, the System uses the value from parameter Default OLI code mapping. Default OLI code mapping – if the category belongs to the CPC standard, this field shows the default corresponding code in the OLI standard. The System translates calling party’s categories automatically, if the CPC in the incoming leg (or after translations on DPs, gateways, etc.) is defined in one standard (for example, CPC), but should be sent to the outgoing leg in the other standard (for example, OLI). 5.8.11 Capacity groups To control the softswitch capacity the System enables assorting calls into capacity groups. Table "Capacity groups" Grouping by capacity aims at flexible management of individual and aggregate capacity of gateways and dial peers. Capacity management allows you to limit the number of calls not only for each standalone gateway, but also for a group of gateways, if necessary. For example, the individual capacity of the terminators A and B is 10 and 10 calls respectively, but you want to limit the total capacity of both gateways to 15 calls. You can fulfill this task by assigning the gateways A and B to an A_B group and limiting the group capacity to 15 concurrent calls. Page 146 Operating TM In such a case when a new call arrives to the A gateway, the System checks if the capacity of the gateway A is not exceeded, as well as if the capacity of the group A_B (to which the gateway A belongs) is not exceeded. Capacity groups may become members of other capacity groups, thus creating a group hierarchy. In such a case when a call arrives to the A gateway, the System checks the capacity of the gateway, the capacity of the group A_B to which the gateway is a member, the capacity of the group A_B_C to which the group A_B is a member, and further up the group hierarchy. To add a new capacity group invoke the pop-up menu and select the Add option. Adding a capacity group Enter the following data in the displayed dialog (the required fields are those marked with asterisk ‘*’): * Name – name that identifies the capacity group. Description – you can enter any descriptive information or comments pertaining to the record being created in this field. Parent group – the parent group of this capacity group. Capacity – the number of concurrent calls that can pass through the group. If the field is empty or zero is entered, the number of calls is unlimited. Allowed values: 0-2147483647. When done, press OK. 5.8.12 Number capacity groups This table comprises capacity groups limiting concurrent calls to/from a specified phone number. The groups defined in the table may be assigned to originators to limit SRC numbers (the parameter SRC Page 147 Operating TM Number capacity group in the equipment settings), to terminators to limit the DST numbers (the parameter DST Number capacity group in the equipment settings) and to dial peers to override the terminator number capacity group settings (the parameter Override number capacity group in the dial peer settings). If the group is assigned, the number of concurrent calls with the same phone number passing through the gateway/dial peer may not exceed the number defined in the group. Number capacity groups * Name – name of the number capacity group. * Capacity – maximum number of calls with the same phone number. If the field is empty or zero is entered, the number of calls is unlimited. Allowed values: 0-4294967295. When limiting the SRC numbers, the number after originator translation is used; when limiting the DST number on the dial peer, the number after per-routing translations is sued; when limiting the DST number on the terminator, the number after dial peer translation is used. 5.8.13 Model codecs This table comprises codec parameters that are predefined in the System in the Codecs table. This table may be used to restore the original settings of the predefined codecs in case they were changed or deleted. Restoring predefined codec settings The table stores a list of predefined codecs together with their original settings. To restore the parameters of a certain codec or codecs, select them in the table by clicking on column to the left, invoke the popup menu and select the Special function -> Restore model codec settings (marked or selected). If a filter is applied to the table, then to restore the settings of the codecs, shown in the filtered table, in the popup menu select the Special function -> Restore model codec settings (all filtered). To restore the settings of all predefined codecs, click the OK button below the Restore model codec settings. 5.8.14 Model RADIUS attributes The page comprises a table with the model RADIUS attributes. This table may be used to restore the original settings of the predefined attributes in the RADIUS attributes table (see the section RADIUS attributes 163 ) in case they were changed or deleted. Page 148 Operating TM Model RADIUS attributes page The following data is available in the table columns: ID – attribute ID (sequence number); Record name – name of the attribute record in the format: <attribute source>-<attribute name>, where: Attribute source may have values: o rfc – attribute profile executed as per RFC2866. o cisco – attribute profile executed as per Cisco specifications. o mvts – attribute profile executed as MVTS Pro proprietary. Attribute name – name of the attribute, selected from the list of names, defined in RFC2866, provided by MVTS Pro or defined by Cisco. Field name – attribute name in the RADIUS packet. Code – digital code of the attribute. Vendor code – ID of the namespace provided to a certain company to define the attribute (9 = CISCO or 207 = Digest-Attributes). In case of an empty value, the attribute is defined according to RFC 2866. Type – value type. Value – value (contents) of the attribute. Authentication Maximum quantity of attributes in outgoing packets (authentication) - max. amount of attributes in the packets, sent to the RADIUS server. The values of the parameter are the following: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute of such type is allowed; 1+ - there can be several attributes of such type. Maximum quantity of attributes in incoming packets (authentification) - max. amount of attributes in the packets, received from the RADIUS server. The values of the parameter are the following: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute of such type is allowed; 1+ there can be several attributes of such type. Authorization Maximum quantity of attributes in outgoing packets (authorization) - max. amount of attributes in the packets, sent to the RADIUS server. The values of the parameter are the following: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute of such type is allowed; 1+ - there can be Page 149 Operating TM several attributes of such type. Maximum quantity of attributes in incoming packets (authorization) - max. amount of attributes in the packets, received from the RADIUS server. The values of the parameter are the following: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute of such type is allowed; 1+ there can be several attributes of such type. Accounting Maximum quantity of attributes in outgoing packets (accounting) - max. amount of attributes in the packets, sent to the RADIUS server. The values of the parameter are the following: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute of such type is allowed; 1+ - there can be several attributes of such type. Disconnect Maximum quantity of attributes in outgoing packets (PoD) - max. amount of attributes in the packets, sent to the RADIUS server. The values of the parameter are the following: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute of such type is allowed; 1+ - there can be several attributes of such type. Maximum quantity of attributes in incoming packets (PoD) - max. amount of attributes in the packets, received from the RADIUS server. The values of the parameter are the following: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute of such type is allowed; 1+ - there can be several attributes of such type. Description – arbitrary description of the attribute. To restore the parameters of RADIUS attributes select them in the table by clicking on column to the left, invoke the popup menu and select the Special function -> Restore model RADIUS attributes (marked or selected). If a filter is applied to the table, then to restore the settings of the attributes, shown in the filtered table, in the popup menu select the Special function -> Restore model RADIUS attributes (all filtered). Pop-up menu for the “Model RADIUS attributes” table To restore the settings of all predefined codec click the OK button below the Restore all model RADIUS attributes. 5.8.15 CDR tables This object comprises lists of all tables with CDRs stored in the DB. The System keeps one table for each day. Page 150 Operating TM CDR tables Each record in the object defines one CDR table in the DB. To view information on a specific table, invoke the context menu and click View. Table name – name of the table in the DB in the format mvts_cdr_<year><month><day>. Row count – number of rows in the table. Data size, MB – size of data in megabytes. Available for removal– indicates if the table can be removed. The following tables can not be removed: Table for the current month; Table mvts_cdr_000000, storing inaccurate CDRs. It is possible to set up automatic removal of CDR tables from the DB. To do it define the period for the table to be kept after its creation in the System global settings, CDR storage period, days (see section System global settings 136 ). Besides, it is possible to remove CDR tables manually. Select the required records in the CDR tables by any means (by clicking on them, activation checkboxes in the left column or applying a filter), invoke a pop-up menu and select Special function -> Remove CDR tables. Last month CDR tables cannot be deleted. 5.8.16 Custom views This table comprises a set of filters that are applied to GUI objects of the System. For each table record the System creates a separate subobject in the category tree, where the filtered information is presented. To add a new view invoke the pop-up menu and select the Add option. Table "Custom views" Enter the following data in the displayed dialog (the required fields are those marked with asterisk ‘*’): * Table - select the table to which the filter will apply. A subobject with data, filtered by the Filter, will be created in this table. * View name - enter the subobject (view) name. Page 151 Operating TM * Filter - define the filter that will be applied to the data of the parent table, specified in Table. The rules of filter definition are described in Use of filters 19 section. Click OK to add the record to the table. The System will create a new view in the form of a separate subobject to the parent table in the GUI object tree. For example, for the figure above the view will be as follows: Added view 5.8.17 Custom languages This tables allows the user to add a new interface language. To add a new language invoke the context menu and select Add. Table "Custom languages" Enter the following data in the displayed dialog (the required fields are those marked with asterisk ‘*’): * Language tag - specify the abbreviated language name. * Language name - specify the name of the new custom language. * Original language - select the language, from which the initial parameter names will be taken. Click OK to add the record to the table. The record will be added to the table Custom languages. The added language can be selected in the parameter System users -> Language. 5.8.18 Custom translations This tables allows the user to edit the names of parameters, objects and categories in the created custom language. Eacg object is assigned a translation in a custom language. Table "Custom translation" The table has the following parameters: Page 152 Operating TM * Object - a category, object or a parameter, to which the translation in the custom language is assigned. * Language - name of the language, to which the translation is assigned. * String type - object class. * Translation - editable name of the object in the custom language. * Original text - initial name of the object in the language select as the original one in the table Custom languages. When done, click OK. 5.9 Logs The category Logs comprises objects, which record all authentication attempts and actions of users in the GUI. 5.9.1 Web authentication history The object Authentication history is designed to store the log of user authentication attempts. Authentication history table The following table presents the authentication history record parameters: Session ID – ID number of the user logon session. Date – date and time of the registered authentication attempt. User – user account used for authentication. Realm – realm of the user. Login – login of the user used for authentication. IP address – IP address, of the computer which requested authentication. Page 153 Operating TM Login successful – shows if the login attempt was successful or not. To view all logged user actions during the selected session, invoke the pop-up menu and select Web activity log. This will open Web activity log filtered by the selected session ID. 5.9.2 Web activity log Web activity log is accessible in the category of objects GUI. The table Web activity log presents an account of user access to database objects and actions that users performed. Page with user activity transcripts An individual user activity record provides the following information presented in table columns: ID – record identifier. Session ID – ID of the session, during which the record was created. Logging time – date and time of record creation. User – actor’s account name. Object – name of the object that was accessed. Action – nature of the action done by the actor. Data – detailed account of the action effect. Filter – filter used while accessing data. Row count – number of processed lines. 5.10 Import The Import category comprises the Import wizard, designed for importing records from csv-files into different System tables. Page 154 Operating TM In step 1 you define the file from which the records are imported and specify the required import settings. Defining imported file parameters. Step 1 The following parameters are available: * From file – click Browse and locate the source file; * To table – select the target table; * Column sequence – select the required method for determining the sequence of columns. This parameter has the following options: Try to match the headers – the import procedure automatically matches the column names in the file with the names of the columns in the web-interface. Thus the sequence of columns in the files may be arbitrary if the column names match the names in the web interface. This method is used for importing records previously exported by means of a context menu from a respective table. Use the template – the import procedure matches the columns in the order they are in the webinterface (without considering the rearrangements performed by the web interface user). The columns that the user can not edit (such as ID) are ignored. This method is used when the file with imported records was obtained from a template file (see below). * Separator – define the separator used to delimit data in the source file; * Quote - define the quote character used in the source file; * Include headers – select this check box if the source file contains column headers. This will instruct the System to ignore the first row of data during import. * Encoding – select the type of encoding used in the source file; * Date format – use this control to define the date format to be applied to the imported data. Besides dates are also checked for compliance to specific requirements of some columns (for example, in the Schedule group of the Dial peer table); Records for inserting only – activate the checkbox if it is necessary to import only those records from the files that are absent in the target table. If they are present, such records will not be updated. * Unique columns – this field shows the list of columns checked for uniqueness during import. For the record in the file to be considered unique it is necessary that the combination of values of columns, defined in the list, should be unique. Non-unique records found in the csv file are discarded during the import. Template - by clicking this hyperlink you can download a template CSV file for import to the selected table. This file can be used to enter data that can be imported later. The template comprises no columns that the user can not edit (such as ID), thus it can be easily imported using the Use the Page 155 Operating TM template method. When done, click the Load button and proceed to the next step. Defining the sequence of columns. Step 2 In step 2 you can re-arrange the columns so that they correspond to the sequence of imported data. Use the and buttons in column headers to move them to the leftmost or rightmost position or click the header name, drag it to the required position and click again to insert it. The customized column order can be saved for further use. For this, click the Save sequence button and enter the layout’s name in the Save column sequence dialog box. Saving column sequence To delete unnecessary sequences click the Delete sequence button and select the needless layout’s name in the Delete column sequence dialog box. Deleting column sequence Click the Next button to continue. Screen 3 of the wizard presents information about imported data including: Target table Page 156 Operating TM Total number of imported records Number of records ready for insert Number of records ready for update Number of erroneous records, such records also will not be uploaded Number of duplicated records in the source file, only the last of the duplicated records in the imported files will be uploaded. Duplicated records in the DB will not be updated. The List of columns to be updated parameter in the Additional parameters group comprises a twowindowed control with column names. The columns in the right list will be updated during the import. The columns in the left list will remain unchanged. To move the columns from the left to the right list use the and buttons. Data for import. Step 3 The table Data for import is a temporary table with data imported from the CSV file in Step 1. In addition to the columns that constitute regular tables, the table Data for import contains the column Errors that provides information on detected errors and the column Status with current status of the record. Records with erroneous data are highlighted in red. You can add new records to the temporary table or edit the existing ones in the same way as you do it in regular tables. Upon editing the records are automatically checked and assigned a new status. Click the Import button to move the data to the regular table. To exit the wizard and return to the first page click Cancel. Page 157 Operating TM 5.11 RADIUS settings The RADIUS settings category comprises objects that allow the user to flexibly configure the interoperation if the System with the RADIUS server for accounting, authorization and routing. The detailed step-by-step instruction on configuring RADIUS interoperation is in section An example of RADIUS accounting configuration 173 . 5.11.1 RADIUS global settings The object RADIUS global settings comprise settings pertaining to interoperation with all RADIUS servers. RADIUS global settings Use H323_IVR_IN parameter in UserName field – “1” means putting the value of the H323_IVR_IN parameter, if it is received from the RADIUS server in case authorization or external routing is used, in Page 158 Operating TM the UserName field of the accounting packets. External routing w/o authorization – “1” means that the System skips authorization of a call if at least one route is generated with help of RADIUS-aided routing. Encrypt H.323 plain text password – toggles encryption of the plain text password from an H.323 device, when the password is sent to a RADIUS server. The password is encrypted, when the device registers through a default gateway or has RADIUS password set to ‘*’. The System uses the secret key of the RADIUS server, to which the password is sent, for encryption. ‘Service-Type’ attribute value – specify the value of the Service-Type attribute to be sent to the RADIUS server. If no value is 0, the attribute is not included into the packets. For further information refer to RFC 2865. ‘Framed-Protocol’ attribute value – specify the value of the Framed-Protocol attribute to be sent to the RADIUS server. If no value is 0, the attribute is not included into the packets. For further information refer to RFC 2865. Use protocol conference ID in h323-conf-id field – the parameter defines the way to fill out the h323conf-id field sent to the RADIUS server. 1 – Conf ID coming from the equipment is used. If the Conf ID has not come from the equipment (for example, in case of SIP), the h323-conf-id is sent empty. 0 – the Conf ID generated by the TS is used for all cases. For this p arameter value1 is valid only in case of using a standard RADIUS p rof ile (i.e. a p rof ile with Send ACCT.START/STOP packets not set to Customizable Cisco-compatible, see section RADIUS accounting p rof iles 170 ) . Otherwise error may occur. Active RADIUS accounting profile – enter the record ID of a RADIUS accounting profile (see section RADIUS accounting profiles 170 ). This profile will become active. Digest authentication type: 0 - draft-sterman-aaa-01, 1 - draft-sterman-aaa-04 – determines the type of Digest authentication (see section Digest authentication 278 ) to be used by the system: 0 - draftsterman-aaa-01, 1 - draft-sterman-aaa-04. RADIUS interims enabled – 0 – do not send RADIUS interims, 1 – send RADIUS interims. In case customized RADIUS p rof ile is used, the System disp atches the interim p ackets of typ e "Originate" and "Answer" (i.e. f or both legs) . Call authorization before routing - if the parameter is 0, call authorization is performed after generating a list of routes. If the parameter is 1, call authorization is performed after generating a list of routes. By default, the parameter is 0. If Call authorization before routing is 1, the System does not make use of External routing w/o authorization parameter value. PoD response storage period, sec - period for storing data on Packet of Disconnect arrival and the System's response to the RADIUS server. By default - 5 secs. Server list generation method - a method for generation of RADIUS server list for each call. Valid values: 0 — By priority — the System sorts the RADIUS server list for each call based on the server's priority, in the descending order. 1 — Round robin balancing — each next call is associated with the next RADIUS server in the list. In other words, with the original list of servers labeled 1, 2, 3 the list for the first call will be 1, 2, 3; for the seconds call - 2, 3, 1; for the third call - 3, 1, 2; for the forth call - 1, 2, 3. When RADIUS groups are employed, the System first rotates the global list of RADIUS servers and then applies the group limitations to it. As the result with the following initial conditions: The initial global RADIUS server list is 1, 2, 3, 4; A RADIUS group holds servers 3 and 4; The System forms the following server lists for each call: Call sequence number 1 Global server list (servers belonging to the group are highlighted) 1, 2, 3, 4 Current active server 3 Page 159 Operating TM Call sequence number Global server list (servers belonging to the group are highlighted) Current active server 2 2, 3, 4, 1 3 3 3, 4, 1, 2 3 4 4, 1, 2, 3 4 5 1, 2, 3, 4 3 2 — By "responses/requests" ratio — the System dynamically generates the list for each call based on the ratio of responded requests to the total number of requests. The list is sorted in the descending order. The procedure for dispatch of RADIUS packets to the server is described in Appendix E. MVTS Pro – RADIUS interaction 257 . Time zone for time in RADIUS packets – choose a time format for the RADIUS billing and routing packets. Value 1 means UTC, which presents the packet date in the UTC time zone. Value 2 means “Local time”, which presents the date as local time, configured on the host with the scripting node. Proxy mode code mapping for RADIUS external routing - the parameter value is a set of commadelimited numbers the default string being 0, 1, 2, 3, 4, 5. The position of the figure in the string denotes the proxy mode value provided by the RADIUS server and the figure that occupies the position shows the proxy mode value of the System. Position numbering starts at 0. The media proxy mode values used by the System are as follows: o 0 - Do not proxy media o 1 - Try not to proxy media on every route o 2 - Try not to proxy media on the first route o 3 - Do not proxy whenever possible, use first originator's codec o 4 - Do not proxy whenever possible, use first common codec o 5 - Proxy media Proxy modes No. 3 and 4 are no longer used. Suppose the value of the new parameter is 5, 5, 5, 2, 1, 0. By this means the System performs proxy mode values mapping as follows: o figure at position 0 is 5 which means that value 0 from the RADIUS server means mode 5 "Proxy media" o 1 -> 5 (i.e., the value 1 from the RADIUS server means "Proxy media") o 2 -> 5 (i.e., the value 2 from the RADIUS server means "Proxy media") o 3 -> 2 (i.e., the value 3 from the RADIUS server means " Try not to proxy media on the first route") o 4 -> 1 (i.e., the value 4 from the RADIUS server means "Try not to proxy media on every route") o 5 -> 0 (i.e., the value 5 from the RADIUS server means "Do not proxy media"). Use external RADIUS routing with separate parameters - specify 1, if it is necessary to use a new format 275 of the field xpgk-xrouting-routing with different values for parameters. If the value is 0, the System will accept the field xpgk-xrouting-routing in the old format 274 . Both formats cannot be supported at the same time (refer to AccessRequest structure for RADIUS-aided routing 273 ). Use h323-redirect-number for billing DST number - specify 1, if it is necessary to use the value of the parameter h323-redirect-number as a DST number, used in the billing. The parameter is applied, if the parameter Call authorization before routing has the value 1. Numbers used in the billing pass through the following translations: 1) prerouting translations (apply to SRC and DST numbers) Page 160 Operating TM 2) using DST number from the parameter h323-redirect-number with enabled parameters Call authorization before routing and Use h323-redirect-number for billing DST number (applies only to DST number) 3) number translations in the dial peers (apply to SRC and DST numbers) 4) number translations during external routing (apply to SRC and DST numbers). 5.11.2 RADIUS servers The table RADIUS servers presents information about configured RADIUS servers used as external authentication, accounting and/or routing means. Table of configured RADIUS servers To add a RADIUS server record, left click the mouse over the table and select Add on the pop-up menu. Adding a RADIUS server record Fill out the displayed server configuration form. The fields marked with an asterisk are required fields. * RADIUS server name – enter the name of the RADIUS server. Page 161 Operating TM Description – you can enter any information pertaining to the record being configured in this field. Enable – select the checkbox to make the record active. * Precedence – use this parameter to define the server precedence. The higher the value – the higher the precedence (that is 2 has higher precedence than 1). At each instance of time MVTS Pro interacts with one server only, with the highest precedence. If the system detects a failure of the RADIUS server it is currently connected to, it will switch to the next configured server with the lower precedence value. Allowed values: 0-2147483647. Enable authentication – select the check box to enable authentication of gateways by the RADIUS server being configured. Enable authorization – select the check box to enable authorization of calls from gateways by the RADIUS server being configured. If RADIUS does not respond in (Max. time of call handling by the scripting node, msec - (SETUP time - time of authorization request dispatch)), the System terminates the call. When the Enable authorization checkbox is selected and at least one route of a dial p eer is generated with help of external routing f eature, all routes of the dial p eer do not undergo authorization on the RADIUS server. This relieves the load f rom the System and the RADIUS server. Enable accounting – select the check box to enable accounting through the RADIUS server being configured. Enable external routing – select the check box to if you are planning to use the RADIUS server for external routing. Secret key – enter a coding key (according to the ‘shared secret’ standard) for communication with the RADIUS server. Category Authentication – these parameters are valid only with the selected Enable authentication or Enable authorization checkboxes: Authentication address – enter the IP address of the RADIUS server used for authentication. Authentication port – enter the port for authentication on the RADIUS server. Allowed values: 165535. Initial RADIUS response timeout (authentication), msec - initial waiting period for a RADIUS response to a dispatched authentication/authorization packet. Allowed values: 0-4294967295. By default - 2 secs. This timeout is used for the first attempt to send the packet to the RADIUS server. In case of a failure, timeouts for further attempts are re-calculated as per RFC 5080. Maximum retries of packet dispatch (authentication) - maximum number of attempts to send the authentication/authorization packet to the specific RADIUS server. Allowed values: 0-65535. By default - 5 attempts. Maximum RADIUS response timeout (authentication), msec - maximum waiting period for a RADIUS response for the second and subsequent attempts to deliver the authentication/authorization packet to the RADIUS server. When re-calculating the timeout after the first attempt as per RFC 5080, the recalculated time is limited by this parameter. Allowed values: 0-4294967295. Maximum total retry period of packet dispatch (authentication), msec - maximum duration for all attempts to deliver the authentication/authorization packet to the specific RADIUS server. All attempts to send the packet to the server will be stopped if the value of this parameter is exceeded. Allowed values: 0-4294967295. Category Accounting – these parameters are valid only with the selected Enable accounting checkbox: Accounting address – enter the IP address of the RADIUS server to be used for accounting purposes. Accounting port – enter the port of the RADIUS server to be used for accounting purposes. Allowed values: 1-65535. Initial RADIUS response timeout (accounting), msec - initial waiting period for a RADIUS response to a dispatched accounting packet. By default - 2 secs. This timeout is used for the first attempt to send the packet to the RADIUS server. In case of a failure, timeouts for further attempts are re-calculated as per RFC 5080. Allowed values: 0-4294967295. Page 162 Operating TM Maximum retries of packet dispatch (accounting) - maximum number of attempts to send the accounting packet to the specific RADIUS server. Allowed values: 0-65535. By default - 5 attempts. Maximum RADIUS response timeout (accounting), msec - maximum waiting period for a RADIUS response for the second and subsequent attempts to deliver the accounting packet to the RADIUS server. When re-calculating the timeout after the first attempt as per RFC 5080, the re-calculated time is limited by this parameter. Allowed values: 0-4294967295. Maximum total retry period of packet dispatch (accounting), msec - maximum duration for all attempts to deliver the accounting packet to the specific RADIUS server. All attempts to send the packet to the server will be stopped if the value of this parameter is exceeded. Allowed values: 0-4294967295. Category External routing – these parameters are valid only with the selected Enable external routing checkbox: External routing address – enter the IP address of the RADIUS server to be used for purposes of external routing. External routing port – enter the port of the RADIUS server to be used for purposes of external routing. Allowed values: 1-65535. Initial RADIUS response timeout (ext. routing), msec - initial waiting period for a RADIUS response to a dispatched external routing packet. By default - 2 secs. This timeout is used for the first attempt to send the packet to the RADIUS server. In case of a failure, timeouts for further attempts are recalculated as per RFC 5080. Allowed values: 0-4294967295. Maximum retries of packet dispatch (ext. routing) - maximum number of attempts to send the external routing packet to the specific RADIUS server. Allowed values: 0-65535. By default - 5 attempts. Maximum RADIUS response timeout (ext. routing), msec - maximum waiting period for a RADIUS response for the second and subsequent attempts to deliver the external routing packet to the RADIUS server. When re-calculating the timeout after the first attempt as per RFC 5080, the recalculated time is limited by this parameter. Allowed values: 0-4294967295. Maximum total retry period of packet dispatch (ext. routing), msec - maximum duration for all attempts to deliver the external routing packet to the specific RADIUS server. All attempts to send the packet to the server will be stopped if the value of this parameter is exceeded. Allowed values: 0-4294967295. It is p ossible to use the same IP addresses and p orts f or dif f erent f unctions of the RADIUS server; you can sp ecif y the same IP address and p ort f or authentication and accounting, f or examp le. When done with entering data, click OK to add the record to the table. If you wish to modify the record, select the Edit item on the pop-up menu. The System p olls RADIUS servers every 60 seconds and uses op erational billing and authorization p ackets f or it. In other words every 60 seconds the System starts to send billing and authorization p ackets not to the active server, but to the server with highest p recedence and f urther to servers with lower p recedence. In case of authorization p ackets, if the server with higher p riority is unavailable, the call will be rej ected during the switch to the lower p recedence server. Besides in case of a large number of inactive RADIUS servers, large retry numbers and large intervals between retries the waiting p eriod f or the RADIUS rep ly may exceed 5 seconds and the call will be rej ected with “TMngr timeout” code. That is why it is recommended to use not more than two RADIUS servers. 5.11.3 RADIUS attributes This table comprises record with all attributes that could be incorporated into the RADIUS packets. Initially the table comprises 130 records with predefined RADIUS fields. Page 163 Operating TM RADIUS attributes table Possible actions over this record are specified in the context menu invoked by a left click. Menu of available actions in the RADIUS attributes table The following information is available in the columns of the table: ID – ID of the attribute record (sequence number). Record name – name of the attribute record in the format: <attribute source>-<attribute name>, where: Attribute source may have values: o rfc – attribute profile executed as per RFC2866. o cisco – attribute profile executed as per Cisco specifications. o mvts – attribute profile executed as MVTS Pro proprietary. Attribute name – name of the attribute, selected from the list of names, defined in RFC2866, provided by MVTS Pro or defined by Cisco. Field name – attribute name in the RADIUS packet. Code – digital code of the attribute. Allowed values: 1-255. Vendor code – ID of the namespace provided to a certain company to define the attribute (9 = CISCO Page 164 Operating TM or 207 = Digest-Attributes). In case of an empty value, the attribute is defined according to RFC 2866. Type – value type. Value – value (contents) of the attribute. Description – arbitrary description of the attribute. It is possible to use the Python expressions as well as variables listed in the table below in the Value field. In the drop-down list Maximum quantity of attributes in the outgoing packets (accounting) select the max. amount of attributes in the packets, sent to the RADIUS server. The following values are available: 0 - the packet of such type cannot contain the attribute; 1 - only one attribute is allowed in the packet; 1+ - there can be several attributes of such type. In the field Description, enter the necessary explanation. Press OK when you finish the settings. The list of available variables for the field Value is provided in the table below. Available variables Name Value on the incoming leg Value on the outgoing leg alertingTime ALERTING arrival time. ALERTING arrival time. ani SRC number. SRC number after pre-routing translations aniBasic SRC number coming to the scripting node on call begin N/A aniBill SRC number for billing after pre-routing translations SRC number for billing after prerouting translations aniIsup SRC number from ISUP message (SIP-T/ SIP-I). N/A aniNumberPlan N/A SRC numbering plan aniPresentation N/A SRC Presentation indicator aniScreening N/A SRC Screening indicator aniTypeOfNumber SRC number type SRC number type callId Call ID from the equipment N/A code N/A Disconnect code codecs Codec list Codec list confId Conf ID from the equipment N/A connectTime CONNECT arrival time. CONNECT arrival time cpc Calling party category. Calling party category creationTime Time of call arrival into the scripting node N/A disconnectInitiator Call disconnect initiator N/A disconnectTime Disconnect time N/A dnis DST number DST number after pre-routing translations dnisBasic DST number coming to the scripting N/A Page 165 Operating TM Name Value on the incoming leg Value on the outgoing leg node on call begin dnisBill DST number for billing after pre-routing translations DST number for billing after dial peer translations dnisIsup DST number from the ISUP message (SIP-T/SIP-I). N/A dnisNumberPlan N/A DST numbering plan dnisTypeOfNumbe DST number type. r DST number type dpName N/A Dial peer name dpID N/A Dial peer ID faststart N/A If faststart is used or not gatekeeperAddress Gatekeeper address N/A gwAddress Originator gateway address Terminator gateway address gwID Originator gateway ID Terminator gateway ID gwName Originator gateway name Terminator gateway name h323Id "H323-ID" parameter from the equipment. N/A h323IvrIn If H232_IVR_IN is used in User-Name field. N/A larFaultReason Re-routing reason N/A localSrcSigAddress Local orig. signaling address N/A outAniTypeOfNum SRC number type ber N/A packetType Packet type: 1=START, 2=STOP Packet type: 1=START, 2=STOP proto Protocol. Protocol. radiusForceOrigina N/A teTelephony If "h323-call-type" has "Telephony" string radiusNasPortNam N/A e RADIUS port name radiusUser N/A RADIUS user name. remoteMediaAddre N/A ss, rtpAddress Media address of the media node remoteSrcSigAddre Remote orig. signaling address ss N/A routeNum N/A Route sequence number routeRowId N/A A random value setupTime SETUP arrive time SETUP arrival time sigAddress N/A Remote term. signaling address signalingSrcSigAd dress Signaling address from the signaling packets Signaling address from the signaling packets Page 166 Operating TM Name Value on the incoming leg Value on the outgoing leg sigNodeName Signaling node name N/A tsCallId Call ID, generated by the TS N/A tsConfId Conf ID, Generated by the TS N/A user User name. N/A zone Zone Zone pdd N/A PDD radiusPassword N/A RADIUS password inOrigDnis Redirecting number (the parameter should always be used with inLeg modifier) N/A Pulses sent (for FICORA) Pulses received (for FICORA) nationalStatistic.pu lses As it is clear from the table the variable value depends on the call leg, for which it is used. Besides it is possible to explicitly specify the call leg by using the inLeg. (incoming) and outLeg. (outgoing) qualifiers before the variable name. Take ani variable as an example: For the incoming leg (the data on which is transmitted in answer packets) the value of ani variable is an SRC number arrived from the gateway. For the incoming leg (the data on which is transmitted in originate packets) the value of ani variable is an SRC number after applying pre-routing translation rules. To explicitly define which value to take, use the following statement: o inLeg.ani – as in the incoming leg; o outLeg.ani – as in the outgoing leg. The requested variable may have no value. In this case the attribute and its value will not be included into the RADIUS packet. Function available in RADIUS attributes Name Parameters Description Example toVsaTimeFormat(setupTime, "UTC") toVsaTimeForma t Time Time zone Translation of time to VSA time format: “14:09:27.861 UTC Wed Oct 01 2008”. Time zone may defined by two values: “UTC” and “SYSTEM”. toCiscoConfId Conf ID Translation of Conf ID to toCiscoConfId(inLeg.confId) Cisco conf id format: “00000000 00000000 00000000 00000000” toCiscoCallId Call ID Translation of Call ID to Cisco call id format: “00000000 00000000 00000000 00000000” toCiscoCallId(callId) getIP IpAddress:port Translation of “IP:port” string from “127.0.0.1:1234” to getIP(gwAddress) Page 167 Operating TM Name Parameters Description Example “127.0.0.1” 5.11.4 reasonToH323 Universal disconnect code Translation of a universal disconnect code to a H323 code reasonToH323(code) ipFromBin Ip-address as 4 bytes Translation of 4-byte IP address into a string “127.0.0.1” ipFromBin(ip) replaceAniIn User name Number Replacement of $ANI$ metavariable in the username with the number. replaceAniIn(user, ani) str Any value Cast of any value to string Str(setupTime) toSeconds A result of times subtraction Translation of times subtraction result into seconds. toSeconds(disconnectTimeconnectTime) toCiscoReleaseS ource Call disconnect initiator Protocol used Translation of toCiscoReleaseSource(inLeg. disconnect data into disconnectInitiator ,proto) Cisco format: If the call disconnect initiator is the System, the result is “Internal call-control application (Tcl or VoiceXML script)” - code 7; If the call disconnect initiator is the originator and SS7 protocol is used, the result is “Calling party located in PSTN” - code 1; If the call disconnect initiator is the originator and SS7 protocol is not used, the result is “Calling party located in VoIP network” - code 2; If the call disconnect initiator is the terminator and SS7 protocol is used, the result is “Calling party located in PSTN” - code 3; If the call disconnect initiator is the terminator and SS7 protocol is not used, the result is “Calling party located in VoIP network” - code 4; RADIUS accounting packets The table RADIUS accounting packets serves to modify and compose new RADIUS accounting packets, sent to the RADIUS server. Page 168 Operating TM RADIUS accounting packets table The addition or modification of packets is performed via a two panel dialog. To add a new packet invoke the context menu and click Add. Dialog for adding/modification of a packet In the parameter Packet name define the new packet name. On the left panel of the Fields dialog is the full list of all attributes from the RADIUS attributes table. On the right panel the fields incorporated into the packet are listed. The packet composition is modified by including one and removing other fields, as well as by changing their order. By moving the elements from the left to the right fields are included into the packet. By moving the elements from the right to the left fields are removed from the packet. Holding down a Shift or a Ctrl key allows you to select several elements at once. Use buttons and Use the versa. to move the selection from one list to the other. and buttons to move all records from the left box to the right one and vice By shifting the element names up and down in the list, using the and , buttons, you can change the order in which they are put into the RADIUS packet. Elements from the top of the list become the first attributes in the packet. When done click OK. If only one field is allowed in the packet, but there are several of them, such packet will not be formed. Such repeated fields will be displayed in the corresponding message. Page 169 Operating TM 5.11.5 RADIUS accounting profiles The RADIUS accounting profiles page allows the user to flexibly define the RADIUS accounting parameters and save this parameters to the accounting profiles. The user can change the active profile according to his own needs and requirements. In every given moment of time of all the profiles in the table only one profile may be active. To activate the profile enter its record ID into the Active RADIUS accounting profile in the RADIUS global setting window. RADIUS accounting profiles table Initially the System has two profiles configured: Standard – the profile imitating RADIUS settings for System versions 1.5.2 and below. Cisco PGW 2200 – the profile the allows the user to flexibly configure the billing information. The composition of the packets corresponds to that of Soft switch Cisco PGW 2200. To add a new RADIUS accounting profile invoke the context menu and select Add. Adding a new RADIUS accounting profile Specify the following parameters in the profile window: * Profile name – name of the RADIUS accounting profile. * Send ACCT. START/STOP packets – defines an accounting method through the choice of packets used for accounting and billing. Select the required option from the drop-down list. In case an option other than Customizable Cisco-compatible is selected, the System composes the packet automatically according to Appendix E. MVTS Pro – RADIUS interaction 257 . of the incoming leg – when selected makes the System send the RADIUS server ACCT. START/STOP packets, pertaining to the incoming leg. of the outgoing leg – when selected makes the System send ACCT. START/STOP packets, Page 170 Operating TM pertaining to the outgoing leg. of both legs – when selected makes the System send ACCT. START/STOP packets, pertaining both to the incoming and outgoing legs. of both legs with field substitution – when selected makes the System send ACCT. START/ STOP packets, pertaining to both call legs, and performs the following substitutions in packet fields: For the incoming leg: Field name Substituted value h323-gw-id ID of the termination gateway h323-gw-address IP address of the termination gateway or gatekeeper used for signaling h323-remote-id ID of the origination gateway h323-remote-address IP address of the origination gateway used for signaling For the outgoing leg: Field name Substituted value h323-gw-id ID of the origination gateway h323-gw-address IP address of the origination gateway or gatekeeper used for signaling h323-remote-id ID of the termination gateway h323-remote-address IP address of the termination gateway used for signaling of both legs for each rerouting attempt – with this option selected the System sends only one pair of ACCT. START/STOP packets pertaining to the incoming leg. For example, if the call was rerouted three times, the set of the packets sent to the RADIUS server will be as follows: Accounting START record for the answer leg originate leg Accounting START record 1 originate leg Accounting STOP record 1 originate leg Accounting START record 2 originate leg Accounting STOP record 2 originate leg Accounting START record 3 originate leg Accounting STOP record 3 Accounting STOP record for the answer leg The fields will have the following contents: For the incoming leg: Field name Substituted value h323-gw-id ID of the termination gateway Page 171 Operating TM h323-gw-address IP address of the termination gateway or gatekeeper used for signaling h323-remote-id ID of the origination gateway h323-remote-address IP address of the origination gateway used for signaling For the outgoing leg: Field name Substituted value h323-gw-id ID of the origination gateway h323-gw-address IP address of the origination gateway or gatekeeper used for signaling h323-remote-id ID of the termination gateway h323-remote-address IP address of the termination gateway used for signaling Customizable Cisco-compatible – when selecting this option the window changes to the following one. The new window allows you to specify the START and STOP packet for the incoming and outgoing legs from the previously defined packets (see section RADIUS accounting packets 168 ): RADIUS accounting profile view when Customizable Cisco-compatible option is selected Send Accounting Boot message – with this option selected, when the System starts or stops interoperation with the RADIUS server (including the emergency restart of the System), it sends the RADIUS server a corresponding Accounting Boot message. The Accounting Boot message is used to synchronize call state on the RADIUS server with call state in the System, as all calls in the System are terminated after emergency restart, so they should be terminated on the RADIUS server. Send Accounting packets for the outgoing leg for the last route only - select the checkbox to send Accounting packets for the outgoing leg and for the last route only. The parameter is visible only if Customizable Cisco-compatible option is selected in Send ACCT. START/STOP packets parameter. Send Accounting STOP only – enables/disables sending of Accounting STOP packets only. Select the checkbox to have the System send accounting STOP packets only. START Answer packet – from the dropdown list select a packet (defined in the RADIUS accounting packets) to be sent to the RADIUS server as a START packet for the incoming call. If an empty option is selected, the START packet for the incoming call leg will not be sent. The parameter is displayed when the Customizable Cisco-compatible option is selected in the Send ACCT.START/STOP packets parameter. Page 172 Operating TM STOP Answer packet – from the dropdown list select a packet (defined in the RADIUS accounting packets) to be sent to the RADIUS server as a STOP packet for the incoming call. The parameter is displayed when the Customizable Cisco-compatible option is selected in the Send ACCT.START/ STOP packets parameter. START Originate packet – from the dropdown list select a packet (defined in the RADIUS accounting packets) to be sent to the RADIUS server as a START packet for the outgoing call. If an empty option is selected, the START packet for the outgoing call leg will not be sent. The parameter is displayed when the Customizable Cisco-compatible option is selected in the Send ACCT.START/ STOP packets parameter. STOP Originate packet – from the dropdown list select a packet (defined in the RADIUS accounting packets) to be sent to the RADIUS server as a STOP packet for the outgoing call. The parameter is displayed when the Customizable Cisco-compatible option is selected in the Send ACCT.START/ STOP packets parameter. 5.11.6 RADIUS groups This table contains the list of RADIUS server groups. If a group is assigned to a gateway, all RADIUS packets associated with this gateway will be dispatched to the servers of this group. To add a group, left click the mouse over the table and select Add on the pop-up menu. Fill out the displayed configuration form. The fields marked with an asterisk are required fields. * RADIUS group name – enter the name of RADIUS server group. RADIUS list – the list of RADIUS servers pertaining to the group. The list composition is modified by including one and removing other servers, as well as by changing their order. By moving the elements from the left to the right servers are included into the group. By moving the elements from the right to the left servers are removed from the group. Holding down a Shift or a Ctrl key allows you to select several elements at once. Use buttons and to move the selection from one list to the other. Use the and buttons to move all records from the left box to the right one and vice versa. The sequence of servers is of no importance. When done with entering data, click OK to add the record to the table. 5.11.7 An example of RADIUS accounting configuration 5.11.7.1 RADIUS server declaration First of all it is necessary to define the settings of the RADIUS server with which the System will be interoperating. In the RADIUS server table invoke the pop-up menu and select Add. Page 173 Operating TM Adding a new RADIUS server record In the RADIUS server name enter the name of the record. In the example it is Custom RADIUS. Select the Enable accounting checkbox for the System to dispatch Accounting packets to the RADIUS server. Otherwise this server will not be used for accounting. In the Accounting parameter group defined the address and port of the RADIUS server to which the Accounting packets will be dispatched. When done click OK. 5.11.7.2 Using predefined or custom profiles The next steps depend on the necessity to use standard RADIUS accounting settings. The application of standard accounting settings (e.g. the Standard profile) allows the user to emulate System operation similar to that of versions 1.5.2 and below. To make use of the standard profile do the following: In the table RADIUS accounting profiles create a new profile or modify the existing one. In the field Send ACCT.START/STOP packets select an option other that Customizable Ciscocompatible (for further information refer to sections RADIUS accounting profiles 170 ). The composition of attributes in packets will be according to the set, specified in section MVTS Pro - RADIUS interoperation. In the table RADIUS global settings -> Active RADIUS accounting profile parameter specify the record ID of the new or modified RADIUS accounting profile. If it is necessary to define the attributes sent to the RADIUS server in a more flexible way, do the following: Page 174 Operating TM Define the required RADIUS attributes (see section RADIUS attributes configuration Distribute attributes among packets (see section RADIUS packet configuration 175 175 ); ); Assign packets to a RADIUS accounting profile and active the profile (see section RADIUS profile configuration 176 ). 5.11.7.3 RADIUS attributes configuration After RADIUS server configuration specify the RADIUS attributes to be sent to the RADIUS server in the RADIUS attributes table. By way of example let’s take a new attribute mvts-custom-h323-call-id. This record will comprise information of the h323-call-id attribute generated by the TS as a string in Cisco format. To add a new attribute invoke the pop-up menu and select Add. Adding a new RADIUS attribute In the Record name parameter specify the record name. In this example it is mvts-custom-h323-call-id. In the Field name parameter select the name of the attribute in the RADIUS packet from the drop-down list. In this example it is h323-call-id. In the Code parameter specify the digital code of the attribute. In this example it is 1. In the Vendor code parameter specify the code of the originator of the attribute. In this example it is 9 (Cisco VSA).Another value of this parameter is 207 (Digest-Attributes). In the Type parameter specify the type of attribute. In this example it is a string. In the Value parameter specify the value of the attribute. In this example it is the result of the function toCiscoCallId, that takes a callId variable. The callId variable comprises the call ID generated by the TS. In the Description parameter specify the pertinent information. When done, click OK. Configure all other required attributes in the similar fashion. 5.11.7.4 RADIUS packet configuration Once attribute configuration is completed it is necessary to group them into different packets. To do it go to the RADIUS accounting packets table and add anew record using the pop-up menu. Page 175 Operating TM Adding a new RADIUS packet In the Packet name field specify the name of the RADIUS packet. In this example it is Custom-Packet. In the Fields window move the required attributes from left to right using the button. In this example move the attribute mvts-custom-h323-call-id. The order of attributes in the packet is modified with the and buttons. When done click OK. 5.11.7.5 RADIUS profile configuration Once RADIUS packets are set it is necessary to configure a RADIUS accounting profile that governs the parameters for interoperation with the RADIUS server, including those defining packet composition. Go to RADIUS accounting profiles and using the context menu create a new profile. Adding a new RADIUS accounting profile In the Profile name specify the profile name. In this example it is Custom-Profile. In the parameter Send ACCT.START/STOP packets select Customizable Cisco-compatible. The view of the page will change and new parameters will appear. In the parameters STOP Answer packet and STOP Originate packet specify the name of the previously created packet (Custom-Packet). When done click OK. Then it is necessary to activate the profile. Go to the table RADIUS global settings and in the parameter Active RADIUS accounting profile specify the record ID of the new profile. In this example it is 4. Page 176 Operating TM Activating a new RADIUS accounting profile Click OK. So after the abovementioned procedure is completed The System will send two packets AccountingStop upon call disconnect with one field h323-call-id that will comprise a Call ID, generated by the TS, in Cisco format. 5.12 SS7 Call Agent node configuration 5.12.1 SS7 Call Agent nodes This page contains a list of SS7 Call Agent nodes configured in the System. Also, on this page you can save and restore settings (data from the tables in the categories M3UA (refer to RFC 4666), MGCP (refer to RFC 3435) and ISUP/Call Control) for a certain node. The table SS7 nodes includes a list of SS7 Call Agent nodes present in the System. To add a node, select Add in the pop-up menu. In the field Name, enter the name of the node. To select a node from the drop-down list of the nodes launched in the System (from the table "Active nodes" 96 of Traffic switch), press the button List. The user can add and delete nodes in this table with the help of the context menu. When adding a node, its settings appear in the subcategory displayed in the SS7 nodes configuration category of the object tree. When deleting a node, the corresponding subcategory disappears from the table. To edit the name of the node, follow the procedure below: save the node settings using the dialog Store/Restore/Delete nodes settings; delete the node; Page 177 Operating TM restore the node settings specifying the new name using the dialog Store/Restore/Delete nodes settings. You can save the current node configuration and then restore it with the help of the dialog Store/ Restore/Delete nodes settings. Enter the following parameters: Action* - select the required action: Store - save the node settings, selected in the drop-down list Node name, under the name specified in the field Name of backed-up node settings. Restore - restore the settings specified in the parameter Name of saved node settings. You can either restore the node settings, saved to the database, or upload the settings from a file. To restore the node settings from the database, select the <node name> - <name of the saved settings> value from the drop-down list Name of saved node settings (see the table Saved settings of nodes below). To apply settings stored in a file, select the checkbox Specify a path to the file with saved settings. After that, two fields will appear: Path to the file with saved settings and Restorable node name. Press the button Browse (or left-click on the field Path to the file with saved settings), then in the window select the file with necessary settings. You can apply the settings from the list Saved settings of nodes to the node which is either new or already existing in the System. Enter the name of the node in the field Restorable node name. To select the node from the drop-down list, press the button List. Delete - delete the earlier saved settings, specified in the parameter Saved settings of nodes. To perform this action, press OK. The table Saved settings of nodes contains the list of earlier saved settings of the nodes. Page 178 Operating TM The table includes the following columns: Node name - the name of the node, for which the settings were saved (the record ID from the table SS7 nodes is specified in brackets for active nodes); Creation date - the date when the file with settings was created; Backup name; Name of the file with saved settings - <name of the backed-up node settings> - <node name> <SS7> - <creation date>.sql. The files are stored in the directory /var/www/rtu/uploads/ ts/backups/. 5.12.2 Node parameters 5.12.2.1 List of invalid records This table contains invalid records from the SS7 node settings. Table name - the name of the table which contains an invalid record. Record ID - the identifier of the table with an invalid record. Comment - the reason why this record is invalid. 5.12.2.2 Wizards Node setup procedure with the help of wizards is the following: signaling gateway setup (see the section Add a signaling gateway media gateway setup (see the section Add a media gateway 188 5.12.2.2.1 194 ); ); ISUP connection setup (see the section Add a ISUP connection trunk setup (see the section Add a trunk 181 192 ); ). Copy the settings of the current node With the help of this wizard you can create new SS7 nodes by copying major parameters from the current node. Page 179 Operating TM * New node name - the name of a new SS7 node. The group of parameters SCTP endpoints contains data on the SCTP endpoints which should be modified when copying the node configuration. The group of parameters Local and Remote contains the parameters, referring to the local and remote SCTP endpoints. * Address (new) - the IP-address of the new local/remote SCTP endpoint (or a list of IP-addresses, delimited with a semicolon ";"). * Port (new) - the port of the new SCTP endpoint (local or remote). Address and port of the current local and remote SCTP endpoint are displayed in the fields Address (<node name>) and Port (<node name>). The p air address:p ort should be unique f or each node. The group of parameters Signaling processes (SP) contains data on the signaling processes (SP), which can be modified when copying the node configuration. The group contains fields with data, if there are any signaling processes with ASP role in the initial configuration. ASP identifier - a new ASP identifier for the added signaling process (SP). The group of parameters MGCP local Instances contains the data on local MGCP instances, which should be modified when copying the node configuration. Page 180 Operating TM * Address (new) - the IP-address of the new local MGCP instance. * Port (new) - the port of the new local MGCP instance. Address and port of the current local MGCP instance are displayed in the fields Address (<node name>) and Port (<node name>). Parameters of the new local MGCP instance can coincide with parameters of the current instance. The group of parameters Media gateways contains data on media gateways which can be modified when copying the node configuration. New name - the name of the new media gateway. New description - the description of the new media gateway. * Address (new) - the new address of the media gateway. * Port (new) - the new port of the media gateway. Parameters of the new media gateway can coincide with parameters of the current media gateway. 5.12.2.2.2 Signaling gatew ay 5.12.2.2.2.1 Add a signaling gatew ay You can easily add records referring to the signaling gateway using the Add a signaling gateway wizard. Step 1. Add SCTP endpoints, SP, SG Select one of the existing local SCTP endpoints from the dropdown list * Local SCTP endpoint (in this case you won't need to specify the parameters of the group Local SCTP endpoint).To create a new local SCTP endpoint select the option New. The group of parameters Local SCTP endpoint * Address - the address of the local SCTP-association endpoint. * Port - the port of the local SCTP-association endpoint. The group of parameters Remote SCTP endpoint Page 181 Operating TM * Address - the address of the remote SCTP-association endpoint. * Port - the port of the remote SCTP-association endpoint. * Role defines which of the parties will establish the association. If you select Client, the association will be established by the local signaling process (ASP or LIPSP). If you select Server, then the local signaling process (ASP or LIPSP) will wait for the establishment of the association. Select the work scheme from the dropdown list * Schema. Available values: ASP/SGP; IPSP/IPSP. In case this node already has a signaling gateway (for example, with the schema ASP/SGP), then it will not be possible to add another signaling gateway with a different schema (in this example - with IPSP/ IPSP). To be able to do that, delete all signaling gateways created for this node. ASP identifier - value of the parameter ASP Identifier is used in the ASPUP message. Value range – 11000. Select the checkbox * Send DAUD messages with one point code, if it is necessary to send DAUD messages for each audited signaling point. If the checkbox is not selected, the System will send only one DAUD message with several signaling point codes. The parameter is displayed, if the ASP/SGP work scheme is selected. * Heart beat interval, ms - interval at which the heart beat packets are sent between the local and remote SCTP endpoints in order to support the association, in milliseconds. After you finish the settings, press Next to proceed to the next step. Step 2. Add routing contexts and AS The group of parameters Routing context Routing context value - Routing Context value of the AS identifier. Value range – 0 - 4294967295. If the value is not specified, Routing Context will not be inserted into the DATA messages. Such configuration is correct only if the association, which the Routing Context is referring to, will be used by the AS with the same Routing Context. Select the checkbox Dynamic registration, if it is necessary to receive the Routing Context value of the gateway with the help of Dynamic registration Routing Key. You don't need to specify the protocol value of Routing Context. If the gateway does not support this procedure, the AS will not be activated. Select one of the existing application servers from the dropdown list * Application server (AS). In order to create a new application server on the next step, select the option New. Page 182 Operating TM Select one of the existing SS7 networks from the dropdown list * SS7 network. To create a new SS7 network select the option New. The group of parameters New SS7 network is displayed, if you selected the option New in the parameter SS7 network. * Network name - the name of the network; * Network indicator - the indicator of the network . The group of parameters Network appearance is displayed if you selected the scheme ASP/SGP on the previous step. Network appearance value - Network Appearance value of SS7 network identifier. Value range – 0 4294967295. When done, press Next to proceed to the next step. Step 3. Add routing key's elements lists In case you select the IPSP/IPSP scheme the dialog window will be the following: Select the identifier of the earlier created local node from the dropdown list * Local node ID (see the section Local nodes 201 ). In order to create a new node, select the option New. The group of parameters New local node * Signaling point code (SPC) - signaling point code. * Domain - the type of the node scheme. IP - IPSP scheme; SS7 - ASP/SGP scheme. Select the identifier of the earlier created remote node from the dropdown list * Remote node ID (see the section Remote nodes 201 ). Select the option New to create a new node. The group of parameters New remote node is displayed, if you selected the option New in the parameter Remote node ID. * Signaling point code (SPC) - signaling point code. Select the node scheme type from the dropdown list * Domain: IP (IPSP) or SS7 (ASP/SGP). Page 183 Operating TM In case you select the ASP/SGP scheme the dialog window will be the following: Select the identifier of the earlier created local node from the dropdown list * Local node ID (see the section Local nodes 201 ). To create a new node select the option New. The group of parameters New local node is displayed, if the value New is selected in the parameter Local node ID. * Signaling point code (SPC) - signaling point code. Select the node scheme type from the dropdown list * Domain: IP (IPSP) or SS7 (ASP/SGP). In the list Remote nodes you can add names of remote nodes. See the pattern and available remote nodes in the corresponding fields above. To add nodes to the configuration, press Save routing key's elements list. To create the new application server AS, press Back. The System will proceed to the step 2. To view the final configuration, press Show configuration. The System will proceed to the step 4. Step 4. New signaling gateway configuration On this step the System displays the final configuration of the signaling gateway. To save this configuration, press Activate. Page 184 Operating TM 5.12.2.2.2.2 Edit a signaling gatew ay You can easily edit records referring to the signaling gateway using the Edit a signaling gateway wizard. Step 1. Select a signaling gateway by a remote SCTP endpoint From the dropdown list * Remote SCTP endpoint select a remote SCTP endpoint, associated with the edited signaling gateway. The edited signaling gateway will be displayed in the group of parameters Selected signaling gateway configuration. To proceed to the next step, press Next. Step 2. Editing of the SCTP endpoints configuration In the group of parameters Local SCTP endpoint (in the fields Address and Port) enter the respective values of the local SCTP endpoint. In the group of parameters Remote SCTP endpoint (in the fields Address and Port) enter the respective values of the remote SCTP endpoint. To proceed to the next step, press Next. Step 3. Select the pair of routing context and application server for editing Page 185 Operating TM From the dropdown list * Routing context select the Routing context and the corresponding AS, subject to editing. Parameters of the edited AS will be displayed in the field AS configuration. To proceed to the next step, press Next. To view the final configuration, press Show configuration. The System will proceed to the step 6. Step 4. Editing of the routing context and network appearance parameters The fields Routing context value and Network appearance value are described in Add a signaling gateway 182 . To proceed to the next step, press Next. To view the final configuration, press Show current configuration. The System will proceed to the step 6. Step 5. Editing of the list of routing key elements Page 186 Operating TM Select the set of routing key elements from the dropdown list Routing key's elements list. To add new elements, select the option New. When selecting the already existing set, the System will automatically adjust the settings of other fields to the parameters of the set. Select the checkbox Delete selected routing key's elements list, if you need to delete the set of elements of routing keys. The parameter is displayed, if the existing set is selected Routing key's elements list. Select the identifier of the earlier created local node * Local node ID from the dropdown list (see the section Local nodes 201 ). To create a new node, select the option New. The group of parameters New local node * Signaling point code (SPC) - signaling point code. Select the node scheme type from the dropdown list * Domain: IP (IPSP) or SS7 (ASP/SGP). In the list Remote nodes you can add names of remote nodes. See the pattern and available remote nodes in the corresponding fields above. To save the modified configuration, press Apply changes. To return to the step 3, press Go to selecting of the pair of routing context and AS. To view the final configuration, press Show current signaling gateway's configuration. The System will proceed to the step 6. Step 6. Changes in the signaling gateway configuration On this step the System displays old and new configuration of the signaling gateway. To return to the step 3, press Go to selecting of the pair of the routing context and AS. To save the configuration, press Activate. 5.12.2.2.2.3 Delete a signaling gatew ay You can easily delete records referring to the signaling gateway using the Delete signaling gateway wizard. Step 1. Select a signaling gateway by a remote SCTP endpoint Page 187 Operating TM From the dropdown list * Remote SCTP endpoint select the remote SCTP endpoint, according to which the signaling gateway will be selected. Configuration of this signaling gateway will be deleted. Select the checkbox Delete a local SCTP endpoint, if it is also necessary to delete the local SCTP endpoint. If the checkbox is selected, the group of fields Local SCTP endpoint, which contains the information about the deleted endpoint, will be displayed. Select the checkbox Delete a local signaling process (SP), if it is also necessary to delete the local signaling process. If the checkbox is selected, the group of fields Local signaling process (SP), which contains the information about the deleted local signaling process, will be displayed. When done, press Next to proceed to the next step. Step 2. Deleted objects On this step the System displays all deleted objects and their parameters. To confirm the deletion, press Delete. 5.12.2.2.3 Media gatew ay 5.12.2.2.3.1 Add media gatew ay You can add all records, referring to the media gateway, from one window with the help of the Add a media gateway wizard. Page 188 Operating TM Name - the name of the media gateway. Description - description of the media gateway. Select the existing local MGCP instance from the dropdown list * MGCP local Instance. To create a new instance, select the option New. The group of parameters New MGCP local Instance is displayed, if the option New was selected in the parameter MGCP local Instance. * Address - the IP-address of the SS7 node, which will be used for receiving and sending of MGCPmessages in the IP-network. * Port - the IP-port of the SS7 node, which will be used for receiving and sending of MGCP-messages in the IP-network. Default value - 2727. * Max. MGCP transaction life time - transaction life time, upon the end of which the transaction is considered unsuccessful and therefore ends, in milliseconds. Default value – 20000. Values range – 1000 - 60000. * Initial response timeout - the initial period for messages forwarding, in milliseconds. Default value – 200. Values range – 100 - 500. * Long transaction response timeout - the period for messages forwarding, in milliseconds (used when the media gateway received the message from TS and is processing it). Default value – 400. Values range – 100 - 10000. * Max. repeat interval - the maximum period of messages forwarding in milliseconds. Default value – 4000. Values range – 1000 - 10000. * Max repeat attempts - the maximum amount of messages forwarding procedures. Upon reaching this amount the transaction is considered to be unsuccessful and this message is not forwarded. Default value – 200. Values range – 5 - 1000. Select the checkbox * Ignore packets from unknown media gateways, if it is necessary to ignore MGCP-packets from the media gateways, which were not configured in the System. Select the checkbox * On CRXC OK message terminate AUEP transaction, if it is necessary to ignore Page 189 Operating TM the results of the audit transaction after the call was sent over the audited trunk. The group of parameters New media gateway * Address - the IP-address of the media gateway. * Port - the port of the media gateway. * Transaction ID range start - the lower border of the value range for the identifiers which can be given to the MGCP transactions, sent by the SS7 node to the media gateway. Default value – 2000. Values range – 1 - 999999999. * Transaction ID range end - the upper border of the value range for the identifiers which can be given to the MGCP transactions, sent by the SS7 node to the media gateway. Default value – 999999999. Values range – 1 - 999999999. * Use fax package - use the fax package according to RFC 5347. Select the checkbox * Set Echo control device bit in IAM/ACM/CON/CPG, if it is necessary to include the parameter Echo control device in the outgoing messages IAM, ACM, CPG and CON. Configure this parameter the same way you configured it on the media gateway. * Allow multiple MGCP audits in one UDP packet - select Yes, if it is necessary to send several MGCP audits in a single UDP-packet. * Interval between MGCP audits - the interval between audits of MGCP endpoints. The default value is 5000 milliseconds. * Max. UDP packet size - the maximum length of the UDP-packet, used in the MGCP-messages. The group of parameters MGCP endpoint name patterns MGCP endpoint name new pattern contains the list of templates for the names of the MGCP endpoints. To add a new template, press the button . To delete a template, press . After you press the button Add, the System will display the result. Page 190 Operating TM 5.12.2.2.3.2 Edit media gatew ay You can easily modify the media gateway settings with the help of the Edit a media gateway wizard. Step 1. Select a media gateway Select one of the existing media gateways for editing from the dropdown list * Media gateway address. When done, press Next to proceed to the next step. Step 2. Edit a media gateway On this step you can edit the media gateway parameters. The edited parameters are similar to the parameters on the page Add a media gateway wizard (see the section Add a media gateway 188 ). To apply the changes, press the button Submit. 5.12.2.2.3.3 Delete media gatew ay You can easily delete a media gateway and corresponding records with the help of the Delete media gateway wizard. Step 1. Select a media gateway Select the existing media gateway for deleting from the dropdown list * Media gateway address. Step 2. Dependent data Page 191 Operating TM Select the checkbox Delete associated with media gateway MGCP endpoints patterns, if you need to delete templates of the MGCP endpoints, associated with the deleted media gateway. After you select the checkbox, the parameter MGCP endpoints patterns will appear. In the field MGCP endpoints patterns specify the list of deleted templates for the names of the MGCP endpoints. To add a template to the list, select its name in the left dialog window and press the button . To delete the template from the list select its name in the right window and press the button . You can move all records from the right window to the left window and vice versa with the help of the buttons and . Order of records in the list does not matter. To apply the changes, press the button Submit. 5.12.2.2.4 Station 5.12.2.2.4.1 Add a station With the help of the Add a station wizard you can connect the local and remote signaling nodes. Page 192 Operating TM The wizard parameters correspond to the parameters of the table ISUP connections (see the section ISUP connections 207 ). After you finish the settings, press the button Create a station. Page 193 Operating TM 5.12.2.2.4.2 Delete a station With the help of the Delete a station wizard you can easily delete a station, in other words, a connection between local and remote signaling nodes. Select the earlier created ISUP connection for deletion from the dropdown list * ISUP connection. To view the result of the deletion on the next step, press the button Delete. 5.12.2.2.5 Trunk 5.12.2.2.5.1 Add trunk The Add a trunk wizard allows you to facilitate the setting of the E1 trunks. Page 194 Operating TM Step 1. Select the trunk type Select the trunk type from the dropdown list. Available values: E1; STM-1. Trunk number - the number given to the added E1 trunk (next after the number of the newest E1 trunk on the SS7 node). The parameter is displayed, if the option E1 is selected in the parameter Type. Start number of a virtual trunk - the start number of the virtual trunk. The parameter is displayed, if the option STM-1 was selected in the parameter Type. After you finish the settings, press the button Next to proceed to the next step. Step 2. Setting up a new trunk Select the checkbox Enable to enable all media trunks. If the media trunk is disabled, the corresponding record will be added after the wizard finishes its work. Note that the wizard will not create those media trunks which were disabled. Start CIC - specify the number of the first media trunk in the E1 trunk (the number of the last CIC of the newest Е1 trunk + 2). Disabled timeslot - specify the number of the disabled timeslot in the E1 trunk (by default - 16). Select the SS7 zone of the media trunk from the dropdown list SS7 zone. Select the ISUP connection, associated with this trunk, from the dropdown list ISUP Connection. The parameter CIC direction (pattern) defines for which media stream this trunk will be used. Available values: both (this value is missing, if the parameter CIC hunting policy has the value ITU method in the Page 195 Operating TM ISUP connection created earlier) First part - In, second - Out First part - Out, second - In Even - In, Odd - Out Even - Out, Odd - In From the dropdown list Media gateway address select the media gateway, to which the trunk is connected. From the dropdown list MGCP endpoint name pattern select the template for the names of MGCP endpoints. Current settings of the media trunks are displayed in the table New trunk configuration. For STM-1 trunks it is possible to filter the table with the filtering condition the current number of the virtual trunk, specified in the corresponding parameter (Current number of virtual trunk). With the help of this table you can edit the settings of each media trunk. To apply the specified settings to the media trunks, press the button Apply settings for current trunk. If the STM-1 trunks are used, the settings are applied to the trunk, which is selected in the parameter Current number of virtual trunk. To save the settings from the table New trunk configuration and to finish the wizard operation, press the button Save trunk with current settings. 5.12.2.2.5.2 Delete trunk The Delete trunk wizard facilitates the process of deletion of the E1 trunks. From the dropdown list * Type select the type of the trunk subject to deletion. Available values: E1 STM-1 * Trunk - the number of the trunk subject to deletion. The parameter is displayed, if the option E1 is selected in the field Type. * Starting virtual trunk for removal - the start number of the deleted trunk. The System will delete all the trunks, starting with this number. The parameter is displayed, if the option STM-1 was selected in the field Type. The names of the media trunks for deletion will be displayed in the field List of timeslots. To delete the trunks, press the Delete. To view the result of deletion on the next step, press the button Delete. Page 196 Operating TM 5.12.2.3 M3UA We recommend you read the RFC 4666 standard bef ore you start "M3UA" section. 5.12.2.3.1 SCTP endpoints The table contains the records of the SCTP-association endpoints. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: From the dropdown list *Type select the endpoint type referring to the System: Local or Remote. In the fields *Address and *Port enter the address (or the list of addresses) and the port of the SCTPassociation endpoint. After you specified all the necessary information, press OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.2 Associations Records in this table describe SCTP-associations (connection) between local (ASP) and remote (SGP) signaling processes. Only one SCTP association is sup p orted between a p air of SPs. To add a new record, select Add in the popup menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: The fields Role and Heart beat interval, ms are described in Add a signaling gateway 182 . Remote endpoint ID - the identifier of the remote SCTP-association endpoint (described in the table SCTP endpoints). Modification of this parameter may result in disconnection of active calls; Local endpoint ID - the identifier of the local SCTP-association endpoint (described in the table SCTP endpoints). Modification of this parameter may result in disconnection of active calls; Remote signaling process ID - the identifier of the remote signaling process (SGP), described in the table Signaling processes (SP), with which the association is established. Modification of this parameter may result in disconnection of active calls. Local signaling process ID - the identifier of the local signaling process (ASP), described in the table Signaling processes (SP), with which the association is established. Modification of this parameter may result in disconnection of active calls. After you specified all the necessary information, press the button OK. The record with ID will be Page 197 Operating TM added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.3 Signaling processes (SP) This table describes the local and remote signaling processes. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: From the dropdown list *Type select the type of the signaling process: Local or Remote. From the dropdown list * Role select on of the values: ASP or IPSP (displayed, if *Type->Local); SGP or IPSP (displayed, if *Type->Remote). If *Type->Local, the parameter ASP Identifier will be displayed (the field is described in Add a signaling gateway 182 ). If *Type->Remote and Role->SGP, the parameter Signaling gateway ID, with contains the identifier of the signaling gateway, to which this process belongs. Modification of this parameter may result in disconnection of active calls. After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the pop-up menu. 5.12.2.3.4 Signaling gatew ays (SG) The table describes the signaling gateway (SG), which is located on the border of IP and SS7 networks and due to which the signaling is transferred from one network to another. To add a new record, select Add in the pop-up menu. In the dialog window if it is necessary select the checkbox Send DAUD message with one point code (the field is described in Add a signaling gateway 182 ). After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the pop-up menu. Page 198 Operating TM 5.12.2.3.5 Routing contexts The table describes the unique identifier of the routing key, which is used when the traffic from one signaling gateway is transferred to several application servers. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: The fields Routing context value and * Dynamic registration are described in Add a signaling gateway 182 . The parameter* Routing context direction is used for IPSP configuration. The parameter allows to define the direction of this Routing context. Possible values: both - IPSP Single Exchange mode (by default); outgoing - IPSP Double Exchange mode. Routing Context functions in the direction of remote IPSP; incoming - IPSP Double Exchange mode. Routing Context functions in the direction of local IPSP; Modification of this parameter may result in disconnection of active calls. Association ID - the association identifier (described in section Associations parameter may result in disconnection of active calls. 197 ). Modification of this Application server ID - the identifier of the application server (described in section Application servers (AS) 199 ). Modification of this parameter may result in disconnection of active calls. After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the pop-up menu. 5.12.2.3.6 Application servers (AS) The table describes the Application Server (AS), logical object, which corresponds to the Routing Key. The Application server contains a Application Server Process (ASP), which transfers signaling from one network to another. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: SS7 network - SS7 network identifier (described in section SS7 networks 202 Routing key ID - Routing Key identifier (described in section Routing keys ). 200 ). After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popPage 199 Operating TM up menu. 5.12.2.3.7 Routing keys The table describes Routing keys. The routing key is a filter (a set of parameters). The filter defines which AS the signaling traffic belongs to. To add a new record, select Add in the pop-up menu. In the dialog window in the field Application server ID specify the identifier of the Application server (described in section Application servers (AS) 199 ). After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.8 Routing key's elements list The table describes the elements of the routing keys (the parameters of the Routing key filter). Modification of the records in the table may result in disconnection of active calls. Adding a new record does not cause disconnection of calls. To add a new record, select Add in the pop-up menu. Specify the following information in the dialog window: Routing key ID - the identifier of the Routing Key (described in section Routing keys Local node ID - the identifier of the local node (described in section Local nodes 201 200 ). ). After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.9 Remote node's elements list The table contains the data on the objects, which present the connection between the routing keys and remote nodes (signaling points). Page 200 Operating TM To add a new record, select Add in the pop-up menu. Specify the following information in the dialog window: Routing key's elements list ID - the identifier of the list of routing keys elements (described in section Routing keys elements list 200 ). Remote node ID - the identifier of the remote signaling point (described in section Remote nodes 201 ). After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.10 Local nodes The table describes the local signaling points. To add a new record, select Add in the pop-up menu. Specify the following information in the dialog window: SS7 network - the SS7 network to which the node belongs. Signaling point code (SPC) - the signaling point code. Select the node scheme type from the dropdown list * Domain: IP (IPSP) or SS7 (ASP/SGP). After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.11 Remote nodes The table describes the remote point codes. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: SS7 network - the SS7 network, to which the node belongs. Signaling point code (SPC) - the signaling point code. Select the node scheme type from the dropdown list * Domain: IP (IPSP) or SS7 (ASP/SGP). Page 201 Operating TM After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the pop-up menu. 5.12.2.3.12 Netw ork appearance The table describes the «network presentation». It also presents the SS7 network identifier, which in combination with the code of the destination point defines to which SS7 network the node belongs. This identifier is used when the traffic, which belongs to different SS7 networks, is sent over a single SCTP-association between the Application server (AS) and the gateway (SG). To add a new record, select Add in the pop-up menu. Specify the following information in the dialog window: Signaling gateway ID - the identifier of the signaling gateway (described in section Signaling gateways (SG) 198 ). SS7 network - the SS7 network, to which the Network appearance belongs; Application server ID - the identifier of the Application server (described in section Application servers (AS) 199 ). The field Network appearance value is described in Add a signaling gateway 183 . After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.13 SS7 netw orks The table describes the SS7 network. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: * Network name - any network name; From the dropdown list * Network indicator select the necessary value. 0-International Page 202 Operating TM 1-Reserved 2-National 3-National spare After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.3.14 M3UA configuration General parameters of the M3UA configuration are displayed on this page. There can be only one record of the M3UA node configuration. The required fields are marked with an asterisk "*". * Destination audit period - the interval at which the DAUD message is sent by the remote signaling point. The DAUD message is sent to each signaling point successively, in milliseconds. * Retransmit attempts interval - the interval between attempts to send an M3UA message, in milliseconds. * Retransmit attempts number - the amount of attempts to send an M3UA message. Select the checkbox * Mark state of PC+SSN after receiving M3UA SSNM, if you need to mark the states PC+SSN for all signaling gateways upon receiving of SSNM messages. * Behavior in absence of ASPUP_ACK - the reaction to the absence of an ASPUP_ACK message from the signaling gateway. Possible values: Ignore Restart retransmit procedure of ASPUP messages Restart the association After you specified all the necessary information, press the button OK. The record with ID will be added to the table. When you add a new M3UA node, two records are added automatically: the record with the def ault set of ISUP-timers and the one with the def ault M3UA node conf iguration. 5.12.2.4 MGCP We recommend you read the RFC 3435 standard bef ore you start "MGCP" section. Page 203 Operating TM 5.12.2.4.1 MGCP endpoints The table describes MGCP endpoints. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: From the dropdown list MGCP endpoint name pattern select the template for names of the MGCP endpoints (described in the section MGCP endpoints groups 204 ). Media gateway address - the address of the media gateway in the format: IP:port. Modification of this parameter may result in disconnection of active calls. Circuit ID - the ISUP-circuit identifier (section Circuits 210 ), corresponding to this MGCP endpoint. * ${gr_level1} value in MGCP endpoint name pattern - the value of the variable ${gr_level1}, which may be added in the template of the MGCP endpoints group name; * ${gr_level2} value in MGCP endpoint name pattern - the value of the variable ${gr_level2}, which may be added in the template of the MGCP endpoints group name; ${gr_level3} value in MGCP endpoint name pattern - the value of the variable ${gr_level3}, which may be added in the template of the MGCP endpoints group name; ${gr_level4} value in MGCP endpoint name pattern - the value of the variable ${gr_level4}, which may be added in the template of the MGCP endpoints group name; ${gr_level5} value in MGCP endpoint name pattern - the value of the variable ${gr_level5}, which may be added in the template of the MGCP endpoints group name. After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.4.2 MGCP endpoints groups The table contains the name templates for the MGCP endpoints. Page 204 Operating TM To add a new record, select Add in the pop-up menu. In the dialog window in the field * MGCP endpoint name pattern enter a line defining allowable names of the MGCP endpoints on this media gateway. You can use the following variables in the template: ${gr_level1}, .., ${gr_level5} - values of these variables are taken from the parameters value of the variable <name of the variable> in the MGCP endpoints group template. [mgw_ip_address] - IP-address of the media gateway. After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the pop-up menu. 5.12.2.4.3 Media gatew ays The table contains the settings of the media gateways. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: Name; Description; * Address; * Port; MGCP local Instance address; * Transaction ID range start; * Transaction ID range end; * Use fax package; * Set Echo control device bit in IAM/ACM/CON/CPG; Page 205 Operating TM * Allow multiple MGCP audits in one UDP packet; * Interval between MGCP audits; * Max. UDP packet size; The above-mentioned fields are described in Add media gateway 188 . After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.4.4 MGCP local instances The table contains the settings of the MGCP subsystem, which functions within the SS7 node. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: * Address; * Port; * Max. MGCP transaction life time; * Initial response timeout; * Long transaction response timeout; * Max. repeat interval; * Max repeat attempts; * Ignore packets from unknown media gateways; * On CRXC OK message terminate AUEP transaction; The above-mentioned fields are described in Add media gateway 188 . After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. Page 206 Operating TM 5.12.2.5 ISUP/Call Control 5.12.2.5.1 Timers The table defines the lists of timers settings. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: Description - the timers settings description. * T1 ... T39 - ISUP-timers. Names and purpose of the timers fully correspond to Q.764 Table A.1. T35 is used to wait until a ST or F signal (end of dialing) of DST number is received in SAM (Subsequent Address message) if it hasn't been received in IAM (Initial Address Message). Incoming call is processed only when T35 expires. T35 is defined as 0-20 seconds (in ITU Q.764 as 15-20 seconds) so that calls from the routes with no end-of-dialing signal in IAM in DST number will not be delayed. If T35=0, incoming call is processed immediately after IAM is received. We recommend you use T35=0 for ISUP-connections with no SAM message. * M3UA response timeout - M3UA response timeout. The SS7 node can't be started unless the response is received. After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. 5.12.2.5.2 ISUP Connections The table describes connections to the remote SS7 switch. The connections consist of several E1 lines. Page 207 Operating TM To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: Local node ID - the local node identifier (described in the section Local nodes 201 ). Remote node ID - the remote node identifier (described in the section Remote nodes 201 ). From the dropdown list Timer configuration select the set of timer settings, which should be applied to this circuit. From the dropdown list * Type of initial blocking of circuits select the type of initial blocking of the circuits: Maintenance oriented Hardware oriented Select the checkbox * Reset circuits when destination point code become available, if it is necessary to reset the circuits whenever the remote signaling point is available. From the dropdown list * On the arrival of an incoming message on unequipped circuits select the reaction of the SS7 node to the arrival of the message at the circuit, which was not configured in the System. Available values: Ignore Responding with the message UCIC * Call rejection ratio, congestion level 1 - the percentage of calls rejected at level congestion 1. The value should be less than the value of * Call rejection ratio, congestion level 2. * Call rejection ratio, congestion level 2 - the percentage of calls rejected at level congestion 2. * BLO/CGB procedure timeout - the period, upon the the expiration of which the retransmitting of BLO/CGB messages ends if there is no response from the remote SS7 switch. Default value – 3600000. The value range – 300000 – 60000000. The value should be equal to or exceed the value of timer T19. Modification of the parameter does not cause disconnection of the active calls. * UBL/CGU procedure timeout - the period, upon the the expiration of which the retransmitting of UBL/CGU messages ends if there is no response from the remote SS7 switch. Default value – 3600000. The value range – 300000 – 60000000. The value should be equal to or exceed the value of timer T21. Modification of the parameter does not cause disconnection of the active calls. * RSC procedure timeout - the period, upon the the expiration of which the retransmitting of RSC messages ends if there is no response from the remote SS7 switch. Default value – 3600000. The value range – 300000 – 60000000. The value should be equal to or exceed the value of timer T17. Modification of the parameter does not cause disconnection of the active calls. * GRS procedure timeout - the period, upon the the expiration of which the retransmitting of GRS messages ends if there is no response from the remote SS7 switch. Default value – 3600000. The value range – 300000 – 60000000. The value should be equal to or exceed the value of timer T23. Page 208 Operating TM Modification of the parameter does not cause disconnection of the active calls. * Early ACM timeout - the period, upon the the expiration of which the ACM response to the incoming call will be generated automatically, if no PROGRESS messages were received from the terminating device. * ISUP national standard - select the applied ISUP national standard. Available values: ITU FICORA (for more information refer to Support of SS7 national standards of Finland 210 ). * CIC hunting policy - the method of searching for available media circuit for outgoing call and serves for lowering the risk of dual seizure. Available values: o Increase - sequential selection in cic descending order, starting from the end of the list (by default). o Decrease - sequential selection in cic descending order, starting from the end of the list. o ITU method - ITUMethod2, see the clause 2.9.1.3 in Q.764. o Random - random selection. o Cyclic - cyclic selection in ascending order. * Transmission Medium Requirement - the required transmission medium. Available values: speech 3.1 kHz Select the checkbox * Add end of pulsing, if it is necessary to add a character which terminates the number dialing. Select the checkbox * Do automatic redial, if it is necessary to redial according to Q.764 p.2.8.1. Select the checkbox * Allow calls without CgPN, if it is necessary to allow calls with no calling number. Select the checkbox * Ask for missing CgPN, if it is necessary to request the missing calling number. * Cause origin location value - the value of the parameter CauseLocation, which will be inserted in the sent REL messages. The values are defined according to Q.850: 0 - User, 1 - LPN, 2 - LN, 3 - TN, 4 RLN, 5 - RPN, 7 - INTL, 10 - BI. Default value - 4. The value range - 0-10. Select the checkbox * Reset circuits on start, if it is necessary to reset the state of the media circuits, when the remote SS7 switch is available for the first time. Modification of the parameter does not cause disconnection of the active calls. Select the checkbox * Block circuits on start, if it is necessary to block the media circuits when starting the ISUP subsystem. Once the subsystem is started the circuits will be unblocked automatically. Select the checkbox * Maintenance blocking of circuits on start, if it is necessary to block circuits according to the type maintenance oriented when starting the ISUP system. The circuits should be unblocked manually through the web-interface. This parameter takes priority over the parameter * Block circuits on start. Select the checkbox * Wait for DLCX procedure completion, if the node should not be started until the DLCX transaction is over (until the ISUP connection is deleted). Select the checkbox * Reset circuits when AS is active, if it is necessary to reset the state of the media circuits when the application server is activated. Select the checkbox * Activate SS7 zone when PC is available, if it is necessary to activate the SS7 zone when the remote signaling point is available. After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the popup menu. Page 209 Operating TM 5.12.2.5.3 Circuits The table describes the media circuits in the ISUP-connection. To add a new record, select Add in the pop-up menu. Specify the following information (the required fields are marked with an asterisk "*") in the dialog window: * Circuit identification code (CIC) - the circuit identifier. The parameter * CIC direction defines for which media stream the circuit will be used. Available values: incoming - incoming media stream. outgoing - outgoing media stream. both - incoming and outgoing media streams. SS7 zone - the SS7 zone. ISUP connection ID - the ISUP-connection identifier, to which the media circuit belongs. MGCP endpoint name - the name of the MGCP endpoint described in the section MGCP endpoints 204 . After you specified all the necessary information, press the button OK. The record with ID will be added to the table. To edit, delete or view the record in a separate window, select the corresponding command in the pop-up menu. 5.13 Support of SS7 national standard of Finland MVTS Pro can process special ISUP messages - Meter Pulse Messages (MPM), used in Finland for call billing. Such messages are processed in SS7 calls (MPM messages) and SIP-I/SIP-T calls (МРМ messages are incapsulated in SIP INFO messages). Due to that, gateways for interoperation according to the finnish standard (Ficora) should be configured differently. See chapters Configuration of SS7 gateway 210 and Configuration of SIP-T/I gateway 211 . Meter Pulse messages are transferred only in the direction from the terminating device to the originating device, that is why there are 3 principles of processing of incoming Meter Pulse messages, which are set in the parameter Meter Pulse message policy (MPM Policy) 76 in the section Dial peers. Pulses are counted in CDRs 5.13.1 105 . The System counts received and sent pulses separately. Configuration of SS7 gateway Operation of any SS7 gateway is mainly defined by adding a ISUP connection 192 . That's why in order to configure an SS7 gateway, add a ISUP connection 192 with ISUP national standard 209 ->FICORA on the SS7 node. Page 210 Operating TM The new ISUP connection shall appear in the settings of the corresponding SS7 node in the folder SS7 Call Agent node configuration 177 . 5.13.2 Configuration of SIP-T/I gateway To configure a SIP-T/I gateway for operation under Ficora is a little more complicated, than for SS7, due to the specificity of operation with IP-networks. You can configure a SIP-T/I gateway for an outgoing call and for an incoming call. 5.13.2.1 Configuration of SIP-T/I gateway for outgoing call To ensure that outgoing call is properly processed under Ficora standard, it is necessary to select ficora in the list Term.SIP-T/I ISUP standard 51 in the settings of the corresponding equipment in section Termination signaling settings. 5.13.2.2 Configuration of SIP-T/I gateway for incoming call When processing the incoming call from a SIP-T/I gateway, it is possible to define under which RTUsupported standard the gateway operates. For that, use the global table ISUP national standards 141 (in the Global settings folder), which contains rules of message identification according to its attributes. Page 211 MVTS Pro Redundancy 6 MVTS Pro Redundancy System redundancy ensures continuous services (or minimum downtime) and correct entry of CDRs for terminated calls. The MVTS Pro system has a modular architecture. Thus MVTS Pro redundancy is achieved by adding redundant nodes to the configuration. The nodes to be backed up: LMN (only one backup node possible). Scripting node (unlimited number of nodes). Signaling node (unlimited number of nodes). Media node (unlimited number of nodes). Balancer node (unlimited number of nodes). SS7 Call Agent node (unlimited number of nodes). Database (only one redundant DB possible). Nodes that can not be backed up: Synchro node. 6.1 Continuous services and correct entry of CDRs To achieve continuity of service in case of a node failure do the following: Back up balancer nodes with the help of a Server Load Balancing (SLB)-capable switch (e.g. CISCO Catalyst 4840G) or a Shared-IP mechanism that allow calls to be redirected to another balancer node. Back up the license management node to avoid complete closedown of the System once 30 minutes passed after the LMN failure. Back up SS7 Call Agent nodes to let a running SS7 Call Agent node process calls previously directed to the failed node. Ensure availability of a full set of other nodes on other servers so that the System could process new calls. The task of entering CDRs into the DB is shared between two node types – a signaling node that terminates the call and a scripting node that stores the CDR. In case the scripting node handling the call crashes, the signaling node sends a command to terminate the call to another scripting node. In case the signaling node crashes, the scripting node detects that the connection to the signaling node has been lost and enters a CDR to the DB. Thus, to ensure correct entry of CDRs the following conditions should be met: The System comprises at least two scripting nodes so that one scripting node is always ready to receive a message about call termination from the signaling node. The database is backed up to be available for CDR entry at all times. 6.2 Two-server redundancy configuration According to this redundancy configuration two servers host a double set on nodes to be backed up. VoIP traffic entry points are backed up using an SLB-capable router or with the help of Shared-IP mechanism (implemented by Linux Heartbeat utility, see section Redundancy using Linux Heartbeat). All SS7 gateways should be connected to at least two SS7 Call Agent nodes on different servers. Page 212 MVTS Pro Redundancy An example of two-server redundancy configuration The advantage of this redundancy configuration is its relative simplicity. The disadvantage is the inability to ensure correct CDR storage in case of hardware failures. To mitigate this problem a interim CDR functionality may be used (see section CDRs 101 ). For example, if call passes through Signaling-1 and Scripting-1 and interim CDRs are disabled, in case of hardware failure of server 1 all data on the call will be complete lost and no CDR will be entered into the DB on this call. 6.3 Four-server redundancy configuration An extended redundancy configuration is designed to ensure correct storage of CDRs in all cases. According to the extended configuration the backed up nodes are hosted on four servers according to the following rules: Signaling nodes and scripting nodes should be hosted on different servers to avoid their simultaneous failure in case the server fails physically. At least two scripting nodes should be hosted on different servers so that the signaling node had at least one scripting node to send a message about call termination in case one scripting node fails. This means that two servers should host signaling nodes, and the other two – scripting nodes. An example of the extended redundancy configuration is shown in the figure below. Page 213 MVTS Pro Redundancy An example of four-server redundancy configuration A disadvantage of this configuration is its cost. 6.4 Control links interval settings To minimize system downtime in case of node failure you should adjust the control link interval settings accordingly. The recommended settings are as follows: link_send_timeout "500"; link_recv_timeout "1000"; link_restore_timeout "1000"; link_reconnect_interval "200"; link_connect_interval "1000"; Consider the control link between two nodes A and B. The System operation is as follows: Node A with the period defined by link_send_timeout sends a keep-alive packet to node B to which it is linked by a control link. Each node (in the example - A) waits for any messages from another node (including keep-alive packets) for the period defined by link_recv_timeout. If after the last message arrival the specified amount of time elapsed and no other messages arrived, the TCP connection with the other node is considered severed. Note during this period node A will store messages, dispatched to B and waiting to be acknowledged by the latter, in its queue. Once the TCP connection is considered severed node A no longer generates and dispatches new messages to B. Once the link_recv_timeout has expired, if the TCP connection is severed a new timeout link_restore_timeout starts, within which with the period defined by link_reconnect_interval node A tries to restore TCP connection to node B. If the link_recv_timeout has expired but the TCP connection was not restored, the control link is considered completely severed and node A start to perform necessary actions in all messages in its queue (e.g. store CDRs, terminate calls, etc). Page 214 MVTS Pro Redundancy If node A did not restore the connection within link_recv_timeout, it tries to establish a TCP connection and a control link from the very start with the period of link_connect_interval. Thus, as it is derived from the abovementioned the link_recv_timeout controls the number of messages dispatched to B when the TCP connection is already severed but is not discovered yet. Beside downtime these intervals also control the validity of dates and times in CDRs. Specifically in case of a control link failure the time of call termination in the CDR will differ from the actual call termination by: Sum of link_recv_timeout and link_restore_timeout (maximum). Value of link_restore_timeout (minimum). 6.5 Node behaviour during crashes 6.5.1 Media Node When one of the media nodes fails, (as MedNode1) the subscribers, whose talk was enabled by the faulty node, will probably (if the workload is large) hear voice distortion for a while (some seconds) or silence in the receiver until the phoenix process automatically restarts the crashed node. The conversation will continue after the MedNode is restarted and its pre-failure state is restored. If the faulty MedNode restart turns out impossible for some reason or there is no access to the server on which the faulty MedNode1 is installed, voice sessions of new arriving calls are established through MedNode2, and the SigNode1 will terminate calls passing through MedNode1 after the timeouts link_recv_timeout and link_restore_timeout expire. Diversion of media flows to healthy media node As soon as MedNode1 is alive again (its serviceability is manifested by a restored link to the SigNode) SigNode1 resumes traffic balancing between MedNode1 and MedNode 2. 6.5.2 Signaling node When a Signaling node fails (as for example SigNode1) all H.323 calls handled by the crashed node get terminated, as well as all non-finalized SIP calls (i.e. calls in the process of being set up or a change of state). Established SIP calls are saved and restored, when the SigNode recovers. The calls that could not be restored get terminated correctly. Page 215 MVTS Pro Redundancy Reassignment of new call arrivals after SigNode1 fails All new arriving calls will be forwarded to SN2 while SN1 remains inoperative. As soon as SN1 resumes functioning, the balancer nodes BN1 and BN2 will again include the SigNodes SN1 and SN2 in load balancing. If the automatic restart fails or there is no network access to the server hosting SigNode1, then after the expiry of link_recv_timeout and link_restore_timeout the media node will stop passing media for calls controlled by the SigNode1 and the scripting node will enter a CDR into the Inaccurate table. For the SIP calls no BYE message will be sent. 6.5.3 Scripting node If the automatic restart fails or there is no network access to the server hosting SigNode1, then the already established call will remain and after their normal termination another scripting will enter a CDR on them into the Inaccurate table. But if interim CDRs is enabled, the calls will be terminated as soon as the System tries to write down an interim CDR. 6.5.4 Balancer node If one of the balancer node fails, all H.323 calls, set up through the faulty node, will be terminated, and all SIP/H.323 registration data, associated with this balancer node, will be lost. If the automatic restart fails or there is no network access to the server hosting the scripting node, then the H.323 calls will be correctly terminated and CDRs on them will be written into the DB. Balancer node failure does not affect the SIP calls, established using the 302 message. For SIP call, established without 302 message, the signaling transmission will stop, as a result the call may be terminated only after the expiry of the media timeout, if its is configured (gateway parameters Orig. RTP timeout and Term. RTP timeout), or if the maximum call duration is exceeded. In any case a normal CDR will be written down for such calls. 6.5.5 SS7 Call Agent node Upon the failure of a SS7 Call Agent node all calls passing through it will be terminated. Page 216 MVTS Pro Redundancy 6.5.6 Synchro node SyncNode serves to keep record of the equipment capacity. There may be only one SyncNode in each System, and it requires no backups. If the SyncNode fails, all set-up calls continue and the System accepts newly arriving calls, though without regard to the existing origination and termination equipment capacity limitations. 6.5.7 Database Due to the architecture of MVTS Pro the database node is not crucial and its crash does not affect the overall System operation. In case the DB crashes, the System continues to handle calls using the information from the latest DB update. The CDRs will be saved into temporary files and then automatically restored to the DB. To increase System solidity you can also use DB redundancy. In this case configure the redundant DB settings (parameters of type dbms_*_slave) and configure DB replication (see section DB replication 240 ). In this case if the man DB fails, the scripting node switches to the failover DB until the connection to the main DB is restored. CDRs will be stored in the failover DB. The System will repeatedly try to restore the connection to the main DB. When the connection to the main DB is restored, the scripting node switches to the main DB. 6.6 License Management node redundancy The LMN serves for software license management (that is it reads the USB dongle) and for disseminates configuration data among other MVTS Pro nodes. When the System starts, the LMN is the first module launched. As other nodes start up, they connect to the LMN and receive configuration files. LMN redundancy is achieved by adding a stand-by LMN with a copy of the USB dongle. Thus a configuration with a primary and failover LMN requires the following sample phoenix.conf files: Examp le of phoenix.conf conf iguration f ile on the p rimary server: management primary=192.168.132.1:9000 backup=122.168.132.2:9001 phoenix address=127.0.0.1:5000 timeout=7000 count=5 sleep=2000 statestore db=phoenix.db trafficlog=traffic.log load type=management name=management-1 mode=main ... This example illustrates that the main LMN with the name SYSTEM-1 runs on the server with IPaddress 192.168.132.1:9000, while the system with IP 192.168.132.2:9500 hosts the failover LMN. Dep loyment of the main and f ailover LMNs on the same host is not allowed! You can display the name of the System’s LMN by carrying out the “show status” (“sh st”) command in the console terminal. Failover and failback events in the System with Management Node redundancy unfold as follows: 1. When the System starts, the primary LMN is the first to start up. The main USB dongle should be inserted into the server beforehand. 2. The failover LMN starts on the failover server with the duplicate USB dongle inserted. Once started the failover LMN establishes a link with the primary LMN and switches to standby operation where it does not interoperate with other functional nodes and does not read the USB dongle. 3. If the main LMN fails (the System alerts the operator to the event by an e-mail notification), the failover LMN switches to “active” mode which means: It reads the USB dongle. It accepts connections from other nodes of the System. It performs periodic checks if the link to the primary LMN server is restored. Page 217 MVTS Pro Redundancy 4. All functional nodes of the System switch to interoperation with the failover LMN within 60 seconds. Meanwhile all set-up connections are preserved and newly arriving calls are processed. 5. Once the main LMN is alive again (this indicated by restored accessibility of the primary server), the failover LMN restores the link with the main LMN, stops interplay with other System nodes and returns to the standby mode. 6. All System nodes switch to interoperation the main LMN. All set-up connections are preserved and all newly arriving calls are processed. 6.7 SS7 Call Agent node redundancy After any change of settings of the primary SS7 node, the operator should clone the settings of the backup node using the web-interface. Before that, it is necessary to delete the current configuration file of the backup node, and only after that - to clone it. Prior to the removal of the current SS7 node, it is necessary to make a backup copy of it using the procedure Store/ Restore/ Delete node settings (SS7 Call Agent node configuration -> SS7 Call Agent nodes): 6.8 DB and WEB interface server redundnacy Owing to the MVTS Pro architecture specifics the DB unit is not a critical component and its failure does not affect the System overall operation. When the System starts, the ScriptNode reads the entire DB, and further just keeps track of updates. If the DB host fails, the System continues call handling, based on data as of the moment of the DB latest update. CDRs get saved to temporary files and pertinent data are later entered in the DB, when the connection is restored. Debug calls are not saved. To ensure data retention, unattended DB backup may be used. However, to ensure additional reliability the user has an option to configure DB redundancy. To do this, fill in the proper settings for the failover database in the scripting node configuration file (parameters like dbms_*_slave) and set up the DB replication (see DB replication 240 ). In a layout with a redundant DB, if the main DB fails, the scripting node switches over to the failover DB until the connection the main one is restored. CDR records will be entered into the failover DB. Meanwhile, the System will successively try to restore connection to the main DB. When the connection is restored, the scripting node switches over to the main database. 6.9 Configuring pacemaker for TS redundancy schemes For conf iguring redundancy using the p acemaker, both servers should have not less than two p hysical network interf aces. Even if only one of them is used f or op eration of the System, second network interf aces are connected directly or, if the servers are installed on dif f erent stands, through another ethernet switch. For TS redundancy, perform the following actions: 1. Write names of both servers in the directory /etc/hosts and check their response to the hostname command. The primary server is given the name rtu-master, the backup server is given the name rtu-slave; 2. Install pacemaker and expect on both servers: aptitude install pacemaker Page 218 MVTS Pro Redundancy aptitude install expect 3. After the installation, configure corosync. All corosync settings are located in the directory / etc/corosync. Configuration parameters of corosync are located in the file /etc/ corosync/corosync.conf. When editing the configuration file, follow the rules below: Corosync is configured on both physical servers. The global parameter rrp_mode should have the value active. The interface section is written for each physical interface. The following parameters are configured in the section interface: o ringnumber – numerical identifier of the network interface. The parameter should be unique for each interface and start with 0 ringnumber; o bindnetaddr - IP-address, to which corosync is connected. For example, if the address of the local interface is 192.168.5.92, and the subnet mask is 255.255.255.0, then bindnetaddr will be equal to 192.168.5.0; o mcastaddr – broadcast address used by corosync. This value should be different for different interfaces. It should not overlap with any other groups, used in the network. It is not recommended to configure the address 224.x.x.x. o mcastport – number of the UDP-port. For operation, the corosync uses 2 ports mcastport and mcastport-1. Example: rrp_mode: active interface { ringnumber: 0 bindnetaddr: x.x.x.x mcastaddr: 226.94.1.1 mcastport: } interface { ringnumber: bindnetaddr: mcastaddr: mcastport: } 5405 1 y.y.y.y 226.94.1.2 5405 4. Start corosync. For that, perform the following actions: replace the line START=no with START=yes in the file /etc/default/corosync; perform the command invoke-rc.dcorosyncstart on both servers. 5. Install and configure the MVTS Pro according to schemes, specified in the chapter Redundancy scheme with one active node or Redundancy scheme with several active nodes. 6.10 Redundancy scheme with one active node 6.10.1 General information RTU redundancy scheme described in this document is organized according to the principle of high availability cluster (HAcluster), in which the primary server of the cluster (Primaryserver) is duplicated by the backup cluster (HotStandbyserver) and the control over the condition of the server is maintained with the help of the p acemaker. The scheme of the RTU server redundancy specified below shows that all outgoing traffic has the Page 219 MVTS Pro Redundancy same source IP-address no matter which of the two servers of the cluster processes more traffic at the moment. This is provided using a virtual IP-address, migrating from one server of the cluster to another. RTU redundancy scheme according to the high availability cluster is shown below. On the shown scheme: the processes and nodes of the primary servers are marked by index 1 (Primary server) the processes and nodes on the hot standby server are marked by index 2 (HotStandbyserver). TS nodes (processes) on primary and backup servers which are started and stopped with the help of p acemaker are marked by dashed box. TSLocation-primary and TSLocation-standby – network locations, specified in the TS configuration. The cluster management system p acemaker starts nodes when the virtual IP-address is online on the server, and stops when the virtual address disappears. Transfer of the virtual address from one server to another is performed when the connection with servers is broken outside the cluster. Page 220 MVTS Pro Redundancy Physical scheme of cluster 6.10.2 Scheme functioning To use the initial state of this redundancy scheme, the primary and backup servers included in the scheme should be the following: Virtual addresses are online on the primary server (one for the transit switch and one for the subscriber station) and all nodes necessary for processing transit and subscriber traffic are started. here are no virtual IP-addresses on the backup server; nodes, which are started and stopped by the utility p acemaker, are not started, other nodes are connected to the license management node (Licensemanagementnode) of the primary server and function. Events which trigger this redundancy scheme can be: switching off and switching on the primary server; switching off and switching on the backup server; loss and recovery of connection with RTU servers with IP-addresses outside the cluster. The table contains states of the scheme elements during the above-mentioned events, taking into consideration that traffic is processed on the primary server, with the exception of situations when the primary server is off. Event 1. Switching off the primary server State of primary server State of backup server Virtual IP-addresses are online, all nodes are started, traffic is processed. Page 221 MVTS Pro Redundancy All nodes are connected to the license management node on the backup server. 2. Switching on the primary server In case stickness=110: resource- In case resource-stickness=110: Virtual IP-addresses are missing. Nodes under control of pacemaker are not started. Other nodes are started and connected to the license management node on the primary server. Virtual IP-addresses are online, all nodes are started, traffic is processed. All nodes are connected to the license management node on the primary server. In case resource-stickness=0: In case resource-stickness=0: Virtual IP-addresses are Virtual IP-addresses are missing. online, all nodes are started, Nodes under control of pacemaker traffic is processed. are not started. Other nodes are All nodes are connected to started and connected to the license the license management node management node on the primary on the primary server. server. 3. Switching off the backup server No changes in the state. There are records about loss of connection with the nodes of the primary server in the log phoenix.log. 4. Switching on the backup server No changes in the state Virtual IP-addresses are offline, nodes under control of pacemaker are not started. Started nodes are connected to the license management node on the primary server. 5. Switching on the backup server No changes in the state No changes in the state 6. Recovery of direct connection between servers No changes in the state No changes in the state 7. Loss of access of the primary server to external IP-addresses Virtual IP-addresses are missing. Nodes under control of pacemaker are not started. Other nodes are started and connected to the license management node on the primary server. Virtual IP-addresses are online, all nodes are started, traffic is processed. 8. Recovery of access of In case All nodes are connected to the license management node on the primary server. resource- In case resource-stickness=110: Page 222 MVTS Pro Redundancy the primary server to external IP-addresses stickness=110: Virtual IP-addresses are online, all nodes are started, traffic is processed. Virtual IP-addresses are missing. Nodes under control of pacemaker are not started. All nodes are connected to the Other nodes are started and license management node on the primary server. connected to the license management node on the primary server. In case resource-stickness=0: In case resource-stickness=0: Virtual IP-addresses are Virtual IP-addresses are missing. online, all nodes are started, Nodes under control of pacemaker traffic is processed. are not started. Other nodes are All nodes are connected to started and connected to the license the license management node management node on the primary on the primary server. server. According to the test results, actual time of switching to the backup node when the p rimary server is of f is 43 seconds, but the reverse transf er f rom the backup server to the p rimary server takes only 18 seconds. Such dif f erence in time is exp lained by the f act that in case of f ailure of the p rimary server all f unctioning nodes will try to connect to the license management node on the f ailed p rimary server and as these f unctioning nodes have no conf iguration the def ault timeouts with great values will be used. During the reverse transf er f rom the backup server to the main server, the license management node on the p rimary server is already started and that is why there is no additional delay. The above-mentioned time intervals are ap p roximate and in certain versions of the cluster may be dif f erent. 6.10.3 Description of failover protection and scheme restrictions When describing the particularities of the cluster behavior, such definitions as "active" and "inactive server" of the scheme are used. An active server is a cluster server (primary or backup) on which at the moment virtual IP-addresses are online and traffic is processed, i.e. a server which is processing traffic. An inactive server of the cluster is a server with no virtual IP-addresses and no traffic processing. Based on the state when one of the servers is processing traffic and the other one is in constant readiness, the suggested scheme is resistant to the following situations: Switching off the inactive server or loss of connection of the inactive server to the external network. Switching on the server which should become inactive. Switching off the primary server or loss of connection of the active server to the external network (the inactive server becomes active) If the primary server was active, the System is not functioning within 43 seconds. If the backup server was active, the System is not functioning within 16 seconds. When the work load is transferred from the backup server to the primary server or vice versa on condition that both servers are on, the System is not functioning within 16 seconds. Switching on the server which shall become active after switching on. The System is not functioning within 16 seconds. Loss of direct connection between the servers. Hanging of some nodes (restart of nodes by phoenix). Page 223 MVTS Pro Redundancy The above-mentioned time intervals are ap p roximate and in certain versions of the cluster may be dif f erent. The scheme is not resistant to the following situations: Loss of connection from the active server on all interfaces – and between the servers, and to the external network, with further quick recovery, i.e. when the resources haven’t been fully synchronized on both servers – they were started on the inactive server before they were stopped on the active server. Redundancy of SS7 Call agent nodes can't be performed using standard means of TS. Recommendations: If both connections have been lost on any server – on the next server and to the external network, then before the interface connection to the external network it’s better to wait until all the resources controlled by the pacemaker are stopped on this server. Switch to the redundancy scheme active-active. 6.10.4 How to configure scheme The high availability cluster (HAcluster) is configured the following way: 1. Configure functional nodes so that sockets receiving H.323 and SIP-signaling (H.323 and SIP listener) were opened only on virtual IP-addresses. 2. Create identical SS7 configurations of the nodes (ss7-m,ss7-b) in the database: ss7-m uses a static IP-address of the primary server for SCTP-associations and MGCP; ss7-b uses a static IP-address of the backup server for SCTP-associations and MGCP. 3. Set the parameter SCTPHBInterval = 10 (default value is 30) on the SS7 gateway to minimize time of the refusal of SS7. 4. Set the following distribution of the program nodes in balancing groups: mvtspro-group balancer-pro-m balancer-pro-b signaling-pro-m signaling-pro-b scripting-m scripting-b ss7-m ss7-b 5. Set the following distribution of the program nodes among locations: location-m location-b media-m media-b synchro-m synchro-b balancer-pro-m balancer-pro-b signaling-pro-m signaling-pro-b ss7-m ss7-b scripting-m scripting-b 6. Set the following program nodes started upon the System start: Page 224 MVTS Pro Redundancy Primary server Backup server management-m management-b media-m media-b scripting-m scripting-b synchro-m synchro-b balancer-pro-m balancer-pro-b 7. Set the following program nodes started when the dynamic IP-address is online: Primary server Backup server signaling-pro-m ss7-m signaling-pro-b ss7-b 8. To configure cluster on the basis of the pacemaker, perform the following commands on any of the servers: crm configure property stonith-enabled=false crm configure property no-quorum-policy=ignore crm configure rsc_defaults resource-stickiness=110 – the command defines if the resources will be transferred from the backup server to the primary server after the recovery of the primary server. The value 110 is specified if there is no need in transferring the resources. If the value 0 is specified, the resource will be returned to the primary server as soon as it becomes available. 1. If backup and main servers have the same conf iguration and the backup server can handle the existing load, set the value to 110. 2. If the backup server conf iguration is weaker and cannot handle the existing load p ermanently (or temp orarily) , set the value to 0. crm configure primitive P_INTERNET ocf:pacemaker:ping params host_list=<list of addresses> name=ping_internet timeout=1 attempts=2 op monitor interval=1s - the command defines the list of addresses, according to the accessibility of which the availability of access to the external network will be defined. It is recommended to add always active IP-addresses behind Ethernetswitch to which the primary and backup servers are connected, to this list; crm configure clone CL_INTERNET P_INTERNET crm configure primitive P_VIP_4 ocf:heartbeat:IPaddr params nic=<interface name> ip=<IP-address of class 4> cidr_netmask="255.255.255.0" - the command defines the IP-address, used as an entrance point for Switch class 4; crm configure primitive RTU_SIGNALING lsb:signaling-start-stop.sh op start timeout=60 op stop timeout=60 crm configure primitive RTU_SS7 lsb:ss7-start-stop.sh op start timeout=60 op stop timeout=60 - configures the scenario of commands for starting the nodes controlled by the p acemaker utility. Located in the catalog /etc/init.d. crm configure location L_VIP4_PCMK1 P_VIP_4 master] - binds the floating IP-address to the main server. crm configure colocation main_resource RTU_SIGNALING RTU_SS7 - joins all resources in one group. 100: [hostname INFINITY: from P_VIP_4 crm configure location L_VIP_INTERNET4 P_VIP_4 rule id=L_VIP_INTERNET4-rule -INFINITY: ping_internet lte 0 - defines the rule of resource transfer to the second server. crm configure order RTU_order mandatory: P_VIP_4 RTU_SIGNALING - Page 225 MVTS Pro Redundancy defines the order in which the pacemaker utility loads resources. crm_mon -A - the command allows you to control the backing up status in real time. To get a full picture you can also use crm_mon -trf. If servers can't be j oined in one cluster, check the f iles / etc/ corosy nc/ authkey which should be identical. 6.10.4.1 Command scripts for primary server 1. signaling-start-stop.sh #!/bin/sh case "$1" in "start") expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=signaling-pro-m method=kill\r" sleep 1 send "quit\r" eof kill -9 `ps auxww | awk '/statestore/ && $0 !~/awk/ {print $2}'` killall -USR2 mvts3g-server expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "load type=signaling name=signaling-pro-m\r" sleep 1 send "quit\r" eof ;; "stop") if (ps auxww | grep "mvts3g" | grep -v grep) > /dev/ null then expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=signaling-pro-m\r" sleep 1 send "quit\r" eof fi ;; "status"|"monitor") if !(ps auxww | grep "signaling-pro" | grep v grep) > /dev/null then sleep 2 if !(ps auxww | grep "signaling-pro" | grep -v grep) > /dev/null Page 226 MVTS Pro Redundancy then exit 7 fi fi ;; esac 2. ss7-start-stop.sh #!/bin/sh case "$1" in "start") expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "load type=ss7 name=ss7-m\r" sleep 1 send "quit\r" eof ;; "stop") if (ps auxww | grep "mvts3g" | grep -v grep) > /dev/ null then expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=ss7-m method=kill\r" sleep 1 send "quit\r" eof fi ;; "status"|"monitor") if !(ps auxww | grep "ss7-" | grep -v grep) > / dev/null then sleep 2 if !(ps auxww | grep "ss7-" | grep -v grep) > /dev/null then exit 7 fi fi ;; esac 6.10.4.2 Command scripts for backup server 1. signaling-start-stop.sh #!/bin/sh case "$1" in "start") Page 227 MVTS Pro Redundancy expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=signaling-pro-b method=kill\r" sleep 1 send "quit\r" eof kill -9 `ps auxww | awk '/statestore/ && $0 !~/awk/ {print $2}'` killall -USR2 mvts3g-server expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "load type=signaling name=signaling-pro-b\r" sleep 1 send "quit\r" eof ;; "stop") if (ps auxww | grep "mvts3g" | grep -v grep) > /dev/ null then expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=signaling-pro-b\r" sleep 1 send "quit\r" eof fi ;; "status"|"monitor") if !(ps auxww | grep "signaling-pro" | grep v grep) > /dev/null then sleep 2 if !(ps auxww | grep "signaling-pro" | grep -v grep) > /dev/null then exit 7 fi fi ;; esac 2. ss7-start-stop.sh #!/bin/sh case "$1" in "start") expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" Page 228 MVTS Pro Redundancy send "load type=ss7 name=ss7-b\r" sleep 1 send "quit\r" eof ;; "stop") if (ps auxww | grep "mvts3g" | grep -v grep) > /dev/ null then expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=ss7-b method=kill\r" sleep 1 send "quit\r" eof fi ;; "status"|"monitor") if !(ps auxww | grep "ss7-" | grep -v grep) > /dev/null then sleep 2 if !(ps auxww | grep "ss7-" | grep -v grep) > /dev/null then exit 7 fi fi ;; esac 6.11 Redundancy scheme with several active nodes 6.11.1 General information When using the redundancy scheme with several active nodes, all operating servers are involved in call processing, that is why it is impossible to distinguish which server is primary and which is reserved in the scheme. The System elements are divided into the following types: 1. Clustered elements which can be started simultaneously on several servers: balancer nodes; signaling nodes; media nodes; scripting nodes; command line nodes. 2. Reserved elements - only one of such elements is active and the other element reserves the active element in the standby mode: license management node; Page 229 MVTS Pro Redundancy SS7 call agent node; database; web-interface. 3. Not reserved elements which are unique in the System at any time. In case a server with one of such elements is out of order, this element is started on another server: synchro node; virtual IP-address. Scheme features: 1. There are fixed IP-addresses and a virtual IP-address in the System. Calls can arrive to fixed IPaddresses and to a virtual IP-address. For equipment with support of several entry points, it is recommended to use fixed IP-addresses. 2. The balancer nodes receive calls on fixed and virtual IP-addresses. Other nodes use only fixed IP-addresses for connection. 3. Outgoing calls are always sent from fixed IP-addresses. 4. Nodes which are not clustered are transferred from one server to another together with a virtual IP-address using the heartbeat mechanism. 5. The resource from both servers is used during the System operation. 6. The scheme can be used with a random amount of servers, equal to or more than 2. 6.11.2 Configuring general scheme Configuration of the high availability cluster (HA cluster) is performed as follows: 1. To configure functional nodes so that sockets, receiving H.323 and SIP signaling (H.323 and SIP listener), were opened only on the virtual IP-addresses. 2. Create identical configurations of SS7 call agent nodes (ss7-m,ss7-b) in DB 2: ss7-m uses a static IP-address of the primary server for SCTP-associations and MGCP; ss7-b uses a static IP-address of the reserved server for SCTP-associations and MGCP. 3. Specify the parameter SCTPHBInterval = 10 (default values is 30) on the SS7 gateway to minimize the SS7 failure time. 4. Establish the following distribution of the program nodes among balancing groups: mvtspro-group balancer-pro-m balancer-pro-b signaling-pro-m signaling-pro-b scripting-m scripting-b ss7-m ss7-b 5. Specify that the following program nodes should be started upon the System start: First server Second server management-m management-b media-m media-b scripting-m scripting-b Page 230 MVTS Pro Redundancy balancer-pro-m balancer-pro-b signaling-pro-m signaling-pro-b ss7-m ss7-b 6. Nodes started by the pacemaker utility on one of the cluster servers: synchro; 7. Nodes which refer to the interface table when the floating address is online/ offline: balancer-pro-m; balancer-pro-b; 8. To configure cluster on the basis of the pacemaker, perform the following commands on any of the servers: crm configure property stonith-enabled=false crm configure property no-quorum-policy=ignore crm configure rsc_defaults resource-stickiness=110 – the command defines if the resources will be transferred from the backup server to the primary server after the recovery of the primary server. The value 110 is specified if there is no need in transferring the resources. If the value 0 is specified, the resource will be returned to the primary server as soon as it becomes available. 1. If backup and main servers have the same conf iguration and the backup server can handle the existing load, set the value to 110. 2. If the backup server conf iguration is weaker and cannot handle the existing load p ermanently (or temp orarily) , set the value to 0. crm configure primitive P_INTERNET ocf:pacemaker:ping params host_list=<list of addresses> name=ping_internet timeout=1 attempts=2 op monitor interval=1s - the command defines the list of addresses, according to the accessibility of which the availability of access to the external network will be defined. It is recommended to add always active IP-addresses behind Ethernet-switch to which the primary and backup servers are connected, to this list; crm configure clone CL_INTERNET P_INTERNET crm configure primitive P_VIP_4 ocf:heartbeat:IPaddr params nic=<interface name> ip=<IP-address of class 4> cidr_netmask="255.255.255.0" - the command defines the IP-address, used as an entrance point for Switch class 4; crm configure primitive RTU_SIGNALING lsb:signaling-start-stop.sh op start timeout=60 op stop timeout=60 crm configure primitive RTU_SS7 lsb:ss7-start-stop.sh op start timeout=60 op stop timeout=60 - configures the scenario of commands for starting the nodes controlled by the pacemaker utility. Located in the catalog /etc/init.d. crm configure location L_VIP4_PCMK1 P_VIP_4 master] - binds the floating IP-address to the main server. 100: [hostname from crm configure colocation main_resource INFINITY: P_VIP_4 RTU_SIGNALING RTU_SS7 - joins all resources in one group. crm configure location L_VIP_INTERNET4 P_VIP_4 rule id=L_VIP_INTERNET4-rule -INFINITY: ping_internet lte 0 - defines the rule of resource transfer to the second server. crm configure order RTU_order mandatory: P_VIP_4 RTU_SIGNALING - defines the order in which the pacemaker utility loads resources. crm_mon -A - the command allows you to control the backing up status in real time. To get a full picture you can also use crm_mon -trf. Page 231 MVTS Pro Redundancy If servers can't be j oined in one cluster, check the f iles / etc/ corosy nc/ authkey which should be identical. 6.11.2.1 Command scripts for primary server synchro-start-stop.sh #!/bin/sh case "$1" in "start") expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "load type=synchro name=synchro-m\r" sleep 1 send "quit\r" eof ;; "stop") if (ps auxww | grep "mvts3g" | grep -v grep) > /dev/ null then expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=synchro-m method=kill\r" sleep 1 send "quit\r" eof fi ;; "status"|"monitor") if !(ps auxww | grep "synchro-" | grep -v grep) > /dev/null then sleep 2 if !(ps auxww | grep "synchro-" | grep -v grep) > /dev/null then exit 7 fi fi ;; esac 6.11.2.2 Command scripts for backup server synchro-start-stop.sh #!/bin/sh case "$1" in "start") expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 Page 232 MVTS Pro Redundancy expect "mvts3g|>" send "load type=synchro name=synchro-b\r" sleep 1 send "quit\r" eof ;; "stop") if (ps auxww | grep "mvts3g" | grep -v grep) > /dev/ null then expect > /dev/null -f- <<eof spawn telnet 127.0.0.1 5000 expect "mvts3g|>" send "unload name=synchro-b method=kill\r" sleep 1 send "quit\r" eof fi ;; "status"|"monitor") if !(ps auxww | grep "synchro-" | grep -v grep) > /dev/null then sleep 2 if !(ps auxww | grep "synchro-" | grep -v grep) > /dev/null then exit 7 fi fi ;; esac 6.11.3 Configuring scheme for several network interfaces/VLAN If it is necessary to use the scheme with several active nodes for several network interfaces/VLAN, the scheme from the chapter Configuring general scheme 230 will be used with the following changes: 1. The zones corresponding to the interfaces are added to the file system-1.zones.conf; 2. There should be a virtual IP-address on each VLAN; 3. Fixed and virtual addresses of all virtual local networks (VLAN) are added to balancer nodes for all sockets, receiving H.323 and SIP-signaling (H.323 and SIP listener); 4. Parameters of remote address accessibility and rules for virtual addresses of each VLAN are configured in the settings of the pacemaker utility. Thereafter, below see how the files will change in comparison with the previous scheme, if we suppose that there are two virtual networks (VLAN) and a main network: 1. Cluster configuration: a.system-1.zone.conf zone { zone "voip" Page 233 MVTS Pro Redundancy { "<external interface network>"; alias "ss7-zone-1"; }; zone "vlan1" { "<VLAN1 network>"; }; zone "vlan2" { "<VLAN2 network>"; }; }; b.system-1.balancer.conf balancer { balancer "balancer-pro-m" { common { loglevel "0"; }; controllink { zone "voip"; port "7200"; }; ras { address { "<virtual IP of MVTS Pro>"; "<static IP of rtu-1>"; "<virtual IP of VLAN1 MVTS Pro>"; "<static IP of VLAN1 rtu-1>"; "<virtual IP of VLAN2 MVTS Pro>"; "<static IP of VLAN2 rtu-1>"; }; port gkname allow_md5 allow_chap allow_plain "1719"; "MVTS3G"; "yes"; "yes"; "yes"; }; sip { address { "<virtual IP of MVTS Pro>"; "<static IP of rtu-1>"; "<virtual IP of VLAN1 MVTS Pro>"; "<static IP of VLAN1 rtu-1>"; "<virtual IP of VLAN2 MVTS Pro>"; "<static IP of VLAN2 rtu-1>"; Page 234 MVTS Pro Redundancy }; port "5060"; expiration "180"; proxying_balancing "yes"; }; h323 { address { "<virtual IP of MVTS Pro>"; "<static IP of rtu-1>"; "<virtual IP of VLAN1 MVTS Pro>"; "<static IP of VLAN1 rtu-1>"; "<virtual IP of VLAN2 MVTS Pro>"; "<static IP of VLAN2 rtu-1>"; }; port "1720"; }; }; balancer "balancer-pro-b" { common { loglevel "0"; }; controllink { zone "voip"; port "7200"; }; ras { address { "<virtual IP of MVTS Pro>"; "<static IP of rtu-2>"; "<virtual IP of VLAN1 MVTS Pro>"; "<static IP of VLAN1 rtu-2>"; "<virtual IP of VLAN2 MVTS Pro>"; "<static IP of VLAN2 rtu-2>"; }; port gkname allow_md5 allow_chap allow_plain "1719"; "MVTS3G"; "yes"; "yes"; "yes"; }; sip { address { "<virtual IP of MVTS Pro>"; "<static IP of IP rtu-2>"; "<virtual IP of VLAN1 MVTS Pro>"; Page 235 MVTS Pro Redundancy "<static IP of IP VLAN1 rtu-2>"; "<virtual IP of VLAN2 MVTS Pro>"; "<static IP of IP VLAN2 rtu-2>"; }; port "5060"; expiration "180"; proxying_balancing "yes"; }; h323 { address { "<virtual IP of MVTS Pro>"; "<static IP of IP rtu-2>"; "<virtual IP of VLAN1 MVTS Pro>"; "<static IP of IP VLAN1 rtu-2>"; "<virtual IP of VLAN2 MVTS Pro>"; "<static IP of IP VLAN2 rtu-2>"; }; port "1720"; }; }; }; For configuration of the pacemaker utility, perform the following commands on one of the servers: 1) crm configure property stonith-enabled=false 2) crm configure property no-quorum-policy=ignore 3) define whether the virtual IP-address will be transferred from backup server to the main one after its recovery. The value 110 is specified, if the transfer of the resources is not required. The value 0 means that the resources will be transferred to the main server as soon as it is available. crm configure rsc_defaults resource-stickiness=110 1. If backup and main servers have the same conf iguration and the backup server can handle the existing load, set the value to 110. 2. If the backup server conf iguration is weaker and cannot handle the existing load p ermanently (or temp orarily) , set the value to 0. 4) define the list of addressees, to which the request about the possibility to receive a call on this server will be sent. It is recommended to add always active IP-addresses behind the ethernetswitch, to which the primary and backup servers are connected, to this list. crm configure primitive P_INTERNET ocf:pacemaker:ping params host_list=<address list> name=ping_internet timeout=1 attempts=2 op monitor interval=1s crm configure primitive P_VLAN1 ocf:pacemaker:ping params host_list=<address list in VLAN1> name=ping_vlan1 timeout=1 attempts=2 op monitor interval=1s crm configure primitive P_VLAN2 ocf:pacemaker:ping params host_list=<address list in VLAN2> name=ping_vlan2 timeout=1 attempts=2 op monitor interval=1s 5) establish that the requests will be sent from both servers: crm configure clone CL_INTERNET P_INTERNET Page 236 MVTS Pro Redundancy crm configure clone CL_VLAN1 P_VLAN1 crm configure clone CL_VLAN2 P_VLAN2 6) define the virtual IP-address of the switch class 4: crm configure primitive P_VIP_4 ocf:heartbeat:IPaddr2 params nic=<interface name> ip=<class 4 IP address> cidr_netmask="255.255.255.0" crm configure primitive P_VIP_4_VLAN1 ocf:heartbeat:IPaddr params nic=<interface name> ip=<IP address CLASS4 in VLAN1> cidr_netmask="255.255.255.0" crm configure primitive P_VIP_4_VLAN2 ocf:heartbeat:IPaddr params nic=<interface name> ip=<IP address CLASS4 in VLAN2> cidr_netmask="255.255.255.0" 7) configure the scenarios of commands for starting the nodes controlled by the pacemaker utility (located in directory /etc/init.d): crm configure primitive RTU_SYNCHRO lsb:synchro-start-stop.sh op start timeout=60 op stop timeout=60 8) bind the floating IP-address to the main server: crm configure location L_VIP4_PCMK1 P_VIP_4 100: [hostname from master] join all resources in one group: crm configure colocation main_resource INFINITY: P_VIP_4 P_VIP_4_VLAN1 P_VIP_4_VLAN2 RTU_SYNCHRO 9) define the rule of resource transfer to the second server: crm configure location L_VIP_INTERNET4 P_VIP_4 rule id=L_VIP_INTERNET4-rule INFINITY: ping_internet lte 0 10) control the backing up status in real time: crm_mon -A To get a full picture you can also use crm_mon -trf. 6.12 Transit from heartbeat to pacemaker To switch from the heartbeat utility to the pacemaker, perform the following actions: 1. Complete the operation of the heartbeat utility and delete it with the help of the command aptitude purge heartbeart. All dynamic IP-addresses will be deleted. All started heartbeat program nodes will be stopped. The traffic will not be processed. 2. Form files /etc/init.d/nodes-start-stop.sh: on the primary and backup servers for the scheme with one active node - according to the chapter How to configure scheme. on each server for the scheme with several active nodes according to the chapters Configuring general scheme 230 or Configuring scheme for several network interfaces/VLAN 233 . Make sure that the System conf iguration corresp onds to the requirements sp ecif ied in the relevant chap ters. 3. Install and configure pacemaker and corosync according to the chapter Configuring pacemaker for TS redundancy schemes 218 . Page 237 MVTS Pro Redundancy 6.13 DB backup and recovery DB backup ensures data retention and database structure preservation and allows recovery from bad situations caused by a corrupted file system, server HDD crash or accidental clearing of information from the DB. 6.13.1 DB specifics affecting backup policy The MVTS Pro DB consists of a multitude of tables that include: 1. GUI tables. 2. TM object properties (configuration) tables (gateways, dial peers, user tables, etc.). 3. Call log and report tables. 4. CDR tables with monthly call data. 5. The mvts_cdr table, which does not contain data but integrates all monthly CDR tables. Tables mentioned in items 1 and 2 are InnoDB tables of the so-called transaction-safe type typical for MySQL. Data from tables of such type are stored in one or several InnoDB data files. The backup of such tables is carried out with the help of the mysqldump utility organic to the MySQL database software. When run, the mysqldump utility creates an SQL script for replication of the database structure or its individual tables and filling them with pertinent data. The nature of data stored in tables of items 3 and 4 does not require “transaction safety”, therefore this data is stored in the tables of myISAM type (ISAM = indexed sequential access method). Data from such tables are saved to special files. Backup of myISAM tables can be performed both by means of the mysqldump utility and through simple replication of structure, data and index files in the file system. As CDR tables are the only ever growing in size tables and the resulting size of data retention files may prove to be formidable it is reasonable to use the “replicate-in-the-file-system” method of backup for CDR tables. Call log tables contain no critical data and information from them is not saved during a backup. The mvts_cdr table is of the special type MERGE. It incorporates no data and only provides a convenient data handling interface for monthly CDR tables. To put it plainly, this table allows retrieval of data according to any criteria for whatever period of time regardless of in which CDR table and for what month the necessary information is actually located. During a backup only the mvts_cdr table structure is preserved. In addition to the tables the DB includes several views and stored procedures also backed up with the help of the mysqldump utility. 6.13.2 Backup tools and utilities Database maintenance utilities are stored on the DB server in the directory /usr/local/lib/ mvtspro. The same directory contains files pertaining to DB backup: backupdb.conf – is the DB backup procedure configuration file. backupdb-cron – an example cron job (for cron configuration directories /etc/cron.daily, / etc/cron.hourly, etc. determining cron scheduling). backupdb.php – is the DB backup script. restoredb.sh – is a script for DB restoration from a backup copy. ssh_auth_keys.sh is a script for SSH authentication keys generation and installation of the open key on a remote server. Installation of the key on the remote server allows setting up SSH for password-free access to the server. 6.13.3 Configuring SSH public key authentication The DB backup copying can be done both to the local disk drive and to a remote server (over ssh or scp). For the sake of a greater safety it is strongly recommended that a remote server backup method be used. If you still opt to save backup copies on the DB server it is advisable to add a special Page 238 MVTS Pro Redundancy purpose hard disk drive to the server. For unattended DB backup by means of the cron utility with saving the backup copy to a remote server password-protected access to the remote server is impossible, therefore it is necessary to set up SSH for open-key authorization. To enable open-key authorization, working as root, launch the ssh_auth_keys.sh script. ./ssh_auth_keys.sh The system will display a message saying that the script was started by the root user. Local user: root If RSA keys had not been created for the root user yet, the script will generate them: Generating public/private rsa key pair. Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: aa:bb:cc:dd:ee:ff:aa:bb::cc:dd:ee:ff:aa:bb:cc root@db-server Further you will be prompted to enter the name or IP address of the remote server and logon name and password for the user account in the name of which backup copy files will be saved on the remote server: Enter remote host: backup-server Enter remote user: root Copy public key to remote host (Enter password for user spatar@ora-testing1 when asked) ... Password: To see if the open-key authentication functions after the script execution is completed, type at the command prompt: ssh root@db-server For the arguments of the ssh command, type user name in lieu of “root” and provide the remote server name or IP address in lieu of “db-server”. If you are not prompted for a password and an access session starts, the open key authentication functions properly. 6.13.4 Configuring DB backup Open the backupdb.conf configuration file for editing and enter the following data: host= name or IP address of the DB server (always use the name “localhost”). user= DB user. password= DB user password. db= DB name. tmpdir= directory for temporary files. The directory must have enough free space to accommodate the DB backup of a forecasted size (to be more specific, there should be enough free space to accommodate all files of a one-time DB backup). desthost= name or IP address of the remote server intended for DB backup storing. If there is no remote server and it is planned to save DB backup files locally, i.e. to the DB server, delete this line or comment it as shown below: #desthost= destuser= user name on the remote server. destdir= target directory for DB backup on the remote or local server (depending on the value of the parameter desthost). This directory must be accessible for writing to the user who performs the DB backup (the user whose name is entered in the parameter destuser, when a remote server is used to Page 239 MVTS Pro Redundancy accommodate the backup). If there is no such a directory it will be created automatically. rotate – the number of directories with latest DB backups in the directory destdir. Count starts from 1 and all subsequent backup copies will be written to the directory with the next number. As soon as the number of folders equals the value of the parameter rotate, the least numbered directory is removed. backup_prefix – prefix for names of folders with DB backup copies (for example, backup). backup_cdrs – flag that can be 1 or 0. The flag determines whether monthly CDRs will be backed up. When the flag is set to 1 monthly CDRs are backed up, when set to 0, there will be no CDR backups. tables_no_data is a comma-separated list of tables that should not be included in backup copies. The table mvts_cdr is the one that needs to be included in the list. 6.13.5 Launching backup The script backupdb.php, that performs the DB backup procedure, should be launched by the user root or a member user of the group mysql, as the correct performance of the script requires the mysql group rights. When run, the utility backupdb.php creates the files tab1.sql and tab2.sql with tables and other DB objects except the monthly CDR tables. The script makes copies of structure files, data files and index files for monthly CDR tables that have changed since the time of previous execution. In addition the utility creates the file cdr.info with information about the status of saved CDR tables. 6.13.6 Unattended backup arrangements DB backup automation arrangements involve the use of the Linux standard cron daemon. For example, if you wish to perform the backup procedure hourly copy the file backupdb-cron to the directory /etc/cron.hourly or create a symbolic link to backupdb-cron there: cp /usr/local/lib/mvtspro/backupdb-cron /etc/cron.hourly/ or ln -s /usr/local/lib/mvtspro/backupdb-cron /etc/cron.hourly/backupdb-cron 6.13.7 DB recovery procedure The script restoredb.sh performs restoration of the DB from a backup copy. The script should be launched by the user root or a member user of the group mysql, as the correct functioning of the script requires the mysql group rights. For a DB recovery: 1. Copy the DB backup files to the DB server. 2. Copy the restoredb.sh script to the same directory with the backup files. Run the script entering the name of the recovery DB as the command argument: ./restoredb.sh rtu_restored Remember the entered recovery DB name must not coincide with the name of the op erational DB. This requirement is exp lained by the necessity to p rotect the op erational DB f rom accidental damage. When launched the restoredb.sh scrip t causes the DB engine restart You can launch the restoredb.sh script from any working directory if you indicate the file path to the backup copy directory in the second command argument, for example: ./restoredb.sh rtu_restored /path/to/backup 6.14 DB Replication Replication is a process of backing up information by transferring it from the main server (master replication server) to one or several slave servers to ensure consistency between the DB replicas. Page 240 MVTS Pro Redundancy In MVTS Pro, replication is used to provide additional fault-tolerance when interoperating with the DB. In case the main server fails, the System switches to the slave server with the redundant DB. 6.14.1 Replication types Replication can be classified in a variety of ways: 1. By the direction of replication: Master-slave rep lication — one-way replication when changes in the master DB are transmitted to the slave DB only. Master-master rep lication — two-way replication when two databases are synchronized with each other. 2. By synchronism: Synchronous rep lication — the DBMS replicates modified data within the same transaction. The changes take no effect until acknowledged by both the local and the remote server. In other words, there is only one version of data at every instance of time. Asynchronous rep lication — the DBMS replicates the modified data after some time, rather than within a transaction. When asynchronous replication takes place, the databases may not be identical for some time. 3. By replication formats: Row-based rep lication — the database management systems share and apply modified rows of the table. Statement-based rep lication — the database management systems share and execute SQL operators. MVTS Pro uses two-way master-master asynchronous row-based replication. To arrange for mutual master-master replication, the user should configure a one-way master-salve replication on each of two MySQL servers. When using rep lication with MVTS Pro never p erf orm write op erations to both databases simultaneously. Write op erations are only allowed to one DB at a time only. 6.14.2 Replication configuration While making arrangements for DB, make sure that the databases on both servers are identical. The easiest way to synchronize data is to copy the entire DB intended for replication to the target server. Disconnect all applications from the involved DBs so that they remain unchanged meanwhile. Additionally, halt the TS while you are preparing for replication. All steps and actions should be performed while working as “root”. In case a p assword was def ined f or the MySQL “root” user, add the --p assword p arameter to all mysqldump and mysql commands. The MySQL DB will then ask f or the MySQL root p assword during execution of a mysql command. 1. Make a dump of the main DB: #> mysqldump --allow-keywords --triggers --routines --opt --hex-blob -databases mvtspro > mvtspro.sql 2. If a DB already exists on the second server , make its back-up copy first executing the command from step 1 and only then remove the existing DB from the second server: #> mysql mysql> drop database mvtspro; 3. Copy the file mvtspro.sql, created at step 1 to the second host and create a DB using the following SQL script: #> mysql <mvtspro.sql Page 241 MVTS Pro Redundancy 4. Add a rep l user to both databases:: #> mysql mysql> grant replication slave on *.* TO 'repl'@'%' identified by 'slavepass'; 5. Stop the slave process for both DBs (no error will occur even if no such process exists) and reset the binary logs: #> mysql mysql> stop slave; mysql> reset slave; mysql> reset master; 6. Stop both DBs: #> invoke-rc.d mysql stop 7. Create the configuration file /etc/mysql/conf.d/rtu-repl.cnf on one of the hosts comprising the following: [mysqld] # # * Logging and Replication # server-id = 10 binlog-format = row log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 30 log-slave-updates auto-increment-increment = 10 auto-increment-offset = 1 replicate-same-server-id = 0 report-host = name-of-this-host replicate-do-db = mvtspro replicate-ignore-table = mvtspro.mvts_debug_call replicate-ignore-table = mvtspro.mvts_debug_call_log replicate-ignore-table = mvtspro.mvts_report replicate-ignore-table = mvtspro.mvts_report_data replicate-ignore-table = mvtspro.mvts_debug_registration replicate-ignore-table = mvtspro.mvts_cdr_export replicate-ignore-table = mvtspro.mvts_cdr_export_status replicate-ignore-table = mvtspro.ts_nodes_backups replicate-wild-ignore-table = web\_webdb\_\_nodes\_backup\_%.% master-host = name-of-the-other-host master-user = repl master-password = slavepass sync_binlog = 1 slave-skip-errors=1062,1053,1032 8. Create the configuration file /etc/mysql/conf.d/rtu-repl.cnf on the other server with the following content: [mysqld] # # * Logging and Replication # server-id = 20 binlog-format = row log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 30 Page 242 MVTS Pro Redundancy log-slave-updates auto-increment-increment = 10 auto-increment-offset = 2 replicate-same-server-id = 0 report-host = name-of-this-host replicate-do-db = mvtspro replicate-ignore-table = mvtspro.mvts_debug_call replicate-ignore-table = mvtspro.mvts_debug_call_log replicate-ignore-table = mvtspro.mvts_report replicate-ignore-table = mvtspro.mvts_report_data replicate-ignore-table = mvtspro.mvts_debug_registration replicate-ignore-table = mvtspro.mvts_cdr_export replicate-ignore-table = mvtspro.mvts_cdr_export_status replicate-ignore-table = mvtspro.ts_nodes_backups replicate-wild-ignore-table = web\_webdb\_\_nodes\_backup\_%.% master-host = name-of-the-other-host master-user = repl master-password = slavepass sync_binlog = 1 slave-skip-errors=1062,1053,1032 The italics highlight the distinctions between the two files. Starting f rom 1.7.0 the rep lication typ e on the MySQL-server should be ROW. The conf iguration f ile /etc/mysql/conf.d/rtu-repl.cnf should contain the f ollowing lines: binlog-format = row slave-skip-errors=1062,1053,1032 Af ter the up date (installation) make sure that the rep lication typ e (f ormat of binary logs) is correct with the help of the f ollowing command: mysql> show variables like 'binlog_format' Af ter that the System will disp lay the f ollowing data: Variable_name | Value binlog_format | ROW 9. Start both DBs: #> invoke-rc.d mysql start 10.Start the slave process in both databases: #> mysql mysql> start slave; 11.Use the following MySQL commands to monitor the state of the replication process: #> mysql mysql> show master status \G; mysql> show slave status \G; The field that shows the state of the replication is the Slave_IO_Status field in the output of the show slave status \G command. In the normal state the field shows the string Waiting for master to send event. If the field shows any other state for a long time, this may be a manifestation of a failure in the replication process. The number and textual representation of the last error are shown in the Last_Errno and Last_Error fields. Page 243 Appendix A. Metacharacters, regular expressions and number transformation 7 Appendix A. Metacharacters, regular expressions and number transformation 7.1 Use of metacharacters in search The comparison operators Like and Not like allow the use of patterns in search. Search patterns may include metacharacters ‘%’ and ‘_’. The character ‘%’ is used to denote any character string including an empty string that is a zerolength string. For example, the search pattern ‘123%’ corresponds to character strings starting with ‘123’. The pattern ‘%123’ corresponds to all character strings that end with ‘123’. The pattern ‘% 123%’ corresponds to character strings that include the sub-string ‘123’. The meta-symbol ‘%’ used individually corresponds to all character strings including empty strings. The underlining sign ‘_’ is used to mean a single arbitrary character. Therefore, the pattern ‘_123’ corresponds to all character strings starting with an arbitrary character followed by ‘123’ (for example, ‘0123’, ‘1123’ and so on.) The same meta-symbol can be used with reference to string inclusions that occur in strings that start and end with definite characters and include an indefinite one, for example ‘1_23’. A search pattern can comprise any number of metacharacters. For example, the search pattern %1_23% corresponds to character strings ‘04513234’, ‘1823’, ‘11123456’, etc. When you use the comparison operator Like the System will display all data that correspond to the search pattern. With the operator Not like the System will output all data that do not correspond to the search pattern. 7.2 Use of regular expressions in search Regular expressions provide a powerful tool for defining information search criteria. Regular expressions used in search consist of alphanumeric characters and metacharacters the description of which follows. Metacharact Description ers Character match . Any character [] Any characters matching those in square brackets Location ^ Beginning of character string (string head) $ End of character string (string tail) Quantity matching ? Matches zero or one occurrence of the previous expression * Matches zero or more occurrences of the previous expression Page 244 Appendix A. Metacharacters, regular expressions and number transformation + Matches one or more occurrences of the previous expression {x} x occurrences of the previous expression {x,} x or more occurrences of the previous expression {x,y} At least x occurrences, but not more than y occurrences of the previous expression Alternation | The alteration operator that matches either the expression before or the expression after the operator Grouping () Logical grouping MVTS Pro special characters / Separation of search pattern and replacement pattern in transformation patterns ; Separation of several patterns To instruct the system to treat a metacharacter as an ordinary character, p recede the metacharacter with a backslash (“\”) . Examples Suppose, you are looking for CDRs involving numbers beginning with “7095123”or “7095124” or “7095125” and ending in any 4 digits. In this case you should use the following regular expression pattern. ^7095(123|124|125).{4}$ As a result, the system will display all the records related to calls involving numbers 70951231234, 70951243333, 70951254567, 70951255678, etc. Suppose you are looking for all numbers that begin with “7095” and end in either 1, 2, or 3. You can use the following regular expression pattern for the search. ^7095.*[123]$ As a result, this pattern will match “70951111111,” “709500002,” “70951234563”, etc. In case you want the system to display all the records involving numbers beginning with "345" and followed by at least 1 but not more than 6 digits. Use the following regular expression pattern. ^345.{1,6}$ As a result, this pattern will match "3450," "3451111," "345888888", etc. Page 245 Appendix A. Metacharacters, regular expressions and number transformation 7.3 Number transformation The purpose of number transformation is bringing the calling or called telephone number to the necessary format. Setting number transformation rules involve the use of regular expressions. As a rule a transformation expression consists of two parts – a search pattern and a replacement string delimited by the slash «/» character. Use the brackets «( )» to create separate sections within the search pattern. The replacement string can include a replacement sub-string for a section. The replacement substring can be preceded by the search pattern section number followed by the backslash symbol «\». The most common number transformation tasks are removal, addition and replacement of number prefixes. Examples Goal: Remove prefix 1234 from number 123456789 Transformation pattern: ^1234(.*)/\1 (remove prefix 1234, that precedes the first section, i.e. \1) Result: 123456789 56789 Goal: Remove prefix 1234# form number 1234#123456 and replace it with prefix 0000# Transformation pattern: ^1234#(.*)/0000#\1 (replace prefix 1234# that precedes the first section with prefix 0000#) Result: 1234#1234567 0000#1234567 Goal: Add prefix 0000# to all numbers Transformation pattern: ^(.*)/0000#\1 (ap p end p ref ix 0000# to the beginning of any string, i.e. bef ore section 1) Result: 1234567 0000#1234567 7654321 0000#7654321, etc. If it is necessary to separate the replacement sub-string from the following symbols, use the following notation: \[group_number] or \g<[group_number]>. The maximum number of groups is 99. This notation is required when the figures go straight after the replacement sub-string. Goal: Add postfix 5555 to all numbers Transformation pattern: ^(.*)/\15555 or ^(.*)/\g<1>5555 (ap p end p ostf ix 5555 to the ending of any string, i.e. af ter section 1) Result: 1234567 12345675555 7654321 76543215555, etc. Page 246 Appendix A. Metacharacters, regular expressions and number transformation The same goal can be attained through the use of different translation patterns: translation pattern ^1234#/0000# is equal in effect to pattern ^1234#(.*)/0000#\1 (replace prefix 1234# with prefix 0000#). translation pattern ^/0000# is equal to pattern ^(.*)/0000#\1 (add prefix 0000# to all numbers). One string can include several translation expressions delimited by semicolons (;). Of all available expressions in the string the first that matches the number is used for transformation. To explain this, consider the following number transformation rules: ^78312/01# (add prefix 01# to numbers beginning with 78312). ^7831/02# (add prefix 02# to numbers beginning with 7831). Such number transformation expression can be written as follows: ^78312/01#;^7831/02# For the number 78312555555 the application will apply the first pattern and as a result prefix 01# will be added to the number (01#78312555555). At the same time the second expression will be used for transformation of the number 78315555555, and the prefix 02# will be added to the number (02#78315555555). Along with the patterns based on regular expressions you can use several additional keywords: the keyword rand(n) replaces itself with a random n-digit number. n may take values from 0 to 99. For example, any number in the rule ^(.*)/(123)rand(2) is translated into such numbers as 12389 or 12322, where the last two digits are random. the pattern ^$ matches an empty SRC number. This pattern may be used in the search pattern only. For example, the rule ^$/123 will translate all empty SRC numbers into number 123. Replaces the obsolete blank keyword. 7.4 Tips and tricks for regular expressions To speed up regexp processing and, consequentially, the overall System performance the System administrator is encouraged to minimize the number of regular expressions and simplify them. It is recommended to adhere to the following rules: 1. Symbol "()" Do not indiscriminately use the braces "()" in regexp patterns without number translation (e.g. in Orig. allowed SRC numbers). By way of example, use ^123456.* instead of ^123456(.*). Use braces only when it is really necessary and only for logical grouping. 2. It is stated in the Python standard library, that you can use up to 99 groups. For more detailed information follow the link http://docs.python.org/2/library/re.html and refer to the section 7.2.4. Match Objects. 3. Do not use \'group number' to specify the group in the translation patterns like (.) (.)(.)(.)(.)(.)(.)(.)(.)(.).*/\10. Use \g<'group number'> instead, in order to avoid ambiguous interpretation. In this example the sequence \10 can refer either to group 10 or to group 1 with symbol '0'. Therefore, it is recommended to use the sequence \g<1>0 instead of \10, which indicates that it is necessary to use group 1 with symbol '0', and not group 10. 4. Symbol ";" 1) Do not use this symbol to delimit several regexp patterns, except for the DP DST prefix allow patterns parameter. Delimit them with "|". As the ";" character delimits separate regular expressions, it can cause lags during routing due to the increased number of expressions. By way of example, use ^123.*|^456.*|789.* instead of ^123.*;456.*;^789.*. In this case three expressions will be substituted by one. 2) Use ";" to delimit the regexps in the DP DST prefix allow patterns parameter, as it is only valid way to supply DST numbers to the dial peers. For example, instead of 12345.*| Page 247 Appendix A. Metacharacters, regular expressions and number transformation 67890.* use 12345.*;67890.*, otherwise the System will not match the number 67890 to the pattern 12345.*|67890.*. 5. Use detailed patterns, delimited by semicolons ";" in the DP DST prefix allow patterns parameter. For example, 38120660173;3812066177[89];.......;38121660173;3812166177[89].. ...... 6. In all fields where number translation is used, reduce the number of expressions combining several expressions into one. For example, a regexp 1234(.*)/\1;1235(.*)/\1; 1236(.*)/\1 may be combined into 123[4-6](.*)/\1. 7. Symbol "^" Do not start the expressions with "^" in the DP DST prefix allow patterns parameter. Each pattern is enclosed with symbols "^" and "$" automatically. For example, instead of ^12345.*;^67890.* use 12345.*;67890.*. 8. When limiting the maximum number length, use a pattern like xxx.{n} in the allowed numbers field, where xxx are the initial digits of the number and n is the maximum number length minus the number of initial digits. For example, to limit the number starting with 1234 with 12 digits use the following pattern: ^1234.{8}. 7.5 Valid characters is phone number fields When specifying phone numbers in the System's settings (such fields as Orig. allowed SRC numbers, SRC number translation, etc.) the following rules apply: All phone numbers should conform to the E.164 format. Valid characters are listed in RFC 3601. Apart from compliance with the E.164 format, numbers received from the RADIUS server (for example, in the field xpgk-ep-numbers) should not comprise a + character. The System creates separate branches of the dial peer tree for figures only. When it comes upon any non-figure, though still valid as per RFC 3601, the System stops further decomposition of the number into the DP tree branches. For example, the number 8w908 will occupy the following position in the tree: Page 248 Appendix B. Codec list generation in MVTS Pro 8 Appendix B. Codec list generation in MVTS Pro 8.1 Codec matching rules Stage I. When using SIP some device types send SDP with non-standard codec definitions. The TS is able to identify codecs with standard definitions only. In case the TS is unable to identify codecs completely, the TM takes over codec identification from the TS. Stage II. The TM tries to match the partially identified (the codec type is identified, but some rtpmap or fmtp parameters may need correction) or unidentified (the codec type is not identified) codecs from the previous stage with the codecs, defined for the equipment in the DB (the Orig. codec group and Term. codec group parameter). Each codec from the equipment is sequentially compared to the codecs defined in the TM. The following rules apply: Codecs from the TM are checked according to their Precedence in group – from codecs with the highest precedence to codecs with the lowest precedence. The rtpmap and fmtp parameters and codec types of codecs from the equipment and codecs from the TM are compared against each other. If the fmtp and rtpmap parameters are not defined for the TM codecs (Use matching pattern for incom. SDP rtpmap and Use matching patterns for incom. SDP fmtp checkboxes are deselected respectively) these parameters are considered defined according to the standard. Codecs from the equipment defined in the standard way (that is those codecs that were fully identified during stage I) are also compared with those TM codecs that have Match with any codec of the same type checkbox selected. Codecs from the equipment that are identified partially or not identified at all during the first stage are not compared against codecs with Match with any codec of the same type checkbox selected. If a codec from the equipment is compared against a codec with Match with any codec of the same type checkbox selected and these codecs have the same codec type, this codec is considered fully identified and remains in the list of allowed codecs. If the codec is not identified and is not matched to any codec in the System, this codec is discarded. Thus the System gets a list of allowed codecs for the equipment. If such list is empty during call initiation, the call will be terminated. Here is an example of codec matching. The originator sent an SDP with the following codecs from the G.729 codec group: m=audio 21000 RTP/AVP 18 100 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=true a=rtpmap:100 G729/8000 During the first stage the TS partially identifies them with the following parameters: The first G.729 codec: SDP rtpmap = "G729" SDP fmtp = "annexb=true" The second G.729 codec: SDP rtpmap = "G729" The first G.729 codec corresponds to the G.729B codec. The second G.729 codec may be a G.729, G.729A, G.729AB or G.729B codec. To determine which codec matches this codec in the G.729 group, the System uses codec precedence. For example, the following codecs are defined in the System: Page 249 Appendix B. Codec list generation in MVTS Pro Identifying codecs of the G.729 group In this case the G.729 codec (number 2, with the checkbox Match with any codec of the same type selected) will be used as a default codec. It has the lowest priority and any partially identified codec of G.729 group without any specific parameters will match this codec in the process of codec matching. If Pass all changes codec policy is used, two more stages are added. Stage III. The System performs the same procedure as in stage II but uses codecs defined for the other party as the TM codecs. For example the originator's codecs obtained after stage II are additionally matched against the terminator’s codecs and vice versa. Stage IV. The final list of available codecs obtained at stage III is sent to the endpoint equipment (that is, to the terminator if the originator’s codecs were filtered or to the originator if the terminator’s codecs were filtered). The described codec identification procedure is performed for the originator as well as the terminator. Thus the codec identification procedure for the Pass all changes codec policy is shown in the figure below. Codec filtering when all changes in codecs are passed The procedure for codec identification for the Do not pass changes, Pass changes of media type, Pass changes for G.711 codec policies is shown in the figure below. Page 250 Appendix B. Codec list generation in MVTS Pro Codec filtering when other codec policies are used If the final codecs of the originator and terminator after filtering do not match each other, codec conversion takes place if possible. Codec conversion f or video codecs (H.261, H.263) and f ax codecs (T.38) is not imp lemented. Of the two codec policies (on the originator and terminator) the System selects the strictest one as the final policy. The list of policies sorted by strictness (from most to least) is as follows: Do not pass changes Pass changes of media type Pass changes for G.711 Pass all changes If the established policy is Pass all changes – the System will ignore the Term. codec sorting policy settings and send the codec from one gateway to the other in the order they were received from their source gateway. If the established policy is other than Pass all changes – the System will use Term. codec sorting settings as follows: If Term. codec sorting = No sorting, the codecs communicated to the gateway will be in the order they were in the DB. If Term. codec sorting = Matching codecs first, the codecs, matching the DB codecs, will be put to the head of the list and communicated to the gateway in the order they were received from the source equipment. 8.2 Proxy policies To ensure maximum flexibility of media transit through the Traffic Switch, the System provides for setting individual media proxy modes for each dial peer. The procedure is as follows: It is possible to select media proxy mode for each dial peer individually from the drop-down list Override equipment proxy mode in the dial peer properties form (Termination > Dial peers > Advanced settings). The dial peer setting overrides similar setting (Term. proxy policy) of the terminator (Equipment -> Equipment -> Termination settings). If the proxy override policy on the dial peer is not defined, the terminator proxy policy will be used. The final proxy mode is selected according to the following procedure: Call legs may be in one of two modes – proxying or non-proxying. The modes on both call legs should coincide. Initially, before the first route (terminator) is chosen, no mode is assigned to any call legs. When selecting the first terminator, the incoming and outgoing call legs are assigned proxy modes as per “Initial call leg mode” column of the table below, depending on the proxy policy applied. The rules for selecting proxy policies are described above. If due to any reason the System was unable to connect to the first terminator, the System resets the proxy mode for the outgoing call leg, leaves the previously selected proxy mode on the incoming call leg and proceeds with the next terminator in the dial peer. When selecting the second and subsequent gateways the System assigns a proxy mode to the outgoing leg as per “When selecting a route other than the first, established mode is” column, depending on the proxy mode established on the incoming call leg. The available proxy policies are shown in the table below. Proxy policies Proxy policy Initial call leg When selecting a route other Notes mode than the first, established mode is Page 251 Appendix B. Codec list generation in MVTS Pro Do not p roxy Proxy media media Do not proxy Do not proxy Continue with Try to stop Call legs are always in nonmedia media non-proxying proxying, if proxying mode; they never failed – switch into proxying mode. proceed to the next route Try not to proxy Do not proxy Continue with Try to stop Call legs may media on every media non-proxying proxying, if proxying mode. route failed – continue proxying switch into Try not to proxy Do not proxy Continue with Continue media on the media non-proxying proxying first route Call legs may proxying mode. switch into Proxy media Call legs are always in proxying mode; they never switch into non-proxying mode. Proxy media Start proxying Continue proxying If finally the established mode for both call legs is non-proxying, then the codec policy for both gateways will be set to Pass all changes. Otherwise the System selects the strictest codec policy for both gateways. Page 252 Appendix C. Default gateways 9 Appendix C. Default gateways When several subscribers connect to the System, their gateway settings differ only in billing parameters. To ease the configuration of such gateway, MVTS Pro features default gateways, i.e. separate template gateways with all-in-one settings, through which the devices register. In such layout the billing information (registration username, password, etc. pertaining to each subscriber) is stored on the RADIUS server, preventing the duplication of the data in the System. The System operation procedure in such a case unfolds as follows: System administrator creates a default gateway (object Equipment), selects Default gateway in the Equipment type combo box and selects the Enable RADIUS authentication checkbox. To complete the configuration, the administrator also needs to specify the allowed and disallowed registration username patterns (the Allowed registration username patterns/Disallowed registration username patterns parameter) and the precedence of the default gateway (the Default gateway precedence parameter). On arrival of a registration request the System first checks if the name of the registering device matches any of the names (Registration username parameter) of configured gateways. If not, the System draws up a list of default gateways, sorted by precedence (the value of the Default gateway precedence parameter). If the registration name of the device, which issued the request, matches any pattern defined in the Allowed registration username patterns, and does not match any patterns defined in the Disallowed registration username patterns, then such gateway is included into the list of default gateways. If the list is not empty, the registering device is authenticated through the RADIUS server using the data of the first appropriate default gateway on the list and the device’s registration name. The System supports the receipt of the registration usernames and passwords under the following methods: o For the SIP-equipment the registration username and password is authenticated using Digest Authentication. o For the H.323-equipment the following authentication methods are available: The H.323-gateway sends the registration username and password in plain text. The System may forward them to the RADIUS server in plain text (if the parameter System global settings -> Encrypt H.323 plain text password = 0), or may first encrypt it with the secret key (the Secret key parameter), defined in the RADIUS server settings. In the latter case the Encrypt H.323 plain text password parameter should be equal to 1. By default the Encrypt H.323 plain text password parameter is 1. The H.323-gateway sends the registration username and password encrypted using md5. The System forwards them to the RADIUS server unmodified. The H.323-gateway sends the registration username and password encrypted using Cisco CHAP. The System forwards them to the RADIUS server unmodified. The System creates a virtual gateway inheriting all the settings of the default gateway. If the gateway is a terminator, the System additionally creates a dial peer with the virtual gateway included into the dial peer’s Equipment list. The System receives the DST numbers for the dialpeer from the RADIUS server in the xpgk-ep-number field. In case this field is absent, empty or contains invalid value, the termination equipment is not authenticated. The call handling procedure for the virtual gateway, cloned from the default gateway, does no differ from the call handling for the gateways, entered into the DB regularly. Page 253 Appendix D. System limitations 10 Appendix D. System limitations 10.1 Cases of possible losing CDRs Data on calls may be lost completely in the following cases: Restart/shutdown of the server with scripting and signaling nodes through which calls are transmitted. Restart of the TS (i.e. simultaneous restart of scripting and signaling nodes through which calls are transmitted). Receipt of a call terminated message by a scripting node that has not been started yet or has not loaded the data from the DB (i.e. immediately after the restart). This situation is possible if this is the only scripting node in the System or all scripting nodes have been restarted simultaneously. The System creates a CDR in the Inaccurate table in the following cases: Restart of a signalling node while a scripting node remains active. Restart of a scripting node if any other scripting node in the System remains active (data on calls may be partially lost as the TS may send the call terminated message to the restarted node at the moment when it has not loaded the information from the DB). 10.2 SS7 Call Agent node limitations At the moment the SS7 Call Agent node has the following limitations: Limitation Possible effects M3UA The ‘Network Appearance’ and 1) This limitation does not conform to the RFC4666 specification. ‘Routing Context’ parameters As per the specification the ‘Routing Context’ and ‘Network are mandatory Appearance’ parameters are optional. 2) As the AS properties on the ASP and SGP side should be the same, and the configuration capabilities of the SGW equipment may be restricted, it may limit the overall number of available System configurations. For example, on the SS7 gateway the AS and its Routing Key are not configured explicitly, and there is no option to set the Routing Context and Network Appearance. The ‘Network parameter is not routing Indicator’ May cause routing errors when different signaling points have used for the same point codes. The node does not support The concept of logical signaling points is a basis for supporting several local (logical) signaling complex configurations by the SS7 Call Agent node. For example, points when one node is connected to several SS7 switches (using one or several SGWs) and may look for them as one or several SS7 switches, depending on the configuration. Presently the support of several SS7 switches within one TS is implemented by setting up several SS7 Call Agent nodes, one node for each local SS7 switch. The reserved signaling gateway The traffic transfer to the reserved gateway can be performed only Page 254 Appendix D. System limitations can't be used with automatic manually ( for example, changing the gateway address). transfer of traffic ISUP-R The overlap signaling is not May cause call routing errors. supported Message segmentation is not May cause problems with calls where segmented messages are supported used. However, segmented messages are rarely applicable, so the problems are unlikely. Continuity supported testing is not May cause problems when continuity testing is used by the remote switch. For example, the switch may stop using the circuits, which failed the test, and eventually decrease the trunk capacity to zero. Signal propagation delay The features basing on this functionality are not supported. detection is not supported Unrecognized data processing is The features basing on this functionality are not supported. not supported Unexpected data handling is not The features basing on this functionality are not supported. supported MTP congestion control is not The features basing on this functionality are not supported. supported Automatic Congestion Control The features basing on this functionality are not supported. is not supported User subsystem readiness The features basing on this functionality are not supported. management is not supported Redundancy A case of SS7 gateway failure The failure of a non-redundant SS7 gateway will most likely cause was not tested. It is strongly problems. recommended to set up a redundant gateway and configure the SS7 Call Agent node accordingly. Initialization of the SS7 Call Agent nodes and switching between them requires some time for exchanging messages with MGW, SGW and a remote SS7 switch. Usually the message exchange time is little, when there are no problems in the network. Generally it is defined by the delays in responses from gateways and remote signaling points, as well as the scale and complexity of configuration. Calls, active at the time of the switch, are terminated. Configuration Changing configuration of some SS7 Call Agent nodes (SCTP +M3UA) ‘on the fly’ (without node restarting) is not supported To change the SS7 Call Agent node configuration, stop the node and start it with the new configuration applied. All current calls get terminated and no calls may pass through the System until the node is online with the new configuration. An SS7 Call Agent node with May cause delay in processing and termination of new calls after Page 255 Appendix D. System limitations complex configuration (with the originator's timers expire. more than 63 E1 trunks) may use Solution to the p roblem: 100% of CPU for a long time. If possible, use several nodes for connections with a lot of ISUP CIC circuits. For example, make sure that there is one node for each DPC (OPC). Thus, if you change the configuration of one connection, it will have little effect on the configuration of other connections. 10.3 Other limitations In case of no available diskspace, the scripting node may crash. It is advisable to monitor diskspace with the help of Disk Space Monitor utility. Page 256 Appendix E. MVTS Pro – RADIUS interaction 11 Appendix E. MVTS Pro – RADIUS interaction The three types of services that the MVTS Pro may request from a RADIUS server are authorization, accounting and routing. In all the three cases the request initiator is the MVTS Pro session controller. The RADIUS server may initiate a communication exchange with the MVTS Pro server in one situation only: when it requires of the MVTS Pro to terminate a call due to depletion of the account balance. With the authorization and routing service the MVTS Pro sends the RADIUS server an AccessRequest of the appropriate type and receives either an AccessAccept or AccessReject. During an accounting exchange the MVTS Pro originates an AccountingRequest (Code 4) while the RADIUS server replies with AccountingResponse. If only one attribute is allowed but there are several of them in the packet received from the RADIUS server, then the last value is used, and the corresponding WARNING message is recorded into the log. In the response from the RADIUS server, the attribute xpgk-ep-number may contain one or several numbers delimited through ";". There can be several xpgk-ep-number attributes in one packet. When the exchange initiator is the RADIUS server, it sends the MVTS Pro DisconnectRequest (type 40), and the MVTS Pro responds with DisconnectAck(type41) for session termination or with DisconnectNak(type 42) for the request rejection. Below is a detailed description of the MVTS Pro-RADIUS server exchange content. 11.1 Procedure for dispatching packets to the RADIUS server Initially the System creates a list of RADIUS server for each calls as specified in the parameter Balancing method. The the following procedure is applied for each packet: The user def ines individual values f or the p arameters listed below f or each p acket typ e authorization, authentication and accounting. 1. After the first attempt to send the packet to the specific RADIUS server, the System waits for the response for the period defined in the Initial RADIUS response timeout, msec parameter. 2. If the response does not arrive within the timeout, the System re-calculates the timeout in keeping with RFC 5080. The re-calculated timeout is limited by the Maximum RADIUS response timeout, msec parameter. The re-calculation takes place for each attempt after the first one. The number of attempts is limited by the parameter Maximum retries of packet dispatch, and the total duration of all attempts - by the parameter Maximum total retry period of packet dispatch, msec. 3. If the System does not eventually receive the RADIUS response (either due to excess of the value of the Maximum retries of packet dispatch parameter or the Maximum total retry period of packet dispatch, msec parameter), it switches to the next RADIUS server in the list and attempts to execute the procedure anew (i.e. returns to step 1). 4. If the list of servers is exhausted but the packet is not yet dispatched, no further attempts to send the packet to the RADIUS server are made. 5. At the same time, note that the maximum duration for all attempts to deliver the packet should not exceed 5 secs, otherwise the TS drops the call with the code "Traffic Manager timeout". 11.2 Registering endpoint authorization The MVTS Pro sends the RADIUS server this type of authorization request on arrival of RegistrationRequest received by the MVTS Pro from the registering endpoint. AccessRequest structure in authorization request for a registering endpoint Page 257 Appendix E. MVTS Pro – RADIUS interaction IETF Attribute name VSA attr. attr. No. No. Description Data format Mandator y/ Optional (M/O) 4 NAS-IPAddress Local MVTS Pro address Defined by the «radius_nas_ip_ addr» parameter from the config file, by default «127.0.0.1» M 61 NAS-PortType Local port type always 0 M 6 Service-Type Service type Value from ‘Service-Type’ attribute value M 26 xpgk-requesttype Authorization request type always «user» M 1 User-Name User name string M 2 User-Password Password encrypted through MD5 BYTE[16] or in the plain form string or O 26 xpgk-md5-auth Password encrypted through MD5 BYTE[16] string or O 3 CHAPPassword CHAP-encrypted password string O 60 CHAPChallenge Unique CHAP identifier string O 104 Digest-Realm Describes a component of protected string RADIUS server realm O 105 Digest-Nonce Used as a component for Digest string authorization scenario O 109 Digest-URI Unique URI for Digest authorization string scenario O 108 Digest-Method Method type for authorization scenario Digest string O 103 DigestResponse Used as a component for Digest string authorization scenario O 115 DigestUsername User name string O 207 DigestAttributes Comprises sub-attributes string representing Digest parameters (Realm, Nonce, URI, Method, UserName) O 1 1 Expected responses are AccessAccept and AccessReject Page 258 Appendix E. MVTS Pro – RADIUS interaction On receipt of AccessReject the authorization is deemed rejected and the MVTS Pro sends the registering user RegistrationReject with the cause SecurityDenial. 11.3 Pre-routing call authorization The MVTS Pro sends the RADIUS server this type of authorization request before forwarding the call to destination along the selected path. AccessRequest structure in pre-routing call authorization IET F attr. No. 1 Attribute name VSA attr. No. User-Name Description User name Data format string Mandato ry/ Optional (M/O) M If the username contains the «$ani$» metasymbol, the metasymbol is replaced with an outgoing SRC number 2 UserPassword Password encrypted using BYTE[16] or string MD5, or in the plain form O 4 NAS-IPAddress Local MVTS Pro address Defined by the «radius_nas_ip_addr» parameter from the config file, by default «127.0.0.1» M 5 NAS-Port Local MVTS Pro port always 0 M 61 NAS-PortType Local port type always 0 M 6 Service-Type Service type Value from ‘ServiceType’ attribute value M 7 FramedProtocol This attribute indicates the Value from ‘Framedframing to be used for framed Protocol’ attribute value access. M 26 xpgk-requesttype Authorization request type always "number" M 31 CallingStation-Id SRC number string M 30 Called-StationId DST number string M 26 h323-conf-id 24 Conference ID h323-conf-id=<HEX[16]> M 26 h323-call-id 1 Call ID h323-call-id=<HEX[16]> M 26 h323-gw-id 33 Originator ID for the RADIUS h323-gw-id=<string> server 1 M Page 259 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. Attribute name VSA attr. No. Description Data format h323-gw-address=<IPaddress> Mandato ry/ Optional (M/O) 26 h323-gwaddress 23 Originator IP address 26 xpgk-srcnumber-in 1 SRC number, received in a xpgk-src-numberSETUP packet in=<number> M 26 xpgk-srcnumber-out 1 SRC number, sent terminator the xpgk-src-numberout=<number> M 26 xpgk-dstnumber-in 1 DST number, received in a xpgk-dst-numberSETUP packet in=<number> M 26 xpgk-dstnumber-out 1 DST number, sent terminator M 44 Acct-SessionId 26 xpgk-record-id 26 to to the xpgk-dst-numberout=<number> M Unique ID string M 1 Unique ID xpgk-record-id=<string> M xpgk-routeretries 1 Current retry number always 0 M 26 h323-remote-id 1 Terminator ID for the RADIUS h323-remote-id=<string> server M 26 h323-remoteaddress 23 Terminator IP address M 26 xpgk-md5-auth 1 MD5 password taken from xpgk-md5SETUP registrationRequest auth=<username/ <timestamp>>/HEX[16] O 3 CHAPPassword CHAP-encrypted password string O 60 CHAPChallenge Unique CHAP identifier string O 104 Digest-Realm Describes a component of string protected RADIUS server realm O 105 Digest-Nonce Used as a component for string Digest authorization scenario O 109 Digest-URI Unique URI for authorization scenario Digest string O 108 DigestMethod Method type for authorization scenario Digest string O 103 DigestResponse Used as a component for string Digest authorization scenario O 115 DigestUsername User name O h323-remoteaddress=<ip-address> string Page 260 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. Attribute name VSA attr. No. 207 DigestAttributes Description Mandato ry/ Optional (M/O) Data format Comprises sub-attributes string representing Digest parameters (Realm, Nonce, URI, Method, User-Name) O 26 h323incomingconf-id 1 Conference ID obtained from BYTE[16] or string the equipment M 26 h323incoming-callid 1 Call ID obtained from the BYTE[16] or string equipment M 26 xpgk-local-srcsignalingaddress 1 Incoming address M 26 xpgk-diversion 1 Redirecting number local signaling BYTE[16] or string string O Expected responses are AccessAccept and AccessReject Content of AccessAccept response from RADIUS server in pre-routing call authorization IETF attr. No. Attribute name VSA attr. No. Description Data format Mandatory/ Optional (M/O) 26 h323-credittime 102 Session length max h323-credit-time=<time, sec> O 26 h323-returncode 103 h323-return-code h323-return-code=<number> (if the field is not present or its value is 0, 13, 51 or 52, the authorization is considered successful, otherwise the call will be finished) O 27 SessionTimeout Session length O 26 h323-ivr-in 26 h323-redirect- 106 number 1 max integer Used as User- string Name in Accounting packets O Number to which string the call should be routed O Page 261 Appendix E. MVTS Pro – RADIUS interaction A receipt of AccessReject means a negated authorization and the route is rejected with the appropriate local disconnect code (LDC). Content of AccessReject response from RADIUS server in pre-routing call authorization IETF attr. No. 26 Attribute name h323disconnectcause VSA attr. No. 30 Description Data format Call disconnect h323-disconnectreason cause=<number> 11.4 Accounting request 11.4.1 Accounting Start record Mandatory/ Optional (M/O) O The MVTS Pro sends the RADIUS server the Accounting Start record upon arrival of a call (incoming leg) or on sending SETUP to the destination gateway (outgoing leg). Request type – AccountingRequest (Code 4) Structure of Accounting Start record forwarded to RADIUS server IETF attr. No. 1 Attribute name User-Name VS A attr . No. Description User name Data format string, Mandato ry/ Optional (M/O) M If the username contains the «$ani$» metasymbol, the metasymbol is replaced with an outgoing SRC number 4 NAS-IP-Address Local MVTS Pro address Defined by the «radius_nas_ip_addr» parameter from the config file, by default «127.0.0.1» M 61 NAS-Port-Type Local port type always 0 M 6 Service-Type Service type Value from ‘ServiceType’ attribute value M 41 Acct-Delay-Time Time (in sec), during which always 0 the client will try to send Accounting packet M 31 Calling-Station-Id SRC number M string Page 262 Appendix E. MVTS Pro – RADIUS interaction IETF attr. No. Attribute name 30 Called-Station-Id 26 h323-setup-time 26 VS A attr . No. Description DST number Data format Mandato ry/ Optional (M/O) string M 25 SETUP receipt time h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy> M h323-connect-time 28 Connect time h323-connect-time=< hh:mm:ss.uuu t www MMM dd yyyy> M 26 h323-conf-id 24 Conference ID h323-confid=<HEX[16]> M 26 h323-call-id 1 Call ID h323-call-id=<HEX[16] > M 26 xpgk-src-number-in 1 SRC number, received in a xpgk-src-numberSETUP packet in=<number> M 26 xpgk-src-number-out 1 SRC number, sent to the xpgk-src-numberterminator out=<number> M 26 xpgk-dst-number-in 1 DST number, received in a xpgk-dst-numberSETUP packet in=<number> M 26 xpgk-dst-numberout 1 DST number, sent to the xpgk-dst-numberterminator out=<number> M 26 xpgk-record-id 1 Unique ID M 26 xpgk-route-retries 1 Current retry number xpgk-route0 - if the call was ended retries=<number> before connection attempts sent only in the on the routes originate AccountingRequest M 26 h323-call-type 27 Call type (depends on Force h323-call-type=VoIP "Telephony" in h323-callor type) h323-calltype=Telephony M 26 h323-call-origin 26 Call leg, to which the packet For the originating leg pertains always “h323-callorigin=answer”, for the terminating leg always “h323-callorigin=originate” M 44 Acct-Session-Id ID for Start-Stop pair of Format detailed after Accounting packets the table M 26 h323-gw-id xpgk-recordid=<string> 33 Originator ID for the RADIUS h323-gw-id=<string> M Page 263 Appendix E. MVTS Pro – RADIUS interaction IETF attr. No. Attribute name VS A attr . No. Description Data format Mandato ry/ Optional (M/O) server 26 h323-gw-address 1 Originator IP address h323-gw-address=<IPaddress> M 26 h323-remote-id 1 Terminator ID h323-remoteid=<string> M 26 h323-remote-address 23 Terminator IP address h323-remoteaddress=<IP-address> M 40 Acct-Status-Type Type of Accounting packet always «1» M 26 xpgk-src-codec 1 Originator codec list xpgk-srccodec=<codecs' list> O 26 xpgk-dst-codec 1 Terminator codec list xpgk-dstcodec=<codecs' list> O 26 h323-incoming-callid 1 Call ID obtained from the BYTE[16] or string equipment M 26 h323-incoming-confid 1 Conference ID obtained from BYTE[16] or string the equipment M 26 xpgk-h323-id 1 H.323 ID obtained from the string incoming SETUP from the originator O 26 xpgk-local-srcsignaling-address 1 Incoming address signaling string M 26 xpgk-destinationuser 1 Parameter RADIUS string username as defined on the terminator O local In the Acct-Session-Id field information is presented as follows: <prefix>-<leg type><route number> where <prefix> is a random 8-digit hexadecimal number, delimited with "-". <leg type> - AV for the incoming leg and OV for the outgoing leg. <route number> is the current call termination attempt number. Expected response is AccountingResponse. 11.4.2 Accounting Interim-Update record The System periodically dispatches Interim records to the RADIUS server during the call session. Request type – AccountingRequest (Code 4) Structure of Accounting Interim-Update record forwarded to RADIUS server Page 264 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. 1 Attribute Name VSA attr. No. User-Name Description User name Data format string, Mandato ry \Optiona l (M\O) M If the username contains the «$ani$» metasymbol, the metasymbol is replaced with an outgoing SRC number 4 NAS-IP-Address Local MVTS Pro address Defined by the «radius_nas_ip_addr» parameter from the config file, by default «127.0.0.1» М 61 NAS-Port-Type Local port type always 0 М 6 Service type Value from ‘ServiceType’ attribute value М Service-Type 41 Acct-Delay-Time Time (in sec), during always 0 which the client will try to send Accounting packet М 31 Calling-Station-Id SRC number string M 30 Called-Station-Id DST number string M 26 h323-setup-time 25 SETUP receipt time h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy> M 26 h323-connect-time 28 Connect time h323-connect-time=< hh:mm:ss.uuu t www MMM dd yyyy> M 26 h323-conf-id 24 Conference ID h323-confid=<HEX[16]> M 26 h323-call-id 1 Call ID h323-call-id=<HEX[16] > M 26 xpgk-src-number-in 1 SRC number, received in a xpgk-src-numberSETUP packet in=<number> M 26 xpgk-src-number-out 1 SRC number, sent to the xpgk-src-numberterminator out=<number> M 26 xpgk-dst-number-in 1 DST number, received in a xpgk-dst-numberSETUP packet in=<number> M 26 xpgk-dst-number-out 1 DST number, sent to the xpgk-dst-numberterminator out=<number> M 26 xpgk-record-id 1 Unique ID M xpgk-recordid=<string> Page 265 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. Attribute Name VSA attr. No. Description Data format Mandato ry \Optiona l (M\O) 26 xpgk-route-retries 1 Current retry number xpgk-route0 - if the call was ended retries=<number> before connection sent only in the attempts on the routes originate AccountingRequest M 26 h323-call-type 27 Call type (depends on h323-call-type=VoIP Force "Telephony" in or h323-call-type) h323-calltype=Telephony M 26 h323-call-origin 26 Call leg, to which the For the originating leg packet pertains always “h323-callorigin=answer”, for the terminating leg always “h323-callorigin=originate” M 44 Acct-Session-Id ID for Start-Stop pair of Format detailed after Accounting packets the table M 26 h323-gw-id 33 Originator ID for RADIUS server M 26 h323-gw-address 1 Originator IP address h323-gw-address=<IPaddress> M 26 h323-remote-id 1 Terminator ID h323-remoteid=<string> M 26 h323-remote-address 23 Terminator IP address h323-remoteaddress=<IP-address> M 40 Acct-Status-Type 26 xpgk-src-codec 1 Originator codec list xpgk-srccodec=<codecs' list> O 26 xpgk-dst-codec 1 Terminator codec list xpgk-dstcodec=<codecs' list> O 26 h323-incoming-call-id 1 Call ID obtained from the BYTE[16] or string equipment M 26 h323-incoming-conf-id 1 Conference ID obtained BYTE[16] or string from the equipment M 26 xpgk-h323-id 1 H.323 ID obtained from the string incoming SETUP from the originator O 26 xpgk-local-srcsignaling-address 1 Incoming local signaling string address M Type packet of the h323-gw-id=<string> Accounting always «3» M Page 266 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. Attribute Name VSA attr. No. 26 xpgk-destination-user 1 46 Acct-Session-Time Description Data format Mandato ry \Optiona l (M\O) Parameter RADIUS string username as defined on the terminator O Current call duration in integer seconds M In the Acct-Session-Id field information is presented as follows: <prefix>-<leg type><route number> where <prefix> is a random 8-digit hexadecimal number, delimited with "-". <leg type> - AV for the incoming leg and OV for the outgoing leg. <route number> is the current call termination attempt number. Expected response is AccountingResponse. 11.4.3 Accounting Stop record The System periodically dispatches Interim records to the RADIUS server during the call session. Request type – AccountingRequest (Code 4) Structure of Accounting Interim-Update record forwarded to RADIUS server IET F attr. No. 1 Attribute Name User-Name VSA attr. No. Description User name Data format string, Mandato ry \Optiona l (M\O) M If the username contains the «$ani$» metasymbol, the metasymbol is replaced with an outgoing SRC number 4 NAS-IP-Address Local MVTS Pro address Defined by the «radius_nas_ip_addr» parameter from the config file, by default «127.0.0.1» М 61 NAS-Port-Type Local port type always 0 М 6 Service type Value from ‘ServiceType’ attribute value М Service-Type 41 Acct-Delay-Time Time (in sec), during always 0 which the client will try to send Accounting packet М 31 Calling-Station-Id SRC number M string Page 267 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. Attribute Name 30 Called-Station-Id 26 h323-setup-time 26 VSA attr. No. Description Data format Mandato ry \Optiona l (M\O) DST number string M 25 SETUP receipt time h323-setup-time=< hh:mm:ss.uuu t www MMM dd yyyy> M h323-connect-time 28 Connect time h323-connect-time=< hh:mm:ss.uuu t www MMM dd yyyy> M 26 h323-conf-id 24 Conference ID h323-confid=<HEX[16]> M 26 h323-call-id 1 Call ID h323-call-id=<HEX[16] > M 26 xpgk-src-number-in 1 SRC number, received in a xpgk-src-numberSETUP packet in=<number> M 26 xpgk-src-number-out 1 SRC number, sent to the xpgk-src-numberterminator out=<number> M 26 xpgk-dst-number-in 1 DST number, received in a xpgk-dst-numberSETUP packet in=<number> M 26 xpgk-dst-number-out 1 DST number, sent to the xpgk-dst-numberterminator out=<number> M 26 xpgk-record-id 1 Unique ID M 26 xpgk-route-retries 1 Current retry number xpgk-route0 - if the call was ended retries=<number> before connection sent only in the attempts on the routes originate AccountingRequest M 26 h323-call-type 27 Call type (depends on h323-call-type=VoIP Force "Telephony" in or h323-call-type) h323-calltype=Telephony M 26 h323-call-origin 26 Call leg, to which the For the originating leg packet pertains always “h323-callorigin=answer”, for the terminating leg always “h323-callorigin=originate” M 44 Acct-Session-Id ID for Start-Stop pair of Format detailed after Accounting packets the table M 26 h323-gw-id Originator ID for RADIUS server M 33 xpgk-recordid=<string> the h323-gw-id=<string> Page 268 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. Attribute Name VSA attr. No. Description Data format Mandato ry \Optiona l (M\O) 26 h323-gw-address 1 Originator IP address h323-gw-address=<IPaddress> M 26 h323-remote-id 1 Terminator ID h323-remoteid=<string> M 26 h323-remote-address 23 Terminator IP address h323-remoteaddress=<IP-address> M 40 Acct-Status-Type 26 xpgk-scd-time 1 Interval between the xpgk-scdSETUP and CONNECT time=<number> message O 26 xpgk-pdd-time 1 Interval between dialing xpgk-pddthe last digit and hearing time=<number> the RBT O 26 h323-disconnect-cause 30 Disconnect cause code M 26 xpgk-local-disconnectcause 1 Local call disconnect code xpgk-local-disconnectcause=<number> M 26 xpgk-source-rtpaddress 1 Media source IP address xpgk-source-rtpaddress=<IP-address> O 26 xpgk-dest-rtp-address 1 Media destination address IP xpgk-dest-rtpaddress=<IP-address> O 26 xpgk-source-faststart 1 Source Faststart capability xpgk-sourcefaststart=<number> O 26 xpgk-destinationfaststart 1 Destination capability O 26 xpgk-src-codec 1 Originator codec list xpgk-srccodec=<codecs' list> O 26 xpgk-dst-codec 1 Terminator codec list xpgk-dstcodec=<codecs' list> O 26 h323-incoming-call-id 1 Call ID obtained from the BYTE[16] or string equipment M 26 h323-incoming-conf-id 1 Conference ID obtained BYTE[16] or string from the equipment M 26 xpgk-h323-id 1 H.323 ID obtained from the string incoming SETUP from the originator O 26 xpgk-local-srcsignaling-address 1 Incoming local signaling string address M Type packet of Accounting always «3» h323-disconnectcause=<number> Faststart xpgk-destinationfaststart=<number> M Page 269 Appendix E. MVTS Pro – RADIUS interaction IET F attr. No. Attribute Name 46 Acct-Session-Time 26 xpgk-last-cdr 26 26 VSA attr. No. Description Data format Mandato ry \Optiona l (M\O) Current call duration in integer seconds M 1 Attribute showing that always 1 this billing session is the last one for the call O Cisco-NAS-Port 2 Incoming port of NAS or string gateway (Cisco-NAS-Port value) O xpgk-destination-user 1 Parameter RADIUS string username as defined on the terminator O In the Acct-Session-Id field information is presented as follows: <prefix>-<leg type><route number> where <prefix> is a random 8-digit hexadecimal number, delimited with "-". <leg type> - AV for the incoming leg and OV for the outgoing leg. <route number> is the current call termination attempt number. Expected response is AccountingResponse. 11.5 AccessRequest structure for RADIUS-aided routing The MVTS Pro sends a routing AccessRequest to the RADIUS server when a gateway, acting as a terminator, is marked as RADIUS routing server. The MVTS Pro’s request is aimed at getting a list of routing options for termination of the call at its destination point. In addition the MVTS Pro affords the possibility to change the username and password for the call in question. The MVTS Pro can handle several route options sequentially attempting every next route after a successful call termination through the previous one proves impossible. The type of request is AccessRequest (Code 1). Structure of routing request sent to RADIUS server VSA attr. No. Mandato ry/ Optional (M/O) IETF attr. No. Attribute name 44 Acct-Session-Id ID for Start-Stop pair of Format detailed after Accounting packets the table M 1 User-Name User name M 2 User-Password Password encrypted using BYTE[16] or string MD5, or in the plain form Description Data format string M Page 270 Appendix E. MVTS Pro – RADIUS interaction VSA attr. No. Mandato ry/ Optional (M/O) IETF attr. No. Attribute name 4 NAS-IP-Address Local MVTS Pro address Defined by the «radius_nas_ip_addr» parameter from the config file, by default «127.0.0.1» M 61 NAS-Port-Type Local port type always 0 M 6 Service-Type Service type Value from ‘ServiceType’ attribute value M 26 xpgk-requesttype Authorization request type always "route" M 31 Calling-StationId SRC number string M 30 Called-Station-Id DST number string M 26 h323-conf-id 24 Conference ID h323-conf-id=<HEX[16] > M 26 h323-call-id 1 Call ID h323-call-id=<HEX[16]> M 26 xpgk-srcnumber-in 1 SRC number, received in a xpgk-src-numberSETUP packet in=<number> M 26 xpgk-srcnumber-out 1 SRC number, sent to the xpgk-src-numberterminator out=<number> M 26 xpgk-dstnumber-in 1 DST number, received in a xpgk-dst-numberSETUP packet in=<number> M 26 xpgk-dstnumber-out 1 DST number, sent to the xpgk-dst-numberterminator out=<number> M 26 xpgk-record-id 1 Unique ID M 26 h323-gw-id 33 Originator ID RADIUS server 26 h323-gw-address 1 Originator IP address 2 User-Password 26 xpgk-md5-auth 3 60 1 Description Data format xpgk-recordid=<string> for the h323-gw-id=<string> h323-gw-address=<IPaddress> M M Password encrypted using BYTE[16] or string MD5, or in the plain form O Password encrypted using BYTE[16] or string MD5 O CHAP-Password CHAP-encrypted password string O CHAP-Challenge Unique CHAP identifier string O 1 Page 271 Appendix E. MVTS Pro – RADIUS interaction IETF attr. No. Attribute name VSA attr. No. Description Data format Mandato ry/ Optional (M/O) 104 Digest-Realm Describes a component of string protected RADIUS server realm O 105 Digest-Nonce Used as a component for string Digest authorization scenario O 109 Digest-URI Unique URI for Digest string authorization scenario O 108 Digest-Method Method type for Digest string authorization scenario O 103 Digest-Response Used as a component for string Digest authorization scenario O 115 Digest-Username User name string O 207 DigestAttributes Comprises sub-attributes string representing Digest parameters (Realm, Nonce, URI, Method, User-Name) O 26 h323-incomingconf-id 1 Conference ID obtained from BYTE[16] or string the equipment M 26 h323-incomingcall-id 1 Call ID obtained from the BYTE[16] or string equipment M 26 h323-setup-time 25 SETUP receipt time M 26 xpgk-local-srcsignalingaddress 1 Incoming address 26 xpgk-routingrequest 1 Special proprietary field always 1 M 26 xpgk-diversion 1 Redirecting number string O local h323-setuptime=<hh:mm:ss.uuu t www MMM dd yyyy> signaling string M In the Acct-Session-Id field information is presented as follows: <prefix>-<route number> where <prefix> is a random 8-digit hexadecimal number, delimited with "-". <route number> is the current call termination attempt number. Expected response – AccessAccept, AccessReject. Structure of AccessAccept response from RADIUS server Page 272 Appendix E. MVTS Pro – RADIUS interaction IETF attr. No. Attribute name 26 h323returncode 26 xpgkxroutingrouting VS A attr. No. Description Data format Mandato ry/ Optional (M/O) 103 If the field is not present or its value is 0, 13, 51 or 52, the authorization is considered successful, otherwise the call is finished. h323-returncode=<number> O Set of routes for call termination. Format detailed after the table O 1 Routes are handled in the same order as they go in the packet. Routes, found within the System, will be used for call termination, if there is no xpgk-xrouting-routing field. This field can contain a list of addresses ip:port delimited with ";" (port can be missing), that will be used instead of IP-addresses from TERM. IP address list 43 (in both formats: old and new). The System can use either old or new format of this attribute (both formats cannot be supported at the same time). For support of the new format, go to Operating TM -> RADIUS settings -> RADIUS global settings and specify 1 as the value of the parameter Use external RADIUS routing with separate parameters 160 . With the value 0 the System accepts the field xpgk-xroutingrouting in the old format. 26 h323-ivr-in Used as User-Name in Accounting packets string O 26 h323102 Maximum call session duration in credit-time seconds string O Maximum call session duration in seconds. If both fields (h323-credittime and Session-Timeout) are present, Session-Timeout is takes priority over h323-credit-time. integer O Name of the media group that should be used for the call. If the attribute is specified, its value shall coincide with one of the media groups, configured in MVTS Pro. string O 27 SessionTimeout 26 xpgkmediagroup-id 1 1 Other attributes in the packet (if specified correctly) are ignored. If one of the attributes of the packet is specified incorrectly or missing in the table RADIUS attributes 163 , such packet will be considered invalid. AccessReject – route authorization failed, the call is terminated with the appropriate local disconnect Page 273 Appendix E. MVTS Pro – RADIUS interaction code. The external routing algorithm is described in the chapter Termination 11.5.1 69 . Field XPGK-XROUTING-ROUTING (old format) Format description: xpgk-xrouting-routing=[route,...] xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill/ip-address[:port]/ converter/sessiontime/mediagroup/extra xpgk-xrouting-routing={text}/{0|1|2|3|4|5}/{telephone}/{telephone}/{telephone}[/{telephone}][/ ip4:[port]][/text][/text][/text] where: gateway – GW name from the Equipment record (a required parameter); proxy_mode – mode of proxy operation: o 0 - Do not proxy media o 1 - Try not to proxy media on every route o 2 - Try not to proxy media on the first route o 3 - Do not proxy whenever possible, use first originator's codec o 4 - Do not proxy whenever possible, use first common codec o 5 - Proxy media Proxy modes No. 3 and 4 are no longer used. When gateways, dial p eers and RADIUS servers use dif f erent p roxy modes, their settings are ap p lied in the f ollowing order: - Dial p eer p roxy mode. - If no p roxy mode is def ined on the dial p eer, the RADIUS server settings take p recedence. - If no p roxy mode is obtained f rom the RADIUS server, terminator's p roxy mode is used. source – calling number (src_number). dest – called party number that will be sent to the terminating gateway (dst_number). src_bill – calling number for the billing system. dst_bill – called number for the billing system. ip-address[:port] – IP address or a list of IP addresses (delimited with ";") for connection (port number is optional). If the port number is not specified, the default port number for the outgoing protocol will be used. The list of IP addresses from this field will be used instead of IP-addresses from TERM. IP address list 43 . converter – name of the record for the converter through which the call is to be terminated. sessiontime - maximum call duration, secs (this parameter overrides all other call duration settings). mediagroup - name of the media-group, to which the route should refer (refer to Appendix N. Media groups 306 ); extra – extra parameters. If the p arameters src_bill and dst_bill have no values, then src_bill=source and dst_bill=dest. Valid route definitions: xpgk-xrouting-routing=gateway/proxy_mode/source/dest/dst_bill If the f ield has 5 p arameters, p arameter number 5 is dst_bill. In all other cases p arameter number 5 is src_bill. Page 274 Appendix E. MVTS Pro – RADIUS interaction xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill/ip4[:port] xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill/ip4[:port] xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill/ip4[:port]/converter xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill/ip4[:port]/converter/ sessiontime xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill/ip4[:port]/converter/ sessiontime/mediagroup xpgk-xrouting-routing=gateway/proxy_mode/source/dest/src_bill/dst_bill/ip4[:port]/converter/ sessiontime/mediagroup/extra. Instead of xp gk-xrouting-routing you can use xp gk-er. These attributes are equal. Don't use both of them in one resp onse. 11.5.2 Field XPGK-XROUTING-ROUTING (new format) Format description: xpgk-xrouting-routing=<route ID>/<parameter ID>=<parameter value>|<parameter ID>=<parameter value>|<parameter ID>=<parameter value>|... where: <route ID> - arbitrary internal identifier, according to which the parameters will be arranged in groups within one route; <parameter ID> - name of the parameter; <parameter value> - value of the parameter. For example, if the following parameters are received: xpgk-xrouting-routing=ID1/gwName=aaa|proxyMode=2 xpgk-xrouting-routing=ID1/dstAddress=xxx.xxx.xxx.xxx xpgk-xrouting-routing=ID2/gwName=bbb xpgk-xrouting-routing=ID2/dstAddress=yyy.yyy.yyy.yyy the following routes will be created: gwName proxyMode dstAddress aaa 2 xxx.xxx.xxx.xxx bbb yyy.yyy.yyy.yyy Allowed ID of the parameters: gwName – GW name from the Equipment record (a required parameter); proxy_mode – mode of proxy operation: o 0 - Do not proxy media o 1 - Try not to proxy media on every route o 2 - Try not to proxy media on the first route o 3 - Do not proxy whenever possible, use first originator's codec o 4 - Do not proxy whenever possible, use first common codec Page 275 Appendix E. MVTS Pro – RADIUS interaction o 5 - Proxy media Proxy modes No. 3 and 4 are no longer used. When gateways, dial p eers and RADIUS servers use dif f erent p roxy modes, their settings are ap p lied in the f ollowing order: - Dial p eer p roxy mode. - If no p roxy mode is def ined on the dial p eer, the RADIUS server settings take p recedence. - If no p roxy mode is obtained f rom the RADIUS server, terminator's p roxy mode is used. ani - calling party number (source number); dnis - called party number, which will be sent to the terminating gateway (destination number); aniBill - calling number for the billing system; dnisBill - called number for the billing system; dstAddress - IP-address or a list of IP addresses (delimited with ";") for connection (port number is optional). If the port number is not specified, the default port number for the outgoing protocol will be used. The list of IP addresses from this field will be used instead of IP-addresses from TERM. IP address list 43 . maxCallTime - maximum call duration, secs (this parameter overrides all other call duration settings); mediaGroup - name of the media-group, to which the route refers (see Appendix N. Media groups 306 ); extraData – additional parameters, written to CDRs to the field ExtraData. Instead of xp gk-xrouting-routing you can use xp gk-er. These attributes are equal. Don't use both of them in one resp onse. 11.6 Authentication of registering devices on a RADIUS-server There are several RADIUS authentication scenarios depending on the authentication types supported by the registering equipment. H.323 ID-based authentication (standard RADIUS authentication) MD5 hash password authentication Chap authentication Digest authentication 11.6.1 H.323 ID-based authentication (standard RADIUS authentication) During standard RADIUS authentication the registering endpoint sends the MVTS Pro an AccessRequest packet with the user’s ID in the field terminalAlias (marked with the red ellipse in the figure below). The user’s ID consists of the user’s name and password delimited by one of the following symbols: «|», «:», «!» or «%». Upon receipt of the packet, the MVTS Pro forwards to the RADIUS server an access request (marked with the red rectangle) with the user’s name, password, the MVTS Pro identifier and port the registering endpoint attempts to access. The password undergoes MD5 hash encryption and is obtained from: UserPassword = MD5Hash(Shared Secret, RemoteAuthenticator) XOR password, where Shared Secret is the value of the parameter Secret key in the RADIUS server settings. RemoteAuthenticator is a pseudorandom number present in the header of the AccessRequest packet received from the registering endpoint. password denotes the user’s password available from the MVTS Pro database. Page 276 Appendix E. MVTS Pro – RADIUS interaction Standard RADIUS authentication Based on the received data and the shared secret established between the MVTS Pro and the RADIUS server, the RADIUS server generates an MD5 hash and if the newly generated hash matches the one received from the MVTS Pro, the RADIUS server responds with AccessAccept, otherwise the server’s reply is AccessReject. 11.6.2 MD5 Authentication With this type of authentication involved the GatekeeperRequest that the MVTS Pro receives from the registering endpoint contains the information that the endpoint is supportive of this authentication method. Upon receipt of the GatekeeperConfirm packet from the MVTS Pro, the endpoint responds with a registration request containing the user’s alias, time stamp, MD5 hash password and data about the parameters used for the hash generation (marked with the red ellipse in the figure below). As the MVTS Pro is unaware of the user’s true password, it sends the hashed password in the field xpgkmd5-auth (marked with the red rectangle) together with the parameters used for its generation rather than in the field password. The RADIUS server must possess the capability to read the field xpgkmd5-auth. . MD5 authentication 11.6.3 CHAP Authentication With CHAP authentication the GatekeeperRequest that the MVTS Pro receives from the registering endpoint contains the information that the endpoint is supportive of this authentication method. The Page 277 Appendix E. MVTS Pro – RADIUS interaction MVTS Pro responds with a GatekeeperConfirm packet that includes the ‘challenge’ (a pseudorandom hexadecimal number). The registering user sends the MVTS Pro a registration request the field tokens of which contains the challenge and the hashed password generated using the challenge, the user’s password and identifier. Following this the MVTS Pro sends the RADIUS server a registration request with the data as below: CHAP-Password – the hashed password generated by the user; CHAP-Challenge – the challenge; User-Name - the user’s name. The figure below shows an example of the MVTS Pro registration request. CHAP authentication The RADIUS server reads the fields CHAP-Password, CHAP-Challenge and searches its database for the user’s password using the user’s name for the search argument. Based on the found password, the user’s name and the challenge the RADIUS server is expected to generate an identical hash. If the hash generated by the RADIUS server does not match the hash received from the MVTS Pro, the authentication attempt is rejected. 11.6.4 Digest authentication Digest authentication is used for authorization of SIP endpoints. A digest authentication procedure includes the following steps: The registering endpoint sends the registration-balancer node a registration request (the packet “REGISTER”) The registration-balancer node responds to the request with packet 401 containing the socalled “nonce”, i.e. a pseudorandom number. Using the received “nonce” and some other data the registering user generates an MD5 hash (DigestResponse) and sends it back along with the data used for its generation in the REGISTER response packet. The registration-balancer node forwards to the MVTS Pro a registration request containing in the field tokens a certificate comprised of the user generated MD5 hash and the data used for its generation. The MVTS Pro uses an AccessRequest packet to provide the RADIUS server with the user’s MD5 hash and the hash generation data. Based on the received data and the user’s password stored in the database the RADIUS server is supposed generate an identical MD5 hash. In case the hash generated by the RADIUS server coincides with the hash received from the MVTS in the Digest-Response attribute, the user is authenticated, otherwise the authentication fails. Page 278 Appendix E. MVTS Pro – RADIUS interaction Digest authentication 11.7 Call disconnect upon Packet of Disconnect arrival This feature allows the RADIUS server to terminate any call by sending a Packet of Disconnect to the System. The packets and their composition is per RFC 3576. The call disconnect procedure unfolds as follows: MVTS Pro receives a Packet-of-Disconnect on any port (authorization, accounting or external routing). The packet should comprise an ID of the conference to be disconnected. Upon packet arrival the System checks if the conference with the ID specified exists. o If the conference exists, the System terminates it and sends a Disconnect-ACK message to the RADIUS server. o Otherwise the System sends Disconnect-NAK. The System disconnects always active calls upon Packet of Disconnect arrival regardless of the settings. Messages associated with Packet-of-Disconnect Message Packet-ofDisconnect RFC 3576 message code 40 Message attributes h323-conf-id — ID of the conference to be disconnected. The ID was generated by the TS. The attribute should comprise the same value as the h323-conf-id, in Access-Request, Accounting-Request. h323-incoming-conf-id - ID of the conference to be disconnected. The ID was received from the equipment. The attribute should comprise the same value as the h323incoming-conf-id, in Access-Request, AccountingRequest. The System expects the arrival of h323-conf-id or h323-incoming-conf-id. If both attributes arrived in the packet, the System uses h323-conf-id. Page 279 Appendix E. MVTS Pro – RADIUS interaction Disconnect-ACK 41 N/A. Disconnect-NAK 42 N/A. Page 280 Appendix F. Removing CDRs from the DB 12 Appendix F. Removing CDRs from the DB To remove CDRs from the DB do the following: Removing CDRs is irreversible. 1. In the MySQL console enter the command: alter table mvts_cdr union=(mvts_cdr_model); 2. Remove all unnecessary CDR tables in the MySQL console. For example: drop table mvts_cdr_200801 drop table mvts_cdr_200801 drop table mvts_cdr_200801 3. In the shell execute the following command: /usr/local/lib/mvtspro/mvtsprodb.py --user=**** --pass=**** --db=mvtspro update_merge_cdr Enter user name and password instead of ****. Page 281 Appendix G. NAT traversal 13 Appendix G. NAT traversal This section describes how MVTS Pro operates with equipment located behind NAT: · SIP calling party behind NAT · SIP called party behind NAT · H.323 calling party behind NAT · H.323 called party behind NAT How the TS registers SIP devices behind NAT When a SIP device registers with the System, Traffic Switch checks if this device is behind NAT. For this, the balancer node compares the IP address where the signaling message actually came from with the IP address from the top Via header of this message. If these IP addresses are different (ports are not taken into consideration), the device is behind NAT, i.e. the actual IP address of the packet is the address of the NAT router. Accessibility of the registered device is supported by the System through sending the OPTIONS message or by the device through sending keep-alive packets. SIP calling party behind NAT How the scripting node authenticates SIP devices behind NAT When selecting a customer authentication record, the scripting node compares IP addresses of the calling device and the NAT router with values from the IP address and NAT IP address fields of the record respectively: · if both fields are empty, the scripting node does not check IP addresses; · if both fields are not empty, the scripting node may select the record only in case of the full match of both address pairs; · if IP address is set and NAT IP address is empty, the scripting node definitely will not select the record. Even if the originating device was not found, the scripting node writes a CDR for it. In this CDR the IP address from which the packet actually came is written as the address of the originating device. SIP called party behind NAT A SIP called device located behind NAT should be registered with the System. H.323 calling party behind NAT An H.323 calling device located behind NAT should be registered with the System. Before placing a call, it should send an H.323 Admission Request (ARQ). When authenticating the device, the TS checks if the corresponding customer authentication record and equipment registration record exist and are enabled. H.323 called party behind NAT MVTS Pro cannot place calls to H.323 equipment behind a NAT router with dynamically defined ports. To fix the problem of transferring media traffic to equipment behind NAT-router, which causes difference between actual media-address and the address from signaling messages, use special flags 0x00000100 39 and 0x00080000 39 in the equipment settings (for detailed information refer to Equipment 39 ). The flag 0x00080000 39 is especially important for transfer of fax messages via T.38 to devices behind NAT. Page 282 Appendix H. Managing endpoints in MVTS Pro 14 Appendix H. Managing endpoints in MVTS Pro Although MVTS Pro is designed to handle transit calls predominantly, it is capable of managing subscriber traffic too. The System assigns a phone number to every subscriber endpoint. The endpoint may or may not register with the System. To use this functionality do the following: Invoke the pop-up menu in the Equipment table and select Add. Select the Endpoint option in the Equipment type listbox. In the Endpoint number field specify the phone number of the subscriber (the same rules as with DST prefix allow patterns in the dial peer settings apply). Define the registration and other parameters for the endpoint if necessary. The System automatically creates a dial peer for this endpoint, and after registration (if it is configured) the endpoint is able to originate and terminate calls. The implicit dial peer will have the name (visible, for example, in the CDRs) based on the endpoint name: <endpoint name>-epdp. This dial peer will not be shown in the Dial peers table. For example, for the endpoint with the name JohnSmithEP the implicit dial peer will have the name JohnSmithEP-epdp. Such implicit dial peer has Precedence equal to 100. Page 283 Appendix I. External routing over SIP/H.323 15 Appendix I. External routing over SIP/H.323 External call routing over SIP and H.323 is implemented in the System. The external routing algorithm is described in the chapter Termination 69 . 15.1 H.323 For H.323 external routing the System interoperates with the H.323 gatekeeper and makes use of Lxx messages. The scheme of interoperation is as follows: If the System finds a gateway of Gatekeeper type in the list of routes, generated from the dial peer, the System sends a LRQ message to this gatekeeper. The gatekeeper responds with a LCF message, comprising numbers and addresses of servers, where the call should be actually routed. This data replaces the gatekeeper record in the route list and the System proceeding with route selection procedure as usual. 15.2 SIP SIP external routing is based on handling SIP 3xx messages that comprise a list of possible destinations for call termination. The scheme of interoperation is as follows: 1. The System sends an INVITE message to the Routing server (SIP) 39 (if a gateway of SIP routing server type has been found in the list of routes, generated from the dial peer). INVITE is sent to the first address from SIP-router's IP address list 55 . Below are two examples of such INVITEs: a) with the origination gateway name: INVITE sip:555@192.168.228.14:9999;user=phone;zone=voip SIP/2.0 Via: SIP/2.0/UDP 192.168.229.67:5061;rport;branch=z9hG4bKdb6ce56e7eef11e4a3c60080484ffad0 Route: <sip:192.168.229.67:5060;lr> From: "mvtspro"<sip:123@192.168.229.67:5061;gwname=gw1;user=phone>;tag=db6cdf9c7e ef11e4a3c60080484ffad0 To: <sip:555@192.168.228.14:9999;user=phone> Call-ID: db6cdfd87eef11e4a3c60080484ffad0@192.168.229.67 CSeq: 1 INVITE Contact: <sip:123@192.168.228.18:0> Max-Forwards: 70 User-Agent: TS-v10.1-100.1 Content-Length: 0 b) without the origination gateway name: INVITE sip:555@192.168.228.14:9999;user=phone;zone=voip SIP/2.0 Via: SIP/2.0/UDP 192.168.229.67:5061;rport;branch=z9hG4bKc58e3f627ef011e4a3c60080484ffad0 Route: <sip:192.168.229.67:5060;lr> From: "mvtspro"<sip:123@192.168.229.67:5061;user=phone>;tag=c58e39a47ef011e4a3c60 080484ffad0 To: <sip:555@192.168.228.14:9999;user=phone> Call-ID: c58e39e07ef011e4a3c60080484ffad0@192.168.229.67 CSeq: 1 INVITE Contact: <sip:123@192.168.228.18:0> Max-Forwards: 70 Page 284 Appendix I. External routing over SIP/H.323 User-Agent: TS-v10.1-100.1 Content-Length: 0 where: From: "mvtspro"<sip:123@192.168.229.67:5061;gwname=gw1;user=phone>;tag=db6cdf9c7eef11e 4a3c60080484ffad0: - "mvtspro" – the value of the Request sender’s name sent to SIP router field in the SIP router's parameters 39 . The value is used to authenticate the System on the external SIProuting server; - 123 – DST number; - 192.168.229.67:5061 – IP address and port of the TS signaling node which sent the INVITE; - gw1 – origination gateway name (written if the Send initiator's name to SIP-server checkbox is selected in the SIP router's parameters 39 category). Contact: <sip:123@192.168.228.18:0>: URI with the DST number (after pre-routing translations) and IP address and port of the origination equipment. 2. The Routing server (SIP) 39 responds with a 3xx message comprising one or more “Contact” fields with a list of URIs in the following format: sip:[destination number];[userParams]@IP:port;[hostParams]. The parameters destination number, userParams, hostParams are optional and may be missing. When parsing, the System ignores userParams and selects gwname=[gateway_name] or tgrp=[SIP_routing_group] from hostParams. For example: SIP/2.0 302 Moved temporarily Via: SIP/2.0/UDP 192.168.229.67:5061;rport=5061;branch=z9hG4bKdb6ce56e7eef11e4a3c60080484ffad0 From: "mvtspro"<sip:123@192.168.229.67:5061;gwname=gw1;user=phone>;tag=db6cdf9c7eef 11e4a3c60080484ffad0 To: <sip:555@192.168.228.14:9999;user=phone>;tag=1 Call-ID: db6cdfd87eef11e4a3c60080484ffad0@192.168.229.67 CSeq: 1 INVITE Contact: <sip:1111@192.168.228.19:1721;gwname=GW2> Contact: <sip:2222@192.168.228.19:1721> Contact: <sip:3333@invalid;gwname=GW2> Contact: <192.168.228.19:1721;gwname=GW2> Contact: <sip:4444@invalid;tgrp=myRoutingGroup> Record-Route: <sip:AQEAECPmyKeHqUS6KegEVk6cAL4DAARKzkq0@192.168.229.67;lr> Record-Route: <sip:AQEAEPOoiNF7u0YKUVnxb5BQHqoDAAQi0D9o@192.168.229.67;lr> Content-Length: 0 where Contact fields are: <sip:1111@192.168.228.19:1721;gwname=GW2>: contact with the DST number, IP address:port and gateway name. <sip:2222@192.168.228.19:1721>: contact with the DST number and IP address:port. <sip:3333@invalid;gwname=GW2>: contact with the DST number and gateway name. <192.168.228.19:1721;gwname=GW2>: contact with the IP address:port and gateway name, but without a DST number. <sip:4444@invalid;tgrp=myRoutingGroup>: contact with the DST number and SIP-routing group name. In the latter case, a group with the myRoutingGroup name should be present in the SIP-routing groups 83 table, otherwise the System will not use this URI. A URI will be also ignored, if it contains both gwname and tgrp parameters, for instance: <sip:4444@invalid;gwname=GW3;tgrp=myRoutingGroup> The p arameter DST number should contain the number consisting of f igures and symbols "-", ".", Page 285 Appendix I. External routing over SIP/H.323 "*", "#", "A", "B", "C", "D", "p " and "w". This number may start with "+", in this case it will be considered as international (symbol "+" is deleted in the termination p rocess) . If the checkbox Drop route containing DST number with invalid symbols is selected in the SIP router's parameters category, the System will drop the route with the DST number containing invalid symbols. If the checkbox is clear, such route will be considered as correct and the System will route the call using the translated number received from the initiator as the DST number. If there is a pattern in the field URI match pattern for DST number received from SIP-server 55 in the settings of this SIP router and the received URI matches this pattern, then the original URI (including all parameters) will be used as a destination number. If the SIP-server in response sent a terminating address, the System will create one route with this address. If the SIP-server sent only gateway name (the received address was invalid), then all IP addresses from TERM. IP address list 43 shall be used. In case of unsuccessful response from the SIP-server the System sends a request to the next address from SIP-router's IP address list 55 . 3. The System searches for the terminating device using the name of the gateway (the value of the gwname parameter), or selects one of the gateways from the tgrp group. Any operating terminating equipment (a gateway, an endpoint with any configured protocol, URI Resolver, ENUM-server) may be used as a terminating device (refer to Equipment 39 ). If there is no gateway, the System will search for the terminating device using the parameter IP:port. If no port is specified in the response from the routing server, then the System will configure routes for all the equipment with the specified IP address. The System searches for the operating terminating equipment of the following type: a gateway or an endpoint with protocols SIP, H.323, SIP-T/I, H.323 and SIP. The parameter IP:port is also used as the terminating device address. If the port number is not specified, the default port number for the outgoing protocol will be used. If there is "Invalid" (the reserved word) instead of "IP:port", then the address specified in the gateway settings is used as the terminating device address. 4. In the Contact field of the 302 Moved Temporarily message, the SIP server sends routes, from which MVTS Pro makes a list: if the parameter "q" (which indicates the priority of a route) is missing, the order in which the routes follow each other in the Contact field is preserved; if the parameter "q" is present, the routes go in the order of descending of the "q" parameter value; routes with equal values of the "q" parameter are processed randomly. For more information refer to http://www.ietf.org/rfc/rfc3261.txt The list of routes replaces the record of the SIP routing server in the general list of dial peers. Page 286 Appendix J. Call routing according to SIP URIs 16 Appendix J. Call routing according to SIP URIs 1. Upon arrival of a call the System finds a suitable originating gateway, then in the settings of this gateway it is defined how the received SRC and DST numbers (URI of the format: proto:digits@domain) will be interpreted - as traditional telephone number (the part digits will be used) or as a URI (the whole URI will be used). The number type is defined according to the patterns from the equipment settings (see the tables below). Parameters used to define the number type Equipment type -> Gateway Equipment type -> Routing server (SIP) Protocol -> SIP Sip-router parameters -> parameter URI match pattern for DST-number received from SIPserver Origination settings -> parameters URI match pattern for SRC number and URI match pattern for DST number The number type depends on the presence of the URI match pattern in the equipment settings. Determining the number type according to the pattern Is the URI match pattern specified? yes no Does the received URI match the pattern? Is the digits alias specified? yes no yes no URI is used as a number digits are used as a number digits are used as a number URI is used as a number If the value of the p arameter Ignore URI, if the p attern f or its def inition is not sp ecif ied the URI match p attern is not sp ecif ied, digits are used as a number. 138 is 1 and As soon as the call originator is found, the number translations are performed on the originating gateway (see Equipment 39 ). 2. Pre-routing translation rules are applied to the received value (see Pre-routing translations 70 ). 3. Since the DST-number may change after the translations, the System tries to identify it again (whether it is a URI: sip:..... or a number: 123456). If the DST-number contains the symbol ":", then it is a URI, if not - it is a number. Then, according to the number type, the System searches for a dial peer (see the description of the parameter *DST prefix allow patterns in the DP settings). For URIs the DP tree is constructed differently: search for user@example.ru.com will be performed in the following order: com-ru-example-@-user (see the pictures and the table below). Page 287 Appendix J. Call routing according to SIP URIs DP tree construction principle for URIs and numbers DST-number type number URI 145 sip:user@test\.ru 185 .*:.*@test\.ru 327 sip:.*@test\.com 839 (sip):.*@example\.com 83(.*) sip:.* .* Page 288 Appendix J. Call routing according to SIP URIs DP tree 4. The call is routed either to a static gateway or to a gateway which location should be defined according to the request sent to the domain name system DNS, or to the RADIUS server for dynamic routing, as shown in the picture Call routing. For each call all the methods can be applied. Examples of NAPTR and SRV DNS-records SRV records used for locating SIP-servers (RFC 3263, RFC 2782) _sip.udp.sample.edu. IN SRV 1 0 5060 voip.sample.edu _sip.udp.sample.edu. IN SRV 2 0 5060 voip-standby.sample.edu Creating a SRV request Does the URI contain numeric IP-address and port? yes The specified IP-address and port will be used for the route. only address is specified only port is specified no The default port The System The System sends a request for this protocol sends a request for the SRV-record to the DNS will be used for for the A-record according to the domain name the route. to the DNS as per the Usage rules from according to the standard RFC2782. After the domain that a route is created for each name. In address. response the The SRV-request will be System receives written according to the a list of applied protocol. addresses, for Page 289 Appendix J. Call routing according to SIP URIs each of which there will be a route. The prefix “_sip._udp.” will be added to the domain part of the URI (i.e. for “sip:user@example.com” the request will be performed according to “_sip._udp.example.com.”) Sending a request according to “Usage rules” from RFC2782 Are there any mistakes in response to the request? Does the amount of the received records exceed 0? yes no Is there only one record? Is the target equal to“.” (root domain)? A-record will be requested according to the domain name yes no There will be no route for the call Received records will be sorted according to the priority (from the lowest to the highest), and within each priority the records will be sorted randomly according to the weight (the more the weight, the higher the probability of being selected). If the value of the Target field is not a numeric IP-address, then according to this field the list of addresses will be received for each element. The route will be constructed for each address using the address and port. The terminating device URI Resolver is used to route calls according to URIs (Uniform Resource Identifier for SIP-protocol). See the picture below and the section Equipment 39 . Call routing The external routing algorithm is described in the chapter Termination 69 . Page 290 Appendix J. Call routing according to SIP URIs If URI is selected as a number, this original URI (including all parameters) will be used in the corresponding field in the INVITE message sent to the terminating device. This rule applies for determination of source numbers and number translations. URIs can be used as numbers when working with the RADIUS server. This feature is supported in all RADIUS messages. Page 291 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 17 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 The utility mvts3g-combineCDRs-export combines detail records of calls with participation of Switch Class 4 and Switch Class 5. The utility uses its own DB, which can be located on another server. See the format of the combined CDR in the table below: Field name in combined CDR Field name in Switch Class 4 CDR Field name in Switch Class 5 CDR Description info_comb_cdr_id Combined CDR ID info_comb_cdr_date Combined CDR date inleg_cdr_id cdr_id cdr_id CDR ID (outgoing leg) outleg_cdr_id cdr_id cdr_id CDR ID (incoming leg) inleg_cdr_type CDR type (incoming leg) outleg_cdr_type CDR type (outgoing leg) info_guid inleg_cdr_date stamp cdr_date class5_cdr_date CDR GUID CDR date (incoming leg) cdr_date Switch Class 5 CDR date outleg_cdr_date cdr_date CDR date (outgoing leg) inleg_ani in_ani src_in Incoming SRC number inleg_dnis in_dnis dst_in Incoming DST number outleg_ani out_ani src_out Outgoing SRC number outleg_dnis out_dnis dst_out Outgoing DST number info_bill_ani bill_ani SRC number for billing info_bill_dnis bill_dnis DST number for billing info_src src SRC number in the internal numbering plan info_dst dst DST number in the internal numbering plan info_effective_src effective_src Effective SRC number info_direction direction Direction info_dvo dvo Value-added services info_sig_node_name sig_node_name Signaling node Page 292 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 Field name in combined CDR Field name in Switch Class 4 CDR Field name in Switch Class 5 CDR inleg_remote_gatekeeper _address src_gatekeeper_ad dress Orig. gatekeeper address inleg_remote_sig_addres s remote_src_sig_ad remote_src_sig_ad dress dress Remote orig. signaling gatekeeper address outleg_remote_sig_addre remote_dst_sig_ad remote_dst_sig_ad ss dress dress Description Remote address term. signaling inleg_remote_media_addr remote_src_media_ remote_src_media_ ess address address Remote orig. media address outleg_remote_media_ad dress remote_dst_media_ remote_dst_media_ address address Remote term. media address inleg_local_sig_address local_src_sig_addr local_src_sig_addr ess ess Local orig. signaling address local_dst_sig_addr local_dst_sig_addr outleg_local_sig_address ess ess Local term. signaling address inleg_local_media_addres local_src_media_a s ddress local_src_media_ad dress Local orig. media address outleg_local_media_addr local_dst_media_a ess ddress local_dst_media_ad dress Local term. media address inleg_proto in_leg_proto in_leg_proto Incoming leg protocol outleg_proto out_leg_proto out_leg_proto Outgoing leg protocol conf_id_ts_in TS conference ID for the incoming leg (Switch Class 5) inleg_ts_conf_id inleg_conf_id conf_id class5_conf_id outleg_conf_id TS conference ID for the incoming leg (Switch Class 4) conf_id TS conference ID (Switch Class 4) conf_id outleg_ts_conf_id TS conference ID (Switch Class 5) conf_id_ts_out TS conference ID for the incoming leg (Switch Class 5) inleg_call_id in_leg_call_id call_id_in Incoming TS Call ID outleg_call_id out_leg_call_id call_id_out Outgoing TS Call ID inleg_user src_user RAS name device of initiating Page 293 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 Field name in combined CDR Field name in Switch Class 4 CDR Field name in Switch Class 5 CDR Description outleg_user dst_user RAS name of terminating device info_radius_user radius_user RADIUS user name src_name Initiating gateway outleg_gw_name dst_name Terminating gateway info_dp_name dp_name Dial peer name info_route_name route_name Route name inleg_originator_id originator_id Originator's ID inleg_originator_guid originator_guid Initiator's GUID inleg_originator_type originator_type Initiator type inleg_originator_name originator_name Initiator name inleg_originator_terminal _id originator_terminal _id Originator terminal ID outleg_terminator_id terminator_id Terminating device ID outleg_terminator_guid terminator_guid Terminating device GUID outleg_outleg_terminator _type terminator_type Terminating device type outleg_terminator_name terminator_name Terminating device name outleg_terminator_termin al_id terminator_terminal Terminating device terminal _id ID inleg_remote_originator_i d remote_originator_i d Remote originator ID inleg_remote_originator_ guid remote_originator_ guid Remote originator GUID inleg_remote_originator_ name remote_originator_ name Remote originator type inleg_remote_originator_t ype remote_originator_t ype Remote originator name outleg_remote_terminator _id remote_terminator_i Remote terminating device d ID outleg_remote_terminator _guid remote_terminator_ Remote terminating device guid GUID outleg_remote_terminator _name remote_terminator_ Remote terminating device name type Page 294 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 Field name in combined CDR Field name in Switch Class 4 CDR Field name in Switch Class 5 CDR Description outleg_remote_terminator _type remote_terminator_ Remote terminating device type name info_domain_id domain_id Domain ID info_domain_guid domain_guid Domain GUID info_domain_path domain_path Domain path inleg_elapsed_time elapsed_time class5_elapsed_time Call duration (incoming leg) elapsed_time Call duration (Switch Class 5) outleg_elapsed_time term_elapsed_time Call duration (outgoing leg) inleg_setup_time setup_time Setup time (incoming leg) class5_setup_time start_time Setup time (Switch Class 5) outleg_setup_time term_setup_time Setup time (outgoing leg) inleg_connect_time connect_time Connect time (incoming leg) class5_connect_time connect_time Connect time (Switch Class 5) outleg_connect_time connect_time Connect time (outgoing leg) inleg_disconnect_time disconnect_time Disconnect time (incoming leg) class5_disconnect_time outleg_disconnect_time disconnect_time term_disconnect_ti me Disconnect Class 5) time (Switch Disconnect time (outgoing leg) disconnect_initiato info_disconnect_initiator r disconnect_initiator Disconnect initiator info_disconnect_code disconnect_code Disconnect code info_disconnect_reason user_disconnect_c ode Disconnect code info_disconnect_code_d esc disconnect_reason Disconnect code description info_q850_reason disconnect_code q850_reason info_q931_reason Q.850 disconnect code q931_code Q.931 disconnect code inleg_codecs in_leg_codecs in_leg_codecs Incoming leg codecs outleg_codecs out_leg_codecs out_leg_codecs Outgoing leg codecs inleg_faststart_present src_faststart_present SRC Faststart present Page 295 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 Field name in combined CDR Field name in Switch Class 4 CDR Field name in Switch Class 5 CDR Description outleg_faststart_present dst_faststart_present DST Faststart present inleg_tunneling_present src_tunneling_present SRC Tunneling outleg_tunneling_present dst_tunneling_present DST Tunneling info_proxy_mode proxy_mode Proxy mode info_lar_fault_reason lar_fault_reason LAR fault reason info_route_retries route_retries Routing retries inleg_scd scd SCD in the incoming leg, msec outleg_scd term_scd SCD in the outgoing leg, msec inleg_pdd pdd PDD in the incoming leg, msec outleg_pdd term_pdd PDD in the outgoing leg, msec info_media_group media_group Media group proxy_mode inleg_media_bytes_from_ src_media_bytes_i src_media_bytes_i orig n n Orig. media bytes in inleg_media_bytes_to_or src_media_bytes_o src_media_bytes_o ig ut ut Orig. media bytes out outleg_media_bytes_fro m_term dst_media_bytes_i dst_media_bytes_i n n outleg_media_bytes_to_t dst_media_bytes_ erm out Term. media bytes in dst_media_bytes_o ut Term. media bytes out inleg_media_packets_fro m_orig src_media_packets src_media_packets _in inleg_media_packets_to_ orig src_media_packets _out Orig. media packets Orig. media packets out outleg_media_packets_fr dst_media_packets om_term dst_media_packets _in Term. media packets outleg_media_packets_to _term dst_media_packets _out Term. media packets out src_media_packets src_media_packets inleg_media_packets_late _late _late Orig. media packets late outleg_media_packets_la dst_media_packets dst_media_packets te _late _late Term. media packets late inleg_media_packets_lost src_media_packets src_media_packets Orig. media packets lost Page 296 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 Field name in combined CDR Field name in Switch Class 4 CDR _lost Field name in Switch Class 5 CDR Description _lost outleg_media_packets_lo dst_media_packets dst_media_packets st _lost _lost Term. media packets lost inleg_min_jitter_size src_min_jitter_size src_min_jitter_size Min. jitter buffer for packets from orig. device, msec inleg_max_jitter_size src_max_jitter_size src_max_jitter_size Max. jitter buffer for packets from orig. device, msec dst_min_jitter_size dst_min_jitter_size Min. jitter buffer for packets from terminating device, msec outleg_max_jitter_size dst_max_jitter_size dst_max_jitter_size Max. jitter buffer for packets from terminating device, msec info_last_cdr last_cdr Last CDR inleg_cpc in_cpc outleg_min_jitter_size info_cpc cpc_in Calling subscriber category on the incoming leg cpc Calling party category outleg_cpc out_cpc cpc_out Calling subscriber category on the outgoing leg inleg_zone in_zone in_zone Orig. zone outleg_zone out_zone out_zone Term. zone inleg_ani_type_of_numb er in_ani_type_of_nu in_ani_type_of_nu mber mber Type of number incoming SRC inleg_dnis_type_of_num in_dnis_type_of_n in_dnis_type_of_n ber umber umber Type of number incoming DST outleg_ani_type_of_num out_ani_type_of_n out_ani_type_of_n Type of ber umber umber number outgoing SRC outleg_dnis_type_of_nu mber outgoing DST out_dnis_type_of_ out_dnis_type_of_ Type of number number number info_src_ton src_ton SRC number type info_dst_ton dst_ton DST number type info_effective_src_ton effective_src_ton Type of number effective SRC inleg_proto_conf_id src_in_leg_conf_id protocol_conf_id Conference ID of protocol inleg_proto_call_id src_in_leg_call_id call_id_in_proto Incoming Call ID of protocol outleg_proto_call_id src_out_leg_call_i call_id_out_proto Outgoing Call ID of protocol Page 297 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 Field name in combined CDR Field name in Switch Class 4 CDR Field name in Switch Class 5 CDR Description d inleg_diversion_number in_orig_dnis originator_diversio n Incoming redirecting number outleg_diversion_number out_orig_dnis terminator_diversio n Outgoing redirecting number originator_diversio n_reason Incoming reason call diversion inleg_diversion_reason terminator_diversio Outgoing n_reason reason call diversion outleg_diversion_reason inleg_disconnect_codes src_disconnect_co aux_src_disconnect Additional disconnect codes des _code on the outgoing leg dst_disconnect_co aux_dst_disconnec Additional disconnect codes outleg_disconnect_codes des t_code on the incoming leg info_record_type record_type Record type info_extradata extradata Additional parameters info_external_router external_router External routing server info_radius_group radius_group Name of RADIUS group inleg_in_ani_screening in_ani_screening SRC screening indicator in the incoming leg inleg_in_ani_presentatio n in_ani_presentatio n SRC presentation indicator in the outgoing leg outleg_out_ani_screenin g out_ani_screening SRC screening indicator in the incoming leg outleg_out_ani_presentat out_ani_presentati ion on SRC presentation indicator in the outgoing leg Utility structure After the installation of RTU the utility is located in the directory /usr/local/lib/mvtspro/ gluingCDRs. It consists of the following directories and executable files: Directories: ./conf contains the configuration file autoexport-cdrs.conf with utility settings; ./data contains the file map_fields.csv, which defines the format of the combined CDR and whether or not it should be exported. In this file you can also configure the presence and sequence of CDR fields during the export; ./database_schema contains the DB scheme, which serves to store the combined CDRs and also CDRs of Switch Cl. 4 and Cl. 5 not combined at the moment; ./variables contains the files to which the latest exported CDR ID and other variables are saved during the export from the DB of Switch Class 4 and Class 5; Page 298 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 ./loaded_cdrs is used to store files with CDRs, exported from Switch Cl. 4 and Cl. 5 DB and CDRs not combined at the moment from the utility database. The files have the corresponding prefix: c4_ - Switch Class 4; c5_ - Switch Class 5; uncomb_c4 - Switch Class 4 CDRs, which were not combined after previous launches of the utility; uncomb_c5 - Switch Class 5 CDRs, which were not combined after previous launches of the utility. All files in the directory ./variables have backup copies with extension .backup, each file also has a copy with .default extension where all variables have initial values. The directory /usr/local/lib/mvtspro contains the example of the file combineCDRs-export which contains 3 executable files: mvts3g- unloader_cdrs.py exports the CDRs of Switch Class 4 and Switch Class 5, and also CDRs that are not combined at the moment, from the utility DB to the directory ./loaded_cdrs. processer_cdrs.py combines CDRs exported to the directory ./loaded_cdrs and saves them to the utility DB. export_cdrs.py exports combined CDRs and also expired uncombined CDRs. After that all expired CDRs are deleted. These files are executed one after another with a certain interval. Description of utility parameters The configuration file autoexport-cdrs.conf contains the main parameters of the utility: Section [common]describes the global parameters of the utility: file_map_cdrs_fields = ./data/map_fields.csv trace_level = 3 file_map_cdrs_fields – path to the configuration file, describing the correspondence between the fields of a combined call detail record and CDRs of Switch Class 4 and Switch Class 5. trace_level - log trace level. The default value - 3; 0 - write CRITICAL messages; 1 - write CRITICAL, ERROR messages; 2 - write CRITICAL, ERROR, WARNING messages; 3 - write CRITICAL, ERROR, WARNING, INFO messages; 4 - write CRITICAL, ERROR, WARNING, INFO, DEBUG messages; Section [class4]contains the parameters of Switch Class 4 CDRs: enable = 1 load_period = 5 address = localhost database = rtu user = **** password = **** balancing_groups = transit-group min_cdr_time = 2012-01-01 01:01:01 Page 299 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 storage_period_of_uncomb_cdrs = 1 notify_about_old_uncomb_cdrs = 1 enable - enables the export of CDRs from Switch Class 4 DB, and also their further participation in combining. With the value 0, CDRs from Switch Class 4 DB will not be exported; load_period – interval between transfers of CDRs groups from Switch Class 4 DB to the utility DB, in seconds. Amount of CDRs in a group by default – 10000. Switch Class 4 DB access parameters are the following: аddress – IP-address; database – database name; user – user name; password – password; balancing_groups - list of Switch Class 4 balancing groups, separated by a comma; min_cdr_time - start date/time of CDRs combining (the System combines only those CDRs which were written to the DB after 2012-01-01 01:01:01 (in this example)); storage_period_of_uncomb_cdrs - storage period for uncombined CDRs for further combining (in days); notify_about_old_uncomb_cdrs - notify the user of deletion of uncombined Switch Class 4 CDRs during the export (performed at the same time as the export of combined CDRs) upon the expiration of the storage period. Section [class5]contains the parameters of Switch Class 5 CDRs. enable = 1 load_period = 5 address = localhost database = centrex user = **** password = **** balancing_groups = subscriber-logic min_cdr_time = 2012-01-01 01:01:01 storage_period_of_uncomb_cdrs = 1 notify_about_old_uncomb_cdrs = 1 enable - enables the export of CDRs from Switch Class 5 DB and their participation in combining. With the value 0, CDRs will not be exported from the Switch Class 5 DB; load_period – interval between transfers of CDRs groups from Switch Class 5 DB to the utility DB, in seconds. Amount of CDRs in a group by default – 10000; Switch Class 5 DB access parameters are the following: аddress – IP-address; database – database name; user – user name; password – password; Page 300 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 balancing_groups - list of Switch Class 5 balancing groups, separated by a comma; min_cdr_time - start date/time of CDRs combining (the System combines only those CDRs which were written to the DB after 2012-01-01 01:01:01 (in this example)); storage_period_of_uncomb_cdrs - storage period of uncombined Switch Class 5 CDRs, in days; notify_about_old_uncomb_cdrs - notify the user of deletion of uncombined Switch Class 5 CDRs upon the expiration of the storage period. Section[join_cdrs]contains the parameters of combined CDRs: enable = 1 address = localhost database = join_cdrs user = **** password = **** storage_period = 30 enable – enables the process of combining CDRs of Switch Class 4 and Switch Class 5. If the value is 0, CDRs will be saved and upon the expiration of the storage period they will be exported as uncombined; The utility DB access parameters are the following: address – IP-address; database – database name; user – user name; password – password; storage_period – period of storage of combined CDRs in the utility database, in days (upon expiration CDRs are deleted from the DB). Section [unload_cdrs]contains the parameters of export of combined CDRs: enable = 1 export_uncomb_cdrs_class4 = 1 export_uncomb_cdrs_class5 = 1 path = /tmp/ min_cdr_time = 2012-01-01 01:01:01 delimiter = ; join_cdr_filename_prefix = j_; uncomb_cdr_c4_filename_prefix = uncomb_c4_; uncomb_cdr_c5_filename_prefix = uncomb_c5_; enable - enables the export of combined CDRs. In case the value is 0, CDRs will not be exported; export_uncomb_cdrs_class4 - enables the export of uncombined CDRs of Switch Class 4 after the storage period is over; export_uncomb_cdrs_class5 - enables the export of uncombined CDRs of Switch Class 5 after the storage period is over; path – export directory; Page 301 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 min_cdr_time – date and time of the first export of the combined CDRs. Storage period for combined CDRs is specified in the parameter storage_period; delimiter - delimiter, used in the csv-format of exported combined CDR-files; join_cdr_filename_prefix - prefix for files with joined CDRs; uncomb_cdr_c4_filename_prefix - prefix for files with Switch Class 4 CDRs, for which no Switch Class 5 match was found; uncomb_cdr_c5_filename_prefix - prefix for files with Switch Class 5 CDRs, for which no Switch Class 4 match was found. Section [ftp]contains the following parameters of CDR-s export to the ftp-server: enable = 0 host = x.x.x.x user = **** password = **** path = /bill/ delete_transferred_files = 1 passive_mode = 1 enable - enable/disable the CDR export to the ftp-server. By default - disabled; host - ftp-server address; user - user; password - password; path - directory on the ftp-server for CDR export; delete_transferred_files - delete files with CDRs from the local disk, if they were exported to the ftp-server. By default - to delete; passive_mode - ftp-server mode. By default - passive. Bef ore exp ort to the f tp -server CDRs should be exp orted to the directory, sp ecif ied in the f ield path f rom the section [unload_cdrs] 301 . Instead of **** enter the necessary values. Utility configuration 1. Configure the DB access Set the access parameters in the configuration file autoexport-cdrs.conf. You can either create a user with access rights to this DB in MySQL or give the access rights to the DB of the utility from the parameter database (section [join_cdrs]) to the already existing user (for that you can use the utility mysql_user.sh described in the Installation and Setup Guide). When creating or editing the user account, specify the IP-address, used to run the utility. 2. Specify the values of the parameter min_cdr_time of sections [class4] and [class5] according to the amount of CDRs in Switch Class 4 and Class 5, combined during the period starting from the specified values. 3. In the settings of Switch Class 4 and Class 5 select the same moment of filling the CDR Date field (upon establishing the connection or upon ending a call), as this field is used to define the right border while selecting a CDR from the database of Switch Class 4 and Class 5. 4. Select the set of fields in the exported combined CDRs. For that edit the file ./data/ map_fields.csv and specify the corresponding value in the column export: 1 - export the field, 0 - do not export. Order of fields in the files with exported CDRs is determined by the order of lines in the specified file. Page 302 Appendix L. Combining CDRs of Switch Class 4 and Switch Class 5 5. To configure cron-tasks of the utility, use the file /usr/local/lib/mvtspro/mvts3gcombineCDRs-export. The following comments should be added to this file: # 0,15,30,45 * * * * root /usr/local/lib/mvtspro/gluingCDRs/unload_cdrs.py # 10,25,40,55 * processer_cdrs.py * # 5,20,35,50 * * * * root /usr/local/lib/mvtspro/gluingCDRs/export_cdrs.py * * root /usr/local/lib/mvtspro/gluingCDRs/ Specify the necessary values in the parameters of start time. Description of the executable files see above. In case there is a redundant server, you can lighten the load on the main server by selecting CDRs of Switch Class 4 and Class 5 f rom dif f erent servers. The utility writes a log to the file /var/log/mvts3g/autoexport-cdrs.log. Notifications of utility malfunctions are configured through the configuration file /etc/mvts3g/ mvts3g-mail.conf (refer to document [3]). If expired uncombined CDRs of Switch Class 4 and Class 5 were found during the export of combined CDRs, the user will be notified of the amount of such records and of the period of their storage (separately for Switch Class 4 and Class 5). Page 303 Appendix M. Dial peer generation and selection 18 Appendix M. Dial peer generation and selection The System creates the dial peer tree as follows: 1. The System uses the field DST prefix allow patterns in the DP settings for dial peer tree generation. 2. The characters valid for tree generation are digits and the character #, while the character ^ is ignored. If the allowed DST prefix pattern comprises any other character, the System stops the creation of the tree out of the dial peer DST number pattern and places the the dial peer to the node of the created tree branch. This means that all dial peers, which DST number patterns start with any character other than a digit or ^, will be placed into the root group of the tree. 3. Dial peers pertaining to the same node are united into a group and sorted by priority in descending order. For example, let's take the following dial peers: dp1 - 123 dp2 - ^124[1,2] , priority - 100 dp3 - 124.*, priority - 200 dp4 - [7-8] 910 dp5 - 12[0-5] * The System will generate the tree as shown below: During the routing process the System selects dial peers as follows: 1. The System discards branches that do not correspond to the called number (DST number). For example, the called number is 1241. Then the System will discard the following branches: Page 304 Appendix M. Dial peer generation and selection 2. The System takes the remaining dial peers groups and creates a list of DPs, putting the DP groups most corresponding to the DST number to the top. This is also the stage when the System discards dial peers by their other properties (SRC number, schedule, etc.). In our example: 3. If one of the dial peers has the Stop route hunting after this DP checkbox selected, all DPs below this DP will be discarded from the list. Suppose, that "dp3" has the checkbox selected. Then the list will look as follows: 4. The System sorts each DP group by the results of the routing policy if all DPs in the groups have the same routing policy assigned. If the routing polices are different, no sorting takes place in the group. Thus, in our example the System will select the dial peer "dp3" for routing the call to the number 1241. If the dial peer gateways are unavailable, the call is rejected. If the checkbox Use common sort for dial peers 137 is selected in the System global settings, then all found dial peers are joined into one group and sorted according to the results of the routing policy (if the routing policy is the same for all dial peers) or according to the priority (if the DP routing policies are different or missing, or if the statistics is disabled in the DP settings). With the checkbox selected, all found dial peers are sorted regardless of groups formed according to the length of matched prefix. The DP tree for URI will be generated differently (for more information refer to Appendix J. Call routing according to SIP URIs 287 ). The external routing algorithm is described in the chapter Termination 69 . Page 305 Appendix N. Media groups 19 Appendix N. Media groups Media groups are essentially balancing groups containing media nodes only. Media groups are used to assign traffic for certain calls to be processed by certain balancing groups, containing media nodes. This may be useful in a geographically distributed configuration of the System where it is required that calls originating in a region were processed by the System part located in the same region. Each gateway is assigned a media group. Groups are assigned individually in the parameters Orig. Media group and Term. Media group depending on the role of the gateway (originator or terminator) If selecting a route means entering proxying mode, the System chooses one of the media nodes in the media group to which the terminator belongs. Media data for the call will be handled by this node. If on media node is available in the group, nodes are chosen from the media group of the originator. If media nodes of the originator are also unavailable, the call is disconnected. On a media node is chosen, further routing does not affect this choice. A media group may also be received from the RADIUS server during external routing and authorization. If a media group was received during external routing procedure in the field xpgkxrouting-routing in the parameter MEDIAGROUP (for an old format)or the parameter mediaGroup (for the new format) it overrides the terminator's group. If the media group was received in the field xpgk-media-group-id during the authorization procedure, it replaces the originator's group. Page 306 Appendix O. Call Disconnection Causes 20 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 65536 TS 0 [Common] Unspecified 16 603 65537 TS 1 [Common] No compatible codecs 88 415 65538 TS 2 [H.323] Signaling channel disconnected 41 603 65539 TS 3 [H.323] Control channel disconnected 41 603 65540 TS 4 [H.323] Failed to open signaling channel 47 603 65541 TS 5 [H.323] Failed to connect signaling channel 27 603 65542 TS 6 [H.323] Unknown control channel mode 41 603 65543 TS 7 [H.323] Socket read/write error 41 603 65544 TS 8 [H.323] Procedure failure 29 603 65545 TS 9 [SIP] ACK not received 21 603 65546 TS 10 [SIP] BYE received 16 603 65547 TS 11 [System] Failed to send CallBegin message 21 500 65548 TS 12 [System] Traffic Manager response timeout 21 503 65549 TS 13 [Common] Failed to process media parameters 34 503 65550 TS 14 [System] Normal system shutdown 16 603 65554 TS 18 [Common] Maximum call time exceeded 31 603 65555 TS 19 [SIP] Gateway pinging failed 16 603 65556 TS 20 [SIP] Failed re-INVITE procedure in 200-ACK mode 16 603 65574 TS 38 [System] License number of concurrent calls exceeded 34 503 65575 TS 39 [SIP] Request timeout 16 408 65576 TS 40 [System] Traffic Manager responded 16 500 Page 307 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP with unsupported signaling protocol 65577 TS 41 [Common] No appropriate routes 34 500 65580 TS 44 [System] Signaling node crashed 16 603 65581 TS 45 [SIP] Socket error 16 503 65582 TS 46 [Common] Funded call time exceeded 16 603 65583 TS 47 [Common] Originator and terminator 21 media proxy modes incompatible 415 65587 TS 51 [SIP] Failed to create socket 16 603 65588 TS 52 [SIP] Failed to create URI from given alias 16 603 65590 TS 54 [SIP] ACK without SDP received in 16 200-ACK mode 603 65591 TS 55 [SIP] No SDP available 16 603 65597 TS 61 [Common] Forceful call discontinuation 16 603 65598 TS 62 [H.323] Outgoing location request rejected 21 603 65600 TS 64 [Common] RTP Timeout 34 503 65602 TS 66 [SIP] PRACK not received 16 500 65603 TS 67 [SIP] PRACK failed 16 603 65604 TS 68 [SIP] No answer 16 603 65605 TS 69 [SIP] Invalid provisional response 16 400 65606 TS 70 [Common] Alerting timeout 34 408 65607 TS 71 [H.323] First answer timeout 16 603 65608 TS 72 [Common] Connect timeout 16 603 65609 TS 73 [Common] Media not acceptable 34 488 65610 TS 74 [SIP] REFER rejected 16 488 65611 TS 75 [SIP] Invalid SDP 16 400 65612 TS 76 [SIP] Invalid request 16 400 65613 TS 77 [SIP] Failed to redirect 16 404 Page 308 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 65619 TS 83 [SIP] Invalid X-Mera-Source-IP header 16 403 65620 TS 84 [SIP] Invalid SDP from originator 16 400 65621 TS 85 [SIP] Invalid SDP from terminator 16 503 65622 TS 86 [Common] No authentication data for outgoing connection 16 503 65623 TS 87 [System] Media node is down 16 503 65626 TS 90 [System] Failed to create terminator for Internal protocol 21 500 65627 TS 91 [System] Failed to set up media channel for Internal protocol 21 500 503 65630 TS 94 [SS7] Setup processing timer expired 47 in SS7 call or too many reservation attempts 65631 TS 95 [ISUP] No free circuits available 34 503 65633 TS 97 [ISUP] T7 timer expired (wait for ACM) 31 408 65634 TS 98 [ISUP] T9 timer expired (wait for ANM) 19 408 65635 TS 99 [ISUP] Remote hardware blocking request received 42 500 65637 TS 101 [ISUP] DPC is unavailable 27 404 65638 TS 102 [ISUP] Mandatory parameters missing in IAM request 96 500 65639 TS 103 [ISUP] Current congestion level does 42 not allow sending IAM 480 65640 TS 104 [MGCP] Failed to create connection 21 500 65641 TS 105 [MGCP] Failed to set connection mode 21 500 65642 TS 106 [MGCP] Failed to update remote SDP 21 500 65643 TS 107 [ISUP] Unexpected RLC received 101 500 65644 TS 108 [ISUP] Local circuit reset 41 500 65645 TS 109 [ISUP] RSC received 41 500 Page 309 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 65646 TS 110 [MGCP] Media connection was deleted on gateway 21 500 65647 TS 111 [SS7] SS7 node was restarted due to termination request 41 500 65648 TS 112 [SS7] Target SS7 zone not found 21 500 65649 TS 113 SS7 Node, CallControl module has not started yet: termination request 16 503 65650 TS 114 Available ss7 node not found 21 500 65651 TS 115 First answer from ss7 node timeout 21 500 65652 TS 116 SS7 node down 21 500 65653 TS 117 Max CPS rate exceeded 16 503 65654 TS 118 Terminate all processed calls in CallControl by request order 41 500 65656 TS 120 Synchro node considered request obsolete 21 403 65657 TS 121 Reserve request timeout 16 603 65659 TS 123 Logic5 node down 21 500 65660 TS 124 Call does not exist 16 603 65661 TS 125 MGCP: tHist timer expired 41 500 65662 TS 126 MGCP: max number of retransmissions exceeded 41 500 65663 TS 127 ISUP: unequipped circuit 44 500 65664 TS 128 Switch proxy mode fail 21 500 65665 TS 129 ControlLink: TCS Answer transaction has expired 16 603 65667 TS 131 Incompatible codec policy 21 415 65668 TS 132 ISUP: dual seizure 41 500 65669 TS 133 MiniIsup unconfigured 21 500 65675 TS 139 BYE received before connect 16 487 65676 TS 140 Call is already terminating 16 500 65677 TS 141 Connect on route request 34 404 65679 TS 143 SS7 Node: Can't find link 21 500 Page 310 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 65680 TS 144 Media request fail 34 503 65681 TS 145 Can't update media 34 503 65682 TS 146 [MGCP] Endpoint disconnected 21 500 65683 TS 147 [MGCP] Endpoint is not used because it is not configured 21 500 65684 TS 148 Media node was shut down 34 503 65687 TS 151 Dropped by originator connect timeout 16 408 65688 TS 152 Dropped by terminator connect timeout after setup 16 408 16 603 65700 TS 164 SIP-T: Internal disconnect (Call ended because ISUP:REL was generated. Possible reason: timer T6 went off after ISUP:SUS) 65703 TS 167 [MGCP] Endpoint is blocked 21 500 41 500 65706 TS 170 REL was received during handling incoming IAM (when processing incoming IAM, TS received a REL message. Possible reason: originator disconnected a call before CallBegin was sent) 65704 TS 168 [ISUP] Circuit is blocked 34 503 65705 TS 169 [SS7] Failed to send CallBegin 41 500 131072 Q.850 0 Normal call clearing 0 603 131073 Q.850 1 Unallocated (unassigned) number 1 404 131074 Q.850 2 No route to specified transit network 2 404 131075 Q.850 3 No route to destination 3 404 131076 Q.850 4 Send special information tone 4 603 131077 Q.850 5 Misdialled trunk prefix 5 603 131078 Q.850 6 Channel unacceptable 6 415 131079 Q.850 7 Call awarded and being delivered in an established channel 7 603 131080 Q.850 8 Preemption 8 603 Page 311 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 131081 Q.850 9 Preemption - circuit reserved for reuse 9 603 131088 Q.850 16 Normal call clearing 16 603 131089 Q.850 17 User busy 17 486 131090 Q.850 18 No user responding 18 480 131091 Q.850 19 No answer from user (user alerted) 19 480 131092 Q.850 20 Subscriber absent 20 404 131093 Q.850 21 Call rejected 21 403 131094 Q.850 22 Number changed 22 603 131095 Q.850 23 Redirection to new destination 23 603 131097 Q.850 25 Exchange routing error 25 603 131098 Q.850 26 Non-selected user clearing 26 603 131099 Q.850 27 Destination out of order 27 502 131100 Q.850 28 Invalid number format (address incomplete) 28 484 131101 Q.850 29 Facility rejected 29 501 131102 Q.850 30 Response to STATUS ENQUIRY 30 603 131103 Q.850 31 Normal, unspecified 31 603 131106 Q.850 34 No circuit/channel available 34 503 131110 Q.850 38 Network out of order 38 480 131113 Q.850 41 Temporary failure 41 503 131114 Q.850 42 Switching equipment congestion 42 603 131115 Q.850 43 Access information discarded 43 603 131116 Q.850 44 Requested circuit/channel not available 44 603 131118 Q.850 46 Precedence call blocked 46 603 131119 Q.850 47 Resource unavailable, unspecified 47 503 131121 Q.850 49 Quality of service not available 49 603 131122 Q.850 50 Requested facility not subscribed 50 603 131124 Q.850 52 Outgoing calls barred 52 503 Page 312 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 131125 Q.850 53 Outgoing calls barred within CUG 53 603 131127 Q.850 55 Incoming calls barred within CUG 55 603 131129 Q.850 57 Bearer capability not authorized 57 603 131130 Q.850 58 Bearer capability not presently available 58 603 62 603 131134 Q.850 62 Inconsistency in designated outgoing access information and subscriber class 131135 Q.850 63 Service or option not available, unspecified 63 603 131137 Q.850 65 Bearer capability not implemented 65 603 131138 Q.850 66 Channel type not implemented 66 603 131141 Q.850 69 Requested facility not implemented 69 603 131142 Q.850 70 Only restricted digital information bearer capability is available 70 603 131151 Q.850 79 Service or option not implemented, unspecified 79 603 131153 Q.850 81 Invalid call reference value 81 603 131154 Q.850 82 Identified channel does not exist 82 603 131155 Q.850 83 A suspended call exists, but this call identity does not 83 603 131156 Q.850 84 Call identity in use 84 603 131157 Q.850 85 No call suspended 85 603 131158 Q.850 86 Call having the requested call identity 86 has been cleared 603 131159 Q.850 87 User not member of CUG 87 603 131160 Q.850 88 Incompatible destination 88 503 131162 Q.850 90 Non-existent CUG 90 603 131163 Q.850 91 Invalid transit network selection 91 603 131167 Q.850 95 Invalid message, unspecified 95 603 131168 Q.850 96 Mandatory information element is missing 96 603 Page 313 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 131169 Q.850 97 Message type non-existent or not implemented 97 603 131170 Q.850 98 Message not compatible with call state or message type non-existent or 98 not implemented 603 131171 Q.850 99 Information element/parameter nonexistent or not implemented 99 603 131172 Q.850 100 Invalid information element contents 100 603 131173 Q.850 101 Message not compatible with call state 101 603 131174 Q.850 102 Recovery on timer expiry 102 603 131175 Q.850 103 Parameter non-existent or not implemented, passed on 103 603 131182 Q.850 110 Message with unrecognized parameter, discarded 110 603 131183 Q.850 111 Protocol error, unspecified 111 500 131199 Q.850 127 Interworking, unspecified 127 603 131328 Q.850 256 Unknown reason 16 603 262544 SIP 400 Bad Request 16 400 262545 SIP 401 Unauthorized 21 401 262546 SIP 402 Payment Required 16 402 262547 SIP 403 Forbidden 21 403 262548 SIP 404 Not Found 20 404 262549 SIP 405 Method Not Allowed 16 405 262550 SIP 406 Not Acceptable 16 406 262551 SIP 407 Proxy Authentication Required 16 407 262552 SIP 408 Request Timeout 16 408 262554 SIP 410 Gone 16 410 262557 SIP 413 Request Entity Too Large 16 413 262558 SIP 414 Request-URI Too Long 16 414 262559 SIP 415 Unsupported Media Type 6 415 262560 SIP 416 Unsupported URI Scheme 16 416 Page 314 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 262564 SIP 420 Bad Extension 16 420 262565 SIP 421 Extension Required 16 421 262567 SIP 423 Interval Too Brief 16 423 262624 SIP 480 Temporarily Unavailable 41 480 262625 SIP 481 Call/Transaction Does Not Exist 16 481 262626 SIP 482 Loop Detected 16 482 262627 SIP 483 Too Many Hops 16 483 262628 SIP 484 Address Incomplete 28 484 262629 SIP 485 Ambiguous 16 485 262630 SIP 486 Busy Here 17 486 262631 SIP 487 Request Terminated 16 487 262632 SIP 488 Not Acceptable Here 6 488 262635 SIP 491 Request Pending 16 491 262637 SIP 493 Undecipherable 16 493 262644 SIP 500 Server Internal Error 111 500 262645 SIP 501 Not Implemented 29 501 262646 SIP 502 Bad Gateway 27 502 262647 SIP 503 Service Unavailable 34 503 262648 SIP 504 Server Time-out 18 504 262649 SIP 505 Version Not Supported 16 505 262657 SIP 513 Message Too Large 16 513 262744 SIP 600 Busy Everywhere 17 600 262747 SIP 603 Decline 21 603 262748 SIP 604 Does Not Exist Anywhere 16 604 262750 SIP 606 Not Acceptable 16 606 2097152 Class 4 0 Unspecified 31 603 2097153 Class 4 1 Unregistered IP Address 21 403 2097155 Class 4 3 No dialpeers found 3 404 2097156 Class 4 4 Originator Capacity Exceeded 34 503 Page 315 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP 2097157 Class 4 5 Terminator Capacity Exceeded 34 503 2097158 Class 4 6 Dial peer Capacity Exceeded 34 503 2097168 Class 4 16 No DST number for route 1 403 2097169 Class 4 17 No compatible routes found 111 404 2097170 Class 4 18 Empty originator capability 21 415 2097171 Class 4 19 No registration record found 21 404 2097173 Class 4 21 Pre-Routing Translation Stack Overflow 111 500 2097174 Class 4 22 Received AccessReject For AccessRequest 21 403 21 403 2097175 Class 4 23 Received AccessAccept With Rejecting h323-return-code For AccessRequest 2097176 Class 4 24 No Response For AccessRequest 21 504 2097178 Class 4 26 Received AccessReject For External 21 Routing Request AccessRequest 403 21 403 2097179 Class 4 27 Received AccessAccept With Rejecting h323-return-code For External Routing Request AccessRequest 2097192 Class 4 40 Gateway Is Invalid 21 500 2097193 Class 4 41 Originator required authorization while there are no enabled RADIUS 21 603 2097194 Class 4 42 Insufficient Bandwidth 34 503 2097195 Class 4 43 Kicked 42 503 2097198 Class 4 46 Failed link to signaling node 21 500 2097199 Class 4 47 Scripting node failure 21 500 2097200 Class 4 48 Gateway capacity exceeded 34 503 2097201 Class 4 49 Group capacity exceeded 34 503 2097202 Class 4 50 Unable to write CDRs 21 500 2097204 Class 4 52 DB is not loaded into the scripting node 21 503 2097205 Class 4 53 The average time of CallBegin 41 480 Page 316 Appendix O. Call Disconnection Causes Universal code Group Code Cause Translation Translation to to H.323 SIP processing exceeded 2097206 Class 4 54 RADIUS response timeout 41 480 2097207 Class 4 55 Timeout No response to CallBegin message has expired 41 480 2097208 Class 4 56 No endpoint number received from RADIUS 41 480 2097209 Class 4 57 Unknown media group 41 480 21 403 21 403 2097210 Class 4 58 Received AccessAccept with incorrect h323-credit-time for AccessRequest 2097211 Class 4 59 Not enough data to send AccessRequest to RADIUS Page 317 Appendix P. List of DB alarms 21 Appendix P. List of DB alarms The table below presents a list of alarms currently generated by the DB. For more information about notification configuration, refer to document [3]. Alarm ID Severity Notification text Description DBREPL001 MINOR Replication restarted The utility detected a failure of the replication procedure, which on host 'NAME' was automatically fixed. DBREPL002 MINOR Replication not on host 'NAME' DBREPL003 MINOR Replication unknown An unexpected error occurred in the replication control utility. error on host 'NAME' DBREPL004 CRITICAL Replication failure The utility detected a failure of detected on host the replication procedure, but it was unable to fix it automatically. 'NAME' DBSERVICE MAJOR DBERROR CRITICAL Error: Process 'pid' already run MySQLdb.MySQLError: 'error' DISKSPACE CRITICAL Directory Available. Error: Process already run found Replication was not set up. Either set up replication, or disable automatic monitoring of the replication state. 'PID' The utility for CDR table rotation is already running. The utility for CDR table rotation is already running, the connection to the DB is unavailable. Limit The amount of free disk space allocated for a specific filesystem dropped below the configured threshold (for details, refer to document [4] 10 , section 12.4 "mvts3g-diskspace"). DS_MYSQL_D CRITICAL Not enough disk space B Disk space is normal DS_MYSQL_L CRITICAL Not enough disk space OG The amount of free disk space allocated for a specific filesystem dropped below the configured threshold. MySQL DBMS was stopped (for details, refer to document [4] 10 , section 12.4 "mvts3g-diskspace"). The amount of free disk space allocated for a specific filesystem came back to normal. MySQL DBMS was started (for details, refer to document [4] 10 , section 12.4 "mvts3g-diskspace"). The amount of free disk space allocated for a specific filesystem dropped below the configured threshold. Logging was disabled (for details, refer to document [4] 10 , section 12.4 "mvts3gdiskspace"). Page 318 Appendix P. List of DB alarms Alarm ID Severity Notification text Description Disk space is normal The amount of free disk space allocated for a specific filesystem came back to normal. Logging was resumed (for details, refer to document [4] 10 , section 12.4 "mvts3g-diskspace"). LO4CDR002 CRITICAL CDRs are saved to temporary files on disk, as they cannot be put in a queue. The parameter Backup CDR notification timeout, sec 138 from System global settings defines the number of times that this notification is sent. LO4CDR003 MAJOR Failed to restore temporarily saved CDRs: cannot save CDRs to DB. LO4CDR004 MAJOR Failed to restore temporarily saved CDRs: all incorrect files were moved to 'unrestoredcdrs'. DB4CDR003 MAJOR Unable to connect to the database while restoring CDRs from the binlogs DB4CDR004 CRITICAL Unable to restore queries to the database and write them to the file DB4CDR001 MAJOR LO4CDR006 CRITICAL CDR-queue is full. WARNING: Duplicate CDRs were found! {amount of such CDRs} Size of normal. LO4CDR007 LO4CDR008 CDR-queue CRITICAL CDR-queue available. is In case of such problem, CDRs will be written to the disk. CDRqueue is not full. is not In case of such problem, CDRs will be written to the disk. CDR-queue available. is CRITICAL Current CDR-table unavailable within hour. is an Current CDR-table available. is Page 319 Appendix P. List of DB alarms Alarm ID Severity Notification text Description CDRs are saved to the DB. If the CDR queue is full and the DB is unavailable, CDRs are saved to the disk. LO4CDR009 CRITICAL CDR-Storage available is not No more CDRs can be stored. Note that the calls are not received until the problem is fixed. CDR-Storage available is CDRs storage is resumed. The calls are received. Page 320

mvts pro 1.9.0-21 administrator's manual eng

Related documents

Products

Support

mvts pro 1.9.0-21 administrator's manual eng

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib