Mizu Softswitch Administrator’s Guide

VoIP Server documentation


Mizu Server is a software soft switch solution running on Microsoft Windows platforms that can replace traditional hardware based PBX and ISDN solutions.









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 with the documented version!



1. Introduction. 11

1.1. Short description. 11

1.2. Features. 12

1.2.1. Hosting. 13

1.2.2. SIP. 13

1.2.3. Codecs. 15

1.2.4. IP Centrex. 16

1.2.5. Call Center 17

1.2.6. Accounting. 17

1.2.7. Routing. 18

1.2.8. Billing. 19

1.2.9. Calling Card. 20

1.2.10. H323. 20

1.2.11. VoIP-GSM.. 21

1.2.12. Management 23

1.2.13. Limitations. 25

1.2.14. Known issues. 25

1.3. Contact and tech support 25

2. Modules. 25

2.1.1. SIP Stack. 26

2.1.2. H323 Stack. 26

2.1.3. SIP-H323 converter 26

2.1.4. Media Server 26

2.1.5. Routing. 26

2.1.6. Billing. 26

2.1.7. Alerting and Daily report 26

2.1.8. Virtual Servers. 26

2.1.9. Call Center 27

2.1.10. Watchdog service. 27

2.1.11. HTTP service. 27

2.1.12. Direct command interface. 27

2.1.13. Enduser web portal 27

2.1.14. Selfcheck and reporting. 27

2.1.15. VoIP-GSM Gateway. 27

2.1.16. Other components. 28

3. Maintenance Tasks. 30

3.1. Server configuration checklist 30

3.2. Gateway quick setup. 30

3.3. Daily Maintenance. 32

3.4. Monthly Maintenance. 32

3.5. Server backup, recovery and maintenance. 33

3.5.1. Database backup. 33

3.5.2. Using Backup database tables. 33

3.5.3. Database maintanance. 34

3.5.4. Saving recorded voice. 34

3.5.5. Alternative backup deletion. 35

3.5.6. Disaster recovery. 35

4. Administration. 36

4.1. MManage. 36

4.1.1. Overview.. 36

4.1.2. MManage Installation. 36

4.1.3. MManage Framework. 37

4.1.4. Import-Export Wizard. 40

4.2. Monitoring. 40

4.2.1. Current Calls. 41

4.2.2. GSM Channels. 42

4.2.3. Basic Statistics. 47

4.2.4. Advanced Statistics. 49

4.2.5. Disc. Reasons. 51

4.2.6. Line Monitor 52

4.2.7. Capacity Check. 52

4.2.8. System Load. 52

4.2.9. Server Console. 52

4.2.10. Server Monitor 53

4.2.11. Logs. 53

4.1.12. Analyze. 54

4.1.13. CDR Records. 54

4.3.14. Balance. 56

4.3.15. Callcenter Statistics. 57

4.3. Access. 57

4.3.1. Users. 57

4.3.2. Devices. 69

4.3.3. Groups. 69

4.3.4. User authorization. 70

4.4. Routing. 74

4.4.1. Firewall 74

4.4.2. Dial Plans. 74

4.4.3. Prefix Rules. 76

4.4.4. Blacklisted. 76

4.4.5. Access Lists. 77

4.4.6. Routing. 77

4.4.7. Routing workflow.. 80

4.4.8. RADIUS. 84

4.4.9. BRS. 84

4.4.10. Failovering. 86

4.4.11. SIM Channel reservation by caller protocol 87

4.4.12. Number portability database. 88

4.5. Billing. 89

4.5.1. Price Settings. 89

4.5.2. Price List 93

4.5.3. Billing. 93

4.5.4. Currency Conversion. 96

4.5.5. Finances. 97

4.5.6. Pin codes. 97

4.5.7. The billing process. 97

4.5.8. Invoice and payment storage. 99

4.5.9. Enviroment variables. 101

4.5.10. Payments. 101

4.5.11. Notes. 105

4.6. GSM/SIM Platform.. 106

4.6.1. SIM Packets. 106

4.6.2. Gateways. 108

4.6.3. Engines. 108

4.6.4. SIMCards. 108

4.6.5. Credits. 109

4.6.6. SIM Distribution. 109

4.6.7. SIM Utilization. 110

4.6.8. New Simcard. 110

