About

This document provides an overall technical description of Mizu VoIP platform. For non technical user guides please check out our website. Your installation may not include all modules described in this document and you will notice small changes if you program version doesn’t conform to the documented version!

Version

MizuServer v.9.6 Administrator’s Guide

Revisited May 18, 2022

Copyright

This document may not be copied or readdressed in whole or part without the expressed, written consent from MizuTech SRL.

Disclaimer: MizuTech SRL reserves the right to change any information found in this document without any written notice to the user.

License Agreement and Trademark Acknowledgement

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

Some of the extra modules are licensed by separate license terms. (These modules are included in unmodified binary format and integrated with the Softswitch via their API)

LINUX is a registered trademark of Linus Torvalds in the United States and other countries.

Windows and Microsoft SQL Server is a trademark of Microsoft Corporation, registered in the United States and other countries.

Oracle is a registered trademark of Oracle Corporation.

OpenSSL are licensed under OpenSSL license: https://www.openssl.org/source/license.txt

Freeswitch licensed under the MPL 1.1.

OpenSSL are licensed under OpenSSL license: https://www.openssl.org/source/license.txt

Freeswitch licensed under the MPL 1.1: https://wiki.freeswitch.org/wiki/Licensing

OpenH323 (used in test tools) are licensed under MPL: http://www.mozilla.org/MPL/MPL-1.0.html. Source code is included on the install CD.

Other logos, products, brand names and service names contained in this document are the property of their respective owners (trademarks or registered trademarks of their respective companies)

Introduction

This document describes the administration of Mizu Gateways, SoftSwitches and CallCenters. A unique set of proprietary software and hardware based capabilities and processes to build up a VoIP network, including planning and network management.

These components are designed to cover the telecommunication needs for small to very large companies and VoIP carriers. The main power of the system is the sophisticated VoIP components, which are strongly used in today’s telecommunication infrastructures.

The Mizu components can be used as standalone or as centralized intelligent VoIP platform, capable to handle millions of minutes/month.

1.2. Features

1.2.1. Hosting

Ø MS-SQL backend (Express or Full versions) or embedded database

Ø Ethernet 10/100/1000 Base-T

Ø Static IP, PPPoE (DSL or cable modem), DialUpISDN,VPN

Ø Encrypted communications

Ø Virtual servers

Ø STUN/ICE Support

Ø NAT Support

Ø Near-End and Far-End NAT traversal

Ø Multi-homed and multi-domain support

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

Ø CLIP/CLIR

Ø DTMF generation

Ø Call-Forward on out-of-service

Ø Codec transcoding

Ø Advanced statistics support

Ø NAT traversal of signaling

Ø NAT traversal of media

Ø SIP Session timers

Ø RTP Timers and media timeout

Ø Blind SIP Registration

Ø Late Codec Negotiation

Ø Multiple SIP registrations per user account

Ø Can act as an SBC

Ø Max Session Setting

Ø Manage Presence

Ø Detailed call logs

Ø SIP/SIMPLE

Ø SIP Reinvites

Ø SIP-H.323 protocol conversion

Ø WebRTC-SIP protocol conversion

Ø Class 4 features

Ø Class 5 features

Ø RFC 2543 compatibility

Ø RFC 3261 compatibility

Ø RFC 2976 The SIP INFO Method

Ø RFC 3262 Reliability of Provisional Responses in Session Initiation

Ø RFC 2617 HTTP Authentication

Ø RFC 3263 Locating SIP Servers

Ø RFC 3265 Specific Event Notification

Ø RFC 3420 Internet Media Type message/sipfrag

Ø RFC 3515 Refer Method

Ø RFC 3311 UPDATE Method

Ø RFC 3581 Symmetric Response Routing

Ø RFC 3842 Message Summary and Message Waiting Indication Event Package

Ø RFC 3891 "Replaces" Header

Ø RFC 3325 Private Extensions to the Session Initiation

Ø RFC 2778 A Model for Presence and Instant Messaging

Ø RFC 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging

Ø RFC 1889 RTP: A Transport for Real-Time Applications

Ø RFC 2190 RTP Payload Format for H.263 Video Streams -only routing

Ø RFC 2327 SDP: Session Description Protocol

Ø RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

Ø RFC 3264 An Offer/Answer Model with Session Description Protocol

Ø RFC 3550 RTP: A Transport Protocol for Real-Time Applications -replaces RFC 1889

Ø RFC 3555 MIME Type Registration of RTP Payload Formats

Ø RFC 3911 The SIP "Join" Header

Ø RFC 3324 Network Asserted Identity

Ø RFC 3326 The Reason Header Field

Ø RFC 3581 Symmetric Response Routing

Ø draft-ietf-mmusic-ice-02 A Methodology for NAT Traversal for Multimedia Session Establishment Protocols

Ø draft-ietf-avt-rtp-ilbc-04

Ø draft-ietf-sipping-cc-transfer Call Control - Transfer

Ø draft-ietf-sip-referredby-05

Ø Custom protocol extensions are possible

1.2.3. Codecs

Ø G.723.1

Ø G.729

Ø G.711 A-law

Ø G.711 u-law

Ø GSM 06.10

Ø GSM

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

Ø Opus

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

Ø G.722

Ø T.38

Ø DTMF

Ø Custom 1 kbits codec

Ø All other codec’s for pass-trough

Ø Voice:

· Adaptive de-jitter buffer

· Voice Activity Detection/Silence Suppression

· Recording conversations (In Stereo caller/callee left/right)

· QoS

· Packet saver technology

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

Ø IVR

Ø Call Recoding: All calls can be recorded and stored

Ø Real time call check out: Supervisors can listen to the ongoing calls real time

Ø PBX Features: Call hold, call wait, call transfer, call forward (conditional and unconditional), call conference, CLIP, CLIR

Ø Customizable Scripts: script tree, with any number of branches, answers, and reason codes.

Ø Customizable IVR: Any number of language, any number of branches, voice and faxmail, call transfer to the operators

Ø Statistic generation: customer statistics, operator statistics, call related statistics, work time statistics, campaign statistics

Ø Campaign creation: supervisors can create a campaigns

Ø Invitation letter: customization, and automatic printing

Ø Report generation: Specific hourly, daily and weekly reports

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

Ø ACL

Ø Sophisticated configurations

Ø Load Balancing on available devices

Ø Rerouting

Ø Number rewriting (calling and called)

Ø Failowering (multiple levels)

Ø Least Cost Routing

Ø BRS -quality based routing

Ø Call Control Features (Maximum Talk Time, Max Ring Time)

Ø Call routing based on PLMN tariff packages

Ø Blacklist/White list filtering

Ø Time of Day Routing

Ø Direct Inward Dialing (DID)

Ø Route capacity

Ø Outbound Dial Map

Ø Speed Dial Numbers

Ø Auto call forwarding

Ø ANI Routing

Ø IP Blacklists

Ø Custom VoIP Providers

Ø Fraud detection tools

Ø Support for NAT traversal

Ø Automatic capacity rebalancing
Remote Linked Servers

Ø Automatic channel management

Ø Number portability support

Ø User authentication by username/password, IP address, techprefix, caller number

Ø GeoIP database

Ø Automatic SIM allocation:

Sim allocation rules:

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

-Static

-will not modify gw settings

-Limits

-sl (day/month)

-packet allowed intervals

-min/max lines for partner

-Priorities

-sim partnerm, sim, gw

-Desired

-desired minute on packet

-packet multiplier

-Rotate

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

-Price

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

-Timetable

-BRS

-LCR

-and many other options

1.2.8. Billing

Ø Flexible Rate Definition (peak/off-peak/flat/custom, end-user/provider/reseller/sales, etc)

Ø Automatic and Real Time billing (CDRs already includes the prices)

Ø Prepaid and Postpaid platforms

Ø Call Credit Limit Control

Ø Unlimited reseller accounts

Ø Callshops

Ø Directions (traffic sender,prefix,gateway,sim packet) and time based billing.

Ø Reporting and price comparisons (LCR)

Ø Balance and rating with SIP signaling or HTTP requests

Ø Invoice generation in different formats, PDF generation, email scheduler and invoice printing

Ø Complete call rating & accounting services for complex rating schemes

Ø Currency and VAT can be set for every packet. Time zone can be changed.

Ø Automatic online currency conversion

Ø Paypal and lot’s of other payment gateways are supported

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

The Mizu VoIP server has full support for WebRTC since version 7.4 (including websocket SIP signaling and DTLS/SRTP encoding/decoding)

1.2.11. 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.12. 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 networks.

VoIP-GSM hardware listing:

VoIP-GSM gateway

-8 channel gateway, best fit to any cheap DSL connection

-up to 64 simcard/gateway

-SIM server interworking capability

-Integrated antenna splitter

SIM Server

-up to 750 simcard

VoIP-GSM Server

-industrial PC

-fault tolerant

-server failowering capability

-distributed architecture

Built in watchdogs to monitor the operation of the system components

GSM features

Ø Dual Band (900 / 1800 MHz or 850 / 1900 MHz)

Ø Half rate, full rate, enhanced full rate, SMS, USSD

Ø SIM server support

Ø Integrated antenna splitter

Ø 8 channels/box

Ø Up to 8 SIM cards per engine

Ø Multiple ways to handle incoming calls

Ø Call Forwarding

Ø Sending and receiving SMS messages

Ø Email To SMS Feature

Ø Inter gateway SIM routing

Ø SIM server interworking

Ø GSM cell selection and locking

Ø DTMF send/receive

Ø CLI restriction

Ø SIM Rerouting

Ø Locking to a given gsm cell

Ø Automatic SIM credit request and charge

Ø Voice Recording and Playback (In Stereo caller/callee left/right)

Ø SIM server interworking

Ø Virtual Channels

VoIP-GSM

Ø First centralized architecture for GSM termination

Ø Unlimited Gateway and TrafficSender support

Ø Multiple signaling protocol support

Ø Load distribution between the operational channels

Ø No hard limit on the number of simultaneous calls

Ø High availability

Ø High throughput (more than 50 million minutes/month)

Ø No additional Mizu hardware required

Ø Equipment management

Ø Channel management

Ø Simcard management

Ø Automatic recharge

Ø Access Control Lists

Ø Routing (see below)

Ø Billing (see below)

Ø Exploits almost any SIM tariff model

Ø Number translation

Ø Protocol encryption

Ø Media proxy

Ø Automatic time synchronizations

Ø H.323/SIP Gateway Topology Hiding

Ø Embedded firewall

Ø Enhanced Security (automatic detection of flood attacks)

Ø Web GUI for end-users

Ø Encrypted communications

Ø License management

Ø Distributed absolute fault tolerant system

Ø External system supervisor service (email and sms alerts, watchdog can restart failed subsystems)

Ø Can be used as virtual servers

1.2.13. Tunneling and encryption

Tunneling and encryption are built-in into the Mizutech VoIP server and you can enable from the global configuration or from the Config Wizard.

Details: https://www.mizu-voip.com/Software/VoIPTunnel.aspx

1.2.14. Push notifications

Push notification support is a built-in module enable by default. Configuration and integration is described here.

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

Ø Real-time call status view

Ø Service restart functions

Ø Display of the current status of each gateway and channel

Ø Real time call supervision (with many grouping options)

Ø Real time channel supervision (with many grouping options)

Ø Statistics (Text based and graphical ASR,ACD,SL, etc) on any traffic direction and time scale

Ø Disconnect Reasons (with many grouping options)

Ø CDR monitoring, retrieval, direct CDR access
Operator Console

Ø Global system analysis!

Ø Routing pattern selection

Ø Routing time selection

Ø Failowering (in case of channel, gateway, direction etc errors)

Ø Best Route Selection

Ø Billing module

Ø Balance module

Ø Real Time Capacity check

Ø Ability to insert queries directly into the database

Ø Blacklist filtering

Ø Self-analysis tools

Ø Detailed logging (multiple levels). Detailed call tracing capability

Ø Call simulations

Ø Reseller/Agent Registration and Management

Ø Capacity and system load reports

Ø Import/Export from/to any format (SQL, text, excel, etc)

Ø CRM Integration

Ø Restore and Backup

1.2.16. 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 and use a proper MS-SQL server (not the Express editions). This doesn’t affect servers with less then 100 simulaneous calls. You can upgrade the SQL server/service anytime later (full compatibility).

1.2.17. Known issues

Ø Some class 5 features will work only with SIP protocol

Ø H323 GK doesn’t support username/password authentication (mostly used for call transit and not to provide enduser services over H323)

Ø RADIUS is compatible only with some servers

Ø Mizutech doesn’t provide support for client side (softphone) FAX and Video debugging. (FAX and Video are fully supported by the server and will work if you are using a softphone conform the SIP standards, however many software has limited interoperability or bugs)

For a more detailed feature list see the homepage and features pages.

1.3. Contact and tech support

Full remote administration can be done by mizutech support including continuous email support and 24/7 emergency phone support.

Email support: serversupport@mizu-voip.com

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. The soft switch is built from several modules: sip stack, h323 stack, sip – h323 conversion module, media server, ACL, routing, billing, alerting. Almost all modules are installed by default and they can be enabled/disabled as needed. Key modules are listed below:

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 and carriers handling millions of minutes.

2.1.2. WebRTC

The WebRTC module will handle VoIP calls from modern browsers. Includes also a WebRTC – SIP bridge with media relay support.

2.1.3. H323 Stack

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

2.1.4. 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.5. RTPM

RTPM is used with Flash clients to convert the signaling and media between Flash and SIP/RTP.

2.1.7. 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.8. 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.9. Billing

The server will generate the detailed CDR after each call. Thus the billing can work nearly real-time. (Very important for prepaid systems). You can generate various reports and invoices based on a set of predefined rules.

2.1.10. 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.11. Virtual Servers

You can create up to 100 virtual servers on a single pc. These are completely separate billing/routing/signaling entities.

2.1.12. Call Center

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

2.1.13. Watchdog service

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

2.1.14. API

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

2.1.15. Extra PBX

A separate module implementing a few extra pbx features such as voicemail and conference rooms.

2.1.16. Direct command interface

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

2.1.17. Enduser web portal

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

2.1.18. Self-check and reporting

Various system thresholds will checked real-time and the server will do the corresponding actions automatically. The same module is responsible for daily/weekly/monthly email or SMS reports and alerts for administrators and users.

2.1.19. VoIP-GSM Gateway

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

See the features section for more details.

GSM

All standard GSM capabilities are supported.

VoIP

Mizu VoIP-GSM Gateways can accept SIP and H323 registrations, can act as a SIP proxy or a H323 Gatekeeper or Gateway. These functions can be run simultaneously.

SIM Bank

The built-in simbank will allow to virtually routing the simcards in other Mizu gateways.

Mizu VoIP-GSM Gateways can take advantage of an external simbank, so you can have all your simcards in one place, easing the maintenance and administration tasks.

2.1.20. Other components

server service: the brain of the system

H323 GK: standard H323 gatekeeper

SIP Server: sip stack
HTTP interface: enduser/reseller website with built-in http server

Media Server: rtp routing

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

SMS: sending short messages over HTTP API or SMPP

client service: this service supervises the gsm gateway and gives a clear interface to the server

MManage: smart client software, capable to manage the whole system

supervisor service: this service supervises the mserver

alerter service: collects statistical information and reports it

recplayer: can play g729, g723, encrypted, raw PCM and wave files

loganalizer: log file parser

gwtest: handle gsm terminal (no h323)

ipmux: packet saver client and server

serveremulator: server interface to gk

simalloctest: test the automatic sim allocation

smtp_test: test smtp functionality

tariffcalc: estimate sim packet real price

tcperver: tcp server for test

udptest: udp through test

valerterclient: alerter sw which can be installed on client computers

vchargecards: manage chargecards

vclientinterface: platform specific functions for the gw

partnerclient: admin sw. for our partners

pricesettings: for packet price configuration

routingandprices: for config. routes, prices and sim packet priorities

servertest: brute force test for the server

supervisor: supervises the server

updater: automatically updates client software from the server ftp

mediasrv: media server for routing rtp packets

businesslgc: controls the routing, registration, endpoint list, endpoint creation, udp initialization

VPC

Simple monitoring software for business purposes. Each partner (gateway or simcard owners, traffic senders, etc) can have their own VPC to monitorize their own traffic and create reports.

VPC Setup

You can give the VPC for any of your partners. The partners can login to the VPC with the username and password configured in the “Users and Devices” form in MManage. Usually only “Owner” users will receive VPC access.

You can define what users can see in their VPC by setting the “Can watch sim packets”, “Can watch users/devices” and “Access Rights” in the user configuration form (billing tab). See section 4.3.1 for more details.

The VPC included with MManage has the capability to login as a super user. To do so, you have to enter your partner username, but use the admin password (from the “ad” account). Then you have access to the “Add Query” button in the VPC. Here you can add,delete or modify the existing queries and their access rights.

In the “rights_allow” field you can put a list of user id, “all” or “nobody” fields. The same for the “rights_deny”. Thus you can configure which partner can see and execute which queries.

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 and cleanup features. Backup and scaling is automatically provided for you if you are using the Mizutech SaaS platform (Hosted VoIP solutions).

However if you have millions of minutes/month, you may have to watch the system parameters closely, setup proper alerting thresholds and adjust system setting as required.

3.1. Server configuration checklist

3.1.1. Software’s

Windows 2003/2008/2012/2014/2016/2019/2022 server, MSSQL (Standard or Express) 2000, 2005, 2008, 2012, 2014, 2016, 2017, 2019, 2022

3.1.2. Firewall

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

-block: all others, file sharing, ms network

3.1.3. Services and memory

Auto restart critical services

For more than 3 Gb set boot.ini: /3GB /PAE on 32 bit systems

3.1.4. Licensing

Setup configuration with the proper software(s)

3.1.5. Config

Setup FTP and Voice directory NTFS access

3.1.6. MSSQL

Change port to 2223

Enable pipes

Check configuration in Management Client

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)

panel

5. Connect to the gateway or server with the MManage (by typing its ip address and username/password in the login form)

The default username/password is admin/tpwdadmin

6. Set up the basic parameters from the “Configurations” form

Be careful.

7. Set up one or more packets for the simcards in the “SIM Packets”

Be careful with the following settings: prepaid/postpaid, allowedpartners

8. Set up the simcards. You can add simcards manually, but it’s easier to wait for them to register. Then you only have to modify its packets, owners and the recharging settings (“Simcards” form)

9. Add some traffic sender in the “Users and Devices” form.

Be careful with the authorization settings

10. Set up the routing (“Routing” form)

Add at least one routing pattern (name it as you wish)

Add at least one entry to its priority list (your newly created packet or some other direction)

11. Set up advanced routing –Optional

Firewall, prefix rules, BRS, etc

12. Set up the billing module –Optional

13. You are ready to accept traffic now.

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

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

-Remove blacklisted but good numbers (if you are using blacklisting)

3.5. Server backup, recovery and maintenance

3.5.1. About

Most of the maintenance tasks are done automatically in background low priority threads and/or scheduled to offpeak times.

These followings are handled automatically:

-database tuning

-user maintenance

-background statistics

-table or record level backup to _backup database

-delete of the old records (for example old log entries)

-database backup to a predefined directory

-and many others

Since all data is stored in the SQL database, you have to protect only your database (the program directory can be recreated anytime by simple file copy or reinstall. Only the database path is stored here in the mizuserver.ini file which need to be reentered correctly after a restore).

Although there is no special maintenance needs with the mizu server, to have a working backup is a very important task to be set and tested properly. The mizu server will automatically create backups on the same server (without any additional settings), but for a real backup you have to change the backup directory to another physical location.

For more reability you should use the MS SQL backup related capabilities instead of using the mizutech built-in backup methods.

3.5.2. What is a backup?

A backup refers to making copies of data so that these additional copies may be used to restore the original after a data loss event. Backups are useful primarily for two purposes. The first is to restore a state following a disaster (called disaster recovery). The second is to restore small numbers of files or records after they have been accidentally deleted or corrupted.

There are also many different ways in which the data storage devices can be arranged to provide geographic redundancy, data security, and portability.

Any backup strategy starts with a concept of a data repository. The backup data needs to be stored somehow and probably should be organized to a degree. Different repository models have different advantages. This is closely related to choosing a backup rotation scheme.

Unstructured: An unstructured repository may simply be a stack of floppy disks or CD-R/DVD-R media with minimal information about what was backed up and when. This is the easiest to implement, but probably the least likely to achieve a high level of recoverability.

Full + Incremental: A Full + Incremental repository aims to make storing several copies of the source data more feasible. At first, a full backup (of all files) is taken. After that, any number of incremental backups can be taken. There are many different types of incremental backups, but they all attempt to only backup a small amount of data relative to the full backup. Restoring a whole system to a certain point in time would require locating the full backup taken previous to that time and the incremental backups that cover the period of time between the full backup and the particular point in time to which the system is supposed to be restored. The scope of an incremental backup is typically defined as a range of time relative to other full or incremental backups. Different implementations of backup systems frequently use specialized or conflicting definitions of these terms.

Differential: A differential backup copies files that have been created or changed since the last normal or incremental backup. It does not mark files as having been backed up (in other words, the archive attribute is not cleared). If you are performing a combination of normal and differential backups, restoring files and folders requires that you have the last normal as well as the last differential backup.

Continuous data protection: Instead of scheduling periodic backups, the system immediately logs every change on the host system. This is generally done by saving byte or block-level differences rather than file-level differences. It differs from simple disk mirroring in that it enables a roll-back of the log and thus restoration of old image of data.

3.5.3. Built-in 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 configurations:

dbmaint_backuplevel: 0=no backups,1=daily,2=daily,monthly,weekly,3=hourly,daily,monthly,weekly,4=keep lots of files

dbmaint_backupdbdir: local path (accessible for the server)

dbmaint_backupdbnetworkdir: path accessible for the database engine (it is necessary when the database is located on a separate box. Otherwise can be left empty –default to dbmaint_backupdbdir)

3.5.4. 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” (measured in days. is direct proportional with this setting)

If the dbmaint_backuptables is set to 2, than the amount of data can be controlled by the dbmaint_removeother value.

Logs are removed after dbmaint_removelogs days.

The backup databases are created with the same name as the current database with a “backup_” prefix.

If you want to place the backup tables to a separate server, you must set that backup server as a linked server in the main database and set the “linkedserver” config option in the server inifile.

The backup intervals can be controlled by the “dbmaint_backuplevel” option: //0=no backups,1=daily,2=daily,monthly,weekly,3=hourly,daily,monthly,weekly,4=full,5=keep lots of files

(be aware that if you set it to 0, than the other option will have no effect)

In order to take advantage of the backup database, you must set the “Secondary database” option in MManage to “Autodetect” or “Secondary DB”. When set to autodetect, it will attempt to load data from the backup database if the query date is set to more than 1 month later (it will failback to main database if is set to earlier than 2 week). In this case the “until” date is modified automatically to yesterday midnight when needed.

For the MManage to be able to connect to the backup database, the “backupdatabaseaddress” must be set up correctly when a separate database is used.

3.5.5. Database maintenance

The server will optimize the database engine automatically.

dbmaint_do: enable/disable the daily and the monthly maintenance

