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.10.2 Administrator’s Guide

Revisited June 1, 2025

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.

Most of the code have been written by us (Mizutech SRL) from scratch, but the software also uses the following open source code or binaries:

o G.711 codec: by Sun Microsystems Inc provided for “unrestricted use"

o G.729 codec: based on ITU-T G.729 Reference C code

o GSM codec: GNU Lesser General Public License version 2.1

o Speex and OPUS codec: by Xiph.Org Foundation license

o Freeswitch: MPL 1.1 license (some unmodified modules as-is)

o OpenSSL: Apache License

o OpenH323 (used in test tools) are licensed under MPL 1.0

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)

Ø Failovering (multiple levels)

Ø Least Cost Routing

Ø BRS -quality based routing

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

Ø Call routing based on PLMN tariff packages

Ø Blacklist/White list filtering

Ø Time of Day Routing

Ø Direct Inward Dialing (DID)

Ø Route capacity

Ø Outbound Dial Map

Ø Speed Dial Numbers

Ø Auto call forwarding

Ø ANI Routing

Ø IP Blacklists

Ø Custom VoIP Providers

Ø Fraud detection tools

Ø Support for NAT traversal

Ø Automatic capacity rebalancing
Remote Linked Servers

Ø Automatic channel management

Ø Number portability support

Ø User authentication by username/password, IP address, techprefix, 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

Deprecated!

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

-distributed architecture

Built in watchdogs to monitor the operation of the system components

GSM features

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

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

Ø SIM server support

Ø Integrated antenna splitter

Ø 8 channels/box

Ø Up to 8 SIM cards per engine

Ø Multiple ways to handle incoming calls

Ø Call Forwarding

Ø Sending and receiving SMS messages

Ø Email To SMS Feature

Ø Inter gateway SIM routing

Ø SIM server interworking

Ø GSM cell selection and locking

Ø DTMF send/receive

Ø CLI restriction

Ø SIM Rerouting

Ø Locking to a given gsm cell

Ø Automatic SIM credit request and charge

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

Ø SIM server interworking

Ø Virtual Channels

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

Standard SIPS/TLS/SRTP are fully supported by default.

An additional tunneling and encryption module is 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

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

Ø Best Route Selection

Ø Billing module

Ø Balance module

Ø Real Time Capacity check

Ø Ability to insert queries directly into the database

Ø Blacklist filtering

Ø Self-analysis tools

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

Ø Call simulations

Ø Reseller/Agent Registration and Management

Ø Capacity and system load reports

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

Ø CRM Integration

Ø Restore and Backup

1.2.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 than 100 simultaneous 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. Tutorial

This VoIP server tutorial is a shorter comprehensive guide to cover the most important topics about the VoIP server usage.

The tutorial have been migrated into a separate document available from here:

https://www.mizu-voip.com/Portals/0/Files/mizu_voip_server_tutorial.pdf

4. Administration

This chapter discusses the administration details of the VoIP server.

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 is part of the VoIP server or it can be downloaded separately from here.

The software is shipped as a standard windows install package. The requirements are the followings:

-Windows 2000/XP/Vista/Win7/8/10/11/2003/2008/2012/2014/2016/2019/2022/2025

-At least 1024x768 screen resolution for better operation

-You may need a headset for test calls

-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

-Database connectivity tools

-VoIP client utility programs (SIP, WebRTC and H323)

-Utility programs: geoip, tariffcalc, smtptest, rptest, pdfcreator, sqlrouter, vpc 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:

Server: server address

Instance: application and database instance (a single server can hold several virtual server)

Username: login name

Password: login password

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 data sources which 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 (failovered), 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.16. Alerting

Admins and support users can receive email, sms and/or push notifications about important events such as critical problems, malfunctions and other server-side issues. Search for “sendalert” on the Configurations form for the related settings:

· sendalert: 0: no, 1: to support only, 2: filtered important errors only (DEFAULT), 3: unfiltered/all errors, 4: all

· sendalert_usr: send alert about user/trunk related issues. -1: auto (DEFAULT to sendalert_maxcount/3), 0: no, 1+: max per day

o sendalert_usr_once: only one message per user. 0: no, 1: yes (DEFAULT)

· sendalert_srv: list of id's or username's to watch (of sip servers). alert will be sent on [not reachable AND sendalert_srv_minfailedcalls subsequent failed calls] OR [on sendalert_srv_maxfailedcalls]

o sendalert_srv_minnoanswer: minimum number of no answer count. default is 5. set to 0 to disable

o sendalert_srv_minfailedcalls: if set to 0, then will trigger alert on first unreachable, otherwise we must also have this number of failed call. default is 20

o sendalert_srv_maxfailedcalls: def is 600. set to 0 to disable

o sendalert_srv_mincallduration: minimum call duration in seconds to treat it as connected call. default is 20

o sendalert_srv_mintime: min time in seconds from first failure (so the failed state must be at least this long before to trigger an alert)

· sendalert_email: 0: no, 1: yes (if email account is configured. otherwise will use cmailer for a while only) (DEFAULT)

· sendalert_sms: 0: no, 1: yes (if sms is configured) (DEFAULT)

· sendalert_push: list of push accounts (id's or username's)

o sendalert_push_via: send push via our gateway if it doesn't have push capabilities. -1: auto (1), 0: this server only, 1: via mizu gateway if this server doesn't have push or fails, 2: via mizu gateway only, 3: via both local and mizu gateway

o sendalert_mzpushallow: allow sendapush ip list (to be configured on mizu push server only at fcm.webvoipphone.com)

o sendalert_mzpushblock: block sendapush ip list (to be configured on mizu push server only at fcm.webvoipphone.com)

· sendalert_to: 0: admin users only, 1: support users only, 2: both (DEFAULT)

· sendalert_maxcount: max message per day -1: auto (DEFAULT), 0+ exact value

· sendalert_delay: minimum time between alerts in minutes. default is -1 which will default to 30 minute

· sendalert_ignoreusrsetting: 0 to check tb_users.sendsmsalert and sendemailalert, 1 to ignore (DEFAULT)

· sendalert_mizusupport: -1 auto (DEFAULT), 0 to disable alerts to mizutech support user, 1 to enable

An email account should be configured for the server to be able to send the email notifications, otherwise the built-in cmailer@mizu-voip.com email account might be used for a while. An email account can be configured from the Config Wizard or by the emailhost, emailuser, emailpassword and other email related global settings from the Configurations form.

Push notifications can be sent to registered accounts with the with the ntype/TYPE parameter set to 3. Details here. If push is not configured on the server, then the notifications can be sent via the mizutech SIP PUSH proxy service.

The supervisor thresholds can be configured as described here.

The following commands can be sent from the Server Console for testing.

o Send push notification: sendpushu,3,from,to,msg

o Send push notification via mizutech proxy: sendpushmz,users,subject,msg

o Send alert notification: sendalert,subject,msg

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 authentication 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 empty 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 outbound 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 properties 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

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 commission percent from the enduser price

Reduction: sales user can give to enduser some percent (subtracted from their commission)

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 (or * if to forward to “best” child user)

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 failover

minacl: minimum acl before failover

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 possible 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 accounts. Will send sms notification to the configured “phone” when a critical error occurs

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

sendsmsreport: send daily sms report

senddailyemail: send daily email report. 0: no, 1: yes, 2: include also CDR’s, 3: save only to file

sendmonthlyemail: send monthly email report. 0: no, 1: yes, 2: include also CDR’s, 3: save only to file

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

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

o 0: don’t use

o 1: load from global config

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

o 3: force

o 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 keep-alive is not the same with NAT keep alive (which 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 authentication 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 -> Settings page.

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 TelNumber 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 explicitly 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_telnumbers

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

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 explicitly 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 nightly)

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 network (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

Phone numbers can be stored in tb_telnumbers and managed from the “Phone numbers” form.

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)

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

-use it as the “username” field

-set the “telnumber” field

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

API

See the “Assign phone number to users” section in the API documentation for the related API’s (getphonenumber/lockphonenumber/assignphonenumber)

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

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: Open 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 a usual firewall, 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 trusted 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 CallerID setting):

replacecalleroncalls:

(user and global setting)

0 No (Keep from the client)

1 Default checks

2 Use the Username

3 Use the TelNumber

4 Use the best number

5 Use the first good number

6 Replace with the Username if not a phone number

7 Replace with the TelNumber if not a phone number

8 Anonymous

9 From header

10 Contact header

11 Remote-Party-ID header

12 Best from client ep

13 Best from all (default)

14: Called party Username

15: Called party TelNumber

Default is: 13.

If the replacecalleroncalls/CallerID setting is set for both the caller and the called user, then it will prioritize the SIP Server setting if any, otherwise the caller user setting. This prioritization can be changed with the replacecalleroncallspriority setting.

replacecalleroncallspriority:

-1: auto (defaults to 8), 0: never (disable), 1: global config only, 2: called only (don't load caller setting), 3: caller only (don't load called setting), 4: prioritize caller, 5: prioritize called, 6: prioritize enduser, 7: prioritize traffic sender, 8: prioritize sip server (def)

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)

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

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

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 and the How to rewrite caller/called numbers FAQ point 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, especially 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 usually 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)

You can also use SQL statements in action strings curly braces. See the How to set a random caller-ID FAQ point as an example.

Keywords can be also embedded in square braces. See the endpoint keywords in the Keywords chapter for the possibilities.

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:

-Failovering: when a device or a device/direction is in failovered 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 failovered -value lower or higher than the current date-time (for automatic failovering)

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

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

SimPacket is not failovered

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 fine-tune 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. Failovering

Mizu server and gateway will make automating failover between outbound gateways if the “CAN_failover” and “hasfailover” global configuration settings are set to true (they are true by default).

The following failovering procedures are done by the mizu voip server:

-gateway failover: when an outbound gateway has wrong global statistics

-direction failover: when only a few direction (prefix) statistics are wrong on an outbound gateway
-failover on subsequent called number
-in-call failover (this is also called as “rerouting”)

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

Failover 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 failovered. 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 failovered (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 failovering are based on ASR, ACD statistics and if there is predefined subsequent wrong calls to a direction. Once a route is marked as failovered, 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 failovered. This routes can be reseted only manually from the failovering 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 “Failovering” 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: failovering 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 failovering to work correctly:

-the server must have enough call to calculate relevant statistics (this can be fine-tuned from the “Failovering” form) ; the default are optimized for medium traffic amount
-some time must elapse for a route to be marked as failovered (too aggressive settings might result in false failovering)

-you must have at least one secondary gateway/direction where the traffic can be failovered

You should not build your entire business based on the correctness of the failovering 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)

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

Other important failovering process is the “in-call failovering” 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)

This can be enabled by the configuration wizard or from the global configuration by the following options.

-allowreroute: -1: auto: if multiple routes found, 0: no, 1: yes-auto on reject, 2: yes-auto also on answer timeout, 3=yes-must always

-maxreroute: how many time a call can be rerouted

-rerouteon: on which conditions a call will be rerouted (0=disabled 1=onlyifset (on busy, on noanswer) 2=on server timeout 3=on server error 4=on all errors)

-reroutedisccodes: disconnect codes to be received for the rerouting

-noreroutedisccodes: define disconnect codes when there will be no rerouting

-rerouteconnected: specify if connected calls can be also rerouted (-1: auto, 0: no, 1: half, 2: yes, 3+ max call duration)

The rerouting is usually enabled by default (depending on your server type and enabled modules) or you can enable it by modifying the above settings. All these setting are set by default to optimal values which might be modified after your requirements.

Note: failovering 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)

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

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

The server is capable to handle WebRTC-WebRTC routing or transparent SIP to WebRTC or WebRTC to SIP conversion.

The WebRTC module description have been moved to a separate document:

https://www.mizu-voip.com/Portals/0/Files/WebRTC_SIP_Gateway_Doc.pdf

The above document focuses on the MRTC gateway, but most of it applies to the VoIP server as well.

4.7. Push notifications

The Push module description have been moved to a separate document:

https://www.mizu-voip.com/Portals/0/Files/VOIP_Push_notifications.pdf

The above document focuses on the MPUSH gateway, but most of it applies to the VoIP server as well.

4.8. Other –MManage

Other not so important MManage modules are described below.

4.8.1. Configurations

Global system configurations.

Basic configuration are vital for the system to run correctly.

A list of settings are described below. New versions usually adds also more configuration options which you can find from the Configurations form.

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_failover	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	hasfailover	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	checkpacketfailovering	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	convert 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.8.2. Direct Query

From this form, direct SQL queries can be done against the Mizu backend. Use it carefully!

4.8.3. Voice Here

With this utility, the conversations on Mizu gateways can be listened in real-time.

voicehere

4.8.4. Test Call

VoIP test calls can be done here.

4.8.5. Rfile system

Upload/download files from gateways.

4.8.6. Rdesktop

Use this form to login directly in gateways and on the server.

4.8.7. DB Admin

Database administration tool. Only for database experts!

4.8.8. Web Admin

Direct link to the Costumers website if you have any.

4.8.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.8.10. To-do

You can define tasks for technical support with the ease of this form.

4.8.11. Notes

Any quick note here to be shared between the support and admin users.

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