4.6.9. New Charge Card. 110

4.6.10. SIM Bank. 111

4.7. Other -MManage. 112

4.7.1. Configurations. 112

4.7.2. Direct Query. 127

4.7.3. Voice Here. 127

4.7.4. Test Call 128

4.7.5. Rfile system.. 128

4.7.6. Rdesktop. 128

4.7.7. DB Admin. 128

4.7.8. Web Admin. 129

4.7.9. Phone Numbers. 129

4.7.10. To-do. 129

4.7.11. Notes. 129

4.7.12. Holidays. 129

4.7.13. Allocating numbers. 129

4.8. Gateway Configuration. 130

4.8.1. Phone Settings. 130

4.8.2. Gateway Basic Settings. 131

4.8.3. Gateway Advanced Settings. 132

4.8.4. Watchdog settings. 139

4.8.5. Other settings. 139

4.8.6. Handling incoming calls from GSM network. 140

4.8.7. Operator friendly gsm termination. 141

4.8.8. How to setup a gateway behind a NAT*. 143

4.9. Call Center 143

4.9.1. Users. 143

4.9.2. Campaigns. 144

4.9.3. Scripts. 144

4.9.4. GUI Designer 149

4.9.5. Quotas. 151

4.9.6. Presentations. 152

4.9.7. Checklist 152

4.9.8. Clients. 152

4.9.9. Campaign Clients. 154

4.9.10. Campaign and global settings. 155

4.9.11. Predective dialer 157

4.9.12. Outgoing callback. 158

4.9.13. Incoming calls. 159

4.9.14. Keywords. 161

4.10. MAgent 163

4.10.1. Login. 163

4.10.2. Manual Call 165

4.10.3. Calls from database. 165

4.10.4. Automatic calls. 165

4.10.5. Automatic software upgrades. 165

4.11. IPCentrex. 166

4.11.1. Call Rerouting. 166

4.11.2. Ring Groups. 166

4.11.3. Caller ID.. 166

4.11.4. DTMF. 167

4.11.5. Call Hold. 167

4.11.6. Call Forward. 167

4.11.7. Call Transfer 168

4.11.8. Three-Way Calling. 169

4.11.9. Call Waiting and queuing. 169

4.11.10. Call Take-Over 169

4.11.11. Conference Calls. 169

4.11.12. Voice Mail 170

4.11.13. Voice Recording. 170

4.11.14. IVR.. 170

4.11.15. CallBack number 173

4.11.16. CallBack services. 173

4.11.17. Calling Card services. 175

4.11.18. Phone to Phone (P2P) calls. 176

4.11.19. SMS. 176

4.11.20. SMS callback. 177

4.11.20. Web (account access) 179

4.11.21. Virtual Servers. 179

4.12. SIM-Bank. 180

4.12.1. Introduction. 180

4.12.2. Configuration. 180

4.12.3. Technical Details. 182

5. FAQ.. 183

5.1. How to make a H323 call directly to a GW (without the gatekeeper) 183

5.2. Sometimes the voice channel is breaking down. How can I improve the voice quality?. 183

5.3. Using Netmeeting. 183

5.4. How can I make test calls?. 183

5.5. How to check the call quality on a specific channel?. 183

5.6. Typical Cisco Config. 184

5.7. Server Recovery (in a separate app and db server configuration) 184

5.8. No incoming calls (no new calls in current call list in peak time) 184

5.9. Calls in „routing” status. 185

5.10. SIP caller cannot call 185

5.11. SIP called cannot be called. 185

5.12. No call on Gateway. 185

5.13. No call on SIM.. 185

5.14. No voice (caller and called cannot hear each-other) 186

5.15. Too many wrong calls on a simpacket (low ASR/ACL) 186

5.16. Not enough or too many calls on a sim or simpacket 186

5.17. Calls are routed to wrong simcards. 186

5.18. Too low ASR.. 186

5.19. Too low ACL. 186

5.20. SIM cards with low credit 186

5.21. GSM Gateway not working. 187

5.22. GSM Gateway malfunctions. 187

5.23. Wrong disconnect reasons. 187

5.24. MManage cannot connect to the server 188

5.25. Too slow MManage. 188

5.26. Server software problem (service unavailable) 188

5.27. Server OS, Database or Hardware problem (server unavailable) 188