dbmaint_removelogs: Trunk log tables and remove logfiles after x days

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

3.5.9. MSSQL Server and MSSQL Studio

Microsoft SQL Server is a relational model database server produced by Microsoft. Its primary query languages are T-SQL and ANSI SQL. You can work directly with the database using the client IDE tools, and several complementary systems that are packaged with SQL Server. These include: an ETL tool (SQL Server Integration Services or SSIS), a Reporting Server, an OLAP and data mining server (Analysis Services), and several messaging technologies, specifically Service Broker and Notification Services.

SQL Server Management Studio is a GUI tool included with SQL Server for configuring, managing, and administering all components within Microsoft SQL Server. The tool includes both script editors and graphical tools that work with objects and features of the server.

A central feature of SQL Server Management Studio is the Object Explorer, which allows the user to browse, select, and act upon any of the objects within the server. It can be used to visually observe and analyze query plans and optimize the database performance, among others. SQL Server Management Studio can also be used to create a new database, alter any existing database schema by adding or modifying tables and indexes, or analyze performance. It includes the query windows which provide a GUI based interface to write and execute queries.

SQL Server Management Studio can be downloaded for free from the Microsoft Website: http://www.microsoft.com/downloads/details.aspx?FamilyID=08E52AC2-1D62-45F6-9A4A-4B76A8564A2B&displaylang=en

3.5.10. How to make a manual backup

First open Microsoft SQL Server Management Studio, open Object Explorer, open Databases, right-click with your mouse on the database you want to back up, select tasks and select Back Up from the menu.

The next window will appear:

At Source/ Database select the database that you want to back up. At Backup type select either full for full type of backup or differential, for differential backup.

At Destination click on the Add button, select the disk, and path to the file where you want to save the backup file. If this is on another server type \\ double-slash, followed by the IP address and path on the another machine.

3.5.11. How to set up automated backup

In the Object Explorer open Management, under Management right-click with your mouse on Maintenance Plans and select New Maintenance Plan. In the small window that appears give it a name.

Click Add Subplan, Introduce names, description, and set the schedule for the given Subplan, by clicking on the small calendar icon.

The Schedule settings window looks like this:

Once the time and frequency of a given schedule is set the tasks from the left side of the window can be dragged and dropped in the field under the subplans list. For every subplan a ‘Backup database task’ and a ‘Maintenance cleanup task’ can be dragged/dropped and defined on this field.

For example you can create 3 folders in the shared folder on the application server, one for hourly differential backup which is backed up once every hour, and the backup is deleted once every day. You can create another for a full daily backup, and one for full monthly backup.

Once you drag/drop and define the backup tasks from the lower left pane to the right, the subplans will look like this:

http://support.microsoft.com/kb/930615

3.5.12. Dual Server Configuration

In the Dual Server Configuration there are two separate servers used, the application server and the database server. The MizuTech VoIP Service is running on the application server and usually a Microsoft SQL Server database is installed on the database server. The direction of the backup is from the database server to the application server, into a shared folder, so that if the database server experiences problems the other server can provide the latest backup.

In an ideal case, backup is of three kinds: an hourly differential backup and a daily full backup about the voipserver database, and a monthly full backup about all databases. For more reability you can also setup continuous backup (with replication or log sipping)

3.5.13. Tools and scripts

Scheduled backup tasks for MS SQL Express: http://www.diaryofaninja.com/blog/2011/02/14/howto-quick-amp-dirty-sql-express-scheduled-backup

Fee backup & FTP tools (for one single database): http://sqlbackupandftp.com/download/

http://www.sqlbackupmaster.com/download

Script for SQL backup & FTP: http://www.morrenth.com/script-to-backup-zip-and-ftp-sql-server-database.aspx

4. Administration

This chapter discusses the Administration of the VoIP server.

A quick tutorial can be found here.

4.1. MManage

4.1.1. Overview

All administration tasks can be done using the MManage (MizuManage) client application. The main module is automatically installed with the server installer, but you can also install it independently to any PC and manage your server remotely. Restricted administration is available also from the web interface. During this guide you will meet very often the “global configuration” term. This is referring for the settings configurable using the “Configurations” form (under the “Other” item). These settings are system global and are stored in the tb_settings database table (will be discussed later)

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/8/10/11/2003/2008/2012/2014/2016/2019/2022

-At least 1024x768 screen resolution for better operation

-You may need a headset for tescalls

-Network connection

Double click on the install exe and follow the instructions.

During the install procedure the following modules and files will be copied:

-MManage.exe –the main executable

-VPC.exe –admin version

-VSQLRouter service –for compressing and encrypting sql requests and answers

-VoIP client programs (SIP and H323)

-Adobe Acrobat Reader –optional (can be canceled during the install process)

-Cute PDF Writer – pdf printer driver used for reports and invoice pdf creation -optional (can be canceled during the install process)

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

-Required dll files

-Help files

-Uninstall.exe

-Other files (depending of your install package configuration, OS version, etc)

When properly installed, you are ready to login on your server(s) and/or your gateways. If you have a central server, all administration tasks can be done connecting only to the server. If your gateways are running without a server, you must connect to each gateway separately for doing administration tasks.

The following values are required on login:

App Server: server ip address

DB Server: database ip address (“default” can be used if the same as “App Server” address )

DB: Application and database instance (because a single server can hold several virtual server)

Username: login name

Password: login password

Use encryption: encrypt and compress the server communication (requires the “vsqlrouter” service to run)

loginf

4.1.3. MManage Framework

tmanage

Almost all tasks are done by selecting an item from the left side of the main form. For detailed descriptions please read below.

In the Menu you can find common tasks such as “Settings”, “Save As”, etc. The selected action usually has effect only on the current active form.

From the File Menu you can save, print or export the selected form. Usual database operations are performed from the Edit Menu. In the Favorites Menu you can see the most frequently used items. In the Config Menu you can find a set of helper applications explained later in this document.

In the Fields the most important form is the “Filter” which will filter almost all listing used in MManage. Here you can define your preference regarding the traffic direction including Source and Destination. You can filter on Item Type, Item, Group, Number Prefix, Packet and SIM Card. For example you may select one SIM ID, and when loading logs, you will see only the messages related to the selected simcard.

In the left-bottom side of the form, you can find an edit box used for quick search. You can use the ‘*’ character in the begin and the end of expressions. (For example when searching for CDR records).

Most of the report will be filtered after the selected Date Interval also.

In the Thresholds you can set some thresholds used for MManage. This setting doesn’t have any effects on the server or gateway. Server and gateway thresholds may be set up from the Configurations Form explained below. In the Options Windows, you can set up several important MManage parameters.

In the Help Menu you have access to documentation.

In the Licensing box you can see your server parameters (there is no effect if you change these values, because these are used only for informing you). Depending on licensing, some modules may not be available in your release! Occasionally you may need to know the software version you use, which you can find in the About box.

Example: How the check your ASR for the traffic sender “A” in the last week.

1. In the date-time drop-down list, select the “Last Week” field

2. In the “Select Direction” form set the “Source” (left side) “Type” to traffic sender, and select “A” in the “Name” drop-down list (or type “A” manually)

3. Launch the “Basic Statisitcs” form under Monitoring.

4. Clear the “Group by” option (select the first “-“ line)

5. Make sure the ASR checkbox is checked

6. Click on (Re)Load

7. Depending on current server config and current load this query may take some time (on a usual configuration this will take 2 second)

4.1.4. Import-Export Wizard

With the ease of the import –export wizard, accessible from MManage File menu, you can import and export data from/to a lots of data formats.

The following file types and databases are supported:

Access

Excel

DSN

CSV

Text

IBM-DB2

Interbase

MS-SQL

MySQL

Oracle

Paradox

DBF,dBase,FoxPro

Other datasources wich can be accessed by ADO or ODBC.

4.2. Monitoring

4.2.1. Current Calls

currentcalls

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.3. Basic Statistics

Shows the main traffic amount and quality parameters of your system.

basicstat

CDRC: call attempt count

SL: speech length (duration in minutes)

ASR: average success ratio (percent)

ACL, ACD: average call length, average call duration (in second)

You can select any direction in the “Select Directions” Box, to check only that specific traffic. Also there are some simple groupings available:

-No grouping: will display the total sum. Chart views are supported only with this option

-Group by Called Gateway: list of destination gateway statistics

-Group by Traffic Sender: list of statistics by source

-Group by SIM Packet: statistics by SIMCard type

-Group by All caller and called

-Group by Provider Direction: statistics by called number prefix (first 4 digits)

4.2.4. Advanced Statistics

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

In some versions is shown simply as “Statistics”.

advancedstat

You can make reports based on the following fields:

-CDRC: number of calls

-SL: speech length (all call duration)

-ASR: the number of successfully answered calls divided by the total number of calls attempted (seizures) Since busy signals and other rejections by the called number count as call failures, the calculated ASR value can vary depending on user behavior

-ACD: average call duration

-ASRB: average success ration, but here the “success” means a minimum amount of duration. Configurable in Settings Menu -> Thresholds Box

-ACT: average connect time. The time elapsed from setup until the connect in seconds

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

-CCC: concurrent (simultaneous) call count

-RTP: media channel statistics

-EC: end-user costs

-PC: provider costs

-SC: sales costs

-CC: company costs

-EP: estimated enduser price/minute

-PP: estimated provider price/minute

-PF: profit value (This require your billing module to be properly configured including provider prices)

-PR: profit margin in percent

-PFE: profit from enduser (useful if you are using reseller or sales accounts)

-PFR: profit from top reseller (useful if you are using reseller accounts)

-HM: hidden minutes

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

The following “group by” options are available:

-: display summary data (no groupby)

Caller and Called: group by caller and called users

Caller: group by caller (source) user

Called: group by called (destination) user

Traffic Sender: group by caller (source) user, but show only traffic senders

Called Gateway: group by called (destination) user, but show only gsm gateways

GSM Engine: group by called gsm channels

Gateway, Packet and SIM Card: group by called simcard (and show the actual gateway and packet)

SIM Card: group by called simcard

Caller IP: group by caller ip address

Week –absolute: group by week, but with sum (don’t groupby to months)

Day –absolute : group by day, but with sum (don’t groupby to weeks)

Hour –absolute: group by hour, but with sum (don’t groupby to day)

Week: group by weeks

Day: group by days

Hour: group by hours

Minute: group by minutes

Day Compare: compare current weekday with last week the same day

Called SIM Packet: group by called simcards group

Partner/Day: group by partner and day

Partner/Hour: group by partner and hour

Partner/Minute: : group by partner and minute

Called Country: : group by called user country

Called Direction: : group by callednumber zone

Provider direction (prefix):: group by callednumber prefix

Provider direction (name): group by callednumber direction

Direction and packet: group by prefix and simpacket

Provider direction and packet: group by callednumber zone and simpacket

By caller root endusers: group by billed or company callerusers

4.2.5. Disc. Reasons

Disconnect codes in graphical form by any traffic direction.

discreasons

The server will collect the reason in the most appropriate format depending on the protocols used. For example for a call from voip to gsm if the disconnect was caused by the gsm party, then you will see the GSM network reason code here. Otherwise, if the disconnect source was the caller party, and then you will see H323 or SIP reason codes here.

The most common reason codes are the followings:

-SIP, Bye: normal SIP close code

-SIP, CANCEL: the call was canceled by the caller (not connected call)

-H323, Remote endpoint application cleared call: normal H323 disconnect

-H323, Remote endpoint stopped calling: the call was canceled by the caller (not connected call)

-GSM, Normal call clearing: normal GSM close code

-GSM, Normal unspecified: normal GSM close code

-Server, Blacklisted: dropped due to ACL (blacklist)

-Wrong Media: no voice activity detected.

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 such as concurrent calls, CPU load and RAM usage.

Note: AvM type means weighted utilization: average of max and average usage ((AVG(value) + MAX(value)) / 2)

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)

and many more as described by the API (all API commands are accessible also from console)

Raw clear text CLI access is also listening on port configured by the adminport global config option.

CLI access might be IP filtered by the remoteadmin parameter. Possible values:

0: disable

1: from localhost/127.0.0.1

2: from same machine

3: from trusted sources

4: from local lan and subnet

5: from everywhere (default)

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 period. You can restrict the listing by defining the source, severity or filtering.

4.1.12. Analyze

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

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

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

CDRs will contain the following fields:

Id: database identifier. Auto increment

Datum: the date-time when the CDR were inserted into the database (call end time)

Callstartdate: call start time (first INVITE sent or received)

Callenddate: first disconnect code or CANCEL/BYE received or sent

Connectdate: first 200 OK received or ACK for 200 OK sent

Connecttime: time elapsed until call fail or call pickup (routing+ringing time)

Workenddate: used for callcenters and represents the time when the operator have finished to work with the current client (CRM updates, etc)

Realduration: speech length

Discparty: disconnect origination. 1=called or gsm, 2=caller or h323, 3=router (server)

Discreason: disconnect reason code. Explanations in tb_reasoncodes

Callerid: caller database id from tb_users

Callerip: the origination ip

Callernumber: caller phone number (or sip username)

Calledid: called database id from tb_users

Simid: called simid (if any)

Calledline: Engine (phone line) or the called proxy authorization id (from tb_proxyauth)

Calledip: the ip address of the called party

OrigCalledNumber: received called party number (not modified)

Callednumber: techprefix and the normalized called number. If the server will block the call too early, than you may have the “origcallednumber” here (no techprefix and normalization)

DialedNumber (calleddialed): the forwarded called number (sometimes only the “callednumber” will be insterted here)

Rtpsent: rtp packets from caller to called. 0 if no rtp routing. At least 1 if routed. If remains 1, then routing has failed

In case of sip this means rtp packets received from the called and sent to caller successfully

Rtprec: rtp packets from called to caller. 0 if no rtp routing. At least 1 if routed. If remains 1, then routing has failed

In case of sip this means rtp packets received from the caller and sent to called successfully

Rtplost: lost rtp packets

Rtpcodec: voice codec name

Rtpname: used for gateways

Rtpframes: rtp payload framed in one udp packet

Signalin: audio signal strength into the playback device

Signalout: audio signal strength received from the audio recorder device

Jittertime: used when jitter time is reported by gateways or softphones

Tpercek: hungarian specific. deprecated

Costprovider: call cost to the provider (ex. Tmobile)

Costenduser: cost for the caller in global currency (ex: a sipuser or traffic sender)

Costenduseru: cost for the caller in user currency

Costsales: sales commission if any

Costcompany: price for the reseller company

Costadditional (costother): used for reseller prices (in the main cdr)

Recfileid: if we have recorded the voice, then after this field we can found the recorded file

Mark (marker): for special CDR records: EMAIL (e-mail), SMS (sms), FAX (fax calls), FAIL (failowered), RER (rerouted), FWD (forwarded), TRANS (transferred), CONF (conference), PRED (predictive) and to signal other important call types

Opworktime: used in callcenters to store the actual operator worktime

Opwaittime: used in callcenters to specify how much time the operator have been waiting for the current cal

Billingstep: loaded from price settings (endusercost packet)

Unitprice: loaded from price settings (endusercost packet)

Billingentry: loaded from price settings (endusercost packet)

Origduration: all original duration (because the “realduration” field can be modified on IVR 2 leg billings or when hidden charges are applied)

Resellerid: top reseller id in tb_cdrs. Actual reseller id in tb_cdrresellers.

Accessnumber: set when the call have been made trough a specified IVR access number

Origcallerid: used when the caller id have been modified during the call. For example the caller can be a “traffic sender” but after ANI or PIN authorization there is an enduser inpersonalisation

Alegduration: used for 2 leg calls (first calleg with ivr)

Blegduration: used for 2 leg calls (second calleg from ivr after callforward)

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

Dirid: direction name after the called number prefix

cdrrecords

Rtpsent and rtprec is 0 when media routing has failed (if we don’t route the media, or the terminating endpoint don’t send media info to us, the system will set there values to 1, so this condition will be true)

All prices in the cdr records are calculated with VAT included!

To find out the possibilities to list the CDR record for a user, please check this wiki.

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 MAgent in the current day

EndTime: operator last seen time in the current day

WorkTime: time when MAgent was running

ActiveTime: time when the operator is in “Automatic Call” form and not paused

OpWaitTime (WaitTime): the time elapsed from a new call request untill the first call connect. Smaller times represent more effectiveness. (the reason for the predective dialer is to reduce this time to minimum). The value will be stored for each connected cdr record.

OpWorkTime (PTime): The time elapsed from hangup untill new call request. This will represent the time spent by the operator for data postprocessing. Quick operators will have smaller opworktimes (but can be affected by the ammount of data to store) . The value will be stored for each connected cdr record.

TotalWorktime: MAgent runtime in that day

ActiveWorktime: When the automatic dialing form is active and not in paused

Called: number of called clients

Completed: clients marked as completed. Useful for meassuring the operators effectiveness.

Invited: clients marked as invited. Useful for meassuring the operators effectiveness.

Recalls: clients marked as need recall

CDRC,SL,ASR,ACL: traditional statistics. More details here.

4.3. Access

4.3.1. Users

This form (Users and devices) will allows to manage the users of the system (Endusers, SIP users, Administrators, Tech. Support users)

The most important user type is the endusers.These are usually registered on the server using the SIP protocol. They are allowed to call each-other usually for free (presence and messaging is also enabled by default).

For high amount of inbound traffic, you should use a traffic sender user instead of an enduser (and use IP autheticaton instead of username/password based)

For outbound routing you will have to add SIP server or H323 gateway user type and set the routing properly.

If you need both to accept and sent traffic to another server (carrier) then you have to add it both as traffic sender and SIP server.

Open the “Users and devices” form to see your users. There are a few template user created during setup. You can add new user by just cloning one existing user (select an user with the appropriate type, click on the “new user” button, the select “yes” when asked for cloning). This is useful if one of the many settings must have a predefined value, so you must set it only once, then if the new users all cloned the setting will be copied also). Otherwise you can create emty records and populate the required fields. Most of the fields are optional (with a preset default value) and only a few is very important which you have to change for each user like the username, password, credit, postpaid/prepaid, IP/AuthIP and the authentication type (needauth field).

Users can also be created in batch (Config menu -> Users)

The following types of users are defined in the Mizu VoIP server:

Enduser: represents retails customers or sip devices. Endusers are usually authenticated by SIP username/password and the account can be either prepaid or postpaid

Sub-enduser: Represents sip devices or callshop cabins. One enduser can have multiple sub-enduser account.. This means that when a sub-enduser (device) makes a call, then the parent Enduser account is billed

Operator: used only for outbound callcenters and represent an Agent account

Calling-Card: this type of account can be used for inbound callcenter if you wish more separation between regural users and ivr users. Otherwise a regural enduser account can be also used for IVR authentication (calling card / PIN)

Reseller: resellers can manage their account trough the web interface and can create their own tarrifs. They can add other resellers or endusers below their account.

Owner: can be used to separate certain type of businesses. You can create one ore more owners and add all other users below the owner account

Traffic sender: from where you receive bigger amount of traffic (wholesale)

Sales: you can add sales people to the system and apply a specified rate as their discount

GSM GW: VoIP-GSM gateways

SIP Server: your otbound routes (carriers)

H323 GW/GK: any device (gateway or gatekeeper) using H323 protocol
ISDN GW: gateways to the PSTN network

SMS GW: sms gateways usually with HTTP API
Support: support people will receive automatic maintenance related emails

Admin: admin people with special permissions (for example you need to login as an admin user to the web enduser interface to be able to have access to the customization options)

The “Users and devices” form can be filtered in many ways:

Ø quick filter field

Ø Fields menu -> Filter

Ø user type

Ø the drop down list from the user form

Ø listings initiated from other forms

Ø groups

Ø For more flexibility you might use direct SQL queries against the “tb_users” table.

You can list the users with the following filters:

-ActiveNow: gateways with received status in the last 5 minute or endusers active (register or invite received) in the last 3 hour

-Active:

-gateways with received status in the last 24 hour or when “mustbeactive” is set to 1

-endusers active (register or invite received) in the last 24 hour

-All Enabled: where the “Enabled” field is not 0

-All: all users

-New Users: users added in the last month

-New Web Registrations: users added in the last month by the web registration form

-Low Credits: will list users with credit lower than 3000

The properities can be modified from one of the following pages:

Ø Listing page (grid). All fields are listed here with add/delete/edit possibilities. The “monitor” field are updated based on current statistics and settings.

Ø Edit operator: showed only for callcenter operators to set the agent related settings

Ø Edit: the most important user settings are listed here

Ø Functions: change class5 features from here

Ø Billing: billing related options

Ø Gateway configuration: only used for linked gateways

Ø Show details: will list most of the important settings

Ø Analyze: view user statistics

The following fields are defined:

ID: database id. Auto increment

Type: user type (together with the “isoperator” field)

0: enduser (usually a sip user). -isoperator field set to 2 (default)

0: sub-enduser-isoperator set to 0

0: Operator (callcenter agent or callshop agent) -isoperator set to 1

0: Calling card –isoperator set to 6

1: reseller (usually a sip reseller)

4: sim,gw or traffic owner (sim partnerid or gateway parentid show this id)

5: traffic_sender (parentid can be a simowner or a gatewayowner)

6: sales (parentid is the reseller id)

8: gsm gw (parentid is the gatewayowner)

9: outbound sipserver (proxy or gateway) (parentid is the gatewayowner)

10: h323 gw (parentid is the gatewayowner)

11: isdn gw (parentid is the gatewayowner)

12: sms, fax,email gateway

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

15: admin users (can see and modify everything, can receive email/sms reports)

17: other users (for various reasons)

ParentID:

This field is very important for resellers/subresellers relationships.

Logical parent of the user. Checked for routing pattern, max lines, etc.

if a sipenduser then reseller company

if traffic sender, then traffic owner

if gateway, then gateway owner

if reseller company, than operator

BillingUserID:

Where the invoices will be sent. Credit will checked for these users

If the current type is an end-user, then can have a BillingUserID where we send the invoices. If not set or the same ID as the current, than the bills will be generated to itself. For example in a company, all bills will be sent to the boss (company address), nit the employee

IsBilledUser: set to 1 if this user is not a real service user, but a user who pays for other user. Usually this is a company who pays for its employee.

Deprecated!

UserGroup: users can call each other only if the user group is the same (default: 0)

usually users with the same parentid (reseller) has common parentid

RingGroup: a list of usernames separated by comma (all number will ring when the actual user will be called)

BelongsToCompany: when a company has more then one subscriber. Used for example for short sip numbers.

IsCompany: if the current user actually is a company

RGMode: how to use the ringgroup: 0=forked call, 1=round robin

Name: user first and last –name

Country: sip phone country (important for prefix rules)

ContactName: additional name

UseCallingCard: if has calling card (usable with pin codes)

CanDial: example: for sipuser is 1. for simowners is 0

Phone: user phone number (but not the sip phone)

Email: where the user can be contacted

Address: where the user can be contacted

Billaddress: where to send the invoices

TelNumber: sip telnumber.users can be contacted if we call there username or telnumber.

More than one DID or ANI number can be assigned for one user. For this the tb_users_othernumbers table is used where the type field is 0 for DID numbers and 1 for ANI numbers.

