![]() |
1.2.13. Tunneling and encryption
2.1.10. Alerting and daily report
2.1.16. Direct command interface
2.1.18. Self-check and reporting
3.1. Server configuration checklist
3.5. Server backup, recovery and maintenance
3.5.3. Built-in database backup
3.5.4. Using backup database tables
3.5.7. Alternative backup deletion
3.5.9. MSSQL Server and MSSQL Studio
3.5.10. How to make a manual backup
3.5.11. How to set up automated backup
3.5.12. Dual Server Configuration
4.5.8. Invoice and payment storage
4.8.3. Gateway Advanced Settings
4.8.6. Handling incoming calls from GSM network
4.8.7. Operator friendly gsm termination
4.8.8. How to setup a gateway behind a NAT
4.9.10. Campaign and global settings
4.10.5. Automatic software upgrades
4.11. PBX / IPCentrex functionality
4.11.2. Ring Groups and Call Fork
4.11.9. Call Waiting and queuing
4.11.18. Calling Card services
4.11.19. Phone to Phone (P2P) calls
4.11.24. Unified communication
4.12.13. Encryption and tunneling
4.13. Security and account limiting
4.13.3. Socket/stream level network protection
4.13.4. Address level network attack preventions
4.13.5. Session level protection
4.13.10. SSL/TLS/WSS/HTTPS setup
4.13.15. Maximum simultaneous call limits
4.13.16. Prepaid account credit limits
4.13.17. Postpaid account monthly spend limits
4.13.18. Fix daily credit limits
4.13.19. Dynamic credit/spent limits
4.13.20. Daily/monthly call duration limits
4.13.24. Billing and profitability
5.1. How to make a H323 call directly to a GW (without the gatekeeper)
5.2. Sometimes the voice channel is breaking down. How can I improve the voice quality?
5.4. How can I make test calls?
5.5. How to check the call quality on a specific channel?
5.6. Typical Cisco H.323 Config
5.7. Server Recovery (in a separate app and db server configuration)
5.8. No incoming calls (no new calls in current call list in peak time)
5.9. Calls in „routing” status
5.11. SIP called cannot be called
5.14. No voice (caller and called cannot hear each-other)
5.15. Too many wrong calls on a simpacket (low ASR/ACL)
5.16. Not enough or too many calls on a sim or simpacket
5.17. Calls are routed to wrong simcards
5.20. SIM cards with low credit
5.22. GSM Gateway malfunctions
5.23. Wrong disconnect reasons
5.24. MManage cannot connect to the server
5.26. Server software problem (service unavailable)
5.27. Server OS, Database or Hardware problem (server unavailable)
5.28. How to restart the server service
5.29. How to restart the server box
5.30. How to restart a GSM gateway
5.31. How are the incoming calls from the gsm network handled?
5.32. Routing test calls to a dedicated gateway
5.33. How to disable PIN request on GSM gateways
5.34. What are the minimal global settings that must be correct on servers?
5.35. How to add a new traffic sender?
5.36. How to add a new sip enduser?
5.37. How to add a new Mizu VoIP-GSM gateway to the server?
5.38. How to add new simcards (sim packet)?
5.39. How to add a new simcard?
5.40. How to set up basic routing?
5.41. How to set up basic billing?
5.42. Where can I check the logs and traces?
5.43. The conversation volume is too loud. How can I change the volume?
5.44. How to register your Mizu Gateway to a H323 gatekeeper?
5.45. What ports are used in the system?
5.46. My gateway restarts too often
5.48. How to set up the automatic credit recharge?
5.49. The automatic credit recharge is not working
5.50. How to monitor the credit automation?
5.51. Gateway and channels are inactive
5.53. How to set up holiday billing
5.54. How to treat specific weekends as weekdays
5.56. SimChange settings from the command line
5.57. How to reenable blacklisted but good numbers
5.58. How are different currencies handled?
5.60. How the check your ASR (or ACD, SL, CDRC) for the traffic sender “A” in the last week.
5.61. How to add endusers (basic settings)
5.65. How to reserve GSM capacity for a certain protocoll
5.67. How to setup a new virtual server instance
5.68. Handling dynamic & private ip/port
5.71. Redirect or forward sessions to other domains
5.72. Delete old database backup
5.75. How to scan your SP for live numbers
5.76. Routing calls from virtual servers
5.77. Routing calls to virtual servers
5.78. How to add plugins in MManage
5.79. Request/response target address
5.81. Automatic prepaid credit expirity
5.83. Short number and internal billing
5.84. Cropping sound on ring when playing voice (ringtone, announcement or any other prompt
5.85. How to play user credit in IVR
5.87. Ringtone for IVR forwarded calls
5.88. How to enable codec transcoding
5.89. Possible NATs and firewalls
5.90. How to disable CLI for all outgoing calls
5.91. How to change the database username/password
5.92. Performance optimizations -fine-tune
5.93. How to reset a failowered gateway/direction
5.94. How to remove the 3 digit techprefix system wide setting
5.95. How to enable H.323 modules?
5.96. How to add SMS provider(s)?
5.97. Working with groups using direct SQL
5.99. CLI settings / A and B numbers / Dial plan.
5.100. How to rewrite caller/called numbers
5.100. How to play advertisement for the callers.
5.102. How to bind IIS webservice to a single interface?
5.103. What are the typical bandwidth requirements for VoIP?
5.104. How the softphone autoupgrade works?
5.106. How to setup a registered SIP server
5.108. Quality statistics (whithout extended cdrinfo)
5.109. How to obtain geolocation and advanced call quality statistics
5.111. How to recalculate the prices for certain cdr
5.112. How to create different webportal for different resellers
5.118. How to check the current load on MS-SQL (query list)
5.119. Load data from all tables from the database (for multiple servers)
5.120. Number of services limit on a server
5.121. How to rewrite SMS number prefix
5.122. How to limit the maximum monthly usage for postpaid accounts
5.123. Not enough storage is available to process this command
5.127. Prices for toll free numbers
5.129. External service, database or API
5.130. How to setup Moneybookers (Skrill)
5.131. Reliability –strict locking
5.132. How to verify audio quality
5.133. How to use long called prefix lists for routing
5.134. Send email to users on low credit
5.136. Analyzing mizu server log files
5.137. How to set customer disconnect reason code?
5.141. Encrypted/hashed password
5.142. How to run multiple webportals
5.143. How to remove duplicates from the number portability table
5.144. How to black-list/white-list client devices
5.146. Network and IP address configuration
5.151. What happens when user calls itself
5.152. Route calls between the local users via the upper server
5.153. Tunnel quality statistics
5.154. Turn the server to an open relay
5.155. How to handle Tech Prefix
5.156. Route incoming calls to user groups
5.157. How to prevent SIM card blocking
5.158. How to play a voice file before calls
5.159. How to enable VoIP push notifications?
5.160. Cannot listen on port 80
5.161. How to run an query in all database
5.162. How to rewrite SIP messages
5.163. How to remove the user=phone from the request URI
5.164. How to change the domain part in the From SIP header
5.165. How to set the Identity header
5.167. Configure SIP Load balancer
5.169. How to backup database to a network drive
5.171. How to block any client on a particular destination
5.177. Caller banning to specific directions
5.178. Fine-tune caller banning to specific directions
5.180. Manaually remove upper push registrations
5.181. Query user register state
5.182. How to set advanced user settings?
5.183. How to set a random caller-ID?
5.187. SQL to reset upperserver register routing
5.188. SQL to reset user multi-device addresses
About
This document provides an overall technical description of Mizu VoIP platform. For non technical user guides please check out our website. Your installation may not include all modules described in this document and you will notice small changes if you program version doesn’t conform to the documented version!
Version
MizuServer v.9.6 Administrator’s Guide
Revisited May 18, 2022
Copyright
Mizu server and other MizuVoIP software are copyrighted by MizuTech SRL. -Copyright ©2006-2021 MizuTech SRL.
This document may not be copied or readdressed in whole or part without the expressed, written consent from MizuTech SRL.
Disclaimer: MizuTech SRL reserves the right to change any information found in this document without any written notice to the user.
License Agreement and Trademark Acknowledgement
You must accept the license agreement (LicenseAgreement) before you use any Mizu hardware or software component!
The softswitch core is licensed by proprietary Mizutech license: All rights reserved for Mizutech.
Some of the extra modules are licensed by separate license terms. (These modules are included in unmodified binary format and integrated with the Softswitch via their API)
LINUX is a registered trademark of Linus Torvalds in the United States and other countries.
Windows and Microsoft SQL Server is a trademark of Microsoft Corporation, registered in the United States and other countries.
Oracle is a registered trademark of Oracle Corporation.
OpenSSL are licensed under OpenSSL license: https://www.openssl.org/source/license.txt
Freeswitch licensed under the MPL 1.1.
OpenSSL are licensed under OpenSSL license: https://www.openssl.org/source/license.txt
Freeswitch licensed under the MPL 1.1: https://wiki.freeswitch.org/wiki/Licensing
OpenH323 (used in test tools) are licensed under MPL: http://www.mozilla.org/MPL/MPL-1.0.html. Source code is included on the install CD.
Other logos, products, brand names and service names contained in this document are the property of their respective owners (trademarks or registered trademarks of their respective companies)
Introduction
This document describes the administration of Mizu Gateways, SoftSwitches and CallCenters. A unique set of proprietary software and hardware based capabilities and processes to build up a VoIP network, including planning and network management.
These components are designed to cover the telecommunication needs for small to very large companies and VoIP carriers. The main power of the system is the sophisticated VoIP components, which are strongly used in today’s telecommunication infrastructures.
The Mizu components can be used as standalone or as centralized intelligent VoIP platform, capable to handle millions of minutes/month.
Ø MS-SQL backend (Express or Full versions) or embedded database
Ø Ethernet 10/100/1000 Base-T
Ø Static IP, PPPoE (DSL or cable modem), DialUpISDN,VPN
Ø Encrypted communications
Ø Virtual servers
Ø STUN/ICE Support
Ø NAT Support
Ø Near-End and Far-End NAT traversal
Ø Multi-homed and multi-domain support
Ø Compliant with SIP rfc's
Ø UDP, TCP and TLS transports
Ø Proxy server
Ø Registrar server
Ø Location server
Ø Redirect server
Ø B2B routing
Ø PBX features
Ø Transcoding B2BUA
Ø Conference Server
Ø SBC (Session Border Controller)
Ø Routed and Direct voice
Ø Automatic NAT detection
Ø DID Direct Inward Dialing
Ø Voice Recording and Playback
Ø Absent Subscriber
Ø Abbreviated Dialing
Ø Multiple Subscriber Aliases
Ø Anonymous Call Rejection
Ø Access Control Lists
Ø Call Baring Incoming/Outgoing
Ø Toll Restriction
Ø Parallel Hunting
Ø Click 2 Call
Ø CLIP/CLIR
Ø DTMF generation
Ø Call-Forward on out-of-service
Ø Codec transcoding
Ø Advanced statistics support
Ø NAT traversal of signaling
Ø NAT traversal of media
Ø SIP Session timers
Ø RTP Timers and media timeout
Ø Blind SIP Registration
Ø Late Codec Negotiation
Ø Multiple SIP registrations per user account
Ø Can act as an SBC
Ø Max Session Setting
Ø Manage Presence
Ø Detailed call logs
Ø SIP/SIMPLE
Ø SIP Reinvites
Ø SIP-H.323 protocol conversion
Ø WebRTC-SIP protocol conversion
Ø Class 4 features
Ø Class 5 features
Ø RFC 2543 compatibility
Ø RFC 3261 compatibility
Ø RFC 2976 The SIP INFO Method
Ø RFC 3262 Reliability of Provisional Responses in Session Initiation
Ø RFC 2617 HTTP Authentication
Ø RFC 3263 Locating SIP Servers
Ø RFC 3265 Specific Event Notification
Ø RFC 3420 Internet Media Type message/sipfrag
Ø RFC 3515 Refer Method
Ø RFC 3311 UPDATE Method
Ø RFC 3581 Symmetric Response Routing
Ø RFC 3842 Message Summary and Message Waiting Indication Event Package
Ø RFC 3891 "Replaces" Header
Ø RFC 3325 Private Extensions to the Session Initiation
Ø RFC 2778 A Model for Presence and Instant Messaging
Ø RFC 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging
Ø RFC 1889 RTP: A Transport for Real-Time Applications
Ø RFC 2190 RTP Payload Format for H.263 Video Streams -only routing
Ø RFC 2327 SDP: Session Description Protocol
Ø RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
Ø RFC 3264 An Offer/Answer Model with Session Description Protocol
Ø RFC 3550 RTP: A Transport Protocol for Real-Time Applications -replaces RFC 1889
Ø RFC 3555 MIME Type Registration of RTP Payload Formats
Ø RFC 3911 The SIP "Join" Header
Ø RFC 3324 Network Asserted Identity
Ø RFC 3326 The Reason Header Field
Ø RFC 3581 Symmetric Response Routing
Ø draft-ietf-mmusic-ice-02 A Methodology for NAT Traversal for Multimedia Session Establishment Protocols
Ø draft-ietf-avt-rtp-ilbc-04
Ø draft-ietf-sipping-cc-transfer Call Control - Transfer
Ø draft-ietf-sip-referredby-05
Ø Custom protocol extensions are possible
Ø G.723.1
Ø G.729
Ø G.711 A-law
Ø G.711 u-law
Ø GSM 06.10
Ø GSM
Ø Speex 2,3,4,5,6 (narrowband, wideband and ultra-wideband)
Ø Opus
Ø G.726 (16,24,32,40 KHz)
Ø G.722
Ø T.38
Ø DTMF
Ø Custom 1 kbits codec
Ø All other codec’s for pass-trough
Ø Voice:
· Adaptive de-jitter buffer
· Voice Activity Detection/Silence Suppression
· Recording conversations (In Stereo caller/callee left/right)
· QoS
· Packet saver technology
Ø Call Forward All/Busy/No Answer
Ø Caller ID
Ø RingGrouops
Ø Call Return
Ø Call Waiting
Ø Call Forking
Ø Call Hold/Retrieve
Ø Caller ID Block
Ø Selective Caller ID Blocking/Unblocking
Ø Speed Dial
Ø Direct Inward Dialing (DID)
Ø Three-Way Calling, Conference support
Ø Message Waiting Indicator
Ø Call transfer, Attended transfer, Unattended transfer
Ø IVR (all applications: call, callback, p2p, forward, etc)
Ø
VoiceMail 2 Email
DTMF transcoding on server side
Ø Interactive Voice Response (IVR) supporting applications such as credit card and prepaid services
Ø Video
Ø Conference calls
Ø T.38 fax relay
Ø SMS relay
Ø SMS commands (callback, P2P)
Ø Web interface
Ø Automatic Call Distribution: like simple automatic dialing, power dialing, predictive dialing, predictive intelligent dialing
Ø IVR
Ø Call Recoding: All calls can be recorded and stored
Ø Real time call check out: Supervisors can listen to the ongoing calls real time
Ø PBX Features: Call hold, call wait, call transfer, call forward (conditional and unconditional), call conference, CLIP, CLIR
Ø Customizable Scripts: script tree, with any number of branches, answers, and reason codes.
Ø Customizable IVR: Any number of language, any number of branches, voice and faxmail, call transfer to the operators
Ø Statistic generation: customer statistics, operator statistics, call related statistics, work time statistics, campaign statistics
Ø Campaign creation: supervisors can create a campaigns
Ø Invitation letter: customization, and automatic printing
Ø Report generation: Specific hourly, daily and weekly reports
Ø ACD Features
Ø Unlimited accounts / Unlimited Extensions
Ø Automatic pincode generation
Ø Flexibile authentication (digest,IP,port,user,etc)
Ø Custom Routing Rules
Ø Multi-Carrier Support
Ø ACL
Ø Sophisticated configurations
Ø Load Balancing on available devices
Ø Rerouting
Ø Number rewriting (calling and called)
Ø Failowering (multiple levels)
Ø Least Cost Routing
Ø BRS -quality based routing
Ø Call Control Features (Maximum Talk Time, Max Ring Time)
Ø Call routing based on PLMN tariff packages
Ø Blacklist/White list filtering
Ø Time of Day Routing
Ø Direct Inward Dialing (DID)
Ø Route capacity
Ø Outbound Dial Map
Ø Speed Dial Numbers
Ø Auto call forwarding
Ø ANI Routing
Ø IP Blacklists
Ø Custom VoIP Providers
Ø Fraud detection tools
Ø Support for NAT traversal
Ø
Automatic capacity rebalancing
Remote Linked Servers
Ø Automatic channel management
Ø Number portability support
Ø User authentication by username/password, IP address, techprefix, caller number
Ø GeoIP database
Ø Automatic SIM allocation:
Rules can be defined on multiple levels: global, partner, gateway, engine, simpacket, simcard, time
-Static
-will not modify gw settings
-Limits
-sl (day/month)
-packet allowed intervals
-min/max lines for partner
-Priorities
-sim partnerm, sim, gw
-Desired
-desired minute on packet
-packet multiplier
-Rotate
-“minrotateival”, “desired”, “maxrotateival”
-Price
-min/max pricediff on obj, maxpricepermin for system/partner
-Timetable
-BRS
-LCR
-and many other options
Ø Flexible Rate Definition (peak/off-peak/flat/custom, end-user/provider/reseller/sales, etc)
Ø Automatic and Real Time billing (CDRs already includes the prices)
Ø Prepaid and Postpaid platforms
Ø Call Credit Limit Control
Ø Unlimited reseller accounts
Ø Callshops
Ø Directions (traffic sender,prefix,gateway,sim packet) and time based billing.
Ø Reporting and price comparisons (LCR)
Ø Balance and rating with SIP signaling or HTTP requests
Ø Invoice generation in different formats, PDF generation, email scheduler and invoice printing
Ø Complete call rating & accounting services for complex rating schemes
Ø Currency and VAT can be set for every packet. Time zone can be changed.
Ø Automatic online currency conversion
Ø Paypal and lot’s of other payment gateways are supported
Ø Pin Generation Management
Ø Pin-less Number Registration
Ø Support for multiple account types
Ø Management of PINs generation, activation and deactivation
Ø Support for unlimited number of PINs
Ø Ability to deactivate accounts after certain period or date
Ø Import and export of PIN batches
Ø Management of call limit per PIN
Ø Routing restrictions
Ø Max call duration management
Ø Automatic User Generation
The Mizu VoIP server has full support for WebRTC since version 7.4 (including websocket SIP signaling and DTLS/SRTP encoding/decoding)
Ø
H.323 Standard Features
(v.1,2,3,4)
SIP-H.323 protocol conversion (Signaling and media when needed)
Ø Full H.323 proxy
Ø H.225.0 Call Signaling
Ø Fast Connect/Fast Start
Ø H.245
Ø H245 tunneling
Ø H245 in setup
Ø DTMF send/receive
Ø Watchdog
Ø Direct endpoint call signaling.
Ø Gatekeeper routed: call signaling (H.225.0).
Ø Gatekeeper routed: call signaling (H.225.0) and control channel (H.245)
Ø Gatekeeper routed: call signaling (H.225.0), control channel (H.245) and voice
Ø RTP Port Range (For firewalls)
Ø Child Gatekeeper capability
Ø Backup Gatekeeper capability
Ø Gatekeeper clustering support (neighbors, parent/child, alternates)
GSM components are not included with the default standard install and the required hardware is for extra costs.
Please contact us about the possibilities.
Hardware Components
No hardware components are required for H323 and SIP networks.
VoIP-GSM hardware listing:
VoIP-GSM gateway
-8 channel gateway, best fit to any cheap DSL connection
-up to 64 simcard/gateway
-SIM server interworking capability
-Integrated antenna splitter
SIM Server
-up to 750 simcard
VoIP-GSM Server
-industrial PC
-fault tolerant
-server failowering capability
-distributed architecture
Built in watchdogs to monitor the operation of the system components
GSM features
Ø Dual Band (900 / 1800 MHz or 850 / 1900 MHz)
Ø Half rate, full rate, enhanced full rate, SMS, USSD
Ø SIM server support
Ø Integrated antenna splitter
Ø 8 channels/box
Ø Up to 8 SIM cards per engine
Ø Multiple ways to handle incoming calls
Ø Call Forwarding
Ø Sending and receiving SMS messages
Ø Email To SMS Feature
Ø Inter gateway SIM routing
Ø SIM server interworking
Ø GSM cell selection and locking
Ø DTMF send/receive
Ø CLI restriction
Ø SIM Rerouting
Ø Locking to a given gsm cell
Ø Automatic SIM credit request and charge
Ø Voice Recording and Playback (In Stereo caller/callee left/right)
Ø SIM server interworking
Ø Virtual Channels
VoIP-GSM
Ø First centralized architecture for GSM termination
Ø Unlimited Gateway and TrafficSender support
Ø Multiple signaling protocol support
Ø Load distribution between the operational channels
Ø No hard limit on the number of simultaneous calls
Ø High availability
Ø High throughput (more than 50 million minutes/month)
Ø No additional Mizu hardware required
Ø Equipment management
Ø Channel management
Ø Simcard management
Ø Automatic recharge
Ø Access Control Lists
Ø Routing (see below)
Ø Billing (see below)
Ø Exploits almost any SIM tariff model
Ø Number translation
Ø Protocol encryption
Ø Media proxy
Ø Automatic time synchronizations
Ø H.323/SIP Gateway Topology Hiding
Ø Embedded firewall
Ø Enhanced Security (automatic detection of flood attacks)
Ø Web GUI for end-users
Ø Encrypted communications
Ø License management
Ø Distributed absolute fault tolerant system
Ø External system supervisor service (email and sms alerts, watchdog can restart failed subsystems)
Ø Can be used as virtual servers
Tunneling and encryption are built-in into the Mizutech VoIP server and you can enable from the global configuration or from the Config Wizard.
Details: https://www.mizu-voip.com/Software/VoIPTunnel.aspx
Push notification support is a built-in module enable by default. Configuration and integration is described here.
Ø Centralized configuration and management for all software and hardware components
Ø MManage:
o -easy to use, mdi style
o -almost every data query is parameterized with traffic direction and time
o -all data in one place
o -lots of data can be obtained from sl,asr,acl forms
o -global system analysis
Ø Create and edit network elements
Ø Remote maintenance of Mizu gateways
Ø Display of system information
Ø Real-time call status view
Ø Service restart functions
Ø Display of the current status of each gateway and channel
Ø Real time call supervision (with many grouping options)
Ø Real time channel supervision (with many grouping options)
Ø Statistics (Text based and graphical ASR,ACD,SL, etc) on any traffic direction and time scale
Ø Disconnect Reasons (with many grouping options)
Ø
CDR monitoring, retrieval, direct
CDR access
Operator Console
Ø Global system analysis!
Ø Routing pattern selection
Ø Routing time selection
Ø Failowering (in case of channel, gateway, direction etc errors)
Ø Best Route Selection
Ø Billing module
Ø Balance module
Ø Real Time Capacity check
Ø Ability to insert queries directly into the database
Ø Blacklist filtering
Ø Self-analysis tools
Ø Detailed logging (multiple levels). Detailed call tracing capability
Ø Call simulations
Ø Reseller/Agent Registration and Management
Ø Capacity and system load reports
Ø Import/Export from/to any format (SQL, text, excel, etc)
Ø CRM Integration
Ø Restore and Backup
Ø The maximum database size for basic gateways and servers is 4GB. If you need to work with more than 5 mil calls for more than 3 month, you should upgrade your license to the advanced version and use a proper MS-SQL server (not the Express editions). This doesn’t affect servers with less then 100 simulaneous calls. You can upgrade the SQL server/service anytime later (full compatibility).
Ø Some class 5 features will work only with SIP protocol
Ø H323 GK doesn’t support username/password authentication (mostly used for call transit and not to provide enduser services over H323)
Ø RADIUS is compatible only with some servers
Ø
Mizutech doesn’t provide support
for client side (softphone) FAX and Video debugging. (FAX and Video are fully
supported by the server and will work if you are using a softphone conform the
SIP standards, however many software has limited interoperability or bugs)
For a more detailed feature list see the homepage and features pages.
Full remote administration can be done by mizutech support including continuous email support and 24/7 emergency phone support.
Contact us or visit http://www.mizu-voip.com for more details.
Email support: serversupport@mizu-voip.com
Depending on licensing, some modules may not be available in your release!
The Mizu Soft switch (Server) is the “brain” of the system. Depending on your needs, you can connect as many gateways as you want. The soft switch is built from several modules: sip stack, h323 stack, sip – h323 conversion module, media server, ACL, routing, billing, alerting. Almost all modules are installed by default and they can be enabled/disabled as needed. Key modules are listed below:
The Mizu SIP stack was written in C++. It’s very fast and robust, currently used by voip service providers and carriers handling millions of minutes.
The WebRTC module will handle VoIP calls from modern browsers. Includes also a WebRTC – SIP bridge with media relay support.
Capable to work as a simple Gateway or as a fully featured Gatekeeper.
Thank to this module, the protocol conversion is very transparent. You don’t even need to know if your partners use SIP or H323.
RTPM is used with Flash clients to convert the signaling and media between Flash and SIP/RTP.
If your server needs to route the media channels for many concurrent calls, you may need to use a separate media server, thus offloading the server traffic, and maximizing media throughput.
With the Mizu softswitch you can build very sophisticated routing scenarios. The routing is usually based on traffic direction and time. LCR and BRS routing are available.
The server will generate the detailed CDR after each call. Thus the billing can work nearly real-time. (Very important for prepaid systems). You can generate various reports and invoices based on a set of predefined rules.
The server can send various reports and alerts based on predefined rules. The reports are sent by email or SMS.
You can create up to 100 virtual servers on a single pc. These are completely separate billing/routing/signaling entities.
Manage operators, automatic call distribution, IVR and other callcenter specific tasks.
This NT service can automatically detect critical service problems and restart the VoIP server, the SQL database or the OS.
The built-in HTTP server will listen for service requests.
A separate module implementing a few extra pbx features such as voicemail and conference rooms.
Administrative tasks and class5 service requests can be handled by the command line TCP interface.
Template portal is available with source code. All common end-user tasks can be done via a user friendly web interface (new user registration, download CDR records, show statistics, setup call forwarding, payment, etc)
Various system thresholds will checked real-time and the server will do the corresponding actions automatically. The same module is responsible for daily/weekly/monthly email or SMS reports and alerts for administrators and users.
Mizu VoIP-GSM Gateways support 8 concurrent calls and up to 64 simcards.
See the features section for more details.
GSM
All standard GSM capabilities are supported.
VoIP
Mizu VoIP-GSM Gateways can accept SIP and H323 registrations, can act as a SIP proxy or a H323 Gatekeeper or Gateway. These functions can be run simultaneously.
SIM Bank
The built-in simbank will allow to virtually routing the simcards in other Mizu gateways.
Mizu VoIP-GSM Gateways can take advantage of an external simbank, so you can have all your simcards in one place, easing the maintenance and administration tasks.
server service: the brain of the system
H323 GK: standard H323 gatekeeper
SIP Server: sip stack
HTTP interface: enduser/reseller website with built-in http server
Media Server: rtp routing
VGW: voip-gsm gateway, the most essential part of the client
SMS: sending short messages over HTTP API or SMPP
client service: this service supervises the gsm gateway and gives a clear interface to the server
MManage: smart client software, capable to manage the whole system
supervisor service: this service supervises the mserver
alerter service: collects statistical information and reports it
recplayer: can play g729, g723, encrypted, raw PCM and wave files
loganalizer: log file parser
gwtest: handle gsm terminal (no h323)
ipmux: packet saver client and server
serveremulator: server interface to gk
simalloctest: test the automatic sim allocation
smtp_test: test smtp functionality
tariffcalc: estimate sim packet real price
tcperver: tcp server for test
udptest: udp through test
valerterclient: alerter sw which can be installed on client computers
vchargecards: manage chargecards
vclientinterface: platform specific functions for the gw
partnerclient: admin sw. for our partners
pricesettings: for packet price configuration
routingandprices: for config. routes, prices and sim packet priorities
servertest: brute force test for the server
supervisor: supervises the server
updater: automatically updates client software from the server ftp
mediasrv: media server for routing rtp packets
businesslgc: controls the routing, registration, endpoint list, endpoint creation, udp initialization
VPC
Simple monitoring software for business purposes. Each partner (gateway or simcard owners, traffic senders, etc) can have their own VPC to monitorize their own traffic and create reports.
VPC Setup
You can give the VPC for any of your partners. The partners can login to the VPC with the username and password configured in the “Users and Devices” form in MManage. Usually only “Owner” users will receive VPC access.
You can define what users can see in their VPC by setting the “Can watch sim packets”, “Can watch users/devices” and “Access Rights” in the user configuration form (billing tab). See section 4.3.1 for more details.
The VPC included with MManage has the capability to login as a super user. To do so, you have to enter your partner username, but use the admin password (from the “ad” account). Then you have access to the “Add Query” button in the VPC. Here you can add,delete or modify the existing queries and their access rights.
In the “rights_allow” field you can put a list of user id, “all” or “nobody” fields. The same for the “rights_deny”. Thus you can configure which partner can see and execute which queries.
When properly set up, Mizu software doesn’t need too many administration tasks. The routing will adjust automatically to the external conditions. Every software module has auto repair and cleanup features. Backup and scaling is automatically provided for you if you are using the Mizutech SaaS platform (Hosted VoIP solutions).
However if you have millions of minutes/month, you may have to watch the system parameters closely, setup proper alerting thresholds and adjust system setting as required.
3.1.1. Software’s
Windows 2003/2008/2012/2014/2016/2019/2022 server, MSSQL (Standard or Express) 2000, 2005, 2008, 2012, 2014, 2016, 2017, 2019, 2022
3.1.2. Firewall
-allow servers, FTP, IIS, MSSQL, SMTP, remote desktop (3386,3389)
-block: all others, file sharing, ms network
3.1.3. Services and memory
Auto restart critical services
For more than 3 Gb set boot.ini: /3GB /PAE on 32 bit systems
3.1.4. Licensing
Setup configuration with the proper software(s)
3.1.5. Config
Setup FTP and Voice directory NTFS access
3.1.6. MSSQL
Change port to 2223
Enable pipes
Check configuration in Management Client
Skip this chapter if you are not using VoIP-GSM gateways.
In order to get a working system, here is a checklist which may help you:
1. Connect the gateway(s) and/or the server to the network.
2. Install the MManage programs in a separate PC used for monitoring your Mizu devices. network (you can find it on the Mizu install CD which is shipped with every product)
3. Set up the gateway(s) and/or the server network parameters with the VnetCfg utility
4. Put your simcards into the gateway (see the image below)
5. Connect to the gateway or server with the MManage (by typing its ip address and username/password in the login form)
The default username/password is admin/tpwdadmin
6. Set up the basic parameters from the “Configurations” form
Be careful.
7. Set up one or more packets for the simcards in the “SIM Packets”
Be careful with the following settings: prepaid/postpaid, allowedpartners
8. Set up the simcards. You can add simcards manually, but it’s easier to wait for them to register. Then you only have to modify its packets, owners and the recharging settings (“Simcards” form)
9. Add some traffic sender in the “Users and Devices” form.
Be careful with the authorization settings
10. Set up the routing (“Routing” form)
Add at least one routing pattern (name it as you wish)
Add at least one entry to its priority list (your newly created packet or some other direction)
11. Set up advanced routing –Optional
Firewall, prefix rules, BRS, etc
12. Set up the billing module –Optional
13. You are ready to accept traffic now.
You should check at least the followings every day:
-Current Calls –to quickly check if you have the required amount of traffic
-Quality Statistics by traffic senders and terminating gateways
-Run a global system analysis (“Analyze” form)
-Check your cash flow (“billing” form) to check if your routing is still profitable
-Logs (errors and critical levels)
-Analyze your traffic by using the “Statistics” form
-Remove blacklisted but good numbers (if you are using blacklisting)
Most of the maintenance tasks are done automatically in background low priority threads and/or scheduled to offpeak times.
These followings are handled automatically:
-database tuning
-user maintenance
-background statistics
-table or record level backup to _backup database
-delete of the old records (for example old log entries)
-database backup to a predefined directory
-and many others
Since all data is stored in the SQL database, you have to protect only your database (the program directory can be recreated anytime by simple file copy or reinstall. Only the database path is stored here in the mizuserver.ini file which need to be reentered correctly after a restore).
Although there is no special maintenance needs with the mizu server, to have a working backup is a very important task to be set and tested properly. The mizu server will automatically create backups on the same server (without any additional settings), but for a real backup you have to change the backup directory to another physical location.
For more reability you should use the MS SQL backup related capabilities instead of using the mizutech built-in backup methods.
A backup refers to making copies of data so that these additional copies may be used to restore the original after a data loss event. Backups are useful primarily for two purposes. The first is to restore a state following a disaster (called disaster recovery). The second is to restore small numbers of files or records after they have been accidentally deleted or corrupted.
There are also many different ways in which the data storage devices can be arranged to provide geographic redundancy, data security, and portability.
Any backup strategy starts with a concept of a data repository. The backup data needs to be stored somehow and probably should be organized to a degree. Different repository models have different advantages. This is closely related to choosing a backup rotation scheme.
Unstructured: An unstructured repository may simply be a stack of floppy disks or CD-R/DVD-R media with minimal information about what was backed up and when. This is the easiest to implement, but probably the least likely to achieve a high level of recoverability.
Full + Incremental: A Full + Incremental repository aims to make storing several copies of the source data more feasible. At first, a full backup (of all files) is taken. After that, any number of incremental backups can be taken. There are many different types of incremental backups, but they all attempt to only backup a small amount of data relative to the full backup. Restoring a whole system to a certain point in time would require locating the full backup taken previous to that time and the incremental backups that cover the period of time between the full backup and the particular point in time to which the system is supposed to be restored. The scope of an incremental backup is typically defined as a range of time relative to other full or incremental backups. Different implementations of backup systems frequently use specialized or conflicting definitions of these terms.
Differential: A differential backup copies files that have been created or changed since the last normal or incremental backup. It does not mark files as having been backed up (in other words, the archive attribute is not cleared). If you are performing a combination of normal and differential backups, restoring files and folders requires that you have the last normal as well as the last differential backup.
Continuous data protection: Instead of scheduling periodic backups, the system immediately logs every change on the host system. This is generally done by saving byte or block-level differences rather than file-level differences. It differs from simple disk mirroring in that it enables a roll-back of the log and thus restoration of old image of data.
You can configure your database engine to do the backup tasks. If you don’t have this possibility, the Mizu Server can also make database backups. Set the following configurations:
dbmaint_backuplevel: 0=no backups,1=daily,2=daily,monthly,weekly,3=hourly,daily,monthly,weekly,4=keep lots of files
dbmaint_backupdbdir: local path (accessible for the server)
dbmaint_backupdbnetworkdir: path accessible for the database engine (it is necessary when the database is located on a separate box. Otherwise can be left empty –default to dbmaint_backupdbdir)
To keep your active size smaller, you can move the content of big database tables to another database. For example cdr records older than 5 month, etc. This backup database will be easily accessed by the MManage.
dbmaint_backuptables: backup cdr records and other tables to xxx_backup: 0=no,1=cdrs,2=extended,3=all
Frequently used and important tables are backed up daily, the other monthly.
The amount of data that is backed up can be controlled by the “dbmaint_removecdrs” (measured in days. is direct proportional with this setting)
If the dbmaint_backuptables is set to 2, than the amount of data can be controlled by the dbmaint_removeother value.
Logs are removed after dbmaint_removelogs days.
The backup databases are created with the same name as the current database with a “backup_” prefix.
If you want to place the backup tables to a separate server, you must set that backup server as a linked server in the main database and set the “linkedserver” config option in the server inifile.
The backup intervals can be controlled by the “dbmaint_backuplevel” option: //0=no backups,1=daily,2=daily,monthly,weekly,3=hourly,daily,monthly,weekly,4=full,5=keep lots of files
(be aware that if you set it to 0, than the other option will have no effect)
In order to take advantage of the backup database, you must set the “Secondary database” option in MManage to “Autodetect” or “Secondary DB”. When set to autodetect, it will attempt to load data from the backup database if the query date is set to more than 1 month later (it will failback to main database if is set to earlier than 2 week). In this case the “until” date is modified automatically to yesterday midnight when needed.
For the MManage to be able to connect to the backup database, the “backupdatabaseaddress” must be set up correctly when a separate database is used.
The server will optimize the database engine automatically.
dbmaint_do: enable/disable the daily and the monthly maintenance
dbmaint_removelogs: Trunk log tables and remove logfiles after x days
Serverftpvoice: where to store recorded audio
Serverftpdailydir: set to true to create separate directory for recorded voices daily
Keeprecorded: days to keep voice records
Voicebackupdir: backup your recorded voices to this secondary location
Keepbackuprecorded: days to keep the voice backups
The voice recording option can be set for any user by checking the “Record” checkbox on the user configuration form in MManage.
Conversation will be saved in the directory specified by the “serverftpvoice” global config option.
A separate backup can be created in the directory specified by the “voicebackupdir” global config option.
Out of date recorded files can be deleted by setting the “keeprecorded” option accordingly (days to keep).
Recorded files can are compressed and encrypted by default.
On new server installation, make sure that the voice directory are accessible via ftp for the MManage (for listening on the “CDR Record” form). To make things easier it is preferable to setup the ftp passwords the same as the database login.
You can define an alternative backup deletion method by the following values:
Deldbbackup: delete old backup files after this day elapsed
Dbbackupdir: delete from this directory and its subdirectories
You can automate backup cleanup by setting the following global config values:
Deldbbackup: days to keep (-1 disables cleenups)
Dbbackupdir: database backup directory
dbdelbackupdir1, dbdelbackupdir1, dbdelbackupdir3: database backup subdirectories
This feature is useful, when the database engine don’t have cleanup feature.
You must always have a working recovery plan.
Here is a template with dual server configuration:
if the application server fails (the server directly connected to the internet, with your public ip
1. call your ISP support to change the internet cable to the backup server, and when it will be available connect to the "backupserver" with the remote desktop "root" account
-on the backup server do the following:
2. enable the "mserver" service
3. launch the start batch file (from gk directory)
4. check the vservdebuglog and the MManage
if the backup server fails (the server behind the main server, with private ip)
-connect to the main server with the remote desktop "root" account
-On the main server, do the followings:
1. launch the stop batch file (from the gk directory)
2. Enable and Start the SQLSERVER service
3. Restore latest database
4. launch the start batch file
5. check the vservdebuglog and MManage (you must have current calls)
6. you are ready
Microsoft SQL Server is a relational model database server produced by Microsoft. Its primary query languages are T-SQL and ANSI SQL. You can work directly with the database using the client IDE tools, and several complementary systems that are packaged with SQL Server. These include: an ETL tool (SQL Server Integration Services or SSIS), a Reporting Server, an OLAP and data mining server (Analysis Services), and several messaging technologies, specifically Service Broker and Notification Services.
SQL Server Management Studio is a GUI tool included with SQL Server for configuring, managing, and administering all components within Microsoft SQL Server. The tool includes both script editors and graphical tools that work with objects and features of the server.
A central feature of SQL Server Management Studio is the Object Explorer, which allows the user to browse, select, and act upon any of the objects within the server. It can be used to visually observe and analyze query plans and optimize the database performance, among others. SQL Server Management Studio can also be used to create a new database, alter any existing database schema by adding or modifying tables and indexes, or analyze performance. It includes the query windows which provide a GUI based interface to write and execute queries.
SQL Server Management Studio can be downloaded for free from the Microsoft Website: http://www.microsoft.com/downloads/details.aspx?FamilyID=08E52AC2-1D62-45F6-9A4A-4B76A8564A2B&displaylang=en
First open Microsoft SQL Server Management Studio, open Object Explorer, open Databases, right-click with your mouse on the database you want to back up, select tasks and select Back Up from the menu.
The next window will appear:
At Source/ Database select the database that you want to back up. At Backup type select either full for full type of backup or differential, for differential backup.
At Destination click on the Add button, select the disk, and path to the file where you want to save the backup file. If this is on another server type \\ double-slash, followed by the IP address and path on the another machine.
In the Object Explorer open Management, under Management right-click with your mouse on Maintenance Plans and select New Maintenance Plan. In the small window that appears give it a name.
Click Add Subplan, Introduce names, description, and set the schedule for the given Subplan, by clicking on the small calendar icon.
The Schedule settings window looks like this:
Once the time and frequency of a given schedule is set the tasks from the left side of the window can be dragged and dropped in the field under the subplans list. For every subplan a ‘Backup database task’ and a ‘Maintenance cleanup task’ can be dragged/dropped and defined on this field.
For example you can create 3 folders in the shared folder on the application server, one for hourly differential backup which is backed up once every hour, and the backup is deleted once every day. You can create another for a full daily backup, and one for full monthly backup.
Once you drag/drop and define the backup tasks from the lower left pane to the right, the subplans will look like this:
http://support.microsoft.com/kb/930615
In the Dual Server Configuration there are two separate servers used, the application server and the database server. The MizuTech VoIP Service is running on the application server and usually a Microsoft SQL Server database is installed on the database server. The direction of the backup is from the database server to the application server, into a shared folder, so that if the database server experiences problems the other server can provide the latest backup.
In an ideal case, backup is of three kinds: an hourly differential backup and a daily full backup about the voipserver database, and a monthly full backup about all databases. For more reability you can also setup continuous backup (with replication or log sipping)
Scheduled backup tasks for MS SQL Express: http://www.diaryofaninja.com/blog/2011/02/14/howto-quick-amp-dirty-sql-express-scheduled-backup
Fee backup & FTP tools (for one single database): http://sqlbackupandftp.com/download/
http://www.sqlbackupmaster.com/download
Script for SQL backup & FTP: http://www.morrenth.com/script-to-backup-zip-and-ftp-sql-server-database.aspx
This chapter discusses the Administration of the VoIP server.
A quick tutorial can be found here.
All administration tasks can be done using the MManage (MizuManage) client application. The main module is automatically installed with the server installer, but you can also install it independently to any PC and manage your server remotely. Restricted administration is available also from the web interface. During this guide you will meet very often the “global configuration” term. This is referring for the settings configurable using the “Configurations” form (under the “Other” item). These settings are system global and are stored in the tb_settings database table (will be discussed later)
The MManage program group is shipped with all Mizu Hardware components. Occasionally you may visit our website to download the newer versions. The software is shipped as a standard windows install package. Requirements are:
-Windows 2000/XP/Vista/Win7/8/10/11/2003/2008/2012/2014/2016/2019/2022
-At least 1024x768 screen resolution for better operation
-You may need a headset for tescalls
-Network connection
Double click on the install exe and follow the instructions.
During the install procedure the following modules and files will be copied:
-MManage.exe –the main executable
-VPC.exe –admin version
-VSQLRouter service –for compressing and encrypting sql requests and answers
-VoIP client programs (SIP and H323)
-Adobe Acrobat Reader –optional (can be canceled during the install process)
-Cute PDF Writer – pdf printer driver used for reports and invoice pdf creation -optional (can be canceled during the install process)
-Utility programs: tariffcalc.exe, smtptest.exe, rptest.exe etc
-Required dll files
-Help files
-Uninstall.exe
-Other files (depending of your install package configuration, OS version, etc)
When properly installed, you are ready to login on your server(s) and/or your gateways. If you have a central server, all administration tasks can be done connecting only to the server. If your gateways are running without a server, you must connect to each gateway separately for doing administration tasks.
The following values are required on login:
App Server: server ip address
DB Server: database ip address (“default” can be used if the same as “App Server” address )
DB: Application and database instance (because a single server can hold several virtual server)
Username: login name
Password: login password
Use encryption: encrypt and compress the server communication (requires the “vsqlrouter” service to run)
Almost all tasks are done by selecting an item from the left side of the main form. For detailed descriptions please read below.
In the Menu you can find common tasks such as “Settings”, “Save As”, etc. The selected action usually has effect only on the current active form.
From the File Menu you can save, print or export the selected form. Usual database operations are performed from the Edit Menu. In the Favorites Menu you can see the most frequently used items. In the Config Menu you can find a set of helper applications explained later in this document.
In the Fields the most important form is the “Filter” which will filter almost all listing used in MManage. Here you can define your preference regarding the traffic direction including Source and Destination. You can filter on Item Type, Item, Group, Number Prefix, Packet and SIM Card. For example you may select one SIM ID, and when loading logs, you will see only the messages related to the selected simcard.
In the left-bottom side of the form, you can find an edit box used for quick search. You can use the ‘*’ character in the begin and the end of expressions. (For example when searching for CDR records).
Most of the report will be filtered after the selected Date Interval also.
In the Thresholds you can set some thresholds used for MManage. This setting doesn’t have any effects on the server or gateway. Server and gateway thresholds may be set up from the Configurations Form explained below. In the Options Windows, you can set up several important MManage parameters.
In the Help Menu you have access to documentation.
In the Licensing box you can see your server parameters (there is no effect if you change these values, because these are used only for informing you). Depending on licensing, some modules may not be available in your release! Occasionally you may need to know the software version you use, which you can find in the About box.
Example: How the check your ASR for the traffic sender “A” in the last week.
1. In the date-time drop-down list, select the “Last Week” field
2. In the “Select Direction” form set the “Source” (left side) “Type” to traffic sender, and select “A” in the “Name” drop-down list (or type “A” manually)
3. Launch the “Basic Statisitcs” form under Monitoring.
4. Clear the “Group by” option (select the first “-“ line)
5. Make sure the ASR checkbox is checked
6. Click on (Re)Load
7. Depending on current server config and current load this query may take some time (on a usual configuration this will take 2 second)
With the ease of the import –export wizard, accessible from MManage File menu, you can import and export data from/to a lots of data formats.
The following file types and databases are supported:
Access
Excel
DSN
CSV
Text
IBM-DB2
Interbase
MS-SQL
MySQL
Oracle
Paradox
DBF,dBase,FoxPro
Other datasources wich can be accessed by ADO or ODBC.
Currently running calls are listed here. Calls terminated on Mizu Gateways are displayed in separate list from other directions. You can filter the listing by selecting your preferences in the “Set Direction” box (as you can do in many other parts of the program).
The following grouping is available: by caller, by called, by called prefix, by simowner and by sim packet.
Field Explanations:
Status: engine or simcard status. Can have the following values: Gateway Disabled, Off (no info), Not Active, Gateway Disconnected, Closed, Not Ready, Ready, Dialing, Ringing, Speaking, Call Ending, DTMF, Simulating Outgoing, Simulated Incoming, Routing to SIMID, Routing to Alias, Routing
Duration: seconds elapsed from Setup (not from Connect!)
Caller: source name (user name or traffic sender name)
Called: destination name (user name or traffic sender name)
CallerNumber: the phone number of the caller party
CalledNumber: the phone number of the called party
Dialed: number routed to called user or gateway (with techprefix)
Line: the number of the gsm channel (usually from 0 to 7)
SimPos: the position of the active simslot in the current engine (usually from 0 to 7)
SIM Owner: the owner of the SIM Card
Packet: the type of the SIM Card
TodaySpeachLength: the number of active minutes on the current simcard since 00:00
ThisMonthSpeachLength: the number of active minutes on the current simcard since the first day of the current month
SIM ID: sim identification number
Shows the main traffic amount and quality parameters of your system.
CDRC: call attempt count
SL: speech length (duration in minutes)
ASR: average success ratio (percent)
ACL, ACD: average call length, average call duration (in second)
You can select any direction in the “Select Directions” Box, to check only that specific traffic. Also there are some simple groupings available:
-No grouping: will display the total sum. Chart views are supported only with this option
-Group by Called Gateway: list of destination gateway statistics
-Group by Traffic Sender: list of statistics by source
-Group by SIM Packet: statistics by SIMCard type
-Group by All caller and called
-Group by Provider Direction: statistics by called number prefix (first 4 digits)
This is an extended version of Basic Statistics. You can find more grouping options here.
In some versions is shown simply as “Statistics”.
You can make reports based on the following fields:
-CDRC: number of calls
-SL: speech length (all call duration)
-ASR: the number of successfully answered calls divided by the total number of calls attempted (seizures) Since busy signals and other rejections by the called number count as call failures, the calculated ASR value can vary depending on user behavior
-ACD: average call duration
-ASRB: average success ration, but here the “success” means a minimum amount of duration. Configurable in Settings Menu -> Thresholds Box
-ACT: average connect time. The time elapsed from setup until the connect in seconds
-SUCC: successful call count (same as ASR but not in percent)
-CCC: concurrent (simultaneous) call count
-RTP: media channel statistics
-EC: end-user costs
-PC: provider costs
-SC: sales costs
-CC: company costs
-EP: estimated enduser price/minute
-PP: estimated provider price/minute
-PF: profit value (This require your billing module to be properly configured including provider prices)
-PR: profit margin in percent
-PFE: profit from enduser (useful if you are using reseller or sales accounts)
-PFR: profit from top reseller (useful if you are using reseller accounts)
-HM: hidden minutes
You can make the grouping by minute in this form by checking the “on minute” box.
The following “group by” options are available:
-: display summary data (no groupby)
Caller and Called: group by caller and called users
Caller: group by caller (source) user
Called: group by called (destination) user
Traffic Sender: group by caller (source) user, but show only traffic senders
Called Gateway: group by called (destination) user, but show only gsm gateways
GSM Engine: group by called gsm channels
Gateway, Packet and SIM Card: group by called simcard (and show the actual gateway and packet)
SIM Card: group by called simcard
Caller IP: group by caller ip address
Week –absolute: group by week, but with sum (don’t groupby to months)
Day –absolute : group by day, but with sum (don’t groupby to weeks)
Hour –absolute: group by hour, but with sum (don’t groupby to day)
Week: group by weeks
Day: group by days
Hour: group by hours
Minute: group by minutes
Day Compare: compare current weekday with last week the same day
Called SIM Packet: group by called simcards group
Partner/Day: group by partner and day
Partner/Hour: group by partner and hour
Partner/Minute: : group by partner and minute
Called Country: : group by called user country
Called Direction: : group by callednumber zone
Provider direction (prefix):: group by callednumber prefix
Provider direction (name): group by callednumber direction
Direction and packet: group by prefix and simpacket
Provider direction and packet: group by callednumber zone and simpacket
By caller root endusers: group by billed or company callerusers
Disconnect codes in graphical form by any traffic direction.
The server will collect the reason in the most appropriate format depending on the protocols used. For example for a call from voip to gsm if the disconnect was caused by the gsm party, then you will see the GSM network reason code here. Otherwise, if the disconnect source was the caller party, and then you will see H323 or SIP reason codes here.
The most common reason codes are the followings:
-SIP, Bye: normal SIP close code
-SIP, CANCEL: the call was canceled by the caller (not connected call)
-H323, Remote endpoint application cleared call: normal H323 disconnect
-H323, Remote endpoint stopped calling: the call was canceled by the caller (not connected call)
-GSM, Normal call clearing: normal GSM close code
-GSM, Normal unspecified: normal GSM close code
-Server, Blacklisted: dropped due to ACL (blacklist)
-Wrong Media: no voice activity detected.
This is a simple listing of your channels. You can discover all simcard problems by scrolling down this list. (Missing channels are highlighted)
This module tests the capacity for the predefined direction in priority order.
Shows system utilization statistics such as concurrent calls, CPU load and RAM usage.
Note: AvM type means weighted utilization: average of max and average usage ((AVG(value) + MAX(value)) / 2)
Direct interface to the server command port. Type help to see the available commands. You can connect directly to any gateway interface.
Command defined on gateway interface:
help show this command list
info show status and important parameters
cmd launch the predefined process
exec launch the predefined process
file will send the requested file
showlog will send the last lines from the requested file
timeset will sent the current time
setini write to config file
getini read from config file
dtmf send dtmf
ftpget load from ftp
ftpput put file to ftp
selfupgrade do a selfupgrade
gwrestart restart the gateway process
pcrestart restart the gateway (hardware)
and many more as described by the API (all API commands are accessible also from console)
Raw clear text CLI access is also listening on port configured by the adminport global config option.
CLI access might be IP filtered by the remoteadmin parameter. Possible values:
0: disable
1: from localhost/127.0.0.1
2: from same machine
3: from trusted sources
4: from local lan and subnet
5: from everywhere (default)
Will connect to the server logport. The trace level depends on configuration (Open the Configuration form, type “log” in the filter box, and hit the enter button. Then you can see all options regarding to log levels)
Here you can see the log records for the server and every connected Mizu Gateways in the selected time period. You can restrict the listing by defining the source, severity or filtering.
You will get detailed system analysis in this module. Thus you can see through the system by only one mouse click. Malfunctions are colored in red.
After every call (and SMS, etc), a new CDR (call detaild record) is stored in the database tb_cdrs table (and in tb_cdrresellers when the reseller option is used).
CDRs can be filtered, analyzed, exported and lots of vital statistics are based on this records.
CDRs will contain the following fields:
Id: database identifier. Auto increment
Datum: the date-time when the CDR were inserted into the database (call end time)
Callstartdate: call start time (first INVITE sent or received)
Callenddate: first disconnect code or CANCEL/BYE received or sent
Connectdate: first 200 OK received or ACK for 200 OK sent
Connecttime: time elapsed until call fail or call pickup (routing+ringing time)
Workenddate: used for callcenters and represents the time when the operator have finished to work with the current client (CRM updates, etc)
Realduration: speech length
Discparty: disconnect origination. 1=called or gsm, 2=caller or h323, 3=router (server)
Discreason: disconnect reason code. Explanations in tb_reasoncodes
Callerid: caller database id from tb_users
Callerip: the origination ip
Callernumber: caller phone number (or sip username)
Calledid: called database id from tb_users
Simid: called simid (if any)
Calledline: Engine (phone line) or the called proxy authorization id (from tb_proxyauth)
Calledip: the ip address of the called party
OrigCalledNumber: received called party number (not modified)
Callednumber: techprefix and the normalized called number. If the server will block the call too early, than you may have the “origcallednumber” here (no techprefix and normalization)
DialedNumber (calleddialed): the forwarded called number (sometimes only the “callednumber” will be insterted here)
Rtpsent: rtp packets from caller to called. 0 if no rtp routing. At least 1 if routed. If remains 1, then routing has failed
In case of sip this means rtp packets received from the called and sent to caller successfully
Rtprec: rtp packets from called to caller. 0 if no rtp routing. At least 1 if routed. If remains 1, then routing has failed
In case of sip this means rtp packets received from the caller and sent to called successfully
Rtplost: lost rtp packets
Rtpcodec: voice codec name
Rtpname: used for gateways
Rtpframes: rtp payload framed in one udp packet
Signalin: audio signal strength into the playback device
Signalout: audio signal strength received from the audio recorder device
Jittertime: used when jitter time is reported by gateways or softphones
Tpercek: hungarian specific. deprecated
Costprovider: call cost to the provider (ex. Tmobile)
Costenduser: cost for the caller in global currency (ex: a sipuser or traffic sender)
Costenduseru: cost for the caller in user currency
Costsales: sales commission if any
Costcompany: price for the reseller company
Costadditional (costother): used for reseller prices (in the main cdr)
Recfileid: if we have recorded the voice, then after this field we can found the recorded file
Mark (marker): for special CDR records: EMAIL (e-mail), SMS (sms), FAX (fax calls), FAIL (failowered), RER (rerouted), FWD (forwarded), TRANS (transferred), CONF (conference), PRED (predictive) and to signal other important call types
Opworktime: used in callcenters to store the actual operator worktime
Opwaittime: used in callcenters to specify how much time the operator have been waiting for the current cal
Billingstep: loaded from price settings (endusercost packet)
Unitprice: loaded from price settings (endusercost packet)
Billingentry: loaded from price settings (endusercost packet)
Origduration: all original duration (because the “realduration” field can be modified on IVR 2 leg billings or when hidden charges are applied)
Resellerid: top reseller id in tb_cdrs. Actual reseller id in tb_cdrresellers.
Accessnumber: set when the call have been made trough a specified IVR access number
Origcallerid: used when the caller id have been modified during the call. For example the caller can be a “traffic sender” but after ANI or PIN authorization there is an enduser inpersonalisation
Alegduration: used for 2 leg calls (first calleg with ivr)
Blegduration: used for 2 leg calls (second calleg from ivr after callforward)
Comment: with details about the call setup and disconnect. Can contain a shortened message exchange log.
Dirid: direction name after the called number prefix
Rtpsent and rtprec is 0 when media routing has failed (if we don’t route the media, or the terminating endpoint don’t send media info to us, the system will set there values to 1, so this condition will be true)
All prices in the cdr records are calculated with VAT included!
To find out the possibilities to list the CDR record for a user, please check this wiki.
Duration lists of several traffic types.
Statistics related to callcenter operations: Campaign and operator statistics.
StartTime: operator first login in MAgent in the current day
EndTime: operator last seen time in the current day
WorkTime: time when MAgent was running
ActiveTime: time when the operator is in “Automatic Call” form and not paused
OpWaitTime (WaitTime): the time elapsed from a new call request untill the first call connect. Smaller times represent more effectiveness. (the reason for the predective dialer is to reduce this time to minimum). The value will be stored for each connected cdr record.
OpWorkTime (PTime): The time elapsed from hangup untill new call request. This will represent the time spent by the operator for data postprocessing. Quick operators will have smaller opworktimes (but can be affected by the ammount of data to store) . The value will be stored for each connected cdr record.
TotalWorktime: MAgent runtime in that day
ActiveWorktime: When the automatic dialing form is active and not in paused
Called: number of called clients
Completed: clients marked as completed. Useful for meassuring the operators effectiveness.
Invited: clients marked as invited. Useful for meassuring the operators effectiveness.
Recalls: clients marked as need recall
CDRC,SL,ASR,ACL: traditional statistics. More details here.
This form (Users and devices) will allows to manage the users of the system (Endusers, SIP users, Administrators, Tech. Support users)
The most important user type is the endusers.These are usually registered on the server using the SIP protocol. They are allowed to call each-other usually for free (presence and messaging is also enabled by default).
For high amount of inbound traffic, you should use a traffic sender user instead of an enduser (and use IP autheticaton instead of username/password based)
For outbound routing you will have to add SIP server or H323 gateway user type and set the routing properly.
If you need both to accept and sent traffic to another server (carrier) then you have to add it both as traffic sender and SIP server.
Open the “Users and devices” form to see your users. There are a few template user created during setup. You can add new user by just cloning one existing user (select an user with the appropriate type, click on the “new user” button, the select “yes” when asked for cloning). This is useful if one of the many settings must have a predefined value, so you must set it only once, then if the new users all cloned the setting will be copied also). Otherwise you can create emty records and populate the required fields. Most of the fields are optional (with a preset default value) and only a few is very important which you have to change for each user like the username, password, credit, postpaid/prepaid, IP/AuthIP and the authentication type (needauth field).
Users can also be created in batch (Config menu -> Users)
The following types of users are defined in the Mizu VoIP server:
Enduser: represents retails customers or sip devices. Endusers are usually authenticated by SIP username/password and the account can be either prepaid or postpaid
Sub-enduser: Represents sip devices or callshop cabins. One enduser can have multiple sub-enduser account.. This means that when a sub-enduser (device) makes a call, then the parent Enduser account is billed
Operator: used only for outbound callcenters and represent an Agent account
Calling-Card: this type of account can be used for inbound callcenter if you wish more separation between regural users and ivr users. Otherwise a regural enduser account can be also used for IVR authentication (calling card / PIN)
Reseller: resellers can manage their account trough the web interface and can create their own tarrifs. They can add other resellers or endusers below their account.
Owner: can be used to separate certain type of businesses. You can create one ore more owners and add all other users below the owner account
Traffic sender: from where you receive bigger amount of traffic (wholesale)
Sales: you can add sales people to the system and apply a specified rate as their discount
GSM GW: VoIP-GSM gateways
SIP Server: your otbound routes (carriers)
H323 GW/GK: any device (gateway or gatekeeper) using H323
protocol
ISDN GW: gateways to the PSTN network
SMS GW: sms gateways usually with HTTP API
Support: support people will receive automatic maintenance related
emails
Admin: admin people with special permissions (for example you need to login as an admin user to the web enduser interface to be able to have access to the customization options)
The “Users and devices” form can be filtered in many ways:
Ø quick filter field
Ø Fields menu -> Filter
Ø user type
Ø the drop down list from the user form
Ø listings initiated from other forms
Ø groups
Ø For more flexibility you might use direct SQL queries against the “tb_users” table.
You can list the users with the following filters:
-ActiveNow: gateways with received status in the last 5 minute or endusers active (register or invite received) in the last 3 hour
-Active:
-gateways with received status in the last 24 hour or when “mustbeactive” is set to 1
-endusers active (register or invite received) in the last 24 hour
-All Enabled: where the “Enabled” field is not 0
-All: all users
-New Users: users added in the last month
-New Web Registrations: users added in the last month by the web registration form
-Low Credits: will list users with credit lower than 3000
The properities can be modified from one of the following pages:
Ø Listing page (grid). All fields are listed here with add/delete/edit possibilities. The “monitor” field are updated based on current statistics and settings.
Ø Edit operator: showed only for callcenter operators to set the agent related settings
Ø Edit: the most important user settings are listed here
Ø Functions: change class5 features from here
Ø Billing: billing related options
Ø Gateway configuration: only used for linked gateways
Ø Show details: will list most of the important settings
Ø Analyze: view user statistics
The following fields are defined:
ID: database id. Auto increment
Type: user type (together with the “isoperator” field)
0: enduser (usually a sip user). -isoperator field set to 2 (default)
0: sub-enduser-isoperator set to 0
0: Operator (callcenter agent or callshop agent) -isoperator set to 1
0: Calling card –isoperator set to 6
1: reseller (usually a sip reseller)
4: sim,gw or traffic owner (sim partnerid or gateway parentid show this id)
5: traffic_sender (parentid can be a simowner or a gatewayowner)
6: sales (parentid is the reseller id)
8: gsm gw (parentid is the gatewayowner)
9: outbound sipserver (proxy or gateway) (parentid is the gatewayowner)
10: h323 gw (parentid is the gatewayowner)
11: isdn gw (parentid is the gatewayowner)
12: sms, fax,email gateway
14: support users (can operate with MManage, has ftp account)
15: admin users (can see and modify everything, can receive email/sms reports)
17: other users (for various reasons)
ParentID:
This field is very important for resellers/subresellers relationships.
Logical parent of the user. Checked for routing pattern, max lines, etc.
if a sipenduser then reseller company
if traffic sender, then traffic owner
if gateway, then gateway owner
if reseller company, than operator
BillingUserID:
Where the invoices will be sent. Credit will checked for these users
If the current type is an end-user, then can have a BillingUserID where we send the invoices. If not set or the same ID as the current, than the bills will be generated to itself. For example in a company, all bills will be sent to the boss (company address), nit the employee
IsBilledUser: set to 1 if this user is not a real service user, but a user who pays for other user. Usually this is a company who pays for its employee.
Deprecated!
UserGroup: users can call each other only if the user group is the same (default: 0)
usually users with the same parentid (reseller) has common parentid
RingGroup: a list of usernames separated by comma (all number will ring when the actual user will be called)
BelongsToCompany: when a company has more then one subscriber. Used for example for short sip numbers.
IsCompany: if the current user actually is a company
RGMode: how to use the ringgroup: 0=forked call, 1=round robin
Name: user first and last –name
Country: sip phone country (important for prefix rules)
ContactName: additional name
UseCallingCard: if has calling card (usable with pin codes)
CanDial: example: for sipuser is 1. for simowners is 0
Phone: user phone number (but not the sip phone)
Email: where the user can be contacted
Address: where the user can be contacted
Billaddress: where to send the invoices
TelNumber: sip telnumber.users can be contacted if we call there username or telnumber.
More than one DID or ANI number can be assigned for one user. For this the tb_users_othernumbers table is used where the type field is 0 for DID numbers and 1 for ANI numbers.
ShortTelnumber: sip short telnumber (for example if several users has the same BelongsToCompany field)
DisplayName: how the user will be displayed. Can be null
Username: the most important field. Used for authentification and also as a DID number. This field is unique and cannot be empty.
Password: password applicable everywhere (sip, web, VPC, etc)
Ip: sipphone, sipproxy or gsmgateway ip address. The server will overwrite with the last known ip address
AuthIp: if we want to authenticate after ip, not after username/password
More than one auth ip or domain can be used for a traffic sender. For this the tb_users_authip table is used.
NeedAuth:
-If NeedAuth is 0, then the system is an open voip relay !!!!
-If NeedAuth is 1, then AuthIP must match (usually from SIP traffic senders)
-If NeedAuth is 2, then TechPrefix must match (usually from H323)
-If NeedAuth is 3, then TechPrefix and IP must match (usually from H323)
-If NeedAuth is 4, then user/pwd must match (usually from SIP end-users)
-If NeedAuth is 5, then username must match
-If NeedAuth is 6, then AuthIP and Port must match
-If NeedAuth is 7, then AuthIP and username must match
-If NeedAuth is 8, then AuthIP and username/password must match
-If NeedAuth is 9 then AuthIP Range must match
-If NeedAuth is 10, then AuthIP Range and username/password must match
AddDate: when the user has been inserted in the database
Rights: rights on user interfaces
0: no access
10: cannot login (disabled)
20: can login but no rights
25: restricted user (for example support under reseller)
30: a normal user
40: sales
50: admin
60: general admin
AddedBy: the user id who have added this user (sales, web registration, etc)
Commission: used for sales to define their comission percent from the enduser price
Reduction: sales user can give to enduser some percent (substracted from their comission)
LateFee: applicable when the user is late paying the invoice cost
PacketID: billing for users, traffic senders
BillingDay: usually 1 (the first day in every month)
Qualification: the importance for the user. From 0 to 10. for example if the user has big priority, then we route its calls to better routes
Postpaid: if the user will prepaid or postpaid
PaymentMode: Check (0), Bank Tranfer (1), Cash (2), Else (3)
ContractNumber: contract for end-users
Allowedpartners:
Allowed traffic senders for the gateway, or allowed gateways for traffic senders.
A list of user id separated by comma or ‘*’
Note that parent users will be checked too
Enabledprefixes: can be one prefix (with any length) or a list of prefixes with 3,4 or 5 digit separated by comma.
Can be used for trafic senders and gateways too. No need to setup a separate routing pattern if you use this restriction.
EnabledTechPrefixes: enabled techprefixes for the specified gateway (3 digit length numbers separated by comma)
BlockPrefixes: list of called prefixes that will be blocked for the user (techprefix will not be considered here). Numbers listed here must have 7 digit
length and separated with comma.
ContractState: the status of the contract
0- Unknown
1- Not applicable
2 -In Progress
3 -Active
4 -Terminated
ContractComment: additional comment for sales
Credit: when postpaid, then we also can set a max amount (which will reset in every month)
Enabled: if disabled, it behaves as if it were deleted
DomainName: sipproxy domain name
Port: signaling port
TransIp: secondary signaling ip
TransPort: secondary signaling port
RouteRtpCaller: routing mode if this endpoint is the caller
0=check called settings –this is the preferred settings
1=don't touch the sdp and the rtp
2=sdp correction if necessary
3=route rtp if both behind nat
4= route rtp if caller is behind nat
5= route rtp if called is behind nat
6= route rtp if any endpoint is behind nat
7=always route rtp
RouteRtpCalled: routing mode if this endpoint is the called
0=check caller settings
1=don't touch the sdp and the rtp
2=sdp correction if necessary
3= route rtp if both behind nat
4= route rtp if caller is behind nat
5= route rtp if called is behind nat
6= route rtp if any endpoint is behind nat
7=always route rtp
If the routertp setting is set to 1 or 7, it will be applied regardless of the other endpoint setting.
RtpIp: last rtp ip
RtpPort: last rtp port
ServerRtpPort: last bind (we try to use the same for every user)
NatDetected: 0= no and don’t change, 1=no but can be changed, 2=yes but can be changed, 3 yes, and don’t change it
NatDetectDisabled: deprecated
Status: 0=inactive,1=registered, 2=speaking (if statusdate is too old, then treat as 0)
StatusDate: last status change
CalledNumber: last called number
CalledID: last called id
Discount1: discount percent. users can have discounts in for max 3 directions
Direction1: prefix. users can have discounts in for max 3 directions
Discount2: discount percent. users can have discounts in for max 3 directions
Direction2: prefix. users can have discounts in for max 3 directions
Discount3: discount percent. users can have discounts in for max 3 directions
Direction3: prefix. users can have discounts in for max 3 directions
TechPrefix:
The server can authorize and/or route the traffic after the incoming techprefix.
Sip users can have techprefixes too. this is usually common for reseller company users.
If no techprefix is specified, then it will be loaded from tb_pxrules if any.
Sim owners and vpc users can have a list of prefixes separated by comma.
If no techprefix is specified, 111 will be inserted for incoming called numbers.
If the techprefix is „-1”, then the original techprefix will be forwarded.
If the techprefix is „-2”, then the original techprefix will be inserted in cdr record (but not forwarded).
If the techprefix is empty, then only the normalized callednumber will be forwarded.
The following techprefixes are reserved for the server: 111,222,999.
Only 3 digit techprefix is allowed. If your traffic sender needs another techprefix length, you must rewrite the incoming number in the “Prefix Rules” form.
Example: protcoll: sip, Type: ip, value: your traffic sender ip, rewritefrom: oldtechprefix, rewriteto: newtechprefix.
Addtechprefix: we insert this number before the callednumber if the caller don’t send its calls with tech prefix
MaxLines: max concurrent calls allowed
maxlinetouse: deprecated
CurrCallCount: current running calls (usable for traffic senders)
enablefakegw: if we don’t have capacity, we can route h323 calls to a fake gateway to prevent congestions
candisablesim: if the router will check the disableduntil field from tb_sims
alarmat: we can ring the sipuser if it is set
forwardonbusy: telnumber where we have to forward the calls when busy
forwardonnoanswer: telnumber where we have to forward the calls when we have no answer
forwardalways: rerouting
voicemail: if we can send messages as email
mincreditonroute: if user has less credit, then we don’t even route the call
regtimeout: reregistration interval for sip proxies
maxsubsfail: we set the „nopriority” field when we reach „maxsubsfail” failed calls
subsfails: successive calls with duration smaller than 20 sec
nopriority: this gateway has lowered priority in the routing until this date
noprioritycount: successive lowered priority countminasr:
minasr: minimum asr before failovering
minacl: minimum acl before failovering
mincallcount: min. Cdr records to calculate minasr and minacl
lastrouted: last call time (applies to caller devices and users or to callers when it is a proxy)
lastcalled: last call time (applies to called devices and users)
active: applicable for gsm gateways.
display: text to display instead of username
description: important comment
comment: any comment
lastrectime: last status receive from this gsm gateway
realgw: we can have fake voip-gsm gateways
temporarilydisabled: gsmgw is temporarily disabled
onlytestcalls: we allow only calls with techprefix 999
testprefix: we allow only this techprefix
datum: when the user has been inserted into the database
mustbeactive: if the gsm gateway must be active. Will do actions if this field is 1 and the gateway is not active
notactivecount: how many time we found that the gw is not active
channelcount: gsm channel count
minline: minimum active lines. If we found less line active, then we do actions
nominlinecount: : how many time we found that the gw has not enough line
prioritypartner: this partner will have priority on this gateway
callerpriority: this caller prefix will have priority on this gateway
calledpriority: this called prefix will have priority on this gateway
autopriority: set by server. If the gateway is wrong, then we lower the priority until this time
absolutepriority: if we set it greater then for other gateways, all calls will be routed here, until it is filled, regardless to other routing settings
priority: gateway priority
swversion: gateway sw version
lastrestart: gateway last restart
cutg711: if a better codec exists for the caller (g723 or g729) than PCMU and PCMA will be not offered to the called party
pingtime: deprecated
avgkbitssec: deprecated
maxkbitssec: deprecated
bandwidth: deprecated
restartcount: gsm sw restart count
pcrestartcount: gsm gw (pc) restart count
lasterror: last error message from this gw
lastlog: last log message from this gw
sendonlyrec: where to send sip messages.
0 = received address and the address in the signaling (via,contact,etc)
1=send only to the source address
2=send only to address specified in the signaling
callsigaddr: h323 port
isfake: we can have fake voip-gsm gateways
forwardearlystart: if we can send media parameters before callstart (OK for INVITE). 2 if check called
changesptoring: if we have to change the session in progress message to ring. . 2 if check called
identityforward: we can toward these kinds of usernames and the other we rewrite to „identityrewrite”
identityrewrite: if the caller username don’t match the identityforward prefix, then we rewrite it
PlayAdv: if we can play advertisements for this user
Maxmonthlycredit: max allowed credit/month even if the user is postpaid (in ft not in filler)
Maxmonthlycreditend: max Maxmonthlycredit (because we increase Maxmonthlycredit by maxmonthlycreditinc every month if the user was active)
onlylocalaccess: traffic sender traffic will not be forwarded (can call only local users from tb_users and tb_numbers)
Maxmonthlycreditinc: determines how much money we add to Maxmonthlycredit every month
ContractNumber:
Contact Status:
0-Unknown
1-Not applicable
2-In Progress
3-Active
4-Terminated
Contract comment: any usefully comment for sales here
Noanswertimeout: will redirect if no answer received
Denyaddr: because the server will try to send the sip messages to all possibile addresses, sometime it will missroute. With this setting you can restrict the address posibilities. Check the FAQ for more details.
sendfakealert: used for gsm gateways. Specifies the timeout in sec after that the gsm gateway will send an alert to voip even if no ringing have been received from gsm network. Set to 0 or -1 to disable. Gsm gateway settings will overwrite the traffic sender settings if is not set to -1
sendsmsalert: use for support and admin acounts. Will send sms notification to the configured “phone” when a critical error occurs
sendemailalert: use for support and admin acounts. Will send email notification to the configured “email” when a critical error occurs
sendsmsreport: daily sms report for support and admins
senddailyemail: daily email report for support and admins
convertdtmf: applicable for sipproxy users
-0: DTMF messages will be forwarded as received from client
-1: INFO and RTP DTMF messages will be converted to InBand
-2: INFO and RTP DTMF messages will be forwarded and converted to InBand too.
-9: don’t forward INFO
sendmonthlyemail: monthly email report for support and admins
Missed by SMS: notify about missed calls by sms. Usually used for endusers
Missed by Email: notify about missed calls by email. Usually used for endusers
Can watch sim packets: list of packetid separated by comma, used for VPC access. The actual partner can see this simpackets with his VPC account
Can watch users/devices: list of users and gateways id separated by comma, used for VPC access. The actual partner can see this devices with his VPC account
Access Rights: specify wich fields are allowed for the user in the VPC application
0: simcard and traffic sender fields are not shown
1: simcard related fields are not shown (simid, packetname)
2: traffic sender related fields are not shown (name, username)
3: all fields are shown
CLI: CLIR and CLIP settings
0: forward always (forward asserted as normal number always!). will not hide, even if caller was set so
1: normal handling (forward asserted as normal number) -default
2: forward as asserted identity always (identityrewrite asserted)
3: forward as asserted identity only to trusted domains (identityrewrite asserted)
4: normal hide (no idenityrewrite forwarding)
5: force hide (no asserted identity too!). always hided
IsOperator: specify if the user is a callcenter operator (1) or a sub-enduser (0) or power enduser (2)
Choosecodecs: list of supported rtp payload formats in priority order separated by comma. Only one will be selected. Don’t set this field to disable
selecting only one code.
If set, than only one codec will be left in the sdp (plus the dtmf codecs). This will help, when the server answer to invitation with more than one codec in the 200.
The client should answer with the final codec in the ACK, but many endpoint fail to do so.
SessionTimer: use session keep alive.
-0: don’t use
-1: load from global config
-2: autodetect (and using the sesskeepalive interval from the global configuration)
-Other: use with the specified timeout (minutes)
For example if we set it to 5, than a UPDATE or reINVITE will be sent in every 5 minute to the other party. Please note, that the session keepalive is not the same with NAT keepalive (wich is used with every endpoint automatically)
Default users:
Owner mycompany: template for owner
GsmGw LOCAL_GW: used for advanced gateways. IP=127.0.0.1
GsmGw NOGW: used when no route found. IP=1.2.3.4, isfake=1,realgw=0
GsmGw FBACKUPGW: used to handle traffic exceed. IP=127.0.0.1, callsigaddr=1725,isfake=1,realgw=0
SipProxy: sip2h323: convert signaling form h323 to sip and from sip to h323. TechPrefix=-1,IP: 127.0.0.1?, Port?
TrafficSender: virtserver X: for routing traffic from virtual servers. AuthIPList: 192.168.0.1, TechPrefix=XXX
Enduser: PREDECTIVE_DIALER: IP: 4.3.2.1, TechPrefix?, username=cc_callbacknumber
The following fileds has direct impact to routing:
Type
ParentID
RingGroup
UserGroup
onlylocalaccess
enabledtechprefixes
accessrights
enabledprefixes
blockprefixes
enabledroutes
RGMode
TechPrefix
forward...
temporarydisabled
onlytestcalls
testprefix
prioritypartner
allowedpartners
callerpriority
calledpriority
absolutepriority
Administration of Mizu Gateways, Other GSM Gateways, H323 Endpoints, SIP Proxies, ISDN Gateways and other compatible devices. The fields are the same as for the Users (see above)
If the actual sip proxy require authentification, then we store the accounts in this table
Id: database identifier. Auto increment
Priority: Account priority (accounts will be used in priority order or in round-robin if they have equal priority)
Username: sip username used in authentification
Password: sip password used in authentification
CallerNumber: usually the same as username. If left as blank, then the server use the actual caller username.
Credit: account balance. When it reach 0, then we switch to the next account if any
DateEntered: record insertion date
LastUsed: the date-time when the server was routed some calls with this account
ProxyID: to which proxy the account belongs
Enabled: set to 0 to disable the usage of this account
SubsFails: the number of subsequent wrong calls with this account. If subsfails will reach a predefined value (30 as default), it means that there is some problem with this account or the money/time limit have been expired, and the server will switch to the next account if any
Grouping of several items will ease the administrations tasks. The following type of items can be grouped:
SIM Packets
Users
Gateways
Traffic Senders
These groups then can be used to simplify your routing and billing.
Useful when you have arranged your users in certain hierarchies. For example reseller chain relationship.
Resellers can have an unlimited child-parent relationship (limited by the ”maxresellers” global config options).
To define the relationships we use the tb_users id and parented fields.
Registration and authentication
User authentification can be done multiple ways (AuthType field in the user table).
Registration and authorization answers are cached in the Mizu server, so for subsequent requests from the same ip:port doesn’t have to query the database again. This means that if you change the password in the database it may take some time until it is considered.
Mizu server has built-in DOS attach protection. This means (among others) that after a few unsuccessful registration (wrong password) request from a UA that will be banned for a time. This banned list can be cleared from the server console with the “delbanned” command. Even whole IP ranges can be banned. For example if there are too much meaningless or not authenticated request from an IP address (probably the attacker), than that IP address will be banned for a time period and the incoming messages from that IP will be silently dropped.
Users and devices will be allowed to access the system (and create new dialogs) only if they pass basic authorization which can be set from MManage -> Users and Devices -> Edit tab.
For IVR access the server will authenticate the actual end-user based on the A number or will request a PIN code.
Basic authorization
Dialog authentication can be performed in the following ways:
-Open Relay: if you set the NeedAuth to 0 for a user, then your server becomes an open relay (this is forbidden by the “enforcestrongauth” global config by default)
-Authentication based on IP address: for this you have to set NeedAuth to 1 and enter the peer IP address in the AuthIp field (can be a list of ip address separated by comma). Instead of IP address you can also use a domain names here.
-Authentication based on tech prefix: this is mainly used in h323 network. Set the NeedAuth to 2 and enter a valid techprefix for the user (which is usually a traffic sender)
-IP and techprefix: NeedAuth must be set to 3. The “TechPrefix” and “AuthIp” fields must be set correctly
-Username/password authentication: usually for your sip endusers. NeedAuth must be set to 4. Username and password fields must be accordingly
-Authentication based on username: A number authentication. NeedAuth must be set to 5 and with a valid username
-IP and port based authentication: gives you better security than just IP authentication and also it is useful when you have more traffic sender from the same domain. NeedAuth must be set to 6. Port and IP have to be set accordingly. (port is stored in the callsigaddr field in tb_users. You need to edit it if needed)
-Username and IP: both username and authip must match
*SIP endusers are usually authenticated based on username and password.
*Traffic senders (carriers) are usually authenticated based on IP address.
Access numbers
Access numbers are special users. You will have to create them like usual users but their ivrid have to be set to a valid campaign id. (this is then linked with an IVR script)
For callback access you also need to set the “iscallback” user field properly. Read the “callback” services for more details.
A number authentication
For calls from traffic senders the server can try to authenticate the caller as an enduser if the “anumberhandling” option is 2,3 or 4 (by default it is set to 3). More details in the IVR authentication section below.
IVR authentication
For IVR calls the server will do a “callingcardauth” global config option based authentication.
Please note that in this case the caller device is already authenticated based on basic authorization settings. The IVR needs to find an enduser to allow further operation, like call forward.
The server can authenticate the user based on the following methods:
Ø ANI/CLI authentication: if the CLI is known and this method is allowed.
A number authentication can be used to try user authentication for a call coming from a traffic sender. If user is found with the actual A number then the caller will be authenticated as the enduser, otherwise will be authenticated as traffic sender. In this case you can require a PIN number from the user.
The A numbers are usually extracted from the “From” field of the incoming SIP INVITE.
Don’t enable A number authentication if you don’t trust the traffic sender or there is a possibility that the A numbers are not received correctly.
Configuration options:
anumberhandling global configuration
· 0=disabled
· 1=only add
· 2= only accept
· 3=add and accept (default)
· 4=only a number access (no pincode request)
anumberhandlingforrouting global configuration
· 0=disabled
· 1=disabled
· 2=yes, but autoturnoff if not used for a while
· 3=always yes
enableanumberlookup per user configuration. You need to set it to 1 for traffic senders to enable or 0 to disable.
A numbers can be also registered by the users on a web interface or by sending an SMS in the proper predefined format.
Ø PIN (calling-card) based authentification:
When the A number is not known or the A number based authentication is disabled, the IVR have to ask the user for a valid PIN code.
This can be done by the CallingCardAuthentication IVR action.
After the server collects the DTMF digits it will lookup the database for a valid user entry. The authentication can be based on username, password or username+password or depending on the “callingcardauth” global config option which can have the following values:
· 0=all combinations with minlength check (default)
· 1=callingcard username
· 2= callingcard password
· 3= callingcard username+password
· 4=any username
· 5=any password
· 6=any username+password
· 7=any username+password or username+pin
· 8=username for callingcard and username+password or username+pin for other users (default)
· 9=pin
· 10=password or pin
· 11=all combinations
· 12= all combinations with minlength check (default)
When using the pin field based authentication, make sure that user has valid pin codes set in this field (when the users are automatically generated, the pin is set to be username+password).
User rights
User rights can be further restricted by several configuration option.
The most useful tool for this is the routing table. You can define were a certain user or a user group can initiate calls.
The following restrictions can be applied per user:
Allowedusers: list of the users or groups (prefixed with 'g') that is allowed to call the user. This can be used to restrict the access to an access number for example.
AllowedPartners: comma separated list of allowed partners and traffic senders. ‘*’ will allow all. You may restrict the access on gateway or simpacket level instead of setting it for all simcards separately. Try to use the packet “allowedpartners” setting and leave it as ‘*’ for the simcards!
Enabledprefixes: can be one prefix (with any length) or a list of prefixes with 3,4 or 5 digit separated by comma.
Can be used for traffic senders and gateways too. No need to setup a separate routing pattern if you use this restriction.
EnabledTechPrefixes: enabled techprefixes for the specified gateway (3 digit length numbers separated by comma)
BlockPrefixes: list of called prefixes that will be blocked for the user (techprefix will not be considered here). Numbers listed here must have 7 digit length and separated with comma.
MaxLines: max concurrent calls allowed (separate value for peak or offpeak)
Maxmonthlycredit: max allowed credit/month even if the user is postpaid
Maxmonthlycreditend: max Maxmonthlycredit (because we increase Maxmonthlycredit by maxmonthlycreditinc every month if the user was active)
Onlylocalaccess: traffic sender traffic will not be forwarded (can call only local users from tb_users and tb_numbers)
Maxmonthlycreditinc: determines how much money we add to Maxmonthlycredit every month
Access Rights: specify wich fields are allowed for the user in the VPC application
0: simcard and traffic sender fields are not shown
1: simcard related fields are not shown (simid, packetname)
2: traffic sender related fields are not shown (name, username)
3: all fields are shown
Global configuration options:
MAXSPEACHLEN: max allowed call duration in sec
allowedusers: max ring time in sec
callmaxwait: max waittime allowed for operators between calls (for administrative purposes)
enforcestrongauth: enforce authorization and strong passwords
More rate limit settings can be found in the “security” and “billing” related sections.
Try to avoid prioritizations by users, gateways, simpackets or channels (absolutepriority, priority, allowedpartners, prioritypartners, etc)
Almost all kind of configuration can be set up by using only the “routing” form.
LDAP, Radius or authentication via external database or API can be also added.
DID (Direct inward dialing) is a feature for routable static/dynamic numbers. Endusers can be reached directly by calling DID numbers from outside networks and DID numbers can be also used as a CLI (display number/A number) for outgoing calls. It might be used to share a SIP trunk among one or multiple users.
DID numbers can be acquired from carriers (for example the carrier where you are otherwise send the VoIP traffic), specialized DID providers such as didx: https://www.didx.net/ or other sources. These numbers can be assigned manually or via API. (integration needed with your did provider for this functionality). The numbers then can be stored in the tb_telnumbers table (Phone numbers form in MManage) and then manually or automatically assigned to users. (If enabled, on new user signup the user can select a DID number if any).
In the mizu servers you can manage DID on multiple levels.
Ø Assign one DID per user
This is the simplest and more robust usage, recommended if you have enough DID’s to assign to all your (business) users.
Just set the DID as user Username.
If for some reason you don’t wish to use DID as username (for example if DID is assigned later) then you can use the OtherNumber field to assign it to the user. The server will automatically accept calls either to username/othernumber/telnumber/shortnumber. For outgoing call it will also guess the best one to use from these fields (or it can be set explicitely by the replacecalleroncalls global config option)
Ø User sign-up from the web portal
You can configure the enduser web control panel so the users can get a DID number during sign-up.
Use the following configuration options:
o autogeneratenewuseraccounts: 0=no,1=auto generate random,3=auto select from tb_telnumbers,6=user select from tb_phonenumber
o autogeneratedid: 0=no,1=auto generate random,3=auto select from tb_telnumbers,6=user select from tb_phonenumberx
o allowenduserdidedit: allow enduser to edit its own telnumber field 0=no,1=yes for resellers,2=yes for endusers
Ø Assign multiple DID per user
You can use the othernumber list for this (tb_users_othernumbers). The same DID can be even assigned for multiple users. In this case the incoming call is routed to the “best” user (Best effort: user online, not in call, etc).
Ø Contact list
DID numbers can be also used to be assigned to users contact lists if they are listed as Shared DID’s in the users table. In this case the DID numbers can be shared and will serve multiple purposes:
o Incoming call from user to a DID in its own contactlist: call will be routed to the contact (username or phone number, which is “best
o Incoming call from contact (username/phone number) to assigned DID: call will be routed to user (to which user the contact belongs)
o For outgoing calls the A number will be also set accordingly or after the rules discussed above
Ø Shared DID
For shared DID you will have to create users with the DID numbers (username set to DID number, shared did option checked) and then these DID numbers can be used by multiple users in the same time. These will ease the access to users favorites from other networks (calling via third-party servers or via the IVR).
Endusers can assign their contacts (internal user or external phone number) to these DID numbers from webportal phonebook page.
To enable/disable this feature, you might explicitely set the feature_shareddidnumbers option to 1 (or set to 0 to disable). The default value is -1 which means that will auto turn to 1 of there are shared did numbers in the system (detected at startup, reload and nigtly)
If the softswitch is used by multiple companies then you can set the BelongsToCompany field to separate the DID numbers by companies.
For incoming call to a shared DID the call will be routed to the “best” user or outbound number (Best effort. The user who have called last time the current caller). You can also use share DID’s to assign a local number to called users or outbound numbers (“Quick Call” feature).
For outgoing calls a DID number will be also assigned as the A number.
Data:
Users contactlist are stored in tb_speedial:
o userid: link to “main user”
o num (any number assigned to this contact -Phone1)
o uphone2 (any number assigned to this contact -Phone2)
o uname (any user name assigned to this contact -Username)
o udid (the shared DID)
Usage:
o Add a few DID number from the “Users and devices” form. These are like normal endusers but their username is a DID number and the “Shared DID” option is checked on the “Functions” tab (this way the “ispublic” field will be set to 4 for these numbers/users)
o Set the “feature_shareddidnumbers” configuration option to 1 (the default is -1 which means that will be automatically enabled once you have added a few DID numbers, otherwise automatically disabled). You can toggle this from the ”users and devices” form “functions” tab “Shared DID” option.
o Once this is done, users can assign DID numbers for their Phonebook entries from the web enduser interface. (stored in the “udid” field in the “tb_speeddial” table). This is optional since the numbers can be found also based on the CDR records (last called numbers)
o Once a DID number is dialed, the following lookup procedure takes place:
Shared DID lookup procedure:
o The calls can come from the internal netword (a SIP endpoint) or from external (from PSTN via a traffic sender). The server will identify the caller via SIP authentication, A number authentication or PIN authentication via IVR. If the feature_shareddidnumbers is set then the server will do the following lookups (in this order):
o incoming call from any enduser to a shared DID in its own contactlist -> call will be routed to the contact phone or name (main user -> contact)
o incoming call from any contact (did, phone or name) to the assigned DID -> call will be routed to the main user (contact-> main user)
o incoming call from any to a shared DID which is found in last 2 hours cdr’s -> route to user who was called this did last time if any (any -> main user). So if a shared number is used for a call, the called person can call back to CallerId and will reach the best suitable contact.
o incoming call from any contact (did, phone or name) -> call will be routed to the main user (contact-> main user)
o incoming call from any to a shared DID which is found in last day cdr’s -> route to user who was called this did last time if any (any -> main user)
These lookups are flexible, so the caller/called/did might be found both with and without IEC or country prefix (+/00/country prefix).
Ø Lookup called user on fix DID
In some circumstances you will receive all calls from devices with the same or invalid destination number. For example you might have a VoIP-GSM gateway forwarding all calls with the target set to its phone number assigned to the SIM card or configured by the administrator.
In these circumstances the target user might be determined by a best match using the A (caller) number as previously described Shared DID procedure (looking at users contact list or last called numbers).
You can enable this from the ”Users and devices” form “functions” tab “B number lookup” option (This will set the anumberlookup field to 10 or 11).
You might also set the replaceanumwithdid after your need: -1=auto (default),0=no,1=shareddid,2=companydid,3=cdr,4=all,5=4+extended cdr search
Ø tb_telnumbers
This table can be used to store the phone numbers but also for special DID number storage. Editable from “Phone numbers” form.
Fields:
· id: auto increment db id
· datum: record creation date (number added date)
· telnumber: the phone number
· ttype: 0=def,1=normal,2=did,3=smsdid,other=other type
· free: 0=allocated,1=free (not allocated),2=locked,3=temporary locked
· useddate: date when it was assigned to user
· comment: any notes
· location: not used
· lockeddt: number preallocated at sign-up with the getphonenumber API
· gatewayid: set to SIP server ID if number has to be used only with this SIP server
· userid: number was last used for this user (trying to use the same number with the same user)
Terms and Settings:
-DID: Direct inward dialing (DID) or called direct dial-in (DDI) is a telecom service to share a single SIP trunk among one or more users
-ANI/CLI authentication: Automatic Number Identification/Calling Line Identification
-Toll free: is a special telephone number, in that the called party is charged the cost of the calls by the telephone carrier, instead of the calling party. This can be configured as a normal access number (enduser) and eventually with higher billing (because we will be the billed party in this case)
-local DID number: normal access numbers. Usually you will have separate DID numbers for different regions to minimize enduser costs
-callback: DID or toll free number configured as enduser with iscallback set to the required IVR
-ANI callback: same as callback with User-ID based authorisation (A number)
-Virtual Numbers (DID): "real" phone numbers allocated for users. You have to buy DID numbers from CLEC or any other service provider like didx.net
TelNumber: sip telnumber.users can be contacted if we call there username or telnumber
Username: the most important field. Used for authentification and also as a DID number. This field is unique and cannot be empty.
ShortTelnumber: sip short telnumber (for example if several users has the same BelongsToCompany field)
DisplayName: how the user will be displayed. Can be null
More than one DID or ANI number can be assigned for one user. For this the tb_users_othernumbers table is used where the type field is 0 for DID numbers and 1 for ANI numbers.
autogeneratenewuseraccounts; //0=no,1=auto generate random,3=auto select from tb_telnumbers,6=select from tb_phonenumber
autogeneratedid; //(new) 0=no,1=auto generate random,3=auto select from tb_telnumbers,6=select from tb_phonenumberx
allowenduserdidedit; //allow enduser to edit its own telnumber field 0=no,1=yes for resellers,2=yes for endusers
feature_shareddidnumbers: -1=auto (def), 0=no,1=yes old,2=yes new,3=yes new and old, 4=also check last calls, 5=extended search, 6=extreme
shareddid_checkcontactlist: //-1=auto (def) ,0=no,1=yes old,2=yes new,3=yes new and old
shareddid_checkcdr: -1 (def) =auto,0=no,1=yes,2=yes extra
checklocaluserforshareddid = 1; //0=no,1=yes (def)
replacecalleroncalls: 0=no,1=default checks (best num; default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good num, 6=check minassertedidentitylen,7=with phonenumber,8=anonymous
replaceanumwithdid: -1=auto (def) ,0=no,1=shareddid,2=companydid,3=cdr,4=all,5=4+extended cdr search
forcedcallernidentity:-1 (auto, def) , user and global setting 0=no,1=default checks (best num; default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good num,6=check minassertedidentitylen,7=with phonenumber,8=anonymous
identityrewrite/identityforward: user setting to replace client->callernumber (controlled by config.identityrwmode)
identityrwmode: 0=no rewrite, 1=basic, 2=conform sip specification (identity; def)
sendidentity: 0=never,1=no (def),2=sometimes,3=always
configallowusernumbertopstn: -1=auto, 0=no,1=yes if phone number, 2=always (send call to outbound if user is offline)
cli:
user setting
0: forward always (forward asserted as normal number always!)
1: normal handling (forward asserted as normal number) -default
2: forward as asserted identity always (forward identityrewrite asserted)
3: forward as asserted identity only to trusted domains (forward identityrewrite asserted)
4: normal hide (no idenityrewrite forwarding)
5: force hide (no asserted identity too!)
minassertedidentitylen:,7=with phonenumber,8=anonymous affects only P-Asserted-Identity; will owerwrite any cli settings. default is -1
didhandleruser: a globally configured number where incoming calls to DID will be routed if no user match (can be a receptionist or an IVR)
globaldidout: a globally configured number to set the A number to this for all calls (should be used only by small business owners)
Incoming calls can be checked agains the tb_telnumbers table with the v_check_localnum to check if the target is a local number (even if it is not in the tb_users table).
You can preallocate a number to a user at sign-in with the getphonenumber API.
Example: http://11.22.33.44/mvapireq/?apientry=getphonenumber&authkey=8725436&count=5&now=555
You can assign a did to a user in the following ways:
-use it as the “username”
-set the “telnumber” field
-add it to tb_users_othernumbers table (if you wish to assign more than one did to a single user)
A quick tutorial can be found here.
The “dial patterns” terminology is not used with the mizu voip server. You can apply the number rewrite rules by the following ways (starting from simple to more complex rewrite rules)
1. Number normalization: Opent the “Configurations” form and search for the “normalize” string to list all related settings.
2. These settings can be used for basic number “normalization” to remove strange characters (like new line) and to remove IEC code. By default this is set to remove the common international escape codes (00,+). To turn this off, change the followings:
a) set cfg_normalizenumbers below 3 (2 should be good)
b) set normalize_localpx to 0
c) set “normalize_clean“ value below 4 (3 should be fine)
3. Tech prefix: tech prefix related operation should be done by using the “techprefix” box in the “Users and devices” form. Set this for the “SIP servers” where a specified tech prefix needs to be sent or set it for the “Traffic sender” when you receive the traffic with a techprefix from some routes.
4. Prefix rules: this is used for simple prefix add/remove operations. (discussed below)
5. Dial plans: you should use this option if you need full control
The firewall rules are checked also at transport level so this is the most effective way to block some unwanted traffic sender.
With the firewall you can block source IP addresses and caller user names (or CLI’s).
For IP address rules, just enter the source IP address as the source.
For caller user rules, prefix the name/number with U:. For example to block user ‘hacker’, enter ‘U:hacker’ as source.
All source are allowed except those are listed if the ip with ‘*’ is 1.
Otherwise (if the source ‘*’ is set to 0) all address are blocked except those that are listed here.
Note:
Make sure to do not delete the * - 1 rule.
If the * -1 rule exists, then it acts as an usual firwall, blocking the sources with addrenabled set to 0.
If the * -1 rule doesn’t exists, then it will allow only sources with addrenabled set to 1 and all others will be blocked!
Be avare of IP address spoofing. Some attackers are capable to falsify the source IP, thus your security should not depend only on source IP filtering (additionally you should also use SIP digest authentication or at least a tech prefix even for trused traffic senders)
By default the server will "normalize" all numbers. This means that it will clean the numbers from garbage characters, sql injection attacks and might remove/add IEC/CC/NEC prefix based on the circumstances and global configuration (international escape code, country code).
If left with these default settings, you will have to deal with this normalized number format for all the call processing including routing and billing.
This behavior can be quickly changed by the normalizedef setting for which you can assign the following values:
-1: default, recommended (mostly like 2) [validateinput=3; normalizenumbers=2; normalizecallednumbersnec=-1;]
0: don't touch (dangerous) [validateinput=0; normalizenumbers=0; normalizecallednumbersnec=0;]
1: minimal (clean the numbers) [validateinput=1; normalizenumbers=1; normalizecallednumbersnec=1;]
2: basic (clean the numbers) [validateinput=2; normalizenumbers=1; normalizecallednumbersnec=1;]
3: normal (remove IEC like + and 00) [validateinput=3; normalizenumbers=2; normalizecallednumbersnec=1;]
4: strict (might add CC and rewrite NEC) [validateinput=4; normalizenumbers=3; normalizecallednumbersnec=2;]
5: extra (full input checking and number rewrite) [validateinput=5; normalizenumbers=4; normalizecallednumbersnec=3;]
It is recommended to leave this setting with its default -1 value and you should change it only to have full control on number rewrite rules (set to 1) or if you wish to set a strict checking (set to 3)
Usually you should leave this (and the other related global config options below) with the default values and you might add your own special number rewrite rules by the "Rewrite" module if you need so.
If you want more control for the rules, then you should leave it with the default setting of -1 and change the global config options below.
If you want full control for the rules, then you should set it to 2 (or 1) and use the "Rewrite" module to add your rules.
Other global configuration options related to number "normalization" and rewrite are the followings:
outgoingprefixremove:
List of prefixes to be removed from the called number for outgoing calls separated by comma
For example +,00
outgoingprefixremove_maxlength:
Will apply the “outgoingprefixremove” rule only if the number length is at least this number inclusive
outgoingprefixremove_minlength:
Will apply the “outgoingprefixremove” rule only if the number length is less than this number exclusive
outgoingprefixremove2:
Single prefix to remove but within the below rules.
outgoingprefixadd:
Set any string prefix which will be applied for called numbers for all outgoing calls.
For example +.
If you need to change the prefix only to one direction, then use the "Rules".
outgoingprefixadd_minlength:
Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number length is at least this number inclusive
outgoingprefixadd_maxlength:
Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number length is less than this number exclusive
outgoingprefixadd_ifbegin:
Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number begins with this
outgoingprefixadd_ifnotbegin:
Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number NOT begins with this
All the above can be applied also when call arrives by setting the incomingprefix settings.
normalizenumbers: how to normalize
0=no,1=basic,2=normal,3=more (hu/ro),4=extra
default is 2
normalizecallednumbersnec: NEC normalization (National Destination Code)
-1=depends on normalizenumbers and normalize_localpx, 0=no,1=yes,2=extra
default is -1
loadcallednumberfromto: 0=autoguess,1=no (from first line),2=yes (from to)
rewriteinternalcalled: rewrite the called numbers for calls to endusers
0=don't set,1=don't rewrite,2=client to as received,3=client to username,4=client to telnumber,5=client to best if match,6=all to as received,7=all to username,8=all to telnumber,9=all to best if match
default is: 7 for servers and 6 for gateways
forwardcalled: what to use for request URI and To fields: 0: no (old server behaviour; callednumber decided at routing), 1: forward as received, 2: forward callednumber, 3: forward callednumber_header, 4: forward callednumber_to
default is: 0 for servers and 1 for gateways
forwardcalledtofs: same as the above forwardcalled but used only if the called party is on WebRTC
validateinput: how to clean the numbers
0=no,1=basic without sql check,2=basic with sql, 3=normal,4=more,5=extreme
default is 3
cfg_minnormalizelength: minimum length of the number to consider for extra normalization.
default is -1 which means that it depends on normalizenumbers (if normal then set to 5)
checknumnumbers: reject call if called is not a phone valid number
0=allow any calls; 1=allow only phonenumbers from H323; 2=allow only phone numbers for all
default is -1 which means that it depends on normalizenumbers (set to 1 if normalizenumbers is normal)
checknumport: check number portability rules
-1=autoguess,0=not check,1=check for changed prefix,2=check for changed number,3=check for changed domain,4=check for changed server id,9=check all
default is -1
The CC/NEC rewrite depends on the followings:
caller CC/NEC
country: country (2 chars)
iec1,iec2,iec3: international escape codes
countryprefix: default country prefix (country code)
prefix1,prefix2,prefix3: national destination codes
cfg_mobileprefixes: list of common mobile prefixes (useful for callenters to differentiate landline and mobile calls)
Deprecated settings (don't use these anymore):
normalize_localpx: replaced by normalizecallednumbersnec
setcalledtosipusername: replaced by rewriteinternalcalled
normalize_clean: replaced by validateinput
normalize_checksp: replaced by normalizecallednumbersnec
Example:
The following settings will normalize incoming numbers (from both national and international format) to international number format then will add 00 when forwarding to an outbound route (to a VoIP carrier):
Settings:
normalizedef: 3
normalizenumbers: 3
incomingprefixremove: 00,+
incomingprefixadd: 4
incomingprefixadd_ifbegin: 07
outgoingprefixadd: 00
outgoingprefixadd_ifnotbegin: 00
Example input dialed number:
+40721234567 OR 0040721234567 OR 40721234567 OR 0721234567 OR 0721234567
IEC: 00 or +
Country code: 40 (Romania)
NEC: 72 (Vodafone)
Normalized number:
40721234567
Outgoing number:
0040721234567
On Caller ID we mean the number or name displayed for the called party which is sent by one of the followings sip headers:
-From header (URI and displayname)
-Contact header (URI and displayname)
-Authentication username
-Identity headers: p-asserted-identity, p-preferred-identity, remote-party-id
-Privacy settings: "privacy" header, "anonymous"
The caller-ID display is specified in the SIP and other RFC's but at the end it is up to the called party device to what caller-id to display (it can be loaded even from a local store instead of from the SIP messages sent by the caller party)
The Caller ID can be influenced by the following factors:
-the SIP message received by the client as described above
-global number normalization settings (see the "number normalization" section)
-global caller id related settings (discussed below)
-caller and especially the called user settings such as the techprefix
-Prefix Rules settings (this is already deprecated. Use "Rules" whenever possible)
-Dial plan SQL (this is already deprecated. Use "Rules" whenever possible)
-Rules (see the "Rules" section)
Settings:
The easiest way to influence the caller-id is the replacecalleroncalls setting (global setting and/or per user setting):
replacecalleroncalls:
(user and global setting)
//0=no,1=default checks (best num; default),2=dbusername,3=telnumber,4=bestnumber,5=first good num,6=check minassertedidentitylen,7=with phonenumber,8=anonymous, 9=from header,10=contact header,11=Remote-Party-ID header, 12=best from client, 13=best from all, 14=called user username, 15=called user telnumber
Default is 13.
forcedcallernidentity:
user and global setting
//0=no,1=default checks (best num; default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good num,6=check minassertedidentitylen,7=with phonenumber,8=anonymous
affects only P-Asserted-Identity
will owerwrite any cli settings
default is -1
realcallernumber
just a routing variable
client->callernumber = realcallernumber;
client->origcallernumber = realcallernumber;
forcedcallernumber:
just a routing variable set by replacecalleroncalls and used by the client ep later
overwrite the client from number
forcedcallernidentityumber:
just a routing variable set by forcedcallernidentity and used by the client ep later
overwrite the client identity
identityrewrite/identityforward
user setting
replace client->callernumber (controlled by config.identityrwmode)
//config.identityrwmode = 2; //0=no rewrite, 1=basic, 2=conform sip specification (identity)
//config.sendidentity = 1; //0=never,1=no,2=sometimes,3=always
cli:
user setting
0: forward always (forward asserted as normal number always!)
1: normal handling (forward asserted as normal number) -default
2: forward as asserted identity always (forward identityrewrite asserted)
3: forward as asserted identity only to trusted domains (forward identityrewrite asserted)
4: normal hide (no idenityrewrite forwarding)
5: force hide (no asserted identity too!)
forwardauth:
user and global setting
confing.cfg_forwardauthentifications = 0; //0=no (default),1=yes,2=yes with username as callername, 3=yes with phonenumber as callername, 4=yes with username as authname too, 5=yes with phonenumber as authname too, 6=replace authorization with username but leave the A number intact, 7=replace authorization with sipphonenumber
can rewrite client auth_username, auth_password, callernumber
rewriteanumber:
user setting
simply replace client->callernumber
set to anonymous to disable the caller-id
cutanumber:
user setting
simply replace client->callernumber prefix
replacecalleronforward
global config option
used only for callforward
//config.replacecalleronforward = 9; //0=no (default),1=yes,2=yes with username as callername, 3=yes with phonenumber as callername, 4=yes with username as authname too, 5=yes with phonenumber as authname too 9=auto
parseidentity
global config option
0=no at all, 1=normal,2=rewrite caller number,3=rewrite callername also
default is 1
parsesipdisplayname
global config option
0=no,1=callername,2=displayname,3=can be used for auth
default is 1
userealphonenumbercallerid: 0=no (default), 1=yes: will overwrite cfg_replacecalleroncalls! (will try to find a phone number to use)
useorigcallerforeu: 0=no (default), 1=yes: will overwrite cfg_replacecalleroncalls! (if call is routed to enduser, then will use normal caller)
replacecalleroncallsusercheck: default is 1
replaceanumwithdid: -1=auto (default) ,0=no,1=shareddid,2=companydid,3=cdr,4=all,5=4+extended cdr search
Also see the DID numbers section for other possibilities.
See the How to set the Identity header for more details about the Identity SIP headers.
Using the “Rules” for you can handle and rewrite almost all SIP fields based on any condition, esepecially the caller and the called number.
This form can be used to create both simple and very complex rules. Hold the mouse over the controls to get a context sensitive help.
Usage:
1. Click on the “Add” button to add a new rule
2. Name the new rule as you wish
3. Run as: it is usualy fine if you leave the “Auto guess”, however you can specify it more exactly in certain conditions
4. Specify the conditions when this rule is executed (for example you might have to reformat the called number if the call is sent via a specific carrier; in this case use the CalledID to select the carrier)
5. Data: specify which data do you wish to load and work with it (for example the callednumber)
6. Check: specify additional conditions when this rule is executed (now you can examine the “data” loaded in the previous step)
7. Action: specify what you wish to do with the data
8. Set: specify how to wish to save back the result (usually “same as loaded data” since most of the case you will just wish to modify a field such as the called number)
Additionally you can modify some global configuration options to modify the caller/called number. These are described below:
You should instead use the “Rules” form mentioned above.
You can rewrite prefixes before they arrive to the routing by entering your preferences here.
The Mizu routing engine will accept only 3 digit length techprefixes or no thechprefix, so you must convert them here if your traffic sender will send the traffic with techprefix that are not three digit length.
Example 1:
To set up a rule which defines that every incoming number from ip 111.111.111.111 on H323 if begins with 1234 must be rewritten to begin with 56. Number 123499999 will be rewritten to 5699999.
If the “RewriteFrom” is emtly, then the “RewriteTo” fill be inserted before the number
Example 2: To remove 011 before all dialed numbers:
Protocol: 0
Type: 1
Value: empty
Rewrite from: 011
Rewrite to: empty
Number to rewrite: Incoming Called (0)
Example 3: To replace 06 with 446 for all SIP calls coming from 192.168.1.8:
Protocol: 1
Type: 2
Value: 192.168.1.8
Rewrite from: 06
Rewrite to: 446
Number to rewrite: Incoming Called (0)
Example 4: to handle the hungarian roaming prefix: 08 + SK + BK + NSN +SN you have to set the following values:
prefixrewritestr: 08X…
prefixrewritefrom: 9
prefixrewriteto: 36
You should instead use the “Rules” form mentioned above.
During the routing process you can modify the caller and called number with the dialplan stored procedure (v_dialplan)
v_dialplan can be called several times during the routing depending on the checkdialplan1-4 global config option.
For CLI and A number rewrite it is enough to set checkdialplan4 to true (after routing) and check/rewrite the numbers using the LIKE operator (wildcards are enabled).
Input parameters:
@calledat TINYINT, /*1=first check, 2=after authentication, 3=before routing out, 4=after routing out*/
@protocoll TINYINT, /*0=SIP, 1=H323, 2=GSM, 3=Other*/
@fromip varchar(22), /*caller ip address*/
@fromport SMALLINT, /*caller port*/
@callerid int, /*caller device database id from tb_users*/
@callernumber varchar(35), /*caller number or sip username*/
@callername varchar(35), /*caller name or displayname*/
@calledid INT, /*called device database id from tb_users*/
@origcallednumber varchar(35), /*called number as received*/
@techprefix VARCHAR(10), /*called number tech prefix*/
@normcallednumber varchar(35) /*normalized (changed) called number*/
The stored procedure can be called at different routing stage:
1: before authentication
2: after auth
3: before routing
4: after routing
This means that if a number has efect on authentication then you can rewrite it on stage 1, but if you need to modify the called number only for the b-leg call then it is better to call this function only at stage 4
Some of the input values are not set at earlier stage. For example when calledat is 1 then the callerid will be 0 because the caller is still not known at this stage.
Usually only the called number have to be rewritten, but you can also change the other values.
Accepted output values:
-emty string: no effect
-_REJECT: will disconnect the call
-_REJECTPLAY,filename: play a file and disconnect the call
-callednumber: will change the called number
-callednumber,calleddialed,origcallednumber,techprefix,callernumber,callerid,calledid
Field details:
-Callednumber: will be used for further routing decisions, for billing purposes and it is stored in CDR record
-Calleddialed: will be used only for b-leg
-Origcallednumber: can be used for further routing decision (mostly not used)
-Techprefix: can be used for further routing decision. Deprecated after version 3.5
-Callernumber: can be used for further routing decision and stored in CDR record
-Callerid: you can modify the caller user if you change this parameter
-Calledid: you can modify the called user if you change this parameter
sql help:
sql tutorial: http://www.w3schools.com/SQL/sql_intro.asp
stored procedures: http://msdn.microsoft.com/en-us/library/aa174792(SQL.80).aspx
string functions: http://msdn.microsoft.com/en-us/library/aa258891(SQL.80).aspx
like operator: http://msdn.microsoft.com/en-us/library/aa933232(SQL.80).aspx
example:
DECLARE @ret_callernumber varchar(35)
DECLARE @ret_callednumber varchar(35)
SET @ret_callernumber = @callernumber
SET @ret_callednumber = @normcallednumber
IF (@calledid = 456 and @ret_callednumber LIKE '1_23%')
BEGIN
SELECT '_REJECT'
RETURN 1
END
IF (@calledid = 457 AND (LEN(@ret_callednumber) < 5 OR ISNUMERIC(@ret_callednumber) = 0))
BEGIN
SET @ret_callednumber = '1234567'
END
IF (LEN(@ret_callednumber) > 6 AND LEFT(@ret_callednumber,3) = '061')
BEGIN
SET @ret_callednumber = '36'+SUBSTRING(@ret_callednumber,3,35)
END
IF (@ret_callednumber LIKE '5222%')
BEGIN
SET @ret_callednumber = SUBSTRING(@ret_callednumber,5,35)
END
SELECT @ret_callednumber+’,’+@ret_callednumber+','+@ret_callednumber+',,'+@ret_callernumber
RETURN 1
If the stored procedure doesn’t run successfully, then it will have no effect.
List the blacklisted target numbers on the selected time interval and direction.
This query will generate high server load. Use it only in off-peak time if possible
You can define the “Blacklist” and the “Whitelist” here for the called numbers. The listing will be used in the routing depending of the actual packet “filtering” setting. Check section 4.5.1 for details regarding filtering.
Note: these filtering applies to targets and not for the source. If you wish to filter the call source, then use the caller banning module as described here.
Global setting to enable/disable black list: numfiltering:
-1=autoguess (default. Will be auto set to 0 if there are no blacklist entries or to 3 if there are)
0=nothing (disable)
1 =only from h323
2=only from sip
3=all (enable)
Blacklist method: blacklisttype:
-1=autoguess (default. Will be auto set to 0 if there are no blacklist entries)
0=nothing (disable)
1=phone number as string or prefix using tb_blacklist (slower)
2=phone number as number using tb_blacklist_int (very fast even for millions of records)
3=both
Global setting to enable/disable white list: checkknownnumbers:
0=no (disable)
1 = autoguess (default. Will be auto set to 0 if there are no blacklist entries or to 3 if there are)
2=yes (enable)
Database tables:
White list: tb_knowngoodnumbers
Black list: tb_blacklist
Blacklist fields:
-telnumber: country code + operator + telnum
-sure: levels
tb_blacklist.sure:
0 –probably good numbers (reput)
1 - not sure (holes)
2 - probably wrong number (monthly autodisabled)
3 - very sure (roaming numbers)
6 – always block (not only to gsm)
tb_packets.filtering: determines how we check the blacklist and the known numbers
0 -no filtering
1 - filter if very sure blacklisted (tb_blacklist.sure >=3)
2 - filter if probably blacklisted (tb_blacklist.sure > =2)
3 –filter if suspicious (tb_blacklist.sure > =1)
4 - filter if present in blacklist (any tb_blacklist.sure)
5 - filter if not a known number
6 - filter out if no sure known number
Blacklist can be also built automatically as defined by the builddynamicblacklist global config option:
-1: auto (will auto turn to 40 if numfiltering is enabled)
0: disable
Other: minimum failed calls per day
Failed calls are checked periodically with the following minimum count to block:
-hourly: builddynamicblacklist/2
-daily: builddynamicblacklist
-weekly: builddynamicblacklist*2
-monthly: builddynamicblacklist*5
Other global config options:
blacklist_maxbcount: max count of numbers to block one time (default is dynamic based on average number of calls per day)
blacklist_minasr: minimum asr per number to block (default is 5)
blacklist_minacd: minimum acd per number to block (default is 10)
You can add a number to the black list form the “Access Lists” form “Add number to blacklist” button or by executing the following SQL from the “Direct Query” form:
insert into tb_blacklist (telnumber,reason,sure,maxtryagaincount,cantryagain,blockdays,lastblocked)
values ('TELNUMBER','COMMENT',6,0,0,99999995,getdate())
(replace TELNUMBER and COMMENT after your needs)
Block scanning
Some spammers might try to scan a number range by making calls to similar numbers (such as trying numbers from A to Z).
Blocking these attempts can be configured by the blockscanning global settings:
· blockscanning_treshold: -1: auto, 0: no, 1+: yes, max count of subsequent similar numbers. Default is 45, or 15 if option checked in the config wizard or 0 if not checked.
· blockscanning_mode: strict (permissive; will count only subsequent numbers or diff is less then 10), 2: general (will check if diff is less then 30 or if there is only single digit change. threshold calculation will be incremented by 3 for subsequent numbers). Default is 2 (general).
Smart blacklist
Will block a number after X failed attempts in Y time interval for Z amount of time.
The “number” here means the target/called numbers, not the source/caller number.
Settings:
· smartblacklist_enable: enable/disable smart blacklist. 0=no,1=on normal load only (will not run on high server load), 2=force always. Default is 0. Set to 1 to enable.
· smartblacklist_peruser: smartblacklist is per user or for all calls. 0=no (so it will check globally), 1=yes for endusers, 2=yes for all callers, 3=yes for all users with “smartbl” field set to 1 (otherwise not checked at all). Default is 1
· smartblacklist_callduration: call duration in seconds to be considered by smartblacklist //0= all calls, negative: count only connected calls, other: count only calls below this duration including not connected calls. Default is 5
· smartblacklist_callduration_min: specify only if you wish to check calls above a specific duration. For example if you wish to block users with calls between 1-3 seconds then set smartblacklist_callduration_min to 1 and smartblacklist_callduration to 4.
· smartblacklist_blockafter: number of attempts after to block the number. Default is 20
· smartblacklist_checkperiod: check calls in this period. 1 means one day, 2=two days, 0.5 means 12 hours. Default is 1 (one day). Increasing this might increase CPU usage.
· smartblacklist_blockperiod: block the number for this duration where 1 means one day. 0=not used (will block until goes out of the checlperiod range), other: will add to blacklist for the specified time. Default is 0.
· smartblacklist_voice: voice playback on call reject (name of the file)
Update old database:
ALTER TABLE tb_blacklist ADD [calleruser] [int] NULL DEFAULT (NULL)
ALTER TABLE tb_blacklist ADD [expireat] [datetime] NULL DEFAULT (NULL)
ALTER TABLE tb_users ADD [smartbl] [tinyint] NULL DEFAULT (0)
SP v_check_blakclist:
select TOP 1 telnumber,sure from tb_blacklist WITH(NOLOCK) where
@called_norm LIKE telnumber+'%' AND blocked = 1 AND telnumber is not null AND LEN(telnumber) > 0 and (expireat is null or expireat > getdate()) and (@callerid = calleruser or @callerid = 0 or calleruser = 0 or calleruser is null)
ORDER BY sure desc
For every time period and direction a “Routing Pattern” needs to be defined. Every Routing pattern has a list of routing directories which may be Mizu GSM Gateteways, other H323 gateways or gatekeepers, ISDN gateways or SIP proxies in priority order. Set up as much directories with the same priority order as possible so the routing engine can prioritize itself after other settings (device priority, LCR, quality,BRS)
Generic rules can be defined by setting the pattern priority lower. For example for every call that doesn’t have a specific route can be routed to a specific direction (otherwise is dropped)
There is a list of typical time definition. If none of them match your needs, the “Start-End Time” entry can be selected to specify proprietary intervals.
In Caller Prefix, you can place only one prefix.
Tech prefix can be empty string, asterisk (*) or 3 digit length number.
Called prefix can be one prefix (with any length) or a list of prefixes with 3 or 4 digit separated by comma.
*Tip: you don’t need to enforce traffic sender rights by routing. The routing can be done as generic as possible for example by specifying only Called Prefixes (Leave the other direction option blank or ‘*’). Rights can be enforced by setting “Enabled Prefixes” for all Traffic Senders
Routing Configurations
Try to set up all routing rules and prioritizations using this form.
Try to avoid prioritizations by gateways, simpackets or channels (absolutepriority, priority, allowedpartners, prioritypartners, etc)
Almost all kind of configuration can be set up by using only the “routing” form
The actual priority order of your route list (right side list) will be affected by numerous factor:
-Failowering: when a device or a device/direction is in failowered state, then its priority is lowered
-Load balancing: will prioritize the direction where the last routed date time is oldest (only if the routing entries are entered with the same priority)
-LCR: the route with the lowest price will be prioritized
-BRS: the best quality/lower price route will be prioritized
These settings can be controlled by the “brs_lcr” global config option:
0=not used
1=only lcr for not gsm
2=lcr
3=brs for not gsm
4=BRS (default)
5=BRS+LCR
Introduction
The routing in the Mizu softswitch means deciding on which active gateway, user or gsm channel should we route the incoming call from traffic senders and endusers.
The routing is influenced mainly by the following:
-device ownership and access rights (allowedpartner settings)
-routing time, direction and the selected pattern (device/packet priority list)
-various priority settings
The routing is blocked if the following conditions are met:
General conditions
syntax error in incoming number (or not known)
max call/day, max speachlength reached (licensing option)
Caller user check
the traffic sender reached their maximum channels
caller gateway, simcard or simpacket is not enabled or temporarily disabled
failed authorization (wrong originating ip, bad username or password or wrong techprefix)
Caller “CanDial” setting is set to false
Caller tb_users.enabledprefixes not match (‘*’ allow all numbers)
Check if other traffic sender has the same ip/techprefix (caller mismatch)
Routing
direction and time don’t match a routing pattern
no active device or simpacket from the selected pattern priority list
Called device/gateway checks
Called gateway(s) is not enabled, not active, temporaydisabled, allowedpartners don’t match or any other problem
Called gateway onlytestcalls not match
Called gateway enabledprefixes not match (‘*’ allow all numbers)
Called gateway blockprefixes match
Called device filtering option doesn’t allow blacklisted number level (if the incoming number is blacklisted)
gateway has testprefix but does not match
Called simpacket check (only for gsm directions)
Packet is not enabled
Caller is not listed in allowedpartners
packets.waitaftercall second not elapsed since last call
packets.filtering. blacklist/whitelist restriction (filtering option doesn’t allow blacklisted number level (if the incoming number is blacklisted))
Simcard check (only for gsm directions)
Called simcard(s) is not enabled, temporaydisabled, not ready, allowedpartners don’t match or any other problem
partner is not allowed on the simcard (allowedpartners)
the simcard is prepaid, but it doesn’t have enough credit
two subsequent calls cannot be routed to the same simcards (configurable)
there was a credit request or recharge in the simcard in the last minute
cannot request credit from prepaid card more than 5 times
maxmonthlyminutes,maxdailyminutes,maxallminutes, maxmonthlyminutespeak are reached
no report from the channel for more than 5 minutes (the gateway may have lost its network connection or power)
Routing priority order
If emergency number, than the defined emergency route has the biggest priority
Routing pattern priority (if two or more pattern overlap)
Routing pattern direction/time best match (if two or more pattern overlap)
Called gateway Globalabsolutepriority
Called gateway and simcard absolutepriority
Positive routing priority (deprioritze simpackets with negative routing priority -these are “emergency packets”)
SimPacket absolute priority partner (absprioritypartner -if set and if match the caller)
Simcard caller priority (absprioritypartner -if set and if match the caller)
Gateway absolute priority
Gateway called priority (if set and if match the caller)
Simcard absolute priority
Routing list priority/100 (differences more than 100 in priority list)
Called gateway is not failowered -value lower or higher than the current date-time (for automatic failovering)
Called gateway is not failowered for the currenct called prefix (direction)
Simcard is not failowered - value lower or higher than the current date-time (for automatic failovering)
SimPacket is not failowered
Tpercek priority (hungarian tmobile specific)
Routing list priority
Elapsed time from last call disconnect is more than 10 sec
Gateway callerpriority match the caller number
Gateway prioritypartner match
Simcard priority partner match
SimPacket nopriority partner not match
SimPacket priority partner match
Gateway priority (simple)
Simcard priority (simple)
Simcard minimum monthly speechlength not reached
Simcard minimum daily speechlength not reached
Simcard desired monthly speechlength not reached
Simcard desired daily speechlength not reached
Simcard todayspeachlength desc order (simcards with more callduration has lower priority)
Simcard thismonthcallcount desc order (simcards with more callcount has lower priority)
Simcard thismonthspeachlength desc order (simcards with more callduration has lower priority)
Simcard a.creditrequestfails desc order (simcards with more failed credit requests with lower priority)
Gateway ready channels (balance calls across gateways)
Last call begin on the simcard (balance calls across simcards -simcards with the most recent calls has lower priority)
Simcard currspeachlen desc
Simcard GSM Fieldstrength
Simcard lastrectime (for randomizations)
Technical description:
Call arrive
from traffic sender or enduser via SIP or H323
Check if MAXCCALS restriction reached (licensing option). Drop if yes.
Check if maxslperdayreached reached. Drop if yes.
Check if maxroutereqpermin reached. Drop if yes.
Check if the current call is a routing retry (forked calls). Drop if too much retry
Normalize caller ip addres
Check if the call was from the local SIP2H323 module. Return with the already prepared target if yes
Chech if the call was arrived from GSM gateway. (callin option). Replace caller and called after the config.
Correct the called number string if it is corrupt.
Check min/max length of the called number
Check if the incoming call is a testcall. Set the testcall flag is yes
Check and apply prefix roules (tb_pxrules – rewriting the called number)
Authenticate the caller (after username/password, ip pr techprefix). Drop the call with “no such user” reason on fail
Add techprefix if needed
Setup sip parameters if the call was arrived from sip
Normalize called number (check prefix, area code, etc). Drop if wrong number
Check if subsecvent wrong call
Check if the caller exceed its max line restriction
Check blacklist and whitelist
Check the embedded firewall
Check if caller called itself
check if called if a sipuser (Username, telnumber, short telnumber)
check the forwardalways option
check the ringgroup option
setup called endpoint if found
get time variables (peak, holiday, etc)
Get the correct routing pattern
Check routing list in priority order
If simpacket found, than Check simrouting
Drop the call if no route found
Define the radius servers, protocol and login information here. Used for authorization and billing.
Short name for “Best Route Selection”.
In addition to LCR (Least Cost Routing), the Mizu routing engine can take in consideration the quality of the route.
To activate BRS based routing, the “brs_lcr” global configuration option have to be changed to 4 or 5. Then the routing will check both the pricing and the routing, which you can finetune using the “BRS” form (only after you have some traffic, so the table is populated with the statics. If you would like to change the default values, you can do this only directly in the database).
Finetuning means the change of the following fields: accuracy,minprice,maxprice,minasr,maxasr,minacl,maxacl.
The rest is populated automatically based on the call statistics.
If you would like only LCR, simply set the “Quality Percent” field to 0.
If we put some directions with equal priority in the pattern, then the system will choose the routing automatically depending on price and quality, when other settings don't modify the routing (min/max minutes, gw/sim priorities, failovered directions, etc)
The server automatically calculates am „autopriority” on every route. This priority is the combination of the quality and the price. The quality is calculated as an average of daily asr/acl and monthly asr/acl. The price is calculated to pricecalcsec seconds with the given minammount and billingstep (from packet prices). The server route the traffic on the higher priority direction, BUT it will try the other routes periodically (to check if quality have changed). You can change this „next time try” setting by changing the values of TryedCount,NextTry, NextTryCount. If the best quality gateway for a route will change, then we will reset TryedCount,NextTry and NextTryCount values to their defaults. (so the server can recheck quicker)
Fields have the following meanings:
-Id: database identifier. Auto increment
-Gateway: gateway id (called)
-Direction: called prefix
-QualityPercent: how much the quality will contribute to the final result. If price is very important for us, set this value lower. Default is 50%
-Accuracy: how accurate the final result will be. If we set it too high, then we probably will have only one route as the best. If we set it too low then too little discrimination will be made between routes. So, the final result (AutoPriority) will be lowered only if we have too wrong acl, asr or price.
Default is 30%. This default means that the AutoPriority will change only if price will change with 2-3 amount or asr will change with at least 15% (considering asr between 10 and 80, price between 0 and 40 and QualityPercent as 50%)
-ASRDay: last day ASR (automatically calculated every day)
-ACLDay: last day ACL (automatically calculated every day)
-ASRMonth: last month ASR (automatically calculated every month in the last day)
-ACLMonth: last month ACL (automatically calculated every month in the last day)
-MinASR, MaxASR, MinACL,MaxACL: when asr or acl reach the min value, then the line is considered very wrong. When it reaches the max values, then the line is considered very good. Must be configured manually for every direction, because the statistics will change dramatically by country
-MinPrice, MaxPrice: min-max prices/minute. set it to a very wrong price to that direction and the max value to a very good one. Calculate it with consideration to billing step and min minutes (so you must fill in as 1/1 price)
-PriceCalcSec: we estimate the price values with this value to get a gross value
-TryedCount: how much time we have tried this alternative route until now. Helps us the decide how to increment NextTry. It will grow only until 7
-NextTry: we will route calls to this route beginning with this date. Will grow exponentially until 1 month.
-NextTryCount: we will route NextTryCount calls on this route next time. ( > CurrTryCount)
-CurrTryCount: counter to know how many times we have routed in this direction
-AutoPriority: the current priority calculated from these values and from the price settings (the result)
To see how much a parameter change will modify the final AutoPriority value, you can find a demo named AutoPriorityDemo in MManage, Config menu - > Utilities. Before changing any value in the BSR table, please play a little with this demo.
Mizu server and gateway will make automating failowering between outbound gateways if the “CAN_failower” and “hasfailower” global configuration settings are set to true (they are true by default).
The following failowering procedures are done by the mizu voip server:
-gateway failowering: when an outbound gateway has wrong global statistics
-direction failowering:
when only a few direction (prefix) statistics are wrong on an outbound gateway
-failowering on subsequent called number
-in-call failowering (this is also called as “rerouting”)
The failowering module will collect statistics in the background and will detect if a gateway is below the predefined thresholds. This means that its priority will be automatically lowered by the routing module.
Failowering can occur on both gateway and gateway-direction level. When the ASR, ACD, etc is “wrong” for all calls trough a gateway, than the whole gateway is failowered. But there are situation when a gateway can handle most of the traffic gracefully and will fail only to a few direction (direction means 4 digit prefix). In this case only these directions are failowered (this means that even if the gateway is with high priority to these directions, other gateways will be favorized –if you have enabled other gateways in these directions). The failowering are based on ASR, ACD statistics and if there is predefined subsequent wrong calls to a direction. Once a route is marked as failowered, it will be probed time to time to check if the problem was solved. This is happening only a few times (with exponentially increased time intervals) than if the quality is still wrong, the route will be marked as permanently failowered. This routes can be reseted only manually from the failowering form if you set the MaxSubsFail, NoPriorityCount, NoPriorityCountD to 0 and the NoPriority to a date in the past.
The rules can be defined using the “Failowering” form. The table will be populated automatically after your traffic pattern.
You can check the route status also from here.
The following fields are defined:
ID: database id. Auto increment
GatewayID: called gateway or sipproxy
Direction: called direction (prefix)
MaxSubsFail: if we get more wrong calls than MaxSubsFail we failover to the next route if any
MinASR: if we get more lower ASR than MinASR we failover to the next route if any
MinACL: if we get more lower ACL than MinACL we failover to the next route if any
MinCallCount: we calculate ASR and ACL statistics only if we have MinCallCount cdr
SubsFails: current subsequent wrong calls detected
NoPriority: We have done a failover until this date. When the time elapses, we try this route again. This will grow exponentially.
NoPriorityCount: we have failovered NoPriorityCount until now because of SubsFails. The bigger is NoPriorityCount, the longer we do the deprioritization (NoPriority)
NoPriorityCountD: : we have failovered NoPriorityCount until now because of statistics
Manual: all routes will be added automatically to failover table with a minimum of quality requirements
Enabled: failowering enabled
Datum: record insertion or last modification date
Comment: why was the record modified last time (reason)
There are some conditions for the gateway and direction failowering to work correctly:
-the server must have enough
call to calculate relevant statistics (this can be fine-tuned from the
“Failowering” form) ; the default are optimized for medium traffic amount
-some time must elapse for a route to be marked as failowered (too aggressive
settings might result in false failowering)
-you must have at least one secondary gateway/direction where the traffic can be failowered
You should not build your entire business based on the correctness of the failowering module. Outbound gateways should be monitorized on a regular interval (Statistics -> by Called gateways) and you should take remedy actions when the statistics will drop to any outbound gateway (fix the problem or remove it by removing from the routing or set as temporary disabled)
Other important failowering process is the “in-call failowering” or “rerouting”. This means that if the call is rejected by the first route, it can be immediately routed to the next route (without the caller to be disconnected)
Another failowering type occurs when there is at least two subsequent calls to one number and the first call length was below 25 seconds. This is a convenient way to detect if somebody calls a number with wrong voice quality and will call it again in a short time. These can be enabled by the configuration wizard or from the global configuration by the following options.
-maxreroute: how many time a call can be rerouted
-rerouteon: on which conditions a call will be rerouted
-reroutedisccodes: disconnect codes to be received for the rerouting
-noreroutedisccodes: define disconnect codes when there will be no rerouting
All these setting are set by default to optimal values which you can modify after your requirements.
Note: failowering will occur with increased thresholds (more slowly) if the priority between the routing directions (SIP servers) is more than 100.
Skip this chapter if you are not using VoIP-GSM gateways.
Best quality (ASR and ACD) SIM channels can be reserved for sip or h323 originated calls.
In the sim table the reserverfor field can have the following values:
0=cannotreserve: this channel will not be reserved
1=sip: always reserve only for SIP (manually assigned)
2=h323: always reserve only for H323 (manually assigned)
3=ISDN: always reserve only for ISDN (manually assigned)
4=dynamic: can be allocated by the server dynamically (hourly check) -this is the default value
5=sipdynamic: allocated automatically for SIP
6=h323dynamic: allocated automatically for H323
7= ISDNdynamic: allocated automatically for ISDN
For every simpacket you can restrict the maximum allowed reservations by the maxalloc field. (useful to not reserve all channel from the same simpacket)
To setup the channel reservation use the following configuration values (mserver, simplatform config):
-reserveforh323: reserve capacity for h323. reservations will be disabled if less than 1
-reserveforsip: reserve capacity for sip . reservations will be disabled if less than 1
By example if you set the reserveforsip field to 5, you can be sure that 5 channels always remain free to be used by calls received with SIP protocol (H323 originated calls didn’t consume all your channels)
The number portability module can be used to alter the routing if the number is ported to another operator for MNP (mobile number portability) or LNP (local number portability) reasons.
More specifically it can influence the routing in one of the following ways:
· route the call to the server specified by newdomain:newport (The fwdtootherdomains must have to be set to at least 1 for domain routing to have effect.)
· route the call to the SIP server specified by sipserverid (or by carrierid with a lookup from tb_carriermap)
· change the called number as specified by the newnumber field
· add a prefix to the called number as specified by the providerpx field
You can set the ported numbers form the MManage “Number Portabilty” form or you can automate the process by programmatically changing the tb_portednumbers database table. The Export/Import wizard from the file menu can be used to easily populate this table (from CSV or other sources).
You can control the server number portability handling by the “checknumport” global configuration:
-1: auto (will turn to 4 if there are entries in the tb_portednumbers table)
0=not check
1=check for changed prefix only (replace)
2=check for changed number only
3=check for changed domain only
4=check for changed server id only
5=check for changed prefix only (insert)
9=check all
tb_portednumbers:
id: autoincrement database primary key
number: original (normalized) called (B) number
sipserverid: change the SIP server id to this
carrierid: change the SIP server id to this via the tb_carriermap lookup table
providerpx: new prefix (for example instead of 3630 changed to 3620)
newnumber: the changed number
newdomain: the new service provider ip or domain
newport: service port (defaults to 5060)
priority: checked for duplicate numbers
datum: record insertion date
You must have the providerpx OR sipserverid OR carrierid OR newnumber OR newdomain:newport specified.
If certain numbers must go to certain carriers (SIP servers) then you might use the tb_carriermap table to add the carriers and just use the carrierid in the tb_portednumbers table. This way you can easily manage the carriers used for LNP.
An important step for the number portability configuration is the access of the number mapping data. This can be set in the following ways:
· Add the number mapping manually
· Create some tool/script to download the data into the mizu table database (and run in periodically from scheduled tasks)
The data can be extracted from a remote database, http/ftp file download or via an API
· Access the data via an API at runtime (HTTP GET). This can be slow
Country specific:
Country specific operator lookup and LNP lookup can be configured with the numporttype global config option.
Currently the following values are defined:
· 0: default
· 1: Brazil specific
· 2: Mexico specific
For more complex number portability handling with CADUP and SPID rewrite per operator, you can also use the tb_routingprefix and tb_directions table to store these informations (spid and cnl fields). A detailed description about the whole process can be found here.
You might use the mimport application to import the numbers (will require customization for you data source and format).
The current implementation is for Brazil, but that can be adjusted for any country with similar requirements for LNP.
For Mexico specific LNP see the number_portability_mexic.pdf guide and download the mexic specific mimport from here.
Enum lookups can be used to route the calls to other SIP servers directly bypassing the PSTN network to reduce the costs and improve the quality of the calls.
Mizu Servers and Gateways has built-in prepaid and postpaid billing.
The pricing must be set from MManage –Prices Settings form
You can list and compare the prices for different directions in the Price List.
The Billing and Invoice generation are done from the “Billing” form.
A quick tutorial can be found here.
The Billing module conforms to the Hungarian laws and can be modified to fit for other countries.
Pricing of the CDR records are done after the prices defined on this form.
You can define “Price Groups”. All price settings that belong together after some logic (enduser prices for example). This is located in the left side of the Prices form.
Invoices can be generated
automatically by the server and send by email, or can be loaded manually by
using the “Billing” form.
You can schedule when to
send the invoice or report to the partner or for you (defined by the mailto
entry)
The report format can be
defined by “Invoice Type” and “Group by” fields.
Below a “Price Group” you can have several Price Setups named “Directions” or “Packets” (the middle column in the form)
For example “Traffic from MizuTech SRL” or “Traffic to T-Mobile direction”
Here you have to set up the actual prices. The price setup is further divided into different prefixes (the right side of the form -Pricelist), because it is very common that you have lots of directions in a provider pricelist.
An alternative method to assign a price list to a user is by using the “Users and devices” from -> “Billing” tab -> “Billing packet” setting. This will always take precedence over the packets set in the “Price Settings” middle column. This is used to simplify the pricelist assignment for users by resellers.
Field descriptions:
Title: the name of the invoice group
Schedule: how often the
report will be generated
DueIn: allowed time for payment in day (used only if the report is an invoice)
Status: billing status
Invoice Type: specifies
the format of the invoice
Group By: specifies the
format of the invoice
Separate by caller: every
caller will receive a separate invoice (used for billing to end-users)
MailTo: list of email
address where to send the generated report
Last Invoice Sent:
date-time when the invoice was emailed to the recipient
Last Payment Received:
date-time when the payment was received
Direction name: name of the billing entry
Type: specify the type of the price. For example the prices used when billing to endusers, or our minute costs to service providers.
Price calculations will be saved directly in the CDRs, thus can be used in prepaid billing. In the CDR records, the following fields are used for price calculation:
-costprovider: used to calculating the minute price they needs to paid to service provider (Tmobile for example)
-costenduser: used for billing to our endusers (sip endusers, traffic senders)
-costcompany: can be used for profit calculations
-costsales: sales commission. If not set, than will be calculated by the commission value in users settings
-costother: can be used for any custom price calculation
Action: How to handle the
calculated price in reporting. For example in “profit” calculations whe have expenses
(prices paid for service providers) and incomings (from our endusers). Thus we
can simply subtract the expenses from the incomings to get the “profit”
Billing Steps: provider specific billing interval in sec
Min. Amount: the minimum payable duration in sec
Free Amount: you may have packets when the first X second is free
Free After: you may have packets when after X seconds the conversation is free
Currency: different providers may have different currency. Used for billing.
VAT Included: if the pricelist applied for this user is with VAT included. Set to 0 if VAT is not included. Used for billing.
VAT Value: the amount of VAT applied for the pricelist. Will have effect only if “VAT Included” is checked
Convert to NET value: if you have defined the pricelist with included VAT, you should check this option, otherwise you overcomplicate the billing process. Thus the VAT value will be subtracted from the price, and you will have NET values in CDR records (try to use net values whenever possible). If you need to generate invoice, make sure that all your prices are set without VAT (net) or you have checked the “Convert to NET value” checkbox.
Convert to XXX: if you have defined the pricelist in other currency than the native (configurations->currency), than your prices will be automatically converted to native currency in CDR records.
Reseller: price created by resellers. Usually should be changed only by resellers (from web portal)
A leg grace: used for IVR billing. If the user will spend too much time using the IVR.
Traffic Direction: here you have to define the rules when the current pricing will be applied
Usually only one field needs to be specified here (for example all traffic from MizuTech SRL -caller)
The caller field will check the caller parent also, but the called field will not check the parent.
These directions will be checked in priority order on routing and billing
ValidSince, ValidUntill: the pricelist may be applied only after a specified date-time
Prefix: called number prefix (this will be loaded after “best fit”). Set to ‘*’ to be applied to all directions
Price: the actual price
CPrice: the price converted in your currency (“currency” entry in the Configuration form and converted after the values specified in the “Currency Converter” form)
Time Definitions: the time period when this rule is applied
Diff between enduserprice and providerprice means that price will be calculated by extracting the provider cost from the enduser cost for an already existing cdr record. Cannot be used for realtime (prepaid) price calculations. Usually used when calculating “profit” values.
By clicking on the “Clone” button, you can easily duplicate a price list (it is very useful when you have to add only a few modification to a long pricelist)
The Billing button is a shortcut to the billing form (does not make the billing automatically)
Importing price definitions from file are done by clicking on the “Import from file” button.
First of all you must create a packet (middle column) defining the general packet properties and the conditions when it will be used. Then you can import a price list for the packet (right column -> “Import from file” button).
The imported file must be comma separated CSV file format.
You can use the Excel -> Save As functionality to export any Excel sheet as CSV file. You can also easily edit any CSV file in Excel. (Don’t leave empty columns before the columns with data)
The file must have the following fields (columns), in this order:
1. prefix (direction definition; mandatory)
2. price (flat price; mandatory)
3. peak price (if a separate preak time price is required; you might also use a separate packet for peak/offpeak)
4. offpeak price (if a separate off-preak time price is required; you might also use a separate packet for peak/offpeak)
5. billing step (if you need different billing step by prefix instead of defining the same for the whole packet)
6. minammount (if you need different minimum billed amount instead of defining the same for the whole packet)
7. mindigits (this prefix will match only if the called number length is at least mindigits)
8. maxdigits (this prefix will match only if the called number length is at most maxdigits)
Only the first two columns (prefix and price) are mandatory. The rest can be omitted or their value can be empty.
If you use the “default peak time definition”, the peak settings will be loaded from the global configuration (peaktimebegin and peaktimeend values). If this is not suitable (different service providers may calculate with different peak-offpeak definitions), you can set up the peak time definition manually (start – end hour).
If you use flat price, than leave the peak and offpeak price fields empty and vice-versa.
Importing price files may take some time, depending from your network connection speed.
Pricing example:
-a separate provider cost tariff for each of your carriers (where you are forwarding your outgoing calls)
-one enduser cost tariff for your wholesale traffic senders (or a separate tariff for each of them)
-one enduser cost tariff for your enduser or create a few groups (like premium and regular) and setup different pricing for each of them
On the List tab you can list all prices for a packet (by using the “Packet” list box) or to a direction (by entering a direction name or a prefix to the filter box)
On the Least Cost tab you can compare the prices from different service providers.
The Reference Packet usually is the price for your end-users.
Only peak (max) prices are compared for every direction.
On the Directory Check tab, lookups from the directory table are possible ( directory name – prefix match).
The server automatically calculates the price field for every incoming CDR record, based on price settings ( Section 4.5.1)
The following prices are calculated:
-enduser cost: used for invoicing for costumers
-provider cost: cost that needs to be paid for service operators
-sales cost: sales commission. If not defined in price setup, then will be loaded from users’ settings (“commission”) if any
-company cost: usually used for profit calculations
-other cost: for any other purpose
Billing can be done from
1. the “Users and Devices” form, Billing tab, by clicking on the “Generate &Invoice or Report” button (billing for the actual user)
2. set up required directions and click on the “Billing” form (in this manner, billing reports can be generated for more users)
The billing process will always take in consideration the selected date interval.
Billing form:
1. On the Customized Billing tab after selecting the required date-time interval and direction, the prices are calculated after predefined parameters (price/minute, billingstep). So you can do simple calculations using this form.
2. The CDR Prices tab will load the “enduser cost” and “provider cost” directly from cdr records (already calculated after real-time price settings)
3. Generating Reports and Invoices tab
Used for billing and reporting.
Fields explanations:
Provider: you must select the invoice emmitent here. By clicking on the “…” button, you can customize the company invoicing details.
Delete old invoices: if checked, than will clear the invoice files directory before saving the new ones.
Include inactive users: uncheck this checkbox, if you don’t want to generate reports (invoices) for inactive users (inactive for the selected period)
Include child users: for example you can select a Reseller as direction source, and all “child” users will be included in billing (where the parent id will point to that reseller)
Include CDR records: include call detail records in appendix
Language: language of the invoice
Grouping: you can select any grouping options to be generated as appendix for the report
Price values: select the price field from the CDR record after which the billing are done.
Reporting: you can automatically save the generated reports or invoices to file, or open it one by one (you can decide what to do for every report -save, print or just preview)
Format: file format (text, pdf) or printing
Real Invoice: if you would like only a quick report for the selected user(s), you can do it by setting this option to “Don't generate real invoices”. If you choose to generate real invoices, than it will take special processing for it (required for bookkeeping)
If you have selected a reseller, you should choose the “For Resellers” option. In this manner a real invoice only for the reseller company is generated. (A report will be generated for all child endusers, but those report are skipped from the bookkeeping)
Invoice Comment: any comment here. This will not be shown on the report
Money Precision: how many floating point digit would you like in money fields.
Completion date: defaults to the end of filling period if not modified
Method of payment: can be specified here, or loaded from user setting.
By clicking on the “&Generate report for the selected directions” button, you can generate the actual invoice(s)
4. Invoices and Payments
The invoice records for the selected user(s) are in this form. You can watch the debt for every user by checking the topmost record debt value.
By right clicking on a invoice record a menu will appear. From
5. You can change the price settings whenever you want, but don’t forget to Rebill your CDR records after the new settings. All CDR prices will be recalculated for the selected time interval and direction. Users and simcards credits will NOT be modified by rebilling!
6. Individual invoice
On this tab you can create invoices manually (not automatically generated from cdr records)
Note: prior to generate pdf report you should configure the installed print to pdf driver to save automatically in the specified directory. The default pdf printer can be configured in the MManage menu on the Settings-> Options from. The “pdfcreator” driver is included in the MManage install package.
For printing jobs, the default configured printer will be used.
The automatic prepaid credit expirity can be configured with the following settings:
Creditunit:
how many credit means 1 day
Creditelapseunit: prepaid credits will be elapsed automatically after this period is elapsed. Creditelapseunit means the credit amount for 1 day. For example if you set it to 40 and the user will buy 5000 ft credit, than it will elapse after 4 month
Maxcreditelapsedays:
max number of days when the credit will elapse
Accelapsedays: the number of days from creditelapsedt when the account will
expire (account number will be suffixed
with _elps ans set to temporarydisabled)
tb_users. Creditelapsedt: date-time when the credit will be expired
tb_users.Accelapsedt: date-time when the account will be expired
For this to work, you must set the “accountcanelapse” global config option to “true”. The credit expire date is calculated when the credit is added.
*You can set prepaid credit by the “Add with elapse” button to elapse automatically.
Monthly payments can be set for users by completing the tb_fees table. Can be accessed from the Users Form -> Billing tab.
The following fields are defined:
Userid: the user where the payment belongs
Datum: record insertion date
Name: the title of the payment
Value: net price
Usable: can be calculated in minute price (1 if yes, default is 0)
Ival:
-1: one time
0: monthly as soon as possible
Other: internal in days
Lastbilled: last time when the it was invoiced
Description: any comment here
To make the billing stricter, you might also set the following global parameters:
blocknotbilledcalls: 0=no (default),1=if best match packet is not found,2=if no exact packet match with prefix,3=block if not assigned directly for the user,4=check also tarifflist prefix,5=check also parent tarifflist
blocknotprofitablecalls 0=no (default),1=yes,2=yes also if equal,3=block also when it is not set
vgetpriceexactmatch: 0=no (default), 1=yes for resellers, 2= yes for all
notbilledcallerr=0 0=default (error with 2 priority),1=error,2=critical
You can set currency in 3 places:
This will be the default currency for all internal operations
When you receive pricelist in other currency, with this setting you can easily convert it to your native currency
Useful when you need to send invoices in different currency format.
The price in the cdr record will be set based on the “currencyconversion” global configuration value which has the following possibilities: 1=native currency, 2=pricelist currency, 3=user currency if match, 4=user currency
The most easy and simply way is to set the same currency in all places.
Otherwise you must refresh time to time your currency converter table.
Currency converter
Defines the conversion between your native currency and other currencies used in price settings. You should update this conversion prices as many times as possible.
Currency precizion
You can control the money precizion display by the tb_currency_precizion table accessible from Billing -> “Money Precizion”
Id: database autoincrement primary key
Currency: name of the actual currency (for example: HUF, USD, EUR)
Precizion: number of fractioan digits on the invoices
Final Precizion: the precizion of the “Total Payment” display
Final Rounding: rounding in the “Total Payment” (ex: 1 or 5 ft)
Separator: usually ‘.’ or ‘,’
You can use this form for your cash-flow administration regarding your voip business.
Recharge codes used if you have prepaid cards printed.
You can generate random prepaid codes here.
Prepaid account can be charged over the website or by ivr:
Website operation:
-user authentication (tb_users.username and password)
-check if pincard is valid (tb_prepaidcodes)
-increase credit for the user (tb_users.credit)
IVR operation:
-automatic user authentication based on sip registration or require entering the phone number to be charged
-require pincode
-check if pincard is valid (tb_prepaidcodes)
-increase credit for the user (tb_users.credit)
-goodbye message
Every cdr record are handled by the billing module. Prices are determined by the v_getprice stored parameters.
v_getprice parameters:
@type tinyint: type of the billing. 1=enduser cost, 2= provider cost, 3=sales cost, 4 = company profit, 5 = other cost
@callednorm varchar(26): normalized callednumber. example: 36301111111 (B number)
@callerid int: database id of the caller user
@callernum varchar(26): caller number (A number)
@techprefix varchar(4): 3 digit tech prefix if exists
@calledid int: database id of the called user
@calledpacket int: simpacket if exists
@timetype1 tinyint: time period
@timetype2 tinyint: time period
@timetype3 tinyint: time period
@timetype4 tinyint: time period
@currday smallint: weekday number (Monday is 1)
@currhour smallint: call midtime hour
@currmin smallint: call midtime minute
@parentid int = 1: database id for the parent of the caller user
timetypes are considered when you doesn’t set a concrete start-end period in the price list, and you choose from a predefined pattern (peak, offpeak, weekend, weekday, holiday,evening, night). the following timetypes are defined:
0: Disabled
1: Start-End Time
2: Peak
3: Offpeak
4: Weekday
5: Weekend
6: Offpeak and weekend
7: Evening
8: Night
9: Holiday
10: All times
11: Other Times (Rest)
example: v_getprice '1','36301234567',6555,'003615555555','150',666,-1,4,2,99,99,4,11,41,500
The v_getprice stored procedure will return the following fields: tb_billentries.currency,tb_billingtimes.isdiff,tb_billingtimes.origprice,tb_billingtimes.price, tb_billentries.billingstep, tb_billentries.minammount,tb_billentries.freeammount,tb_billentries.freeafter,tb_billentries.vatincluded, tb_billentries.vatvalue, tb_billentries.converttonative,tb_billentries.converttovat
According to returned billing settings, the price is calculated accordingly.
If there are no price defined, than default price are loaded. (if set)
If there are no sales price defined, than will be loaded from user setting (commission)
For enduser prices, the discounts and userreductions are applied if set so. Then the user credit is updated.
If there are any error with the billing process, than the default prices are applied if exists.
Billing verification:
List the required CDR records with “Show minute price option”
You can find the billing logs if you search for the called number in the server logs.
Copy the required v_getprice log in the direct query form.
Check if the returned values are as expected.
Invoices and payments are stored in tb_invoices in the database. So the invoices can be searched, recreated and storno invoice can be built based on existing invoices (conforming to Hungarian laws).
The last invoice number are loaded from database before every new invoice and incremented. Thus the invoice number increment is guaranteed the by database engine transactional behavior.
The following fields are defined:
ID: autoincrement database primary key
Type:
0=All or Recreate (technical)
1=Report
2=Proform
3=Advance
4=Invoice
5= CreditNote
6=Storno
7=Correction
8=Payment (technical: payment received)
Copynum: printed copies
CompanyID: emmitent company ID (tb_billsources)
UserID: costumer ID from tb_users (if any)
User_name: costumer name or company name
User_address: costumer address
User_regnum: costumer registration number
User_euregnum: costumer eu registration number
User_bank: consumer bankdetails (cont and address)
Payment_type: mode of the payment (Ex: bank-transfer)
Datum: record date-time
Invoicenum: the number of the invoice
Invoiceid: deprecated
Invoicefrom: billing period begin time
Invoiceuntill: billing period endtime
Invoicegenerated: invoice print time (optional)
Invoicesent: invoice sent time (optional)
Completitiondate: completition date
Duedate: payment due date
Language: invoice language
Vat: VAT percent
VatValue: sum of VAT
InvoicePrice_Net: final net price
InvoicePrice: final price
PaymentReceived: date-time of the payment
Debt: sum of all debt
Pending: all sum before due date
Comment: invoice comment
InvoiceImage: saved ivoice file
tb_invoice_entries:
Id: autoincrement database primary key
Invoiceid: foreign key to tb_invoices
datum: record insert date
description: product description with code
fromdate: billing period if applied
todate: billing period if applied
Ammount: ammount
AmmountName: name of the amount (minute)
AmmountPrice: unit price (net)
The emmitent (company) settings are stored in the tb_providers table. Only one company entry can be stored (conform to Hungarian laws). Once the company details are inserted to the database, the company name cannot be changed anymore.
Creditelapseunit: prepaid credits will be elapsed automatically after this period is elapsed. Creditelapseunit means the credit amount for 1 day. For example if you set it to 40 and the user will buy 5000 ft credit, than it will elapse after 4 month
Currency: the currency type is loaded from the “currency” global configuration or from the billed user currency setting.
The price setup currency settings also can affect the currency settings.
Currency conversions: if the pricelist is not in the native currency format (set by the “currency” global config option), than the server can convert to it automatically based on tb_currencies. You can change the conversion rates from MManage -> Billing -> Currency converter
Language: the invoice language can be controlled from the invoice form.
PDF Printer and delay: set this on MManage -> Menu-> Options
Time format: if to separe duration values to day/hour/min/sec or display only in seconds. (MManage -> Menu-> Options)
Money precision and rounding and separator are stored in the tb_currency_precizion table, accessible from the Billing form.
MINSPEACHLENONROUTE: the minimum calculated max speechlength when the call will be routed
There are various built-in prepaid and postpaid payment method implemented. Payments are tracked in the tb_invoices table and can be queried later for statistics and reports (Billing -> Reports form)
All credit changes for prepaid users should be logged in this user. Never modify the credit directly. Use the “Modify” button from Users and device -> Billing page if direct modification is required.
Invoices for postpaid user can be generated from the Billing -> Invoices
Chargecards can be generated from Billing -> Pincodes
CallingCards:
There is a special user type called “callingcards” but any usual user can act as a calling card.
Users can access the system via Web or IVR typing a pincode. The pincode will represent the “pincode” column from the user table or the username+password combination for enduser or only the username field for calling cards.
PayPal: direct or indirect handling of PayPal payments are supported. Search for “paypal” in the global configuration to setup. See the FAQ for the details about the configuration.
Your users are allowed to use e-payment and to pay directly with their credit card. Most of the available merchant gateways are supported.
Credit Card and eCheck processing support for every major Internet Payment Gateway using secure data communications using up to 128-bit SSL encryption and Digital Certificates.
The Credit Card validity checks decrease expenses that result from attempting to authorize invalid credit cards.
The current list of supported payment gateways include:
3DSI EC-Linx |
|
ACH Payments |
|
Authorize.Net |
|
Bank Of America |
|
BeanStream |
|
Chase Merchant Services |
|
Concord EFSNET |
|
CyberCash |
|
Cyber Source |
|
DPI Link |
|
ECHOnline |
|
ECX QuickCommerce |
|
eProcessing |
|
eWay |
|
Fast Transact |
|
FirstData / Cardservice Int. |
|
goEmerchant |
|
GoRealTime (Full-pass) |
|
Innovative Gateway |
|
Intellipay ExpertLink |
|
Iongate |
|
iTransact RediCharge HTML |
|
LinkPoint |
|
Merchant Anywhere |
|
Merchant Partners |
|
Moneris |
|
MPCS Weblink |
|
NetBilling |
|
Network Merchants |
|
NexCommerce |
|
NOVA's My Virtual Merchant |
|
NOVA's Viaklix |
|
OGONE |
|
Optimal Payments |
|
PayFlow Link |
|
PayFlow Pro |
|
PayFuse - First National MS |
|
Paygea |
|
PayJunction Trinity |
|
Paymentech - Orbital |
|
Payment Express |
|
Payments Gateway |
|
Payready Link |
|
PayStream |
|
Planet Payment |
|
Plug 'n Pay |
|
PRIGate |
|
Protx |
|
PSIGate |
|
RTWare WebLink |
|
SECPay |
|
SecurePay |
|
SkipJack |
|
Sterling |
|
SurePay / YourPay |
|
TransFirst eLink |
|
TrustCommerce |
|
USA ePay |
|
uSight |
|
Verifi |
|
Verisign PayFlow Pro |
|
WorldPay Select Junior Invisible |
|
YourPay |
|
and more ... |
Search for epayment in the global settings for the configuration details.
To enable the E-Payment module follow these steps:
-1. Install the epayment module: EPaymentIntegrator (request from support if you haven’t received)
-2. Register the e-payment module
-3. Set the epayment_xxxx settings properly in the global configuration
E-Payments can be initiated from softphone, web portal or the module can be accessed by any external application using the console or the database API.
Any other third party payment method can be integarated.
If the “resellerbilling” global config option is set, than reseller cdr records are stored in the tb_cdrresellers and billed accordingly.
To define a “base tariff” for
the reseller the “Is Public” option is used from the “Price Settings” form
(usually applied to an “enduser cost” packet.)
This will be the prices that will have to be paid by resellers to the service
owner.
Reseller can create their base tariff (by setting the “resellerid” in tb_billentries) usually from a web portal. Multiple packets are allowed and packets can be assigned to other users or resellers directly from web (in the same way like on the “Users and Devices” form -> “Billing” tab -> Billing packet setting.
Resellers usually will create their own price lists by cloning an existing list or their base tariff list.
For early billing set the reseller stage field to 9.
Top reseller statistics can be viewed on the “Statistics” form by checking the “OC” and the “PR”/”PFR” fields.
The following features can be used to use various promotions to (new) users:
· First X seconds are free
You might create packets when the first few seconds are not billed.
Just use the “Free amount” option on the Price Setup form for this
· Call X direction for only … cent
Just setup a separate packet with lowered prices for this.
Use only the directions (prefixes) you wish to promote.
· 10 USD free to direction X
Set the “packetcredit” field in tb_users to 10
Create a special packet with the desired directions (prefixes). Set the “isforpacket” field to 1 for this packet(s)
With these settings the cost of the call is calculated with this special packet(s) and the cost will be deducted from the “packetcredit” field instead of the real “credit” field.
· You can offer some directions for the users where they can call Y minutes for free
The followings fields have to be used for this from the tb_users table:
o freeminutes: free minutes included
o freesms: number of free sms messages included
o freeminutesleft: remaining free seconds! (this field will be modified by the server. No more free minutes when reach to 0)
o freesmsleft: remaining free sms (this field will be modified by the server. No more free sms when reach to 0)
o freedirections: numbers separated by comma or a prefix where the free minutes or sms can be used (it can be also a whole number). Empty value for this allows free calls to all directions.
o freedays: set to a positive value if you wish the free minutes to be reset after this number of days (recurring free minutes). Set to 0 to disable reset. (By reset we mean that the freeminutesleft will be set to freeminutes)
o freebegindt: freedays begin date-time
For this feature to be used you might have to set the “checkfreeminutes” global config option to 2. You might also set the “freedirections” global config option to restrict the directions that can be allowed by the tb_users. Freedirections field (if you let this field to be modified freely by the users, for example to select one preferred number or destination prefix)
Example SQL to add 100 free minutes ad 30 SMS for a set of users to prefix 4411:
update tb_users set freeminutes = 100, freesms = 30, freeminutesleft=100*60, freesmsleft=30, freedirections =’4411’, freebegindt=getdate(),freedays=31 where id in (X,Y,Z)
To add 10 free minutes for new users, just set the default value for the “freeminutes” field to 10 in the database.
· Offer some free minutes for all new users (restricted by user IP)
There is another possibility by restricting the maximum number of calls or call duration from a source address by the following global settings:
o maxcallperip: max number of calls from the same IP
o maxdurationperip: max call duration from the same IP
o maxcostperip: max call cost per IP
o maxcallperperiod: the period for the above (1.0 means one day)
o maxcallperuserid: the above will be set to this user only (set to -1 for all users)
Additionally to IP restriction you should set as much other restrictions as possible to restrict your server attack surface, such restricting the usage to one user (maxcallperuserid), set user as prepaid, set max lines and daily/monthly limits on the account as other best practices discussed in this documentation.
See the “Security and account limiting” section,
Call forward billing: 2 cdr record will be generated. A->B and B->C
Call forward from IVR: one cdr will be generated. Whether we charge the call to the IVR or only bill the forwarded call can be controlled by “resetdurationonfwd”
Call transfer by SIP signaling: the second call is completely different from the first call. Billing goes normally (2 calls)
Call transfer with dtmf (*5*): only one call leg is billed
Conference with dtmf (*1*): separate cdr will be generated for all call legs
Conference by sip: technically separate calls. Will be billed normally (2 cdr)
Call forwarding from IVR (2-leg calls):
CDR’s generated based on “ivrbilling” global and user setting: 0: one CDR including the forwarded call, 1: load duration only from forwarded call, 2: generate 2 CDR records (A leg + B leg), 3=both merged,4=merged with short a-leg,5=only b-leg billing if call is connected
Ø ivrbilling is 0: (server side) 1 CDR will be generated with total client call duration. The billing will be done after the final called user (the IVR accessnumber when the call was not forwarded. Otherwise the final destination number)
Ø ivrbilling is 1: (client side) 1 cdr will be generated. The call duration will be set after B-leg call duration and billed accordingly
Ø ivrbilling is 2: (both) 2 (or more) cdr will be generated (when there was call forwarding action). The 2 cdr record can be billed separately after different billing tables
Ø ivrbilling is 3: (both merged) 1 cdr will be generated, but the enduserprice can be loaded from different billing tables (2-leg merged)
Ø ivrbilling is 4: (both merged with short a-leg) 1 cdr will be generated, but the enduserprice can be loaded from different billing tables (2-leg merged). The A leg duration is shortened (only the time spent with IVR until the call forward action)
Ø ivrbilling is 5: (server side if connected –mostly the same like ivrbilling 0) 1 CDR will be generated. If the call was not connected then all duration will be billed (you can setup different billing for these calls by marking the entry as “is ivr call” and set the “called” to the access number. If the call is connected, then the B-leg will be billed (possibly after a different billing packet)
Skip this chapter if you don’t have VoIP-GSM gateways
Id: database primary key. Autoincrement
Provider, type, subtype: the name of the packet
Owner: simowner in case of simpackets
Allowedpartners: applied when it is a simpacket
AbsPriorityPartner: this partner will have big priority on sims that belong to this packet
PriorityPartner: this partner will have increased priority on sims that belong to this packet
NopriorityPartner: this partner will have lowered priority on sims that belong to this packet
Filtering: determines how we check the blacklist and the known numbers
0-no filter: allow all numbers
1-allow blacklist „sure” level: 0,1 and 2 (tb_blacklist)
2- allow blacklist „sure” level: 0 and 1
3-allow only blacklist „sure” level: 0
4-block all blacklist
5-allow only knownnumbers (listed in tb_knowngoodnumbers)
6- allow only knownnumbers that are 100% ok (sure is 1 in tb_knowngoodnumbers)
Dialplan:
0: international number format with 00... (e.g.: 003630xxxxxxx)
1: international number format with +... (e.g.: +3630xxxxxxx)
2: area code + number (0630xxxxxx, 061xxxxxxx)
3: shortest possible number (xxxxxxx in the same simpacket or 0630xxxxxxx in other simpacket)
4: correct it to the most appropriate format if original is not correct
WaitAfterCall: how much time must be elapsed between calls to simcard belonging to this packet
MaxMonthlyMinutes: we don’t route more than MaxMonthlyMinutes to simcards belonging to this packet
MaxMonthlyMinutesPeak: maximum allowed minutes in peak time / month
MaxMonthlyMinutesOffPeak: maximum allowed minutes in offpeak time / month
MaxMonthlyMinutesWeekend: maximum allowed minutes in weekends / month
MinMonthlyMinutes: this packet will run on higher priority until the min minutes is reached
Price: default minute price if not set in tb_packetprices (deprecated. Loaded from pricelist from v.3.2)
BillingStep: second increments (used for calculation simcards minutes –daily, weekly, peak, offpeak)
MinAmmount: min billing seconds (used for calculation simcards minutes –daily, weekly, peak, offpeak)
FreeAmmount: free speech seconds (used for calculation simcards minutes –daily, weekly, peak, offpeak)
MinCreditOnRoute: if the sim has less credit, then we don’t route call to it
MinCreditOnCharge: if the sim has less credit, then we begin trying to charge it
Prepaid: 0=postpaid, 1=prepaid
SendFakeSMS: we send dummy sms on this sim
CanCallEachOther: the simcard in this packet will call each other periodically to generate incoming traffic
IncludeVAT: used when credit message information are received from simcards (typically via SMS) and the simcards credits are calculated without the VAT value
Currency: used when the credit messages received needs to be converted in native currency (“currency” global setting) format. If the currency is not the same as the native currency and the “convertsimcreditcurrency” global setting is set to true, than the received credit value is converted to the native currency, based on “Currency Converter” settings, found in MManage under the “Billing” section
MaxAlloc: helper settings when automatically alocating channels for a direction. (Depending on reserverfor simcard setting).
Here you can define the maximum count of simcards that can be reserved for the actual packet. Set to 0 to disable rezerving from that packet.
Credit Request Command: the command used by the server for sim credit request (used for recharge automation)
Credit Charge Command: the command used by the server for sim credit charge (used for recharge automation)
The request and the charge command must have the following syntax: <DTMF,action,simid,”message”,telnum>
The “chargecode” string in the message will be replaced with a valid code if found.
You can introduce delays by inserting ‘#’ characters in the message.
The action parameter can be
-0: used to send USSD messages
The message parameter must have the following format “AT+CUSD=command” where command is the ussd string.
Example: DTMF,0,simid,"AT+CUSD=1,*121*chargecode#"
-1: will send the specified message to the engine. The message can be any valid AT command
-2: will dial the specified telnum, and then send the message as DTMF.
If the message string if empty, than only will dial the requested telnum, hold a little and then drop.
Example: DTMF,2,simid,"",172
-3: reserved for future usage
-4: will send the specified message as SMS to telnum
Used to configure your Mizu VoIP-GSM gateways.
The fields are the same as listed in section 4.3.1
Listing of gsm channels. The fields are self explanatory.
Skip this if you are not using VoIP-GSM gateways.
Usually this is the most frequently used form by the technical support. You can see the status of each gsm channel on your gateway(s).
Status Filter:
Existing lines: List only current running channels. (this doesn’t mean that the channel is workable. We list all channels who have reported there status in the last 5 minutes)
Good lines: only workable lines are listed. (ok status and with enough credit)
Credit problem: will list the channels with low credit and when the credit request/recharge functionality doesn’t work properly
Wrong lines: list all “bad” channels
Last week detected: all active simcards in the last week
All: all channels including disabled ones
Sim distribution: all existing simcards
Not used postpaid: Some simcards may not receive calls for many days due to some misconfigurations. You may check this list occasionally to be sure that all of your postpaid simcards are working.
Active and not used: Working simcard without calls on it
Monitor: simcards grouped on gsm channels. You may detect missing “holes” very easily by scrolling down this list. This listing is almost the same as in the “Line Monitor” form.
Field Explanations:
ID: database unique identifier
SIM ID: sim identification number (you can find this number written on the simcard)
IMEI: unique gsm engine identifier
Monitor: the status of the channel. The following values are defined:
-unknown: you may have to reload
-missing: no simcard detected
-sim disabled: the “enabled” property of the simcard is set to false. No calls are routed to that simcard.
-gw disabled: the “enabled” property of the gateway is set to false. No calls are routed to that gateway.
-gw missing: no status from this gateway for more than 8 minutes
-sim missing: no status from this simcard for more than 8 minutes
-sim temp. disabled: the simcard “temporarily disabled” property is set to true. You must reenable the simcard to receive calls.
-gw temp. disabled: the gateway “temporarily disabled” property is set to true. You must reenable the gateway to receive calls.
-packet disabled: : the “enabled” property of the simpacket is set to false. No calls are routed to the members of that packet.
-closed: the channel is in the “closed” status. Can be for simchange or maybe is in restart.
-failovered: call quality has dropped below the predefined values, so the sim priority is lowered
-cannot get credit: credit automation malfunction. There are simcards from which the operator may restrict the credit request if they have no credit. Also you may need to check the packet settings related to the credit request. Check the logs too.
-wrong statistics: wrong ASR or ACD in that channel in the current day
-wrong ASR: the ASR is low in that channel in the current day
-wrong ACL: the ACD is low in that channel in the current day
-expired: the simcard has reached the predefined limits (you can configure this limits in the SIM Packets form)
-low credit: not enough credit on this simcard. Check if you have enough chargecards and the credit automation is working correctly.
-autodisabled: same as failovered
-ready (in black): no calls have been routed in the last 10 minutes on that channel (but the simcard is working without problems)
Status: channel status as reported by the gateway. Can have the following values: Gateway Disabled, Off (no info), Not Active, Gateway Disconnected, Closed, Not Ready, Ready, Dialing, Ringing, Speaking, Call Ending, DTMF, Simulating Outgoing, Simulated Incoming, Routing to SIMID, Routing to Alias, Routing
Line: the number of the gsm channel (usually from 0 to 7)
SimPos: the position of the active simslot in the current engine (usually from 0 to 7)
SIM Owner: the owner of the SIM Card
PartnerID: The database ID of the owner user
CanWatchPartnerID: database id of the partner who can see this simcard
in there VPC
Packet: the type of the SIM Card
TodaySpeachLength: the number of active minutes on the current simcard since 00:00
ThisMonthSpeachLength: the number of active minutes on the current simcard since the first day of the current month
ThisMonthSpeachLengthPeak: the number of minutes since the first day of the current month in peaktime
ThisMonthSpeachLengthOffPeak: the number of minutes since the first day of the current month in offpeak times
ThisMonthSpeachLengthWeekend: the number of minutes since the first day of the current month in weekends
Username: Gateway Alias
Credit: current credit on the simcards. Refreshed after all calls, and corrected after credit requests (VAT included!)
InitialCredit: you may save the initial credit of the simcard here
Tpercek: special field for TMobile Tminutes
AllowedPartners: comma separated list of allowed partners and traffic senders. ‘*’ will allow all. You may restrict the access on gateway or simpacket level instead of setting it for all simcards separately. Try to use the packet “allowedpartners” setting and leave it as ‘*’ for the simcards!
Prepaid: loaded from the packet settings (1 if prepaid, 0 if postpaid)
Datum: the date when the simcard was inserted in the database (first use)
Comment: you may place any comment here
LastError: last error message received from the gateway related to the actual simcard
LastLog: last log message received from the gateway related to the actual simcard
LastFailedCalls: the number of subsequent failed calls (not connected calls)
LastWrongCalls: the number of subsequent wrong calls (below the predefined speech length)
LastGoodCalls: : the number of subsequent good calls (above the predefined speech length)
FieldStrength: combination of last reported field strength value in percent (0-100%) and the rx quality (from 0 to 7. 9 is invalid).
Value = field strength*10+rxqual (divide with 10 to get the fieldstrength. The remaining is the rxqual)
Pin: the security code of the simcard
LastRecTime: : the date-time of the last message received from the simcards. Every channel will send status messages in every 2 minutes and on status changes
LastCallerid: the destination id of the last call attempt
LastDialedNum: the called party number of the last call on the simcard
LastCallBegin: the date-time of the last call attempt on the simcard
LastCallEnd: the date-time of the last call attempt on the simcard
Enabled: set to 0 to disable the simcards instead of deleting it
TemporarilyDisabled: you can disable the simcard temporarily for maintenance tasks by setting this value to 1
DisabledUntil: used for automatic failovering. If the value is above the current time, the simcard is in failovered state
DisabledCause: last disable cause explained
ReenabledCount: how many times have the simcard reenabled after a failover
LastReenabled: the date-time of the last reenabling operation
TodayCallCount: call attempts from 00:00
ThisMonthCallCount: call attempts from the first day of the current month
AllCallCount: all call attempts on the simcard until now
AllWrongCalls: all wrong calls on the simcard until now (speech length below the predefined value)
AbsolutePriority: if you set it higher then on other sims, all calls will be routed here primary
Priority: routing priority boost
Filtering: determines how we check the blacklist and the known numbers
0-no filter: allow all numbers
1-allow blacklist „sure” level: 0,1 and 2 (tb_blacklist)
2- allow blacklist „sure” level: 0 and 1
3-allow only blacklist „sure” level: 0
4-block all blacklist
5-allow only known numbers (listed in tb_knowngoodnumbers)
6- allow only known numbers that are 100% ok (sure is 1 in tb_knowngoodnumbers)
Co_....: fields used by server for fake call and sms simulations
BestDirection: used for automatic simallocation
BestPrice: used for automatic simallocation
EngineID: the corresponding engine (tb_engines.id)
Credit automation related fields:
CheckCredit: credit calculation or request/charge operations needed
CrequestEnabled: automatic credit request enabled/disabled (1/0)
LastCreditRequestTry: the date-time of the last credit request command issued by the server
AllCreditRequestCount: the number of credit requests
LastCreditAnswer: the date-time of the last answer to the credit request command
CreditRequestFails: subsequent failed credit request. Check the credit automation logs if this goes above 3
LastCreditRequestFail: : the date-time of the last failed credit request
ManualCreditRequestNeed: when set to 1, the server will request the credit from the simcard in 5 minutes
ChargeEnabled: automatic recharge is enabled/disabled (1/0)
MustCharge: when set to 1, the server will charge the simcard in 5 minutes
LastCreditChargeTry: the date-time of the last credit charge command issued by the server
LastChargeCardID: the database identifier of the last charge card used for this simcard
LastChargecardPrice: the value of the last charge card used for this simcard
CreditWhenCharged: the credit value after the last recharge operation
AllChargeTryCount: number of charge operations until now
AllChargePrice: the sum of the total charge card value
FailedCharges: subsequent failed charge requests. Check the credit automation logs if this goes above 3
LastChargeSuccess: the date-time of the last successfully completed charge operation
LastChargeFail: the date-time of the last failed charge operation
CreditDiffErrors: too big difference detected on sim credit reports
Same as “GSM Channels”. See section 4.2.2
The first field will show the status of the simcard (Monitor). The most frequently used values are the followings:
Unknown: the last list refresh is too old. Status cannot be determined. Click on the reload button to refresh
Missing: simid not found. Corrupt entry
Sim Disabled: simcard “Enabled” is set to false
GW Disabled: gateway “Enabled” field is set to false
GW Missing: last message received from gateway is more than 8 minute old
SIM Missing: last message received from simcard is more than 8 minute old
SIM Temp. Disabled: simcard “Temporary disabled” field is set to true
GW Temp. Disabled: gateway “Temporary disabled” field is set to true
No Packet Set: no packet settings are present for this sim. You always need to set the correct packet settings for all simcards
Packet Disabled: simpacket “Enabled” field is set to false
Closed: simcard channel status is set to closed. A simchannel can be closed for different reason. Cannot register to gsm network, Sim Change, Just restarted, etc. If this status persist, check the logs for that simcard
Failovered: server has detected wrong quality on the simcard. Traffic will be forwarded to other simcards if possible
AutoDisabled: same as “Failowered”
Cannot Get Credit: automatic credit request failed. Check the credit automation log for errors
Wrong Statistics: wrong statistics for the current day
Wrong ASR: wrong ASR detected on the channel. Treshold values can be set up from the MManage -> Menu -> Settings
Wrong ACD: too small average speechlenth detected on that simcard
Expired: maximum monthly or daily speechlength limit reached (SimPacket option)
Low Credit: prepaid simcard expired
Gateway Disc.: gateway is offline or just restarting.
Not Ready: simcard is not ready for some reason. Maybe just starting. Checj the logs if this status persist
Ready: simcard is ready to accept incoming call
Dialing: outgoing call setup in progress
Ringing: ringing signal received from gsm network
Speaking: gsm engine is ringing or call in progress
Call ending: dropping the current call
DTMF: dtmf or credit request/recharge message in progress
Simulating incoming/outgoing: calls between simcards generated by the server
Routing: the call have been routed from the server, but still not arrived to the gsm gateway. If this persist, check the log for errors. Usually means firewall/NAT problems
Note: dialing, ringing and call ending messages may not be shown in the monitor depending from the gsm gateway configuration.
If the “sendallstatus” setting is set to false, than instead of “dialing” and “ringing” only the “speaking” message will be shown.
For Identification of sms and dtmf messages received from simcards that are useful for credit request and charge
Type: 0=other, 1=succ charge without credit info,2=credit start/end, 3=failed charge, 4=need charge
Msgbgn: begins with
Msgeng: ends with -used if type is 0 (replace) or 2 (end of credit), 4 (new credit. usually 0)
Priority: check order (longer messages usually first, to not include shorter) –higher values first
All simslots are listed here.
Probability values:
not sure: the simcards was seen more than one month
probably: the simcards in the last month
sure: the simcards in the last week
The other fields are the same as described in section 4.2.2.
List of simcards in call duration order.
You can add new simcards by using this form.
However, the simcards are usually added automatically. If they are active in the gateway they will register automatically. Usually only the owner and the packet must be set manually.
Add new chargecards with this form.
The charge card will be charged only on the simpackets selected (“packets for”) and if the owner will match.
In the SIM Bank form you can monitor the sim flying activity.
Global system configurations.
Basic configuration are vital for the system to run correctly.
The following config settings are defined:
Category |
Key |
Description |
CallCenter |
allowdbcalls |
Allow calls from database in MAgent |
CallCenter |
allowmanualcalls |
Allow manual calls from MAgent |
CallCenter |
allowopcampchange |
Allow operators to change its campaign from MAgent |
CallCenter |
autoformname |
Type of AutoCall GUI to load |
CallCenter |
callbackautorecall |
1= schedule for recall if number is in campaign |
CallCenter |
callbackhandling |
handling incoming calls: 0=dropp all |
CallCenter |
callbackivr |
play special messgae (callback.wav) if no operator found or ring timeout expired |
CallCenter |
callbacknumber |
A number for calls. For example the predective dialer will use this number |
CallCenter |
callbackringtimeout |
ring timeout on callback (after than play ivr message if set) defrecallmin |
CallCenter |
callbackroutenumber |
number to be dialed on incoming calls when callbackhandling is 1 |
CallCenter |
CALLCENTERPORT |
callcenter tcp port number (for requesting new clients) |
CallCenter |
callmaxring |
max ring time in sec |
CallCenter |
callmaxwait |
max worktime for operators between calls |
CallCenter |
callnumbertype |
Preference order of numbers (if more than one number exists for a client): 0=first try landline |
CallCenter |
callretryival |
seconds to wait untill to redial the client |
CallCenter |
ccorder |
client call order: 0=database id order |
callcenter |
defrecallmin |
recall data-time will be shown with the specified minute in MAgent |
CallCenter |
desireddropprate |
optimal percent of calls wich cannot be assigned to operators when in predective |
callcenter |
finishvoice |
default file when set to "finish with voice" in scripts |
CallCenter |
handlingincoming |
0=not handled |
CallCenter |
maxcallatonce |
max number of calls in one round when in predective (error guard) |
CallCenter |
maxcallsperminute |
max new call attempts/minute when in predective (error guard) |
CallCenter |
maxcalltrycount |
max attemt of calls for a client |
CallCenter |
maxrecallafter |
client can be recalled in this interval |
CallCenter |
maxrecallafterall |
client can be recalled in this interval by any operator |
CallCenter |
maxrecallbefore |
client can be recalled before the specified time |
callcenter |
maxrecallmin |
restriction of the recall date-time input in MAgent |
CallCenter |
maxrecalltrycount |
max attemt of REcalls for a client |
CallCenter |
mobileratio_08_12 |
percent of mobile calls in the specified period [1-100] |
callcenter |
mobileratio_12_16 |
percent of mobile calls in the specified period [1-100] |
CallCenter |
mobileratio_16_20 |
percent of mobile calls in the specified period [1-100] |
CallCenter |
mobileratio_20_08 |
percent of mobile calls in the specified period [1-100] |
CallCenter |
mobileratio_weekend |
percent of mobile calls in the specified period [1-100] |
CallCenter |
predectivecheckival |
controlls the speed of the predective dialer thread -advanced technical setting |
CallCenter |
predectivecorrection |
correction of precalculated success ratio statistics in predective. for example if we set it to 80 |
CallCenter |
predectivecutnofreeop |
disconnect pending predective calls if no more operator waiting |
CallCenter |
predectivedial |
dialing mode: 0=simple MAgent requests |
CallCenter |
predectivelogging |
details of predective logs (0=no logs |
CallCenter |
predectivemaxsucccalls |
max predective calls in the same time (check in calllist) |
CallCenter |
predectivemaxsuccmobilecalls |
max predective mobile calls in the same time (check in calllist) |
callcenter |
presentationmode |
0=no presentations |
CallCenter |
quotastatrecalcival |
how often the quotas will be recalculated |
callcenter |
recallonlyinsamecampaign |
call only with its own campaign (no recalls from other campaigns) |
CallCenter |
recallrescheduleival |
if call continue to fail |
CallCenter |
recallrescheduleivalfirst |
if call failed for the first time |
CallCenter |
recallrestrictions |
recall mode: 0=give to the same operator |
CallCenter |
savemode |
level of saving data - 1=automatikus mentes a kovetkezo kerdesre ugraskor |
CallCenter |
statival |
rebuild predective statistics interwal (-2 = automatic) |
CallCenter |
stopwrongcdrc |
pause predective if the ASR is too low (error guard) |
CallCenter |
waitforpredective |
max time to wait for a free operator when a predective call is connected |
CallCenter |
waitifnotaccepted |
max time to wait in MAgent if the client is not "accepted" |
CallCenter |
waitifnotconnected |
wait after calls even if was not connected (operator worktime) |
gatekeeper |
h323debuglog |
write h323 gk log to logfile |
license |
CAN_alert |
default license (will have no effect if you change it here) |
license |
CAN_billing |
default license (will have no effect if you change it here) |
license |
CAN_failower |
default license (will have no effect if you change it here) |
license |
CAN_filtering |
default license (will have no effect if you change it here) |
license |
CAN_gsmextra |
default license (will have no effect if you change it here) |
license |
CAN_hash323 |
default license (will have no effect if you change it here) |
license |
CAN_hassimbank |
default license (will have no effect if you change it here) |
license |
CAN_hassimplatform |
default license (will have no effect if you change it here) |
license |
CAN_hassip |
default license (will have no effect if you change it here) |
license |
CAN_recharge |
default license (will have no effect if you change it here) |
license |
CAN_runsipproxy |
default license (will have no effect if you change it here) |
license |
CAN_sipextra |
default license (will have no effect if you change it here) |
license |
FULLRIGHTS |
default license (will have no effect if you change it here) |
license |
lic_isset |
default license (will have no effect if you change it here) |
license |
LICENSEMAXMONTH |
default license (will have no effect if you change it here) |
license |
LICENSEMAXYEAR |
default license (will have no effect if you change it here) |
license |
MAXALLUSERS |
default license (will have no effect if you change it here) |
license |
MAXCCALS |
default license (will have no effect if you change it here) |
license |
MAXCHANNELS |
default license (will have no effect if you change it here) |
license |
MAXGATEWAYS |
default license (will have no effect if you change it here) |
license |
MAXSIPUSERS |
default license (will have no effect if you change it here) |
license |
MAXSL |
default license (will have no effect if you change it here) |
license |
MAXTRAFFICSENDERS |
default license (will have no effect if you change it here) |
license |
SRVVERSION |
default license (will have no effect if you change it here) |
licensecfg |
hasalerting |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hasbilling |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hascallcenterin |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hascallcenterout |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hasextra |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hasfailower |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hasfiltering |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hasgsmextra |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hash323 |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hasrecharge |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hassimbank |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hassimplatform |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
hassip |
modules to load (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxallusers |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxcallspermin |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxccalls |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxccallsblock |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxchannels |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxgateways |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxgsmgateways |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxivrspeechlen |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxregistrations |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxsessionspeechlen |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxsipusers |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxsl |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxtagents |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
maxtrafficsenders |
limitations (has effect only if not prohibited by builtin license restriction) |
licensecfg |
runsipproxy |
run h323 - sip translator |
settings |
adminport |
adminport |
settings |
alertonlowdiskspace |
alert on low disc space |
settings |
aliasrouting |
allow lrq routing |
settings |
allownumbersendback |
allow to route back the call to the caller |
settings |
autodetectlocalip |
automatically overwrite the localip value if set to true |
settings |
autoholiday |
holiday routing and billing treated as Sunday |
settings |
billshortnumlength |
number that are smaller than this value will not be billed |
settings |
bindip |
bind to this ip (for multihomed servers or if we run multiple serers on the same maschine) |
settings |
boostonfirstcall |
if to start with low priority and boost it when the first call arrives |
settings |
brs_lcr |
routing algoritm: 0=not used |
settings |
buildloadstatistics |
tb_loadstatistics |
settings |
canaoutosaveinifiles |
if we can save unsaved items |
settings |
canrestartformalfunctions |
0=cannot restart |
settings |
cfg_block711 |
if g711 (PCMU |
settings |
checkblacklist |
0=no check |
settings |
checkcallerids |
wich calls are to be checked on the selfcheck thread (useful if you have wrong traffic senders) |
settings |
checkcputime |
if cputime is constantly high |
settings |
checkcredirights |
if to check the owner of the sim and chargecards |
settings |
checkgkcdrs |
if to check cdr records from the gk statusport |
settings |
checkgsmnumlen |
if to allow incoming number only with this size |
settings |
checkknownnumbersex |
0 = no |
settings |
checklocalnumberpx |
local endusers prefix to check (to not route to other servers). if emty |
settings |
checklocalnumbers |
check local endusers on routing |
settings |
checkmaxlines |
check max used lines to client and partner |
settings |
checkmaxlinetb |
extended check for max lines (tb_maxlinep) |
settings |
checkmaxnumlen |
max called number length allowed |
settings |
checkminnumlen |
min called number length allowed |
settings |
checknumlen |
if to check the incoming number len //14 |
settings |
checknumport |
check number portability |
settings |
checknumportpx |
check number portability for this prefixes |
settings |
checkpacketfailowering |
0=don't check |
settings |
checkprefixes |
check asr/acd for alerting and wachdog only for this prefixes. must be in the following format: 'xxx' |
settings |
checkprefixroules |
set to 1 to check additional prefix rules. by default only H323 ip prefix rules are applied |
settings |
checkrouterrights |
callprefixrights and partner binding |
settings |
checksss |
check special numbers |
settings |
connectondisccode |
if to connect the sipcall before to play the disconnect reason. 0=not connect |
settings |
country |
used in number normalizations |
settings |
countryprefix |
used on routing |
settings |
creditcheckforpostp |
check credit for postpaid users too (max limit) |
settings |
creditcheckforts |
check credit for traffic senders too |
settings |
currency |
local currency |
settings |
dailymainttaskhour |
when to perform daily maintenance tasks |
settings |
dbdelbackupdir1 |
additional backup directory to cleenup |
settings |
dbdelbackupdir2 |
additional backup directory to cleenup |
settings |
dbdelbackupdir3 |
additional backup directory to cleenup |
settings |
dbloglevel |
db server loglevel (0=only errors to monitor |
settings |
dbmaint_backupdbdir |
database backup directory |
settings |
dbmaint_backupdbnetworkdir |
database backup directory path (if the database engine is located on a remote server) |
settings |
dbmaint_backuplevel |
0=no backups |
settings |
dbmaint_backuptables |
backup cdr records and other tables to xxx_backup: 0=no |
settings |
dbmaint_do |
do database maintanance |
settings |
dbmaint_removecdrs |
remove cdr records after x days |
settings |
dbmaint_removelogs |
remove logfiles after x days |
settings |
dbmaint_removeother |
remove other tables records after x days |
settings |
dbtimeout |
database query timeout |
settings |
defaultenduserprice |
if no price entry found |
settings |
defaultproviderprice |
if no price entry found |
settings |
defcallerid |
default caller id for cdr records if cannot be determined exactly |
settings |
deldbbackup |
delete old backup files after this day elapsed |
settings |
deleteoldlogfiles |
delete older logfiles than the specified day (set to 0 to disable) |
settings |
emailbatchwait |
bulk email sender wait interval |
settings |
emailfromaddr |
default email config |
settings |
emailfromname |
default email config |
settings |
emailhost |
smtp server used for alerting |
settings |
emailsubject |
default email config |
settings |
emailuser |
smtp username used for alerting |
settings |
emergencydir |
route emergency calls to this gateway (user id) |
settings |
enablefirewall |
enable/disable builtin firewall and dos attack filtering |
settings |
enforcestrongauth |
enforce authorization and strong passwords |
settings |
estimatedspeachlenoncard |
sim card config |
settings |
eveningbegin |
evening begins at that hour. used for common time intervalls |
settings |
fakegwalias |
will route the wrong calls here. set to FBACKUPGW if needed |
settings |
faxfromaddr |
fax sender configuration (email to fax server) |
settings |
faxfromname |
fax sender configuration (email to fax server) |
settings |
faxhost |
fax sender configuration (email to fax server) |
settings |
faxnormalize |
fax sender configuration (email to fax server) |
settings |
faxsubject |
fax sender configuration (email to fax server) |
settings |
faxsuffix |
fax sender configuration (email to fax server) |
settings |
faxuser |
fax sender configuration (email to fax server) |
settings |
fileloglevel |
file server loglevel (0=only errors to monitor |
settings |
filetransferbufflen |
fileserver buffer length |
settings |
filetransfertick |
fileserver speed |
settings |
freenumlen |
number length that can be called free of charge |
settings |
gkcommand |
how to start the h323 gatekeeper |
settings |
gkstoptick |
gk setting |
settings |
globalcdrid |
server generated. don't touch |
settings |
gmtdiff |
the difference to gmt (useful for sip date header) |
settings |
gsminccallerip |
convert incoming caller ip from gsm gateways when forwarding to a support phone (incall action in gsm gateways is 3) |
settings |
incduration |
to increase cdr duration. 1=small inc ~ 1% |
settings |
internal_endusercost |
enduser price for internal calls (between endusers) |
settings |
internal_providercost |
provider price for internal calls (between endusers) |
settings |
InternalIP |
sipserver internal ip (interface to clinets) |
settings |
keepbackuprecorded |
days to keep voice records in the backup directory |
settings |
keeprecorded |
days to keep voice records |
settings |
LocalIP |
sipserver external ip |
settings |
loglevel |
other server loglevel (0=only errors to monitor |
settings |
lognofreecardc |
list free card data when no route found |
settings |
logsqlcommands |
trace sql commands (log) |
settings |
logtodb |
trace to database (log) |
settings |
logtofile |
trace to file (log) |
settings |
maxdisableonss |
reserver sim capacity config |
settings |
maxgkmemoryutilization |
max memory for gatekeeper in KB (restart if exceed) |
settings |
maxloglisten |
max log message quee length |
settings |
maxmemoryutilization |
max memory utilization in KB (restart if exceed) |
settings |
maxnocdrmin |
will take the correspondig action if no cdr record found in the last "maxnocdrmin" minute. set to 0 to disable checks |
settings |
maxnogkcallmin |
will take the correspondig action if no new call |
settings |
maxnologival |
will take the correspondig action if no log entry found in the last "maxnologival" minute. set to 0 to disable checks |
settings |
maxnosip2h323callmin |
will take the correspondig action if no sip2h323 call |
settings |
maxpriceperminute |
will alarm if providerprice is bigger |
settings |
maxrecdiff |
recorded voice stereo sync in msec |
settings |
maxrecdiff2 |
recorded voice stereo sync in msec |
settings |
maxroutereqpermin |
allow only "maxroutereqpermin" routing request/minute |
settings |
maxudpselect |
max socket on select (set to -2 to autoconfigure. -1 means no limits) |
settings |
minacd |
min acl value |
settings |
minactivegateways |
will take the correspondig action if not enough gateways |
settings |
minactivesims |
will take the correspondig action if not enough channels |
settings |
minasr |
min asr allowed. will alert/reset if lower |
settings |
minblockcallcount |
mincallcount to check in periodic blacklist refresh |
settings |
mincdrcount20min |
minimum number of calls/20 min. restart if lower |
settings |
mincreditoncharge |
general credit limits |
settings |
mincreditonroute |
credit limits |
settings |
minfreechargecards |
min free sim charge card |
settings |
minlinetoprefix |
min line to the predefined prefix |
settings |
minlogdelay |
minimum delay between writing two log messages in msec |
settings |
minmemoryutilization |
will restart on offpeak if exceed |
settings |
minprofit |
alerting threshold |
settings |
minprofitpercent |
alert config |
settings |
minsubsecventcallbegin |
wait at least minsubsecventcallbegin when route to the same channel |
settings |
mobileprefixes |
mobile number prefixes |
settings |
monitorport |
default monitor port |
settings |
nightbegin |
night begins at that hour. used for common time intervals |
settings |
normalizenumbers |
0=not at all |
settings |
numfiltering |
blacklist/whitelist filter (0=don't filter |
settings |
onlyroutealias |
you can set a gateway here. all traffic will be routed to that gw |
settings |
onlyroutesim |
you can set a simid here. all traffic will be routed to that sim |
settings |
peaktimebegin |
peaktime settings for billing and routing |
settings |
peaktimebegintr |
peaktime settings for various operation |
settings |
peaktimeend |
peaktime settings for billing and routing |
settings |
peaktimeendtr |
peaktime settings for various operation |
settings |
ppriority |
0=low |
settings |
removetrailinghash |
remove # when routing |
settings |
restartatnight |
set to true if you want a reset every night |
settings |
restartpcatfirst |
restart the pc immediately on error (don't restart the sw) |
settings |
rotatelogfile |
create separate logfiles for every day |
settings |
rrr_black |
blacklist q931 disconnect code. defaults to ResourceUnavailable = 47 |
settings |
rrr_denied |
access denied q931 disconnect code. defaults to ChannelUnacceptable = 6 |
settings |
rrr_desterr |
wrong destination q931 disconnect code. defaults to DestinationOutOfOrder = 27 |
settings |
rrr_err |
routing error q931 disconnect code. defaults to TemporaryFailure = 41 |
settings |
rrr_nogw |
no capacity q931 disconnect code. defaults to NoCircuitChannelAvailable = 34 |
settings |
rrr_tomany |
too many wrong request q931 disconnect code. defaults to Congestion = 42 |
settings |
rrr_wrongnum |
wrong B number q931 disconnect code. defaults to InvalidNumberFormat = 28 |
settings |
runfakegw |
if to run local fake h323 gw to offload exceeding traffic |
settings |
runstatistics |
long havy cdr statistics |
settings |
salescomissionfromprofit |
The defined commission percent will be calculated for the profit or for the enduserprice |
settings |
sendmailalert |
if to send alerts on critial errors (pease configure the emailalertX settings) |
settings |
serverftpdailydir |
create separate directory for recorded voices daily |
settings |
serverftpdir |
used for inifiles |
settings |
serverftpvoice |
where to store recorded audio |
settings |
servername |
server name (will appear in reports |
settings |
shortnum_endusercost |
enduser cost for short numbers |
settings |
shortnum_providercost |
provider cost for short numbers |
settings |
sipcommand |
how to launch the local h323-sip server |
settings |
SIPH323GWID |
sip to h323 protocoll conversion will be done using this gateway or module |
settings |
siph323gwid2 |
sip2h323 user id (if -1 than will load automatically) |
settings |
skipsqlerrors |
if to skip sql errors (not throw) |
settings |
storecdrcomments |
sore comment to cdr records. 0=no |
settings |
storeduplicatecdr |
store separate cdr record for sip 2 h323 conversions |
settings |
usedefaultdisccodes |
don't use customized disconnect codes |
settings |
usedelayedupdate |
sql upfates in separate thread |
settings |
usewrongnumfilter |
block (nearly) subsecvent wrong callednumbers (0=don't block |
settings |
voicebackupdir |
where to store a backup of recorded conversations |
settings |
weekendispeak |
peaktime settings for billing and routing |
settings |
weekendispeaktr |
peaktime settings for various operation |
settings |
wrongnumcache |
remembered callednumbers. used if usewrongnumfilter is not 0 |
settings |
wrongnumdropcount |
drop call if this number of failed calls found in cache. . used if usewrongnumfilter is not 0 |
SIMAllocation |
simallocivaltype |
simbank config |
SIMAllocation |
simallocsendival |
simbank config |
SIMAllocation |
simalloctimebefore |
simbank config |
SimPlatform |
allowlastsim |
specify to allow two subsequent calls to be routed on the same simcard |
SimPlatform |
allowlastwrongnum |
specify to allow subsequent wrong number |
SimPlatform |
allowoldstat |
allow old status messages |
SimPlatform |
autosimalloc |
automatically allocate simcards |
SimPlatform |
brsforgsm |
check BRS for gsm gateways too |
SimPlatform |
checkcredirights |
sim and chargecard rights |
SimPlatform |
checkcreditandcharge |
if to run the creditcheck thread |
SimPlatform |
checksimsdisable |
automatic simcard prioritization based on ASR and ACD |
SimPlatform |
checktpercek |
allow tpercek exception in routing |
SimPlatform |
checkwestelcards |
Hungarian specific |
SimPlatform |
convertsimcreditcurrency |
convert incoming credit message to native currency (defined by "curerency" config value) |
SimPlatform |
convertsimcredittonovat |
conert oncoming credit message to not include VAT values |
SimPlatform |
creditchecktimeival |
run the creditcheck thread for every X interval |
SimPlatform |
creditunit |
usefull in credit checks. equilavent with 600 ft. less if you want more precise credit calculations |
SimPlatform |
defaultsimpacket |
use the default packet for new simcards (simcards without a packet) |
SimPlatform |
enforcegwname |
accept only gateways with valid name. the 'GW' suffix must be present in names |
SimPlatform |
estimatedspeachlenoncard |
needed for routing |
SimPlatform |
fakesmscount |
fake sms messages by sim / month |
SimPlatform |
fieldstrengthstatistics |
build fieldstrengthstatistics |
SimPlatform |
fnosamecountyc |
used for fake sms and calls. every fnosamecountyc sms/calls will go to some other country |
SimPlatform |
fnosamepacketc |
used for fake sms and calls. every fnosamepacketc sms/calls will go to some other simpacket |
SimPlatform |
fnosameprovidc |
used for fake sms and calls. every fnosameprovidc sms/calls will go to some other provider |
SimPlatform |
gkpname |
gatekeeper name |
SimPlatform |
gkrstifnotconnected |
restart the gk if not connected |
SimPlatform |
gsmgwport |
port for the gsm gateways |
SimPlatform |
gsminccalled |
forward incoming call from gsm gateway to this number |
SimPlatform |
gsminccaller |
convert incoming caller number from gsm gateways when forwarding to a support phone |
SimPlatform |
gsminccallerip |
gsminccallerip |
SimPlatform |
gsminfromip |
fromip |
SimPlatform |
gwstatistics |
to build the table or not |
SimPlatform |
incomigcalls |
simulate incoming calls on simcards. 0=no |
SimPlatform |
incomingcallcount |
number of incoming call/month by simcard (if the incomigcalls options is set to 1 or 2) |
SimPlatform |
lowercredit |
sss |
SimPlatform |
maxallowedcredit |
only values below are valid (when received in sms or dtmf) |
SimPlatform |
maxflysims |
max flying simcards |
SimPlatform |
maxsimpreconfig |
max credit rec delta |
SimPlatform |
maxsimpriceonalloc |
max accepted price |
SimPlatform |
mincreditoncharge |
min credit |
SimPlatform |
minfreelines |
will take the correspondig action if not enough free line found |
SimPlatform |
minsimlastrectime |
elapsed minutes when the server decide that the channel is offline |
SimPlatform |
onlyroutealias |
route all calls to this gateway |
SimPlatform |
onlyroutesim |
route all calls to this simcard |
SimPlatform |
reservedef |
reserver capacity |
SimPlatform |
reserveforh323 |
reserve capacity for h323. reservations will be disabled if less than 1 |
SimPlatform |
reserveforsip |
reserve capacity for sip . reservations will be disabled if less than 1 |
SimPlatform |
sendfakesms |
send sms messages between simcards |
SimPlatform |
simalloccangominus |
we may activate sims that have negative values |
SimPlatform |
simcreditdiv |
reported credit must be divided by this number |
SimPlatform |
succchargetime |
minimum time between succesive charge try on the same simcard in minutes |
SIPSettings |
ABSOLUTETIMEOUT |
max session time (call duration + setup time + clearing time) in seconds |
SipSettings |
addcontentdispozition |
0=no;1=optional;2=required |
SIPSettings |
allowcallunregistered |
allow to call before registered (terminals) |
SIPSettings |
allowdiscmessage |
allow disconect reason voice playback |
SipSettings |
allowlist |
INVITE |
SIPSettings |
CanAcceptLocalIp |
Can call from 127.0.0.1 |
SipSettings |
cancutsipnumbers |
packet dialplan for sipnumbers |
SipSettings |
canmove |
0=not allowed |
SipSettings |
checknomedia |
disconnect calls on rtp disconnect |
SIPSettings |
COMPANYNAME |
this will apear in the sip signaling |
SipSettings |
def_max_sessiontimer |
sip session-timer config |
SipSettings |
def_mid_sessiontimer |
sip session-timer config |
SipSettings |
def_min_sessiontimer |
sip session-timer config |
SipSettings |
domainnames |
registrar domainnames (used for inter-domain rerouting) |
SipSettings |
eventlist |
refer |
SipSettings |
forwardretrytimer |
ivr forward retry interval |
SipSettings |
fwdtootherdomains |
0=no |
SIPSettings |
fwdunknownheaders |
forward unknown sip headers |
SIPSettings |
HasInternalAccess |
accept from 192.168... or 10.0.... |
SIPSettings |
identityrwmode |
0=no rewrite |
SIPSettings |
IDLETIMEOUT |
used for various session timers |
SIPSettings |
im_billinguserid |
used for instant messaging |
SIPSettings |
im_parentid |
used for instant messaging |
SIPSettings |
lastlocalsdpport |
used in terminals |
SIPSettings |
loadcallednumberfromto |
load the called number from sip to instead from the sip first line (URI) |
SIPSettings |
localclientport |
useful for 2 port configurations |
SIPSettings |
LocalDomain |
sipserver domainname |
SIPSettings |
localinternaldomain |
sipserver internal domainname |
SIPSettings |
LocalPort |
sipserver listen port |
SipSettings |
logsipmsgexchange |
store the sip message headers in the cdr comment |
SIPSettings |
MAINTIMERIVAL |
sip background process timer. used for garbage collections mainly |
SIPSettings |
MAXEPCOUNTTRESHOLD |
maximum number of registered endpoint (it may be limited by license too) |
SIPSettings |
MAXH323GKCDRCACHE |
this must at least the maximum h323-h323 simultaneous call number |
SIPSettings |
maxreroute |
max number rute retry |
SipSettings |
MaxRTP |
rtp port range begin for sip |
SIPSettings |
MAXSPEACHLEN |
max allowed call duration in sec |
SipSettings |
maxstatchangepermin |
max allowed enduser status changes/60 sec (slower if exceed) |
SIPSettings |
MAXSUBSMSGCOUNT |
max subsequent messages before block |
SIPSettings |
MAXSUBSMSGPERIOD |
max subsequent messages before block are checked for this interval (sec) |
SIPSettings |
MAXWRONGMSGALLOWED |
dos attack protection |
SIPSettings |
MEDIATIMEOUT |
will disconnect if the media disappears |
SIPSettings |
MEDIATIMEOUTSTART |
will disconnect if no media detected |
SIPSettings |
MINRESENDIVAL |
sip udp resend timer (T1) in msec |
SipSettings |
MinRTP |
rtp port range begin for sip |
SIPSettings |
MINSPEACHLENONROUTE |
minimum remained speechlength for the caller when the router will still route the call |
SIPSettings |
MINUSERCREDITONROUTE |
minimum credit for the caller when the router will still route the call |
SIPSettings |
MINUSERNAMELEN |
minimum accepted username length |
SIPSettings |
PRODUCTNAME |
the name of the product. this will apear in the sip signaling |
SipSettings |
propersipcomments |
set to true if you want personalized sip headers |
SIPSettings |
REBUILDREGCLIENTS |
usually the same as maxspeachlen |
SIPSettings |
REENABLEDOSBLOCKED |
reenable blocked endpoints after this interval. defaults to 12 hour |
SIPSettings |
REGISTERIVAL |
upper registration interval in msec. defaults to 40 min |
SIPSettings |
RELOADPROXYLISTIVAL |
reload proxies from the config |
SIPSettings |
REPOPUPULATEFDSETIVAL |
used for rtp routing |
SipSettings |
REPOPUPULATEFDSETIVAL_MAIN |
used for main routing |
SIPSettings |
rerouteon |
rerouting behaviour: 0=disabled 1=onlyifset (on busy |
SipSettings |
resolvedns |
resolve uri domain names |
SipSettings |
ringtimeout |
sip calls ring timeout |
SIPSettings |
routepresence |
route subscribes |
SipSettings |
rtpsendonlytorec |
send the rtp only to the rec address |
SipSettings |
rtpwritefirst |
send a rtp packet after connect (to open NAT) |
SipSettings |
sdpalthandling |
0=not handled |
SipSettings |
sessiontimer |
0: don’t use |
SipSettings |
sipmsgresendcount |
resend sip message count |
SipSettings |
sipmsgresendival |
sip message resend timer |
SipSettings |
sipsendtodefport |
try to send to port 5060 too |
SipSettings |
statussaveival |
minutes. used when predective is active |
SipSettings |
supportlist |
privacy |
SIPSettings |
traceep1 |
user id |
SIPSettings |
traceep2 |
user id |
SipSettings |
udpkeepalive |
send keepalive messages |
SIPSettings |
udppriority |
rtp thread priority: 1=normal |
SipSettings |
upperexpire |
register expire |
SIPSettings |
usedateheader |
send date to user agents |
SIPSettings |
userofflinemin |
enduser will be considered offline if no register or invite for this period |
supervisor |
canrestartformalfunctions |
if supervisor can do restarts. 0 |
supervisor |
checkcallerids |
check only this cdr records |
supervisor |
checkprefixes |
check only this cdr records |
supervisor |
maxnocdrmin |
restart if no cdr records |
supervisor |
minacd |
min treshold |
supervisor |
minacl |
min treshold |
supervisor |
minasr |
min treshold |
supervisor |
peaktimeendtr |
peaktime end hour |
supervisor |
restartatnight |
if to restart at every night |
supervisor |
restartpcatfirst |
don't restrart the service. restart the pc immediatly |
supervisor |
trafficammount |
0=after setup |
supervisor |
weekendispeak |
treat weekend as peaktime (same traffic ammount) |
Other config options:
Show/hide child’s and spouse from accept action:
„showspouoseandchild:
0=don’t show,1=show only spouose, 2=only child, 3 = show both of them.
default value is: 3
From this form, direct SQL queries can be done against the Mizu backend. Use it carefully!
With this utility, the conversations on Mizu gateways can be listened in real-time.
H323 test calls can be done here.
Upload/download files from gateways.
Use this form to login directly in gateways and on the server.
Database administration tool. Only for database experts!
Direct link to the Costumers website if you have any.
Numbers allocated by authorities. You may add new endusers with telnumbers set to a free number from this database. Don’t forgot to set the “free” field to 0 if the number is allocated to an enduser.
The web interface will get free numbers for newly registered users from this database too.
You can define tasks for technical support with the ease of this form.
Any quick note here to be shared between the support and admin users.
Mizu server can treat holidays as weekend in routing and billing if the “autoholiday” global config is set to “1”.
If the autoholiday is set to 0, than you can configure the holiday routing and billing manually (by selecting the “holiday” pattern from the time pattern list)
In the “Holidays” Form you can set the holidays.
The isholiday value can have the following values:
1: the time period is considered as holiday
0: the time period is considered as workday (even if is weekend)
Then you must set the time interval (fromdate-todate).
Prefixlist can contain ‘*’ or 2,3 or 4 digit prefixes separated by comma.
If the prefix list is empty or it contains ‘*’ than will be applied to for all directions.
Allocated and used phone numbers can be tracked on the “Phone Numbers” form.
Numbers allocated to users or sipproxyes must be marked (set “free” to 0)
The location can contain the id of the user where the number belongs. This is very important for sip proxy users where the number is not stored as the record username or number (usually for virtual servers). If set so, the server will know where to route the incoming call. Otherwise the routing must be configured in the MManage.
With the scheduled tasks form you can define tasks that will be executed by the server at regular time intervals. Two type of task is allowed: launching as program or running an SQL command.
Depending on completition the server can initiate the following actions:
o Send Email
o Send SMS
o Ring a phone number
o Restart the VoIP service
o Restart the SQL service
o Reboot the server
For SQL the condition will be success if the first field value is a positive number (first row/first col). Otherwise (no record, null record, non number, zero or negative number) the result will be treated as “fail”.
The following keyword can be used with the email and sms actions:
· SQLRESULT: will be replace with the sql query result set (all rows and columns)
· {FIELD}: any field returned by the query (replace the FIELD with a valid returned field from your query)
· {SQL}: any SQL result (replace the SQL with a select statement like {SELECT TOP 10 * from tb_cdrs})
· USERID: it can be used in the above SQL to be replaced with tb_users.id if the query was against tb_users
·