5.28. How to restart  the server service. 188

5.29. How to restart  the server box. 188

5.30. How to restart  a GSM gateway. 189

5.31. How are the incoming calls from the gsm network handled?. 189

5.32. Routing test calls to a dedicated gateway. 189

5.33. How to disable PIN request on GSM gateways. 189

5.34. What are the minimal global settings that must be correct on servers?. 190

5.35. How to add a new traffic sender?. 190

5.36. How to add a new sip enduser?. 190

5.37. How to add a new Mizu VoIP-GSM gateway to the server?. 190

5.38. How to add new simcards (sim packet)?. 190

5.39. How to add a new simcard?. 190

5.40. How to set up basic routing?. 191

5.41. How to set up basic billing?. 191

5.42. Where can I check the logs and traces?. 191

5.43. The conversation volume is too loud. How can I change the volume?. 191

5.44. How to register your Mizu Gateway to a H323 gatekeeper?. 191

5.45. What ports are used in the system?. 191

5.46. My gateway restarts too often. 192

5.47. H323 signaling problems. 192

5.48. How to set up the automatic credit recharge?. 192

5.49. The automatic credit recharge is not working. 192

5.50. How to monitor the credit automation?. 193

5.51. Gateway and channels are inactive. 193

5.52. How calls are processed. 193

5.53. How to set up holiday billing. 194

5.54. How to treat specific weekends as weekdays. 194

5.55. How the different currencies are handled?. 194

5.56. SimChange settings from the command line. 194

5.57. How to reenable blacklisted but good numbers. 195

5.58. How are different currencies handled?. 195

5.59. How is VAT handled?. 195

5.60. How the check your ASR (or ACD, SL, CDRC) for the traffic sender “A” in the last week. 196

5.61. How to add endusers (basic settings) 196

5.62. Basic callcenter tasks. 197

5.63. Abbreviations. 197

5.64. Codecs. 199

5.65. How to reserve GSM capacity for a certain protocoll 199

5.66. PDF creation in MManage. 199

5.67. How to setup a new virtual server instance. 200

5.68. Fax detection. 201

5.68. Handling dynamic & private ip/port 201

5.69. Fax settings. 201

5.70. License limitations. 202

5.71. Redirect or forward sessions to other domains. 203

5.72. Delete old database backup. 204

5.73. Sales commissions. 204

5.74. Multihomed setup. 205

5.75. How to scan your SP for live numbers. 205

5.76. Routing calls from virtual servers. 206

5.77. Routing calls to virtual servers. 206

5.78. How to add plugins in MManage. 206

5.79. Request/response target address. 207

5.80. Server supervisor 208

5.81. Automatic prepaid credit expirity. 209

5.82. Simple prefix rewrite. 209

5.83. Short number and internal billing. 210

5.84. Cropping sound on ring when playing voice (ringtone, announcement or any other promt 210

5.85. How to play user credit in IVR.. 210

5.86. Encryption. 210

5.87. Running Mizu Server in proxy mode. 212

5.88. Mizu Server security. 213

5.89. Ringtone for IVR forwarded calls. 214

5.90.        CLI settings / A and B numbers / Dial plan. 214

5.91. Possibile NATs and firewalls. 216

5.92. How to disable CLI for all outgoing calls. 217

5.93. How to change the database username/password. 217

5.94. Performance optimizations. 218

5.95. How to reset a failowered gateway/direction. 218

5.96. How to remove the 3 digit techprefix system wide setting. 218

5.97. How to enable H.323 modules?. 219

5.98. How to add an SMS provider?. 219




MizuServer v4.1 Administrator’s Guide

Revisited Febr 4, 2010

You will notice smal changes if you program version doesn’t conform with the documented version!



Mizu server and other MizuVoIP software is  copyrighted by MizuTech SRL. -Copyright ©2006-2010 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

You must accept the license agreement (LicenseAgreement) before you use any Mizu hardware or software component!


Trademark Acknowledgement

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.

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)

1. Introduction



This document describes the administration of Mizu Gateways, SoftSwitches, CallCenters and SimBanks. A unique set of proprietary software and hardware based capabilities and processes in VoIP network 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/ISDN/GSM platform, capable to handle millions of minutes/months.

1.2. Features

1.2.1. Hosting

Ø  MS-SQL backend (Express or Full versions)