ShortTelnumber: sip short telnumber (for example if several users has the same BelongsToCompany field)

DisplayName: how the user will be displayed. Can be null

Username: the most important field. Used for authentification and also as a DID number. This field is unique and cannot be empty.

Password: password applicable everywhere (sip, web, VPC, etc)

Ip: sipphone, sipproxy or gsmgateway ip address. The server will overwrite with the last known ip address

AuthIp: if we want to authenticate after ip, not after username/password

More than one auth ip or domain can be used for a traffic sender. For this the tb_users_authip table is used.

NeedAuth:

-If NeedAuth is 0, then the system is an open voip relay !!!!

-If NeedAuth is 1, then AuthIP must match (usually from SIP traffic senders)

-If NeedAuth is 2, then TechPrefix must match (usually from H323)

-If NeedAuth is 3, then TechPrefix and IP must match (usually from H323)

-If NeedAuth is 4, then user/pwd must match (usually from SIP end-users)

-If NeedAuth is 5, then username must match

-If NeedAuth is 6, then AuthIP and Port must match

-If NeedAuth is 7, then AuthIP and username must match

-If NeedAuth is 8, then AuthIP and username/password must match

-If NeedAuth is 9 then AuthIP Range must match

-If NeedAuth is 10, then AuthIP Range and username/password must match

AddDate: when the user has been inserted in the database

Rights: rights on user interfaces

0: no access

10: cannot login (disabled)

20: can login but no rights

25: restricted user (for example support under reseller)

30: a normal user

40: sales

50: admin

60: general admin

AddedBy: the user id who have added this user (sales, web registration, etc)

Commission: used for sales to define their comission percent from the enduser price

Reduction: sales user can give to enduser some percent (substracted from their comission)

LateFee: applicable when the user is late paying the invoice cost

PacketID: billing for users, traffic senders

BillingDay: usually 1 (the first day in every month)

Qualification: the importance for the user. From 0 to 10. for example if the user has big priority, then we route its calls to better routes

Postpaid: if the user will prepaid or postpaid

PaymentMode: Check (0), Bank Tranfer (1), Cash (2), Else (3)

ContractNumber: contract for end-users

Allowedpartners:

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

A list of user id separated by comma or ‘*’

Note that parent users will be checked too

Enabledprefixes: can be one prefix (with any length) or a list of prefixes with 3,4 or 5 digit separated by comma.

Can be used for trafic senders and gateways too. No need to setup a separate routing pattern if you use this restriction.

EnabledTechPrefixes: enabled techprefixes for the specified gateway (3 digit length numbers separated by comma)

BlockPrefixes: list of called prefixes that will be blocked for the user (techprefix will not be considered here). Numbers listed here must have 7 digit

length and separated with comma.

ContractState: the status of the contract

0- Unknown

1- Not applicable

2 -In Progress

3 -Active

4 -Terminated

ContractComment: additional comment for sales

Credit: when postpaid, then we also can set a max amount (which will reset in every month)

Enabled: if disabled, it behaves as if it were deleted

DomainName: sipproxy domain name

Port: signaling port

TransIp: secondary signaling ip

TransPort: secondary signaling port

RouteRtpCaller: routing mode if this endpoint is the caller

0=check called settings –this is the preferred settings

1=don't touch the sdp and the rtp

2=sdp correction if necessary

3=route rtp if both behind nat

4= route rtp if caller is behind nat

5= route rtp if called is behind nat

6= route rtp if any endpoint is behind nat

7=always route rtp

RouteRtpCalled: routing mode if this endpoint is the called

0=check caller settings

1=don't touch the sdp and the rtp

2=sdp correction if necessary

3= route rtp if both behind nat

4= route rtp if caller is behind nat

5= route rtp if called is behind nat

6= route rtp if any endpoint is behind nat

7=always route rtp

If the routertp setting is set to 1 or 7, it will be applied regardless of the other endpoint setting.

RtpIp: last rtp ip

RtpPort: last rtp port

ServerRtpPort: last bind (we try to use the same for every user)

NatDetected: 0= no and don’t change, 1=no but can be changed, 2=yes but can be changed, 3 yes, and don’t change it

NatDetectDisabled: deprecated

Status: 0=inactive,1=registered, 2=speaking (if statusdate is too old, then treat as 0)

StatusDate: last status change

CalledNumber: last called number

CalledID: last called id

Discount1: discount percent. users can have discounts in for max 3 directions

Direction1: prefix. users can have discounts in for max 3 directions

Discount2: discount percent. users can have discounts in for max 3 directions

Direction2: prefix. users can have discounts in for max 3 directions

Discount3: discount percent. users can have discounts in for max 3 directions

Direction3: prefix. users can have discounts in for max 3 directions

TechPrefix:

The server can authorize and/or route the traffic after the incoming techprefix.

Sip users can have techprefixes too. this is usually common for reseller company users.

If no techprefix is specified, then it will be loaded from tb_pxrules if any.

Sim owners and vpc users can have a list of prefixes separated by comma.

If no techprefix is specified, 111 will be inserted for incoming called numbers.

If the techprefix is „-1”, then the original techprefix will be forwarded.

If the techprefix is „-2”, then the original techprefix will be inserted in cdr record (but not forwarded).

If the techprefix is empty, then only the normalized callednumber will be forwarded.

The following techprefixes are reserved for the server: 111,222,999.

Only 3 digit techprefix is allowed. If your traffic sender needs another techprefix length, you must rewrite the incoming number in the “Prefix Rules” form.

Example: protcoll: sip, Type: ip, value: your traffic sender ip, rewritefrom: oldtechprefix, rewriteto: newtechprefix.

Addtechprefix: we insert this number before the callednumber if the caller don’t send its calls with tech prefix

MaxLines: max concurrent calls allowed

maxlinetouse: deprecated

CurrCallCount: current running calls (usable for traffic senders)

enablefakegw: if we don’t have capacity, we can route h323 calls to a fake gateway to prevent congestions

candisablesim: if the router will check the disableduntil field from tb_sims

alarmat: we can ring the sipuser if it is set

forwardonbusy: telnumber where we have to forward the calls when busy

forwardonnoanswer: telnumber where we have to forward the calls when we have no answer

forwardalways: rerouting

voicemail: if we can send messages as email

mincreditonroute: if user has less credit, then we don’t even route the call

regtimeout: reregistration interval for sip proxies

maxsubsfail: we set the „nopriority” field when we reach „maxsubsfail” failed calls

subsfails: successive calls with duration smaller than 20 sec

nopriority: this gateway has lowered priority in the routing until this date

noprioritycount: successive lowered priority countminasr:

minasr: minimum asr before failovering

minacl: minimum acl before failovering

mincallcount: min. Cdr records to calculate minasr and minacl

lastrouted: last call time (applies to caller devices and users or to callers when it is a proxy)

lastcalled: last call time (applies to called devices and users)

active: applicable for gsm gateways.

display: text to display instead of username

description: important comment

comment: any comment

lastrectime: last status receive from this gsm gateway

realgw: we can have fake voip-gsm gateways

temporarilydisabled: gsmgw is temporarily disabled

onlytestcalls: we allow only calls with techprefix 999

testprefix: we allow only this techprefix

datum: when the user has been inserted into the database

mustbeactive: if the gsm gateway must be active. Will do actions if this field is 1 and the gateway is not active

notactivecount: how many time we found that the gw is not active

channelcount: gsm channel count

minline: minimum active lines. If we found less line active, then we do actions

nominlinecount: : how many time we found that the gw has not enough line

prioritypartner: this partner will have priority on this gateway

callerpriority: this caller prefix will have priority on this gateway

calledpriority: this called prefix will have priority on this gateway

autopriority: set by server. If the gateway is wrong, then we lower the priority until this time

absolutepriority: if we set it greater then for other gateways, all calls will be routed here, until it is filled, regardless to other routing settings

priority: gateway priority

swversion: gateway sw version

lastrestart: gateway last restart

cutg711: if a better codec exists for the caller (g723 or g729) than PCMU and PCMA will be not offered to the called party

pingtime: deprecated

avgkbitssec: deprecated

maxkbitssec: deprecated

bandwidth: deprecated

restartcount: gsm sw restart count

pcrestartcount: gsm gw (pc) restart count

lasterror: last error message from this gw

lastlog: last log message from this gw

sendonlyrec: where to send sip messages.

0 = received address and the address in the signaling (via,contact,etc)

1=send only to the source address

2=send only to address specified in the signaling

callsigaddr: h323 port

isfake: we can have fake voip-gsm gateways

forwardearlystart: if we can send media parameters before callstart (OK for INVITE). 2 if check called

changesptoring: if we have to change the session in progress message to ring. . 2 if check called

identityforward: we can toward these kinds of usernames and the other we rewrite to „identityrewrite”

identityrewrite: if the caller username don’t match the identityforward prefix, then we rewrite it

PlayAdv: if we can play advertisements for this user

Maxmonthlycredit: max allowed credit/month even if the user is postpaid (in ft not in filler)

Maxmonthlycreditend: max Maxmonthlycredit (because we increase Maxmonthlycredit by maxmonthlycreditinc every month if the user was active)

onlylocalaccess: traffic sender traffic will not be forwarded (can call only local users from tb_users and tb_numbers)

Maxmonthlycreditinc: determines how much money we add to Maxmonthlycredit every month

ContractNumber:

Contact Status:

0-Unknown

1-Not applicable

2-In Progress

3-Active

4-Terminated

Contract comment: any usefully comment for sales here

Noanswertimeout: will redirect if no answer received

Denyaddr: because the server will try to send the sip messages to all possibile addresses, sometime it will missroute. With this setting you can restrict the address posibilities. Check the FAQ for more details.

sendfakealert: used for gsm gateways. Specifies the timeout in sec after that the gsm gateway will send an alert to voip even if no ringing have been received from gsm network. Set to 0 or -1 to disable. Gsm gateway settings will overwrite the traffic sender settings if is not set to -1

sendsmsalert: use for support and admin acounts. Will send sms notification to the configured “phone” when a critical error occurs

sendemailalert: use for support and admin acounts. Will send email notification to the configured “email” when a critical error occurs

sendsmsreport: daily sms report for support and admins

senddailyemail: daily email report for support and admins

convertdtmf: applicable for sipproxy users

-0: DTMF messages will be forwarded as received from client

-1: INFO and RTP DTMF messages will be converted to InBand

-2: INFO and RTP DTMF messages will be forwarded and converted to InBand too.

-9: don’t forward INFO

sendmonthlyemail: monthly email report for support and admins

Missed by SMS: notify about missed calls by sms. Usually used for endusers

Missed by Email: notify about missed calls by email. Usually used for endusers

Can watch sim packets: list of packetid separated by comma, used for VPC access. The actual partner can see this simpackets with his VPC account

Can watch users/devices: list of users and gateways id separated by comma, used for VPC access. The actual partner can see this devices with his VPC account

Access Rights: specify wich fields are allowed for the user in the VPC application

0: simcard and traffic sender fields are not shown

1: simcard related fields are not shown (simid, packetname)

2: traffic sender related fields are not shown (name, username)

3: all fields are shown

CLI: CLIR and CLIP settings

0: forward always (forward asserted as normal number always!). will not hide, even if caller was set so

1: normal handling (forward asserted as normal number) -default

2: forward as asserted identity always (identityrewrite asserted)

3: forward as asserted identity only to trusted domains (identityrewrite asserted)

4: normal hide (no idenityrewrite forwarding)

5: force hide (no asserted identity too!). always hided

IsOperator: specify if the user is a callcenter operator (1) or a sub-enduser (0) or power enduser (2)

Choosecodecs: list of supported rtp payload formats in priority order separated by comma. Only one will be selected. Don’t set this field to disable

selecting only one code.

If set, than only one codec will be left in the sdp (plus the dtmf codecs). This will help, when the server answer to invitation with more than one codec in the 200.

The client should answer with the final codec in the ACK, but many endpoint fail to do so.

SessionTimer: use session keep alive.

-0: don’t use

-1: load from global config

-2: autodetect (and using the sesskeepalive interval from the global configuration)

-Other: use with the specified timeout (minutes)

For example if we set it to 5, than a UPDATE or reINVITE will be sent in every 5 minute to the other party. Please note, that the session keepalive is not the same with NAT keepalive (wich is used with every endpoint automatically)

users

Default users:

Owner mycompany: template for owner

GsmGw LOCAL_GW: used for advanced gateways. IP=127.0.0.1

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

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

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

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

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

The following fileds has direct impact to routing:

Type

ParentID

RingGroup

UserGroup

onlylocalaccess

enabledtechprefixes

accessrights

enabledprefixes

blockprefixes

enabledroutes

RGMode

TechPrefix

forward...

temporarydisabled

onlytestcalls

testprefix

prioritypartner

allowedpartners

callerpriority

calledpriority

absolutepriority

4.3.2. Devices

Administration of Mizu Gateways, Other GSM Gateways, H323 Endpoints, SIP Proxies, ISDN Gateways and other compatible devices. The fields are the same as for the Users (see above)

If the actual sip proxy require authentification, then we store the accounts in this table

Id: database identifier. Auto increment

Priority: Account priority (accounts will be used in priority order or in round-robin if they have equal priority)

Username: sip username used in authentification

Password: sip password used in authentification

CallerNumber: usually the same as username. If left as blank, then the server use the actual caller username.

Credit: account balance. When it reach 0, then we switch to the next account if any

DateEntered: record insertion date

LastUsed: the date-time when the server was routed some calls with this account

ProxyID: to which proxy the account belongs

Enabled: set to 0 to disable the usage of this account

SubsFails: the number of subsequent wrong calls with this account. If subsfails will reach a predefined value (30 as default), it means that there is some problem with this account or the money/time limit have been expired, and the server will switch to the next account if any

4.3.3. Groups

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

SIM Packets

Users

Gateways

Traffic Senders

These groups then can be used to simplify your routing and billing.

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 attacker), than that IP address will be banned for a time period and the incoming messages from that IP will be silently dropped.

Users and devices will be allowed to access the system (and create new dialogs) only if they pass basic authorization which can be set from MManage -> Users and Devices -> Edit tab.

For IVR access the server will authenticate the actual end-user based on the A number or will request a PIN code.

Basic authorization

Dialog authentication can be performed in the following ways:

-Open Relay: if you set the NeedAuth to 0 for a user, then your server becomes an open relay (this is forbidden by the “enforcestrongauth” global config by default)

-Authentication based on IP address: for this you have to set NeedAuth to 1 and enter the peer IP address in the AuthIp field (can be a list of ip address separated by comma). Instead of IP address you can also use a domain names here.

-Authentication based on tech prefix: this is mainly used in h323 network. Set the NeedAuth to 2 and enter a valid techprefix for the user (which is usually a traffic sender)

-IP and techprefix: NeedAuth must be set to 3. The “TechPrefix” and “AuthIp” fields must be set correctly

-Username/password authentication: usually for your sip endusers. NeedAuth must be set to 4. Username and password fields must be accordingly

-Authentication based on username: A number authentication. NeedAuth must be set to 5 and with a valid username

-IP and port based authentication: gives you better security than just IP authentication and also it is useful when you have more traffic sender from the same domain. NeedAuth must be set to 6. Port and IP have to be set accordingly. (port is stored in the callsigaddr field in tb_users. You need to edit it if needed)

-Username and IP: both username and authip must match

*SIP endusers are usually authenticated based on username and password.

*Traffic senders (carriers) are usually authenticated based on IP address.

Access numbers

Access numbers are special users. You will have to create them like usual users but their ivrid have to be set to a valid campaign id. (this is then linked with an IVR script)

For callback access you also need to set the “iscallback” user field properly. Read the “callback” services for more details.

A number authentication

For calls from traffic senders the server can try to authenticate the caller as an enduser if the “anumberhandling” option is 2,3 or 4 (by default it is set to 3). More details in the IVR authentication section below.

IVR authentication

For IVR calls the server will do a “callingcardauth” global config option based authentication.

Please note that in this case the caller device is already authenticated based on basic authorization settings. The IVR needs to find an enduser to allow further operation, like call forward.

The server can authenticate the user based on the following methods:

Ø ANI/CLI authentication: if the CLI is known and this method is allowed.

A number authentication can be used to try user authentication for a call coming from a traffic sender. If user is found with the actual A number then the caller will be authenticated as the enduser, otherwise will be authenticated as traffic sender. In this case you can require a PIN number from the user.

The A numbers are usually extracted from the “From” field of the incoming SIP INVITE.

Don’t enable A number authentication if you don’t trust the traffic sender or there is a possibility that the A numbers are not received correctly.

Configuration options:

anumberhandling global configuration

· 0=disabled

· 1=only add

· 2= only accept

· 3=add and accept (default)

· 4=only a number access (no pincode request)

anumberhandlingforrouting global configuration

· 0=disabled

· 1=disabled

· 2=yes, but autoturnoff if not used for a while

· 3=always yes

enableanumberlookup per user configuration. You need to set it to 1 for traffic senders to enable or 0 to disable.

A numbers can be also registered by the users on a web interface or by sending an SMS in the proper predefined format.

Ø PIN (calling-card) based authentification:

When the A number is not known or the A number based authentication is disabled, the IVR have to ask the user for a valid PIN code.

This can be done by the CallingCardAuthentication IVR action.

After the server collects the DTMF digits it will lookup the database for a valid user entry. The authentication can be based on username, password or username+password or depending on the “callingcardauth” global config option which can have the following values:

· 0=all combinations with minlength check (default)

· 1=callingcard username

· 2= callingcard password

· 3= callingcard username+password

· 4=any username

· 5=any password

· 6=any username+password

· 7=any username+password or username+pin

· 8=username for callingcard and username+password or username+pin for other users (default)

· 9=pin

· 10=password or pin

· 11=all combinations

· 12= all combinations with minlength check (default)

When using the pin field based authentication, make sure that user has valid pin codes set in this field (when the users are automatically generated, the pin is set to be username+password).

User rights

User rights can be further restricted by several configuration option.

The most useful tool for this is the routing table. You can define were a certain user or a user group can initiate calls.

The following restrictions can be applied per user:

Allowedusers: list of the users or groups (prefixed with 'g') that is allowed to call the user. This can be used to restrict the access to an access number for example.

AllowedPartners: comma separated list of allowed partners and traffic senders. ‘*’ will allow all. You may restrict the access on gateway or simpacket level instead of setting it for all simcards separately. Try to use the packet “allowedpartners” setting and leave it as ‘*’ for the simcards!

Enabledprefixes: can be one prefix (with any length) or a list of prefixes with 3,4 or 5 digit separated by comma.

Can be used for traffic senders and gateways too. No need to setup a separate routing pattern if you use this restriction.

EnabledTechPrefixes: enabled techprefixes for the specified gateway (3 digit length numbers separated by comma)

BlockPrefixes: list of called prefixes that will be blocked for the user (techprefix will not be considered here). Numbers listed here must have 7 digit length and separated with comma.

MaxLines: max concurrent calls allowed (separate value for peak or offpeak)

Maxmonthlycredit: max allowed credit/month even if the user is postpaid

Maxmonthlycreditend: max Maxmonthlycredit (because we increase Maxmonthlycredit by maxmonthlycreditinc every month if the user was active)

Onlylocalaccess: traffic sender traffic will not be forwarded (can call only local users from tb_users and tb_numbers)

Maxmonthlycreditinc: determines how much money we add to Maxmonthlycredit every month

Access Rights: specify wich fields are allowed for the user in the VPC application

0: simcard and traffic sender fields are not shown

1: simcard related fields are not shown (simid, packetname)

2: traffic sender related fields are not shown (name, username)

3: all fields are shown

Global configuration options:

MAXSPEACHLEN: max allowed call duration in sec

allowedusers: max ring time in sec

callmaxwait: max waittime allowed for operators between calls (for administrative purposes)

enforcestrongauth: enforce authorization and strong passwords

More rate limit settings can be found in the “security” and “billing” related sections.

Try to avoid prioritizations by users, gateways, simpackets or channels (absolutepriority, priority, allowedpartners, prioritypartners, etc)

Almost all kind of configuration can be set up by using only the “routing” form.

LDAP, Radius or authentication via external database or API can be also added.

4.3.6. DID numbers

DID (Direct inward dialing) is a feature for routable static/dynamic numbers. Endusers can be reached directly by calling DID numbers from outside networks and DID numbers can be also used as a CLI (display number/A number) for outgoing calls. It might be used to share a SIP trunk among one or multiple users.

DID numbers can be acquired from carriers (for example the carrier where you are otherwise send the VoIP traffic), specialized DID providers such as didx: https://www.didx.net/ or other sources. These numbers can be assigned manually or via API. (integration needed with your did provider for this functionality). The numbers then can be stored in the tb_telnumbers table (Phone numbers form in MManage) and then manually or automatically assigned to users. (If enabled, on new user signup the user can select a DID number if any).

In the mizu servers you can manage DID on multiple levels.

Ø Assign one DID per user

This is the simplest and more robust usage, recommended if you have enough DID’s to assign to all your (business) users.

Just set the DID as user Username.

If for some reason you don’t wish to use DID as username (for example if DID is assigned later) then you can use the OtherNumber field to assign it to the user. The server will automatically accept calls either to username/othernumber/telnumber/shortnumber. For outgoing call it will also guess the best one to use from these fields (or it can be set explicitely by the replacecalleroncalls global config option)

Ø User sign-up from the web portal

You can configure the enduser web control panel so the users can get a DID number during sign-up.

Use the following configuration options:

o autogeneratenewuseraccounts: 0=no,1=auto generate random,3=auto select from tb_telnumbers,6=user select from tb_phonenumber

o autogeneratedid: 0=no,1=auto generate random,3=auto select from tb_telnumbers,6=user select from tb_phonenumberx

o allowenduserdidedit: allow enduser to edit its own telnumber field 0=no,1=yes for resellers,2=yes for endusers

Ø Assign multiple DID per user

You can use the othernumber list for this (tb_users_othernumbers). The same DID can be even assigned for multiple users. In this case the incoming call is routed to the “best” user (Best effort: user online, not in call, etc).

Ø Contact list

DID numbers can be also used to be assigned to users contact lists if they are listed as Shared DID’s in the users table. In this case the DID numbers can be shared and will serve multiple purposes:

o Incoming call from user to a DID in its own contactlist: call will be routed to the contact (username or phone number, which is “best

o Incoming call from contact (username/phone number) to assigned DID: call will be routed to user (to which user the contact belongs)

o For outgoing calls the A number will be also set accordingly or after the rules discussed above

Ø Shared DID

For shared DID you will have to create users with the DID numbers (username set to DID number, shared did option checked) and then these DID numbers can be used by multiple users in the same time. These will ease the access to users favorites from other networks (calling via third-party servers or via the IVR).

Endusers can assign their contacts (internal user or external phone number) to these DID numbers from webportal phonebook page.

To enable/disable this feature, you might explicitely set the feature_shareddidnumbers option to 1 (or set to 0 to disable). The default value is -1 which means that will auto turn to 1 of there are shared did numbers in the system (detected at startup, reload and nigtly)

If the softswitch is used by multiple companies then you can set the BelongsToCompany field to separate the DID numbers by companies.

For incoming call to a shared DID the call will be routed to the “best” user or outbound number (Best effort. The user who have called last time the current caller). You can also use share DID’s to assign a local number to called users or outbound numbers (“Quick Call” feature).

For outgoing calls a DID number will be also assigned as the A number.

Data:

Users contactlist are stored in tb_speedial:

o userid: link to “main user”

o num (any number assigned to this contact -Phone1)

o uphone2 (any number assigned to this contact -Phone2)

o uname (any user name assigned to this contact -Username)

o udid (the shared DID)

Usage:

o Add a few DID number from the “Users and devices” form. These are like normal endusers but their username is a DID number and the “Shared DID” option is checked on the “Functions” tab (this way the “ispublic” field will be set to 4 for these numbers/users)

o Set the “feature_shareddidnumbers” configuration option to 1 (the default is -1 which means that will be automatically enabled once you have added a few DID numbers, otherwise automatically disabled). You can toggle this from the ”users and devices” form “functions” tab “Shared DID” option.

o Once this is done, users can assign DID numbers for their Phonebook entries from the web enduser interface. (stored in the “udid” field in the “tb_speeddial” table). This is optional since the numbers can be found also based on the CDR records (last called numbers)

o Once a DID number is dialed, the following lookup procedure takes place:

Shared DID lookup procedure:

o The calls can come from the internal netword (a SIP endpoint) or from external (from PSTN via a traffic sender). The server will identify the caller via SIP authentication, A number authentication or PIN authentication via IVR. If the feature_shareddidnumbers is set then the server will do the following lookups (in this order):

o incoming call from any enduser to a shared DID in its own contactlist -> call will be routed to the contact phone or name (main user -> contact)

o incoming call from any contact (did, phone or name) to the assigned DID -> call will be routed to the main user (contact-> main user)

o incoming call from any to a shared DID which is found in last 2 hours cdr’s -> route to user who was called this did last time if any (any -> main user). So if a shared number is used for a call, the called person can call back to CallerId and will reach the best suitable contact.

o incoming call from any contact (did, phone or name) -> call will be routed to the main user (contact-> main user)

o incoming call from any to a shared DID which is found in last day cdr’s -> route to user who was called this did last time if any (any -> main user)

These lookups are flexible, so the caller/called/did might be found both with and without IEC or country prefix (+/00/country prefix).

Ø Lookup called user on fix DID

In some circumstances you will receive all calls from devices with the same or invalid destination number. For example you might have a VoIP-GSM gateway forwarding all calls with the target set to its phone number assigned to the SIM card or configured by the administrator.

In these circumstances the target user might be determined by a best match using the A (caller) number as previously described Shared DID procedure (looking at users contact list or last called numbers).

You can enable this from the ”Users and devices” form “functions” tab “B number lookup” option (This will set the anumberlookup field to 10 or 11).

You might also set the replaceanumwithdid after your need: -1=auto (default),0=no,1=shareddid,2=companydid,3=cdr,4=all,5=4+extended cdr search

Ø tb_telnumbers

This table can be used to store the phone numbers but also for special DID number storage. Editable from “Phone numbers” form.

Fields:

· id: auto increment db id

· datum: record creation date (number added date)

· telnumber: the phone number

· ttype: 0=def,1=normal,2=did,3=smsdid,other=other type

· free: 0=allocated,1=free (not allocated),2=locked,3=temporary locked

· useddate: date when it was assigned to user

· comment: any notes

· location: not used

· lockeddt: number preallocated at sign-up with the getphonenumber API

· gatewayid: set to SIP server ID if number has to be used only with this SIP server

· userid: number was last used for this user (trying to use the same number with the same user)

Terms and Settings:

-DID: Direct inward dialing (DID) or called direct dial-in (DDI) is a telecom service to share a single SIP trunk among one or more users

-ANI/CLI authentication: Automatic Number Identification/Calling Line Identification

-Toll free: is a special telephone number, in that the called party is charged the cost of the calls by the telephone carrier, instead of the calling party. This can be configured as a normal access number (enduser) and eventually with higher billing (because we will be the billed party in this case)

-local DID number: normal access numbers. Usually you will have separate DID numbers for different regions to minimize enduser costs

-callback: DID or toll free number configured as enduser with iscallback set to the required IVR

-ANI callback: same as callback with User-ID based authorisation (A number)

-Virtual Numbers (DID): "real" phone numbers allocated for users. You have to buy DID numbers from CLEC or any other service provider like didx.net

TelNumber: sip telnumber.users can be contacted if we call there username or telnumber

Username: the most important field. Used for authentification and also as a DID number. This field is unique and cannot be empty.

ShortTelnumber: sip short telnumber (for example if several users has the same BelongsToCompany field)

DisplayName: how the user will be displayed. Can be null

More than one DID or ANI number can be assigned for one user. For this the tb_users_othernumbers table is used where the type field is 0 for DID numbers and 1 for ANI numbers.

autogeneratenewuseraccounts; //0=no,1=auto generate random,3=auto select from tb_telnumbers,6=select from tb_phonenumber

autogeneratedid; //(new) 0=no,1=auto generate random,3=auto select from tb_telnumbers,6=select from tb_phonenumberx

allowenduserdidedit; //allow enduser to edit its own telnumber field 0=no,1=yes for resellers,2=yes for endusers

feature_shareddidnumbers: -1=auto (def), 0=no,1=yes old,2=yes new,3=yes new and old, 4=also check last calls, 5=extended search, 6=extreme

shareddid_checkcontactlist: //-1=auto (def) ,0=no,1=yes old,2=yes new,3=yes new and old

shareddid_checkcdr: -1 (def) =auto,0=no,1=yes,2=yes extra

checklocaluserforshareddid = 1; //0=no,1=yes (def)

replacecalleroncalls: 0=no,1=default checks (best num; default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good num, 6=check minassertedidentitylen,7=with phonenumber,8=anonymous

replaceanumwithdid: -1=auto (def) ,0=no,1=shareddid,2=companydid,3=cdr,4=all,5=4+extended cdr search

forcedcallernidentity:-1 (auto, def) , user and global setting 0=no,1=default checks (best num; default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good num,6=check minassertedidentitylen,7=with phonenumber,8=anonymous

identityrewrite/identityforward: user setting to replace client->callernumber (controlled by config.identityrwmode)

identityrwmode: 0=no rewrite, 1=basic, 2=conform sip specification (identity; def)

sendidentity: 0=never,1=no (def),2=sometimes,3=always

configallowusernumbertopstn: -1=auto, 0=no,1=yes if phone number, 2=always (send call to outbound if user is offline)

cli:

user setting

0: forward always (forward asserted as normal number always!)

1: normal handling (forward asserted as normal number) -default

2: forward as asserted identity always (forward identityrewrite asserted)

3: forward as asserted identity only to trusted domains (forward identityrewrite asserted)

4: normal hide (no idenityrewrite forwarding)

5: force hide (no asserted identity too!)

minassertedidentitylen:,7=with phonenumber,8=anonymous affects only P-Asserted-Identity; will owerwrite any cli settings. default is -1

didhandleruser: a globally configured number where incoming calls to DID will be routed if no user match (can be a receptionist or an IVR)

globaldidout: a globally configured number to set the A number to this for all calls (should be used only by small business owners)

Incoming calls can be checked agains the tb_telnumbers table with the v_check_localnum to check if the target is a local number (even if it is not in the tb_users table).

You can preallocate a number to a user at sign-in with the getphonenumber API.

Example: http://11.22.33.44/mvapireq/?apientry=getphonenumber&authkey=8725436&count=5&now=555

You can assign a did to a user in the following ways:

-use it as the “username”

-set the “telnumber” field

-add it to tb_users_othernumbers table (if you wish to assign more than one did to a single user)

4.4. Routing

A quick tutorial can be found here.

4.4.1. Dial patterns

The “dial patterns” terminology is not used with the mizu voip server. You can apply the number rewrite rules by the following ways (starting from simple to more complex rewrite rules)

1. Number normalization: Opent the “Configurations” form and search for the “normalize” string to list all related settings.

2. These settings can be used for basic number “normalization” to remove strange characters (like new line) and to remove IEC code. By default this is set to remove the common international escape codes (00,+). To turn this off, change the followings:

a) set cfg_normalizenumbers below 3 (2 should be good)

b) set normalize_localpx to 0

c) set “normalize_clean“ value below 4 (3 should be fine)

3. Tech prefix: tech prefix related operation should be done by using the “techprefix” box in the “Users and devices” form. Set this for the “SIP servers” where a specified tech prefix needs to be sent or set it for the “Traffic sender” when you receive the traffic with a techprefix from some routes.

4. Prefix rules: this is used for simple prefix add/remove operations. (discussed below)

5. Dial plans: you should use this option if you need full control

4.4.2. Firewall

The firewall rules are checked also at transport level so this is the most effective way to block some unwanted traffic sender.

With the firewall you can block source IP addresses and caller user names (or CLI’s).

For IP address rules, just enter the source IP address as the source.

For caller user rules, prefix the name/number with U:. For example to block user ‘hacker’, enter ‘U:hacker’ as source.

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

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

Note:

Make sure to do not delete the * - 1 rule.

If the * -1 rule exists, then it acts as an usual firwall, blocking the sources with addrenabled set to 0.

If the * -1 rule doesn’t exists, then it will allow only sources with addrenabled set to 1 and all others will be blocked!

Be avare of IP address spoofing. Some attackers are capable to falsify the source IP, thus your security should not depend only on source IP filtering (additionally you should also use SIP digest authentication or at least a tech prefix even for trused traffic senders)

4.4.3. Normalize numbers

By default the server will "normalize" all numbers. This means that it will clean the numbers from garbage characters, sql injection attacks and might remove/add IEC/CC/NEC prefix based on the circumstances and global configuration (international escape code, country code).

If left with these default settings, you will have to deal with this normalized number format for all the call processing including routing and billing.

This behavior can be quickly changed by the normalizedef setting for which you can assign the following values:

-1: default, recommended (mostly like 2) [validateinput=3; normalizenumbers=2; normalizecallednumbersnec=-1;]

0: don't touch (dangerous) [validateinput=0; normalizenumbers=0; normalizecallednumbersnec=0;]

1: minimal (clean the numbers) [validateinput=1; normalizenumbers=1; normalizecallednumbersnec=1;]

2: basic (clean the numbers) [validateinput=2; normalizenumbers=1; normalizecallednumbersnec=1;]

3: normal (remove IEC like + and 00) [validateinput=3; normalizenumbers=2; normalizecallednumbersnec=1;]

4: strict (might add CC and rewrite NEC) [validateinput=4; normalizenumbers=3; normalizecallednumbersnec=2;]

5: extra (full input checking and number rewrite) [validateinput=5; normalizenumbers=4; normalizecallednumbersnec=3;]

It is recommended to leave this setting with its default -1 value and you should change it only to have full control on number rewrite rules (set to 1) or if you wish to set a strict checking (set to 3)

Usually you should leave this (and the other related global config options below) with the default values and you might add your own special number rewrite rules by the "Rewrite" module if you need so.

If you want more control for the rules, then you should leave it with the default setting of -1 and change the global config options below.

If you want full control for the rules, then you should set it to 2 (or 1) and use the "Rewrite" module to add your rules.

Other global configuration options related to number "normalization" and rewrite are the followings:

outgoingprefixremove:

List of prefixes to be removed from the called number for outgoing calls separated by comma

For example +,00

outgoingprefixremove_maxlength:

Will apply the “outgoingprefixremove” rule only if the number length is at least this number inclusive

outgoingprefixremove_minlength:

Will apply the “outgoingprefixremove” rule only if the number length is less than this number exclusive

outgoingprefixremove2:

Single prefix to remove but within the below rules.

outgoingprefixadd:

Set any string prefix which will be applied for called numbers for all outgoing calls.

For example +.

If you need to change the prefix only to one direction, then use the "Rules".

outgoingprefixadd_minlength:

Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number length is at least this number inclusive

outgoingprefixadd_maxlength:

Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number length is less than this number exclusive

outgoingprefixadd_ifbegin:

Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number begins with this

outgoingprefixadd_ifnotbegin:

Will apply the “outgoingprefixadd” and “outgoingprefixremove2” rules only if the number NOT begins with this

All the above can be applied also when call arrives by setting the incomingprefix settings.

normalizenumbers: how to normalize

0=no,1=basic,2=normal,3=more (hu/ro),4=extra

default is 2

normalizecallednumbersnec: NEC normalization (National Destination Code)

-1=depends on normalizenumbers and normalize_localpx, 0=no,1=yes,2=extra

default is -1

loadcallednumberfromto: 0=autoguess,1=no (from first line),2=yes (from to)

rewriteinternalcalled: rewrite the called numbers for calls to endusers

0=don't set,1=don't rewrite,2=client to as received,3=client to username,4=client to telnumber,5=client to best if match,6=all to as received,7=all to username,8=all to telnumber,9=all to best if match

default is: 7 for servers and 6 for gateways

forwardcalled: what to use for request URI and To fields: 0: no (old server behaviour; callednumber decided at routing), 1: forward as received, 2: forward callednumber, 3: forward callednumber_header, 4: forward callednumber_to

default is: 0 for servers and 1 for gateways

forwardcalledtofs: same as the above forwardcalled but used only if the called party is on WebRTC

validateinput: how to clean the numbers

0=no,1=basic without sql check,2=basic with sql, 3=normal,4=more,5=extreme

default is 3

cfg_minnormalizelength: minimum length of the number to consider for extra normalization.

default is -1 which means that it depends on normalizenumbers (if normal then set to 5)

checknumnumbers: reject call if called is not a phone valid number

0=allow any calls; 1=allow only phonenumbers from H323; 2=allow only phone numbers for all

default is -1 which means that it depends on normalizenumbers (set to 1 if normalizenumbers is normal)

checknumport: check number portability rules

-1=autoguess,0=not check,1=check for changed prefix,2=check for changed number,3=check for changed domain,4=check for changed server id,9=check all

default is -1

The CC/NEC rewrite depends on the followings:

caller CC/NEC

country: country (2 chars)

iec1,iec2,iec3: international escape codes

countryprefix: default country prefix (country code)

prefix1,prefix2,prefix3: national destination codes

cfg_mobileprefixes: list of common mobile prefixes (useful for callenters to differentiate landline and mobile calls)