· ***SUBJECT: anysubject (to specify a subject for the message

· ***TO: email@domain.com (to specify an exact address for the message to send to. Otherwise it is sent to admins and support)

· ***TO: USER: this is a special keyword if your query is against the tb_users table so all record will be processed separately and the message will be sent to current user email or phone.

For example to send daily notifications to users with credit below $10, you might set the followings (you need to create a lastemailnotificationsent field in tb_users):

· Interval: daily

· Type: conditional

· SQL Query: select id,email,name from tb_users with(nolock) where credit < 10 and postpaid < 1 and enabled <> 0 and temporarydisabled <> 1 and lastemailnotificationsent < getdate() - 10

· Action On Succ: email

· Action On Fail: no action

· Message body:

***SUBJECT: Low Credit on VoIP

***TO: USER

Dear {name}

Your credit is {credit}

{update tb_users set lastemailnotificationsent = getdate() where id = USERID}

Example to use SQL keyword (sending the last called number for a users every night):

· Message body:

***SUBJECT: Your last call

***TO: USER

Dear {name}

Your last call was made to {select top 1 callednumber from tb_cdrs with(nolock) where datum > getdate()-1 and callerid = USERID order by datum desc}

4.9. Call Center

This section will describe the outgoing callcenter module but can also be useful to read when using the incoming callcenter module (e.g. IVR)
The Mizu callcenter combine the maximum efficiency with easy to use, intuitive interfaces.

Statistics can be viewed in real-time. See Callcenter Statistics for more details.

4.9.1. Users

Will load the callcenter operators (agents). Here you can add, delete and edit them.

The basic settings are placed on the Edit Operator tab. SIP enduser related settings can be edited on the Advanced tab.

With the Campaign drop-down list you can assign the selected operator to a campaign.

Operators must have entered and quit date set correctly. (If the quit date is elapsed, than the operator is not allowed to work with MAgent)

Technically operators are just sip endusers (tb_users.type =0) by the isoperator flag is set to 1.

4.9.2. Campaigns

You can setup the campaigns in this form.

Campaign will start to run when the StartDate is reached and will run until no more clients (phone number) are assigned or the EndDate was reached. This means that MAgent -> Automatic Calls will run if this conditions are met.

The “Display” field will be displayed for the operators in MAgent “Automatic Call” window.

By clicking on the “Load Statistics”, a sort statistics window will be displayed regarding the selected campaign.

Handling invitations:

Load Invitation: will download the assigned invitation from the database. This can be any file, but Microsoft Word document are preferred.

Save Invitation: will save the document back to database. Prior to hit this button, the document must be edited, saved and closed.

Print Invitations: will print a separate invitation for all invited clients in this campaign.

You can use special keywords in word documents and that will be replaced with the corresponding value. See the Keywords section for more details.

4.9.3. Scripts

Every campaign can have different operator instructions. These instructions can be defined in this form.

For every step (question) the operator can select from different actions (answers). The call will follow these selected instructions. Pay attention to cover all possibilities.

tb_ccscripts: (used for questions)

id: autoincrement PK

campaignid: the campaign where this script belongs to

ordernum: display order (used when jumping to next question)

title: script alias. also used for statistics

question: question in text format (can contain keywords. see the Keywords chapter for more details)

questionex: the question in rtf or html format

completition: completition marks can be used for statistical purposes.

oldid: used for cloning

datainputtype: used to control the gui for the anwer

-----SIMPLE-----

Text

Number

Date

Time

Date-Time

Phone Number

CheckBox

-----LISTS-----

CheckBoxList

ListBox

RadioGroupList

DropDownList

DropDownListFixed

-----GRIDS-----

RadioGrid

CheckGrid

-----COMPLEX-----

Custom GUI

Run

-----ACTIION-----

ActionRecall

ActionReject

ActionAccept

tb_ccscript_answers: (used for answers)

id: autoincrement PK

questionid: answer belongs to this question

ordernum: display order

answer: the answer text

alias: will be stored as answer (usually the same as the ‘answer’)

actioncontext: can be used for storing reject reasons or for data imput field specification

fields: used grids to determine its columns. Values must be separated by comma ‘,’ or semicolon ‘;’

jumpto: next presented question. possible values:

-3: no jump

-2: jumt to next question

-1: finished

-4: finised with voice

-5: jump forward

other: questionid

endcode: the endcode for the last answer (with a valid code) will be stored for statistical reasons. if you specify more endcodes, the last endcode will be stored in the database.

entercondition: simlple sql clause. if the condition result is true, than will jump to question ‘onconditiontrue’, othervise will jumpt to ‘onconditionfalse’

entercondition rules:

1. any sql in the following format: select … (if return 0 than the result will be interpreted as false, othervise as true)

2. simplified condition. can use the following keywords:

prefixes:

any database table name (tb_cclient, tb_ccampain_clients, etc)

script (maps to scriptquestion.alias - scriptanswer.alias)

client (maps to tb_cclient)

cclient (maps to tb_ccampain_clients)

campaign (maps to tb_cccampaigns)

quotacount, quotapercent, completedcount, completedpercent, averagequotacompletition

suffixes: script alias names or table fields name

operators and functions: most of sql92 keywords will work (=, <>, <, (,),TRIM, LOWER, AND, OR, etc)

examples:

1. (script.alias = ‘fidesz’ or scriptcode.alias = 3 or quotacount.quotaalias >0) and (LOWER(client.name) = ‘john’)

2. quotacompletedpercent.quotaalias < 100

see the keywords section for more details!

onconditiontrue: if the entercondition result is true, than the next question will be the question with this order (ordernum)

onconditionfalse: if the entercondition result is false, than the next question will be the question with this order (ordernum)

Running external applications:

set the datainputtype to “Run”

specify application name and parameters in the “Command” field.

keywords can be used as part of command.

the following Parameters are defined (separe them with comma)

-hide: will launch the application hided

-wait: will wait for the application to terminate

Text Mask:

Use EditMask to restrict the characters a user can enter into the masked edit control to valid characters and formats. If the user attempts to enter an invalid character, the edit control does not accept the character. Validation is performed on a character-by-character basis by the ValidateEdit method.

A mask consists of three fields with semicolons separating the fields. The first part of the mask is the mask itself. The second part is the character that determines whether the literal characters of a mask are saved as part of the data. The third part of the mask is the character used to represent unentered characters in the mask.

These are the special characters used in the first field of the mask:

! If a ! character appears in the mask, optional characters are represented in the EditText as leading blanks. If a ! character is not present, optional characters are represented in the EditText as trailing blanks.

> If a > character appears in the mask, all characters that follow are in uppercase until the end of the mask or until a < character is encountered.

< If a < character appears in the mask, all characters that follow are in lowercase until the end of the mask or until a > character is encountered.

<> If these two characters appear together in a mask, no case checking is done and the data is formatted with the case the user uses to enter the data.

\ The character that follows a \ character is a literal character. Use this character to use any of the mask special characters as a literal in the data.

L The L character requires an alphabetic character only in this position. For the US, this is A-Z, a-z.

l The l character permits only an alphabetic character in this position, but doesn't require it.

A The A character requires an alphanumeric character only in this position. For the US, this is A-Z, a-z, 0-9.

a The a character permits an alphanumeric character in this position, but doesn't require it.

C The C character requires an arbitrary character in this position.

c The c character permits an arbitrary character in this position, but doesn't require it.

0 The 0 character requires a numeric character only in this position.

9 The 9 character permits a numeric character in this position, but doesn't require it.

# The # character permits a numeric character or a plus or minus sign in this position, but doesn't require it.

: The : character is used to separate hours, minutes, and seconds in times. If the character that separates hours, minutes, and seconds is different in the regional settings of the Control Panel utility on your computer system, that character is used instead.

/ The / character is used to separate months, days, and years in dates. If the character that separates months, days, and years is different in the regional settings of the Control Panel utility on your computer system, that character is used instead.

; The ; character is used to separate the three fields of the mask.

_ The _ character automatically inserts spaces into the text. When the user enters characters in the field, the cursor skips the _ character.

Any character that does not appear in the preceding table can appear in the first part of the mask as a literal character. Literal characters must be matched exactly in the edit control. They are inserted automatically, and the cursor skips over them during editing. The special mask characters can also appear as literal characters if preceded by a backslash character (\).

The second field of the mask is a single character that indicates whether literal characters from the mask should be included as part of the text for the edit control. For example, the mask for a telephone number with area code could be the following string:

(000)_000-0000;0;*

The 0 in the second field indicates that the Text property for the edit control would consist of the 10 digits that were entered, rather than the 14 characters that make up the telephone number as it appears in the edit control.

A 0 in the second field indicates that literals should not be included, any other character indicates that they should be included. The character that indicates whether literals should be included can be changed in the EditMask property editor, or programmatically by changing the MaskNoSave typed constant.

The third field of the mask is the character that appears in the edit control for blanks (characters that have not been entered). By default, this is the same as the character that stands for literal spaces. The two characters appear the same in an edit window. However, when a user edits the text in a masked edit control, the cursor selects each blank character in turn, and skips over the space character.

Setting EditMask to an empty string removes the mask.

tb_ccscript_processing: (used for storing answers)

id: autoincrement PK

datum: row age

operatorid: the id of the caller operator

clientid: the id of the called client (from tb_cclient)

ccid: campaign_client foreign key

questionid: the id from tb_ccscripts

answerid: the id from tb_ccscript_answers

answervalue: entered value (saved as text, but can represent other data type. for example date-time)

Note:

data inputs can be saved to tb_cclient or tb_campaign_clients if specified so. column names must be prefixes with client. or campaign. keywords. see the keywords section for more details

all script answers (including data input) will be saved to tb_ccscript_processing

list answers will be separated by semicolon ;

grid answer will be saved in separate columns where the column title will be the tb_script.title + the grid column title

4.9.4. GUI Designer

The MAgent Automatic Call form user interface can be customized in the MManage -> GUI Designer.

Basic MSWindows controls and specific controls are supported.

Note: the dynamic MAgent gui will be loaded only if the “autoformname” setting is set to “dynamic”. Otherwise other company specific form will be loaded.

Typical workflow:

1. Load a default gui from file

2. Drag and drop controls on the gui area

3. Set controls properties

4. Save the new gui in the database (the “New” checkbox must be checked, otherwise will overwrite!)

5. Set campaign gui to the newly created one (or set it to a script question as a data input gui)

Text controls can contain dynamic data if the control “Data” properties are defined in the following way:

-[tablename.fieldname]: simple map to the required field

if the control is not read-only, than the edited value will be saved back in the database

-[select …]: any select condition

-only the first column in the first row will be considered

-keywords (see the Keywords chapter)

Specific controls:

-Script question: space for displaying script questions

-Script answers: answer list. Deprecated!

-Script data: space for displaying script answers and choices

-Recall label: will display the call “recall” status

-ProgressBar: for displaying the call progress (the position in the script)

-Ok: save script answer and jump to next question

-Skip: jump to next question without saving the current

-Hangup: dropp the current call

-Pause: no more new calls

-Next Client: force jump to next client (will hang-up the current call if any)

-Recall: set client for later recall

-Reject: will set the rejected flag

-Hold: call hold (mute all directions)

-Display call status: display called party name and call duration

-Call Statistics: operator statistics

4.9.5. Quotas

You can define campaign target quotas by launching the “CC Quotas” form from MManage.

By defining quotas, you can restrict your calls to well defined target groups (called clients).

Database fields:

id: autoincrement PK

~~allowed: deprecated~~

campaignid: foreign key to tb_cccampaigns.id

alias: the name of the quota (any string here)

condition: sql clause applied for tb_cclient and tb_ccampain_clients. All separate expressions must be included in barckets!

found: found clients after fixed condition
quotacount: number of desired interviews

quotapercent: percent of desired interviews from global quota. the global quota can be specified in the campaign settings, or is calculated automatically

status: any number. you can refer to it from scripts. for example when you don’t want more calls for a quota, set the status to 1

and check it in the script enter condition (if quotastatus.myalias = 1 than jump to finish)

~~autobalace: calls will be automatically balanced based on condition (if the condition can be evaluated)~~

~~othervise the quota completition percent doesn’t effect the calls~~ deprecated

completedcount: number of completed interviews

completedpercent: competed interviews in percent

enabled:

-0: ignored (instead of deletion)

-1: ignored on server (but can be referenced from scripts)

-2: default

Block: if set to 1, than calls to clients that meets the quota condition will be disallowed

Autostop: if set to 1, than call will be blocked when the completedpercent reach 100%

Either quotacount or quotapercent need to be specified.

If the global quota for the campaign is not specified, and only the quotapercent is specified for the campaign, than the quota will remain invalid.

Note: call record must reach a completition question to be valid in quota calculations

4.9.6. Presentations

Used to store the different presentation locations. When a client is invited, the operator will select a presentation for them.

Presentation can be selected dynamically in MAgent by setting the sql condition in the script form.

It can be done by tree way:

1. leaving empty

In this case the following query will be run: select top 150 id,Name,startdate,remainusers,comment from tb_ccpresentations with(nolock) where > getdate() and campaignid = :assignedcampaign order by startdate, name

2. using only the sql clause

for example: name like ‘%hotel%’

the default clause is: startdate > getdate() and campaignid = :assignedcampaign

3. using a complete sql.

In this case the “id” and a “displaytext” field must be returned.

Example: select id, name+’ ‘+comment as displaytext from tb_ccpresentations where name like ‘%hotel%’

The usual keywords can be embedded in the sql scripts. See chapter Keywords.

4.9.7. Checklist

Can be used in presentations to print the list of invited users.

Status texts can be configured in tb_ccstatus. To be compatible with other version, change the texts to correspond with the original without changing the statusid.

The “Print Invitations” button will print all invitations in the selected campaign/checklist whose status indicated that it was not printed prior.

4.9.8. Clients

The client (phone number) database.

Clients can be assigned and/or reassigned to campaigns with the ease of this form.

You can search across client by a lot of condition presented on this form.

By selecting the “Last Status” filer, the users can be searched by the reason code in the last campaign

By selecting the “Any Status” filer, the users can be searched by the reason code in any campaign

Importing client database can be done from external csv or dbf files. These files must have the following fields:

CSV file columns (must be in this order):

-Name (string)

-Landline phone number (string)

-Mobile phone nuber (string)

-Zipcode (short string)

-City (string)

-Age (number)

-Passport (0 if unknown, 1 if no or 2 if yes)

-Married (0 if unknown, 1 if no or 2 if yes)

-Sex (0 if unknown, 1 if no or 2 if yes)

-Robinson (0 if unknown, 1 if no or 2 if yes)

-Address (string)

-Comment (string)

DBF files must contain the following columns (can contain other columns too):

-UNEV: user name

-TEL: phone number

-VAROS: city

-UTCA: address

-ROBIN: robin

-IRSZ: zipcode

At least the landline or mobile phone must contaion a valid entry.

4.9.9. Campaign Clients

For every campaign clients must be assigned. This means loading records from tb_cclient to tb_ccampain_clients. Records from tb_cclient are usually not modified during the campaign. All modification will be done in tb_ccampain_clients and in tb_ccscript_processing (scrip answers).

tb_ccscript_processing database fields:

id: PK, unique identifier (autoincrement)

campaignid: foreign key pointing to tb_cccampaigns.id

clientid: foreign key pointing to tb_cclient.id

clientname: first characters from tb_cclient.name. (denormalized here for speedup)

datum: client record assigment date

operatorid: last operator who have called this client

aquired: used in automatic calls for record locking. deprecated.

enabled: if 0, than this client will not be called again

calltrycount: number of call attempts

recalltrycount: number of recall attempts

lastfailtype: wich number has failed last time (0=unknown,1=mobile,2=landline)

called: the client has been called successfully

needrecall: 0: no need for recall, 1=recall set manually by the operator, 2=recall automatically due to unhandled incoming call,3=other recall reson, >=4: already recalled

recalldate: date-time of the next recall attempt

lastcalldate: date-time of the last call attempt (successfully or failed call)

comment: any comment (can be filled by operators)

randorder: deprecated

numstatus: wich number is present. 0=both are missing,1=only landline,2=only mobile,3=both (denormalized here for speedup)

guidrand: used when clients need to be called randomly (not in database or A-Z order)

rejected: 1 if the call was rejected (rejected by user not by the phone)

rejectedreason: optional comment when rejected

4.9.10. Campaign and global settings

Allowdbcalls: allow calls from database in MAgent

Allowmanualcalls: allow manual calls in MAgent

Callmaxring: max ringtime when automatic calls in sec

Callnumbertype: 0=start with landline, and if fail, call mobile, 1=start with mobile, and if fail, call landline, 2 =call only landline, 3 = call only mobile

Maxcalltrycount: max number of calls to a client (except recalls).

Maxrecalltrycount: max number of recalls to a client.

Recallrestrictions: 0=try to recall with the same operator, but allow other if no recall, 1 = only with the same operator, 2=any operator can recall, 3 =disable recalls

Predectivedial: predective dialing: 0=don't use, 1=onfree, 2=onfree + periodic,3=periodic,4=automatic,>4=automatic will switch to 2 if this number is operator reached

predectivelogging: will save detailed logs about predective activities and statuses

waitforpredective: timeout in sec to wait for a free operator on connect. 0 disables waiting. -1 will disconnect all calls in progress (ringing) when there are no more free operators.

Predectivecorrection: initiated call count correction in percent (for example 80 will generate calls faster by 20%)

Callbackhandling: 0=dropp calls, 1=forward to the same UE if exists, 2=forward to a free operator, *3=try to forward to a operator but on fail route to the same UE, 4= forward to UE and if not exists than to a free operator , other=forward to the specified number

Callbacknumber: special threatments when this number is called. When the predective caller user is already created, than the callbacknumber is its username

Callbackroutenumber: called operator when callbackhandling is 1,3 or 4. defaults to callbacknumber

ccorder: determine how clients are loaded

0: campaing client id

1: load calls from A to Z

2: load calls from Z to A

3: load calls in random order

Other: not ordered

waitifnotconnected: wait after calls (callmaxwait sec) even if it is not connected (to allow opertor work)

callbackringtimeout: ring timeout on callback (after than play ivr message if set)

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

callbackivr: play special messgae (callback.wav) if no operator found or ring timeout expired

callbackhandling: 0=dropp calls, 1=forward to the same UA if exists, 2=forward to a free operator, 3=try to forward to a operator but on fail route to the same UA, 4= forward to UA and if not exists than to a free operator , other=forward to the specified number

callbackautorecall: 1= schedule for recall if number is in campaign,0=don't recall automatically

defrecallmin: the callback date-time selector will appear with this default recall minue

maxrecallmin: max minute setting allowed for callbacks in MAgent

finishvoice: calls will be finished with this voice promt

mobileratio_X_Y: the percent of mobile calls between hours X and Y

presentationmode: if to show presentation choice in MAgent

recallonlyinsamecampaign: recalls allowed from other campaigns too

desireddropprate: optimal percent of calls wich cannot be assigned to operators (-1: disable, -2: dynamic)

maxcallsperminute: max new call attempts/minute (-1: disable, -2: dynamic)

maxcallatonce: max call launch/branch (used for additonal checking)

statival: statistics recalculation interval in sec (-2: dynamic)

stopwrongcdrc: will pause predective execution for 15 minute if subsecvent “stopwrongcdrc” calls are less than 8 sec to guard agains service provider error

scriptnavigation: allow script navigation in MAgent (0=no, 1=only forward, 2=only back, 3 = forward&back, 4 =all navigation, 5=allow navigation when not connected, 6=allow edit too)

datainputmode: 1=store only in client and cc_client tables, 2=store in cc tables and to default field to, 3=store in cc tables and in script processing, 4=store in all locations

savemode:

1=automatic –will save on when moving to next question (don’t display ok button)

2=save only when the ok button was pressed

3=with skip button

4=ok+automatic

5=cannot skip. user must press ok button to be able to move to next question

blockrejected: when the tb_ccampain_clients.rejected is set to 1 by operators, than will set tb_cclient.robinson to 1 automatically

loginmessage: message to be displayed for the operators on MAgent launch

allowopcampchange: allow operators to change their campaign

maxrecallbefore: callbacks can be initiatet “maxrecallbefore” minute before the specified time

maxrecallafter: callbacks can be initiated by the operator untill “maxrecallafter” minute after the specified time. if the operator is not able to receive the call, than the call will be offered to other operators after maxrecallafter elapsed (and untill maxrecallafterall)

maxrecallafterall: callbacks will be invalidated if not able to give to any operators when this timeout elapse

quotastatrecalcival: quota statistics recalculation intervall (specified in second)

Note: the predictive dialer is not so precise when started after a long time of inactivity. Accuracy also depends on the number of operators (more operator means more accuracy).

4.9.11. Predictive dialer

To restrict the operator wait times, the calls can be prepared on the server side and dropped to operators when they are waiting for it.

There are separate predictive threads for all campaigns. The campaign predictive related settings will overwrite the global configuration

The predictive thread will check if new calls are needed in every 1-20 sec (varies dynamically)

Calls are started based on the following variables:

-predictive mode

-1: new call will be made only when waiting operators found

-3: new calls will be started regularly based on predictive calculations

-2: mix of 1 and 3

-4: will switch between 1 and 2 dynamically

-operator count (all, active, waiting)

-call statistics (call count, asr, acd, dropprate) calculated on long term, midterm and short intervals

-campaign and global configurations (desireddropprade, etc). Please check Global Settings for more details.

The thread activity can be logged in tb_predectivelogs, otherwise the standard logs can be found when searching to “predictive”.

Calls are started by the PREDECTIVE_DIALER user (this will be created automatically if not exists), so the A number will be its number (loaded from the „callbacknumber” config when created automatically). When the called party pickup the phone, a free operator will be searched and the call will be towarded to it. So the call is already connected when it is presented to the operator. If the operator cannot handle the call, than a CDR record will be generated (usually with a short duration) but with a specified reason code. Another special case is when there is no free operator found when the call is connected. In this case the disconnect reason will be set to „No free operator on predective”.

If the embedded dialer speed dosn’t satisfy your need, you can control the speed by changing the desireddropprate and the predectivecorrection configuration. The predective functionality perform better as there are more operators (more than 10).

Predective related settings:

- Callbacknumber: "A" number for calls. For example the predective dialer will use this number

- Desireddropprate: optimal percent of calls wich cannot be assigned to operators when in predective (-100 has no effect)

- Maxcallatonce: max number of calls in one round when in predective (error guard)

- Maxcallsperminute: max new call attempts/minute when in predective (error guard)

- Predectivecheckival: controlls the speed of the predective dialer thread -advanced technical setting

- Predectivecorrection: correction of precalculated success ratio statistics in predective. for example if we set it to 80, than there will be more calls with 20% than the precalculated optimal

- Predectivedial: dialing mode: 0=simple MAgent requests,1=automatic on free clients,2=predective inteligent, 3=simple predective, 4=set automatically

- Predectivelogging: details of predective logs (0=no logs,1=minimal,2=nnormal,3=max log)

- Statival: rebuild predective statistics interwal (-2 = automatic)

- Stopwrongcdrc: pause predective if the ASR is too low (error guard)

- Waitforpredective: max time to wait for a free operator when a predective call is connected

- Waituntillconnected: if set to false, than will dropp started call when no more operator waiting (no more "No free operator on predective" disconnect reason)

4.9.12. Outgoing callback

There are two types of callbacks:

1. operator set Recall (1) manually

2. server receive an incoming call and set to Callback (2) automatically

Client records will be marked when callbacks or recalls are needed. The following values are defined for the „needrecall” field:

-0: not set

-1: recall set by operator

-2: callback set because incoming call

-4: recalled

-5: callback completed

Callback numbers:

Special A numbers are the followings:

- callbacknumber

- predective dialer number

- identityrewrite number for outgoing proxy

these should be set to the same number. By default it is loaded from „callbacknumber” global setting

*if the callbacknumber is not set, the predictive dialer will use “1111” by default

* identityrwmode global setting should be set to 1 for callcenters

*if the CLI is hided, than there will be NO incoming calls,

to enable CLIP you must set the “identityrwmode” setting to 1 or set the CLI for users to 1

The „callbackhandling” global setting will determine how incoming calls to callbacknumber will be handled. Incoming calls when the caller is not found in any campaign will be inserted to the client table with a name set to “unknown callback”.

Make sure to setup the callback number on the main server to be routed to the actual virtual server! (check faq)

4.9.13. Incoming calls

Incoming calls can be handled in different ways:

1. Simple distribution across operators

2. By specifying a callbacknumber and setting the callbackhandling option.

3. Handling by the IVR

4. Make incoming campaigns

Incoming callers (clients) identity can be loaded from database when the call arrives. If the client data is not found, then can be added to database automatically.

In the MAgent the call can be handled in the following ways:

1. Dropp all

2. Show in Manual Call

3. Show with client data

4. Show in “Auto Calls” with the actual script

The following config settings will be applied:

CampType:

0 or NULL=default

1=callcenter (OUT)

2=IVR (IN) -new numbers will not be requested from the server

3=Mixed -incoming calls can be received from ivr, but from dialer too

Callbackhandling:

0=dropp all

1=route to callbackroutenumber

2=route to free operators

3=route to free operators, and if not answered than route to callbackroutenumber

4=first to callbackroutenumber than to free operators

Callbacknumber:

"A" number for calls. For example the predective dialer will use this number

Callbackringtimeout:

ring timeout on callback (after than play ivr message if set)

defrecallmin ring timeout on callback (after than play ivr message if set) defrecallmin

callbackroutenumber:

number to be dialed on incoming calls when callbackhandling is 1,3 or 4

ivr_addmissingusers: -applicable on serverside ivr calls and in MAgent

0=no -default

1=add to client table

2=add to campaign client

addmissingusersto: -in wich campaign to add the incoming client

0=add to the current campaign (default)

other=add to the specified campaign (campaign id)

Handlingincoming:

0=not handled

1=allow to search the current campaingn for the incomig number

2=allow to search and edit the current campaingn for the incomig number

3=allow to search the whole database for the incomig number

4=allow to search and edit the whole database for the incomig number

5=show scripts form

~~Handlingincoming~~:

~~0=not handled~~

~~1=allowed~~

~~2=show scripts form~~

~~IncSearch~~

~~0=no automatic search~~

~~1=allow to search and edit the current campaingn for the incomig number~~

~~2=allow to search the whole database for the incomig number~~

~~3=allow to search and edit the whole database for the incomig number~~

Incoming campaigns:

1. First you must define your phone numbers wich will handle the incoming campaign(s).

2. If the server is a virtual server, you must setup your main server to route that numbers to the virtserver (See this caption for more details)

3. You must add this numbers to your user list, and assign an IVR for them.

4. For the IVR campaign set the “CampType” field to 2 and don’t forget the ivr_addmissingusers and handlingincoming settings

5. Create the MAgent script and GUI in the MManage.

6. Assign some operators for the campaign(s).

4.9.14. Keywords

The following controls can contain keywords:

-script question

-script answer

-script enter condition

-quota condition

Table name abverbiations:

camp => tb_cccampaigns

client => tb_cclient

campaign => tb_ccampain_clients

script => tb_ccscripts with answertext

scriptcode => tb_ccscripts with code

scriptquestions => tb_ccscripts

scriptanswers => tb_ccscript_answers

quota(s) => tb_ccquotas

The following keywords are defined:

-all database fields from tb_cclient, ccampain, tb_ccampain_clients, tb_ccscripts, tb_ccscript_answers and tb_ccquotas

-[currentnumber] current called number

-[callduration] call duration

-[ringduration] ring duration

-[callstarttime] begin time

-[callcount] number of call attemts

-[currdatetime], [currdate], [currname] current time/date/date-time

-[currweekday], [curryear] weekday, year, month, min, etc

-[bell] bell

-[campaignname] campaign name

-[opusername] operator username

-[opname] operator name

-quotacount

-quotastatus

-quotapercent

-quotacompletedcount, completedcount

-quotacompletedpercent, completedpercent

All ep specific keyword list:

currentnumber

lastforwardednumber

callduration

ringduration

creditdurationmin

creditdurationminminpx

creditdurationminmin

creditduration

creditdurationmin2

creditduration2

maxspeachlen

credit

credit_tospeech_ex

credit_tospeech

bell

companyname

opusername

dtmf

dtmftrimmed

dtmfstored

storedivrstring

storedani

dtmfstoredtrimmed

opname

currdatetime

currdate

currdatetimesql

currtime

currweekday

curryear

currmonth

currday

currhour

currmin

currsec

calleruserid

calleduserid

proxyid

origcallernumber

origcallernumber_nq

orignumber_nq

realcallernumber

callernumber

callernumber_nq

number_nq

callername

origcallednumber

callednumber

calledname

techprefix

called_norm

auth_username

auth_password

transportip

fromip

rtprecip

transportport

fromport

rtprecport

callertype

usertype

callstate

cc_clientid

cc_ccid

credit

maxduration

globalcurrency

ratingcents

ratingcurrency

rating

rating_tospeech_ex

rating_tospeech

currency

centname

disccausetextex

otherpartyname

otherpartydisplayname

otherpartyfullname

Embedding controls in texts:

Basic:

Keyword embedded in square brackets [xxx] will be replaced with dynamically loaded data. (Label)

Keyword embedded in brackets {xxx} will be editable (loaded and saved to/from edit control) (Edit)

Advanced:

You can define other controls by the following text rule:

{ControlName|Width|BindValue|Item1|Item2,...}

The following control types are defined: Edit,Memo,ComboBox,ComboBoxRo,CheckBox,RadioButton,Date,Time

Examples:

{ComboBox|150| tb_ccampain_clients.faworiteos|Mac|Windows|Linux}

{ComboBox|200|tb_cclient.phone_landline|elsooo|masodiiik|harmadiik}

{Date|300|tb_cclient.recalldate}

Controls that can contain keywords, can also contain simple select conditions.

For example for list controls in the answer field a simple sql query can be specified wich can return one or two columns, wich will represent the list items.
If two columns are returned, the first should be a number (key).

4.10. MAgent

The MAgent application is used by callcenter operators as a sip client and database frontend.

4.10.1. Login

Enter server settings and authentication info here to login.

The following values are required on login:

App Server: server ip address

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

Data port: defaults to 1433 (or 2223 for older versions)

Database username: the same for all agents

Database password: the same for all agents

Username: agent username

Password: agent password

tagent

4.10.2. Manual Call

Simple VoIP client window where the operator are free to make calls to any number

4.10.3. Calls from database

Call to any client presented in the central database.

4.10.4. Automatic calls

Will handle calls automatically if the operator is part of a campaign.

4.10.5. Automatic software upgrades

Mizu client applications can check for newer version and selfupgrade.

The following modules are responsible for handling software updates:

-TUpdater.exe: to download the new software from a central directory (usually ftp)

-TUpdLaunch.exe: will check for new downloaded software on every main software start (will make backup of the old sw)

For autoupgrades to work the following tasks must be done:

-copy the new software’s in the ftp/specifieddirectory

-insert a new record in tb_autoupdate

swname: the name of the main software executable that needs to be updated (for example: MAgent)

mode: 0: ask the user first, 1: automatic install

version: new software version. make sure that this is correct especially when you use * in “oldversions” to avoid endless update!

oldversions: client softwares will check this record to know if the new software can be applied (* mean all)

forusers: applicable for this users (* or database user names separated by comma –login names from tb_users)

host,username,password,dir: ftp parameters. make sure than the user will have access to the files!

files: files that must be updated (separated by comma)
comment: will be displayed for users (new features, corrected bugs, etc)

Make sure that the version of the new software is bigger than the current and is not in the “oldversions” list, because otherwise will result in an endless update proces!

4.11. PBX / IPCentrex functionality

In addition to supporting class5 features according to sip rfc’s, drafts and recommendations, most of the features normally held on UA are implemented on the server side also and can be accessed by dtmf messages (client device must be able to send DTMF as INFO or RFC2833 at least)

4.11.1. Call Rerouting

Failed calls (error code, no answer) will be rerouted automatically to the next device according to routing preferences.

The rerouting can be performed within session, so the caller user doesn’t notify that the call was rerouted.

This is different from call failover (which means that a route is marked as low priority temporarily or definitely).

4.11.2. Ring Groups and Call Fork

A call can be sent to multiple devices in the following conditions:

· SIP device with ambiguous address

Some devices might advertise different addresses about themselves. For example different address in Via, Contact and physical socket address. In these situations the VoIP server might send invite to different addresses to be sure that the call arrives to the user device. This can be disabled if you set the “allowforkforsignaling” global setting to 0

· User registered from multiple locations

The VoIP servers allow users to be registered from multiple locations. For example a user can register with the same username/password from both of their laptop and smartphone. In this circumstance the server will send incoming call to all devices and once the user pick-up one of the device, all the other calls are canceled

· For simple call forward when the target is offline or doesn’t answer, you can just use the “On No Answer” setting frim Users and Devices -> Functions tab.

· User ringgroup (“Users and devices” form / tb_users.ringgroup)

User devices can be configured to ring in different locations (by filling tb_users.ringgroup with phonenumbers/usernames separated by comma).

Single line extensions are supported.

The calls can be also serialized with the RGMode option: 0=forked call (default), 1=round robin

· Routing ringgroup (“Routing” form)

Calls can be routed explicitly to multiple locations also from routing. Define a pattern (for example incoming calls to 12345) and add multiple endusers for the route (right side of the routing form) and select the “Is Ringgroup” checkbox (if the checkbox is checked then the call will be forked to all destinations at once; otherwise it will be routed to the highest priority destination or to the “best” one)

Call forking can be achieved in 2 ways:

-Using separate sessions (separate endpoints with their own unique SIP call-id)

-Via branch (same endpoint sending to different address using different via branch values)

The first session receiving 200 OK is the winner. For the others a CANCEL is sent.

Note: there are also other ways to create multi-session calls such as call rerouting, p2p, forwarding, transfer or conference.

4.11.3. Caller ID

You can setup the caller id display/hide (CLIP/CLIR) function by changing the CLI setting for the actual user.

The following values can be used:

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

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

The SIP Privacy method is also supported.

4.11.4. DTMF

H323 gateways support the following DTMF send/receive methods:

-as Q931

-as String

-as Tone (In-Band)

-as RFC2833

SIP endpoints support the following DTMF send/receive methods

-INFO method

-as Tone (In-Band)

-as RFC2833

DTMF in GSM network (send/receive):

-InBand DMTF

The SIP Softswitch (server) will parse DTMF received:

-INFO method

-as RFC2833

-convert from the above modes to “in-band” dtmf if needed

Usually In-Band DTMF are supported by any vendors in endpoint devices but will not be parsed on IVR servers because of high computation requirements to decode the encoded RTP channels.

The following DTMF global configuration settings are defined (key,default value, comment):

Ø defdtmfpayload = 101; //default payload number can be also negotiated between the peers

Ø maxdtmfdigit = 16; //max dtmf digit number (used in SDP)

Ø ivrdtmfmethod = 4; //0=inband,1=info,2=inband+info,3=RFC2833,4=RFC2833 and info,5=inband, RFC2833 and info,6=inband, RFC2833 or info

Ø dtmfdigittimeout = 6;

Ø deftmfsleep = 500; //msec delay on space w or W chars

Ø deftmfdelay = 0; //msec delay between 2 dtmf digit (default is 0. you might increase it usually not more than 1000 msec)

Ø deftmfpackettime = 0; //0 means default value in msec (after the negotiated codec) usually between 10 and 60 msec

Ø deftmfpacketcount = 6; //packets to send one dtmf digit

Ø deftmfendpacketcount = 2; //packets to end one dtmf digit

//the time spent for one dtmf digit is: (deftmfpacketcount + deftmfendpacketcount)*deftmfpackettime + deftmfdelay msec

4.11.5. Call Hold

The call-hold feature is implemented according to SIP specification. Most UA will support it.

4.11.6. Call Forward

You can enable the call forward feature by filling the following fields in the user configuration form (Functions tab):

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 or the called user is not online

if set to * then it will lookup and forward to “best” child user

set the “noanswertime” value after your preferences

forwardalways: rerouting

Call forwards are also supported by the “Moved” (code: 300-305) SIP message, so users can set the call forward in their phones (no need to change the “forwardalways” setting on the server)

The server behavior can be controlled by the “canmove” global config option:

0=not allowed

1=forward the 3xx message 1 to the caller (default)

2=callednumber change allowed (not safe, because pricing can change in different directions)

3=domain change allowed (not safe, because pricing can change in different domains/directions)

~~4=call routing again~~

5=call forward (call forward 301/302)

More details about call forward can be found in the wiki.

4.11.7. Call Transfer

-The standard sip calltransfer protocol is supported (REFER, replaces methods) using the transfer button on sip phones, but because many sip devices have problems with call-transfer, the DTMF mode transfer is supported. If the transfer fails, than the Cisco “Also” method is also supported for transfer failover.

-Calls can be transferred by the following dtmf digits:

*9*number# -> unattended transfer

*8*number# -> transfer with consultation

-You will hear a music if the calltransfer is in progress, or a failure notice if it failed.

-After the transfer successfully begun (ringing to the new client), you have the following DTMF options:

1: talk with the new called party when it is connected (not possible if already is connected),

for example to discuss the purpose of the caller.

When you hang-up, the caller and the new called party will be connected.

You don’t need to press 1 if you have started the transfer with consultation (*8*).

2: disconnect the new called party and talk with the original caller (not possible if already transferred)

for example you can redirect the caller to a new destination

3: stay in line with the old client (you have to hang-up when you finish to complete the transfer)

Note: DTMF ** will always reset your already entered digits to *

Related configurations:

handlerefer

Specify how to handle REFER requests.

-2: block

-1: block for outbound/allow only for endusers

0: auto/default (forward as-is or handle if REFER is not supported by peer ep or if the transfer was made with Replace)

1: handle as unattended transfer (except for transfers with Replace as in that case we might handle the Replace)

2: handle as attended transfer (except for transfers with Replace as in that case we might handle the Replace)

3: forward as a new call

4: just forward the REFER as is

fs_handletransfer

Specify how to handle WebRTC call transfer requests (applicable only for WebRTC calls)

-1: auto/default (if target user is SIP and not here and no replaces)

0: handle the transfers in the WebRTC stack

1: auto (handle the transfers in the SIP stack if target user is SIP and no replaces)

2: handle the transfers in the SIP stack whenever possible

3: always force handling the transfers in the SIP stack

allowclientinitiatedtransfer

Specify if you wish to allow transfer requests from client endpoints

-1: auto/default (it will allow to local user or if no billing is required)

0: no

1: yes

playtransfertone

Enable/disable ring or music playback on transfer.

0: nothing

1: ring

2: music (default)

discontransfer

Disconnect old parties on transfer

-1: auto (default)

0: no

1: yes on C party connect

2: immediately on succ if no refersub

3: immediately on fail if no refersub

4: always immediately

holdontransfer

Specify if call should be muted on transfer.

0: no

1: yes (default)

refertorewrite

Specify if the server should attempt to fix the Refer-To SIP header if the other parties are elsewhere (old refertoforward)

-1: auto/default

0: don't rewrite

1: auto

2: always rewrite

Technical description:

Structures:

calltype = eTransfer

//for the transferrer client ep

transferstate; //0=unknown, 1 = mute to all, 2=talk with old client, 3 = talk with new client, 4 = talk with both clients

because we have 2 client ep (called) for the server (caller):

GetOldTransferClient(); //will return the operator

GetNewTransferClient(); //will return the new client

Workflow:

Unconditional dtmf received (*9*number#)

Set Istransferrer = true

RouteCall()

If fail than play transferfail

4.11.8. Three-Way Calling

Three way dialogs with call holds are supported.

4.11.9. Call Waiting and queuing

Call waiting scenarios are supported. Need to be implemented in UA to work.

Group hunting and queuing are implemented only in callcenters.

4.11.10. Call Take-Over

You can pick up or transfer an incoming or existing call to any other device, by dialing *7*origcalled on the target device.

You must be in the same user group or billed user for this feature to work. The SIP replace method is also supported.

4.11.11. Conference Calls

Conference call can be made in the following ways:

· Standard SIP conferencing

-Three-way calls

-Conference managed from client side (client side RTP mixer)

· Server managed conference calls via DTMF:

Two-way conversation can be extended to multiparty by inviting new members with the following DTMF sequence:

*1*number#

Only the session initiator (original caller) can invite new members to the conversation! When the session initiator left the conference, the conference will be destroyed (other members will be disconnected too).

This method can be very useful if your SIP client don’t have built-in conference support.

Note: Make sure that the SIP clients are sending the DTMF digits in RFC2833 or SIP invite format (not in-band RTP)

· Conference rooms:

If you enable the PBX extra module from the server configuration wizard, then the conference room feature will be added automatically with room access numbers 5100-5199 for narrowband and 5200-5299 for wideband conference. (The room pool can be also extended to allow up to 10000 conference rooms). You can use the “getconfroom” API to auto allocate a conference room and its access number for the user.

4.11.12. Voice Mail

To enable voicemail on your server, make sure to enable the PBX Extra module in the server configuration wizard or set the fs_pbx global config option to 1.

Also make sure that the voicemail global config option is not set to 0 (setting voicemail to 0 will disable the voice mail feature system wide).

Enable voicemail for a user by checking the “voicemail” checkbox. (Users and devices form -> Functions tab).

At least one of the voicemail handling checkbox should be also selected (on busy, on no answer, always).

Recorded voices can be also sent to the user email address in wave or mp3 file attachment.

Users can access their voicemail box by calling 5000 (with pin authentication usually from external network) or by calling 5001 (with auto sip digest authentication from a SIP client).

The following config options are defined for the voicemail global config:

-1=auto

0=disable

1=enable

2=force

3=force also for called

You can force enable voicemail for all users by setting the voicemail global config option to 2.

Using the base voicemail module, users can also replay the last voicemail by the following DTMF digits: *3* or listen their voicemail trough the IVR (since this feature is rarely used, there is no mizutech support for it in the new server versions). This feature is not available in the extra pbx module, but here you have a voicemail access number.

Checklist:

-fs_pbx global config set to 1

-voicemail global config is not 0

-outgoing SMTP settings are set properly in the global configuration (by default it will use mizutech email server which you can change if you wish)

-the called user has voicemail enabled and one of the followings are enabled: voicemail on busy, on no answer, always

-the called user has a valid email address set

-for the core voicemail only: voicemailcampaign is set correctly in the global configuration (must point to voicemail_rec script which also have to be set correctly)

-for the core voicemail only: for the listening script you have to properly configure the voicemal_play script (if listening trough the IVR is required)

Another related feature is the “Missing call notification”. Just check this option to have an email about all unanswered calls.

More details can be found in the voicemail wiki.

4.11.13. Voice Recording

Call recording can be toggled on/off globally or per user.

Enable/disable globally from Config menu -> Configurations -> Recording -> Calls.

Enable/disable recording per users from the Users and Devices form -> Functions tab -> Voice recording checkbox.

Recorded calls can be listened or exported (as wav or mp3) from the CDR form.

Details:

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.

The exact location will be: serverftpvoice\databasename\currentday\voice.xxx

A separate backup can be created in the directory specified by the “voicebackupdir” global config option.

Old files can be deleted by setting the “keeprecorded” option accordingly (days to keep).

Recorded files are compressed and encrypted by default.

On new server installation, make sure that the voice directory is accessible via ftp for the MManage (for listening on the “CDR Record” form).

A separate ftp account might be enable with the same credentials as the database login.

Recorded conversation can be downloaded from the web.

Users can replay the last record by the following DTMF digits: *4*

You might also disable peer to peer rtp routing to prevent media bypassing the server. For this set the “disablep2prtprouting” parameter to 1.

You can also use the voicerecdownload API to download any recorded file(s).

The request should look like this:

https://yourdomain.com/mvapireq/?apientry=voicerecdownload&callid=XYZ&maxrecords=1&authkey=SERVERKEY&authid=ADMINUSERNAME&authpwd=ADMINPASSWORD

In case if your are using the Mizu webphone, then the HTTP or FTP upload URI can be also configured in the webphone itself using the webphone voicerecupload parameter or voicerecord API.

Call recording will use extra disk space, can make the routing and media path longer by disabling peer to peer routing and also will increase your server I/O and CPU usage.

4.11.14. Chat Recording

The users chat history can be recorded and stored in table tb_messagelog.

For this set the “logmessenger”: 0=no,1=on low load,2=always

You also have to disable fast message forwarding: set the “fastmessagequeue” configuration option to 0.

The recorded messages can be seen on the “Chat Logs” form MManage.

4.11.15. IVR

You can assign an IVR menu to any user if you set the “ivr” field to a valid IVR id.

IVRs are directly mapped to campaigns and can be edited in the script editor. Set your CampType to 2 if you have assigned to an IVR. See Scripts for more details.

The following actions can be defined at serverside:

Wait for DTMF: wait until match or eof characters found or timeout

Play a File: play any voice message. A repeat count can be defined. You can choose to jump to next action when the play begins, or only when finished (the client will have to listen the whole message before he can move forward with dtmf)

If you uncheck the “Wait for playback to finish”, than the IVR will continue with the next action immediately and the playback will be stopped only when a “stop pending playback” condition is reached or a new playback is started.

Play SQL Result: you can write any sql query here. The first field in the first column will be played. The SQL can contain keyword, defined below.

Forward to Phone Number: forward the caller to any number.

Forward to Group: forward the caller to a group.

Forward to SQL: forward the caller to the phone number or username returned by custom sql.

Forwarding will be tried “retry” count in every “forwardretrytimer” sec.

Charge: unused (use “execute sql” for charging).

Mailbox: unused (use “execute sql” and the “record” actions to implement a custom mailbox).

Execute SQL: execute any sql command (check allowed keywords below).

Record: record conversation. Can be used for voicemail recording.

Delete Recorded: delete current recorded and start playback the next recorded audio.

Next Recorded: playback next recorded audio (leaving the current).

Prev Recorded: playback prev recorded audio.

Text playback will be handled in different ways for numeric characters and for any other character. For numbers, the internal NumberToSpeech engine will be used (configurable in multiple languages). For any other text the default TextToSpeech engine will be used (available only in English in this moment).

For skill based callcenters you can use the “Forward to Group” or the “Forward to SQL” actions.

Voicemail can be implemented by the “record” actions.

Keywords at server side:

Ø currentnumber

Ø callduration

Ø ringduration

Ø opusername

Ø opname

Ø currdatetime

Ø currdatetimesql

Ø currdate

Ø currweekday

Ø curryear

Ø currmonth

Ø currday

Ø currhour

Ø currmin

Ø currsec

Ø calleruserid

Ø calleduserid

Ø proxyid

Ø origcallernumber

Ø callernumber

Ø callername

Ø origcallednumber

Ø callednumber

Ø calledname

Ø techprefix

Ø called_norm

Ø auth_username

Ø auth_password

Ø transportip

Ø fromip

Ø rtprecip

Ø transportport

Ø fromport

Ø rtprecport

Ø callertype

Ø callstate

Ø cc_clientid

Ø cc_ccid

Technical description:

On routing if calleduser.ivrid > 0 than set ep ivr_id and calltype to eIvr

No other ep will be created

ivr_id is the campaignid

On invite (after routed) if calltype = eIvr () call IvrAction(actIvrStart);

IvrAction(EIvrActionType actiontype)

1. the actiontype will tell what was happened: actDefault, actIvrStart, actReady, actUserInput, actTimeout, actFail

2. load the scripts if already not loaded

3. Check next action todo (jumpto). Especially check for dtmf input action

a. if actiontype == actUserInput than check if input finished (eof or maxlen)

b. if play finished and need to repeat, than play again

c. othervise set jumpto

4. JumpTo next action if needed (check enterconditions)

5. Do the next action (datainputtype, if any)

Play file, execute sql, forward, etc

A more detailed description about the Mizu IVR system can be found here and here.

4.11.16. Callback number

Used for handling incoming calls by callcenter operators.

See the “callback“ global config option.

4.11.17. Callback services

To configure callback services you will need to perform the following tasks:

1. Create callback access numbers: just create callback enduser from the “Users and devices” form and specify the “Act as IVR” settings on the “Functions” tab.

2. Create a callback IVR script: callbacks always need an associated IVR to perform some actions once the server calls back the user (such as playing some announcement or request the user to enter some phone number to forward the call to)

Callback services can be implemented by various methods:

· From the enduser webportal

o By entering the number to call on the website

o On the ensuser webportal you can find callback and p2p page (they are almost identical)

· By CID or ANI callback

o Setup a callback number (enduser) and assign the callback IVR script to it.Assuming that our callback number is C:

§ A call C

§ C will drop the call

§ C will call back the A number and will ask to enter the B number (this is done with the IVR. You should already have a “callback” ivr script template there)

§ Once A is ready with the number input, C will call the B number

§ Once C and B is connected, C will goes out of the path and will interconnect A with B

· By inbound SMS

o By a special SMS message

· By API

o Using the server HTTP API, the callback functionality can be easily integrated in any application or website

To define access numbers set tb_user.iscallback to the required ivr (campaignid) and tb_user.anumberlookup to 1.

The calls will be authenticated based on “ivrauthentication” global config value and/or “iscallback” user field. When using only A number authentication be aware of frauding possibilities.

Callback will be initiated from “callbackcallernumber” A number or from the user who received the call if “callbackcallernumber” is not specified.

The callback will automatically start the IVR specified in the “iscallback” field or in “ivrid” field of the access number.

The IVR script to be used for a call, can be loaded from the followings:

· Callback user (access number) tb_users.ivrid field (you can specify it on the “Users and devices” Functions tab)

· “ivr” URI parameter if the callback is API initiated

· Or loaded from the defcallbackivr global config if the above is not specified

Ivrauthentication is deprecated. Use the anumberhandling global configuration: 0=disabled,1=only add, 2 = only accept, 3=add and accept (default)

iscallback

Ø 1=act based on anumberhandling (default - connect to the ivr if not authenticated as enduser, otherwise callback immediately)

Ø 2=connect to the ivr if not authenticated as enduser, otherwise callback immediately

Ø 3=connect to the ivr if authenticated as enduser, otherwise callback immediately

Ø 4=drop the call if not authenticated as enduser, otherwise callback immediately

Ø 5=drop the call if authenticated as enduser, otherwise callback immediately

Ø 6= callback immediately always

Ø 7=always ivr

Ø other=ivr id to use (otherwise will check the "ivrid" field)

Example 1: if you want to call only authenticated users (no expense for failed authentication on callback):

Ø ivrauthentication: 1

Ø iscallback: 1

Example 2: if you have a free to call number or you can afford the callback payment to unauthenticated users then you can use the following settings:

Ø ivrauthentication: 1

Ø iscallback: 8

Example 3: no free callback and no trust in A number authentication

Ø ivrauthentication: 3

Ø iscallback: 2

*Note: if you would like to allow calls to IVR or to callback numbers from not authenticated parties, then set the “freeivraccess” and “freeaccessuserid” configuration options accordingly.

Technical details

1. call initated from console, db check or iscallback user

2. mainlogic process asyncCallback and initiate call

3. client endpoint changed to server ep on connect

4. ivr starts requiring pin if needed and the target number

5. ivr callforward with 2 leg billing

4.11.18. Calling Card services

For a calling card service you must setup an IVR (and a campaign) that will handle the authentication and forward the call to the requested destination.

To create an access number, add a “enduser” and set the ivrid to the campaign id you wish to use.

You can also allow authentication based on A number by setting “anumberlookup” for the traffic sender.

Example IVR:

-Play File: Welcome to xxx. Please enter your PIN number

-Wait for dtmf (acquire PIN digits)

-CallingCardAuthentication: (Will check the pincode in the database). On success go to next item, on fail play a prompt to try again

-Play File: Please enter the destination number

-Forward to phone number [dtmftrimmed] (call forwarding)

-Finish (release ivr)

If you want to bill the user for calling the ivr, then set the “ivrbilling” global config to “0”. Otherwise set to “1” and only the forwarded call will be billed.

If you need 2 leg billing, then set the “ivrbilling” value to 2. In this case 2 CDR records will be generated for the original caller.

PIN codec can be stored in the user table. Their type must be set to 0, isoperator to 6 and authentication based on username (5)

The authentication can be based on username, password or username+password or depending on the “callingcardauth” config option.

The following values are defined:

0=pin

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=calling card username or enduser username + password or enduser username + pin (default)

Calling cards can be generated in batch from the Config -> Users menu.

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

4.11.19. Phone to Phone (P2P) calls

You can implement this service on your website or in softphone.

The calls can be initiated with the following methods:

connect to the server console (a TCP connection) and issue the p2p call command. All communication can be encrypted and the clients are authenticated properly.
Insert a new record to tb_conferences with type set to 3

The billed user will be the logged in user. The p2p command has 3 parameters. A number, B number and IVR id (optional).

2 CDR records are generated for these calls, both of them billed to the initiator (based on your usual pricing).

The call to the A number will be initiated from “callbackcallernumber” configurable number or from the user who initiated the call.

You must set the “checkdbconf” global config value to 1 or 2 if you need to initiate phone 2 phone calls from the database (initiated from website for example)

Note: unless callback service, p2p doesn’t need any IVR as it will just interconnect two endpoints

4.11.20. Virtual Servers

You can create up to 100 virtual servers on a single pc. These are completely separate billing/routing/signaling entities and can be used for different business models or to offer hosted services to separate companies or organizations.

If you can afford, use a specific number prefix for each virtual server and setup the routing on the main server accordingly.

If a specific number scheme cannot be used:

On the main server you can specify to wich virtual server a number belongs in the “numbers” table (MManage -> Other -> Phone Numbers). In the location field, the virtual server sipuser id must be entered. -1 means that the number belongs to the main server.

Make sure that each service will use a different IP (bind ip) or the ports are set to be different.

4.11.21. DID

Virtual/real number mapping can be used to staticallt/dynamically routed DID numbers and for A number assignments. See the “DID numbers” section under “Access” for more details. See the DID number section for more details.

4.11.23. Barge-In

Intercept call barge or call spying can be done multiple ways:

-With the Voice Here module from MManage (or just right click on a record on the Current Calls form

-Via the 5009 access number for PBX calls

-From the customized SIP clients by sending a specific SIP header (defined by the bargeinheader)

4.11.24. Unified communication

The Mizu VoIP server implements a broad range of UC features.

Most of these features are available on the server by default with no special settings.

Just make sure that you have selected the “PBX Extra” module on the “Roles and Features” section of the configuration wizard.

Here are some of the UC related features:

· Video: works by default conform SIP standards with all video capable sip endpoint

· Chat: works by default via SIP standards RFC 3428 (chat recording can be also enabled)

· File transfer: requires client side support which is rare (you can use our webphone or windows softphone for example)

· SMS: supported as sip messages (if your carrier has this support) or you need to configure an external SMS gateway for this to work. For example Clicatel. Here is a short description.

· Fax: enabled by default and both analog and T.38 are supported. (Fax to email is not supported at this moment but it can be added via a gateway)

· Conference: via SIP standard, via dtmf *1*number# or via conference rooms using extensions between 5100-5199 for narrowband and 5200-5299 for wideband (these can be changed)

· Voicemail: enable from users and devices form -> functions tab. Default access number are 5000 (with pin) and 5001 (with auto authentication). Auto-email forward is enabled by default.

· Many Others: A lot’s of other UC related features are implemented. Check the configuration wizard, global configuration and the documentations for more details

4.11.25. Other features

The Mizu VoIP server implements most of the SIP related RFC’s as described here.

4.12. Additional modules

The following modules can be enabled optionally and are part of the “all-in-one” package:

4.12.1. Calling-Card

The calling card functionality is implemented by using the IVR module described in the previous section

4.12.2. SMS

Users of the Mizu VoIP server can send and receive SMS messages from softphones, web portal or API.

The server is capable to also convert simple SIP text messages to SMS if the target is a mobile phone number.

Incoming SMS requests can be converted to HTTP(S) or SMPP(S) requests and forwarded to an SMS gateway defined by the smsurl global config value.

The server can also use SMS for special purposes such as SMS code based sign-up verification (uauthverify) or administrative alters.

User interface

Once SMS is configured on your server, the endusers has various method to send SMS messages:

· Using the API. This can be easily integrated with any custom user interface or third party tool. See the API section below for the details.

· Customized softphones: softphones provided by Mizutech can have a “Send SMS” feature

· Third-party softphones: the server is cabable to convert standard SIP chat messages to SMS if the target is a mobile phone number, thus SMS can be sent from any SIP endpoint (sendsmsmessages global config option enabled by default)

· Web portal: Users can also send SMS messages from the enduser web control panel (SMS page)

· Server console: you can easily test SMS messages using the asendsms command. Example: asendsms,TONUMBER,Hello word

SMS Integration

To be able to offer SMS capabilities for your users, you will need to interconnect with an SMS service provider or with an SMS gateway.

The Mizu VoIP server has support for SMS over various protocols such as SIP IM, email, 3GPP SMS routing, SMPP or HTTP GET/POST with proprietary API’s using clear text, JSON, XML or other text based payload types.

You can configure integration with any SMS service as described below.

Outbound SMS

The server can connect to SMS providers (such as clickatel , routomessaging or sight) and send SMS message via SMPP(S) or HTTP(S) requests.

If you don’t have an SMS provider yet then please consider this list:

clickatell.com

www.sinch.com

infobip.com

messagingbay.com

www.routomessaging.com

hqsms.com

tm4b.com

smsbts.com

bulksms.co.uk

smsxchange.com

textmagic.com

truesenses.com

txtlocal.co.uk

We recommend clickatel and sight due to their affordable pricing and system stability.

The SMS API URL and it’s parameters must be obtained from the SMS provider. This is usually a HTTP link or SMPP config.

Set the URL in the global configuration under the smsurl key.

If the SMS is to be sent over SMPP, then the URL must have the following format: SMPP;key1=value1;key2=value2;…etc. See the parameters below at the “SMPP parameters” section.

If the request have to be a HTTP POST (instead of GET) then you can set the data to be posted with the smssendata parameter or stored in the smssendata.txt file in the server app folder.

If some special HTTP header(s) are required (for example Authentication) then you can specify it with the sms smssendheader parameter or in the smssendheader.txt file.

You can use the following keywords in the smsurl, smssendata and smssendheader:

[fromid], [fromnum],[tonum],[message],[smscounter],[smsid],[gatewayid],[clientip] or any SQL query in brackets such as {SELECT …}.

These will be replaced automatically to their respective values for each session.

The delivery success is guessed by default from the response or you can configure the smssuccessstring and/or smsfailstring the keyword to look for (the response is parsed as simple text).

Unicode messages are also supported.

If you wish to route to SMS messages to multiple providers then you should follow the following steps:

· set the smsrouting global config option to 1

· add SMS GW users

· setup the routing

· setup billing

· HTTP POST data will be loaded from smssendata_ID.txt loaded file (where ID is the gateway id -tb_users.id)

· HTTP headers can be added from smssendheader_ID.txt file (where ID is the gateway id -tb_users.id)

See the “SMS Routing” section below for clarifications regarding outbound SMS routing.

You can find more details about SMS setup here.

Inbound SMS

You can also receive incoming SMS messages as HTTP callback requests.

To enable SMS receiving, set the smsreceive_route parameter to 4 (or any other value as described below).

For incoming SMS you will have to configure your SMS service provider callback URL to point to your server smsreceive API which looks like this:

http://domain.com/mvapireq/?apientry=smsreceive

(Replace the domain.com with your SIP server domain name or IP address and use HTTPS instead if you enabled TLS on your server)

For example a simple SMS send might look like this:

https://sip.mydomain.com/mvapireq/?apientry=smsreceive&from=1234567&to=98765432&message=Works&now=555

(You can also use POST instead of GET)

See the smsreceive_xxx parameters below for other incoming SMS related configuration options.

SMS routing

In case if you have only one SMS gateway configured globally by the smsurl or smpp configuration, then all SMS will be routed to this gateway.

In case if you wish to use multiple SMS outbound gateways, then create SMS GW users and configure routing rules for them.

The routing rules can be configured exactly as for outbound calls, the only difference is that you must set the “Type” for the routing patters to “SMS”.

Once configured, SMS messages will be routed according to your routing rules.

See the above “Outbound SMS” section for more details.

In case if you wish to rewrite the outbound SMS number, check this FAQ point for the details.

SMS billing

After SMS messages a CDR record will be created with its type set to “SMS”. You can see them on the “CDR” form.

For unified (simplified one price) billing you can use the smsprice and the smstime global config options. In this case all sms messages will be billed with the same price, regardless of the destination). The smstime is set to -1 by default which means 60 seconds for up to 160 characters and then an addional 60 seconds for every 140 characters in excess.

Otherwise for normal SMS billing, the prices can be set on the “Price Setup” form the same way as for voice calls.

The only difference is that all SMS messages appear with be accounted wiht 60 sec duration by default and you must set the “ServiceType” to “SMS” for you SMS related billing packets.

If no pricing found, then the sms messages will be billed after the smsprice global config value.

Note: CDR generation for SMS messages might be delayed by about 10 seconds (because the server also sends a second requests to verify wether the SMS was sent successfully or not).

Rewrite SMS number prefix

Create a stored procedure named v_dialplansms with the following inputs:

- tonum varchar(256)

- fromid int

- fromnum varchar(64)

- clientip varchar(64)

This sp must return one field containing the rewritten target number (“tonum”)

Set the “usesmsprefixsp” global config option to “true” and reload.

API

The following API entries are defined:

sms: old deprecated

sendsms: asynchronously (fast) send SMS for endusers (check user rights and billing)

sendsmssync: synchronously (wait for delivery result) send SMS for endusers (check user rights and billing)

asendsms: asynchronously (fast) send SMS for admins

asendsmssync: synchronously (wait for delivery result) send SMS for admins

API parameters:

Sender number: anum or from

Target number: bnum or to

Message text body: message or txt

API Answer:

On success, the API will answer with message beginning with OK text.

On failure, the API will answer with message beginning with ERROR text.

By default the “asendsms” and “sendsms” API will send the SMS asynchronously. This means that you will receive a positive answer immediately once the send was initiated (which is then completed in a separate thread).

You can use the “asendsmssync” or “sendsmssync” API to send SMS synchronously. This will wait for the final status.

We recommend the “asendsms” and “sendsms” API to be used for high volume SMS since it is much faster. The “asendsmssync” and “sendsmssync” API should be used only if you need an accurate result (delivery succeed/failed) for the API. Otherwise you can always check the CDR for the delivery results.

Example:

http://yourserveraddress.com/mvapireq/?apientry=asendsms&authkey=xxx&authid=xxx&authmd5=xxx&authsalt=xxx&anum=FROMNUMBER&bnum=TONUMBER&message=MESSAGE&now=555

Configurations

All SMS related settings can be configured from the following places:

· Users and devices form: you might create multiple outbound SMS gateways as “SMS GW” user entries

· Routing form: you can create routing rule patter(s) for SMS messages by setting the “Type” to “SMS” for the directory definition

· Price Setup form: create billing rules for SMS messages by specifying “SMS” for the pricing packet(s) service type

· Global configuration: search for “sms” and/or “smpp” to list all SMS related settings (discussed here below)

The SMS related global config options are listed below:

· enablesms: enable the SMS module (default is true. Set to false to disable)

· smsurl: outbound SMS URL (it can be also an executable path instead of URL)

· smssendata: HTTP data for outbound SMS if POST have to be used

· smssendheader: HTTP headers for outbound SMS (for example Authentication header)

· smsthread: 0: no separate thread (more reliable answer), 1: separate thread (better performance)

· smsverifyurl: if a second request is request to verify the SMS success (currently harcoded to use "messageId" from the answer

· smssendataverify: HTTP POST data for verify (otherwise HTTP GET will be used)

· smsverifydelay: milliseconds to wait before calling the verify URL

· smssignature: to add a “signature” text after all outbound SMS

· smsadv: set to true for advertising –to insert and advertising message before each outbound SMS (tb_advertisment)

· smsadvprefix: insert a text before each message

· smsadvvalue: users can receive some credit if advertisement are sent to them

· smssuccessstring: success keyword to look for in the response (depending on your SMS provider and payload type)

· smsfailstring: failure keyword to look for in the response (depending on your SMS provider and payload type)

· smsrouting: if SMS routing have to be used (“Routing” form): -1: auto guess, 0: global config only, 1=multiple sms gw

· sendsmsmessages: specifiy wether to convert SIP IM to SMS. 0=no,1=to mobile only (default), 2=to all phone number, 3=to all destination

· smsprice: default SMS price for a 60 second SMS (which is the default “duration” for an SMS)

· smstime: SMS messages will be treated with this duration. The default -1 means 60 seconds for the first 160 characters and an 60 for any additional characters

· smsreceive_route: how to forward incoming SMS to users: 0: disable, 1:chat,2:email,3:chat or email,4:chat and email

· smsreceive_ip: allow incoming SMS only from this IP address or IP address list separated by comma (if empty, then it will allow from anywhere)

· smsreceive_check: any string to check if the message is incoming sms, otherwise will be dropped. usually empty

· smsreceive_from: extact sms sender number from the incoming message. it can be a single word parameter name or fromstring1,fromstring2,tostring1,tostring2

· smsreceive_to: extact sms target number (our user) from the incoming message. it can be a single word parameter name or fromstring1,fromstring2,tostring1,tostring2

· smsreceive_message: extact the SMS message body from the incoming message. it can be a single word parameter name or fromstring1,fromstring2,tostring1,tostring2

SMPP parameters:

SMPP parameters can be set in the global configuration with an “smpp_” prefix (for example “smpp_server”) or inside the SMS URL as key=value pairs.

Example URL or smpp_allparameters:

· Basic: SMPP;server=11.22.33.44;username=smppuser;password=xxx;serverport=2775

· Advanced: SMPP;server=55.66.77.88;username=smppuser;password=xxx;serverport=2785;version=50;timeout=30;msgpriority=3;servicetype=CMT;SourceTON=1

Possible parameters:

· smpp_allparameters: You can store all the below parameters in this single field using the above format

· server: SMPP server address to connect to. The instant messaging server must contain a valid SMPP service application address. Usually an IP address.

· username: User ID value to be used for identification with the SMPP service

· password: This is the user's password

· serverport: SMPP server port (default is 2775)

· version: the SMPP version to be used. Possible values: 33: v.3.3, 34: v.3.4, 50: v.5.0. Default is 34 (v.3.4)

· secure: set to 1 if you need SSL/TLS connection

· systemtype: Some SMS servers might require suplying the system type which is usually an abbreviation string of maximum 12 characters. Default is empty.

· servicetype: type of service. Can be set globally or by message. Possible values: 0: default, 1: CMT, 2: CPT, 3: VMN, 4: VMA, 5: WAP, 6: USSD, 7: CBS. Default is 0.

· msgpriority: message priority. Can be set globally or by message. Possible values: -1: default, 0: low, 1: normal, 2: high, 3: urgent. Default is 1 (normal).

· msgexpire: optional MC expiration time in YYMMDDhhmmsstnnp format. p set to "R" means relative. (validity period of the current message). Default is empty. t means tenths of a second (0-9). nn means quarter-hour time difference between local time and UTC time (00-48)

· timeout: timeout in seconds for inter-packet inactivity. Default is 60. You might set the AbsoluteTimeout config to true to interpret this as total timeout.

· recipients: one destination phone number or multiple destinations separated by ; (max 255)

· recipienttype: 0: normal SMS number or ipv4, 1: namelist

· isdata: set to 1 if you wish to send the paypload as data instead of a message. Only one recipient is supported in this case

· extraconfig: additional exta configuration parameters as key=value;key2=value2;

o SenderAddress: the SMPP protocol allows an External Short Messaging Entity (ESME) to specify its address, whether it is a phone number or an IP address. If SenderAddress is not set, the component will default to the value in LocalHost

o SourceTON: Type of Number for the ESME. 0: unknown, 1: international, 2: national, 3: network specific, 4: subscriber number without prefixes, 5: alphanumeric, 6: abbreviated

o SourceNPI: Number Planning Indicator for the ESME used to specify the numbering plan. 0: unknown, 1: ISDN, 3: data, 4: telex, 6: landline, 8: national, 9: private, 10: ERMES, 14: internet, 18: WAP. Default is 1 which since mobiles are usually covered by ISDN

o DestinationTON: Type of Number for the destination ESME. Possible values: same as for SourceTON.

o DestinationNPI: Number Planning Indicator for the desination ESME. Possible values: same as for SourceNPI.

o DataCoding: data encoding mechanism to be used for the current message. Possible values: 0: MC Specific encoding, 1: IA5 (CCITT T.50)/ASCII (ANSI X3.4), 2: Octet unspecified (8-bit binary), 3: Latin 1 (ISO-8859-1), 4: Octet unspecified (8-bit binary), 5: JIS (X 0208-1990), 6: Cyrillic (ISO-8859-5), 7: Latin/Hebrew (ISO-8859-8), 8: UCS2 (ISO/IEC-10646), 9: Pictogram Encoding, 10: ISO-2022-JP (Music Codes), 11: Reserved, 12: Reserved 2, 13: Extended Kanji JIS (X 0212-1990), 14: KS C 5601,

o HexString: a hex-encoded binary string to be sent to the current recipient

o InBufferSize: size in bytes of the incoming queue of the socket.

o OutBufferSize: size in bytes of the outgoing queue of the socket.

o AbsoluteTimeout: determines whether timeout means inactivity timeout or absolute timeout

· ssl config (to be set only if you need to use secure SMPPS):

o sslaccept: set to "ANY" or "ALL" to accept any certificate presented by the server. set to - to cler it and force cert validation.

o sslencodig: the PEM/base64 encoded SSL certificate

o sslcertstore: name of the certificate store for the client certificate. Possible values: MY: personal cert store, CA: authority certs, ROOT: root certs, SPC: publisher cert, filename: PFX or java cert store or cert+private key file

o sslpwd: password for the certificate store (if any)

o sslstoretype: type of certificate store for the client certificate. Possible values: 0: user, 1: machine, 2: PFX file, 3: PFX blob, 4: PEM cert and key

o sslsubject: subject of the certificate used for client authentication. can be set to * for any

Debug

In case if you encounter any issue with SMS sending, you can find out the problem following these steps:

1. Verify the SMS related configuration described above. Search for “sms” in the global config on the “Configurations” form.

2. Note that the Mizu server SMPP module will bind as a transmitter. Receiver and trasreceiver bind is not supported.

3. SMPP connectivity and message delivery can be tested with the mnetutils.exe (found in your VoIP server app folder).
You can also test with third party tools such as SMPPCli.

4. Check the SMS CDR records (CDR form). Delivered SMS messages has a positive “duration” set after the smstime global config (-1 or 60 by default). Failed SMS messages has 0 duration and you can find details in the disconnect reason and comment fields (with “All Fields” checkbox checked).

Note: if a separate API request is used for SMS verification then the CDR records are generated with around 6 seconds delay.

5. If the problem is not clear from the CDR, have a look into the server logs (MizuManage -> Control -> Logs -> Show -> Log Folder). Make sure that the logs are enabled (Set to “On” or loglevel is set to 5) and search for “sms” in the logs (or for “sendsms” or for your SMS number or message text).

SMS CDR

The fields in the SMS call detail records means the followings:

o realduration: 0 if not sent, 60 or GetSMSTime if sent

o discreason: GSM, Normal, unspecified if sent, other on fail (the discreason code might be different depending on the ack/fail stage)

o connecttime: 1 (+send time which should be 0)

o discparty: 3;

o callerid: sender user id

o callername: sender number

o callernumber: sender number

o calledtype: 12

o gatewayid: SMS gateway id

o simid: smpp ourid

o calledline: 99

o simpos: 99

o callerip: sender IP addrsss

o calledip: gateway address or URL or settings

o calledname: URL

o origcallednumber: original target number

o callednumber: target number

o calleddialed: target number

o rtpsent: 10

o rtprec: 0 on error, otherwise 1

o rtpframes: smscounter (ignore for smpp)

o rtpcodec: SMS

o web: smpp protocol id (as received from the SMPP server) or our id or retval

o comment: details about the send process

4.12.3. SMS callback

Using SMS callback you can initiate VoIP calls with SMS messages.

If you subscribe to an SMS provider (like clickatel) the server can receive SMS messages (usually on http port 8084) and initiate actions regarding the content.

By sending an sms messages users can initiate callback, register a new A number for CLI authentication, initiate phone to phone call or add credit to your account.

There are different formats for all functions (short/long - depending on the authentication method). The server can use A number based authentication for the incoming sms messages. If the CLI is hided, or the A number is not specified then the users have to send their username and password or a pincode.

Instead of SMS callback we can recommend the phone to phone functionality. (In this mode the users don't have to work with the IVR. the 2 phone number can be interconnected immediate)

The authentication of the requests is done based on “callingcardauth” global setting.

Pincode can represent the concatenated username and password (if allowed by callingcardauth)

The following formats are defined:

general

username password number1, number2

pincode number

number

pincode

b (pincode based authentication. the A number will be called back)

general requests will result in a p2p call when at least 2 number is known. If only one number is know, than it will result in generating a callback to that number. Two numbers can be supplied, one by sms and the another number can be known from the sender CLI.

callback:

b username password number (username and password based authentication and the number to be called)

b pincode number (pincode based authentication and the number to be called)

b number (pincode based authentication only the number to be called have to be sent)

b (pincode based authentication. the A number will be called back)

n username password number

n pincode number

n number

phone to phone:

p username password number1 number2

p pincode number1 number2

p number1 number2

p number2

add credit:

c username password rechargecode number2

c pincode rechargecode number2

c rechargecode number2

c rechargecode

Example http request:

POST / HTTP/1.1

User-Agent: Clickatell MO Callback

Host: 99.99.99.99:8084

Pragma: no-cache

Accept:

Referer: 99.99.99.99

Content-Length: 157

Content-Type: application/x-www-form-urlencoded

api_id=3144985&from=3611111111&to=3622222222&timestamp=2009-07-04 21:39:40&text=Test+1+2+3&charset=ISO-8859-1&udh=&moMsgId=5jv45t5tb42bavu34drftr

For callbacks you must define the campaign which will have the proper IVR content by the defcallbackivr global configuration setting.

You can set a httpsmscallbackip parameter if you wish to enable callbacks only from a specific IP address.

4.12.4. Web portal

The Mizu VoIP server web interface can be used by the VoIP users to perform the common tasks related to their accounts.

The web interface is handled by a separate service called “MizuWebService” with its own embedded webserver (http/https server).

Different type of user can login and will have their own different interface after login: admin, reseller, enduser and callshop interface.

You should be able to access your web interface by typing the following URI in your browser:

From a local browser:

http://127.0.0.1 or http://127.0.0.1:8080

From a remote server

http://domainname.com or http://ipaddress.com or http://domainname.com:8080 or http://ipaddress.com:8080

By default the webportal will listen on port 8080 which can be changed at any time by the configuration settings.

Make sure that the IIS (or any other webserver) is turned off if you are using the HTTP default port (80).

Recent versions are using the universal port (usually set to 80) to allow access all services via a single port, so you can access the webportal also via this port like: http://serveraddress/webvoip

If you enabled the TLS functionality, then use HTTPS instead of HTTP: https://serveraddress/webvoip

Separate functionality for endusers, resellers, callshops and admins

Functionality:

-new enduser registrations

-status

-user acc details

-tariffs

-CDR’s

-statistics

-initiate payments

-endusers: recharge

-endusers: setup call forwarding

-endusers: initiate phone to phone calls and callbacks

-enduser: send SMS

-endusers: launch webphone

-resellers: create sub reseller and enduser accounts

-resellers: create own tariffs

-resellers: generate pins and users

-callshop: watch cabin’s status

-admin: manipulate users

-admin: global statistics

To enable the SMS,phone to phone and the callback functionality the “checkdbconf” must be set to 1 or 2. (can be done via the configuration wizard by enabling the database interface)

4.12.5. Resellers

To activate the reseller module, you must set the “resellerbilling” global config option to true. This can be done also by using the configuration wizard from the Config menu.

Resellers will be able to log-in on the web portal to manage their accounts: set pricing, create endusers (and sub-reseller) accounts, see their traffic (including their CDR records) and other functions.

User parent-child relationships:

When the reseller option is enabled, you should always create one (or more) owner account.

1. below the owner account(s) you can put the “top resellers”.

2. below the top resellers you can have any sub-resellers (unlimited level - limited by your hardware resources and the “maxresellers” global config options)

3. below the reseller you can put the Enduser accounts.

4. below the Enduser account you can have sub-user accounts (attached phones, cabins for callshops, etc)

This parent-child relationship can be analyzed by using the “Ownerships” form.

Before to add any reseller in the system, make sure you have a public reseller price listing (end-user costs). Read the billing documentation for more details regarding reseller account billing.

Top reseller accounts can be created from the MManage application using the “Users and devices” form. You can create “Reseller” type users (type is 1).

Then this top resellers can login on the web interface and create their own billing and add sub resellers and/or child endusers. Reseller can create a “base tariff” and other tariffs assigned to individual users. 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. Individual reseller prices are stored in tb_billsources with their “resellerid”. If reseller has not tariffs, than the billing will be done after usual enduserprices. If reseller has no credit, the billing will be done after the provider prices (usually generating profit loss for the reseller)

set parent for top reseller accounts to an owner account

CDR:

When the reseller option is enabled, the main cdr record will store the top reseller user id in tb_cdrs.resellerid and the “othercost” field will contain the payment from the reseller (loaded from public reseller price).

Individual reseller cdr records are stored in a separate table called tb_cdrresellers (when a reseller will login to the web interface, all reports are loaded from this table and not from the main cdr table –tb_cdrs)

In the first cdr:

-the caller enduser name

-reseller field set to top reseller

-pricing after parent reseller

You can see the reseller account statistics by using the “Statistics” form by checking the “OC” and the “PR”/”PFR” fields or if you login with their own credentials on the web (or with parent user credentials)

Billing

There are two options for reseller billing controlled by the “defearlypay” global config option:

The possible values for defearlypay are the followings:

Ø 0=configurable (default). Early billing if the “stage” field in tb_users is set to 9. Otherwise late billing (default is 8 for the “stage” field which means late billing)

Ø 1=always late billing

Ø 2=always early billing

1. Late billing

The credit for the reseller and enduser will be deducted after each call.

(Resellers can assign any amount of credit for the users, but the calls from the users will be rejected when the credit for the reseller reach to 0)

2. Early billing

Credit from the reseller account is deducted when he add credit for the users (create new users with some default credit, increase user credit, generate recharge PIN’s).

Tariff edit is not enabled by default in this mode unless you set the allow_tariffedit or the user rights field (in thus case the resellers could create low price tariff lists so their users could call in excess)

Other configuration options related to billing:

Ø allow_createresellers = -1; //-1: default, 0=no,1=yes (allow resellers to create sub resellers)

Ø allow_tariffedit = -1; //-1: default, 0=no,1=yes (allow resellers to edit tariffs. This ca be influenced also by the tb_user.rights field)

If defearlypay is set to 2 and allow_createresellers is left with the default value (-1) then tariff edit is forbidden by default.

You can also edit reseller rights by user via the "rights" field in the users (tb_users) table if the allow_xxx fields above are left with the default values (-1) (On the "Users and devices" form, click on the ... button and type "Rights". Then modify it after your needs for the resellers):

Ø 8: can’t edit tariffs and can’t add resellers

Ø 10: can’t edit tariffs

Ø 11: can’t create tariffs with lower price

Ø 12: can’t add resellers

Ø 30: can add resellers and tariffs

Other options:

Ø Creditelapseunit

Ø Maxcreditelapsedays

Ø Defaultcredit

Ø feature_creditcards

Ø feature_transfercredit

Ø feature_creditedit

Ø feature_creditfornewusers

Ø currencyprecision

Ø feature_seeowntariffs

Ø feature_createtariffs

Ø feature_recharge

Ø feature_hasbasetariffs

Reseller programs can work in two different ways:

1. The reseller can generate PIN codes regardless of the balance in the account.

When a call is made, both the end user and the reseller are charged.

When the reseller's credit ends, the end user will no longer be allowed to make calls.

2 The reseller can generate PIN codes only if he has enough credit in the account.

If you opt for this method, you have to enable the early payments for the reseller.

You can find this option on the reseller's billing tab.

Please be aware that once you enable the early payments the reseller will no longer be charged for calls.

You might lose money if the reseller already generated PIN codes using the first method.

4.12.6. Call-shops

-callshop owners are endusers

-cabins are sub-endusers where the parented and the billed user points to the callshop owner

-callshop owners (endusers) can add/modify their sub-endusers (cabins) from the web

See the wiki articles for more details.

4.12.7. Softphone

With the “all in one” platform you can have your own customized softphone.

For a basic softphone customization the mizutech support will need at least the following details:

-brand name (name of the executable, install package and shortcuts)

-company name (displayed in various location for example in the about box)

-company logo (if any)

-icon

-voip server ip or domain

-a long list of other configurations are also supported

You can also configure and build your softphone from here.

4.12.8. Webphone

The webphone is a SIP library and a customizable SIP client running in browsers.

All the details can be found from here.

A demo version can be downloaded from here.

You can start to work with this version at any time, test and customize it then with the “all in one” platform the mizu support will send your own build that can be used in production.

4.12.9. GSM/SIM Platform

Deprecated!

Skip this chapter if you don’t have VoIP-GSM gateways

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

Gateways

Used to configure your Mizu VoIP-GSM gateways.

The fields are the same as listed in section 4.3.1

Engines

Listing of gsm channels. The fields are self explanatory.

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

SIM Cards

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 “Failovered”

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.

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

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

SIM Utilization

List of simcards in call duration order.

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.

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

SIM-Bank

Skip this chapter if you are not using VoIP-GSM gateways.

Introduction:

In the SIM Bank form you can monitor the sim flying activity.

Mizu servers can automatically switch to the best simcards based on routing settings and traffic estimations.

Simcards can be bound to engines located in remote gateways, wich allows us to simulate real sim movements.

Allocation simcards between gateways is called “sim flying”.

Configuration:

The following settings are defined:

Global config:

simcallocival: minutes between sim allocations. If set to 60, than the simallocation will start at “simallocstart” minute in every hour

maxflysims: maximum simultaneous flying simcards

Gateway config:

canalloc: if automatic sim allocation and flying is allowed in the gateway (0=no, 1=only alloc,2 = fly and alloc)

SIM Packet configurations:

canalloc: if automatic sim allocation and flying is allowed with the simcards in the packet (0=no, 1=only alloc,2 = fly and alloc)

minflyday: minimum flying minutes/day

maxflyday: maximum flying minutes/day (0=disable flying)

minflyweek: minimum flying minutes/week

maxflyweek: maximum flying minutes/ week (0=disable flying)

minflymonth: minimum flying minutes/month

maxflymonth: maximum flying minutes/ month (0=disable flying)

minflyonce: minimum time to fly at once

maxflyonce: maximum time to fly at once

minstayonce: minimum time to stay (not fly) at once

maxstayonce: maximum time to stay (not fly) at once

minflydeep: minimum gateway count to fly trough at once

maxflydeep: maximum gateway count to fly trough at once

Simcard fields:

origgatewayid: original gateway for the simcard (gatewayid can be the virtual gateway)

origline: original line for the simcard (line can point to the virtual engine)

origsimpos: original position for the simcard (simpos can be the virtual position)

lastpresent: last seen (date-time)

presenterrors: simcard should be active but it is not active (counter)

lastpreserror: last not found time

flyetosim: the current engine must bind to this sim (simid): -2 = err, -1 = not set, other = simid for the engine

todayfly: today flying minutes for the simcard

thisweekfly: this week flying minutes for the simcard

thismonthfly: this month flying minutes for the simcard

canfly: 10=never (manual), 20=unspecified, 30=no, 40 can accept, 50=can, 60=should, 70=must, 80= always (manual)

importance: sim importance calculated for the next period

flytoorder: engine can accept flying simcard (engines with not so important simcards goes first)

Fly Directions: (tb_flydirections)

defines the fly routes and the minimum times between two gateways

simpacket: applied only for this simpacket (if -1 than applies to all simpacket)

fromgw: fly from this gateway

togw: can fly to this gateway

mintime: minimum time in minutes between the two gateway

Technical Details:

gateway inifile:

[phoneX]

flylastupdate=datetime

flyvalidfor= 60000 //seconds

flyto=ip/engine/simpos/simid //template

flyto=local/local/2/999999 //local simpos

flyto=local/2/2/99999999 //other engine

flyto=1.1.1.1/2/3/99999999 //other gateway

flyto=manual //after manual timetable

flyto=off //switch off

tb_sims

origgatewayid: original gateway for the simcard

origline: original engine for the simcard

origsimpos: original position for the simcard

presenterrors: simcard activation fail count (increased in every 10 min if sim is not active when should be active)

preserrreset: presenterrors will be reseted several times to retry the simcard

flyetosim (e): the engine must be bound to the required simcard ?

currflydeep: gateway count from the original gateway

flystarted: time of flying start

staystarted: time of stay start

todayfly: elapsed flying minutes today

thisweekfly: elapsed flying minutes in the current week

thismonthfly: elapsed flying minutes in the current month

4.12.10. GSM Gateways

Deprecated!

Skip this section if you are not using VoIP-GSM gateways.

All configurations can be done from the MManage Client Utility GUI and the VnetCfg utility.

For better understandings we present the gateway configuration settings here:

Phone Settings

[PhoneX]

//serial port

PortNumber=1

//control port (not used in 1.6 hardware)

ModemControllPort=X

//if there are no "In" and "Out" device, we use this settings both for in and out

##AudioDevice="Xaaaaaa"

//from engine

AudioDeviceIn="1Audio Codec 1000"

//to engine

AudioDeviceOut="2Audio Codec 1000"

//simchange settings

simchange1= 00:00:00 - 00:00:00 - 01234567890123456789

//if 1 then the conversations (voice) will be saved to files on encrypted, compressed format

record=0

//init commands only for this engine: atinit1,atinit2 ... atinit19

##atinit1=XXXX

##atinit2=XXXX

##etc

//simcard id's in the slots

simcard0=01234567890123456789

simcard1=

simcard2=

simcard3=

Simchange settings explanation:

format:

simchange1= 2004.03.05/13:00:00 - 2004.03.07/13:00:00 - 8936302403070132426 (from date - to date)

simchange2= 10:20:00 - 10:26:00 - 8936302403070132426 (every day from time to time)

simchange3= 2/10:20:00 - 7/10:26:00 - 8936302403070132426 (from Tuesday 10:00 to Sunday 10:00)

simchange4= 6/00:00:00 - 7/24:00:00 - 8936302403070132426 (Saturday and Sunday)

there is a priority order from top to bottom (simchange1, simchange2, etc.) numbering begins from 1 without holes

tip: you can set date-hour prioritization

tip: 24:60 is a wrong time (minutes ends with 59)

tip: on day and exact date settings the roundrobin trick is not working

special characters are: - , / . :

Gateway Basic Settings

//the name of the gateway. uppercase with "GW" suffix. must be descriptive

alias=NEWGW

//hardware version: 10,16,18 or 19

hwversion=18

//mode of operation. virtual available from hw 1.9

virtualmode=0

//server ip address

serverip=1.2.3.4

//number of hardware audio buffers (the jitter base is soundbuffcount*10)

sndbuffnum=8

//min jittertime in milisec (the minimum of the dynamic maximum jitter time. must be larger than soundbuffcount*5)

minjitter=130

//maximum jittertime in milisec (the maximum of the dynamic maximum jitter time. must be larger than maxjitter. if equal, then static jitter will be applied)

maxjitter=350

//0=off,1=dynamic,2=fixed,3=dynamic+off

silencedetection=3

//codecs to use: onlyg723, onlyg729, onlyg72X, onlyg711

onlyg72x=1

//useserver if false, then don't connect to the simserver. will save cdr records to file. may be limited due to licensing options

useserver=true

//load configuration from the server (at startup, at regular intervals and when specified)

loadcfgfromdb=true

//gatekkep ip address (leave it empty if you don't want arq registration)

gkip=

//gatekeeper H.235 security

gkpassword=

Gateway Advanced Settings

//search for gatekeeper

gkdiscover=0

//gatekeeper supported prefixes (from 1 to 100)

gkprefixes1=

gkprefixes2=

gkprefixesX=

//volume in (sound device recorder from the gsm engine). defaults to 40 in hw. 1.8, 100 in hw 1.6

volumein=

//volume out (sound device player to the gsm engine) defaults to 75 in hw. 1.8, 100 in hw 1.6

volumeout=

//gsm engine receive gain. defaults to 0 in hw. 1.8, 64 in hw 1.6

vgr=

//gsm engine transmit gain. defaults to 0 in hw. 1.8, 64 in hw 1.6

vgt=

//ethernet interface to use. leave it empty to listen on all

netinterface=

//don't touch it usually

launchcmd=voipgsmgw

//install status: 0=idle, 1=wait, 2=normal

opmode=1

//will be set to false after first init

firstinit=true

//tracelevel 1-6 't'

trace=t

//record voice

record=0

//what kind of logs to send to server (1-5)

tracetoserver=1

//process priority

priority=1

//ModemControllPort used only with hw 1.0

controlportnumber=1

//if we use prefXXX settings

useseparatesettings=0

//signaling endpoint port. Defaults to 20001

mintcpport=20001

//max h323 signaling endpoint port. Defaults to 29999

maxtcpport=29999

//min h323 udp endpoint port. Defaults to 36000

minudpport=36000

//max h323 udp endpoint port. Defaults to 37999

maxudpport=63999

//min media port. Defaults to 38000

minrtpport=36000

//max media endpoint port. Defaults to 63999

maxrtpport=63999

//call with immediately pick up

fakecalls=0

//set to 1 if you want error report

errreport=0

//codec frames in one packet: g723frames, g729frames, g72xframes, g72xframes

g72xframes=1

g723frames=1

g729frames=2

//minimum frame count in 1 packet (apply even if the other end says another settings)

g72xminframes=0

//if set to 0, then we send connect when the call arrives

waitforring=1

//reset the engine/gw if we reach this limit

maxnotconnectedcalls=25

//reset the engine/gw if we reach this limit

maxwrongcalls=40

//wrong call criteria

wrongcallmaxduration=30

//call duration limit in sec (defaults to 3 hour -10800 sec)

callimit=10800

//max time to wait for ring signal from gsm network in msec

maxringewait=36000

//ring limit in msec (defaults to 52 sec)

maxringtime=52000

//deprecated

statusintervall=600

//do Q931 progress indication

doprogreessindicator=0

//reset the gw if we have fewer lines

minactivelines=2

//delay of initialization of the lines (msec)

initdelay=2200

//delay of registration of the lines (msec)

destroydelay=100

//max simchange wait in sec (if sim in call, we will wait until disconnect). default is 5 min

simchangewait=300

//max simcard/channel (will auto detect. don't overwrite)

maxsimcount=

//additional hang-up on the call end (to increase the real duration)

delayonhangup=0

//if we can retry the call

allowreroute=1

//deprecated, as we use only self reroute now

onlyselfreroute=1

//all calls will be routed on the onlyphone if enabled (no simcard requested from the server). deprecated

##onlyphone=3

//automatically increased on every gw (re)start

restartcounter=0

//usually set to 1

enableh245tuneling=1

//usually set to 0

connectwithmedia=1

//usually set to 1

faststart=1

//used for debug purposes

ringtime=6000

//desktop access

desktoppwd=

//if set, then will try to autologin

loginpwd=

//if we want to play a background sound

backgroundsound=0

//4 or 8. no problem if we use 8 on a 4 channel gateway

chanellnum=8

//pincode applied globally to all channels (if not specified in phonex section)

pincode=

//will set the simcards to don't request for pincode (pincode must be set in gateway or phonex sections)

autoremovepincode=true

//volume in/out (will be overwritten with volumein and volumeout)

volume=

//auto gain enable/disable

doautogain=0

//listening tcp port (may be changed on NAT configurations)

signalport=1721

//0=no watchdog, 1=yes, 2=unknown

paralellwatchdog=2

//set to 1 if you want to remap usb audio lines

mustremapaudio=0

//set to 1 if you want to reread all simcards

readallsims=0

//set to 0 if you don't want an usb remap on every pc restart

canremaponstart=1

//if we have usb audio and don’t have other usb device then allow to remap if needed

canremapusbaudio=1

canrenewusbaudio=1

//set to 0 if you don’t want panel reset

canpanelreset=1

//set to 0 if you want an usb remap when the service will start

mustremapaudio=0

//disable reading sms messages

nosmsread=0

//socket read/write timeout and system checks operations modifier. default=4

timeoutmultiplier=4

//backup server address

serverip2=

//route incoming calls here (defaults to serverip if not specified)

outserverip=

//keep connected to the internet (redial, reconnect, repair, enable/disable network interface, restart)

keepinternet=1

//ethernet interface name. configure from the vnetcfg tool

net_interfacename=

//network connection type (STATICIP/DHCPIP/ISDNIP/ADSLIP,CARDNAME). configure from the vnetcfg tool

net_conntype=

//network interface ip address. configure from the vnetcfg tool

net_ip=

//network netmask. configure from the vnetcfg tool

net_netmask=

//network default gateway. configure from the vnetcfg tool

net_defgw=

//network primary dns server. configure from the vnetcfg tool

net_dns=

//dialup phone number

net_phonenum=

//network ppp username. configure from the vnetcfg tool

net_username=

//network ppp password. configure from the vnetcfg tool

net_pwd=

//maximum speech length allowed in sec. defaults to 10800 (3 hour). set to 0 to disable

maxcallduration=

//maximum ringtime allowed in msec. defaults to 52000 (52 sec)

maxringtime=

//password on local command line. default is cmdpwd1234

cmdpwd=cmdpwd1234

//towarding dtmf from voip to gsm

forwarddtmf=1

//what to do with incoming calls (0=drop,1=hold a little then drop,2=auto forward,3=forward to server as forwardnum,4=forward to number requested by dtmf)

inccalls=1

//file to play when requesting number to call on dtmf (when incalls is 4). "please enter phone number to forward call"

playdtmfreqfile=

//file to play when requesting number to call on dtmf failed (when incalls is 4) "forwarding failed"

playdtmffail=

//file to play when requesting number to call on dtmf succeed, and forwarding begins (when incalls is 4) "your call has been forwarded. please wait for connect"

playdtmfforward=

//auto forward number (used if inccalls is 2)

forwardnum=

//used to require the number to forward to (when inccalls is 4)

promtfile=

//allow towarding dtmf messages to gsm network

allowdtmf=true

//how we send the ring signal. 0=send immediately and always, 1=send when received from gsm, (on the server you can set a timeout)

exactring=1

//used by the ipconfig tool. don't edit manually

ethcfg=

//local ip stored here. don't modify

localip=

//date-time of the last config download from the server

lastinisave=

//date-time of the last config upload to the server

lastiniupload=

Watchdog settings

[watchdog]

//set to 0 if you don’t want pc restarts

canrestartpc=1

//set to 0 if you don’t want service restart (then the watchdog will have no effect)

canrestartservice=1

//set to 1 if you want a reset on every night

canrestartdaily=0

//how often can the watchdog restart the service. defaults to 1000*60*25 msec (will change dynamically)

MAXSERVICERESTARTIVAL=

//how often can the watchdog restart the pc. defaults to 1000*60*45 msec (will change dynamically)

MAXPCRESTARTIVAL=

//max time to wait for watchdog reset. defaults to 1000*60*20 msec

MUSTRECEIVEOKIVAL=

Other settings

//at commands sent only once for all engines

[atonce]

#hardware version

cmd0=AT+WHWV

#sw version

cmd1=AT+WSSW

//at commands sent for all engine at every init

[atinit]

##cmd0=XXXX

##cmd1=XXXX

##etc

//prefix depending settings

[prefXXX]

connectwithmedia=0

g723frames=3

g729frames=6

[ipmux]

ipmuxenabled=0/1

[sounddevices]

//will be filled when reading all sims, so you can copy device names from here

Handling incoming calls from GSM network

Depending on the “incalls” (gateway configuration) settings, incoming calls from gsm network can be handled in several ways.

1. When incalls is set to 0

-all incoming calls to gsm simcards will be dropped immediately

2. When incalls is set to 1

-the engine will pickup the call, hold a little (random time, but maximum 1 minute), and than drop. Also used in call simulations.

3. When incalls is set to 2

-call will be forwarded to the number specified by the “forwardnum“ option in the GSM network.

-the simcards must support the forwarding options, otherwise this operation will fail

4. When incalls is set to 3

-the call will be forwarded to the Mizu server specified by the “outserverip” setting in the gateway configuration.

-on the server, the call will be forwarded to the “gsminccalled” number (SimPlatform configuration). If the “gsminccaller” option is filled with a valid phone number, than the callernumber will change accordingly. Otherwise the caller number will be the original caller. The ip caller address can be changed with the “gsminccallerip” option. (thus you can simulate the routing from a predefined user)

5. When incalls is set to 4

-the caller will be asked to enter the target number (handled with dtmf), and the call will be forwarded to that number

-the prompt played to ask the target number can be set by the “playdtmfreqfile” setting. This will have to point to a PCM 8000kHz, 8 bit mono wave audio file.

-the prompt to be played if the forwarding has failed can be specified by the “playdtmffail” setting. When the forwarding is in progress, the “playdtmfforward” file will be played to the user.

-the call will arrive to the server with the ‘222’ techprefix, and you can setup a separate routing roule for this tecprefix

A possibe callflow for calls arrived to a working simcard in” inccals 3” mode:

original caller initiate call

call routed by gsm network

call arrives to our simcard

converting from gsm to h323

call routed to GK

on routing: caller will be converted to “gsminccaller”, called will be converted to “gsminccalled”

call needs to be forwarded to “sip2h323”

sip2h323 module doing the protocoll conversion from h323 to sip

call arrives to SIP module

routing will decide the proper routing

client sip endpoint is created and call forwarded to the target gateway

call will be handled by the called gateway

call forwarded to the final user

Operator friendly gsm termination

Not using industrial engines

On request, we can deploy our gateways equipped with normal gsm phones instead of industrial gsm engines. Ask the Mizu support for more details

Virtual Engines

Each simcards can have it’s own GSM engine (in other gsm gateway the engines are used by more simcards)

GSM Cell Lock

Because Mizu GSM Gateways use only 8 channels, they don’t overuse the gsm network. However, you can setup individual GSM channels to use separate cells

Virtual Simcards

With the ease of Mizu simbank, your simcards can be stored in a central location, and used in gsm gateways installed at different locations.

Delayed network registration

A delay time can be configured to elapse between succesive engine (re)registrations.

Intelligent routing

Ballancing the traffic across your simcard based on price and quality

Handling of incoming calls

In usual GSM gateways there are no simple mechanisms to handle incoming calls from the gsm network. In a Mizu system all calls can be forwarded to your support team, so each call can be responded accordingly.

No GSM network owerload

Mizu GSM gateways occupy only 8 channels

Fast detection of dead channels

Failovering from simcards blocked by the operator or with wrong quality

Automatic blacklist generation

Wrong numbers will be detected and blocked on the server (not forwarded to the gsm network)

Minute limits

Each simcard can have different daily, monthly and other limits

Time between subsequent calls

Calls will not be forwarded to gsm gateway without a delay between (configurable)

SIM Bank

Simcards can be managed on a central location, and they will “fly” between gateways

Many other tricks

Ask the Mizu support for more details

How to setup a gateway behind a NAT

For the basic gateway the followin port forward must be applied on your NAT box:

-TCP: 1721 (h323 signaling)

-TCP: 3386 (remote desktop)

-UDP: 44444 (“voice-here”)

-at least 16 UDP port for RTP (setup the minrtpport and maxrtpport settings accordingly in the voipgsmgw.ini)

(RTP media may work without the port forwarding set explicitly. This depends on caller party)

-TCP: 21 (optional for ftp access)

For advanced gateways and servers the following port ports must be forwarded also:

-TCP: 1720 (default h323 GK signaling)

-UDP: 5060 (default SIP port)

-TCP: 9885, 9886, 9889 (gsm server, admin port, log port)

-TCP: 1433 or 2223 (for SQL server)

-TCP: 80 (optional for HTTP)

*you may use other ports than the defaults listed above

4.12.11. H.323

The mizu voip server is capable to handle H.323-H.323 routing or transparent sip to H.323or H.323 to sip conversion.

Both Gateway and Gatekeeper (v.1,2,3,4) mode are enabled and protocol variations are handled automatically (RAS, H.245, H.225, media proxy or bypass, Fast Connect/Fast Start, etc)

H.323 should be used only for gateways. For endusers you should always prefer SIP over H323 because:

-some class 5 features will work only with SIP protocol

-H323 GK doesn’t support username/password authentication (only ip/port and/or techprefix based)

Files needed (part of the install package):

Ø atarongk.exe -main h323 gateway and gatekeeper

Ø vsip.exe -for SIP to H323 conversion (will not be used for H323 to H323 calls)

Ø openh323.dll, ptlib.dll, pwlib.dll, libyate.dll -required dll's

Ø sipcfg directory and sipunits directory -required for sip to h323 converter (vsip.exe)

To enable h323 the hash323 and can_h323 global config values must be set to true.

To enable h323-SIP conversion the runsipproxy global config values must be set to true.

Local and LAN IP’s should be also enabled.

These are can be enabled from the Configuration Wizard.

The atarongk application can be controlled from the console port if you type the “gk” command

Two important user entry is created automatically during setup used internally for sip to h323 conversion (and inverse):

Ø "sip2h323caller" traffic sender

Ø "sip2h323" sip proxy

Make sue that these are present and enabled.

To setup a h323 caller (incoming traffic), there is no special action to do. You just have to add a traffic sender user with the proper authentication.

For outgoing traffic you must use a "H323 GW/GK" user type and then add it to your routing

In case of H323 entries, the "callsigaddress" field is used instead of the "port" field. This must be set to 1720 usually (standard H323 signaling port). The media ports are negotiated automatically.

Make sure that atarongk and vsip is enabled on the firewall.

Technical background:

h323 to h323:

1. incoming call arrive to atarongk

2. atarongk will call the routing and will get the destination address

3. atarongk forwards the call to the destination

h323 to sip conversion:

1. incoming call arrive to atarongk (h323 protocol)

2. atarongk will call the routing

3. call will be forwarded to vsip converter

4. vsip will call the routing again (sip protocol)

5. the rest of the call is handled by mizu sipstack

sip to h323 conversion:

1. incoming call arrive to mizu sipstack (sip protocol)

2. call will be sent for vsip

3. vsip will send the call to atarongk (h323 protocol)

4. atarongk will call the routing again

5. atarongk will forward the call to the destination

Troubleshooting:

1. replace the atarongk file with the _dbg version

2. change the "sipcommand" global config option to "vsip -vvvvvvvv -l siplog.dat"

3. change the "gkcommand" global config option to "atarongk -ttttt -o gklog.txt"

4. set loglevel to 5

5. check the callsigaddress field for h323 gateways (usually 1720)

6. start the service

7. make sure that atarongk and vsip processes are running

8. make a test call and check the logs

9. for h323 test calls you can use the openphone.exe or the ohphone.exe (example: ohphone -n -p 192.168.1.7 -ttttt 2222)

4.12.12. Encryption and tunneling

The mizu voip service and client application has built in tunneling and encryption features.

For a detailed presentation please visit this link: https://www.mizu-voip.com/Software/VoIPTunnel.aspx

You can configure the most important settings on the “Tunnel” page of the server configuration wizard from MManage Config menu.

The secured communication can used by all softphones provided by mizutech (customized softphones for all platforms with buit-in tunneling and encryption support) or you can use the cross-platform “mtunnelclient” application to secure any third-party server/devices/phones.

Encryption v.2 (new)

The new version of the tunneling module brings many advantages as described on the website. Highly recommended to upgrade if you are using the old version.

basic settings:

· useencryption: 0=disabled, 1=only when rec encrypted (default), 2=use, 3=always (only 0 and 1 is used for now)

· fwdregistrations: forward registrations to upper server and don't handle locally. 0=no,1=only from alternate port, 2=always

· forwardauthentifications: will forward invite (regarding routing setup) 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

· other related: replacecalleronforward, forwardauthentificationsfromtr, forwardauthentificationsfromend, replacecalleriponforward, normalizedef,

· autocreatereguser: 0=no,1=when fwd authenticated ok register, 2=always (when we receive the register)

· userautoaddwithowner: wether server should auto create resellers. -1=auto,0=no (standalone. no resellers needed), 1=yes (less secure), 2=must (must means that the calls will be rejected if parent not already exists or no fix match for brandname)

· allowupperserverselection: 0=no,1=yes (def), 2=yes only if found as sipserver allow client softphone to specify upper server. default is true. for standalone sofswitch with prebuilt softphone should be 0. otherwise can be 1 or 2

· fwdregistrations_domain=fix registrar sip domain

· fwdregistrations_ip=fix registrar ip or FQDNS

· fwdregistrations_port=fix registrar port

other settings:

· maxlinefornewunknownparents: def max line for auto created resellers (default is 5). useful to auto create trial access together if userautoaddwithowner is set to 2

· maxlinefornewunknownusers: max line for new unknown users. (default values is 3)

· alternatelocalportencrypt: 0=default,1=never,2=auto,3=always,4=reject if not encrypted (To encrypt all communication on the alternatelocalport. If set to 3, then will not accept clear test VoIP)

· usequickencryption: setting for v1. false for strong but slower encryption mode , true for weak and quick encryption mode. default is true.

· alloweuserusercalls = 1: 0=no (don't check if local target),1=yes (default),2=disable (dropp) call to endusers route calls directly between endusers or all calls have to go trough upperserver. default is 1.

· encryptedpeerlist: list of IP to always encrypt (optional)

· noencryptedpeerlist: list of IP to never encrypt (optional)

· noencryptedpeerlist2: list of IP to never encrypt on socket send level (optional)

· tb_users.encrypt: 0=default 1=newer 2=dynamic no (decide automatically) 3=dynamic 4=dynamic yes 5=always (to always initiate encrypted sessions) 6=force always

· tb_users.candisablesim: will auto store the encryption method. 0=not known, 1-20 old encryption, 21=new encryption, 22=new fast encryption (for iOS)

Encryption v.1 (old)

Optionally a separate udp port can be set on the server to handle encrypted sessions (alternatelocalport)

Encrypted sessions are always answered encrypted by the server.

Use the tb_users.encrypt field to control encryption on user level:

0=default

1=newer

2=dynamic no

3=dynamic

4=dynamic yes

5=always

6=force always

To initiate encrypted sessions, set the “encrypt” field for the user to 5.

To decide automatically, then set to 2.

To encrypt all communication on the alternatelocalport, set “alternatelocalportencrypt” global config to 2.

There are two types of built-in encryption:

-weak and quick encryption mode (when usequickencryption is true -default)

-strong but slower encryption mode (when usequickencryption is false)

Encryption can be enabled/disabled with the “useencryption” global configuration value:

0=disabled,

1=only when rec encrypted (default)

2=use

3=always

The encryption method is stored in the “candisablesim” field in tb_users (refreshed automatically by the server on client connect)

Also, there is a possibility to define a list of ip addresses with the “encryptedpeerlist”. All communications with these peers will be done encrypted.

If the mvoiptunnel client service is used with some always running device, then you should set a fix “encryptionkey”, otherwise it is changed every night which might cause communication issues for long running clients.

Standard SSL/TLS signaling encryptions are negotiated runtime as well as SRTP media encryption.

The recommended encryption type between mizu devices is the embedded fast or bowlish+compression. These types of encryption require much less CPU power and are done with no additional network overhead.

Running Mizu Server in proxy mode

(the server doesn’t handle registration and authentication, just forward it)

Fwdregistrations=2 // //0=no,1=only from alternate port, 2=always

fwdregistrations_domain=registrar sip domain

fwdregistrations_ip=registrar ip or FQDNS

fwdregistrations_port=registrar port

autocreatereguser=1 //0=no,1=when fwd authenticated ok register, 2=always (when we receive the register)

Forwardauthentifications=1 //will forward invite (regarding routing setup)

Sendrandompackets=true

udptunnelsamesock=1

Ftpname=-

Allowdiscmessage=false

Maxreroute=1 //only if 1 upper server is used

Sslogport=0

Setup routing to point to the upper server

Optionaly you may increase these tresholds:

Maxmsgcountlimitmultiplier=2

Maxnocdrmin=3000

Maxroutereqpermin=5000

Checkmaxlines = 0 ?

Checkmaxlinetb=0 ?

Maxsessionspeechlen= 1000UL * 60UL * 60UL * 6UL

Ringtimeout=120

MAXEPCOUNTTRESHOLD=30000

MAXSUBSMSGCOUNT=99999

MAXWRONGMSGALLOWED=9999

Running the server as a VPN access point (forced encryption)

Fwdregistrations=1 //only from encrypted clients (bug: set to 2)

Alternatelocalport=5088 //or any other port; same like the port that was set in the softphone and webphone

Alternatelocalportencrypt=3 //0=default,1=never,2=auto,3=always

normalize_clean=1

normalizenumbers=0

alloweuserusercalls=false //set to disable user to user calls

Set the “encrypt” field for the users to 5 (update tb_users set encrypt = 5 where type = 0)

When all the new automatically created users are allowed to use only encrypted comunication, set the autonewusersencrypt to 5.

Stop and disable the MizuWebService

TCP and HTTP tunneling port settings

-on the server, set the usehttp and usetcptunnel settings to true

-the default port for simple TCP signaling is the same as the main udp port (5060 by default and configurable with the “localtcpport” parameter)

-the default port for http tunneling is 80. Set it explicitely if needed with the localhttpport parameter. In the softphone it is controlled by the remotehttpport parameter

-the default port for tcp tunneling is 443. Set it explicitely if needed with the localtcptunnelport parameter. In the softphone it is controlled by the remotetcptunnelingport parameter

-the default port for TLS signaling is the same as the main udp port + 1 (5061 by default)

Client driven upper server

Setup the tunneling server as usually (create a “default” registrar and upper server)

Set “allowupperserverselection” to “true”.

Create a sip proxy named “upperserver_template”. (this will be a “default” route and default upper server settings)

Create one or more server and set the “rdport” field properly.

From the client set the sy.uppersrv properly (must match with a rdport or set to a upper server ip:port)

This can be done with the upperserver applet parameter or with the UPPERSERVERID define from the softphones.

Tunneling signaling and media in the same udp stream

Set the udptunnelsamesock congig option to at least 1. (udptunnelsamesock = 0; //0=no,1=if received so, 2=yes). This will tunnel only encrypted sessions so it is safe to use.

Increase the “udpbuffsize” configuration option

Tunneling between two servers

Setup the sip servers and traffic senders with forced encryption and desired protocol

Set the “usehttpclient“ global config option to “true”.

Set tb_users.protocol to 4 if TCP tunneling is needed and set the port to 443 (default TCP server port)

Tunneling between a servers and mtunnelsrv

Just set the tunnel client to connect to the server.

You might also adjust the following tcp tunneling related configuration options:

-tcptunnelallowsendtosameip; //0=no,1=without streamid,2=yes

-tcptunnelmultipleep; //when set to true than we are searching for rtp ssrc (more than one ep can send in one tcp stream. for example when we have a mtunnelclientsrv with multiple gateways)

-userptepptrsig; //each tcp rtp packet is marked when this is set to true

4.12.13. SBC

The mizu voip service can be used as an SBC, providing:

· transparent user authentication (will forward digest authentications to your PBX or softswitch)

· SIP security at the edge of your network

· WebRTC-SIP gateway functionality

· H.323-SIP gateway functionality

· rate limiting

· NAT traversal support

· media transcoding

· call and chat recording

· fast route between local endpoints to free up server resources

· and other services

You can turn the mizu server to an SBC from the configuration wizard or via the following global config options:

o autocreatereguser=1 //0=no,1=when fwd authenticated ok register, 2=always (when we receive the register)

o fwdregistrations=2 //0=no,1=only from alternate port, 2=always

o fwdregistrations_address/fwdregistrations_domain/fwdregistrations_ip/fwdregistrations_port

o forwardauthentifications=1 //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

o forwardauthpassword=1 //-1=auto, 0=fwd from ep, 1=means 3 if from webrtc for recent users, 2=answer from local always,3=answer from localalso for register, 4=answer from remapped upperusername/upperpassword

o fwdregistrations_xxx settings: fwdregistrations_domain, fwdregistrations_address, fwdregistrations_ip, fwdregistrations_port, fwdregistrations_protocol, fwdregistrations_proxy_ip, fwdregistrations_proxy_port

When running as an SBC the registrations and calls will be forwarded to:

o the globally configured upper server (fwdregistrations_xxx)

o or after routing rules (Always for the calls. For registrations you need to set the routingforregister setting to 1 for this)

o or as suggested by the SIP client UA (if enabled by setting the allowupperserverselection setting to 1)

A more details SBC guide can be found here:

https://www.mizu-voip.com/Portals/0/Files/SIP_SBC_Doc.pdf

4.13. Security and account limiting

The Mizu VoIP server is secure by default however with also usability in mind. For usual usage you can leave everything with the default settings and you still have a high level protection as the Mizu server has security constrains and built-in automatic attack prevention mechanisms at multiple levels enabled by default. The Mizu VoIP server has very few dependencies of third-party components (including OS services) which also improves security.

Please note that regardless of the server side security, there are still a room for hackers to exploit client endpoints such as stooling SIP username/passwords from softphones/devices. You can't prevent these to happen as it depends on client environments and third party software/hardware however you can still reduce its impact by leveraging strength server side restrictions (max lines, max daily/monthly limits and others).

For extra security, read through this chapter and fine-tune your settings, however please note that most of these settings will have direct effect on usability. (Your service might work incorrectly if security restrictions are too strength. Don’t change setting unnecessarily)

4.13.1. OS security

The Mizu VoIP server uses only core windows services (networking, file access and other resources with no security implications) so it is not vulnerable for the usual windows related vulnerabilities, because kernel/core ip networking vulnerabilities are very rare and hard to exploit (and windows is no worse in this then other systems such as like linux).

For maximum security just use a clean windows install, with no any unneeded services enabled and see the OS security checklist at the end of this chapter.

You can configure your MizuVoIP server to disable all network services on your firewall (including RDP and SQL access) and enable only the VoIP service and the mztunnel (you can still comfortably manage all services from remote MManage via the mztunnel).

4.13.2. DB security

The database contains ALL the data used by the Mizu server including user details and CDR records so a special care has to be taken to protect your database. With a regular SQL install using a strong password you are already secure by default without any special action to be taken.

SQL injection attacks are prevented on multiple layers: all input data are properly filtered and sanitized. SQL parameters are passed by query parameters and not with SQL query string manipulation using stored procedures whenever practicable.

Note: the MManage admin client is treated as a trusted component with few restrictions once the user is logged in.

Make sure to have working backups (incremental/full) to be able to recover your database from a disaster at any time.

4.13.3. Socket/stream level network protection

All streams are rate limited in the server to avoid all DoS or overflow attempts.

To fine-tune, you might change the "maxnetworkspeed" global config option which is set to 800000 by default (this means 0.8 gbits so it is optimized for a gigabit NIC with some room for IP/TCP/UDP headers)

For example if your NIC is only 100 mbits, then you might set this to 80000.

The server will perform early message inspection at network level to efficiently filter out malicious requests. These and other extra protections are also applied for media streams for RTP/RTCP flood protection.

4.13.4. Address level network attack preventions

· DOS attack prevention: when there are too many messages received from an IP address, the address will be blacklisted automatically. Controlled by MAXSUBSMSGCOUNT (default is 39000) and MAXSUBSMSGPERIOD (default is 3 minute) global configuration settings.

· when there are too many “wrong” or meaningless messages from an IP, the address will be blacklisted automatically. Is controlled by MAXWRONGMSGALLOWED (default is 4000) and MAXWRONGMSGPERIOD (default is 1 hour) global configuration setting.

· when there are too many subsequent auth request from an IP with no positive result, the source address will be blacklisted automatically. Is controlled by maxsubsipauthrequest global configuration setting (default is -1 which means automatically calculated based on server load)

· when there are too many unauthorized request from an IP, the address will be blacklisted automatically. Is controlled by MAXWRONGAUTHFROMIP (default is 2500) and MAXSUBFAILAUTHPERIOD (default is 1 hour) global configuration setting.

· when there are too many unauthorized request from an IP:port, the address will be blacklisted automatically. Is controlled by MAXFAILEDAUTHENABLEDIPPORT (default is 50)/ MAXFAILEDAUTHENABLEDIP (default is 800) and MAXSUBFAILAUTHPERIOD (default is 1 hour) global configuration setting.

· You might set the “checkrtpaddr” configuration option to 2 to force the server to accept rtp packets only from known media sources. (the default setting is false)

· All counters are reset periodically controlled by the REENABLEDOSBLOCKED (default is 6 hours) global configuration setting.

· For the new registrar module the “fastauthsubswrongusermsg” setting will be applied: not authenticated messages from same ip or all messages in 90 sec. (also X*10 for any IP). Default value is 300.

4.13.5. Session level protection

Session level limits are enabled for all services provided by the Mizu VoIP server. This includes the core VoIP services (SIP/H323) but also the enduser web portal and the API.

The server will close the session on the following circumstances:

· absolute timeout, call timeout, media timeout, ring timeout, call init timeout, timeout on session timers (all these are configurable from MManage -> Configurations form)

· too many incoming messages (dynamically based on frequency and number of requests)

· too many authentication failures (dynamically based on frequency and number of requests)

· too quick (abnormal) message receptions (dynamically based on frequency and number of requests)

· subsequent invalid signaling messages (DDOS protection)

· some known scanners are blocked by default. You can add more with the "blockua" global config option

Blocked devices and users can be re-enabled by issuing the “delbanned,ip” or “delbanned,all” command on the Console port.

4.13.6. Web security

The Mizu VoIP server uses a native embedded engine for web interfaces so it is not vulnerable for the exploits against the common web servers.

The web engine implements the best current practices including proper authentication, input filtering, rate limiting and XSS attack prevention with secured default settings.

4.13.7. API access security

The API is secured by default and each sensitive API requires proper authentication to be executed. All data received from the network or user input are properly filtered and sanitized.

Optionally you can harden its security by setting up HTTPS access, setting a random httpapikey key, fine-tuning the API access and using the methods described in the API documentation.

See the "Security", the "Authentication" and the “Hardened access” sections in the VoIP_Server_API documentation.

4.13.8. Payment security

User payments security are completely offloaded to payment gateways (for example PayPal), which must comply for PCI requirements.

This means that the Mizu Server doesn't process any confidential data such as user or credit card details, just forwards the user to the configured payment processor.

Once the transaction is completed (or failed) the Mizu server will receive a message from the payment processor to handle the result (increase user credit).

Various frauds are not uncommon with online payments which are handled by both the payment processor and the mizu server. Suspicious transaction can be left to be approved manually instead to be accepted automatically.

Check your PayPal related settings to enforce proper verifications and limits. (See the PayPal related section in this documentation and search for “paypal” in the MManage configuration form)

4.13.9. Encrypted VoIP

The Mizu VoIP server provides a complete solution for secured communication. See the "Encryption and tunneling" section and the VoIP tunnel documentation for the details.

4.13.10. SSL/TLS/WSS/HTTPS setup

You can use the TLS proxy module to add secured transport for most protocols in the mizu server. This module can be used to encrypt all services offered by the mizu voip server, automatically handling each built-in protocols separately regarding to its requirements, including:

· SIPS (secure SIP protocol. Default port is 5061. Unencrypted port: 5060)

· VoIP tunneling (tunneling over TLS. Default port is random)

· WebRTC (secure websocket / wss)

· HTTPS (Secure HTTP protocol. Default port is 443. Unencrypted port: 80). This is used for the following services:

o enduser web portal (default internal unencrypted port is 8080)

o API (default internal unencrypted port is 80)

o mmq service (default internal unencrypted port is 80)

o websocket (for API, WebRTC and mmq)

o the universal port 80 (unified maina port)

The VoIP server is capable to maintain a Let’s Encrypt TLS certificate automatically which can be selected from the configuration wizard.

You will need to assign a domain name to your server to be able to get a TLS certificate. Create a (sub)domain at your domain service provide (for example sip.yourcompany.com) and set its DNS A and/or SRV record to point to your server IP address.

For other related settings, search for “tls” and “ssl” in the global config (Configuration form).

Note: From v.7.5.2 the mizu server is capable to automatically acquire SSL certificate from Let’s Encrypt and it has built-in TLS module (no need for the TLS Proxy anymore), so there is no need for be below described steps anymore.
By default the server is shipped with a self-signed certificate. This can be used for VoIP tunnel encryption, but not for authentication/identity. Will not work for wss and if used for the webportal, the browsers will present a warning.

Follow these steps to manually setup and enable TLS on your server with a valid certificate (less likely required for new versions):

1. You need a (sub)domain name assigned to your server IP (you should also set it in “LocalDomain” global config).

If you already have a domain name (such as company.com/www.company.com) then with most of the DNS providers you can create sub-domains for free from their control panel. Create a subdomain like sip.company.com for your VoIP server IP. If you don’t have a domain name yet, then you can purchase for any DNS providers at around $10/year. For example at GoDaddy.

You can use the same subdomain for both your web and voip server is you wish.

2. Get a valid certificate for your domain from a reputable CA

StartSSL: free, but you can’t use it to host the webhone.jar (Not recognized by Oracle, however good for WebRTC or any other purposes)

Comodo: $10 per year. Works everywhere

Let’s Encrypt: free (recommended for sysadmins and developers).

For example you can get free certificate from StartSSL by following these steps or for let’s encrypt here is an easy app.

You can use the same certificate for both your webserver and VoIP server if they are on the same IP with the same (sub)domain.

3. Make sure the tlsproxy.exe, tlsproxy_mserver.exe or tlsproxy_servicename.exe exists in your app directory (contact us if you can’t find this app in your server directory)

4. Add your SSL certificate. For this you just have to copy the following files in the server directory:

· key.pem: the key file (your private key which you have got when generated the CSR - keyfile.key)

· cert.pem: the certificate file (your certificate as received from the CA -yourdomaincertificate)

· root.pem (the chain: CA intermediary + root certificate. intermediate.crt + root.crt)

· dh.pem and/or dh2.pem: these are optional used for DH key exchange and it can be generated with the following commands:

-fast: openssl dhparam -dsaparam -out dh.pem 1048

-slower/better: openssl dhparam -out dh2.pem 2048

All these are clear text files. If you haven’t received your certificate in similar format from your CA, then convert them and create these files (copy content using notepad). If these files are not set, then the server will use the default built-in self-signed certificate (which will result in browser warnings).

5. Set server settings (search for “tls” in the global configuration)

· usetls: set to true for SIPS (SIP signaling encryption)

· encv2_usetls: set to true if you wish to use TLS for VoIP tunneling (if you are using the VoIP tunneling module)

· usetlsforweb: for internal webportal

· usetlsforall: will auto set TLS for mainaport, web, voip tunnel, sips (recommended)

· forcetls: runtime http -> https rewrite: 0=force no, 1=def, 2=force tls,3=extra

· localtlsport: SIPS TLS port (default is 5061)

· sslcertpwd: if your certificate is password encypted, set the password here

· set the domain name assigned to your VoIP server to the “localdomain” global config

· you might also need set the cfg_baseurl webportal setting to https:\\yourdomain

· if you need to use an other port then the standard 443, then set it in the sslportweb config (also it can be set in the tlsproxy.ini)

6. Configure tlsproxy.ini if you need the certificate for WebRTC/websocket. Example:

[settings]

security=1

insertheader=1

forwardtoothers=1

localdomain=sub.domain.com

externalip=11.22.33.44

listenip=192.168.1.8

listenport=2443

7. Reload or restart the service (restart recommended)

8. Test:

· Direct response from the proxy: https://yoursipdomain.com/ tlsproxytestxxxxxxx (only for gateways if forwardtoothers is set)

· Example request for enduser webportal over the unified port: https://yoursipdomain.com/webvoip

· Or via a request to built-in webportal: https://yoursipdomain.com/mvweb/anyexistingfile.html

· For api: https://yoursipdomain.com/mvapireq/?apientry=apitest1

(Note: make sure to add the :port after the domain if your tls is not on the standard 443 port)

Other tools:

· SSLBuddy

· OpenSSL (win binaries)

· Test

4.13.11. User authentication

The mizu server provides flexible user authentication services which can be set per user by the "AuthType" config option from MManage. See the "Users" and the "User authorization" section for more details. On the IVR the users can be authenticated also by PIN code or A number authentication. See the “IVR” section or the IVR documentation for the details.

For speed considerations, the mizu server can cache device login information for a time so it will not ask again for authorization for every REGISTER or INVITE request. This means that it can happen that you change the user credentials and the user is still able to login with its old username/password or inverse: the user enters the correct credential but will be still blocked for a time. This can be controlled by the “cacheregistrations” global config variable.

The server will periodically recheck the password for all accounts and will change to a random strong password when weak password is found (enforcestrongauth global config option). Password storage can be encrypted/hashed as set by the securepasswords global config option.

4.13.12. Per IP call limits

You can restrict the maximum number of calls or call duration from a source address by the following global settings:

· maxcallperip: max number of calls from the same IP

· maxdurationperip: max call duration from the same IP

· maxcostperip: max call cost per IP

· maxcallperperiod: the period for the above (1.0 means one day)

· maxcallperuserid: the above will be set to this user only (set to -1 for all users)

4.13.13. IP Spoofing

IP Spoofing means incoming TCP or UDP packets with false source IP which might be used by attackers to impersonalization. You can avoid this with the following measurements:

· If you are vulnerable to IP spoofing, make sure to not use IP based authentication.

· Consider using a techprefix also of IP authentication is required for call (NeedAuth user field set to 3 which means IP auth + tech prefix)

· Make sure that your router or gateway performs proper ingress filtering (blocking of packets from outside the network with a source address inside the network).

· Adjust the allowtrustedip global config option after your needs: 0=no,1=my ip only,2=private ip's only,3=yes(def),4=everywhere(including admin console)

4.13.14. Firewall

The server has a built-in static and dynamic firewall to block unwanted sources. See the “Firewall” section in this documentation for more details.

4.13.15. Maximum simultaneous call limits

To avoid overflow with calls you should set the MaxLines/MaxLinesOffpeak settings for each enduser and traffic sender properly.

(For enduser the default Max Line is 5. We don't recommend to be set to 1, since this might disallow services such as call transfer and conference)

4.13.16. Prepaid account credit limits

Prepaid accounts have a hard limit by their credit value.

4.13.17. Postpaid account monthly spend limits

You can also limit postpaid account to prevent unexpected bills.

Set the “creditcheckforpostp” global config to true.

Set a meaningful default and actual value for each user for the followings: maxmonthlycredit, maxmonthlycreditinc, maxmonthlycreditend.

· 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

To set the default value, you should edit the database default values and then run a query like this:

update tb_users set maxmonthlycredit = X, maxmonthlycreditinc=X, maxmonthlycreditend=X where type = 0 and postpaid > 0

To make it default for new users:

alter table tb_users drop constraint DF_tb_users_maxmonthlycredit

alter table tb_users drop constraint DF_tb_users_maxmonthlycreditend

alter table tb_users drop constraint DF_tb_users_maxmonthlycreditinc

alter table tb_users add constraint DF_tb_users_maxmonthlycredit default X for maxmonthlycredit

alter table tb_users add constraint DF_tb_users_maxmonthlycreditend default X for maxmonthlycreditend

alter table tb_users add constraint DF_tb_users_maxmonthlycreditinc default X for maxmonthlycreditinc

4.13.18. Fix daily credit limits

You can apply a maximum daily limit for all (both prepaid and postpaid) accounts with the following global configurations settings:

· maxdailycreditforenduser (max daily spend for endusers)

· maxdailycreditforts (max daily spend for traffic senders)

· You can also set the limit on user level by setting the "maxdailycredit" field for the respective users. (For this to work you should also set the "maxdailycreditperuser" global config option to 1, but that is auto set at first config reload if at least one user has "maxdailycredit" set)

4.13.19. Dynamic credit/spent limits

Set the "checkmaxdyndailycredit" global configuration option to enable dynamic credit/spent monitoring and call block on threshold.

Once this is turned on, the server will not allow the usage (spending) to grow more than a specified level (maxdyndailycredit_multiplier) within a single day. (The server will always remember the maximum value spend by a single user in a single day. Then it will block the calls if this value is exceed by the specified multiplier)

Configuration:

· checkmaxdyndailycredit: 0=disabled,1=enabled for enduser,2=enabled for endusers and traffic senders

· maxdyndailycreditforenduser_min: will not block endusers if spend below this value (default is 10)

· maxdynmaxdailycreditforts_min: will not block traffic senders if spend below this value (default is 100)

· maxdyndailycredit_multiplier: max grow allowed within a single day. Default is 7 (you might lower it for better protection, however values below 4 is not recommended because that can be considered as normal calling pattern)

The disconnect reason for such calls can be configured by the “quotadiscreason” global config option. Default is 403.

Admins can receive emails about user blocks if the sendadminemailnotifications global config option is set to 2.

For example if user A normally spend 10 usd maximum per day, and if one day it suddenly reach over 70 usd then calls are blocked. Please note that smooth increase if traffic is still fine (the max allowed grows automatically if the user is below the max grow limit).

Another example:

· Monday (firs day) the user spend 10 usd. Fine, the maxdyndailycredit is set to 10.

· Tuesday the user doesn't make any call. No changes.

· Wednesday the user spends 5 USD. No changes since 5 is lower than the previous max which was set to 10 on Monday.

· Thursday the user spend 30 USD. Fine since 30 is lower the maxdyndailycredit * maxdyndailycredit_multiplier (which is 70). The maxdyndailycredit is set to 30.

· Friday the user (or a hacker which have stolen the user credentials) start to make mass calls or calls to expensive direction. Once his spending reaches 210, the account is blocked (210 = the previous maxdyndailycredit which is 30 multiplied with the maxdyndailycredit_multiplier which is set to 7)

Follow these steps to enable this for old database versions:

change tb_users.todaycredit data type from int to decimal(18, 5)

exec sql: ALTER TABLE tb_users ADD [maxdailycredit] [int] NULL

exec sql: ALTER TABLE tb_users ADD [maxdyndailycredit] [int] NULL

add a.todaycredit,a.maxdailycredit,a.maxdyndailycredit to [v_checkuser] select list

set globan config:

maxdailycreditforenduser=1

maxdailycreditforts=1

maxdailycreditperuser=1

4.13.20. Daily/monthly call duration limits

You can apply a maximum daily and/or monthly limit for call duration per user with the following settings:

· maxslperday (max allowed speech length per day in seconds)

· maxslpermonth (max allowed speech length per month in seconds)

When these fiels are set for a enduser or traffic sender then the initiated call durations are counted (preventing the caller to make more calls then these limits).

When these fiels are set for a SIP server then the terminated call durations are counted (no more calls will be routed to the SIP server above these limits).

Calls that was already started will not be interrupted when the limit is reached (the next call will be blocked).

You might set the calcmaxsl global config option to 1 to enable this feature (-1: means auto detect, 0: means disabled, 1: means enabled).

4.13.21. Fraud calls

By default the mizu server blocks most of the well-known satellite and premium numbers (blocksatellitecalls and blockpremiumnumbers).

You can also block other unwanted destinations from routing or billing

4.13.22. Blacklists

With the fix/dynamic and smart blacklist modules you can efficiently block unwanted numbers. See the Blacklisting/Access Lists chapters in this documentation and/or search for “black” in the Configurations form from MManage for more details.

4.13.23. Auto ban

Auto ban can be used to block unsolicited or telemarketing calls by rejecting the caller when bad statistics are detected.

See the Caller banning FAQ point for the details.

4.13.24. Billing and profitability

To make the billing strict (proof protect), 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 tariff list prefix,5=check also parent tariff list

· 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

· blockhighcostcalls: don't route the call if the cost per minutes is higher than this value (default is 0 which means no limit)

Note: In the price lists you can set the * prefix with a very high cost (to be blocked by the above settings) or don't set at all to avoid wildcard matching.

(* prefix means any other prefixes which you haven't explicitly set)

You can implement call blocking to certain destinations by using "null routes".

Just create new routing patterns ("Routing" form) and don't set any destination for them (empty right side list).

This way the calls that matches your definitions will be blocked.

4.13.25. Alerting

Admins and support users can receive email, sms and/or push notification alerts about important events as described here.

4.13.26. Security checklist

The Mizu softswitch comes with default secure configuration, but extreme secure settings might prevent comfortable usage and we had to think about a good balance of security and usability. You might go through the below points to further secure your VoIP environment. Do not attempt to change all these settings, only those which are relevant for you.

Network security:

· make sure that your router or gateway performs proper ingress filtering (blocking of packets from outside the network with a source address inside the network).

· set proper firewall rules to protect your services (not important for the VoIP service itself, but you might host other services within your network which might require firewall protection)

· set proper packet flood filtering rules

· be aware of DDoS attacks and its mitigation especially if you are a big organization or VoIP is vital for you (while the VoIP service is capable to mitigate DDoS attack by itself, this will not help if your ethernet ports are fully flooded). Use a network provider capable to mitigate DDoS attacks.

· disable all unneeded network services such as NetBIOS and related services

· use secure access (HTTPS for websocket, TLS for SIP signaling, DTLS/SRTP for media, tunnel for admin access)

OS security:

· do not install any third party software on your VoIP server and don’t use it’s desktop for your daily work

· run MManage -> Config -> OS -> Secure Windows

· enable the embedded windows firewall. It’s speed and application level packet filtering is perfect for VoIP. Enable only the needed applications (mserver.exe, mssql.exe, vfpt.exe, tlsproxy.exe, mizuweb.exe)

· disable all unneeded network services (File and Printer Sharing, IIS, FTP, etc. With a clean windows install this is not necessary since not installed/enabled by default)

· disable NetBIOS over TCP/IP and Client for Microsoft Networks on network connections where it is not needed.

· don’t install any virus scanner (it is meaningless)

· choose a strong password for your OS accounts (especially for the Administrator account and better if you don't create or disable all unneeded OS user accounts)

· rename the Administrator account

· run the Microsoft Baseline Security Analyzer tool

· change the RDP port, preferably to 60089

(registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp)

· use the Tunnel for remote access (built-in encrypted + compressed secure access)

DB security:

· choose a strong long password for your database access (especially for the sa account).

· change the default MSSQL port from 1433 (this is not a security issue, but when the MS SQL runs on the default ports, you can experience lots of login attempts).

· restrict the SQL service account (especially if your server is not dedicated to VoIP / you are using the server also for other purposes)

· create users with different roles and set only minimal rights as required (especially if the engine is hosting also other databases)

VoIP service security:

Check these parameters (don’t set them blindly as some of these parameters might turn the server completely unusable for your use-case):

· strengthen the above listed configurations (DDoS attack prevention, per IP call limits, max monthly call and credit limits, daily credit limits, max line per user, etc)

· request (and verify) as much data from your subscribers as necessary (country, email address, etc)

· increase minpwdlength (default value is 4)

· set the fwdtootherdomains global config option to 0 to disable arbitrary call routing to other domains

· set the apiv2key global config option to a random value (a short 5 digit number will fulfill its reason)

· set the enforcestrongauth global config option to true (true by default since v.5.2 2013)

· set strongdigestauth to 1 (you might set it also to 2 but this is too much usually and not compatible with some devices)

· set the allowcalleridchange global config option to 0

· set the useshadigestauh global config to 2 to use SHA-256 instead of MD5 (if clients supports this)

· set the “allownoauthfork” global config option to 3 or 4

· set the “stricttransport” global config option to 2 or 3

· make sure that all users have a strong password (this should be fulfilled automatically if the rest of the settings are set correctly)

· set authfastusers to 1

· set remoteadmin to 0,1,2 or 3

· set max amount, max ports for users

· set maxmonthlycredit per user (as discussed in above sections)

· set callingcardauth to a more strict check (for example set to 9 for pin code strict only)

· configure the maxdyndailycredit global config option and dynamic credit/spend limits as discussed in above sections

· set the validateinput global config to 3 or more (0=no,1=basic without sql check,2=basic with sql, 3=normal,4=more,5=extreme)

· set the validatepassword to 2

· set the autocreatereguserstrict to 1

· set the securepasswords parameter to 1 or more

· set a random serverapikey (don’t change it if you already have customized softphones)

· set publicservices to 0

· set the uauthverifypwd to 0

· set blockotherdomains to 1

· set fs_restrictsiptolocal to 3

· set blockscanning_treshold to a positive low value such as 10

· set the forwardclientaddress to 0 (to prevent forwarding the peer location)

· set the apisipauth to 1 (to enforce SIP authentication for API access when appropriate)

· set allownoauthcalls to 0

· set allowanonymouscaller to 0

· set securemove to 1 or 2 to prevent 301/302 call forward routing to traffic senders

· set reuseep to 0

· set reuseepauth to 0

· set reusedifferentportreg to 0

· set reuseupperregep to 0

· set cacheregistrations to 0 or 1

· set enablefirewall to 5

· set autoban to 2

· set earlystart to 0 and/or blockearlymedia to 1/2/3 and/or blockearlymedia_in to 1/2 if you wish to block all early media (including inband ringtones)

· leverage TLS security (optional)

· remove the “Lookup A number” option from Traffic senders if it is not a DID provider for users

· disable unwanted directions (unwanted countries, etc)

· check your traffic on a daily basis or setup scheduled tasks to check abnormal traffic amounts and notify you by sms or email. Use the Analyze form regularly.

· setup the allowed ip and trusted ip global config option properly by the apiv2ipauth global config option (applied especially for the http api). Disable trustlanip from global config if not needed.

· set trustsubnet, trustauthip and treatusersasknownip to false (these are false by default)

· set the allowtrustedip to 1 or 2

· set simultancallscreditcut to 3

· set the blocksatellitecalls and blockpremiumnumbers to true

· check proper dtmf input in your ivr scripts

· check your global configuration parameters related to IP, port, currency, credit amounts and other restrictions

· make sure that the A number authentication is set correctly if you are using IVR call forward. disable if not needed (turn off for each traffic sender at the "Functions" tab and/or set the anumberhandling global config option to 0)

· you should verify first payment manually (don’t accept automatically first PayPal payment from not verified users. see the PayPal settings)

· disable JSONP to other servers by setting the enablejsonp global config option to 1

· set handlerefer to -1 or -2 if you don’t need call transfer

· disable conference rooms if not needed (set enableconferencerooms to 0)

· you might set the autofinetune to 0 to set consistent service level and disable runtime feature set changes (but this is not optimal for servers with occasional high-load)

· search for billing related configurations: search for “credit”, “bill” and “pric” in the config wizard

· disable http file upload if no file sharing services are used by setting the allowhttpfileupload global config option to 0

· set apidefneedlogin to 3 for nonce verification on API access

· set apideftrustadmin to 4 (0: no, 1: admin if trusted ip (def), 2: always ip only, 3: always pwd only, 4: always ip+pwd)

· you can also apply system level limits by the licensecfg global config option (see the “License limitations” FAQ section)

· set the default credit to 0 by executing the following queries (from the direct query form or from SQL management studio):

alter table tb_users drop constraint DF_tb_users_Credit

alter table tb_users add constraint DF_tb_users_Credit default 0 for Credit

· if you have reached here, maybe you are interested also in the performance related settings (see the “Performance optimizations -fine-tune” FAQ)

4.14. High availability

With the Mizu VoIP you can implement a highly available VoIP service with automated backups and auto failover on all levels.

Please visit the following documents for the details:

4.14.1. Large scale VoIP

4.14.2. HA VoIP service

4.14.3. HA database

4.14.4. Database failover

4.15. Maintenance

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 lots of traffic then you may need to watch the system parameters closely, setup proper alerting thresholds and adjust system setting as required.

4.15.1 Server configuration checklist

Software’s

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

Firewall

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

-block: all others, file sharing, ms network

Services and memory

Auto restart critical services

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

Licensing

Setup configuration with the proper software(s)

Config

Setup FTP and Voice directory NTFS access

MSSQL

Change port to 2223

Enable pipes

Check configuration in Management Client

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

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

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

4.15.5 Server backup, recovery and maintenance

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 ratability you should use the MS SQL backup related capabilities instead of using the mizutech built-in backup methods.

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.

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)

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.

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

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.

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.

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

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

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.

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

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 ratability you can also setup continuous backup (with replication or log sipping)

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

5. FAQ

Frequently Asked Questions

5.1. Abbreviations

Common terms used in this document:

Caller: The person making/initiating a call

Callee: The person receiving a call (called party)

Global config: server wide configurations which can be edited from MManage “Configurations” form and stored in the tb_settings table

ASR: average success ratio (percent of the connected calls)

ACD: average call duration. The same as ACL (ACD can also mean Automatic Call Distributor, but this is not used here)

ACL: average call length. The same as ACD

SIMID: sim identifier. 13-17 digit number stored in the simcard (and written on the simcard)

IMEI: gsm engine identifier (should be globally unique)

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

PF: profit. (for correct values, requires your billing module to be properly configured)

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

CCC: concurrent (simultaneous) call count

CC: callcenter

TCP: is a connection-oriented internet protocol

TLS: encrypted TCP

UDP: internet core protocol for datagram packets (not reliable)

RTP: media channel protocol

SIP: The Session Initiation Protocol (SIP) is a signaling protocol used for establishing sessions in an IP network. A session could be a simple two-way telephone call or it could be a collaborative multi-media conference session.

WebRTC: Web Real-Time Communication used implemented in HTML5 browsers and other clients

H323: H.323 is an ITU (International Telecommunications Union) recommended standard, which provides a foundation for audio, video and data communications on non-guaranteed Quality of Service networks

RAS: used in H323. Used between the endpoint and its Gatekeeper in order to

Allow the Gatekeeper to manage the endpoint (Registration, Admission, and Status)

GK Registration: Endpoint will send an RRQ and expect to receive either an RCF or RRJ

H225: Call Signaling is used to establish calls between two H.323 entities

H245: generally transmitted on a separate TCP connections by most older endpoints

REGISTRAR: server-side component that allows SIP REGISTER requests

IEC: international escape code

NEC: national escape code

AC: area code

NUM: phone number

ANI / CLI – Automatic Number Identification or Caller Line Identification

IVR – Interactive Voice Recognition

LCR: least cost routing (price)

BRS: best route selection (price + quality + other settings)

SRTP: media encryption protocol
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
SMS callback: callback triggered by received SMS message. You have to subscriebe to a two way sms service like clickatel.com. users can be authenticated by sender ID, pincode or username/password insterted to the sms text.

5.2. Text to Speech

TTS capabilities are available for the Mizu VoIP Server IVR system to play any text, without the need to have a recorded voice file for it.

You can use Microsoft SAPI or eSpeak (espeak.msi), configurable with the tts global config option, then use TTS commands in your IVR scripts after your needs. See the IVR guide for more details.

5.3. Spam calls

If your server is exposed on the public internet, then you can expect all kind of attacks, password guessing scripts and junk call attempts.

This is normal for public facing servers and should be mitigated automatically by the server. Just make sure that you are using strong passwords, including for the SIP accounts.

In case if your customers are connecting only by app/service, then you might use non-standard ports (for example port 5070 instead of the default 5060) and/or you can restrict the apps after their User-Agent with the alloweua global config.

See the security guide for more details.

5.4. How can I make test calls?

1. simply right click on a channel (“Simcards” form) and select the “Test call” option

2. or use one of the voip clients from the “Config” menu -> Utilities

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

1. In the “Set Directions” box set the preferred simid. Then go to the “Statistics” form and check the ASR/ACD values.

2. Start some test calls (right click on the preferred channel and then hit the “Test Call” menu)

3. Listen to conversation. (“Voice Here” form)

5.6. Manually remove upper push registrations

This might be used if you have a gateway with multiple servers and you wish to wipe out push users to a certain upper server:

delete from tb_users where type = 0 and (contactname = 'DOMAIN' or contactname = 'IP' or hwid = 'DOMAIN' or hwid= 'IP')

5.7. Server Recovery (in a separate app and db 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

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

1. Check the logs (filtered to „Server”)

2. If you cannot find the solution then.

a) Restart the server.

b) Call the administrator.

5.9. Calls in „routing” status

1. If all calls are in routing status, then restart the gateway.

2. If this behavior is specific only for some of the gateways, then check if you have enabled the voipgsmgw.exe and the vclientsrv.exe on the windows firewall.

3. If enabling this programs on the firewall and restarting the service (stop.bat, start.bat) will not help, then do a software upgrade and restart the PC.

4. If still in routing mode, then call the administrator.

5.10. SIP caller cannot call

1. Check disconnect reasons in cdr record for that caller

2. Check username/password

3. Check credit (if prepaid user)

4. Check caller techrefix, and the routing settings for that techprefix

5.11. SIP called cannot be called

1. Check disconnect reasons in cdr record for that called

3. Check if username exists

4. Check if usergroup matches the caller usergroup

5. Check user firewall settings

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

1. Check routertp settings for the caller and the called

2. Check called firewall and nat settings

5.13. Wrong disconnect reasons

1. Check firewalls

2. Check the log file for that directions

5.14. MManage cannot connect to the server

1. Ping the server box. If ping is working, then check your username/password

2. Restart the server if you are sure that it is blocked

3. If still is not working, call the administrator immediately

5.15. Too slow MManage

1. Check your internet connection

2. Check server processor load. If too high, then check server logs, and if necessary, restart the server

3. If the problem persists, call the administrator

5.16. Query user register state

Using the API, you can use the reguser request to get the register state of a user like this:

http://SERVERADDRESS/mvapireq/?apientry=reguser&usr=USER_TO_QUERY&authkey=APIKEY&authid=ADMINUSERNAME&password=ADMINPASSWORD&now=555

You can also request the register state of a user from the database using the following SQL query:

select top 1 id from tb_users where username = 'USER_TO_QUERY' and status > 0 and statusdate > getdate() - 0.1 and Enabled <> 0 and temporarydisabled <> 1

This will return the user id if the user is registered, or null/no record if the user is not registered, disabled or doesn't exists (status 0 means unregistered, 1 registered, 2 and 3 means user is in call).

Note: direct database connections are not available with the free/compact version.

Call decisions based on user register state usually can be handled by the server itself.

For example you can create a routing rule where you will add multiple target users (or a group of users) and the server can automatically route the call to the "best" available user (registered, not in call, longest time not routed and/or priority orders)

5.17. How to set advanced user settings?

There are many advanced user settings which can be applied for endusers/traffic senders/sip servers/other users and don’t have a GUI element on the “Users and Devices” form. These are more rarely used settings with no exposed user interface controls to prevent cluttering the configuration pages, however you can still easily change them using one of the following ways:

· Users and Devices form -> Settings page -> Details link -> Edit field

· Drag the splitter right to the Users and devices tree view control until a grid appears (or click on the Details link -> Toggle grid link). Click on the “Search fields” link and enter the field name or a part of it then hit the Enter button. The grid will be reloaded displaying your field as the first column where you can edit it as you wish.

· Use a simple SQL query from the Direct Query form. For example: update tb_users set xxx = y where username = 'zzz'

5.18. How to set a random caller-ID?

The Caller-ID can be rewritten to a random number or to a random number with a specified prefix or to a random number from a specified list or by any other SQL driven logic.

You can use the Rules for this (“Rules” form).

Create a new rule with the following parameters:

· Run at: At routing end

· Conditions: after your needs

· Get Data: callernumber

· Action: Full replace

· Data to set: CallerNumber extended

The Action Value should be set to something like one of the followings:

+9222222222

This will generate rewrite the caller-id to the specified +9222222222 number (not random, mentioned here only for clarification).

+9222222222{SELECT FLOOR(RAND()*10)}

This will generate numbers between +92222222220 and +92222222229.

234{SELECT FLOOR(RAND()*90000000)+10000000}

This will generate numbers beginning with 234 and total length of 11 digits. Example: 23480635297.

Example to rewrite the called number to first 8 digit from the called number and 5 random digits using two queries in the Value string (because it is possible to use multiple queries):

{select substring('[callednumber]',1,8)}{SELECT FLOOR(RAND()*90000)+10000}

Example to rewrite the called number to first 8 digit from the called number and 5 random digits using one query:

{select substring('[callednumber]',1,8) + CAST((SELECT FLOOR(RAND()*90000)+10000) AS VARCHAR(32))}

To set a caller id from Phone Numbers, you can use this string for the rule:

{SELECT TOP 1 telnumber FROM tb_telnumbers WITH(NOLOCK) WHERE ttype=X and free=X ORDER BY NEWID()}

You might also create a separate table to store your numbers and load from there (instead from the tb_telnumbers table).

For example create a table named tb_calleridnumbers with one number field as varchar and use a query like this:

{SELECT TOP 1 number FROM tb_calleridnumbers WITH(NOLOCK) ORDER BY NEWID()}

It is also possible to specify endpoint keywors in square brackets. For example you might select a caller id which match the called number country like this:

{SELECT TOP 1 number FROM tb_calleridnumbers WITH(NOLOCK) WHERE '[called_norm]' like SUBSTRING(number,1,2)+'%' ORDER BY NEWID()}

In this query the [called_norm] will be replaced with the normalized called number and a random number will be selected with a match for the first two character (the country prefix code)

Another example in case if your tb_calleridnumbers has a prefix column which should match with the prefix of the called number (3 digits), ignoring the first digit (with other words: the second, third and forth character from the called number must match the 3 digit prefix column in your tb_calleridnumbers table):

{SELECT TOP 1 number FROM tb_calleridnumbers WITH(NOLOCK) WHERE prefix = (select substring('[callednumber]',2,3)) ORDER BY NEWID()}

5.19. Import/export data

Any data/rows can be imported/exported to/from the VoIP server database tables using one of the following methods:

· MManage -> File menu -> Export/Imports

· SQL Management Studio -> right click to database to bring up the popup menu -> Tasks -> Import…

· Using direct SQL (INSERT commands or BULK IMPORT) from MManage -> Direct Query form or from SQL Management Studio

· You can also import/export to a new temporary table first and from there insert to the final table.

5.20. User settings

Many configurations can be set on two levels: globally or per user.

For global configurations just use the “Configuration Wizard” (for the important settings) and “Configurations” form (for all settings).

Per user settings can be configured in the following way:

The most important settings can be set from the MizuManage user interface from the “Users and devices” form.

Other (more advanced / all) per user configurations can be set multiple ways:

· Users and devices form -> Expand the grid (scratch out or double click) -> Search field link -> Enter the field name or a part of it

· Users and devices form -> Details link -> Edit fields

· Direct Query form -> use SQL like: UPDATE tb_users SET fieldname = 'fieldvalue' WHERE id = 1234 (or WHERE username = 'user')

5.21. Create custom reports

You will need some minimal SQL knowledge to be able to create custom reports.

An easy way to create reports is to create something similar from MManage first, then go to Direct Query form and click on the "Last" link which will show the last SQL executed by MManage and then you modify it after your needs.

For example a call details report can be easily listed by just using the CDR form:

1. Open the CDR form

2. Select "All" from the drop-down list (instead of the default "Last 35")

3. Se the correct date - time interval (left-top time dropdown -> select "Custom" and then select start/end date)

4. Fields menu -> Filter -> Set Direction Filter: select Source enduser or traffic sender

5. Execute the query and then go to the Direct Query form, load it with the "Last" link and modify it after your needs

This is how such a query looks like (copy-paste it to the Direct Query form and execute):

SELECT b.datum as 'Date', b.realduration as 'Seconds', cast(b.costenduser as decimal(10,2)) as 'Cost', u1.username as 'Caller', b.callednumber as 'Called',

(select top 1 tb_directions.name from tb_directions with(nolock) where b.dirid = tb_directions.id) as 'direction name'

from tb_cdrs b WITH(NOLOCK)

left join tb_users u1 with(nolock) on (b.callerid = u1.id )

WHERE

b.datum > '5/1/2025 0:0:0' AND b.datum < '5/31/2025 23:59:59' AND

b.callerid = X AND b.realduration > 0

ORDER BY b.datum

5.22. SQL to reset upperserver register routing

reset upper servers:

update tb_users set sendcfgcount = 0, lastrouted = getdate() - 1, hwid = '', ContractComment = '' where username in ('xxxx')

reset selfrest regival:

update tb_users set RegTimeout = 1 where RegTimeout > 1 and username like 'self%'

5.23. SQL to reset user multi-device addresses

Execute this query if the server is sending the calls (also) to old/wrong addresses for multihome users / call fork:

update tb_users set addrlist = '', transip = '', transport = null

5.24. Media Routing

The Mizu VoIP server includes advanced RTP routing capabilities including RTP/RTCP routing or offloading, voice/video/fax/data routing, NAT handling, DTMF processing, media transformations, RTP mixing for conference calls, transcoding, voice recording, statistics generation and more.

It is important to be aware that if all media is routed via the server this can be responsible for ~80% of the total CPU and ~95% of the bandwidth usage (so the signaling and all its processing requires only ~20% CPU and ~5% of the bandwidth), thus it is important to take attention on this and try to offload as many media routing as possible.

SIP endpoints are usually capable to rote the media between directly between them (peer to peer) and only the signaling have to go through via the server.

Whether the endpoints is capable for direct RTP routing, depends on the followings:

· Endpoints are behind NAT or has a public IP (if one endpoint is public and the endpoints are not very dumb, then the RTP can be routed directly; if both endpoints are behind the same NAT then direct routing should always succeed if the endpoint can use private IP or the router can route back packets to its public IP)

· NAT type: how the router(s) or the NAT device(s) handles the NAT mapping as described here

· Endpoint capabilities: ICE/STUN/TURN usage, intelligent NAT handling, stable RTP ports, keep-alive, rport support, UPnP

· Firewall/access control rules: some gateways and other devices such as carrier equipment might be configured to accept the media only from the signaling address especially with IP based authentication

Common scenarios:

· When call is made between endusers, it is very possible that both of them are behind NAT and in this case the server should route the RTP except if the users are using advanced SIP clients or they are behind the same NAT.

· For inbound and outbound calls the trunk/gateway/service provider most probably is on a public IP thus the media should be able to pass directly.

· If some server side media processing must be performed (such as conference mixing, voice recording or DTLS decoding) then the media will be always routed, regardless of the settings.

The Mizu VoIP server can decide if RTP routing is necessary based on the server settings and the above conditions as detected by the server.

The media routing can be configured from MManage:

· globally from Config Menu -> Configurations -> RTP relay (will change settings for all users and default values for new user records)

· by user: from Users and Devices form -> Functions page -> Media relay -> Route RTP caller/called settings (mapped to tb_users.RouteRTPCaller and RouteRTPCalled fields)

The configurations are loaded and merged from the caller and the called party user. If the routertp setting is set to 1 or 7 and it will be applied regardless of the other endpoint setting, otherwise the more strict setting will be applied.

The following values are defined:

· 0: check caller/called settings: will load the config from the peer user settings. You should use this only for one of the settings such as for the RouteRtpCaller.

· 1: don't touch the sdp and the rtp: the SDP will be forwarded as-is. Use this if for some reason you don’t want the server to touch the SDP and the media or the server is doing something incorrectly. [Same as “Bypass” config]

· 2: sdp correction if necessary: the server might modify the SDP in a way to make the RTP direct routing possible such as changing private IP to public, inserting more candidates, fixing codec misconfigurations and handling known NAT related issues including known software dependent bugs. Use this only if you always wish to avoid RTP routing

· 3: route rtp if both behind nat: if both endpoints are behind NAT then RTP routing is usually necessary, especially if the endpoint doesn’t have advanced NAT handling capabilities such as STUN usage. This should be the preferred setting to offload as many media routing as possible. [Same as “Auto –Performance” config]

· 4: route rtp if caller is behind nat: rarely used, similar to 6

· 5: route rtp if called is behind nat: rarely used, similar to 6

· 6: route rtp if any endpoint is behind nat: a very conservative setting to make sure that RTP can always pass. Use this instead 3 if users are using dumb endpoints. [same as “Auto –Strict” config]

· 7: always route rtp: will route the media unconditionally. Use it if media routing is a must such as peer accepts RTP only from signaling IP or for topology hiding [Same as “Route” and “Force route” config]

The server can take intelligent decisions whether to route or offload the media only if the above setting is configured to 3,4,5 or 6. For example it will bypass the media if both device are behind the same NAT and direct routing should be possible.

Media routing should be avoided whenever possible.

The softswitch is capable to "intelligently" find out if it needs to route the media or not (to bypass the RTP routing whenever possible and route the RTP only when necessary).

You can reconfigure the default settings globally (for all users) from Config menu -> Configurations -> RTP Relay or by users from the Users and Devices form -> Functions tab -> Media relay.

The most conservative setting is the "Always route rtp", when MPUSH will always relay the media streams (the RTP should succeed in this case even if both parties are "dumb").

If you wish to avoid RTP routing by the server (to reduce CPU usage and shorten the RTP path), then you might set this to one of the followings:

o “Route RTP if one peer is behind NAT”: this is fine if the other peer has good RTP NAT handling capabilities. For example if your server has advanced NAT handling, then you might set this option to it (SIP servers -such as Asterisk- has only very basic NAT handling capabilities)

o “Route RTP if both behind NAT”: RTP routing between endpoints are usually required, even if both peers has advanced NAT handling capabilities (because sometime they might not be able to determine their correct public address)

o “SDP correction if necessary”: Probably you should never use this (unless you know that the peers are always on public IP or both peers has advanced NAT handling)

The recommended setting is:

· 3: for best performance and quality (99% of the calls should behave correctly and only dumb SIP endpoints might fail for which you might set to 7)

· 6: if you must ensure that no calls can fail due to poor endpoint side NAT handling

· 7: for restrictive trunks or topology hiding only

The advantages of media routing are the followings:

· NAT handling can’t fail

· Server side media handling capabilities (call recording, transcoding, etc. But if server side processing is needed, the media is always forced to be routed anyway.)

· Topology hiding (when you don’t wish to reveal the other endpoint address)

The disadvantages of media routing are the followings:

· Higher CPU usage

· Higher bandwidth usage

· Longer media path which might result in more delay (if the server is not close to the endpoints or on the way between them)

5.25. Export CDR’s

You can easily export CDR records by listing them on the CDR form (with the desired date-time and direction filters) and Save as csv or html (from File menu).

For example here are the step-by-step instructions to export all CDR’s from a traffic sender:

1. Launch MManage and login

2. Open the CDR form

3. Below the (Re)Load button, select “All” from the drop-down box

4. Select desired date-time interval (change from “Today” to “Custom” and select start/end date)

5. Launch View menu -> Filter -> Set Direction filter and for the source select Type: Traffic Sender, Name: XY and click OK.

6. Click the (Re)Load button on the CDR form

7. Export to file from File menu -> Save as (select html or csv file type) and send the resulted file to your traffic sender if needed

5.26. Server software problem (service unavailable)

1. Restore the last good configuration (Stop the service with stop.bat, copy all files from the lastconfig directory, near the current config and restart the service with start.bat)

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

1. Follow the failover plan.

2. Call the administrator

5.28. How to restart the server service

MManage->Administration->Server Console->Connect and send the „servicerst” command

5.29. How to restart the server box

-MManage->Administration->Server Console->Connect and send the „pcrst” command

-If you cannot connect with MManage, you can find a small program in the vclients directory named „serverrst” (usually at C:/Program Files/VCLIENTS/ serverrst.exe

-If these does’nt work, then the server has a serious problem. Follow the failovering plan and call the administrator

5.30. How to restart a GSM gateway

-MManage->Administration->Server Console->Connect and send the „client,XXX” command, where XXX is the gateway name or ip address. When connected to the gateway, send the „pcrestart” command

-if this does not work, then try to connect with remote desktop to the required gateway

-if the gateway is unreachable, then the pc or the internet is down.

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

Depending from Gateway Configuration inccalls value.

(0=drop,1=hold a little then drop,2=auto forward,3=forward to server as forwardnum,4=forward to number requested by dtmf)

Check the Gateway Configuration for more details.

5.32. Routing test calls to a dedicated gateway

set the calledpriority to the techprefix of the traffic sender

calledpriority: all calls with the specified techprefix will prioritize this gateway (but other techprefixes can go to this gateway also)

testprefix: only the specified techprefix can go to that gateway (but the specified testprefix can go to other gateways also)

so if you want a dedicated gateway for a techprefix, then you have to set the calledpriority and a testprefix too

example:

update tb_users set calledpriority = '987', testprefix = '987' where username = 'TESTGW'

then all calls with techprefix 987 will go to TESTGW with high priority

in case when the TESTGW channels are not available, the calls can be routed to an other gateway

5.33. How to disable PIN request on GSM gateways

The easy way

Set up the pincode entry under the [gateway] or [phoneX] section with the valid pincode. The gateway service will remove the pincodes automatically.

The hard way

1. Start GWTest and switch to the preffered channel/simpos

2. „login” with: AT+CPIN=xxxx (where xxxx is the original pin code)

3. Disable pin code request with: AT+CLCK=”SC”,0,”xxxx” (where xxxx is the original pin code)

4. in the next switch on, the sim will login to the gsm network automatically

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

On the “Configuration” form select “Basic” settings and check at least the following values:

LocalIP, LocalInternalIP, LocalDomain, currency, Routing, emergencydir, creditunit

5.35. How to add a new traffic sender?

In the “Users and Devices” form select Traffic Sender. Load the list and then hit the “New” button. Then you have the option to clone an already existing traffic sender. Set up the authorization correctly!

5.36. How to add a new sip enduser?

In the “Users and Devices” form select Endusers. Load the list and then hit the “New” button. Then you have the option to clone an already existing traffic sender. Set up the authorization correctly! Check the credit and prepaid/postpaid option!

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

Mizu gateways will register automatically on the server. You may adjust the properties when the gateway is present. After that, you have to set up its sim channels correctly.

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

Create a new packet in the “SIM Packets” form. Set up a meaningful name, specify if is postpaid or prepaid and walk through the other options (ownership, access list, recharging options, etc)

5.39. How to add a new simcard?

GSM channels will register automatically on the server. Then you have to set up its properties (to which packet it belongs, recharge options, owner, etc)

5.40. How to set up basic routing?

On the routing form add routing patterns to cover all possibilities (directions and times). Then you have to add your sim packets or other direction in desired priority order. Specify as many simpackets with the same priority as you can (so the server can do the routing too after the other conditions. For example the quality.)

5.41. How to set up basic billing?

On the “Price Setup” form add a new “Invoice and statistics” entry. Then you can add packets to it, which will define the traffic direction when the actual packet will be active and the price.

5.42. Where can I check the logs and traces?

1. “Logs” form

2. “Server Monitor” form

3. Set up your trace level in the “Configurations” form (filer after the “log” expression)

For more details see here and here.

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

In the Gateway Configuration check the followings: volumein, volumeout, vgr, vgt

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

In the Gateway Configuration check the followings: gkip, gkpassword, gkdiscover, gkprefixesX

5.45. What ports are used in the system?

Standard SIP signaling port: 5060 (TCP and UDP)

SIPS: 5061 (TCP/TLS)

Access port: 80 (TLS)

Secure access port (443 TLS)

Default H323 signaling port: 1720 (TCP)

H323 signaling port used by Mizu gateways: 1721 (TCP)

Rdesktop port: 8836 TCP

SQL Server port: 1433 or 2223 TCP

“Voice Here” port: 44444 UDP

Mizu server admin port: 9885 TCP

Mizu server comm. port: 9886 TCP

Mizu server log port: 9889 TCP

Virtual SIM port: 9886 UDP

H323 additional port: configurable dynamic TCP

Media ports: configurable dynamic UDP

WebServer: 80 TCP

FTP: 21,22 TCP

The exact port numbers used by softswitch can be listed from MManage -> Config menu -> Network - > Active Ports.

5.46. My gateway restarts too often

Check the watchdog settings. For example the gateway will restart if no traffic is routed on it for 3 hour by default. Also check the maxwrongcalls and maxnotconnectedcalls settings

5.47. H323 signaling problems

Check your firewalls.

Check Gateway Configuration: onlyg7x, connectwithmedia, enableh245tuneling, faststart.

5.48. How to set up the automatic credit recharge?

First you have to set up the “Message Rules”.

The packet must be set to prepaid. Proper Credit Request/Charge command must be defined. See at 4.6.1. SIM Packets

SIMcard “Credit and Recharge” setting must be set accordingly.

Message Rules types:

-0: msgbgn need to be replaced with msgend before further processing

-1: if msgbgn was found in the sms than it means a successful recharge

-2: credit value between msgbgn and msgend

-4: if msgbgn was found in the sms than it means a failed recharge

5.49. The automatic credit recharge is not working

Check mincreditonrequest, creditrequestival for the packet.

SIMcard “Credit and Recharge” setting must be set accordingly.

Check the CreditRequestFail and CreditChargeFail (the server will try only 5 times. Reset to 0 if the problem is eliminated)

Check the other fields in the simcards regarding to credit charge and request. (fieldnames that contains the “credit” word. You have to check the “All Fields” checkbox on the SIM Channels form to see those fields)

Check if you have charge card for the required simpacket.

Check Logfiles (filter for “credit”)

5.50. How to monitor the credit automation?

Method 1: Launch MManage -> Sim Platform -> Credits and check the “credit history” queries

Method 2: Launch MManage -> Monitoring -> Logs and filter for “credit related”

To monitor the credit automation for a selected simcard, you can filter after the simid both in logs and in the Credit form.

5.51. Gateway and channels are inactive

Check if the gateway has internet connection.

5.52. How calls are processed

1. The SETUP or INVITE signal arrives from the traffic sender

2. If the caller is not allowed by the firewall, the call will be silently dropped

3. If the caller is blocked (e.g. DOS attack protection), then call will be silently dropped

4. Caller authorization (by source IP address, username/password, techprefix, etc)

5. Check the call parameters. If doesn’t fit into the predefined limits, the call will be dropped (example: too long called number)

6. Rewriting the called number if any Prefix Rule Match

7. Normalizing the called number (validating call prefix)

8. Searching for the best routing pattern

9. Searching for best route direction (available channels, priority order, round-robin, LCR, BRS, failovers, rerouting. etc)

10. Calculating the maximum speech length based on caller credit

11. Checking class 5 features and other endpoint settings (media routing, early-start, etc)

12. Initiating protocol conversion if needed

13. Routing the call to destination

14. Checking for call status, dropping if time exceed and other call monitoring tasks

15. Collecting CDR records at the end of the call

16. Calculating the prices of the call (realtime billing)

5.53. How to set up holiday billing

In the price form in “Time Definitions” select the “Holiday” entry

Set the priority higher in the Directions settings

5.54. How to treat specific weekends as weekdays

Set up a new entry in the holidays form and don’t set as holiday (uncheck the checkbox)

5.55. How to add endusers

Endusers can be added to your server multiple ways:

· MManage admin user interface

o Users and devices form -> click on the New button

o Users and devices form -> right click on the New button for more options

o Import users from Config menu -> Users

o Import data from file menu -> Import/Export

o Generate users in bulk from the “Generate users and PIN’s” menu item

o Quickly add an enduser: right click on the “Users and devices” tree view node and select “Add enduser”

· API: you can use the API to programmatically add users

· Softphones: users can self register to your service also from the customized softphones

· Web control panel: the VoIP servers ships with a web control panel where your users can manage their settings, recharge or see their call history and statistics. On the first (login) page of this control panel there is a “New user” link which can be used by your new customers to register themselves.

· Database: you can directly connect to the database from any environment or programming language to instert new user records. Example: insert into tb_users (type, username, password, credit) values (0,’username’,’password’,0)

· Web site: you can create endusers also from your website using the VoIP server API or via direct database instert

5.56. SimChange settings from the command line

format:

simchange1= 2004.03.05/13:00:00 - 2004.03.07/13:00:00 - 8936302403070132426 (from date - to date)

simchange2= 10:20:00 - 10:26:00 - 8936302403070132426 (every day from time to time)

simchange3= 2/10:20:00 - 7/10:26:00 - 8936302403070132426 (from Tuesday 10:00 to Sunday 10:00)

simchange4= 6/00:00:00 - 7/24:00:00 - 8936302403070132426 (Saturday and Sunday)

there is a priority order from top to bottom (simchange1, simchange2, etc.) numbering begins from 1 without holes

tip: you can set date-hour prioritization

tip: 24:60 is a wrong time (minutes ends with 59)

tip: on day and exact date settings the roundrobin trick is not working

5.57. How to reenable blacklisted but good numbers

Do the followings to reenable good target numbers:

- In MManage -> direct query, under the misc section check the “reenable blocked but good numbers” section

- delete old number from the helper table (section 0)

- run the query from section 1. this will load blacklisted but good number. The query execution may take 15 minutes

- list found numbers (section 2) and check it agains the blacklist (section 3)

- now you may delete blacklist entryies or set the “sure” level lower. First check the requested blacklist entry agains the query in section 4 (found numbers may be only a subset from the blacklist entry and in this case you may not delete or modify the blacklist. But if the asr and acl values are good for the blacklist entry, you may delete or modify it). Before you delete or modify the blacklist entry, check the comment (why was that number blocked). Number with comment “jukak” or “autdisabled monthly/weekely/daily” should be deleted or changed without problems.

5.58. How are different currencies handled?

In the global configuration, a global currency can be defined by the “currency” setting. For example ‘EUR’, and there is the possibility to convert other currencies (used for pricelists, simpackets, users) to this “native” currency. For prices defined in “Price List” form, there is a possibilty to convert all input prices in “native” currency by checking the “Convert to XXX” checkbox. In this manner for example you can import a pricelist in other currency and that will be converted automatically in native currency when calculating CDR prices.

The conversions are done based on the settings in the “Currency Converter” form. You should update the conversion rates here as frequently as possible.
If you wish, you can leave the original value intact, so you can make your billing in other currencies than the native.

For every simpacket you can also define the currency, wich will affect the simcard credit calculation (automatic simcredit requests and recharges for prepaid simcards). Simcredits can be converted in the native currency format if the “convertsimcreditcurrency” configuration option is set to true. So you can have simcards in different countries, but all simcredits will be shown in the native currency.

For endusers and traffic senders you can also define different currency format in the Users and Devices form, Billing tab. The currency format defined here will be taken in consideration by the billing process.

Realtime price calculation in CDR records and the credit calculations for prepaid users are always done in the global currency (can be set up in configuration->currency)

However, you are able to set up your pricesettings in any currency. Automatic conversion is done when the given currency is not the same as the “global currency”. The conversion is done by predefined rates. You can set these rates in the “Currency convert” form in the MManage.

5.59. How is VAT handled?

You should try to use prices without VAT included all ower in the system (for pricelist and for simcards)

VAT included pricelists can be easily converted to net values by checking the “Convert to NET value” checkbox in the “Price List”. You should enter the VAT percent in the “VAT Value” editbox for proper calculations.

For simcards you can setup the VAT value in the Packet options (“VAT” editbox). If you set the “convertsimcredittonovat” global configuration options to true, than sim credits will be automatically converted to net values. For examlpe after an automatic credit request, the credit value in the received messages (SMS) will be automatically conveted to net values.

You should set up the appropiate VAT values for users too, wich will be taken in consideration during the billing process.

5.60. How the check your ASR (or ACD, SL, CDRC) 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)

5.61. How to add endusers (basic settings)

1. Go to MManage -> Users and device form, and select enduser type

1. Select an already existing user wich has the same caracteristics as the required new endusers

2. Hit “New User” and than accept the the copy from existing option (cloning)

3. Check at least the following fields: username, password, parent id, authorizaton type (usually username/password), prepaid/postpaid, billed user

4. Check other settings

5. Save

5.62. Basic callcenter tasks

1. Setup your server as for a normal sofswitch (routes)

2. Create campaigns

3. Add callcenter operators

4. Assign operators to campaigns

5. Add or import clients

6. Assign clients to campaigns

7. Add presentation locations

8. Setup global callcenter configurations

9. Operators now are ready to start there MAgent application

10. Check statistics

11. Print invitations

12. Use checklist when you are on presentations

5.63. SRTP

SRTP media encryption is fully supported by the VoIP server and it can be configured globally or per user/device.

The SRTP module can be enabled/disabled from MManage -> Configuration wizard -> Roles and features page and its default behavior can be set from the Network page.

You can also configure the same with the srtp global config from the Configurations form.

Possible values:

o -2: IGNORE: disable all srtp processing (will ignore all srtp related code).
Will completely disabling the SRTP module.

o -1: AUTO: like 1/FORWARD, but like NO if target is PSTN number.

Default. Will auto guess the best behavior.

o 0: DISABLE: disable SRTP (don't forward SRTP and respond in 200 Ok without srtp in the sdp).
Can be used to remove SRTP without any extra server side processing if the client allows plain RTP answer for SRTP initiated calls.

o 1: FORWARD: forward as-is when possible (try to bypass and failback to local decode if the peer doesn't accept SRTP).

With this option you can usually avoid SRTP related transcoding.

o 2: PROCESS: if incoming call is with SRTP, then transcode locally and forward as simple RTP. don't forward SRTP for outgoing calls.
You can set to this value to let the server process (decode/encode) the SRTP and always forward unencrypted RTP.

o 3: YES: offer SRTP for outgoing calls (even if incoming was without SRTP). For incoming calls this will act like AUTO.
You can set this value to transcode raw RTP to SRTP.

o 4 FORCE: always offer and reject call if not with srtp.
Same as YES, but will allow only SRTP calls also for inbound.

Default value is -1/AUTO

There are a few extra SRTP related global configurations which you can change from the “Configurations” from by searching for “srtp”. The defaults are optimal.

srtp_auth: -1: yes/default, 0: no, 1+: specific algorithm

def_srtp_alg: defaults to AES_CM_128_HMAC_SHA1_80

The followings are supported: AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, AES_CM_256_HMAC_SHA1_80, AES_CM_256_HMAC_SHA1_32

You can also configure SRTP per user form the Users and devices form -> Functions page -> Media relay section.

This will overwrite the global setting.

(This will set the tb_users.srtp field but the value will be 2 points higher then for the global srtp settings. For example tb_users.srtp 3 means FORWARD)

It is recommended to use TLS transport for the signaling if you need SRTP encryption for the media.

Note:

o Depending on the circumstances (routertp and whether any local RTP processing is required), the server might just bypass the SRTP stream (P2P media between the peers), it might forward the SRTP stream but doesn’t encode/decode or it might forward with local encoding/decoding. If local processing is required, can be specified with the rtpmightlocalprocess global config. Default is -1 (auto), 0 means never (usually meaningless), 1 means always (which means that the SRTP streams will be always decoded and then re-encoded if required)

o If the target party rejects the call due to SRTP or missing SRTP (for example with SIP/2.0 488 Not Acceptable Here), then by default the server can retry the call with SRTP transcoding (with or without SRTP).
This behavior can be disabled/enabled/forced with the autosrtp global setting:

§ 0: disable. never auto failback to SRTP transcode

§ 1: enable with auto guess (default value)

§ 2: force. always auto failback to SRTP transcode (with the risk that codec transcoding would be needed instead)

5.64. Codecs

The sofswitch can route any audio, video and fax codecs.

If the audio stream needs to be manipulated (conference, call recording), the following codec’s are supported:

G.711, OPUS, G.729, G.723, GSM, iLBC, Speex, G.722

(Voice recording, “voice here” and conferencing feature will work only with these codecs.)

5.65. How to reserve GSM capacity for a certain protocoll

In the global configuration you have to set the following keys:

reserveforh323: number of channels to be reserved for traffic received from H323;

reserveforsip: number of channels to be reserved for traffic received from SIP.

On packet and gateway level you can specify the maximum number of reserver channels from that packet by setting the “maxalloc” field (defaults to 0!).

When set properly, the server will reallocate the requested best quality channels for the requested direction in every hour.

To manually reserve capacity for sip set the reserverfor field in tb_sims to 1 on the required channels.

5.66. PDF creation in MManage

In order to use “PDFCreator” to save the invoice in PDF, some modifications are needed to the program

1. Make sure that the default PDF printer is set to “PDFCreator”

(MManage -> Menu -> Settings -> Options -> Default PDF Printer option)

2. Open the printer “Options” Form

This can be achieved

-when you save invoices as PDF first time

-from Start Menu -> Programs -> PDF Creator -> PDF Creator -> Printer Menu -> Options

3. Setup Auto-Save

Select the Programs->AutoSave form

-check the “Use Auto-save” checkbox

-In the filename template type: <Title>

-Check the “Use this directory for auto-save” checkbox, and select the folder where the invoices will be saved

>Now your invoices will be saved automatically in the selected folder when you select PDF as output.

If PDF creation doesn’t work:

1. check if the “Print Spooler” service is running (set it to start automatically in StartMenu->Settings->ControlPanel->Administrative Tools->Services)

2. reinstall “PDFCreator” by starting the “PDFCreator.exe” from your MManage directory

If you cannot use the “PDFCreator” program, you can change the PDF creator tool in MManage -> Menu -> Settings -> Options -> Default PDF Printer option

5.67. How to setup a new virtual server instance

1. create a new directory named “virtserverX”

2. copy all files from an old virtserver directory (except the logfiles)

3. rename virtserverOLD.exe to virtserverNEW.exe

4. register the new virtserverX.exe as a system service

5. rewrite the start.bat and stop.bat

6. allow the new service (and other executables if any) in the OS firewall

7. create a new ftp directory for the recorded voices files under the “voice” directory and set the correct rights

8. set the database connection settings in the inifile

9. clone an old database instance

10. clean old database tables (MManage ->Advanced->Clean Database Tables)

11. setup default tables (MManage ->Advanced->Setup Default Virtserver Database)

12. upgrade to the newest version (MManage ->Advanced->CC SW Version Migration)

13. setup configuration (MManage ->Settings-> Quick Setup)

14. check port collisions (rewrite portnumbers)

15. configure routing in the mainserver (in and out). Add the virtserver user as traffic sender and sipproxy

16. allocate numbers in the mainserver for the new virtserver instance (callback numbers)

17. start the new virtual server

18. make a testcall

19. check the logfile for errors. test MAgent. check MManage

5.68. Fax detection

Usually you can filter out fax calls by setting the “block711” global setting.

5.68. Handling dynamic & private ip/port

For sip proxyes, endusers and gsm gateways the server will handle ip and port changes automatically. For sip proxyes and endusers the ip/port/transip/transport settings will be changed dynamically only if the “Can Dial” option is enabled for the device.

5.69. Fax settings

faxhost: email-fax gateway domain name or ip

faxuser: smtp username

faxsubject: email subject

faxfromaddr: from field

faxfromname: from name field

faxnormalize:

0 = leave original number

1=normalize

2=normalize, no iec

3=normalize, with iec

faxsuffix: append after faxnumber (usually @host.domain)

5.70. License limitations

You can configure the limits in the “licensecfg” global config section, but the configured values cannot exceed the builtin hardlimits. Most of builtin hardlimits are listed in the “license” section or you can check them in MManage->help->licensing menu. The -1 value means “no limit”.

When the software has no builtin and configured limits, than only the hardware can restrict its performance and throughput.

The following hard limits are built in the software:

MAXALLUSERS: to restrict the total number of users and devices (including endusers,gateways, etc)

Devices behind this limit will be disabled (calls blocked)

MAXSIPUSERS: to restrict the total number of sip endusers.

Users behind this limit will be disabled (calls blocked)

MAXGATEWAYS: to restrict the total number of sip, h323 and gsm gateways, gatekeepers and proxies.

Gateways behind this limit will be disabled (calls blocked)

MAXTRAFFICSENDERS: to restrict the total number of sip traffic senders

Traffic senders behind this limit will be disabled (calls blocked)

MAXCHANNELS: to restrict the total number of gsm channels (active simcards)

Server will not accept more simcards to be active, thus no calls will be routed to them.

MAXCCALS: to log exceeding traffic. When the number of the simultaneous call count exceed this limit, a log entry will be written with the following text: “WARNING, max concurrent calls reached (license) [num of calls]”.

MAXCALLSBLOCK : call behind this limit will be dropped with “Max concurrent calls reached” reason code.

MAXCCALSPERMIN: max number of call setup/minute.

MAXSL: max speachlength/day in minutes. All calls will be dropped after this limit is reached.

MAXSESSIONSPEECHLEN: max speech length for all calls in miliseconds.

MAXREGISTRATIONS: max number of registered users (by the nature of sip registration process, this limit can’t be 100% precise)

MAXTAGENTS: max number of maximum MAgent application registrations. There is no way to control wich of the MAgent application will be blocked. (The registration request will be refused when there are more TAgents online than this limit, where “online” means at least registered status in the last 15 minutes)

The following modules can be added/removed:

Ø callcenterout

Ø callcenterin

Ø extra

Ø filtering

Ø failover

Ø alerting

Ø recharge

Ø gsmextra

Ø sip

Ø h323

Ø simplatform

Ø simbank

To check for more limitations, search the config with the “license” and “max” keyword.

5.71. Redirect or forward sessions to other domains

Routing to other domain can be restricted by the “fwdtootherdomains” global config setting. This means SIP calls with other domains in the request uri (not listed in the “domainnames” values, and no IP address match)

The following values are defined:

0=don’t forward calls to other domains

1=check if our numbers first (local user)

2=don’t forward mobile numbers

3=forward all required sessions

4=forward all required with “Moved Temporarily”

5=unconditional move (will move all required traffic without checking the caller)

You can forward calls to other domains before any routing configuration will be checked. (with 302 Moved Temporarily)

The following config values will be applied:

Forwardpx: comma separated prefixes to be forwarded. ‘*’ means all traffic (can be used for failovering and load balancing). Set to emty to disable forwarding.

Forwardto: IP address or domain name where these prefixes will be forwarded.

This feature is usually not enabled for service providers ( if you provide services for costs), and usually is enabled for home or company users.

5.72. Delete old database backup

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 doesn’t have cleanup feature.

5.73. Sales commissions

The sales cost will be calculated to the CDR record “costsales” field. So you can build any statistics based on this value.

Every user can have the “Added By” field filled, wich will point to the sales person where the user belongs.

You can define the sales commission explicitly in the “Price setup” form (Type must be set to “Sales cost”)

If no such price is defined, than the sales commission will be loaded from the actual sales user setting.

The defined commission percent will be calculated for the profit or for the enduserprice. This behavior can be set by the “salescomissionfromprofit” global config.

Sales can give up for the users some reduction wich will be substracted from their cost. This can be configured with the “reduction” value for the individual endusers.

5.74. Multihomed setup

UDP ports must be binded to different ip interface (at least the default sip port 5060), or set to different values.

TCP ports must be setup differently

On the gsm gateway set the serverip to the binded ip and the cmdport to the gsmclientport

Change the pipename setting in the gatekeeper.ini

5.75. How to scan your SP for live numbers

The scanner thread can be used to initiate phone calls to a range of phone numbers and will store the validity status of these number in CDR records.

Phone numbers can be specified by a range (scan_from, scan_untill) or loaded from a text file (scan_filepath).

The speed of the thread can be controlled by the following options: scan_callival, scan_callsperminute, scan_maxcalls (you might specify all these 3 constrains for a better control).

If there is no error in the configuration, the scanner thread will start immediately withing 2 minutes after service startup.

Otherwise the scanner can be started/stopped with the “checkscanner” console command (will start if the parameters are ok and scan_enable

At the end of the scan, you can query the results from tb_cdrs.

The following global config values must be set accordingly:

scan_enable –set to 0 to disable scanning or 1 to enable (The scanner thread will start automatically if this is set to 1 and will stop automatically on 0 value)

scan_from –range start

scan_untill –range end

scan_filepath -to load the numbers from file (scan_from and scan_untill will not be used in this case)

scan_callernum –a valid username (phone number) from “users and devices”. Proper routing must be set for this caller. (A number)

scan_callival –new call attempt interval in msec. (delay between 2 calls)

scan_callsperminute –max calls/minute to initiate

scan_maxcalls –max simoultan calls

scan_stop_at –at what stage the call setup progress will stop.

0=trying,1=progress (default),2=ringing,3=connect

*all global config can be listed if you filter for the “scan” word”

The results can be seen in the marker field of the cdr records:

SU1=unknown

SS1=trying (scan success 1: the last status was: trying) -2

SS2=progress (scan success 2: the last status was: progress) -3

SS3=ringing (scan success 3: the last status was: ringing) -4

SS4=connect (scan success 4: the last status was: connect) -5

SF1=disc code (scan failed 1: the last status was: disc code received) -6

SF2=bye (scan failed 2: the last status was: bye received) -7

For example the following query will list all live numbers when the scan_stop_at is set to 1:

select callednumber from tb_cdrs with(nolock) where datum > X and callerid = Y and marker in ('SS2', 'SS3','SS4')

You might also consider a number to be live on special disconnect reason codes (like user busy)

Disconnect codes are stored in tb_reasoncodes (there are mappings to SIP codes)

For example the following statement will list all numbers found as valid in the last 7 days including calls with “Busy here” disc reason.

select callednumber from tb_cdrs with(nolock) where datum > GETDATE() - 7 and (marker in ('SS2', 'SS3','SS4') or (marker = 'SF1' and discreason in (4486)))

5.76. Routing calls from virtual servers

The actual virtsever must be configured as a traffic-sender in the mainserver.

In the virtserver, the mainserver must be configured as a sip-proxy.

Setup the routing in the virtual server and in the mainserver too.

5.77. Routing calls to virtual servers

From the mainserver there are two possibilities:

-set some phone numbers “location” to virtserver id and /or

-setup the routing (for a range of numbers defined by a prefix)

The actual virtsever must be configured as a sip-proxy in the mainserver.

In the virtserver:

-setup the callbacknumber ant it’s routing correctly in global configuration and /or

-assign real phonenumbers for operators (or endusers)

In the virtserver, the mainserver must be configured as a traffic-sender..

5.78. How to add plugins in MManage

Create your custom exe.

In the MizuManage.ini under the “plugins” section add your plugin entry:

nameX=MyPlugin

cmdX=MyPlugin.exe

X is a number starting from 0 to MAXPLUGINCOUNT

The MManage will pass the database access parameters in the command line.

Any other parameter must be readed from the inifile.

Command Line: dbserverip,dbport dbname username password connectionstring

*Please note that appserverip may differ from dbserverip!

Direction parameters will be located under the “parameters” section. Read them as soon as possibile.

The following keys are defined:

Ø fromdate, todate

Ø source, destination

Ø fromtype,fromid, frompacket, fromsimid, fromgroup, fromcamp

Ø totype, toid, topacket, tosimid, togroup

Ø fromname, frompattern

Ø toname, topattern

Ø fromenabled, toenabled

Ø fromidlist; toidlist

Ø fromsimidstr; tosimidstr

Ø fromip, toip

Ø fromsimgrouplist, fromusergrouplist

Ø tosimgrouplist, tousergrouplist

Ø reloadgroups reloadgroups

5.79. Request/response target address

Because the server will try to send the sip messages to all possibile addresses, sometime it will misroute it.

With the denyaddr setting you can restrict the address posibilities. It can be set global or user level.

The following values are defined:

Ø NULL //will load the default denysetting

Ø * //allow all

Ø loopbackip, loopbackaddr //127.0…, 0…

Ø localip, localaddr //locally configured or autodetected ip/port

Ø lanip, lanaddr //192.168, 10.0, etc

Ø privateip, privateaddr //local + lan

Ø notfromip, notfromaddr //the address from where messages are received

Ø notsigip, notsigaddr //the address sent in sip signaling

Ø specificip, specificaddr //any ip or ip:port

Examples:

to restrict the target address for a sipuser you don’t allow local and lan ip: privateip

to restrict the target address for a virtserver you don’t allow: localaddr

to restrict a misconfigured proxy wich is always telling you 11.12.13.14: privateip, 11.12.13.14

on a virtserver you must deny only the localaddr for the mainserver (wich is configured usually as a sipproxy) and for the operators you can deny privateip

5.80. Extra charges

To increase the call durations (and the price) for the CDR records, set the “incduration” global config option to true and then set the “incduration” field for the users to one of the following values:

0 = no increase

1 = small inc ~ 1%

2 - normal inc ~ 2%

3=bigger inc ~ 3%

4=very big inc ~ 4%

5=very big inc ~ 5%

6=abnormal :)

above 6: means a fix percent increase

You might also set the “incdurationmode” global config option to 1 if you wish the increases to be applied only for endusers and not the resellers.

5.81. Automatic prepaid credit expirity

You can set prepaid credit by the “Add with elapse” button to elapse automatically.

The following configurations are defined:

Creditunit: How much credit means 1 day

Maxcreditelapsedays: max number of days when the credit will elapse
Accelapsedays: the number of days from creditelapsedt when the account will expire

Tb_users. Creditelapsedt: date-time when the credit will be expired

Tb_users.Accelapsedt: date-time when the account will be expired

5.82. Simple prefix rewrite

To rewrite prefixes on router number normalization, you have to set the following global config values:

prefixrewritestr: the original prefix

prefixrewritefrom: keep from

prefixrewriteto: inserted string

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

prefixrewritestr: 08X…

prefixrewritefrom: 9

prefixrewriteto: 36

5.83. Short number and internal billing

You can set the short number billing mode by the “shortnumbill_type” config value. When set to 0, all short numbers are billed with the price set in “internal_providercost” and “internal_endusercost”. When set to 1 (default),, then the “999” prefix is inserted before the called numbers, and you have to create billing entries for these numbers.

Numbers are treated as “short” if its length doesn’t exceed the value set by the “billshortnumlength” global config option.

Calls between endusers are billed with the “internal_providercost” and “internal_endusercost” values (defaults to 0).

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

Cropping sound on ring when playing voice (ringtone, announcement or any other prompt)

Set the stopplayeronrtprec global config value.

5.85. How to play user credit in IVR

Create a “Play number” action.

Enter [credit] for the file name.

5.86. Mizu Server security

Moved to “Security and account limiting” section

5.87. Ringtone for IVR forwarded calls

Can be controlled by the playivrfwdringtone global configuration

We have 4 options here:

0=no ringtone from the server (instead we can play any file directly from IVR). In this case if there is no other IVR file playback in progress, the client can hear the ringtone generated by the called endpoint

1=generate ringtone on ring received if there are no other IVR playback in progress (in this case the client will hear ringtone even if the called endpoint is not generated –i.e. it just sends ringing message in signaling). This is the default setting.

2= generate ringtone on ring received even if other file playback is in progress (stopping the old playback)

3=generate fake ringtone immediately after call was sent to routing

5.88. How to enable codec transcoding

By default the server will try to auto-negotiate the “best” possible common codec between peers and it can automatically failback to transcoding if there is no common codec, thus most probably you don’t need to touch the code or transcoding related settings.

In case if you wish to prefer or force some codec for a SIP endpoint, then just set the “Codec” setting from the “Users and devices” form “Functions” tab (this can be set for Enduser, Traffic sender and SIP Server entries). This will set the tb_users.choosecodecs field accordingly.

In case if you wish to force transcoding, then also select the “Transcode” checkbox. This should be done only if you know that the caller and called pary will not have a common codec. This will set the tb_users. needcodecconversion field to 1.

You might also need to adjust the convertcodecs global config after your needs (list all the possible payloads).

More details:

If one of your peers has limited codec capabilities or the accepted codec(s) doesn’t match with the sender codec’s, then set its “needcodecconversion” to 1 (for the target user which is usually a SIP Server user or Enduser)

Set the “convertcodecs” global config value to the target codec payload list. The default value is 0,8,18,3,105 which means PCMU,PCMA,G.729,GSM and OPUS-wideband. The list should include both the caller and called party codec’s.

The server is able to transcode between the following codecs: G.711 A-law , G.711 A-law ,G.729, G.723.1, GSM, Speex 2,3,4,5,6 (narrowband, wideband and ultrawideband), OPUS (narrowband, wideband and ultrawideband), G.726 and G.722. You might also have to set the “choosecodecs” field for the target user (same as the “convertcodecs” global config value) and the “convertcodecsforced” global config option to true.

Be aware that codec transcoding require a high amount of CPU usage. For example one CPU (core) can handle around maximum 10-200 simultaneous transcoding between PCMU and G729 on full load (depending on your CPU type).

5.89. Possible NATs and firewalls

There are several ways UDP might be handled by a specific NAT or firewall implementations, these are categorized into:

Full Cone NAT
A full cone NAT is a solution, where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.

Restricted Cone:
A restricted cone NAT is a solution, where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.

Port Restricted Cone
A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.

Symmetric Nat
A symmetric NAT is a solution, where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.

5.90. How to disable CLI for all outgoing calls

For the sip proxy users(s) in the rewriteanumber put “anonymous”. Make sure you don’t have identity forward and identity rewrite (both of them must be empty)

5.91. How to change the database username/password

The auto installer will use the “sa” username with “srEgtknj34f” password by default.

Install the SQL Server Management Studio if not already installed.

Open “Security” -> “Logins”. From here you can easily add/remove any users or change passwords.

Before changing the default user settings, stop the mserver service (By launching the stop.bat file or from Services).

Change the database settings in the mizuserver.ini configuration file.

Restart the voip service.

5.92. Performance optimizations -fine-tune

The Mizu VoIP server is optimized by default and will also fine-tune itself at runtime.

Do not change these default settings unless you have a solid reason to do so on high traffic servers if you have performance issues.

Use the v_check_blakclist_int sp if there are a lot of blacklisted numbers (global config blacklisttype = 2)

Disable rtp routing whenever possible (set the default to “route rtp if both behind nat”)

Set getpacketloss global config option to 0 (this will enable fix rtp relay)

Disable resellerbilling if possible (Set to 0 if you are not working with resellers)

Set trace level to 1

Switch off dbmaint_mssqldbbackup (set to 0) and set db backup from ms sql studio

Set outboundprefix1, outboundprefix1 and outboundprefix2

Disable early media on client and server side

Disable retrybilling, retrycalldir and retryrouting

Increase media frame/packet

Set uniqueportperuser to 0

Set “allowlastwrongnum” to false

Set “usesockrecmutex” to false

Set “usemencmutex” to false

Set “rtpalwaysroutebyfs” to 2

Set “fs_timer” to 2

Set “dbcache” to 2 if you have enough RAM

Set “checkrtpevents” to false if you don’t need DTMF based conference or transfer

Set lookupcdrcalldirection to false (disable direction name in cdrs)

Increase maxasyncrecthreads (set to number of available cpu)

Set threadsafeoops to 1 (or to 2 if there are stability issues)

Enable/disable useasynctransportthread (global config option for async send, defaults to -1 which depends on cpu count); set the useasynctransportthread global config option to 1 if too high load for the main thread

Use MS-SQL query governor

Turn off disk write-cache buffer caching if you have a separate power supply

Set the usevgetpriceint to true (also requires dbversion 124; with this mode, + and 0 prefixes are not allowed in the billing. Only numbers)
Setup user caching (set “cacheregistrations” to 2)

Set checkfilecontents to false.

Set updateusrcalldate to 0

set #define MAXMSGLEN to 2000

Adjust DEFQUEUELEN

Set REBUILDREGCLIENTS to -1

Remove performance counters, lasttoops

Set offlinechat to 0.

Set checklocalnumbers to 0

Set blacklisttype to 2 if you have a lot’s of blacklisted numbers (convert to tb_blacklist_int)

Set quickanswerforoptionnotify to 2

Set simultancallscreditcut to 0 or 1

Finetune opus settings (lower bandwidth)

Set resolvedns to 1 (for non blocking / only delayed resolve)

Set useencryption to 0 if no mizu encrypted clients are used

Set checkiostcpfastencrypt to 0 if no iOS encryption is used

Turn off cpu affinitiy by settin the followings to 0: cfg_cpuaffinity, autocpuaffinity, autocpuaffinitysubprocess, autocpuaffinitythreead

Set usemencmutex to false (migt result in instability)

Set waitforsqlupdate to 0

Set reusedblockedep to 2

Set validatesipmessages to 0

Set “useasynctransportthread” to 1 (especially if TCP is used)

Optimize the number of threads (“thead”settings)

Increase REGISTERIVAL,upperexpire, userofflinemin, upperexpiremin

Set allowforkforsignaling to 0

Set usertpmutex to false

Set allowlogloss to 2

Increase cfg_sipmsgresendival

Turn off creditcheckforpostp

Turn off allowforkforsignaling

Turn off creditcheckforts

Turn off lookupcdrcalldirection

Turn off brs if not needed. (“lcr_brs”)

Turn off the dynamic firewall.

Turn off client credit (balance) notifications (set sendusercredit to 0)

Turn off rtp mutex (set “usertpmutex” to false)

Disable RTCP (set enablertcp to 0)
Remove rules if not needed (checkprefixroules)

Turn off checkdbconf or set to 1 if db interface needed.
Turn off checkepvalidity (Set to 0)

Turn off storecdrcomments

Turn of A number authentication if not needed (anumberhandling=0)

Turn on quickrtp

Turn off forking (media and signaling also)

Turn off rerouting

Set fastackforcalls to true

Turn off input validation (validateinput)

Turn off A number lookup for users when not needed

Increase the maxregelivetime on high CPU load

Decrease the maxregelivetime on high memory usage

Increase or turn off keep alive message interval

Use only UDP transport

Set “alwayssethttpanswerport” to false

Set “maxhttpbuffering” to 0

Set “checkwithzerocredit” to 0

Set cdrextra to 0 and remove the following fields from cdrs: billingstep,unitprice,billingentry,origduration,costenduseru
System: SQL optimizations (tuning wizard) and profiling according to your workload.

From v_getroutingtime remove @called_norm2 LIKE tb_routing.calledprefix +'%' and use fixed length matches only

Don't use LCR

Check your network card settings:

-disable flow control

-enable interrupt moderation

-enable IP/UDP checksum calculation offload if you have a performant network card / less CPU inverse or disable if your CPU is high-end bug the network card is moderate only (some network cards might not be able to keep up with the checksum calculation workload)

Run SQL profiler to find out low performing queries

Adjust MAXDOP option (to prevent one query stealing all your cpu time)

Disable all software firewalls (disable the windows built-in firewall). Firewalls has a big impact on UDP traffic.

Set ipdontfragment to 1 (test if peers can still receive large udp packets such as SIP INVITE)

Add the app folder to your virus scanner (defender) exception list

-Some other OS optimisations:

- Disable QoS Packet Scheduler

- Disable TCP/IP v6

- Disable Indexing

- Set screen saver to none

- Sound Off and Sound scheme to No Sounds

- Adjust Visual Effects to best performance

- Clear C:\Users\Administrator\AppData\Local\Temp folder

- Go to the cmd prompt and type powercfg.exe -h off to disable hibernation. (This also deletes the hiberfile.sys from c:\)

- Power Options (from Control Panel) Change option to High Performance (http://support.microsoft.com/kb/2207548)

- Configure SNMP

- Defragment the C drive

-RTP routing offload

-From server management install the “Network Policy and Access Service” Role, “Routing” feature

-From “Routing and remote access” right click on the server node and select “Configure and enable Routing”

-Select the “Custom” option and then select “NAT”

-Rigth click on the “NAT” node and from “New Interface” select your network card connected to the public network/internet

-Select “Public” interface and select “Enable NAT on this interface” then click OK to save

-for the mserver global config, set the followings:

-rtpoffload = 1

-for the “rtpoffloadapter” enter the name of your network adapter. (default is: “Local Area Connection”)

-Increase page file maximum size to allow more virtual memory (If auto managed then Windows might limit it to 4 GB)

-System/MS SQL optimisations

-Set forced parametrization: ALTER DATABASE mserver SET PARAMETERIZATION FORCED

-optimize indexes and fillfactor: https://www.brentozar.com/archive/2013/04/five-things-about-fillfactor/

-set the v_selpattern to return only top 10

-remove unneeded called prefix length checks from v_getroutingtime (PATINDEX ('%,'+substring(@called_norm2,1,1)+',%', ','+tb_routing.calledprefix+',') >0)

-increase the recovery interval (to 5 or 10 depending on your needs)

-optimize for ad hoc workloads:

sp_configure 'show advanced options',1

reconfigure

sp_configure 'optimize for ad hoc workloads',1

reconfigure

-create 8 tempdb with equal size

-add TOP X for v_getroutingtime (1 is enough if you are not using failovering between patters. Otherwise set to a reasonable value)

-review the following settings

SetCfgStr("supervisor","canrestartformalfunctions","1");

SetCfgStr("settings","mincdrcount20min","1");

SetCfgStr("settings","maxmemoryutilization","800000");

SetCfgStr("settings","minmemoryutilization","280000");

SetCfgStr("settings","maxgkmemoryutilization","90000");

SetCfgStr("settings","priorityboost","false");

SetCfgStr("settings","wrongnumcache","100");

SetCfgStr("SIPSettings","MAXSUBSMSGCOUNT","35000");

SetCfgStr("SIPSettings","MAXWRONGMSGALLOWED","4000");

SetCfgStr("SIPSettings","MAXWRONGAUTHFROMIP","3000");

SetCfgStr("SIPSettings","MAXFAILEDAUTHENABLEDIPPORT","170");

SetCfgStr("supervisor","maxnocdrmin","6000");

SetCfgStr("supervisor","maxnologival","20");

SetCfgStr("SIPSettings","MAXH323GKCDRCACHE","400");

SetCfgStr("CallCenter","maxcallatonce","1000");

SetCfgStr("CallCenter","maxcallsperminute","5000");

SetCfgStr("CallCenter","predectivemaxsucccalls","500");

SetCfgStr("CallCenter","stopwrongcdrc","400");

SetCfgStr("settings","allowlastwrongnum","true");

SetCfgStr("settings","maxroutereqpermin","5000");

SetCfgStr("settings","MAXEPCOUNTTRESHOLD","1000");

SetCfgStr("settings","checkmaxcalls","500");

SetCfgStr("settings","maxauththreads","9");

SetCfgStr("settings","maxivrthreads","9");

SetCfgStr("settings","maxasyncqueryhreads","9");

SetCfgStr("settings","maxroutingthreads","9");

-enable Disk Write Caching (only on stable servers with backups)

-use SSD and as many RAM as possible

-If you are using SQL Server Enterprise and high disk usage and low CPU usage: Use Compression

-put the main database, tempdb and logs to deparate disks

-put the tempdb to a ramdisk if you have plently of RAM

-use in-memory tables

-increase the 'min memory per query' option if your server has a lot of memory available

-set the 'priority boost' SQL Server options to 1 of you have a dedicated sql server

-split the database to multiple files

-on servers hosting MSSQL, format disk with NTFS 64K allocation unit size

-fine tune MSSQL based on your hardware/configuration/requirements:

USE mserver;

EXEC

sp_configure 'cost threshold for parallelism', 30; //set to 20-90 (50)

sp_configure 'max degree of parallelism', 4; //set to number of processors / 4

sp_configure 'blocked process threshold', 60 ;

sp_configure 'optimize for ad hoc workloads',1 //might degrade the performance!

sp_configure 'query wait', 60;

sp_configure 'max server memory', 4096; //MB auto set Max Server Memory to 90% of the system (leave at least 10% or 2 GB for the OS)

sp_configure 'backup compression default', 1;

RECONFIGURE WITH OVERRIDE ;

SELECT name, value, value_in_use, [description] FROM sys.configurations ORDER BY name;

You can set the 'priority boost' SQL Server options to 1. ...if server is dedicated for mssql

Set OS power management to "High performance"

In case if you are hosting multiple services on your server, you might need to increase the heap size.

Set HKLM\System\CurrentControlSet\Services\AFD\Parameters\FastSendDatagramThreshold value to 1450 (decimal)

Increase HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters\IRPStackSize

netsh int ipv4 set dynamicport tcp start=40000 num=64000

netsh int tcp set global dca=enabled

netsh int tcp set global netdma=enabled

Set the power plan to “High performance”

check perfmon /report

https://msdn.microsoft.com/en-us/library/windows/hardware/dn529133(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/cc558565%28v=bts.10%29.aspx

https://kbsupport.blogspot.ro/2012/10/registry-settings-to-improve-network.html

http://blogs.technet.com/b/vipulshah/archive/2006/11/30/understanding-perfmon-counters-while-troubleshooting-sql-server-performance-issues.aspx

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

http://technet.microsoft.com/en-us/library/cc966401.aspx

http://technet.microsoft.com/en-us/library/cc966420.aspx

http://msdn.microsoft.com/en-us/library/cc558565%28v=bts.10%29.aspx

SELECT * FROM sys.dm_os_performance_counters

https://forums.spybot.info/showthread.php?4723-Solve-Security-Issues-in-Windows-XP

Increase softswitch stability (and decrease performance) with these settings:

usemencmutex=true

usertpmutex=true

usesockrecmutex=true

threadsafeoops=2

other threading and mutex related

checkepvalidity = 3

recompile with the following settings for TSQueue:

#define KQUEUE_EXTRAMUTEX

#define KQUEUE_USECONDITIONVARIABLE 2

#define KQUEUE_USEWAITONADDRESS

also check the performance related settings above

NIC performance:

https://blog.serverfault.com/2011/03/23/performance-tuning-intel-nics/

https://docs.microsoft.com/en-us/biztalk/technical-guides/general-guidelines-for-improving-network-performance

https://docs.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-tuning-nics

https://helpdesk.flexradio.com/hc/en-us/articles/202118518-Optimizing-Ethernet-Adapter-Settings-for-Maximum-Performance

https://www.tradingtechnologies.com/xtrader-help/tt-system-requirements/appendix-setting-descriptions/nic-settings/

If you are using VMWare, increase the interrupt rate as described here: https://kb.vmware.com/s/article/2040065

5.93. How to reset a failovered gateway/direction

-set tb_users.nopriority to any date-time in the past

-open failoweing and reset the failovered gateways

-check if all gateways have provider pricing

5.94. How to remove the 3 digit techprefix system wide setting

This might be required for old server versions (before 2009) to convert to the latest database format:

Run the following queries and reload the server config.

update tb_cdrs set callednumber = substring(callednumber,4,99) where calledid > 0 and LEN(callednumber) > 3

insert into tb_settings (location,filename,inisection,keystr,valstr) values ('global','vserver','settings','dbformat','86174')

insert into tb_settings (location,filename,inisection,keystr,valstr) values ('global','vserver','settings','usetechprefix','false')

update tb_settings set valstr = 'false' where keystr = 'usetechprefix' and inisection = 'settings'

update tb_users set ccenddate = getdate()+9999

update tb_users set ccstartdate = getdate()+2 where ccstartdate > getdate()

To enable variable length techprefix for the authentication, do the followings:

-set the “techprefixlenauth” global config option to -1

-upgrade to the latest v_checkuser stored procedure

5.95. How to enable H.323 modules?

H.323 is usable if your license contains these modules and you have installed the H.323 modules during the initial setup.

Open the global configuration form.

Search for h323

Set the followings to true:

-CAN_hash323

-CAN_runsipproxy

Enable the sip2h323caller and sip2h323 users.

Restart the VoIP service.

5.96. How to add SMS provider(s)?

Content moved to SMS chapter.

5.97. Working with groups using direct SQL

Open “Direcy Query” from MizuManage or MS SQL Management Studio.

--check related tables

select top 1000 * from tb_groups

select top 1000 * from tb_grouptypes

select top 1000 * from tb_groupentries

select * from tb_groups, tb_groupentries, tb_grouptypes

where tb_groupentries.groupid = tb_groups.id and tb_groupentries.entrytype = tb_grouptypes.dirid

--create a new group

insert into tb_groups (name) values ('testgroup')

--add 1 user to the new group (by id)

insert into tb_groupentries (groupid,entrytype,entryid) values

(

(select id from tb_groups where name = 'testgroup'), --group id instered previously

1, --entry type. 1 means "endusers" (values from tb_grouptypes.dirid)

100207 --id from tb_users

)

--add all users to this group which username contains "111"

insert into tb_groupentries (groupid,entrytype,entryid)

select

(select id from tb_groups where name = 'testgroup'),

from tb_users

where username like '%111%'

--select users from this group

select tb_users.id, tb_users.Username, tb_users.name

from tb_groupentries, tb_users

where

tb_groupentries.groupid = (select id from tb_groups where name = 'testgroup') and

tb_users.id = tb_groupentries.entryid

--delete group

delete from tb_groupentries where groupid = (select id from tb_groups where name = 'testgroup')

delete from tb_groups where name = 'testgroup'

5.98. Compatibility issues

In case if you have SIP signaling compatibility issues with old devices you might change these global config options:

addnewlineaftermsg = 2

rtpwritefirst = 0

allowheaders = 0

5.99. CLI settings / A and B numbers / Dial plan

There are multiple ways to apply your rules.

The server will “normalize” the numbers automatically based on rules from the global configuration (search for normalize). For example it can remove strange digits, IEC codes like 00 or +, enforce length, etc.

Also there are built-in rules for several countries, so users can dial without CC/IEC/NEC.

For outgoing calls if you need to use a tech prefix, you just have to enter the corresponding digits as tech prefix for the sip proxy user.