Ø  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


1.2.2. SIP

Ø  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


Ø  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 Reinvites

Ø  SIP-H.323 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

1.2.3. Codecs

Ø  G.723.1

Ø  G.729

Ø  G.711 A-law

Ø  G.711 u-law

Ø  GSM 06.10


Ø  Speex 2,3,4,5,6 (narrowband, wideband and ultrawideband)

Ø  G.726 (16,24,32,40 KHz)

Ø  G.722

Ø  T.38


Ø  Custom 1 kbits codec

Ø  All other codecs 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


1.2.4. IP Centrex

Ø  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

1.2.5. Call Center

Ø  Automatic Call Distribution: like simple automatic dialing, power dialing, predictive dialing, predictive intelligent dialing


Ø  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

1.2.6. Accounting

Ø  ACD Features

Ø  Unlimited accounts / Unlimited Extensions

Ø  Automatic pincode generation

Ø  Flexibile authentication (digest,IP,port,user,etc)

1.2.7. Routing

Ø  Custom Routing Rules

Ø  Multi-Carrier Support


Ø  Sophisticated configurations

Ø  Load Balancing on available devices

Ø  Rerouting

Ø  Number rewriting (calling and called)

Ø  Failovering (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, callernumber

Ø  GeoIP database

Ø  Automatic SIM allocation:

Sim allocation rules:

Rules can be defined on multiple levels: global, partner, gateway, engine, simpacket, simcard, time


    -will not modify gw settings


    -sl (day/month)

    -packet allowed intervals

    -min/max lines for partner


    -sim partnerm, sim, gw


    -desired minute on packet

    -packet multiplier


    -“minrotateival”, “desired”, “maxrotateival”


    -min/max pricediff on obj, maxpricepermin for system/partner




 -and many other options

1.2.8. Billing

Ø  Flexible Rate Definition (peak/offpeak/flat/custom,  enduser/provider/reseller/sales, etc)

Ø  Automatic and Real Time billing (CDR records 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)

Ø  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

1.2.9. Calling Card

Ø  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


1.2.10. H323

Ø  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)

1.2.11. VoIP-GSM

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 newtworks.


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 failovering 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



Ø  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


1.2.12. Management

Ø  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

Ø  Realtime 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