Deprecated settings (don't use these anymore):

normalize_localpx: replaced by normalizecallednumbersnec

setcalledtosipusername: replaced by rewriteinternalcalled

normalize_clean: replaced by validateinput

normalize_checksp: replaced by normalizecallednumbersnec

Example:

The following settings will normalize incoming numbers (from both national and international format) to international number format then will add 00 when forwarding to an outbound route (to a VoIP carrier):

Settings:

normalizedef: 3

normalizenumbers: 3

incomingprefixremove: 00,+

incomingprefixadd: 4

incomingprefixadd_ifbegin: 07

outgoingprefixadd: 00

outgoingprefixadd_ifnotbegin: 00

Example input dialed number:

+40721234567 OR 0040721234567 OR 40721234567 OR 0721234567 OR 0721234567

IEC: 00 or +

Country code: 40 (Romania)

NEC: 72 (Vodafone)

Normalized number:

40721234567

Outgoing number:

0040721234567

4.4.4. Caller ID Settings

On Caller ID we mean the number or name displayed for the called party which is sent by one of the followings sip headers:

-From header (URI and displayname)

-Contact header (URI and displayname)

-Authentication username

-Identity headers: p-asserted-identity, p-preferred-identity, remote-party-id

-Privacy settings: "privacy" header, "anonymous"

The caller-ID display is specified in the SIP and other RFC's but at the end it is up to the called party device to what caller-id to display (it can be loaded even from a local store instead of from the SIP messages sent by the caller party)

The Caller ID can be influenced by the following factors:

-the SIP message received by the client as described above

-global number normalization settings (see the "number normalization" section)

-global caller id related settings (discussed below)

-caller and especially the called user settings such as the techprefix

-Prefix Rules settings (this is already deprecated. Use "Rules" whenever possible)

-Dial plan SQL (this is already deprecated. Use "Rules" whenever possible)

-Rules (see the "Rules" section)

Settings:

The easiest way to influence the caller-id is the replacecalleroncalls setting (global setting and/or per user setting):

replacecalleroncalls:

(user and global setting)

//0=no,1=default checks (best num; default),2=dbusername,3=telnumber,4=bestnumber,5=first good num,6=check minassertedidentitylen,7=with phonenumber,8=anonymous, 9=from header,10=contact header,11=Remote-Party-ID header, 12=best from client, 13=best from all, 14=called user username, 15=called user telnumber

Default is 13.

forcedcallernidentity:

user and global setting

//0=no,1=default checks (best num; default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good num,6=check minassertedidentitylen,7=with phonenumber,8=anonymous

affects only P-Asserted-Identity

will owerwrite any cli settings

default is -1

realcallernumber

just a routing variable

client->callernumber = realcallernumber;

client->origcallernumber = realcallernumber;

forcedcallernumber:

just a routing variable set by replacecalleroncalls and used by the client ep later

overwrite the client from number

forcedcallernidentityumber:

just a routing variable set by forcedcallernidentity and used by the client ep later

overwrite the client identity

identityrewrite/identityforward

user setting

replace client->callernumber (controlled by config.identityrwmode)

//config.identityrwmode = 2; //0=no rewrite, 1=basic, 2=conform sip specification (identity)

//config.sendidentity = 1; //0=never,1=no,2=sometimes,3=always

cli:

user setting

0: forward always (forward asserted as normal number always!)

1: normal handling (forward asserted as normal number) -default

2: forward as asserted identity always (forward identityrewrite asserted)

3: forward as asserted identity only to trusted domains (forward identityrewrite asserted)

4: normal hide (no idenityrewrite forwarding)

5: force hide (no asserted identity too!)

forwardauth:

user and global setting

confing.cfg_forwardauthentifications = 0; //0=no (default),1=yes,2=yes with username as callername, 3=yes with phonenumber as callername, 4=yes with username as authname too, 5=yes with phonenumber as authname too, 6=replace authorization with username but leave the A number intact, 7=replace authorization with sipphonenumber

can rewrite client auth_username, auth_password, callernumber

rewriteanumber:

user setting

simply replace client->callernumber

set to anonymous to disable the caller-id

cutanumber:

user setting

simply replace client->callernumber prefix

replacecalleronforward

global config option

used only for callforward

//config.replacecalleronforward = 9; //0=no (default),1=yes,2=yes with username as callername, 3=yes with phonenumber as callername, 4=yes with username as authname too, 5=yes with phonenumber as authname too 9=auto

parseidentity

global config option

0=no at all, 1=normal,2=rewrite caller number,3=rewrite callername also

default is 1

parsesipdisplayname

global config option

0=no,1=callername,2=displayname,3=can be used for auth

default is 1

userealphonenumbercallerid: 0=no (default), 1=yes: will overwrite cfg_replacecalleroncalls! (will try to find a phone number to use)

useorigcallerforeu: 0=no (default), 1=yes: will overwrite cfg_replacecalleroncalls! (if call is routed to enduser, then will use normal caller)

replacecalleroncallsusercheck: default is 1

replaceanumwithdid: -1=auto (default) ,0=no,1=shareddid,2=companydid,3=cdr,4=all,5=4+extended cdr search

Also see the DID numbers section for other possibilities.

See the How to set the Identity header for more details about the Identity SIP headers.

4.4.5. Rules

Using the “Rules” for you can handle and rewrite almost all SIP fields based on any condition, esepecially the caller and the called number.

This form can be used to create both simple and very complex rules. Hold the mouse over the controls to get a context sensitive help.

Usage:

1. Click on the “Add” button to add a new rule

2. Name the new rule as you wish

3. Run as: it is usualy fine if you leave the “Auto guess”, however you can specify it more exactly in certain conditions

4. Specify the conditions when this rule is executed (for example you might have to reformat the called number if the call is sent via a specific carrier; in this case use the CalledID to select the carrier)

5. Data: specify which data do you wish to load and work with it (for example the callednumber)

6. Check: specify additional conditions when this rule is executed (now you can examine the “data” loaded in the previous step)

7. Action: specify what you wish to do with the data

8. Set: specify how to wish to save back the result (usually “same as loaded data” since most of the case you will just wish to modify a field such as the called number)

Additionally you can modify some global configuration options to modify the caller/called number. These are described below:

4.4.6. Prefix rules

You should instead use the “Rules” form mentioned above.

You can rewrite prefixes before they arrive to the routing by entering your preferences here.

The Mizu routing engine will accept only 3 digit length techprefixes or no thechprefix, so you must convert them here if your traffic sender will send the traffic with techprefix that are not three digit length.

Example 1:

To set up a rule which defines that every incoming number from ip 111.111.111.111 on H323 if begins with 1234 must be rewritten to begin with 56. Number 123499999 will be rewritten to 5699999.

If the “RewriteFrom” is emtly, then the “RewriteTo” fill be inserted before the number

Example 2: To remove 011 before all dialed numbers:

Protocol: 0

Type: 1

Value: empty

Rewrite from: 011

Rewrite to: empty

Number to rewrite: Incoming Called (0)

Example 3: To replace 06 with 446 for all SIP calls coming from 192.168.1.8:

Protocol: 1

Type: 2

Value: 192.168.1.8

Rewrite from: 06

Rewrite to: 446

Number to rewrite: Incoming Called (0)

Example 4: to handle the hungarian roaming prefix: 08 + SK + BK + NSN +SN you have to set the following values:

prefixrewritestr: 08X…

prefixrewritefrom: 9

prefixrewriteto: 36

4.4.7. Dial Plans

You should instead use the “Rules” form mentioned above.

During the routing process you can modify the caller and called number with the dialplan stored procedure (v_dialplan)

v_dialplan can be called several times during the routing depending on the checkdialplan1-4 global config option.

For CLI and A number rewrite it is enough to set checkdialplan4 to true (after routing) and check/rewrite the numbers using the LIKE operator (wildcards are enabled).

Input parameters:

@calledat TINYINT, /*1=first check, 2=after authentication, 3=before routing out, 4=after routing out*/

@protocoll TINYINT, /*0=SIP, 1=H323, 2=GSM, 3=Other*/

@fromip varchar(22), /*caller ip address*/

@fromport SMALLINT, /*caller port*/

@callerid int, /*caller device database id from tb_users*/

@callernumber varchar(35), /*caller number or sip username*/

@callername varchar(35), /*caller name or displayname*/

@calledid INT, /*called device database id from tb_users*/

@origcallednumber varchar(35), /*called number as received*/

@techprefix VARCHAR(10), /*called number tech prefix*/

@normcallednumber varchar(35) /*normalized (changed) called number*/

The stored procedure can be called at different routing stage:

1: before authentication

2: after auth

3: before routing

4: after routing

This means that if a number has efect on authentication then you can rewrite it on stage 1, but if you need to modify the called number only for the b-leg call then it is better to call this function only at stage 4

Some of the input values are not set at earlier stage. For example when calledat is 1 then the callerid will be 0 because the caller is still not known at this stage.

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

Accepted output values:

-emty string: no effect

-_REJECT: will disconnect the call

-_REJECTPLAY,filename: play a file and disconnect the call

-callednumber: will change the called number

-callednumber,calleddialed,origcallednumber,techprefix,callernumber,callerid,calledid

Field details:

-Callednumber: will be used for further routing decisions, for billing purposes and it is stored in CDR record

-Calleddialed: will be used only for b-leg

-Origcallednumber: can be used for further routing decision (mostly not used)

-Techprefix: can be used for further routing decision. Deprecated after version 3.5

-Callernumber: can be used for further routing decision and stored in CDR record

-Callerid: you can modify the caller user if you change this parameter

-Calledid: you can modify the called user if you change this parameter

sql help:

sql tutorial: http://www.w3schools.com/SQL/sql_intro.asp

stored procedures: http://msdn.microsoft.com/en-us/library/aa174792(SQL.80).aspx

string functions: http://msdn.microsoft.com/en-us/library/aa258891(SQL.80).aspx

like operator: http://msdn.microsoft.com/en-us/library/aa933232(SQL.80).aspx

example:

DECLARE @ret_callernumber varchar(35)

DECLARE @ret_callednumber varchar(35)

SET @ret_callernumber = @callernumber

SET @ret_callednumber = @normcallednumber

IF (@calledid = 456 and @ret_callednumber LIKE '1_23%')

BEGIN

SELECT '_REJECT'

RETURN 1

END

IF (@calledid = 457 AND (LEN(@ret_callednumber) < 5 OR ISNUMERIC(@ret_callednumber) = 0))

BEGIN

SET @ret_callednumber = '1234567'

END

IF (LEN(@ret_callednumber) > 6 AND LEFT(@ret_callednumber,3) = '061')

BEGIN

SET @ret_callednumber = '36'+SUBSTRING(@ret_callednumber,3,35)

END

IF (@ret_callednumber LIKE '5222%')

BEGIN

SET @ret_callednumber = SUBSTRING(@ret_callednumber,5,35)

END

SELECT @ret_callednumber+’,’+@ret_callednumber+','+@ret_callednumber+',,'+@ret_callernumber

RETURN 1

If the stored procedure doesn’t run successfully, then it will have no effect.

4.4.8. Blacklisting

List the blacklisted target numbers on the selected time interval and direction.

This query will generate high server load. Use it only in off-peak time if possible

4.4.9. Access Lists

You can define the “Blacklist” and the “Whitelist” here for the called numbers. The listing will be used in the routing depending of the actual packet “filtering” setting. Check section 4.5.1 for details regarding filtering.

Note: these filtering applies to targets and not for the source. If you wish to filter the call source, then use the caller banning module as described here.

Global setting to enable/disable black list: numfiltering:

-1=autoguess (default. Will be auto set to 0 if there are no blacklist entries or to 3 if there are)

0=nothing (disable)

1 =only from h323

2=only from sip

3=all (enable)

Blacklist method: blacklisttype:

-1=autoguess (default. Will be auto set to 0 if there are no blacklist entries)

0=nothing (disable)

1=phone number as string or prefix using tb_blacklist (slower)

2=phone number as number using tb_blacklist_int (very fast even for millions of records)

3=both

Global setting to enable/disable white list: checkknownnumbers:

0=no (disable)

1 = autoguess (default. Will be auto set to 0 if there are no blacklist entries or to 3 if there are)

2=yes (enable)

Database tables:

White list: tb_knowngoodnumbers

Black list: tb_blacklist

Blacklist fields:

-telnumber: country code + operator + telnum

-sure: levels

tb_blacklist.sure:

0 –probably good numbers (reput)

1 - not sure (holes)

2 - probably wrong number (monthly autodisabled)

3 - very sure (roaming numbers)

6 – always block (not only to gsm)

tb_packets.filtering: determines how we check the blacklist and the known numbers

0 -no filtering

1 - filter if very sure blacklisted (tb_blacklist.sure >=3)

2 - filter if probably blacklisted (tb_blacklist.sure > =2)

3 –filter if suspicious (tb_blacklist.sure > =1)

4 - filter if present in blacklist (any tb_blacklist.sure)

5 - filter if not a known number

6 - filter out if no sure known number

Blacklist can be also built automatically as defined by the builddynamicblacklist global config option:

-1: auto (will auto turn to 40 if numfiltering is enabled)

0: disable

Other: minimum failed calls per day

Failed calls are checked periodically with the following minimum count to block:

-hourly: builddynamicblacklist/2

-daily: builddynamicblacklist

-weekly: builddynamicblacklist*2

-monthly: builddynamicblacklist*5

Other global config options:

blacklist_maxbcount: max count of numbers to block one time (default is dynamic based on average number of calls per day)

blacklist_minasr: minimum asr per number to block (default is 5)

blacklist_minacd: minimum acd per number to block (default is 10)

You can add a number to the black list form the “Access Lists” form “Add number to blacklist” button or by executing the following SQL from the “Direct Query” form:

insert into tb_blacklist (telnumber,reason,sure,maxtryagaincount,cantryagain,blockdays,lastblocked)

values ('TELNUMBER','COMMENT',6,0,0,99999995,getdate())

(replace TELNUMBER and COMMENT after your needs)

Block scanning

Some spammers might try to scan a number range by making calls to similar numbers (such as trying numbers from A to Z).

Blocking these attempts can be configured by the blockscanning global settings:

· blockscanning_treshold: -1: auto, 0: no, 1+: yes, max count of subsequent similar numbers. Default is 45, or 15 if option checked in the config wizard or 0 if not checked.

· blockscanning_mode: strict (permissive; will count only subsequent numbers or diff is less then 10), 2: general (will check if diff is less then 30 or if there is only single digit change. threshold calculation will be incremented by 3 for subsequent numbers). Default is 2 (general).

Smart blacklist

Will block a number after X failed attempts in Y time interval for Z amount of time.

The “number” here means the target/called numbers, not the source/caller number.

Settings:

· smartblacklist_enable: enable/disable smart blacklist. 0=no,1=on normal load only (will not run on high server load), 2=force always. Default is 0. Set to 1 to enable.

· smartblacklist_peruser: smartblacklist is per user or for all calls. 0=no (so it will check globally), 1=yes for endusers, 2=yes for all callers, 3=yes for all users with “smartbl” field set to 1 (otherwise not checked at all). Default is 1

· smartblacklist_callduration: call duration in seconds to be considered by smartblacklist //0= all calls, negative: count only connected calls, other: count only calls below this duration including not connected calls. Default is 5

· smartblacklist_callduration_min: specify only if you wish to check calls above a specific duration. For example if you wish to block users with calls between 1-3 seconds then set smartblacklist_callduration_min to 1 and smartblacklist_callduration to 4.

· smartblacklist_blockafter: number of attempts after to block the number. Default is 20

· smartblacklist_checkperiod: check calls in this period. 1 means one day, 2=two days, 0.5 means 12 hours. Default is 1 (one day). Increasing this might increase CPU usage.

· smartblacklist_blockperiod: block the number for this duration where 1 means one day. 0=not used (will block until goes out of the checlperiod range), other: will add to blacklist for the specified time. Default is 0.

· smartblacklist_voice: voice playback on call reject (name of the file)

Update old database:

ALTER TABLE tb_blacklist ADD [calleruser] [int] NULL DEFAULT (NULL)

ALTER TABLE tb_blacklist ADD [expireat] [datetime] NULL DEFAULT (NULL)

ALTER TABLE tb_users ADD [smartbl] [tinyint] NULL DEFAULT (0)

SP v_check_blakclist:

select TOP 1 telnumber,sure from tb_blacklist WITH(NOLOCK) where

@called_norm LIKE telnumber+'%' AND blocked = 1 AND telnumber is not null AND LEN(telnumber) > 0 and (expireat is null or expireat > getdate()) and (@callerid = calleruser or @callerid = 0 or calleruser = 0 or calleruser is null)

ORDER BY sure desc

4.4.10. Routing

For every time period and direction a “Routing Pattern” needs to be defined. Every Routing pattern has a list of routing directories which may be Mizu GSM Gateteways, other H323 gateways or gatekeepers, ISDN gateways or SIP proxies in priority order. Set up as much directories with the same priority order as possible so the routing engine can prioritize itself after other settings (device priority, LCR, quality,BRS)

Generic rules can be defined by setting the pattern priority lower. For example for every call that doesn’t have a specific route can be routed to a specific direction (otherwise is dropped)

There is a list of typical time definition. If none of them match your needs, the “Start-End Time” entry can be selected to specify proprietary intervals.

In Caller Prefix, you can place only one prefix.

Tech prefix can be empty string, asterisk (*) or 3 digit length number.

Called prefix can be one prefix (with any length) or a list of prefixes with 3 or 4 digit separated by comma.

routing

*Tip: you don’t need to enforce traffic sender rights by routing. The routing can be done as generic as possible for example by specifying only Called Prefixes (Leave the other direction option blank or ‘*’). Rights can be enforced by setting “Enabled Prefixes” for all Traffic Senders

Routing Configurations

Try to set up all routing rules and prioritizations using this form.

Try to avoid prioritizations by gateways, simpackets or channels (absolutepriority, priority, allowedpartners, prioritypartners, etc)

Almost all kind of configuration can be set up by using only the “routing” form

The actual priority order of your route list (right side list) will be affected by numerous factor:

-Failowering: when a device or a device/direction is in failowered state, then its priority is lowered

-Load balancing: will prioritize the direction where the last routed date time is oldest (only if the routing entries are entered with the same priority)

-LCR: the route with the lowest price will be prioritized

-BRS: the best quality/lower price route will be prioritized

These settings can be controlled by the “brs_lcr” global config option:

0=not used

1=only lcr for not gsm

2=lcr

3=brs for not gsm

4=BRS (default)

5=BRS+LCR

4.4.11. Routing workflow

Introduction

The routing in the Mizu softswitch means deciding on which active gateway, user or gsm channel should we route the incoming call from traffic senders and endusers.

The routing is influenced mainly by the following:

-device ownership and access rights (allowedpartner settings)

-routing time, direction and the selected pattern (device/packet priority list)

-various priority settings

The routing is blocked if the following conditions are met:

General conditions

syntax error in incoming number (or not known)

max call/day, max speachlength reached (licensing option)

Caller user check

the traffic sender reached their maximum channels

caller gateway, simcard or simpacket is not enabled or temporarily disabled

failed authorization (wrong originating ip, bad username or password or wrong techprefix)

Caller “CanDial” setting is set to false

Caller tb_users.enabledprefixes not match (‘*’ allow all numbers)

Check if other traffic sender has the same ip/techprefix (caller mismatch)

Routing

direction and time don’t match a routing pattern

no active device or simpacket from the selected pattern priority list

Called device/gateway checks

Called gateway(s) is not enabled, not active, temporaydisabled, allowedpartners don’t match or any other problem

Called gateway onlytestcalls not match

Called gateway enabledprefixes not match (‘*’ allow all numbers)

Called gateway blockprefixes match

Called device filtering option doesn’t allow blacklisted number level (if the incoming number is blacklisted)

gateway has testprefix but does not match

Called simpacket check (only for gsm directions)

Packet is not enabled

Caller is not listed in allowedpartners

packets.waitaftercall second not elapsed since last call

packets.filtering. blacklist/whitelist restriction (filtering option doesn’t allow blacklisted number level (if the incoming number is blacklisted))

Simcard check (only for gsm directions)

Called simcard(s) is not enabled, temporaydisabled, not ready, allowedpartners don’t match or any other problem

partner is not allowed on the simcard (allowedpartners)

the simcard is prepaid, but it doesn’t have enough credit

two subsequent calls cannot be routed to the same simcards (configurable)

there was a credit request or recharge in the simcard in the last minute

cannot request credit from prepaid card more than 5 times

maxmonthlyminutes,maxdailyminutes,maxallminutes, maxmonthlyminutespeak are reached

no report from the channel for more than 5 minutes (the gateway may have lost its network connection or power)

Routing priority order

If emergency number, than the defined emergency route has the biggest priority

Routing pattern priority (if two or more pattern overlap)

Routing pattern direction/time best match (if two or more pattern overlap)

Called gateway Globalabsolutepriority

Called gateway and simcard absolutepriority

Positive routing priority (deprioritze simpackets with negative routing priority -these are “emergency packets”)

SimPacket absolute priority partner (absprioritypartner -if set and if match the caller)

Simcard caller priority (absprioritypartner -if set and if match the caller)

Gateway absolute priority

Gateway called priority (if set and if match the caller)

Simcard absolute priority

Routing list priority/100 (differences more than 100 in priority list)

Called gateway is not failowered -value lower or higher than the current date-time (for automatic failovering)

Called gateway is not failowered for the currenct called prefix (direction)

Simcard is not failowered - value lower or higher than the current date-time (for automatic failovering)

SimPacket is not failowered

Tpercek priority (hungarian tmobile specific)

Routing list priority

Elapsed time from last call disconnect is more than 10 sec

Gateway callerpriority match the caller number

Gateway prioritypartner match

Simcard priority partner match

SimPacket nopriority partner not match

SimPacket priority partner match

Gateway priority (simple)

Simcard priority (simple)

Simcard minimum monthly speechlength not reached

Simcard minimum daily speechlength not reached

Simcard desired monthly speechlength not reached

Simcard desired daily speechlength not reached

Simcard todayspeachlength desc order (simcards with more callduration has lower priority)

Simcard thismonthcallcount desc order (simcards with more callcount has lower priority)

Simcard thismonthspeachlength desc order (simcards with more callduration has lower priority)

Simcard a.creditrequestfails desc order (simcards with more failed credit requests with lower priority)

Gateway ready channels (balance calls across gateways)

Last call begin on the simcard (balance calls across simcards -simcards with the most recent calls has lower priority)

Simcard currspeachlen desc

Simcard GSM Fieldstrength

Simcard lastrectime (for randomizations)

Technical description:
Call arrive from traffic sender or enduser via SIP or H323

Check if MAXCCALS restriction reached (licensing option). Drop if yes.

Check if maxslperdayreached reached. Drop if yes.

Check if maxroutereqpermin reached. Drop if yes.

Check if the current call is a routing retry (forked calls). Drop if too much retry

Normalize caller ip addres

Check if the call was from the local SIP2H323 module. Return with the already prepared target if yes

Chech if the call was arrived from GSM gateway. (callin option). Replace caller and called after the config.

Correct the called number string if it is corrupt.

Check min/max length of the called number

Check if the incoming call is a testcall. Set the testcall flag is yes

Check and apply prefix roules (tb_pxrules – rewriting the called number)

Authenticate the caller (after username/password, ip pr techprefix). Drop the call with “no such user” reason on fail

Add techprefix if needed

Setup sip parameters if the call was arrived from sip

Normalize called number (check prefix, area code, etc). Drop if wrong number

Check if subsecvent wrong call

Check if the caller exceed its max line restriction

Check blacklist and whitelist

Check the embedded firewall

Check if caller called itself

check if called if a sipuser (Username, telnumber, short telnumber)

check the forwardalways option

check the ringgroup option

setup called endpoint if found

get time variables (peak, holiday, etc)

Get the correct routing pattern

Check routing list in priority order

If simpacket found, than Check simrouting

Drop the call if no route found

4.4.12. RADIUS

Define the radius servers, protocol and login information here. Used for authorization and billing.

4.4.13. BRS

Short name for “Best Route Selection”.

In addition to LCR (Least Cost Routing), the Mizu routing engine can take in consideration the quality of the route.

To activate BRS based routing, the “brs_lcr” global configuration option have to be changed to 4 or 5. Then the routing will check both the pricing and the routing, which you can finetune using the “BRS” form (only after you have some traffic, so the table is populated with the statics. If you would like to change the default values, you can do this only directly in the database).

Finetuning means the change of the following fields: accuracy,minprice,maxprice,minasr,maxasr,minacl,maxacl.

The rest is populated automatically based on the call statistics.

If you would like only LCR, simply set the “Quality Percent” field to 0.

If we put some directions with equal priority in the pattern, then the system will choose the routing automatically depending on price and quality, when other settings don't modify the routing (min/max minutes, gw/sim priorities, failovered directions, etc)

The server automatically calculates am „autopriority” on every route. This priority is the combination of the quality and the price. The quality is calculated as an average of daily asr/acl and monthly asr/acl. The price is calculated to pricecalcsec seconds with the given minammount and billingstep (from packet prices). The server route the traffic on the higher priority direction, BUT it will try the other routes periodically (to check if quality have changed). You can change this „next time try” setting by changing the values of TryedCount,NextTry, NextTryCount. If the best quality gateway for a route will change, then we will reset TryedCount,NextTry and NextTryCount values to their defaults. (so the server can recheck quicker)

brs

Fields have the following meanings:

-Id: database identifier. Auto increment

-Gateway: gateway id (called)

-Direction: called prefix

-QualityPercent: how much the quality will contribute to the final result. If price is very important for us, set this value lower. Default is 50%

-Accuracy: how accurate the final result will be. If we set it too high, then we probably will have only one route as the best. If we set it too low then too little discrimination will be made between routes. So, the final result (AutoPriority) will be lowered only if we have too wrong acl, asr or price.

Default is 30%. This default means that the AutoPriority will change only if price will change with 2-3 amount or asr will change with at least 15% (considering asr between 10 and 80, price between 0 and 40 and QualityPercent as 50%)

-ASRDay: last day ASR (automatically calculated every day)

-ACLDay: last day ACL (automatically calculated every day)

-ASRMonth: last month ASR (automatically calculated every month in the last day)

-ACLMonth: last month ACL (automatically calculated every month in the last day)

-MinASR, MaxASR, MinACL,MaxACL: when asr or acl reach the min value, then the line is considered very wrong. When it reaches the max values, then the line is considered very good. Must be configured manually for every direction, because the statistics will change dramatically by country

-MinPrice, MaxPrice: min-max prices/minute. set it to a very wrong price to that direction and the max value to a very good one. Calculate it with consideration to billing step and min minutes (so you must fill in as 1/1 price)

-PriceCalcSec: we estimate the price values with this value to get a gross value

-TryedCount: how much time we have tried this alternative route until now. Helps us the decide how to increment NextTry. It will grow only until 7

-NextTry: we will route calls to this route beginning with this date. Will grow exponentially until 1 month.

-NextTryCount: we will route NextTryCount calls on this route next time. ( > CurrTryCount)

-CurrTryCount: counter to know how many times we have routed in this direction

-AutoPriority: the current priority calculated from these values and from the price settings (the result)

To see how much a parameter change will modify the final AutoPriority value, you can find a demo named AutoPriorityDemo in MManage, Config menu - > Utilities. Before changing any value in the BSR table, please play a little with this demo.

4.4.14. Failowering

Mizu server and gateway will make automating failowering between outbound gateways if the “CAN_failower” and “hasfailower” global configuration settings are set to true (they are true by default).

The following failowering procedures are done by the mizu voip server:

-gateway failowering: when an outbound gateway has wrong global statistics

-direction failowering: when only a few direction (prefix) statistics are wrong on an outbound gateway
-failowering on subsequent called number
-in-call failowering (this is also called as “rerouting”)

The failowering module will collect statistics in the background and will detect if a gateway is below the predefined thresholds. This means that its priority will be automatically lowered by the routing module.

Failowering can occur on both gateway and gateway-direction level. When the ASR, ACD, etc is “wrong” for all calls trough a gateway, than the whole gateway is failowered. But there are situation when a gateway can handle most of the traffic gracefully and will fail only to a few direction (direction means 4 digit prefix). In this case only these directions are failowered (this means that even if the gateway is with high priority to these directions, other gateways will be favorized –if you have enabled other gateways in these directions). The failowering are based on ASR, ACD statistics and if there is predefined subsequent wrong calls to a direction. Once a route is marked as failowered, it will be probed time to time to check if the problem was solved. This is happening only a few times (with exponentially increased time intervals) than if the quality is still wrong, the route will be marked as permanently failowered. This routes can be reseted only manually from the failowering form if you set the MaxSubsFail, NoPriorityCount, NoPriorityCountD to 0 and the NoPriority to a date in the past.

The rules can be defined using the “Failowering” form. The table will be populated automatically after your traffic pattern.

You can check the route status also from here.

The following fields are defined:

ID: database id. Auto increment

GatewayID: called gateway or sipproxy

Direction: called direction (prefix)

MaxSubsFail: if we get more wrong calls than MaxSubsFail we failover to the next route if any

MinASR: if we get more lower ASR than MinASR we failover to the next route if any

MinACL: if we get more lower ACL than MinACL we failover to the next route if any

MinCallCount: we calculate ASR and ACL statistics only if we have MinCallCount cdr

SubsFails: current subsequent wrong calls detected

NoPriority: We have done a failover until this date. When the time elapses, we try this route again. This will grow exponentially.

NoPriorityCount: we have failovered NoPriorityCount until now because of SubsFails. The bigger is NoPriorityCount, the longer we do the deprioritization (NoPriority)

NoPriorityCountD: : we have failovered NoPriorityCount until now because of statistics

Manual: all routes will be added automatically to failover table with a minimum of quality requirements

Enabled: failowering enabled

Datum: record insertion or last modification date

Comment: why was the record modified last time (reason)

There are some conditions for the gateway and direction failowering to work correctly:

-the server must have enough call to calculate relevant statistics (this can be fine-tuned from the “Failowering” form) ; the default are optimized for medium traffic amount
-some time must elapse for a route to be marked as failowered (too aggressive settings might result in false failowering)

-you must have at least one secondary gateway/direction where the traffic can be failowered

You should not build your entire business based on the correctness of the failowering module. Outbound gateways should be monitorized on a regular interval (Statistics -> by Called gateways) and you should take remedy actions when the statistics will drop to any outbound gateway (fix the problem or remove it by removing from the routing or set as temporary disabled)

Other important failowering process is the “in-call failowering” or “rerouting”. This means that if the call is rejected by the first route, it can be immediately routed to the next route (without the caller to be disconnected)

Another failowering type occurs when there is at least two subsequent calls to one number and the first call length was below 25 seconds. This is a convenient way to detect if somebody calls a number with wrong voice quality and will call it again in a short time. These can be enabled by the configuration wizard or from the global configuration by the following options.

-maxreroute: how many time a call can be rerouted

-rerouteon: on which conditions a call will be rerouted

-reroutedisccodes: disconnect codes to be received for the rerouting

-noreroutedisccodes: define disconnect codes when there will be no rerouting

All these setting are set by default to optimal values which you can modify after your requirements.

Note: failowering will occur with increased thresholds (more slowly) if the priority between the routing directions (SIP servers) is more than 100.

4.4.15. Channel reservation

Skip this chapter if you are not using VoIP-GSM gateways.

Best quality (ASR and ACD) SIM channels can be reserved for sip or h323 originated calls.

In the sim table the reserverfor field can have the following values:

0=cannotreserve: this channel will not be reserved

1=sip: always reserve only for SIP (manually assigned)

2=h323: always reserve only for H323 (manually assigned)

3=ISDN: always reserve only for ISDN (manually assigned)

4=dynamic: can be allocated by the server dynamically (hourly check) -this is the default value

5=sipdynamic: allocated automatically for SIP

6=h323dynamic: allocated automatically for H323

7= ISDNdynamic: allocated automatically for ISDN

For every simpacket you can restrict the maximum allowed reservations by the maxalloc field. (useful to not reserve all channel from the same simpacket)

To setup the channel reservation use the following configuration values (mserver, simplatform config):

-reserveforh323: reserve capacity for h323. reservations will be disabled if less than 1

-reserveforsip: reserve capacity for sip . reservations will be disabled if less than 1

By example if you set the reserveforsip field to 5, you can be sure that 5 channels always remain free to be used by calls received with SIP protocol (H323 originated calls didn’t consume all your channels)

4.4.16. Number portability

The number portability module can be used to alter the routing if the number is ported to another operator for MNP (mobile number portability) or LNP (local number portability) reasons.

More specifically it can influence the routing in one of the following ways:

· route the call to the server specified by newdomain:newport (The fwdtootherdomains must have to be set to at least 1 for domain routing to have effect.)

· route the call to the SIP server specified by sipserverid (or by carrierid with a lookup from tb_carriermap)

· change the called number as specified by the newnumber field

· add a prefix to the called number as specified by the providerpx field

You can set the ported numbers form the MManage “Number Portabilty” form or you can automate the process by programmatically changing the tb_portednumbers database table. The Export/Import wizard from the file menu can be used to easily populate this table (from CSV or other sources).

You can control the server number portability handling by the “checknumport” global configuration:

-1: auto (will turn to 4 if there are entries in the tb_portednumbers table)

0=not check

1=check for changed prefix only (replace)

2=check for changed number only

3=check for changed domain only

4=check for changed server id only

5=check for changed prefix only (insert)

9=check all

tb_portednumbers:

id: autoincrement database primary key

number: original (normalized) called (B) number

sipserverid: change the SIP server id to this

carrierid: change the SIP server id to this via the tb_carriermap lookup table

providerpx: new prefix (for example instead of 3630 changed to 3620)

newnumber: the changed number

newdomain: the new service provider ip or domain

newport: service port (defaults to 5060)

priority: checked for duplicate numbers

datum: record insertion date

You must have the providerpx OR sipserverid OR carrierid OR newnumber OR newdomain:newport specified.

If certain numbers must go to certain carriers (SIP servers) then you might use the tb_carriermap table to add the carriers and just use the carrierid in the tb_portednumbers table. This way you can easily manage the carriers used for LNP.

An important step for the number portability configuration is the access of the number mapping data. This can be set in the following ways:

· Add the number mapping manually

· Create some tool/script to download the data into the mizu table database (and run in periodically from scheduled tasks)

The data can be extracted from a remote database, http/ftp file download or via an API

· Access the data via an API at runtime (HTTP GET). This can be slow

Country specific:

Country specific operator lookup and LNP lookup can be configured with the numporttype global config option.

Currently the following values are defined:

· 0: default

· 1: Brazil specific

· 2: Mexico specific

For more complex number portability handling with CADUP and SPID rewrite per operator, you can also use the tb_routingprefix and tb_directions table to store these informations (spid and cnl fields). A detailed description about the whole process can be found here.

You might use the mimport application to import the numbers (will require customization for you data source and format).

The current implementation is for Brazil, but that can be adjusted for any country with similar requirements for LNP.

For Mexico specific LNP see the number_portability_mexic.pdf guide and download the mexic specific mimport from here.

4.4.17. ENUM

Enum lookups can be used to route the calls to other SIP servers directly bypassing the PSTN network to reduce the costs and improve the quality of the calls.

4.5. Billing

Mizu Servers and Gateways has built-in prepaid and postpaid billing.

The pricing must be set from MManage –Prices Settings form

You can list and compare the prices for different directions in the Price List.

The Billing and Invoice generation are done from the “Billing” form.

A quick tutorial can be found here.

The Billing module conforms to the Hungarian laws and can be modified to fit for other countries.

4.5.1. Price Settings

Pricing of the CDR records are done after the prices defined on this form.

You can define “Price Groups”. All price settings that belong together after some logic (enduser prices for example). This is located in the left side of the Prices form.

~~Invoices can be generated automatically by the server and send by email, or can be loaded manually by using the “Billing” form.~~

~~You can schedule when to send the invoice or report to the partner or for you (defined by the mailto entry)~~

~~The report format can be defined by “Invoice Type” and “Group by” fields.~~

Below a “Price Group” you can have several Price Setups named “Directions” or “Packets” (the middle column in the form)

For example “Traffic from MizuTech SRL” or “Traffic to T-Mobile direction”

Here you have to set up the actual prices. The price setup is further divided into different prefixes (the right side of the form -Pricelist), because it is very common that you have lots of directions in a provider pricelist.

An alternative method to assign a price list to a user is by using the “Users and devices” from -> “Billing” tab -> “Billing packet” setting. This will always take precedence over the packets set in the “Price Settings” middle column. This is used to simplify the pricelist assignment for users by resellers.

pricing

Field descriptions:

Title: the name of the invoice group

Schedule: how often the report will be generated
DueIn: allowed time for payment in day (used only if the report is an invoice)

~~Status: billing status~~

~~Invoice Type: specifies the format of the invoice~~

~~Group By: specifies the format of the invoice~~

~~Separate by caller: every caller will receive a separate invoice (used for billing to end-users)~~

~~MailTo: list of email address where to send the generated report~~

~~Last Invoice Sent: date-time when the invoice was emailed to the recipient~~

~~Last Payment Received: date-time when the payment was received~~

Direction name: name of the billing entry

Type: specify the type of the price. For example the prices used when billing to endusers, or our minute costs to service providers.

Price calculations will be saved directly in the CDRs, thus can be used in prepaid billing. In the CDR records, the following fields are used for price calculation:

-costprovider: used to calculating the minute price they needs to paid to service provider (Tmobile for example)

-costenduser: used for billing to our endusers (sip endusers, traffic senders)

-costcompany: can be used for profit calculations

-costsales: sales commission. If not set, than will be calculated by the commission value in users settings

-costother: can be used for any custom price calculation

Action: How to handle the calculated price in reporting. For example in “profit” calculations whe have expenses (prices paid for service providers) and incomings (from our endusers). Thus we can simply subtract the expenses from the incomings to get the “profit”

Billing Steps: provider specific billing interval in sec

Min. Amount: the minimum payable duration in sec

Free Amount: you may have packets when the first X second is free

Free After: you may have packets when after X seconds the conversation is free

Currency: different providers may have different currency. Used for billing.

VAT Included: if the pricelist applied for this user is with VAT included. Set to 0 if VAT is not included. Used for billing.

VAT Value: the amount of VAT applied for the pricelist. Will have effect only if “VAT Included” is checked

Convert to NET value: if you have defined the pricelist with included VAT, you should check this option, otherwise you overcomplicate the billing process. Thus the VAT value will be subtracted from the price, and you will have NET values in CDR records (try to use net values whenever possible). If you need to generate invoice, make sure that all your prices are set without VAT (net) or you have checked the “Convert to NET value” checkbox.

Convert to XXX: if you have defined the pricelist in other currency than the native (configurations->currency), than your prices will be automatically converted to native currency in CDR records.

Reseller: price created by resellers. Usually should be changed only by resellers (from web portal)

A leg grace: used for IVR billing. If the user will spend too much time using the IVR.

Traffic Direction: here you have to define the rules when the current pricing will be applied

Usually only one field needs to be specified here (for example all traffic from MizuTech SRL -caller)

The caller field will check the caller parent also, but the called field will not check the parent.

These directions will be checked in priority order on routing and billing

ValidSince, ValidUntill: the pricelist may be applied only after a specified date-time

Prefix: called number prefix (this will be loaded after “best fit”). Set to ‘*’ to be applied to all directions

Price: the actual price

CPrice: the price converted in your currency (“currency” entry in the Configuration form and converted after the values specified in the “Currency Converter” form)

Time Definitions: the time period when this rule is applied

Diff between enduserprice and providerprice means that price will be calculated by extracting the provider cost from the enduser cost for an already existing cdr record. Cannot be used for realtime (prepaid) price calculations. Usually used when calculating “profit” values.

By clicking on the “Clone” button, you can easily duplicate a price list (it is very useful when you have to add only a few modification to a long pricelist)

The Billing button is a shortcut to the billing form (does not make the billing automatically)

Importing price definitions from file are done by clicking on the “Import from file” button.

First of all you must create a packet (middle column) defining the general packet properties and the conditions when it will be used. Then you can import a price list for the packet (right column -> “Import from file” button).

The imported file must be comma separated CSV file format.

You can use the Excel -> Save As functionality to export any Excel sheet as CSV file. You can also easily edit any CSV file in Excel. (Don’t leave empty columns before the columns with data)

The file must have the following fields (columns), in this order:

1. prefix (direction definition; mandatory)

2. price (flat price; mandatory)

3. peak price (if a separate preak time price is required; you might also use a separate packet for peak/offpeak)

4. offpeak price (if a separate off-preak time price is required; you might also use a separate packet for peak/offpeak)

5. billing step (if you need different billing step by prefix instead of defining the same for the whole packet)

6. minammount (if you need different minimum billed amount instead of defining the same for the whole packet)

7. mindigits (this prefix will match only if the called number length is at least mindigits)

8. maxdigits (this prefix will match only if the called number length is at most maxdigits)

Only the first two columns (prefix and price) are mandatory. The rest can be omitted or their value can be empty.

If you use the “default peak time definition”, the peak settings will be loaded from the global configuration (peaktimebegin and peaktimeend values). If this is not suitable (different service providers may calculate with different peak-offpeak definitions), you can set up the peak time definition manually (start – end hour).

If you use flat price, than leave the peak and offpeak price fields empty and vice-versa.

Importing price files may take some time, depending from your network connection speed.

Pricing example:

-a separate provider cost tariff for each of your carriers (where you are forwarding your outgoing calls)

-one enduser cost tariff for your wholesale traffic senders (or a separate tariff for each of them)

-one enduser cost tariff for your enduser or create a few groups (like premium and regular) and setup different pricing for each of them

4.5.2. Price List

On the List tab you can list all prices for a packet (by using the “Packet” list box) or to a direction (by entering a direction name or a prefix to the filter box)

On the Least Cost tab you can compare the prices from different service providers.

The Reference Packet usually is the price for your end-users.

Only peak (max) prices are compared for every direction.

On the Directory Check tab, lookups from the directory table are possible ( directory name – prefix match).

4.5.3. Billing

The server automatically calculates the price field for every incoming CDR record, based on price settings ( Section 4.5.1)

The following prices are calculated:

-enduser cost: used for invoicing for costumers

-provider cost: cost that needs to be paid for service operators

-sales cost: sales commission. If not defined in price setup, then will be loaded from users’ settings (“commission”) if any

-company cost: usually used for profit calculations

-other cost: for any other purpose

Billing can be done from

1. the “Users and Devices” form, Billing tab, by clicking on the “Generate &Invoice or Report” button (billing for the actual user)

2. set up required directions and click on the “Billing” form (in this manner, billing reports can be generated for more users)

The billing process will always take in consideration the selected date interval.

Billing form:

1. On the Customized Billing tab after selecting the required date-time interval and direction, the prices are calculated after predefined parameters (price/minute, billingstep). So you can do simple calculations using this form.

2. The CDR Prices tab will load the “enduser cost” and “provider cost” directly from cdr records (already calculated after real-time price settings)

3. Generating Reports and Invoices tab

Used for billing and reporting.

Fields explanations:

Provider: you must select the invoice emmitent here. By clicking on the “…” button, you can customize the company invoicing details.

Delete old invoices: if checked, than will clear the invoice files directory before saving the new ones.

Include inactive users: uncheck this checkbox, if you don’t want to generate reports (invoices) for inactive users (inactive for the selected period)

Include child users: for example you can select a Reseller as direction source, and all “child” users will be included in billing (where the parent id will point to that reseller)

Include CDR records: include call detail records in appendix

Language: language of the invoice

Grouping: you can select any grouping options to be generated as appendix for the report

Price values: select the price field from the CDR record after which the billing are done.

Reporting: you can automatically save the generated reports or invoices to file, or open it one by one (you can decide what to do for every report -save, print or just preview)

Format: file format (text, pdf) or printing

Real Invoice: if you would like only a quick report for the selected user(s), you can do it by setting this option to “Don't generate real invoices”. If you choose to generate real invoices, than it will take special processing for it (required for bookkeeping)

If you have selected a reseller, you should choose the “For Resellers” option. In this manner a real invoice only for the reseller company is generated. (A report will be generated for all child endusers, but those report are skipped from the bookkeeping)

Invoice Comment: any comment here. This will not be shown on the report

Money Precision: how many floating point digit would you like in money fields.

Completion date: defaults to the end of filling period if not modified

Method of payment: can be specified here, or loaded from user setting.

By clicking on the “&Generate report for the selected directions” button, you can generate the actual invoice(s)

4. Invoices and Payments

The invoice records for the selected user(s) are in this form. You can watch the debt for every user by checking the topmost record debt value.

By right clicking on a invoice record a menu will appear. From

5. You can change the price settings whenever you want, but don’t forget to Rebill your CDR records after the new settings. All CDR prices will be recalculated for the selected time interval and direction. Users and simcards credits will NOT be modified by rebilling!

6. Individual invoice

On this tab you can create invoices manually (not automatically generated from cdr records)

Note: prior to generate pdf report you should configure the installed print to pdf driver to save automatically in the specified directory. The default pdf printer can be configured in the MManage menu on the Settings-> Options from. The “pdfcreator” driver is included in the MManage install package.

For printing jobs, the default configured printer will be used.

The automatic prepaid credit expirity can be configured with the following settings:

~~Creditunit: how many credit means 1 day~~

Creditelapseunit: prepaid credits will be elapsed automatically after this period is elapsed. Creditelapseunit means the credit amount for 1 day. For example if you set it to 40 and the user will buy 5000 ft credit, than it will elapse after 4 month

Maxcreditelapsedays: max number of days when the credit will elapse
Accelapsedays: the number of days from creditelapsedt when the account will expire (account number will be suffixed with _elps ans set to temporarydisabled)

tb_users. Creditelapsedt: date-time when the credit will be expired

tb_users.Accelapsedt: date-time when the account will be expired

For this to work, you must set the “accountcanelapse” global config option to “true”. The credit expire date is calculated when the credit is added.

*You can set prepaid credit by the “Add with elapse” button to elapse automatically.

Monthly payments can be set for users by completing the tb_fees table. Can be accessed from the Users Form -> Billing tab.

The following fields are defined:

Userid: the user where the payment belongs

Datum: record insertion date

Name: the title of the payment

Value: net price

Usable: can be calculated in minute price (1 if yes, default is 0)

Ival:

-1: one time

0: monthly as soon as possible

Other: internal in days

Lastbilled: last time when the it was invoiced

Description: any comment here

To make the billing stricter, you might also set the following global parameters:

blocknotbilledcalls: 0=no (default),1=if best match packet is not found,2=if no exact packet match with prefix,3=block if not assigned directly for the user,4=check also tarifflist prefix,5=check also parent tarifflist

blocknotprofitablecalls 0=no (default),1=yes,2=yes also if equal,3=block also when it is not set

vgetpriceexactmatch: 0=no (default), 1=yes for resellers, 2= yes for all

notbilledcallerr=0 0=default (error with 2 priority),1=error,2=critical

4.5.4. Currency Conversion

You can set currency in 3 places:

-native currency in the global configuration “currency”

This will be the default currency for all internal operations

-currency for pricelist packet

When you receive pricelist in other currency, with this setting you can easily convert it to your native currency

-currency for the individual users

Useful when you need to send invoices in different currency format.

The price in the cdr record will be set based on the “currencyconversion” global configuration value which has the following possibilities: 1=native currency, 2=pricelist currency, 3=user currency if match, 4=user currency

The most easy and simply way is to set the same currency in all places.

Otherwise you must refresh time to time your currency converter table.

Currency converter

Defines the conversion between your native currency and other currencies used in price settings. You should update this conversion prices as many times as possible.

Currency precizion

You can control the money precizion display by the tb_currency_precizion table accessible from Billing -> “Money Precizion”

Id: database autoincrement primary key

Currency: name of the actual currency (for example: HUF, USD, EUR)

Precizion: number of fractioan digits on the invoices

Final Precizion: the precizion of the “Total Payment” display

Final Rounding: rounding in the “Total Payment” (ex: 1 or 5 ft)

Separator: usually ‘.’ or ‘,’

4.5.5. Finances

You can use this form for your cash-flow administration regarding your voip business.

4.5.6. Pin codes

Recharge codes used if you have prepaid cards printed.

You can generate random prepaid codes here.

Prepaid account can be charged over the website or by ivr:

Website operation:

-user authentication (tb_users.username and password)

-check if pincard is valid (tb_prepaidcodes)

-increase credit for the user (tb_users.credit)

IVR operation:

-automatic user authentication based on sip registration or require entering the phone number to be charged

-require pincode

-check if pincard is valid (tb_prepaidcodes)

-increase credit for the user (tb_users.credit)

-goodbye message

4.5.7. The billing process

Every cdr record are handled by the billing module. Prices are determined by the v_getprice stored parameters.

v_getprice parameters:

@type tinyint: type of the billing. 1=enduser cost, 2= provider cost, 3=sales cost, 4 = company profit, 5 = other cost

@callednorm varchar(26): normalized callednumber. example: 36301111111 (B number)

@callerid int: database id of the caller user

@callernum varchar(26): caller number (A number)

@techprefix varchar(4): 3 digit tech prefix if exists

@calledid int: database id of the called user

@calledpacket int: simpacket if exists

@timetype1 tinyint: time period

@timetype2 tinyint: time period

@timetype3 tinyint: time period

@timetype4 tinyint: time period

@currday smallint: weekday number (Monday is 1)

@currhour smallint: call midtime hour

@currmin smallint: call midtime minute

@parentid int = 1: database id for the parent of the caller user

timetypes are considered when you doesn’t set a concrete start-end period in the price list, and you choose from a predefined pattern (peak, offpeak, weekend, weekday, holiday,evening, night). the following timetypes are defined:

0: Disabled

1: Start-End Time

2: Peak

3: Offpeak

4: Weekday

5: Weekend

6: Offpeak and weekend

7: Evening

8: Night

9: Holiday

10: All times

11: Other Times (Rest)

example: v_getprice '1','36301234567',6555,'003615555555','150',666,-1,4,2,99,99,4,11,41,500

The v_getprice stored procedure will return the following fields: tb_billentries.currency,tb_billingtimes.isdiff,tb_billingtimes.origprice,tb_billingtimes.price, tb_billentries.billingstep, tb_billentries.minammount,tb_billentries.freeammount,tb_billentries.freeafter,tb_billentries.vatincluded, tb_billentries.vatvalue, tb_billentries.converttonative,tb_billentries.converttovat

According to returned billing settings, the price is calculated accordingly.

If there are no price defined, than default price are loaded. (if set)

If there are no sales price defined, than will be loaded from user setting (commission)

For enduser prices, the discounts and userreductions are applied if set so. Then the user credit is updated.

If there are any error with the billing process, than the default prices are applied if exists.

Billing verification:

List the required CDR records with “Show minute price option”

You can find the billing logs if you search for the called number in the server logs.

Copy the required v_getprice log in the direct query form.

Check if the returned values are as expected.

4.5.8. Invoice and payment storage

Invoices and payments are stored in tb_invoices in the database. So the invoices can be searched, recreated and storno invoice can be built based on existing invoices (conforming to Hungarian laws).

The last invoice number are loaded from database before every new invoice and incremented. Thus the invoice number increment is guaranteed the by database engine transactional behavior.

The following fields are defined:

ID: autoincrement database primary key

Type:

0=All or Recreate (technical)

1=Report

2=Proform

3=Advance

4=Invoice

5= CreditNote

6=Storno

7=Correction

8=Payment (technical: payment received)

Copynum: printed copies

CompanyID: emmitent company ID (tb_billsources)

UserID: costumer ID from tb_users (if any)

User_name: costumer name or company name

User_address: costumer address

User_regnum: costumer registration number

User_euregnum: costumer eu registration number

User_bank: consumer bankdetails (cont and address)

Payment_type: mode of the payment (Ex: bank-transfer)

Datum: record date-time

Invoicenum: the number of the invoice

~~Invoiceid: deprecated~~

Invoicefrom: billing period begin time

Invoiceuntill: billing period endtime

Invoicegenerated: invoice print time (optional)

Invoicesent: invoice sent time (optional)

Completitiondate: completition date

Duedate: payment due date

Language: invoice language

Vat: VAT percent

VatValue: sum of VAT

InvoicePrice_Net: final net price

InvoicePrice: final price

PaymentReceived: date-time of the payment

Debt: sum of all debt

Pending: all sum before due date

Comment: invoice comment

InvoiceImage: saved ivoice file

tb_invoice_entries:

Id: autoincrement database primary key

Invoiceid: foreign key to tb_invoices

datum: record insert date

description: product description with code

fromdate: billing period if applied

todate: billing period if applied

Ammount: ammount

AmmountName: name of the amount (minute)

AmmountPrice: unit price (net)

The emmitent (company) settings are stored in the tb_providers table. Only one company entry can be stored (conform to Hungarian laws). Once the company details are inserted to the database, the company name cannot be changed anymore.

4.5.9. Environment variables

Creditelapseunit: prepaid credits will be elapsed automatically after this period is elapsed. Creditelapseunit means the credit amount for 1 day. For example if you set it to 40 and the user will buy 5000 ft credit, than it will elapse after 4 month

Currency: the currency type is loaded from the “currency” global configuration or from the billed user currency setting.

The price setup currency settings also can affect the currency settings.

Currency conversions: if the pricelist is not in the native currency format (set by the “currency” global config option), than the server can convert to it automatically based on tb_currencies. You can change the conversion rates from MManage -> Billing -> Currency converter

Language: the invoice language can be controlled from the invoice form.

PDF Printer and delay: set this on MManage -> Menu-> Options

Time format: if to separe duration values to day/hour/min/sec or display only in seconds. (MManage -> Menu-> Options)

Money precision and rounding and separator are stored in the tb_currency_precizion table, accessible from the Billing form.

MINSPEACHLENONROUTE: the minimum calculated max speechlength when the call will be routed

4.5.10. Payments

There are various built-in prepaid and postpaid payment method implemented. Payments are tracked in the tb_invoices table and can be queried later for statistics and reports (Billing -> Reports form)

All credit changes for prepaid users should be logged in this user. Never modify the credit directly. Use the “Modify” button from Users and device -> Billing page if direct modification is required.

Invoices for postpaid user can be generated from the Billing -> Invoices

Chargecards can be generated from Billing -> Pincodes

CallingCards:

There is a special user type called “callingcards” but any usual user can act as a calling card.

Users can access the system via Web or IVR typing a pincode. The pincode will represent the “pincode” column from the user table or the username+password combination for enduser or only the username field for calling cards.

PayPal: direct or indirect handling of PayPal payments are supported. Search for “paypal” in the global configuration to setup. See the FAQ for the details about the configuration.

Your users are allowed to use e-payment and to pay directly with their credit card. Most of the available merchant gateways are supported.

Credit Card and eCheck processing support for every major Internet Payment Gateway using secure data communications using up to 128-bit SSL encryption and Digital Certificates.

The Credit Card validity checks decrease expenses that result from attempting to authorize invalid credit cards.

The current list of supported payment gateways include:

3DSI EC-Linx	www.3dsi.com
ACH Payments	www.ach-payments.com
Authorize.Net	www.authorize.net
Bank Of America	www.bankofamerica.com
BeanStream	www.beanstream.com
Chase Merchant Services	www.chase.com
Concord EFSNET	www.concordefsnet.com
CyberCash	www.cybercash.net
Cyber Source	www.cybersource.com
DPI Link	www.dpicorp.com
ECHOnline	www.echo-inc.com
ECX QuickCommerce	www.ecx.com
eProcessing	www.eProcessingNetwork.com
eWay	www.eway.com.au
Fast Transact	www.fasttransact.com
FirstData / Cardservice Int.	www.firstdata.com
goEmerchant	www.goemerchant.com
GoRealTime (Full-pass)	www.gorealtime.com
Innovative Gateway	www.innovativegateway.com
Intellipay ExpertLink	www.intellipay.com
Iongate	www.iongate.com
iTransact RediCharge HTML	www.itransact.com
LinkPoint	www.linkpoint.com
Merchant Anywhere	www.merchantanywhere.com
Merchant Partners	www.merchantpartners.com
Moneris	www.moneris.com
MPCS Weblink	www.merchantcommerce.net
NetBilling	www.netbilling.com
Network Merchants	www.networkmerchants.com
NexCommerce	www.thompsonmerchant.com
NOVA's My Virtual Merchant	www.myvirtualmerchant.com
NOVA's Viaklix	www.viaklix.com
OGONE	www.ogone.be
Optimal Payments	www.optimalpayments.com
PayFlow Link	www.paypal.com
PayFlow Pro	www.paypal.com
PayFuse - First National MS	www.firstnationalmerchants.com
Paygea	www.paygea.com
PayJunction Trinity	www.payjunction.com
Paymentech - Orbital	www.paymentech.com
Payment Express	www.paymentexpress.com
Payments Gateway	www.paymentsgateway.com
Payready Link	www.payready.net
PayStream	www.paystream.com.au
Planet Payment	www.planetpayment.com
Plug 'n Pay	www.plugnpay.com
PRIGate	www.paymentresource.com
Protx	www.protx.com
PSIGate	www.psigate.com
RTWare WebLink	www.rtware.net
SECPay	www.secpay.com
SecurePay	www.securepay.com
SkipJack	www.skipjack.com
Sterling	www.sterlingpayment.com
SurePay / YourPay	www.surepay.com
TransFirst eLink	www.transfirst.com
TrustCommerce	www.trustcommerce.com
USA ePay	www.usaepay.com
uSight	gateway.usight.com
Verifi	www.verifi.com
Verisign PayFlow Pro	www.verisign.com
WorldPay Select Junior Invisible	www.worldpay.com
YourPay	www.yourpay.com
and more ...

Search for epayment in the global settings for the configuration details.

To enable the E-Payment module follow these steps:

-1. Install the epayment module: EPaymentIntegrator (request from support if you haven’t received)

-2. Register the e-payment module

-3. Set the epayment_xxxx settings properly in the global configuration

E-Payments can be initiated from softphone, web portal or the module can be accessed by any external application using the console or the database API.

Any other third party payment method can be integarated.

4.5.11. Resellers

If the “resellerbilling” global config option is set, than reseller cdr records are stored in the tb_cdrresellers and billed accordingly.

To define a “base tariff” for the reseller the “Is Public” option is used from the “Price Settings” form (usually applied to an “enduser cost” packet.)
This will be the prices that will have to be paid by resellers to the service owner.

Reseller can create their base tariff (by setting the “resellerid” in tb_billentries) usually from a web portal. Multiple packets are allowed and packets can be assigned to other users or resellers directly from web (in the same way like on the “Users and Devices” form -> “Billing” tab -> Billing packet setting.

Resellers usually will create their own price lists by cloning an existing list or their base tariff list.

For early billing set the reseller stage field to 9.

Top reseller statistics can be viewed on the “Statistics” form by checking the “OC” and the “PR”/”PFR” fields.

4.5.12. Promotions

The following features can be used to use various promotions to (new) users:

· First X seconds are free

You might create packets when the first few seconds are not billed.

Just use the “Free amount” option on the Price Setup form for this

· Call X direction for only … cent

Just setup a separate packet with lowered prices for this.

Use only the directions (prefixes) you wish to promote.

· 10 USD free to direction X

Set the “packetcredit” field in tb_users to 10

Create a special packet with the desired directions (prefixes). Set the “isforpacket” field to 1 for this packet(s)

With these settings the cost of the call is calculated with this special packet(s) and the cost will be deducted from the “packetcredit” field instead of the real “credit” field.

· You can offer some directions for the users where they can call Y minutes for free

The followings fields have to be used for this from the tb_users table:

o freeminutes: free minutes included

o freesms: number of free sms messages included

o freeminutesleft: remaining free seconds! (this field will be modified by the server. No more free minutes when reach to 0)

o freesmsleft: remaining free sms (this field will be modified by the server. No more free sms when reach to 0)

o freedirections: numbers separated by comma or a prefix where the free minutes or sms can be used (it can be also a whole number). Empty value for this allows free calls to all directions.

o freedays: set to a positive value if you wish the free minutes to be reset after this number of days (recurring free minutes). Set to 0 to disable reset. (By reset we mean that the freeminutesleft will be set to freeminutes)

o freebegindt: freedays begin date-time

For this feature to be used you might have to set the “checkfreeminutes” global config option to 2. You might also set the “freedirections” global config option to restrict the directions that can be allowed by the tb_users. Freedirections field (if you let this field to be modified freely by the users, for example to select one preferred number or destination prefix)

Example SQL to add 100 free minutes ad 30 SMS for a set of users to prefix 4411:

update tb_users set freeminutes = 100, freesms = 30, freeminutesleft=100*60, freesmsleft=30, freedirections =’4411’, freebegindt=getdate(),freedays=31 where id in (X,Y,Z)

To add 10 free minutes for new users, just set the default value for the “freeminutes” field to 10 in the database.

· Offer some free minutes for all new users (restricted by user IP)

There is another possibility by restricting the maximum number of calls or call duration from a source address by the following global settings:

o maxcallperip: max number of calls from the same IP

o maxdurationperip: max call duration from the same IP

o maxcostperip: max call cost per IP

o maxcallperperiod: the period for the above (1.0 means one day)

o maxcallperuserid: the above will be set to this user only (set to -1 for all users)

Additionally to IP restriction you should set as much other restrictions as possible to restrict your server attack surface, such restricting the usage to one user (maxcallperuserid), set user as prepaid, set max lines and daily/monthly limits on the account as other best practices discussed in this documentation.

4.5.13. Fraud protection

See the “Security and account limiting” section,

4.5.14. Notes

Call forward billing: 2 cdr record will be generated. A->B and B->C

Call forward from IVR: one cdr will be generated. Whether we charge the call to the IVR or only bill the forwarded call can be controlled by “resetdurationonfwd”

Call transfer by SIP signaling: the second call is completely different from the first call. Billing goes normally (2 calls)

Call transfer with dtmf (*5*): only one call leg is billed

Conference with dtmf (*1*): separate cdr will be generated for all call legs

Conference by sip: technically separate calls. Will be billed normally (2 cdr)

Call forwarding from IVR (2-leg calls):

CDR’s generated based on “ivrbilling” global and user setting: 0: one CDR including the forwarded call, 1: load duration only from forwarded call, 2: generate 2 CDR records (A leg + B leg), 3=both merged,4=merged with short a-leg,5=only b-leg billing if call is connected

Ø ivrbilling is 0: (server side) 1 CDR will be generated with total client call duration. The billing will be done after the final called user (the IVR accessnumber when the call was not forwarded. Otherwise the final destination number)

Ø ivrbilling is 1: (client side) 1 cdr will be generated. The call duration will be set after B-leg call duration and billed accordingly

Ø ivrbilling is 2: (both) 2 (or more) cdr will be generated (when there was call forwarding action). The 2 cdr record can be billed separately after different billing tables

Ø ivrbilling is 3: (both merged) 1 cdr will be generated, but the enduserprice can be loaded from different billing tables (2-leg merged)

Ø ivrbilling is 4: (both merged with short a-leg) 1 cdr will be generated, but the enduserprice can be loaded from different billing tables (2-leg merged). The A leg duration is shortened (only the time spent with IVR until the call forward action)

Ø ivrbilling is 5: (server side if connected –mostly the same like ivrbilling 0) 1 CDR will be generated. If the call was not connected then all duration will be billed (you can setup different billing for these calls by marking the entry as “is ivr call” and set the “called” to the access number. If the call is connected, then the B-leg will be billed (possibly after a different billing packet)

4.6. GSM/SIM Platform

Skip this chapter if you don’t have VoIP-GSM gateways

4.6.1. SIM Packets

Id: database primary key. Autoincrement

Provider, type, subtype: the name of the packet

Owner: simowner in case of simpackets

Allowedpartners: applied when it is a simpacket

AbsPriorityPartner: this partner will have big priority on sims that belong to this packet

PriorityPartner: this partner will have increased priority on sims that belong to this packet

NopriorityPartner: this partner will have lowered priority on sims that belong to this packet

Filtering: determines how we check the blacklist and the known numbers

0-no filter: allow all numbers

1-allow blacklist „sure” level: 0,1 and 2 (tb_blacklist)

2- allow blacklist „sure” level: 0 and 1

3-allow only blacklist „sure” level: 0

4-block all blacklist

5-allow only knownnumbers (listed in tb_knowngoodnumbers)

6- allow only knownnumbers that are 100% ok (sure is 1 in tb_knowngoodnumbers)

Dialplan:

0: international number format with 00... (e.g.: 003630xxxxxxx)

1: international number format with +... (e.g.: +3630xxxxxxx)

2: area code + number (0630xxxxxx, 061xxxxxxx)

3: shortest possible number (xxxxxxx in the same simpacket or 0630xxxxxxx in other simpacket)

4: correct it to the most appropriate format if original is not correct

WaitAfterCall: how much time must be elapsed between calls to simcard belonging to this packet

MaxMonthlyMinutes: we don’t route more than MaxMonthlyMinutes to simcards belonging to this packet

MaxMonthlyMinutesPeak: maximum allowed minutes in peak time / month

MaxMonthlyMinutesOffPeak: maximum allowed minutes in offpeak time / month

MaxMonthlyMinutesWeekend: maximum allowed minutes in weekends / month

MinMonthlyMinutes: this packet will run on higher priority until the min minutes is reached

Price: default minute price if not set in tb_packetprices (deprecated. Loaded from pricelist from v.3.2)

BillingStep: second increments (used for calculation simcards minutes –daily, weekly, peak, offpeak)

MinAmmount: min billing seconds (used for calculation simcards minutes –daily, weekly, peak, offpeak)

FreeAmmount: free speech seconds (used for calculation simcards minutes –daily, weekly, peak, offpeak)

MinCreditOnRoute: if the sim has less credit, then we don’t route call to it

MinCreditOnCharge: if the sim has less credit, then we begin trying to charge it

Prepaid: 0=postpaid, 1=prepaid

SendFakeSMS: we send dummy sms on this sim

CanCallEachOther: the simcard in this packet will call each other periodically to generate incoming traffic

IncludeVAT: used when credit message information are received from simcards (typically via SMS) and the simcards credits are calculated without the VAT value

Currency: used when the credit messages received needs to be converted in native currency (“currency” global setting) format. If the currency is not the same as the native currency and the “convertsimcreditcurrency” global setting is set to true, than the received credit value is converted to the native currency, based on “Currency Converter” settings, found in MManage under the “Billing” section

MaxAlloc: helper settings when automatically alocating channels for a direction. (Depending on reserverfor simcard setting).

Here you can define the maximum count of simcards that can be reserved for the actual packet. Set to 0 to disable rezerving from that packet.

Credit Request Command: the command used by the server for sim credit request (used for recharge automation)

Credit Charge Command: the command used by the server for sim credit charge (used for recharge automation)

The request and the charge command must have the following syntax: <DTMF,action,simid,”message”,telnum>

The “chargecode” string in the message will be replaced with a valid code if found.

You can introduce delays by inserting ‘#’ characters in the message.

The action parameter can be

-0: used to send USSD messages

The message parameter must have the following format “AT+CUSD=command” where command is the ussd string.

Example: DTMF,0,simid,"AT+CUSD=1,*121*chargecode#"

-1: will send the specified message to the engine. The message can be any valid AT command

-2: will dial the specified telnum, and then send the message as DTMF.

If the message string if empty, than only will dial the requested telnum, hold a little and then drop.

Example: DTMF,2,simid,"",172

-3: reserved for future usage

-4: will send the specified message as SMS to telnum

4.6.2. Gateways

Used to configure your Mizu VoIP-GSM gateways.

The fields are the same as listed in section 4.3.1

4.6.3. Engines

Listing of gsm channels. The fields are self explanatory.

4.6.4. GSM Channels

Skip this if you are not using VoIP-GSM gateways.

Usually this is the most frequently used form by the technical support. You can see the status of each gsm channel on your gateway(s).

channels

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

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

Same as “GSM Channels”. See section 4.2.2

The first field will show the status of the simcard (Monitor). The most frequently used values are the followings:

Unknown: the last list refresh is too old. Status cannot be determined. Click on the reload button to refresh

Missing: simid not found. Corrupt entry

Sim Disabled: simcard “Enabled” is set to false
GW Disabled: gateway “Enabled” field is set to false

GW Missing: last message received from gateway is more than 8 minute old

SIM Missing: last message received from simcard is more than 8 minute old

SIM Temp. Disabled: simcard “Temporary disabled” field is set to true

GW Temp. Disabled: gateway “Temporary disabled” field is set to true

No Packet Set: no packet settings are present for this sim. You always need to set the correct packet settings for all simcards

Packet Disabled: simpacket “Enabled” field is set to false

Closed: simcard channel status is set to closed. A simchannel can be closed for different reason. Cannot register to gsm network, Sim Change, Just restarted, etc. If this status persist, check the logs for that simcard

Failovered: server has detected wrong quality on the simcard. Traffic will be forwarded to other simcards if possible

AutoDisabled: same as “Failowered”

Cannot Get Credit: automatic credit request failed. Check the credit automation log for errors

Wrong Statistics: wrong statistics for the current day

Wrong ASR: wrong ASR detected on the channel. Treshold values can be set up from the MManage -> Menu -> Settings

Wrong ACD: too small average speechlenth detected on that simcard

Expired: maximum monthly or daily speechlength limit reached (SimPacket option)

Low Credit: prepaid simcard expired

Gateway Disc.: gateway is offline or just restarting.

Not Ready: simcard is not ready for some reason. Maybe just starting. Checj the logs if this status persist

Ready: simcard is ready to accept incoming call

Dialing: outgoing call setup in progress

Ringing: ringing signal received from gsm network

Speaking: gsm engine is ringing or call in progress

Call ending: dropping the current call

DTMF: dtmf or credit request/recharge message in progress

Simulating incoming/outgoing: calls between simcards generated by the server

Routing: the call have been routed from the server, but still not arrived to the gsm gateway. If this persist, check the log for errors. Usually means firewall/NAT problems

Note: dialing, ringing and call ending messages may not be shown in the monitor depending from the gsm gateway configuration.

If the “sendallstatus” setting is set to false, than instead of “dialing” and “ringing” only the “speaking” message will be shown.

4.6.6. Credits

For Identification of sms and dtmf messages received from simcards that are useful for credit request and charge

Type: 0=other, 1=succ charge without credit info,2=credit start/end, 3=failed charge, 4=need charge

Msgbgn: begins with

Msgeng: ends with -used if type is 0 (replace) or 2 (end of credit), 4 (new credit. usually 0)

Priority: check order (longer messages usually first, to not include shorter) –higher values first

4.6.7. SIM Distribution

All simslots are listed here.

Probability values:

not sure: the simcards was seen more than one month

probably: the simcards in the last month

sure: the simcards in the last week

The other fields are the same as described in section 4.2.2.

4.6.8. SIM Utilization

List of simcards in call duration order.

4.6.9. New Simcard

You can add new simcards by using this form.

However, the simcards are usually added automatically. If they are active in the gateway they will register automatically. Usually only the owner and the packet must be set manually.

4.6.10. New Charge Card

Add new chargecards with this form.

The charge card will be charged only on the simpackets selected (“packets for”) and if the owner will match.

chargecard

4.6.11. SIM Bank

In the SIM Bank form you can monitor the sim flying activity.

4.7. Other -MManage

4.7.1. Configurations

Global system configurations.

Basic configuration are vital for the system to run correctly.

The following config settings are defined:

Category	Key	Description

CallCenter	allowdbcalls	Allow calls from database in MAgent
CallCenter	allowmanualcalls	Allow manual calls from MAgent
CallCenter	allowopcampchange	Allow operators to change its campaign from MAgent
CallCenter	autoformname	Type of AutoCall GUI to load
CallCenter	callbackautorecall	1= schedule for recall if number is in campaign
CallCenter	callbackhandling	handling incoming calls: 0=dropp all
CallCenter	callbackivr	play special messgae (callback.wav) if no operator found or ring timeout expired
CallCenter	callbacknumber	A number for calls. For example the predective dialer will use this number
CallCenter	callbackringtimeout	ring timeout on callback (after than play ivr message if set) defrecallmin
CallCenter	callbackroutenumber	number to be dialed on incoming calls when callbackhandling is 1
CallCenter	CALLCENTERPORT	callcenter tcp port number (for requesting new clients)
CallCenter	callmaxring	max ring time in sec
CallCenter	callmaxwait	max worktime for operators between calls
CallCenter	callnumbertype	Preference order of numbers (if more than one number exists for a client): 0=first try landline
CallCenter	callretryival	seconds to wait untill to redial the client
CallCenter	ccorder	client call order: 0=database id order
callcenter	defrecallmin	recall data-time will be shown with the specified minute in MAgent
CallCenter	desireddropprate	optimal percent of calls wich cannot be assigned to operators when in predective
callcenter	finishvoice	default file when set to "finish with voice" in scripts
CallCenter	handlingincoming	0=not handled
CallCenter	maxcallatonce	max number of calls in one round when in predective (error guard)
CallCenter	maxcallsperminute	max new call attempts/minute when in predective (error guard)
CallCenter	maxcalltrycount	max attemt of calls for a client
CallCenter	maxrecallafter	client can be recalled in this interval
CallCenter	maxrecallafterall	client can be recalled in this interval by any operator
CallCenter	maxrecallbefore	client can be recalled before the specified time
callcenter	maxrecallmin	restriction of the recall date-time input in MAgent
CallCenter	maxrecalltrycount	max attemt of REcalls for a client
CallCenter	mobileratio_08_12	percent of mobile calls in the specified period [1-100]
callcenter	mobileratio_12_16	percent of mobile calls in the specified period [1-100]
CallCenter	mobileratio_16_20	percent of mobile calls in the specified period [1-100]
CallCenter	mobileratio_20_08	percent of mobile calls in the specified period [1-100]
CallCenter	mobileratio_weekend	percent of mobile calls in the specified period [1-100]
CallCenter	predectivecheckival	controlls the speed of the predective dialer thread -advanced technical setting
CallCenter	predectivecorrection	correction of precalculated success ratio statistics in predective. for example if we set it to 80
CallCenter	predectivecutnofreeop	disconnect pending predective calls if no more operator waiting
CallCenter	predectivedial	dialing mode: 0=simple MAgent requests
CallCenter	predectivelogging	details of predective logs (0=no logs
CallCenter	predectivemaxsucccalls	max predective calls in the same time (check in calllist)
CallCenter	predectivemaxsuccmobilecalls	max predective mobile calls in the same time (check in calllist)
callcenter	presentationmode	0=no presentations
CallCenter	quotastatrecalcival	how often the quotas will be recalculated
callcenter	recallonlyinsamecampaign	call only with its own campaign (no recalls from other campaigns)
CallCenter	recallrescheduleival	if call continue to fail
CallCenter	recallrescheduleivalfirst	if call failed for the first time
CallCenter	recallrestrictions	recall mode: 0=give to the same operator
CallCenter	savemode	level of saving data - 1=automatikus mentes a kovetkezo kerdesre ugraskor
CallCenter	statival	rebuild predective statistics interwal (-2 = automatic)
CallCenter	stopwrongcdrc	pause predective if the ASR is too low (error guard)
CallCenter	waitforpredective	max time to wait for a free operator when a predective call is connected
CallCenter	waitifnotaccepted	max time to wait in MAgent if the client is not "accepted"
CallCenter	waitifnotconnected	wait after calls even if was not connected (operator worktime)
gatekeeper	h323debuglog	write h323 gk log to logfile
license	CAN_alert	default license (will have no effect if you change it here)
license	CAN_billing	default license (will have no effect if you change it here)
license	CAN_failower	default license (will have no effect if you change it here)
license	CAN_filtering	default license (will have no effect if you change it here)
license	CAN_gsmextra	default license (will have no effect if you change it here)
license	CAN_hash323	default license (will have no effect if you change it here)
license	CAN_hassimbank	default license (will have no effect if you change it here)
license	CAN_hassimplatform	default license (will have no effect if you change it here)
license	CAN_hassip	default license (will have no effect if you change it here)
license	CAN_recharge	default license (will have no effect if you change it here)
license	CAN_runsipproxy	default license (will have no effect if you change it here)
license	CAN_sipextra	default license (will have no effect if you change it here)
license	FULLRIGHTS	default license (will have no effect if you change it here)
license	lic_isset	default license (will have no effect if you change it here)
license	LICENSEMAXMONTH	default license (will have no effect if you change it here)
license	LICENSEMAXYEAR	default license (will have no effect if you change it here)
license	MAXALLUSERS	default license (will have no effect if you change it here)
license	MAXCCALS	default license (will have no effect if you change it here)
license	MAXCHANNELS	default license (will have no effect if you change it here)
license	MAXGATEWAYS	default license (will have no effect if you change it here)
license	MAXSIPUSERS	default license (will have no effect if you change it here)
license	MAXSL	default license (will have no effect if you change it here)
license	MAXTRAFFICSENDERS	default license (will have no effect if you change it here)
license	SRVVERSION	default license (will have no effect if you change it here)
licensecfg	hasalerting	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hasbilling	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hascallcenterin	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hascallcenterout	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hasextra	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hasfailower	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hasfiltering	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hasgsmextra	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hash323	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hasrecharge	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hassimbank	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hassimplatform	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	hassip	modules to load (has effect only if not prohibited by builtin license restriction)
licensecfg	maxallusers	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxcallspermin	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxccalls	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxccallsblock	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxchannels	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxgateways	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxgsmgateways	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxivrspeechlen	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxregistrations	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxsessionspeechlen	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxsipusers	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxsl	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxtagents	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	maxtrafficsenders	limitations (has effect only if not prohibited by builtin license restriction)
licensecfg	runsipproxy	run h323 - sip translator
settings	adminport	adminport
settings	alertonlowdiskspace	alert on low disc space
settings	aliasrouting	allow lrq routing
settings	allownumbersendback	allow to route back the call to the caller
settings	autodetectlocalip	automatically overwrite the localip value if set to true
settings	autoholiday	holiday routing and billing treated as Sunday
settings	billshortnumlength	number that are smaller than this value will not be billed
settings	bindip	bind to this ip (for multihomed servers or if we run multiple serers on the same maschine)
settings	boostonfirstcall	if to start with low priority and boost it when the first call arrives
settings	brs_lcr	routing algoritm: 0=not used
settings	buildloadstatistics	tb_loadstatistics
settings	canaoutosaveinifiles	if we can save unsaved items
settings	canrestartformalfunctions	0=cannot restart
settings	cfg_block711	if g711 (PCMU
settings	checkblacklist	0=no check
settings	checkcallerids	wich calls are to be checked on the selfcheck thread (useful if you have wrong traffic senders)
settings	checkcputime	if cputime is constantly high
settings	checkcredirights	if to check the owner of the sim and chargecards
settings	checkgkcdrs	if to check cdr records from the gk statusport
settings	checkgsmnumlen	if to allow incoming number only with this size
settings	checkknownnumbersex	0 = no
settings	checklocalnumberpx	local endusers prefix to check (to not route to other servers). if emty
settings	checklocalnumbers	check local endusers on routing
settings	checkmaxlines	check max used lines to client and partner
settings	checkmaxlinetb	extended check for max lines (tb_maxlinep)
settings	checkmaxnumlen	max called number length allowed
settings	checkminnumlen	min called number length allowed
settings	checknumlen	if to check the incoming number len //14
settings	checknumport	check number portability
settings	checknumportpx	check number portability for this prefixes
settings	checkpacketfailowering	0=don't check
settings	checkprefixes	check asr/acd for alerting and wachdog only for this prefixes. must be in the following format: 'xxx'
settings	checkprefixroules	set to 1 to check additional prefix rules. by default only H323 ip prefix rules are applied
settings	checkrouterrights	callprefixrights and partner binding
settings	checksss	check special numbers
settings	connectondisccode	if to connect the sipcall before to play the disconnect reason. 0=not connect
settings	country	used in number normalizations
settings	countryprefix	used on routing
settings	creditcheckforpostp	check credit for postpaid users too (max limit)
settings	creditcheckforts	check credit for traffic senders too
settings	currency	local currency
settings	dailymainttaskhour	when to perform daily maintenance tasks
settings	dbdelbackupdir1	additional backup directory to cleenup
settings	dbdelbackupdir2	additional backup directory to cleenup
settings	dbdelbackupdir3	additional backup directory to cleenup
settings	dbloglevel	db server loglevel (0=only errors to monitor
settings	dbmaint_backupdbdir	database backup directory
settings	dbmaint_backupdbnetworkdir	database backup directory path (if the database engine is located on a remote server)
settings	dbmaint_backuplevel	0=no backups
settings	dbmaint_backuptables	backup cdr records and other tables to xxx_backup: 0=no
settings	dbmaint_do	do database maintanance
settings	dbmaint_removecdrs	remove cdr records after x days
settings	dbmaint_removelogs	remove logfiles after x days
settings	dbmaint_removeother	remove other tables records after x days
settings	dbtimeout	database query timeout
settings	defaultenduserprice	if no price entry found
settings	defaultproviderprice	if no price entry found
settings	defcallerid	default caller id for cdr records if cannot be determined exactly
settings	deldbbackup	delete old backup files after this day elapsed
settings	deleteoldlogfiles	delete older logfiles than the specified day (set to 0 to disable)
settings	emailbatchwait	bulk email sender wait interval
settings	emailfromaddr	default email config
settings	emailfromname	default email config
settings	emailhost	smtp server used for alerting
settings	emailsubject	default email config
settings	emailuser	smtp username used for alerting
settings	emergencydir	route emergency calls to this gateway (user id)
settings	enablefirewall	enable/disable builtin firewall and dos attack filtering
settings	enforcestrongauth	enforce authorization and strong passwords
settings	estimatedspeachlenoncard	sim card config
settings	eveningbegin	evening begins at that hour. used for common time intervalls
settings	fakegwalias	will route the wrong calls here. set to FBACKUPGW if needed
settings	faxfromaddr	fax sender configuration (email to fax server)
settings	faxfromname	fax sender configuration (email to fax server)
settings	faxhost	fax sender configuration (email to fax server)
settings	faxnormalize	fax sender configuration (email to fax server)
settings	faxsubject	fax sender configuration (email to fax server)
settings	faxsuffix	fax sender configuration (email to fax server)
settings	faxuser	fax sender configuration (email to fax server)
settings	fileloglevel	file server loglevel (0=only errors to monitor
settings	filetransferbufflen	fileserver buffer length
settings	filetransfertick	fileserver speed
settings	freenumlen	number length that can be called free of charge
settings	gkcommand	how to start the h323 gatekeeper
settings	gkstoptick	gk setting
settings	globalcdrid	server generated. don't touch
settings	gmtdiff	the difference to gmt (useful for sip date header)
settings	gsminccallerip	convert incoming caller ip from gsm gateways when forwarding to a support phone (incall action in gsm gateways is 3)
settings	incduration	to increase cdr duration. 1=small inc ~ 1%
settings	internal_endusercost	enduser price for internal calls (between endusers)
settings	internal_providercost	provider price for internal calls (between endusers)
settings	InternalIP	sipserver internal ip (interface to clinets)
settings	keepbackuprecorded	days to keep voice records in the backup directory
settings	keeprecorded	days to keep voice records
settings	LocalIP	sipserver external ip
settings	loglevel	other server loglevel (0=only errors to monitor
settings	lognofreecardc	list free card data when no route found
settings	logsqlcommands	trace sql commands (log)
settings	logtodb	trace to database (log)
settings	logtofile	trace to file (log)
settings	maxdisableonss	reserver sim capacity config
settings	maxgkmemoryutilization	max memory for gatekeeper in KB (restart if exceed)
settings	maxloglisten	max log message quee length
settings	maxmemoryutilization	max memory utilization in KB (restart if exceed)
settings	maxnocdrmin	will take the correspondig action if no cdr record found in the last "maxnocdrmin" minute. set to 0 to disable checks
settings	maxnogkcallmin	will take the correspondig action if no new call
settings	maxnologival	will take the correspondig action if no log entry found in the last "maxnologival" minute. set to 0 to disable checks
settings	maxnosip2h323callmin	will take the correspondig action if no sip2h323 call
settings	maxpriceperminute	will alarm if providerprice is bigger
settings	maxrecdiff	recorded voice stereo sync in msec
settings	maxrecdiff2	recorded voice stereo sync in msec
settings	maxroutereqpermin	allow only "maxroutereqpermin" routing request/minute
settings	maxudpselect	max socket on select (set to -2 to autoconfigure. -1 means no limits)
settings	minacd	min acl value
settings	minactivegateways	will take the correspondig action if not enough gateways
settings	minactivesims	will take the correspondig action if not enough channels
settings	minasr	min asr allowed. will alert/reset if lower
settings	minblockcallcount	mincallcount to check in periodic blacklist refresh
settings	mincdrcount20min	minimum number of calls/20 min. restart if lower
settings	mincreditoncharge	general credit limits
settings	mincreditonroute	credit limits
settings	minfreechargecards	min free sim charge card
settings	minlinetoprefix	min line to the predefined prefix
settings	minlogdelay	minimum delay between writing two log messages in msec
settings	minmemoryutilization	will restart on offpeak if exceed
settings	minprofit	alerting threshold
settings	minprofitpercent	alert config
settings	minsubsecventcallbegin	wait at least minsubsecventcallbegin when route to the same channel
settings	mobileprefixes	mobile number prefixes
settings	monitorport	default monitor port
settings	nightbegin	night begins at that hour. used for common time intervals
settings	normalizenumbers	0=not at all
settings	numfiltering	blacklist/whitelist filter (0=don't filter
settings	onlyroutealias	you can set a gateway here. all traffic will be routed to that gw
settings	onlyroutesim	you can set a simid here. all traffic will be routed to that sim
settings	peaktimebegin	peaktime settings for billing and routing
settings	peaktimebegintr	peaktime settings for various operation
settings	peaktimeend	peaktime settings for billing and routing
settings	peaktimeendtr	peaktime settings for various operation
settings	ppriority	0=low
settings	removetrailinghash	remove # when routing
settings	restartatnight	set to true if you want a reset every night
settings	restartpcatfirst	restart the pc immediately on error (don't restart the sw)
settings	rotatelogfile	create separate logfiles for every day
settings	rrr_black	blacklist q931 disconnect code. defaults to ResourceUnavailable = 47
settings	rrr_denied	access denied q931 disconnect code. defaults to ChannelUnacceptable = 6
settings	rrr_desterr	wrong destination q931 disconnect code. defaults to DestinationOutOfOrder = 27
settings	rrr_err	routing error q931 disconnect code. defaults to TemporaryFailure = 41
settings	rrr_nogw	no capacity q931 disconnect code. defaults to NoCircuitChannelAvailable = 34
settings	rrr_tomany	too many wrong request q931 disconnect code. defaults to Congestion = 42
settings	rrr_wrongnum	wrong B number q931 disconnect code. defaults to InvalidNumberFormat = 28
settings	runfakegw	if to run local fake h323 gw to offload exceeding traffic
settings	runstatistics	long havy cdr statistics
settings	salescomissionfromprofit	The defined commission percent will be calculated for the profit or for the enduserprice
settings	sendmailalert	if to send alerts on critial errors (pease configure the emailalertX settings)
settings	serverftpdailydir	create separate directory for recorded voices daily
settings	serverftpdir	used for inifiles
settings	serverftpvoice	where to store recorded audio
settings	servername	server name (will appear in reports
settings	shortnum_endusercost	enduser cost for short numbers
settings	shortnum_providercost	provider cost for short numbers
settings	sipcommand	how to launch the local h323-sip server
settings	SIPH323GWID	sip to h323 protocoll conversion will be done using this gateway or module
settings	siph323gwid2	sip2h323 user id (if -1 than will load automatically)
settings	skipsqlerrors	if to skip sql errors (not throw)
settings	storecdrcomments	sore comment to cdr records. 0=no
settings	storeduplicatecdr	store separate cdr record for sip 2 h323 conversions
settings	usedefaultdisccodes	don't use customized disconnect codes
settings	usedelayedupdate	sql upfates in separate thread
settings	usewrongnumfilter	block (nearly) subsecvent wrong callednumbers (0=don't block
settings	voicebackupdir	where to store a backup of recorded conversations
settings	weekendispeak	peaktime settings for billing and routing
settings	weekendispeaktr	peaktime settings for various operation
settings	wrongnumcache	remembered callednumbers. used if usewrongnumfilter is not 0
settings	wrongnumdropcount	drop call if this number of failed calls found in cache. . used if usewrongnumfilter is not 0
SIMAllocation	simallocivaltype	simbank config
SIMAllocation	simallocsendival	simbank config
SIMAllocation	simalloctimebefore	simbank config
SimPlatform	allowlastsim	specify to allow two subsequent calls to be routed on the same simcard
SimPlatform	allowlastwrongnum	specify to allow subsequent wrong number
SimPlatform	allowoldstat	allow old status messages
SimPlatform	autosimalloc	automatically allocate simcards
SimPlatform	brsforgsm	check BRS for gsm gateways too
SimPlatform	checkcredirights	sim and chargecard rights
SimPlatform	checkcreditandcharge	if to run the creditcheck thread
SimPlatform	checksimsdisable	automatic simcard prioritization based on ASR and ACD
SimPlatform	checktpercek	allow tpercek exception in routing
SimPlatform	checkwestelcards	Hungarian specific
SimPlatform	convertsimcreditcurrency	convert incoming credit message to native currency (defined by "curerency" config value)
SimPlatform	convertsimcredittonovat	conert oncoming credit message to not include VAT values
SimPlatform	creditchecktimeival	run the creditcheck thread for every X interval
SimPlatform	creditunit	usefull in credit checks. equilavent with 600 ft. less if you want more precise credit calculations
SimPlatform	defaultsimpacket	use the default packet for new simcards (simcards without a packet)
SimPlatform	enforcegwname	accept only gateways with valid name. the 'GW' suffix must be present in names
SimPlatform	estimatedspeachlenoncard	needed for routing
SimPlatform	fakesmscount	fake sms messages by sim / month
SimPlatform	fieldstrengthstatistics	build fieldstrengthstatistics
SimPlatform	fnosamecountyc	used for fake sms and calls. every fnosamecountyc sms/calls will go to some other country
SimPlatform	fnosamepacketc	used for fake sms and calls. every fnosamepacketc sms/calls will go to some other simpacket
SimPlatform	fnosameprovidc	used for fake sms and calls. every fnosameprovidc sms/calls will go to some other provider
SimPlatform	gkpname	gatekeeper name
SimPlatform	gkrstifnotconnected	restart the gk if not connected
SimPlatform	gsmgwport	port for the gsm gateways
SimPlatform	gsminccalled	forward incoming call from gsm gateway to this number
SimPlatform	gsminccaller	convert incoming caller number from gsm gateways when forwarding to a support phone
SimPlatform	gsminccallerip	gsminccallerip
SimPlatform	gsminfromip	fromip
SimPlatform	gwstatistics	to build the table or not
SimPlatform	incomigcalls	simulate incoming calls on simcards. 0=no
SimPlatform	incomingcallcount	number of incoming call/month by simcard (if the incomigcalls options is set to 1 or 2)
SimPlatform	lowercredit	sss
SimPlatform	maxallowedcredit	only values below are valid (when received in sms or dtmf)
SimPlatform	maxflysims	max flying simcards
SimPlatform	maxsimpreconfig	max credit rec delta
SimPlatform	maxsimpriceonalloc	max accepted price
SimPlatform	mincreditoncharge	min credit
SimPlatform	minfreelines	will take the correspondig action if not enough free line found
SimPlatform	minsimlastrectime	elapsed minutes when the server decide that the channel is offline
SimPlatform	onlyroutealias	route all calls to this gateway
SimPlatform	onlyroutesim	route all calls to this simcard
SimPlatform	reservedef	reserver capacity
SimPlatform	reserveforh323	reserve capacity for h323. reservations will be disabled if less than 1
SimPlatform	reserveforsip	reserve capacity for sip . reservations will be disabled if less than 1
SimPlatform	sendfakesms	send sms messages between simcards
SimPlatform	simalloccangominus	we may activate sims that have negative values
SimPlatform	simcreditdiv	reported credit must be divided by this number
SimPlatform	succchargetime	minimum time between succesive charge try on the same simcard in minutes
SIPSettings	ABSOLUTETIMEOUT	max session time (call duration + setup time + clearing time) in seconds
SipSettings	addcontentdispozition	0=no;1=optional;2=required
SIPSettings	allowcallunregistered	allow to call before registered (terminals)
SIPSettings	allowdiscmessage	allow disconect reason voice playback
SipSettings	allowlist	INVITE
SIPSettings	CanAcceptLocalIp	Can call from 127.0.0.1
SipSettings	cancutsipnumbers	packet dialplan for sipnumbers
SipSettings	canmove	0=not allowed
SipSettings	checknomedia	disconnect calls on rtp disconnect
SIPSettings	COMPANYNAME	this will apear in the sip signaling
SipSettings	def_max_sessiontimer	sip session-timer config
SipSettings	def_mid_sessiontimer	sip session-timer config
SipSettings	def_min_sessiontimer	sip session-timer config
SipSettings	domainnames	registrar domainnames (used for inter-domain rerouting)
SipSettings	eventlist	refer
SipSettings	forwardretrytimer	ivr forward retry interval
SipSettings	fwdtootherdomains	0=no
SIPSettings	fwdunknownheaders	forward unknown sip headers
SIPSettings	HasInternalAccess	accept from 192.168... or 10.0....
SIPSettings	identityrwmode	0=no rewrite
SIPSettings	IDLETIMEOUT	used for various session timers
SIPSettings	im_billinguserid	used for instant messaging
SIPSettings	im_parentid	used for instant messaging
SIPSettings	lastlocalsdpport	used in terminals
SIPSettings	loadcallednumberfromto	load the called number from sip to instead from the sip first line (URI)
SIPSettings	localclientport	useful for 2 port configurations
SIPSettings	LocalDomain	sipserver domainname
SIPSettings	localinternaldomain	sipserver internal domainname
SIPSettings	LocalPort	sipserver listen port
SipSettings	logsipmsgexchange	store the sip message headers in the cdr comment
SIPSettings	MAINTIMERIVAL	sip background process timer. used for garbage collections mainly
SIPSettings	MAXEPCOUNTTRESHOLD	maximum number of registered endpoint (it may be limited by license too)
SIPSettings	MAXH323GKCDRCACHE	this must at least the maximum h323-h323 simultaneous call number
SIPSettings	maxreroute	max number rute retry
SipSettings	MaxRTP	rtp port range begin for sip
SIPSettings	MAXSPEACHLEN	max allowed call duration in sec
SipSettings	maxstatchangepermin	max allowed enduser status changes/60 sec (slower if exceed)
SIPSettings	MAXSUBSMSGCOUNT	max subsequent messages before block
SIPSettings	MAXSUBSMSGPERIOD	max subsequent messages before block are checked for this interval (sec)
SIPSettings	MAXWRONGMSGALLOWED	dos attack protection
SIPSettings	MEDIATIMEOUT	will disconnect if the media disappears
SIPSettings	MEDIATIMEOUTSTART	will disconnect if no media detected
SIPSettings	MINRESENDIVAL	sip udp resend timer (T1) in msec
SipSettings	MinRTP	rtp port range begin for sip
SIPSettings	MINSPEACHLENONROUTE	minimum remained speechlength for the caller when the router will still route the call
SIPSettings	MINUSERCREDITONROUTE	minimum credit for the caller when the router will still route the call
SIPSettings	MINUSERNAMELEN	minimum accepted username length
SIPSettings	PRODUCTNAME	the name of the product. this will apear in the sip signaling
SipSettings	propersipcomments	set to true if you want personalized sip headers
SIPSettings	REBUILDREGCLIENTS	usually the same as maxspeachlen
SIPSettings	REENABLEDOSBLOCKED	reenable blocked endpoints after this interval. defaults to 12 hour
SIPSettings	REGISTERIVAL	upper registration interval in msec. defaults to 40 min
SIPSettings	RELOADPROXYLISTIVAL	reload proxies from the config
SIPSettings	REPOPUPULATEFDSETIVAL	used for rtp routing
SipSettings	REPOPUPULATEFDSETIVAL_MAIN	used for main routing
SIPSettings	rerouteon	rerouting behaviour: 0=disabled 1=onlyifset (on busy
SipSettings	resolvedns	resolve uri domain names
SipSettings	ringtimeout	sip calls ring timeout
SIPSettings	routepresence	route subscribes
SipSettings	rtpsendonlytorec	send the rtp only to the rec address
SipSettings	rtpwritefirst	send a rtp packet after connect (to open NAT)
SipSettings	sdpalthandling	0=not handled
SipSettings	sessiontimer	0: don’t use
SipSettings	sipmsgresendcount	resend sip message count
SipSettings	sipmsgresendival	sip message resend timer
SipSettings	sipsendtodefport	try to send to port 5060 too
SipSettings	statussaveival	minutes. used when predective is active
SipSettings	supportlist	privacy
SIPSettings	traceep1	user id
SIPSettings	traceep2	user id
SipSettings	udpkeepalive	send keepalive messages
SIPSettings	udppriority	rtp thread priority: 1=normal
SipSettings	upperexpire	register expire
SIPSettings	usedateheader	send date to user agents
SIPSettings	userofflinemin	enduser will be considered offline if no register or invite for this period
supervisor	canrestartformalfunctions	if supervisor can do restarts. 0
supervisor	checkcallerids	check only this cdr records
supervisor	checkprefixes	check only this cdr records
supervisor	maxnocdrmin	restart if no cdr records
supervisor	minacd	min treshold
supervisor	minacl	min treshold
supervisor	minasr	min treshold
supervisor	peaktimeendtr	peaktime end hour
supervisor	restartatnight	if to restart at every night
supervisor	restartpcatfirst	don't restrart the service. restart the pc immediatly
supervisor	trafficammount	0=after setup
supervisor	weekendispeak	treat weekend as peaktime (same traffic ammount)

Other config options:

Show/hide child’s and spouse from accept action:

„showspouoseandchild:

0=don’t show,1=show only spouose, 2=only child, 3 = show both of them.

default value is: 3

4.7.2. Direct Query

From this form, direct SQL queries can be done against the Mizu backend. Use it carefully!

4.7.3. Voice Here

With this utility, the conversations on Mizu gateways can be listened in real-time.

voicehere

4.7.4. Test Call

H323 test calls can be done here.

4.7.5. Rfile system

Upload/download files from gateways.

4.7.6. Rdesktop

Use this form to login directly in gateways and on the server.

4.7.7. DB Admin

Database administration tool. Only for database experts!

4.7.8. Web Admin

Direct link to the Costumers website if you have any.

4.7.9. Phone Numbers

Numbers allocated by authorities. You may add new endusers with telnumbers set to a free number from this database. Don’t forgot to set the “free” field to 0 if the number is allocated to an enduser.

The web interface will get free numbers for newly registered users from this database too.

4.7.10. To-do

You can define tasks for technical support with the ease of this form.

4.7.11. Notes

Any quick note here to be shared between the support and admin users.

4.7.12. Holidays

Mizu server can treat holidays as weekend in routing and billing if the “autoholiday” global config is set to “1”.

If the autoholiday is set to 0, than you can configure the holiday routing and billing manually (by selecting the “holiday” pattern from the time pattern list)

In the “Holidays” Form you can set the holidays.

The isholiday value can have the following values:

1: the time period is considered as holiday

0: the time period is considered as workday (even if is weekend)

Then you must set the time interval (fromdate-todate).

Prefixlist can contain ‘*’ or 2,3 or 4 digit prefixes separated by comma.

If the prefix list is empty or it contains ‘*’ than will be applied to for all directions.

4.7.13. Allocating numbers

Allocated and used phone numbers can be tracked on the “Phone Numbers” form.

Numbers allocated to users or sipproxyes must be marked (set “free” to 0)

The location can contain the id of the user where the number belongs. This is very important for sip proxy users where the number is not stored as the record username or number (usually for virtual servers). If set so, the server will know where to route the incoming call. Otherwise the routing must be configured in the MManage.

4.7.14. Scheduled tasks

With the scheduled tasks form you can define tasks that will be executed by the server at regular time intervals. Two type of task is allowed: launching as program or running an SQL command.

Depending on completition the server can initiate the following actions:

o Send Email

o Send SMS

o Ring a phone number

o Restart the VoIP service

o Restart the SQL service

o Reboot the server

For SQL the condition will be success if the first field value is a positive number (first row/first col). Otherwise (no record, null record, non number, zero or negative number) the result will be treated as “fail”.

The following keyword can be used with the email and sms actions:

· SQLRESULT: will be replace with the sql query result set (all rows and columns)

· {FIELD}: any field returned by the query (replace the FIELD with a valid returned field from your query)

· {SQL}: any SQL result (replace the SQL with a select statement like {SELECT TOP 10 * from tb_cdrs})

· USERID: it can be used in the above SQL to be replaced with tb_users.id if the query was against tb_users