Ø  Failovering (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


1.2.13. Limitations

Ø  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.

1.2.14. Known issues

Some class 5 features  will work only with SIP protocoll

H323 GK doesn’t support username/password authentication

RADIUS is compatibile only with some servers

1.3. Contact and tech support

Full remote administration supported.

Continous email support.

24/7 emergency phone support.

Visit http://www.mizu-voip.com for more details.

2. Modules

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. Small companies can use “all in one” solutions, where the gateway and the server are placed in the same box. Large organizations will divide the server in multiple units, adding more power and fault tolerance. Up to 6 gateways the server can be used with the built-in database engine. With more gateways or users it is strongly recommended to use one or more separate database servers (MS-SQL or ORACLE). The soft switch is built from several modules: sip stack, h323 stack, sip – h323 conversion module, media server, ACL, routing, billing, alerting.

2.1.1. SIP Stack

The Mizu SIP stack was written in C++. It’s very fast and robust, currently used by voip service providers handling thousands of users.

2.1.2. H323 Stack

Capable to work as a simple Gateway or as a fully featured Gatekeeper.

2.1.3. SIP-H323 converter

Thank to this module, the protocol conversion is very transparent. You don’t even need to know if your partners use SIP or H323.

2.1.4. Media Server

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.

2.1.5. Routing

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.

2.1.6. Billing

The server will generate the detailed CDR records 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.

2.1.7. Alerting and Daily report

The server can send various reports and alerts based on predefined rules. The reports are sent by email or SMS.

2.1.8. Virtual Servers

You can create up to 100 virtual server on a single pc. These are completly separate billing/routing/signaling entitites.

2.1.9. Call Center

Manage operators, automatic call distribution, IVR and other callcenter specific tasks.

2.1.10. Watchdog service

This NT service can automatically detect critical service problems and restart the VoIP server, the SQL database or the OS.


2.1.11. HTTP service

The built-in HTTP server will listen for service requests.


2.1.12. Direct command interface

Administrative tasks and class5 service requests can be handled by the command line TCP interface.


2.1.13. Enduser web portal

Template portal is available with source code. All common enduser tasks can be done via a user friendly web interface (new user registration, download CDR records, show statistics, setup call forwarding, payment, etc)


2.1.14. Selfcheck and reporting

Various system tersholds will checked reltime 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.




2.1.15. VoIP-GSM Gateway

Mizu VoIP-GSM Gateways support 8 concurrent calls and up to 64 simcards. 

See the features section for more details.


All standard GSM capabilities are supported.


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 route 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.

2.1.16. Other components

server service: the brain of the system

H323 GK: standard H323 gatekeeper

SIP Server: sip stack

Media Server: rtp routing

VGW: voip-gsm gateway, the most essential part of the client

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



Simple monitoring software fot business purposes. Each partners (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 they 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 superuser. 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.


3. Maintenance Tasks

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 features. However if you have millions of minutes/month, you may have to watch the system parameters every day.

3.1. Server configuration checklist

3.1.1. Softwares

Windows 2003/2008 server, MSSQL 2000,2005 or 2008

3.1.2. Firewall

-allow servers, FTP, IIS, MSSQL, SMTP, remote destop (3386,3389)

-block: all others, file sharing, ms network

3.1.3. Services and memory

Autorestart critical services

For more than 3 Gb set boot.ini: /3GB /PAE

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

Disable pipes

Check configuration in Management Client



3.2. Gateway quick setup

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 ore 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.

3.3. Daily Maintenance

You should check at least the followings every day:

            -Current Calls –to quickly check if you have the required amount of traffic

            -GSM Channels (channels with problems are marked with red)

            -Quality Statistics by traffic senders and terminating gateways

            -Run a global system analysis (“Analyze” form)

3.4. Monthly Maintenance

-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 “Advanced Statistics” form

-Remove blacklisted but good numbers


3.5. Server backup, recovery and maintenance

3.5.1. Database backup

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 configuratuions:

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 neccesarry when the database is located on a separate box. Othervise can be left empty –default to dbmaint_backupdbdir)

3.5.2. Using Backup database tables

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” (meassured 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 “untill” 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.

3.5.3. Database maintanance

The server will optimize the database engine automatically.

dbmaint_do: enable/disable the daily and the monthly maintanance

dbmaint_removelogs: Trunk log tables and remove logfiles after x days



3.5.4. Saving recorded voice

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.



3.5.5. Alternative backup deletion


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.


3.5.6. Disaster recovery

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

4. Administration

4.1. MManage

4.1.1. Overview

Although the server and the gateway are PC based, you will newer have to login to the PC. All administration tasks are done from MManage.


4.1.2. MManage Installation

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/2003/2008

-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 –tha 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)

-Utilty programs: tariffcalc.exe, smtptest.exe, rptest.exe etc

-Required dll files

-Help files


-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: databse 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 comunication  (requires the “vsqlrouter” service to run)



4.1.3. MManage Framework



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 Tools Menu you can find a set of helper applications explained later in this document.

 In the Settings Menu  the most important form is the “Select Direction” 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 (still from the Tools Menu), 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 ar 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)

4.1.4. Import-Export Wizard

With the ease of the inport –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:















Other datasources wich can be accessed by ADO or ODBC.

4.2. Monitoring


4.2.1. Current Calls

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


4.2.2. GSM Channels

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


4.2.3. Basic Statistics

Shows the main quality parameters of your system.



CDRC: call attempt count

SL: speech length (duration in minutes)

ASR: average success ration (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 Provider Direction: statistics by called number prefix (first 4 digits)


4.2.4. Advanced Statistics

This is an extended version of Basic Statistics. You can find more grouping options here.



Additional reports:

-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

-PF: profit. This require your billing module to be properly configured

-SUCC: successful call count (same as ASR but not in percent)

-CCC: concurrent (simultaneous) call count

-RTP: media channel statistics


You can make the grouping by minute in this form by checking the “on minute” box.


The following “grouopby” 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: comapare 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


4.2.5. Disc. Reasons

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 se 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.

4.2.6. Line Monitor

This is a simple listing of your channels. You can discover all simcard problems by scrolling down this list. (Missing channels are highlighted)

4.2.7. Capacity Check

This module tests the capacity for the predefined direction in priority order.

4.2.8. System Load

Shows system utilization statistics.

4.2.9. Server Console

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)

4.2.10. Server Monitor

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)

4.2.11. Logs

Here you can see the log records for the server and every connected Mizu Gateways in the selected time preiod. You can restrict the listing by defining the source, severity or filtering.

4.1.12. Analyze

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.


4.1.13. CDR Records

After every call (and SMS, etc), a new CDR is stored in the database tb_cdrs table (and in tb_cdrresellers when the reseller option is used).

CDR records can be filtered, analiyzed, exported and lots of vital statistics are based on this records.

CDR records 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 (seconf calleg from ivr after callforward)

Comment: with details about the call setup and disconnect. Can contain a shortened message exchange log.



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!

4.3.14. Balance

Duration lists of several traffic types.

4.3.15. Callcenter Statistics

Statistics related to callcenter operations: Campaign and operator  statistics.

StartTime: operator first login in TAgent in the current day

EndTime: operator last seen time in the current day

WorkTime: time when TAgent 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: Tagent 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.

4.3. Access

4.3.1. Users


This form will allow to manage the users of the system (Endusers, SÍP users, Administrators, Tech. Support users)


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


-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



ID: database id. Auto increment

Type: user type

0=enduser (usually a sip user). Operator if isoperator set to 1, power user if set to 2, calling card when set to 6, enduser if 0

1=reseller company (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=gsmgw,  (parentid is the gatewayowner)

9=sipproxy,  (parentid is the gatewayowner)

10=h323gw,  (parentid is the gatewayowner)

11=isdngw, (parentid is the gatewayowner)

12=sms, fax,email gateway

14=support (can operate with MManage, has ftp account)

15=admin (can see and modify everything)


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


    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.


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 userid 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 an 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

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 in authentification.

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


            -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


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

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


Allowed traffic senders for the gateway, or allowed gateways for traffic senders.

A list of user id searated 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  –this is the preferred settings

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

Rtp settings will be checked first for the called and then the caller (so if the  caller RouteRtpCaller settings is not 0, then it will overwrite the called RouteRtpCalled settings)

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


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 bee 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


Contact Status:


1-Not applicable

2-In Progress



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 fielss 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: specif if the user is a callcenter operator (1) or a normal enduser (0)  or power user (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 keepalive.

-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=

GsmGw NOGW: used when no route found. IP=, isfake=1,realgw=0

GsmGw FBACKUPGW: used to handle traffic exceed. IP=, callsigaddr=1725,isfake=1,realgw=0

SipProxy: sip2h323: convert signaling form h323 to sip and from sip to h323. TechPrefix=-1,IP:, Port?

TrafficSender: virtserver X: for routing traffic from virtual servers. AuthIPList:, TechPrefix=XXX

Enduser: PREDECTIVE_DIALER:  IP:,  TechPrefix?, username=cc_callbacknumber


The following fileds has direct impact to routing:























4.3.2. Devices

Administarton 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 sipproxy 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


4.3.3. Groups

Grouping of several items will ease the administrations tasks. The following type of items can be grouped:

SIM Packets



Traffic Senders


4.3.4. Ownership

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.


4.3.5. User authorization



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 attacher), 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 enduser 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 ip authmust 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. (which 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.



 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, othervise will be authenticated as traffic sender. In this case you can require a PIN number from the user.


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)

enableanumberlookup per user configuration. You need to set it to 1 for traffic senders.


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=calling card username or any user username + password or username + pin (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


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 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.


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 fielss 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


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.






4.4. Routing

4.4.1. Firewall

The firewall rules are checked first when a call are initiated (SETUP or INVITE received), so this is the most effective way to block some unwanted traffic sender.

All ip address are allowed except those are listed if the ip with ‘*’ is 1.

Otherwise (if the ip ‘*’ is set to 0) all address are blocked except  those that are listed here.

4.4.2. Dial Plans

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*/


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 know at this stage.


Usualy only the called number have to be rewritten, but you can also change other values.

Accepted output values:

  -emty string: no effect

  -_REJECT: will disconnect the call

  -callednumber: will change the called number



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



    DECLARE @ret_callernumber varchar(35)

       DECLARE @ret_callednumber varchar(35)


       SET @ret_callernumber = @callernumber

       SET @ret_callednumber = @normcallednumber