Contents. 2
1. Introduction. 8
1.2. Features. 9
1.3. Contact and tech support 21
2. Modules. 21
3. Tutorial 24
4. Administration. 25
4.1. MManage. 25
4.1.1. Overview.. 25
4.1.2. MManage Installation. 25
4.1.3. MManage Framework. 26
4.1.4. Import-Export Wizard. 28
4.2. Monitoring. 29
4.2.1. Current Calls. 29
4.2.3. Basic Statistics. 30
4.2.4. Advanced Statistics. 31
4.2.5. Disc. Reasons. 34
4.2.6. Line Monitor 35
4.2.7. Capacity Check. 35
4.2.8. System Load. 35
4.2.9. Server Console. 35
4.2.10. Server Monitor 36
4.2.11. Logs. 36
4.1.12. Analyze. 37
4.1.13. CDR.. 37
4.3.14. Balance. 40
4.3.15. Callcenter Statistics. 40
4.3. Access. 42
4.3.1. Users. 42
4.3.2. Devices. 53
4.3.3. Groups. 54
4.3.4. Ownership. 54
4.3.5. User authorization. 54
4.3.6. DID numbers. 58
4.4. Routing. 63
4.4.1. Dial patterns. 63
4.4.2. Firewall 63
4.4.3. Normalize numbers. 64
4.4.4. Caller ID Settings. 68
4.4.5. Rules. 72
4.4.6. Prefix rules. 73
4.4.7. Dial Plans. 73
4.4.8. Blacklisting. 76
4.4.9. Access Lists. 76
4.4.10. Routing. 79
4.4.11. Routing workflow.. 81
4.4.12. RADIUS. 84
4.4.13. BRS. 84
4.4.14. Failovering. 86
4.4.15. Channel reservation. 88
4.4.16. Number portability. 89
4.4.17. ENUM... 90
4.5. Billing. 91
4.5.1. Price Settings. 91
4.5.2. Price List 95
4.5.3. Billing. 95
4.5.4. Currency Conversion. 97
4.5.5. Finances. 98
4.5.6. Pin codes. 98
4.5.7. The billing process. 99
4.5.8. Invoice and payment storage. 100
4.5.9. Environment variables. 102
4.5.10. Payments. 102
4.5.11. Resellers. 105
4.5.12. Promotions. 105
4.5.13. Fraud protection. 106
4.5.14. Notes. 107
4.6. WebRTC.. 107
4.7. Push notifications. 108
4.8. Other –MManage. 108
4.8.1. Configurations. 108
4.8.2. Direct Query. 122
4.8.3. Voice Here. 122
4.8.4. Test Call 123
4.8.5. Rfile system.. 123
4.8.6. Rdesktop. 123
4.8.7. DB Admin. 123
4.8.8. Web Admin. 123
4.8.9. Phone Numbers. 123
4.8.10. To-do. 123
4.8.11. Notes. 123
4.8.12. Holidays. 123
4.8.13. Allocating numbers. 124
4.8.14. Scheduled tasks. 124
4.9. Call Center 125
4.9.1. Users. 125
4.9.2. Campaigns. 126
4.9.3. Scripts. 126
4.9.4. GUI Designer 130
4.9.5. Quotas. 131
4.9.6. Presentations. 132
4.9.7. Checklist 132
4.9.8. Clients. 132
4.9.9. Campaign Clients. 133
4.9.10. Campaign and global settings. 134
4.9.11. Predictive dialer 136
4.9.12. Outgoing callback. 137
4.9.13. Incoming calls. 138
4.9.14. Keywords. 140
4.10. MAgent 142
4.10.1. Login. 143
4.10.2. Manual Call 144
4.10.3. Calls from database. 145
4.10.4. Automatic calls. 145
4.10.5. Automatic software upgrades. 145
4.11. PBX / IPCentrex functionality. 145
4.11.1. Call Rerouting. 146
4.11.2. Ring Groups and Call Fork. 146
4.11.3. Caller ID.. 146
4.11.4. DTMF. 147
4.11.5. Call Hold. 148
4.11.6. Call Forward. 148
4.11.7. Call Transfer 148
4.11.8. Three-Way Calling. 151
4.11.9. Call Waiting and queuing. 151
4.11.10. Call Take-Over 151
4.11.11. Conference Calls. 151
4.11.12. Voice Mail 151
4.11.13. Voice Recording. 153
4.11.14. Chat Recording. 154
4.11.15. IVR.. 154
4.11.16. Callback number 156
4.11.17. Callback services. 156
4.11.18. Calling Card services. 158
4.11.19. Phone to Phone (P2P) calls. 159
4.11.20. Virtual Servers. 160
4.11.21. DID.. 160
4.11.23. Barge-In. 160
4.11.24. Unified communication. 160
4.11.25. Other features. 161
4.12. Additional modules. 161
4.12.1. Calling-Card. 161
4.12.2. SMS. 161
4.12.3. SMS callback. 168
4.12.4. Web portal 170
4.12.5. Resellers. 172
4.12.6. Call-shops. 174
4.12.7. Softphone. 175
4.12.8. Webphone. 175
4.12.9. GSM/SIM Platform.. 175
4.12.10. GSM Gateways. 187
4.12.11. H.323. 198
4.12.12. Encryption and tunneling. 199
4.12.13. SBC.. 204
4.13. Security and account limiting. 205
4.13.1. OS security. 205
4.13.2. DB security. 205
4.13.3. Socket/stream level network
protection. 206
4.13.4. Address level network attack
preventions. 206
4.13.5. Session level protection. 206
4.13.6. Web security. 207
4.13.7. API access security. 207
4.13.8. Payment security. 207
4.13.9. Encrypted VoIP. 207
4.13.10. SSL/TLS/WSS/HTTPS setup. 207
4.13.11. User authentication. 209
4.13.12. Per IP call limits. 210
4.13.13. IP Spoofing. 210
4.13.14. Firewall 210
4.13.15. Maximum simultaneous call
limits. 210
4.13.16. Prepaid account credit
limits. 210
4.13.17. Postpaid account monthly
spend limits. 211
4.13.18. Fix daily credit limits. 211
4.13.19. Dynamic credit/spent limits. 211
4.13.20. Daily/monthly call duration
limits. 212
4.13.21. Fraud calls. 213
4.13.22. Blacklists. 213
4.13.23. Auto ban. 213
4.13.24. Billing and profitability. 213
4.13.25. Security checklist 214
4.14. High availability. 217
4.14.1. Large scale VoIP. 217
4.14.2. HA VoIP service. 217
4.14.3. HA database. 217
4.14.4. Database failover 217
4.15. Maintenance. 218
4.15.1 Server configuration checklist 218
4.15.2 Gateway quick setup. 218
4.15.3 Daily Maintenance. 220
4.15.4 Monthly Maintenance. 220
4.15.5 Server backup, recovery and
maintenance. 220
5. FAQ.. 227
6. Links. 333
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.0
Administrator’s Guide
Revisited June 7, 2024
Copyright
Mizu server and other
MizuVoIP software are copyrighted by MizuTech SRL. -Copyright ©2006-2024 MizuTech
SRL.
This document may not be
copied or readdressed in whole or part without the expressed, written consent
from MizuTech SRL.
Disclaimer: MizuTech SRL reserves
the right to change any information found in this document without any written
notice to the user.
License Agreement and Trademark
Acknowledgement
You must accept the license
agreement (LicenseAgreement) before you use any Mizu hardware or software
component!
The softswitch core is
licensed by proprietary Mizutech license: All rights reserved for Mizutech.
Some of the extra modules are
licensed by separate license terms. (These modules are included in unmodified
binary format and integrated with the Softswitch via their API)
LINUX is a registered
trademark of Linus Torvalds in the United States and other countries.
Windows and Microsoft SQL
Server is a trademark of Microsoft Corporation, registered in the United States
and other countries.
Oracle is a registered
trademark of Oracle Corporation.
OpenSSL
is licensed under OpenSSL license: https://www.openssl.org/source/license.txt
Freeswitch
is licensed under the MPL 1.1: https://wiki.freeswitch.org/wiki/Licensing
OpenH323
(used in test tools) are licensed under MPL: http://www.mozilla.org/MPL/MPL-1.0.html. Source code is included on the install CD.
Other logos, products, brand
names and service names contained in this document are the property of their
respective owners (trademarks or registered trademarks of their respective
companies)
Introduction
This document describes the
administration of Mizu Gateways, SoftSwitches and CallCenters. A unique set of
proprietary software and hardware based capabilities and processes to build up
a VoIP network, including planning and network management.
These components are designed
to cover the telecommunication needs for small to very large companies and VoIP
carriers. The main power of the system is the sophisticated VoIP components, which
are strongly used in today’s telecommunication infrastructures.
The
Mizu components can be used as standalone or as centralized intelligent VoIP
platform, capable to handle millions of minutes/month.
1.2. Features
Ø
MS-SQL backend (Express or Full
versions) or embedded database
Ø
Ethernet 10/100/1000 Base-T
Ø
Static IP, PPPoE (DSL or cable
modem), DialUpISDN,VPN
Ø
Encrypted communications
Ø
Virtual servers
Ø
STUN/ICE Support
Ø
NAT Support
Ø
Near-End and Far-End NAT traversal
Ø
Multi-homed and multi-domain
support
Ø
Compliant with SIP rfc's
Ø
UDP, TCP and TLS transports
Ø
Proxy server
Ø
Registrar server
Ø
Location server
Ø
Redirect server
Ø
B2B routing
Ø
PBX features
Ø
Transcoding B2BUA
Ø
Conference Server
Ø
SBC (Session Border Controller)
Ø
Routed and Direct voice
Ø
Automatic NAT detection
Ø
DID Direct Inward Dialing
Ø
Voice Recording and Playback
Ø
Absent Subscriber
Ø
Abbreviated Dialing
Ø
Multiple Subscriber Aliases
Ø
Anonymous Call Rejection
Ø
Access Control Lists
Ø
Call Baring Incoming/Outgoing
Ø
Toll Restriction
Ø
Parallel Hunting
Ø
Click 2 Call
Ø
CLIP/CLIR
Ø
DTMF generation
Ø
Call-Forward on out-of-service
Ø
Codec transcoding
Ø
Advanced statistics support
Ø
NAT traversal of signaling
Ø
NAT traversal of media
Ø
SIP Session timers
Ø
RTP Timers and media timeout
Ø
Blind SIP Registration
Ø
Late Codec Negotiation
Ø
Multiple SIP registrations per
user account
Ø
Can act as an SBC
Ø
Max Session Setting
Ø
Manage Presence
Ø
Detailed call logs
Ø
SIP/SIMPLE
Ø
SIP Reinvites
Ø
SIP-H.323 protocol conversion
Ø
WebRTC-SIP protocol conversion
Ø
Class 4 features
Ø
Class 5 features
Ø
RFC 2543 compatibility
Ø
RFC 3261 compatibility
Ø
RFC 2976 The SIP INFO Method
Ø
RFC 3262 Reliability of
Provisional Responses in Session Initiation
Ø
RFC 2617 HTTP Authentication
Ø
RFC 3263 Locating SIP Servers
Ø
RFC 3265 Specific Event
Notification
Ø
RFC 3420 Internet Media
Type message/sipfrag
Ø
RFC 3515 Refer Method
Ø
RFC 3311 UPDATE Method
Ø
RFC 3581 Symmetric Response
Routing
Ø
RFC 3842 Message Summary and
Message Waiting Indication Event Package
Ø
RFC 3891 "Replaces"
Header
Ø
RFC 3325 Private Extensions to the
Session Initiation
Ø
RFC 2778 A Model for Presence and
Instant Messaging
Ø
RFC 3428 Session Initiation
Protocol (SIP) Extension for Instant Messaging
Ø
RFC 1889 RTP: A Transport for
Real-Time Applications
Ø
RFC 2190 RTP Payload Format for
H.263 Video Streams -only routing
Ø
RFC 2327 SDP: Session Description
Protocol
Ø
RFC 2833 RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals
Ø
RFC 3264 An Offer/Answer Model
with Session Description Protocol
Ø
RFC 3550 RTP: A Transport Protocol
for Real-Time Applications -replaces RFC 1889
Ø
RFC 3555 MIME Type Registration of
RTP Payload Formats
Ø
RFC 3911 The SIP "Join"
Header
Ø
RFC 3324 Network Asserted Identity
Ø
RFC 3326 The Reason Header Field
Ø
RFC 3581 Symmetric Response
Routing
Ø
draft-ietf-mmusic-ice-02 A
Methodology for NAT Traversal for Multimedia Session Establishment Protocols
Ø
draft-ietf-avt-rtp-ilbc-04
Ø
draft-ietf-sipping-cc-transfer
Call Control - Transfer
Ø
draft-ietf-sip-referredby-05
Ø
Custom protocol extensions are
possible
Ø
G.723.1
Ø
G.729
Ø
G.711 A-law
Ø
G.711 u-law
Ø
GSM 06.10
Ø
GSM
Ø
Speex 2,3,4,5,6
(narrowband, wideband and ultra-wideband)
Ø
Opus
Ø
G.726 (16,24,32,40 KHz)
Ø
G.722
Ø
T.38
Ø
DTMF
Ø
Custom 1 kbits codec
Ø
All other codec’s for pass-trough
Ø
Voice:
·
Adaptive de-jitter buffer
·
Voice Activity Detection/Silence
Suppression
·
Recording conversations (In
Stereo caller/callee left/right)
·
QoS
·
Packet saver technology
Ø
Call Forward All/Busy/No Answer
Ø
Caller ID
Ø
RingGrouops
Ø
Call Return
Ø
Call Waiting
Ø
Call Forking
Ø
Call Hold/Retrieve
Ø
Caller ID Block
Ø
Selective Caller ID
Blocking/Unblocking
Ø
Speed Dial
Ø
Direct Inward Dialing (DID)
Ø
Three-Way Calling, Conference
support
Ø
Message Waiting Indicator
Ø
Call transfer, Attended transfer,
Unattended transfer
Ø
IVR (all applications: call,
callback, p2p, forward, etc)
Ø
VoiceMail 2 Email
DTMF transcoding on server side
Ø Interactive Voice Response (IVR) supporting
applications such as credit card and prepaid services
Ø
Video
Ø
Conference calls
Ø
T.38 fax relay
Ø
SMS relay
Ø
SMS commands (callback, P2P)
Ø
Web interface
Ø
Automatic Call Distribution: like
simple automatic dialing, power dialing, predictive dialing, predictive
intelligent dialing
Ø
IVR
Ø
Call Recoding: All calls can be
recorded and stored
Ø
Real time call check out:
Supervisors can listen to the ongoing calls real time
Ø
PBX Features: Call hold, call
wait, call transfer, call forward (conditional and unconditional), call
conference, CLIP, CLIR
Ø
Customizable Scripts: script tree,
with any number of branches, answers, and reason codes.
Ø
Customizable IVR: Any number of
language, any number of branches, voice and faxmail, call transfer to the
operators
Ø
Statistic generation: customer
statistics, operator statistics, call related statistics, work time statistics,
campaign statistics
Ø
Campaign creation: supervisors can
create a campaigns
Ø
Invitation letter: customization,
and automatic printing
Ø
Report generation: Specific
hourly, daily and weekly reports
Ø
ACD Features
Ø
Unlimited accounts / Unlimited
Extensions
Ø
Automatic pincode generation
Ø
Flexibile authentication
(digest,IP,port,user,etc)
Ø
Custom Routing Rules
Ø
Multi-Carrier Support
Ø
ACL
Ø
Sophisticated configurations
Ø
Load Balancing on available
devices
Ø
Rerouting
Ø
Number rewriting (calling and
called)
Ø
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
Ø
Flexible Rate Definition (peak/off-peak/flat/custom,
end-user/provider/reseller/sales, etc)
Ø
Automatic and Real Time billing
(CDRs already includes the prices)
Ø
Prepaid and Postpaid platforms
Ø
Call Credit Limit Control
Ø
Unlimited reseller accounts
Ø
Callshops
Ø
Directions (traffic
sender,prefix,gateway,sim packet) and time based billing.
Ø
Reporting and price comparisons
(LCR)
Ø
Balance and rating with SIP
signaling or HTTP requests
Ø
Invoice generation in different
formats, PDF generation, email scheduler and invoice printing
Ø
Complete call rating &
accounting services for complex rating schemes
Ø
Currency and VAT can be set for
every packet. Time zone can be changed.
Ø
Automatic online currency
conversion
Ø
Paypal and lot’s of other payment
gateways are supported
Ø
Pin Generation Management
Ø
Pin-less Number Registration
Ø
Support for multiple account types
Ø
Management of PINs generation,
activation and deactivation
Ø
Support for unlimited number of
PINs
Ø
Ability to deactivate accounts
after certain period or date
Ø
Import and export of PIN batches
Ø
Management of call limit per PIN
Ø
Routing restrictions
Ø
Max call duration management
Ø
Automatic User Generation
The Mizu VoIP server has full support for WebRTC since
version 7.4 (including websocket SIP signaling and DTLS/SRTP encoding/decoding)
Ø
H.323 Standard Features (v.1,2,3,4)
SIP-H.323 protocol conversion (Signaling and media when needed)
Ø
Full H.323 proxy
Ø
H.225.0 Call Signaling
Ø
Fast Connect/Fast Start
Ø
H.245
Ø
H245 tunneling
Ø
H245 in setup
Ø
DTMF send/receive
Ø
Watchdog
Ø
Direct endpoint call signaling.
Ø
Gatekeeper routed: call signaling
(H.225.0).
Ø
Gatekeeper routed: call signaling
(H.225.0) and control channel (H.245)
Ø
Gatekeeper routed: call signaling
(H.225.0), control channel (H.245) and voice
Ø
RTP Port Range (For firewalls)
Ø
Child Gatekeeper capability
Ø
Backup Gatekeeper capability
Ø
Gatekeeper clustering support
(neighbors, parent/child, alternates)
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
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
Push notification support is
a built-in module enable by default. Configuration and integration is described
here.
Ø
Centralized configuration and management
for all software and hardware components
Ø
MManage:
o
-easy to use, mdi style
o
-almost every data query is
parameterized with traffic direction and time
o
-all data in one place
o
-lots of data can be obtained from
sl,asr,acl forms
o
-global system analysis
Ø
Create and edit network elements
Ø
Remote maintenance of Mizu
gateways
Ø
Display of system information
Ø
Real-time call status view
Ø
Service restart functions
Ø
Display of the current status of
each gateway and channel
Ø
Real time call supervision (with
many grouping options)
Ø
Real time channel supervision
(with many grouping options)
Ø
Statistics (Text based and
graphical ASR,ACD,SL, etc) on any traffic direction and time scale
Ø
Disconnect Reasons (with many
grouping options)
Ø
CDR monitoring, retrieval, direct
CDR access
Operator Console
Ø
Global system analysis!
Ø
Routing pattern selection
Ø
Routing time selection
Ø
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
Ø
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).
Ø
Some class 5 features will work
only with SIP protocol
Ø
H323 GK doesn’t support
username/password authentication (mostly used for call transit and not to
provide enduser services over H323)
Ø
RADIUS is compatible only with
some servers
Ø
Mizutech doesn’t provide support for
client side (softphone) FAX and video debugging. (FAX and video are fully
supported by the server and will work if you are using a softphone conform the
SIP standards, however many software has limited interoperability or bugs)
For a more detailed feature
list see the homepage and
features
pages.
Full remote administration can
be done by mizutech support including continuous email support and 24/7 emergency
phone support.
Contact us or visit http://www.mizu-voip.com
for more details.
Email support: serversupport@mizu-voip.com
Depending on licensing,
some modules may not be available in your release!
The Mizu Soft switch (Server)
is the “brain” of the system. Depending on your needs, you can connect as many
gateways as you want. The soft switch is built from several modules: sip stack,
h323 stack, sip – h323 conversion module, media server, ACL, routing, billing,
alerting. Almost all modules are installed by default and they can be
enabled/disabled as needed. Key modules are listed below:
The Mizu SIP stack was
written in C++. It’s very fast and robust, currently used by voip service
providers and carriers handling millions of minutes.
The WebRTC module will handle
VoIP calls from modern browsers. Includes also a WebRTC – SIP bridge with media
relay support.
Capable to work as a simple
Gateway or as a fully featured Gatekeeper.
Thank to this module, the
protocol conversion is very transparent. You don’t even need to know if your
partners use SIP or H323.
RTPM is used with Flash
clients to convert the signaling and media between Flash and SIP/RTP.
If your server needs to route
the media channels for many concurrent calls, you may need to use a separate
media server, thus offloading the server traffic, and maximizing media
throughput.
With the Mizu softswitch you
can build very sophisticated routing scenarios. The routing is usually based on
traffic direction and time. LCR and BRS routing are available.
The server will generate the
detailed CDR after each call. Thus the billing can work nearly real-time. (Very
important for prepaid systems). You can generate various reports and invoices
based on a set of predefined rules.
The server can send various
reports and alerts based on predefined rules. The reports are sent by email or
SMS.
You can create up to 100
virtual servers on a single pc. These are completely separate
billing/routing/signaling entities.
Manage operators, automatic
call distribution, IVR and other callcenter specific tasks.
This NT service can
automatically detect critical service problems and restart the VoIP server, the
SQL database or the OS.
The built-in HTTP server will
listen for service requests.
A separate module
implementing a few extra pbx features such as voicemail and conference rooms.
Administrative tasks and
class5 service requests can be handled by the command line TCP interface.
Template portal is available
with source code. All common end-user tasks can be done via a user friendly web
interface (new user registration, download CDR records, show statistics, setup
call forwarding, payment, etc)
Various system thresholds
will checked real-time and the server will do the corresponding actions
automatically. The same module is responsible for daily/weekly/monthly email or
SMS reports and alerts for administrators and users.
Mizu VoIP-GSM Gateways
support 8 concurrent calls and up to 64 simcards.
See the features section for more details.
GSM
All standard GSM capabilities
are supported.
VoIP
Mizu VoIP-GSM Gateways can
accept SIP and H323 registrations, can act as a SIP proxy or a H323 Gatekeeper
or Gateway. These functions can be run simultaneously.
SIM Bank
The built-in simbank will
allow to virtually routing the simcards in other Mizu gateways.
Mizu VoIP-GSM Gateways can
take advantage of an external simbank, so you can have all your simcards in one
place, easing the maintenance and administration tasks.
server service: the brain of the system
H323 GK: standard H323 gatekeeper
SIP Server: sip stack
HTTP interface: enduser/reseller website with built-in http server
Media Server: rtp routing
VGW: voip-gsm gateway, the most essential part of the
client
SMS: sending short messages over HTTP API or SMPP
client service: this service supervises the gsm gateway and gives a
clear interface to the server
MManage: smart client software, capable to manage the whole
system
supervisor service: this service supervises the mserver
alerter
service: collects statistical
information and reports it
recplayer:
can play g729, g723, encrypted, raw
PCM and wave files
loganalizer:
log file parser
gwtest: handle gsm
terminal (no h323)
ipmux: packet
saver client and server
serveremulator: server
interface to gk
simalloctest: test the
automatic sim allocation
smtp_test: test smtp
functionality
tariffcalc: estimate
sim packet real price
tcperver: tcp server
for test
udptest: udp
through test
valerterclient: alerter sw
which can be installed on client computers
vchargecards: manage
chargecards
vclientinterface: platform
specific functions for the gw
partnerclient: admin sw.
for our partners
pricesettings: for packet
price configuration
routingandprices: for
config. routes, prices and sim packet priorities
servertest: brute
force test for the server
supervisor: supervises
the server
updater: automatically
updates client software from the server ftp
mediasrv: media
server for routing rtp packets
businesslgc: controls
the routing, registration, endpoint list, endpoint creation, udp initialization
VPC
Simple monitoring software for
business purposes. Each partner (gateway or simcard owners, traffic senders,
etc) can have their own VPC to monitorize their own traffic and create reports.
VPC Setup
You can give the VPC for any
of your partners. The partners can login to the VPC with the username and
password configured in the “Users and Devices” form in MManage. Usually only
“Owner” users will receive VPC access.
You can define what users can
see in their VPC by setting the “Can watch sim packets”, “Can watch users/devices”
and “Access Rights” in the user configuration form (billing tab). See section 4.3.1 for more details.
The VPC included with MManage
has the capability to login as a super user. To do so, you have to enter your
partner username, but use the admin password (from the “ad” account). Then you
have access to the “Add Query” button in the VPC. Here you can add,delete or
modify the existing queries and their access rights.
In the “rights_allow” field
you can put a list of user id, “all” or “nobody” fields. The same for the
“rights_deny”. Thus you can configure which partner can see and execute which
queries.
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
This chapter discusses the administration details of the
VoIP server.
All administration tasks can
be done using the MManage (MizuManage) client application. The main
module is automatically installed with the server installer, but you can also
install it independently to any PC and manage your server remotely. Restricted
administration is available also from the web interface. During this guide you
will meet very often the “global configuration” term. This is referring
for the settings configurable using the “Configurations” form (under the
“Other” item). These settings are system global and are stored in the
tb_settings database table (will be discussed later)
The MManage program 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
-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
Almost
all tasks are done by selecting an item from the left side of the main form.
For detailed descriptions please read below.
In the Menu you can find
common tasks such as “Settings”, “Save As”, etc. The selected action usually
has effect only on the current active form.
From
the File Menu you can save, print or export the selected form.
Usual database operations are performed from the Edit Menu. In
the Favorites Menu you can see the most frequently used items. In
the Config Menu you can find a set of helper applications
explained later in this document.
In the Fields
the most important form is the “Filter” which will filter almost all
listing used in MManage. Here you can define your preference regarding the
traffic direction including Source and Destination. You can filter on Item
Type, Item, Group, Number Prefix, Packet and SIM Card. For example you may
select one SIM ID, and when loading logs, you will see only the messages
related to the selected simcard.
In the left-bottom side of the form, you can find an
edit box used for quick search. You can use the ‘*’ character in the
begin and the end of expressions. (For example when searching for CDR records).
Most
of the report will be filtered after the selected Date Interval also.
In
the Thresholds you can set some thresholds used for MManage. This setting doesn’t
have any effects on the server or gateway. Server and gateway thresholds may be
set up from the Configurations Form explained below. In the Options Windows,
you can set up several important MManage parameters.
In the Help Menu
you have access to documentation.
In the Licensing
box you can see your server parameters (there is no effect if you change these
values, because these are used only for informing you). Depending on
licensing, some modules may not be available in your release! Occasionally
you may need to know the software version you use, which you can find in the About
box.
Example: How the check your ASR for the traffic sender “A” in
the last week.
1. In the date-time drop-down
list, select the “Last Week” field
2. In the “Select Direction”
form set the “Source” (left side) “Type” to traffic sender, and select “A” in
the “Name” drop-down list (or type “A” manually)
3. Launch the “Basic
Statisitcs” form under Monitoring.
4. Clear the “Group by” option
(select the first “-“ line)
5. Make sure the ASR checkbox
is checked
6. Click on (Re)Load
7. Depending on current server
config and current load this query may take some time (on a usual configuration
this will take 2 second)
With the ease of the import
–export wizard, accessible from MManage File menu, you can import and export
data from/to a lots of data formats.
The following file types and
databases are supported:
Access
Excel
DSN
CSV
Text
IBM-DB2
Interbase
MS-SQL
MySQL
Oracle
Paradox
DBF,dBase,FoxPro
Other data sources which
can be accessed by ADO or ODBC.
Currently running calls are
listed here. Calls terminated on Mizu Gateways are displayed in separate list
from other directions. You can filter the listing by selecting your preferences
in the “Set Direction” box (as you can do in many other parts of the program).
The following grouping is
available: by caller, by called, by called prefix, by simowner and by sim
packet.
Field Explanations:
Status: engine or simcard status. Can have the following
values: Gateway Disabled, Off (no info), Not Active, Gateway Disconnected,
Closed, Not Ready, Ready, Dialing, Ringing, Speaking, Call Ending, DTMF,
Simulating Outgoing, Simulated Incoming, Routing to SIMID, Routing to Alias,
Routing
Duration: seconds elapsed from Setup (not from Connect!)
Caller: source name (user name or traffic sender name)
Called: destination name (user name or traffic sender name)
CallerNumber: the phone number of the caller party
CalledNumber: the phone number of the called party
Dialed: number routed to called user or gateway (with
techprefix)
Line: the number of the gsm channel (usually from 0 to 7)
SimPos: the position of the active simslot in the current
engine (usually from 0 to 7)
SIM Owner: the owner of the SIM Card
Packet: the type of the SIM Card
TodaySpeachLength: the number of active minutes on the current simcard
since 00:00
ThisMonthSpeachLength: the number of active minutes on the current simcard
since the first day of the current month
SIM ID: sim identification number
Shows the main traffic amount
and quality parameters of your system.
CDRC: call attempt count
SL: speech length (duration
in minutes)
ASR: average success ratio
(percent)
ACL, ACD: average call
length, average call duration (in second)
You can select any direction
in the “Select Directions” Box, to check only that specific traffic. Also there
are some simple groupings available:
-No grouping: will display
the total sum. Chart views are supported only with this option
-Group by Called Gateway:
list of destination gateway statistics
-Group by Traffic Sender:
list of statistics by source
-Group by SIM Packet:
statistics by SIMCard type
-Group by All caller and
called
-Group by Provider Direction:
statistics by called number prefix (first 4 digits)
This is an extended version
of Basic Statistics. You can find more grouping options here.
In some versions is shown
simply as “Statistics”.
You can make reports based on
the following fields:
-CDRC: number of calls
-SL: speech length (all call
duration)
-ASR: the number of
successfully answered calls divided by the total number of calls attempted
(seizures) Since busy signals and other rejections by the called number count
as call failures, the calculated ASR value can vary depending on user behavior
-ACD: average call duration
-ASRB: average success
ration, but here the “success” means a minimum amount of duration. Configurable
in Settings Menu -> Thresholds Box
-ACT: average connect time.
The time elapsed from setup until the connect in seconds
-SUCC: successful call count
(same as ASR but not in percent)
-CCC: concurrent (simultaneous)
call count
-RTP: media channel
statistics
-EC: end-user costs
-PC: provider costs
-SC: sales costs
-CC: company costs
-EP: estimated enduser
price/minute
-PP: estimated provider
price/minute
-PF: profit value (This
require your billing module to be properly configured including provider
prices)
-PR: profit margin in percent
-PFE: profit from enduser
(useful if you are using reseller or sales accounts)
-PFR: profit from top
reseller (useful if you are using reseller accounts)
-HM: hidden minutes
You can make the grouping by
minute in this form by checking the “on minute” box.
The following “group by”
options are available:
-: display summary data (no
groupby)
Caller and Called: group by
caller and called users
Caller: group by caller
(source) user
Called: group by called
(destination) user
Traffic Sender: group by
caller (source) user, but show only traffic senders
Called Gateway: group by
called (destination) user, but show only gsm gateways
GSM Engine: group by called
gsm channels
Gateway, Packet and SIM Card:
group by called simcard (and show the actual gateway and packet)
SIM Card: group by called
simcard
Caller IP: group by caller ip
address
Week –absolute: group by
week, but with sum (don’t groupby to months)
Day –absolute : group by day,
but with sum (don’t groupby to weeks)
Hour –absolute: group by
hour, but with sum (don’t groupby to day)
Week: group by weeks
Day: group by days
Hour: group by hours
Minute: group by minutes
Day Compare: compare current
weekday with last week the same day
Called SIM Packet: group by
called simcards group
Partner/Day: group by partner
and day
Partner/Hour: group by
partner and hour
Partner/Minute: : group by
partner and minute
Called Country: : group by
called user country
Called Direction: : group by
callednumber zone
Provider direction (prefix)::
group by callednumber prefix
Provider direction (name):
group by callednumber direction
Direction and packet: group
by prefix and simpacket
Provider direction and
packet: group by callednumber zone and simpacket
By caller root endusers:
group by billed or company callerusers
Disconnect codes in graphical
form by any traffic direction.
The server will collect the
reason in the most appropriate format depending on the protocols used. For
example for a call from voip to gsm if the disconnect was caused by the gsm
party, then you will see the GSM network reason code here. Otherwise, if the
disconnect source was the caller party, and then you will see H323 or SIP
reason codes here.
The most common reason codes
are the followings:
-SIP, Bye: normal SIP close
code
-SIP, CANCEL: the call was
canceled by the caller (not connected call)
-H323, Remote endpoint
application cleared call: normal H323 disconnect
-H323, Remote endpoint
stopped calling: the call was canceled by the caller (not connected call)
-GSM, Normal call clearing: normal
GSM close code
-GSM, Normal unspecified:
normal GSM close code
-Server, Blacklisted: dropped
due to ACL (blacklist)
-Wrong Media: no voice
activity detected.
This is a simple listing of
your channels. You can discover all simcard problems by scrolling down this
list. (Missing channels are highlighted)
This module tests the
capacity for the predefined direction in priority order.
Shows system utilization
statistics such as concurrent calls, CPU load and RAM usage.
Note: AvM type means
weighted utilization: average of max and average usage ((AVG(value) +
MAX(value)) / 2)
Direct interface to the
server command port. Type help to see the available commands. You can connect directly
to any gateway interface.
Command defined on gateway
interface:
help
show this command list
info
show status and important parameters
cmd
launch the predefined process
exec
launch the predefined process
file
will send the requested file
showlog
will send the last lines from the requested file
timeset
will sent the current time
setini
write to config file
getini
read from config file
dtmf
send dtmf
ftpget
load from ftp
ftpput
put file to ftp
selfupgrade
do a selfupgrade
gwrestart
restart the gateway process
pcrestart
restart the gateway (hardware)
and
many more as described by the API (all API
commands are accessible also from console)
Raw
clear text CLI access is also listening on port configured by the adminport global config option.
CLI
access might be IP filtered by the remoteadmin parameter.
Possible values:
0:
disable
1:
from localhost/127.0.0.1
2:
from same machine
3:
from trusted sources
4:
from local lan and subnet
5:
from everywhere (default)
Will connect to the server
logport. The trace level depends on configuration (Open the Configuration form,
type “log” in the filter box, and hit the enter button. Then you can see all
options regarding to log levels)
Here you can see the log
records for the server and every connected Mizu Gateways in the selected time period.
You can restrict the listing by defining the source, severity or filtering.
You will get detailed system analysis
in this module. Thus you can see through the system by only one mouse click.
Malfunctions are colored in red.
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
Rtpsent and rtprec is 0
when media routing has failed (if we don’t route the media, or the terminating
endpoint don’t send media info to us, the system will set there values to 1, so
this condition will be true)
All prices in the cdr
records are calculated with VAT included!
To find out the possibilities
to list the CDR record for a user, please check this wiki.
Duration lists of several
traffic types.
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.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 (reseller) has common parentid
RingGroup: a list of usernames
separated by comma (all number will ring when the actual user will be called)
BelongsToCompany: when a
company has more then one subscriber. Used for example for short sip numbers.
IsCompany: if the current
user actually is a company
RGMode: how to use the
ringgroup: 0=forked call, 1=round robin
Name: user first and last
–name
Country: sip phone country
(important for prefix rules)
ContactName: additional name
UseCallingCard: if has
calling card (usable with pin codes)
CanDial: example: for sipuser
is 1. for simowners is 0
Phone: user phone number (but
not the sip phone)
Email: where the user can be
contacted
Address: where the user can
be contacted
Billaddress: where to send
the invoices
TelNumber: sip
telnumber.users can be contacted if we call there username or telnumber.
More than one DID or ANI
number can be assigned for one user. For this the tb_users_othernumbers table
is used where the type field is 0 for DID numbers and 1 for ANI numbers.
ShortTelnumber: sip short
telnumber (for example if several users has the same BelongsToCompany field)
DisplayName: how the user
will be displayed. Can be null
Username: the most important
field. Used for authentification and also as a DID number. This field is unique
and cannot be empty.
Password: password applicable
everywhere (sip, web, VPC, etc)
Ip: sipphone, sipproxy or
gsmgateway ip address. The server will overwrite with the last known ip address
AuthIp: if we want to
authenticate after ip, not after username/password
More than one auth ip or
domain can be used for a traffic sender. For this the tb_users_authip table is
used.
NeedAuth:
-If
NeedAuth is 0, then the system is an open voip relay !!!!
-If
NeedAuth is 1, then AuthIP must match (usually from SIP traffic senders)
-If
NeedAuth is 2, then TechPrefix must match
(usually from H323)
-If
NeedAuth is 3, then TechPrefix and IP must match (usually from H323)
-If
NeedAuth is 4, then user/pwd must match (usually from SIP end-users)
-If
NeedAuth is 5, then username must match
-If
NeedAuth is 6, then AuthIP and Port must match
-If
NeedAuth is 7, then AuthIP and username must match
-If
NeedAuth is 8, then AuthIP and username/password must match
-If
NeedAuth is 9 then AuthIP Range must match
-If
NeedAuth is 10, then AuthIP Range and username/password must match
AddDate: when the user has
been inserted in the database
Rights: rights on user
interfaces
0:
no access
10:
cannot login (disabled)
20:
can login but no rights
25:
restricted user (for example support under reseller)
30:
a normal user
40:
sales
50:
admin
60:
general admin
AddedBy: the user id who have
added this user (sales, web registration, etc)
Commission: used for sales to
define their 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
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)
Default
users:
Owner
mycompany: template for owner
GsmGw
LOCAL_GW: used for advanced gateways. IP=127.0.0.1
GsmGw
NOGW: used when no route found. IP=1.2.3.4, isfake=1,realgw=0
GsmGw
FBACKUPGW: used to handle traffic exceed. IP=127.0.0.1,
callsigaddr=1725,isfake=1,realgw=0
SipProxy:
sip2h323: convert signaling form h323 to sip and from sip to h323.
TechPrefix=-1,IP: 127.0.0.1?, Port?
TrafficSender:
virtserver X: for routing traffic from virtual servers. AuthIPList:
192.168.0.1, TechPrefix=XXX
Enduser:
PREDECTIVE_DIALER: IP: 4.3.2.1, TechPrefix?, username=cc_callbacknumber
The
following fileds has direct impact to routing:
Type
ParentID
RingGroup
UserGroup
onlylocalaccess
enabledtechprefixes
accessrights
enabledprefixes
blockprefixes
enabledroutes
RGMode
TechPrefix
forward...
temporarydisabled
onlytestcalls
testprefix
prioritypartner
allowedpartners
callerpriority
calledpriority
absolutepriority
Administration of Mizu
Gateways, Other GSM Gateways, H323 Endpoints, SIP Proxies, ISDN Gateways and
other compatible devices. The fields are the same as for the Users (see above)
If
the actual sip proxy require authentification, then we store the accounts in
this table
Id: database identifier. Auto
increment
Priority: Account priority
(accounts will be used in priority order or in round-robin if they have equal
priority)
Username: sip username used
in authentification
Password: sip password used
in authentification
CallerNumber: usually the
same as username. If left as blank, then the server use the actual caller username.
Credit: account balance. When
it reach 0, then we switch to the next account if any
DateEntered: record insertion
date
LastUsed: the date-time when
the server was routed some calls with this account
ProxyID: to which proxy the
account belongs
Enabled: set to 0 to disable
the usage of this account
SubsFails: the number of subsequent
wrong calls with this account. If subsfails will reach a predefined value (30
as default), it means that there is some problem with this account or the
money/time limit have been expired, and the server will switch to the next
account if any
Grouping of several items
will ease the administrations tasks. The following type of items can be
grouped:
SIM Packets
Users
Gateways
Traffic Senders
These groups then can be used
to simplify your routing and billing.
Useful when you have arranged
your users in certain hierarchies. For example reseller chain relationship.
Resellers can have an unlimited child-parent relationship
(limited by the ”maxresellers” global config options).
To define the relationships
we use the tb_users id and parented fields.
Registration and authentication
User 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_phonenumber
o
autogeneratedid: 0=no,1=auto
generate random,3=auto select from tb_telnumbers,6=user select from
tb_phonenumberx
o
allowenduserdidedit: allow enduser
to edit its own telnumber field 0=no,1=yes for resellers,2=yes for endusers
Ø
Assign multiple DID per user
You can use the othernumber
list for this (tb_users_othernumbers). The same DID can be even assigned for
multiple users. In this case the incoming call is routed to the “best” user
(Best effort: user online, not in call, etc).
Ø
Contact list
DID numbers can be also used
to be assigned to users contact lists if they are listed as Shared DID’s in the
users table. In this case the DID numbers can be shared and will serve multiple
purposes:
o
Incoming call from user to a DID
in its own contactlist: call will be routed to the contact (username or phone
number, which is “best
o
Incoming call from contact
(username/phone number) to assigned DID: call will be routed to user (to which
user the contact belongs)
o
For outgoing calls the A number
will be also set accordingly or after the rules discussed above
Ø
Shared DID
For shared DID you will have
to create users with the DID numbers (username set to DID number, shared did
option checked) and then these DID numbers can be used by multiple users in the
same time. These will ease the access to users favorites from other networks
(calling via third-party servers or via the IVR).
Endusers can assign their
contacts (internal user or external phone number) to these DID numbers from
webportal phonebook page.
To enable/disable this
feature, you might 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
This table can be used to
store the phone numbers but also for special DID number storage. Editable from
“Phone numbers” form.
Fields:
·
id: auto increment db id
·
datum: record creation date
(number added date)
·
telnumber: the phone number
·
ttype:
0=def,1=normal,2=did,3=smsdid,other=other type
·
free: 0=allocated,1=free (not
allocated),2=locked,3=temporary locked
·
useddate: date when it was
assigned to user
·
comment: any notes
·
location: not used
·
lockeddt: number preallocated at
sign-up with the getphonenumber API
·
gatewayid: set to SIP server ID if
number has to be used only with this SIP server
·
userid: number was last used for
this user (trying to use the same number with the same user)
Terms and Settings:
-DID: Direct inward dialing
(DID) or called direct dial-in (DDI) is a telecom service to share a single SIP
trunk among one or more users
-ANI/CLI authentication:
Automatic Number Identification/Calling Line Identification
-Toll free: is a special
telephone number, in that the called party is charged the cost of the calls by
the telephone carrier, instead of the calling party. This can be configured as
a normal access number (enduser) and eventually with higher billing (because we
will be the billed party in this case)
-local DID number: normal
access numbers. Usually you will have separate DID numbers for different
regions to minimize enduser costs
-callback: DID or toll free
number configured as enduser with iscallback set to the required IVR
-ANI callback: same as
callback with User-ID based authorisation (A number)
-Virtual Numbers (DID):
"real" phone numbers allocated for users. You have to buy DID numbers
from CLEC or any other service provider like didx.net
TelNumber: sip
telnumber.users can be contacted if we call there username or telnumber
Username: the most important
field. Used for authentification and also as a DID number. This field is unique
and cannot be empty.
ShortTelnumber: sip short
telnumber (for example if several users has the same BelongsToCompany field)
DisplayName: how the user
will be displayed. Can be null
More than one DID or ANI
number can be assigned for one user. For this the tb_users_othernumbers table
is used where the type field is 0 for DID numbers and 1 for ANI numbers.
autogeneratenewuseraccounts;
//0=no,1=auto generate random,3=auto select from tb_telnumbers,6=select from
tb_phonenumber
autogeneratedid; //(new)
0=no,1=auto generate random,3=auto select from tb_telnumbers,6=select from
tb_phonenumberx
allowenduserdidedit; //allow
enduser to edit its own telnumber field 0=no,1=yes for resellers,2=yes for
endusers
feature_shareddidnumbers:
-1=auto (def), 0=no,1=yes old,2=yes new,3=yes new and old, 4=also check last
calls, 5=extended search, 6=extreme
shareddid_checkcontactlist:
//-1=auto (def) ,0=no,1=yes old,2=yes new,3=yes new and old
shareddid_checkcdr: -1 (def) =auto,0=no,1=yes,2=yes
extra
checklocaluserforshareddid =
1; //0=no,1=yes (def)
replacecalleroncalls: 0=no,1=default
checks (best num; default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good
num, 6=check minassertedidentitylen,7=with phonenumber,8=anonymous
replaceanumwithdid: -1=auto
(def) ,0=no,1=shareddid,2=companydid,3=cdr,4=all,5=4+extended cdr search
forcedcallernidentity:-1
(auto, def) , user and global setting 0=no,1=default checks (best num;
default),2=dbusername,3=dbsipnumber,4=bestnumber,5=first good num,6=check
minassertedidentitylen,7=with phonenumber,8=anonymous
identityrewrite/identityforward: user
setting to replace client->callernumber (controlled by
config.identityrwmode)
identityrwmode: 0=no rewrite,
1=basic, 2=conform sip specification (identity; def)
sendidentity: 0=never,1=no
(def),2=sometimes,3=always
configallowusernumbertopstn:
-1=auto, 0=no,1=yes if phone number, 2=always (send call to outbound if user is
offline)
cli:
user setting
0: forward
always (forward asserted as normal number always!)
1: normal handling
(forward asserted as normal number) -default
2: forward as
asserted identity always (forward identityrewrite asserted)
3: forward as
asserted identity only to trusted domains (forward identityrewrite asserted)
4: normal hide
(no idenityrewrite forwarding)
5: force hide (no
asserted identity too!)
minassertedidentitylen:,7=with
phonenumber,8=anonymous affects only P-Asserted-Identity; will
owerwrite any cli settings. default is -1
didhandleruser: a globally
configured number where incoming calls to DID will be routed if no user match
(can be a receptionist or an IVR)
globaldidout: a globally
configured number to set the A number to this for all calls (should be used
only by small business owners)
Incoming calls can be checked
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).
You can pre-allocate a number
to a user at sign-in with the getphonenumber API.
Example: http://11.22.33.44/mvapireq/?apientry=getphonenumber&authkey=8725436&count=5&now=555
You can assign a DID to a user in the following ways:
-use it as the “username”
-set the “telnumber” field
-add it to
tb_users_othernumbers table (if you wish to assign more than one did to a
single user)
A quick tutorial can be found here.
The “dial patterns” terminology is not used with the mizu
voip server. You can apply the number rewrite rules by the following ways
(starting from simple to more complex rewrite rules)
1. Number
normalization: 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
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)
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:
You should instead use the
“Rules” form mentioned above.
You can rewrite prefixes
before they arrive to the routing by entering your preferences here.
The Mizu routing engine will
accept only 3 digit length techprefixes or no thechprefix, so you must convert
them here if your traffic sender will send the traffic with techprefix that are
not three digit length.
Example 1:
To
set up a rule which defines that every incoming number from ip 111.111.111.111
on H323 if begins with 1234 must be rewritten to begin with 56. Number
123499999 will be rewritten to 5699999.
If
the “RewriteFrom” is emtly, then the “RewriteTo” fill be inserted before the
number
Example 2: To remove 011
before all dialed numbers:
Protocol:
0
Type:
1
Value:
empty
Rewrite
from: 011
Rewrite
to: empty
Number
to rewrite: Incoming Called (0)
Example 3: To replace 06 with
446 for all SIP calls coming from 192.168.1.8:
Protocol:
1
Type:
2
Value:
192.168.1.8
Rewrite
from: 06
Rewrite
to: 446
Number
to rewrite: Incoming Called (0)
Example 4: to handle the
hungarian roaming prefix: 08 + SK + BK + NSN +SN you have to set the following
values:
prefixrewritestr:
08X…
prefixrewritefrom:
9
prefixrewriteto:
36
You should instead use the
“Rules” form mentioned above.
During the routing process
you can modify the caller and called number with the dialplan stored procedure
(v_dialplan)
v_dialplan can be called
several times during the routing depending on the checkdialplan1-4 global
config option.
For CLI and A number rewrite
it is enough to set checkdialplan4 to true (after routing) and check/rewrite
the numbers using the LIKE operator (wildcards are enabled).
Input parameters:
@calledat TINYINT, /*1=first check, 2=after
authentication, 3=before routing out, 4=after routing out*/
@protocoll TINYINT, /*0=SIP, 1=H323, 2=GSM,
3=Other*/
@fromip varchar(22), /*caller ip address*/
@fromport SMALLINT, /*caller port*/
@callerid int, /*caller device database
id from tb_users*/
@callernumber varchar(35), /*caller number or sip username*/
@callername varchar(35), /*caller name or displayname*/
@calledid INT, /*called device database
id from tb_users*/
@origcallednumber varchar(35), /*called number as received*/
@techprefix VARCHAR(10), /*called number tech prefix*/
@normcallednumber
varchar(35) /*normalized (changed)
called number*/
The stored
procedure can be called at different routing stage:
1: before
authentication
2: after auth
3: before routing
4: after routing
This means that
if a number has efect on authentication then you can rewrite it on stage 1, but
if you need to modify the called number only for the b-leg call then it is
better to call this function only at stage 4
Some of the input values are
not set at earlier stage. For example when calledat is 1 then the callerid will
be 0 because the caller is still not known at this stage.
Usually only the called
number have to be rewritten, but you can also change the other values.
Accepted output values:
-emty string: no effect
-_REJECT: will disconnect the call
-_REJECTPLAY,filename: play a file and
disconnect the call
-callednumber: will change the called
number
-callednumber,calleddialed,origcallednumber,techprefix,callernumber,callerid,calledid
Field details:
-Callednumber:
will be used for further routing decisions, for billing purposes and it is
stored in CDR record
-Calleddialed:
will be used only for b-leg
-Origcallednumber:
can be used for further routing decision (mostly not used)
-Techprefix: can
be used for further routing decision. Deprecated after version 3.5
-Callernumber:
can be used for further routing decision and stored in CDR record
-Callerid: you
can modify the caller user if you change this parameter
-Calledid: you
can modify the called user if you change this parameter
sql help:
sql tutorial:
http://www.w3schools.com/SQL/sql_intro.asp
stored procedures:
http://msdn.microsoft.com/en-us/library/aa174792(SQL.80).aspx
string functions:
http://msdn.microsoft.com/en-us/library/aa258891(SQL.80).aspx
like operator:
http://msdn.microsoft.com/en-us/library/aa933232(SQL.80).aspx
example:
DECLARE @ret_callernumber
varchar(35)
DECLARE @ret_callednumber
varchar(35)
SET @ret_callernumber =
@callernumber
SET @ret_callednumber =
@normcallednumber
IF (@calledid = 456 and
@ret_callednumber LIKE '1_23%')
BEGIN
SELECT '_REJECT'
RETURN 1
END
IF (@calledid = 457 AND
(LEN(@ret_callednumber) < 5 OR ISNUMERIC(@ret_callednumber) = 0))
BEGIN
SET @ret_callednumber =
'1234567'
END
IF (LEN(@ret_callednumber) > 6
AND LEFT(@ret_callednumber,3) = '061')
BEGIN
SET @ret_callednumber =
'36'+SUBSTRING(@ret_callednumber,3,35)
END
IF (@ret_callednumber LIKE
'5222%')
BEGIN
SET @ret_callednumber =
SUBSTRING(@ret_callednumber,5,35)
END
SELECT @ret_callednumber+’,’+@ret_callednumber+','+@ret_callednumber+',,'+@ret_callernumber
RETURN 1
If the stored procedure
doesn’t run successfully, then it will have no effect.
List the blacklisted target numbers
on the selected time interval and direction.
This query will generate high
server load. Use it only in off-peak time if possible
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
For every time period and
direction a “Routing Pattern” needs to be defined. Every Routing pattern has a
list of routing directories which may be Mizu GSM Gateteways, other H323
gateways or gatekeepers, ISDN gateways or SIP proxies in priority order. Set up
as much directories with the same priority order as possible so the routing
engine can prioritize itself after other settings (device priority, LCR,
quality, BRS)
Generic rules can be defined
by setting the pattern priority lower. For example for every call that doesn’t
have a specific route can be routed to a specific direction (otherwise is
dropped)
There is a list of typical
time definition. If none of them match your needs, the “Start-End Time” entry
can be selected to specify proprietary intervals.
In Caller Prefix, you can
place only one prefix.
Tech prefix can be empty
string, asterisk (*) or 3 digit length number.
Called prefix can be one prefix
(with any length) or a list of prefixes with 3 or 4 digit separated by comma.
*Tip: you don’t need to
enforce traffic sender rights by routing. The routing can be done as generic as
possible for example by specifying only Called Prefixes (Leave the other
direction option blank or ‘*’). Rights can be enforced by setting “Enabled
Prefixes” for all Traffic Senders
Routing Configurations
Try to set up all routing rules
and prioritizations using this form.
Try to avoid prioritizations
by gateways, simpackets or channels (absolutepriority, priority,
allowedpartners, prioritypartners, etc)
Almost all kind of
configuration can be set up by using only the “routing” form
The actual priority order of
your route list (right side list) will be affected by numerous factor:
-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
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
Define the radius servers, protocol
and login information here. Used for authorization and billing.
Short name for “Best Route
Selection”.
In addition to LCR (Least
Cost Routing), the Mizu routing engine can take in consideration the quality of
the route.
To activate BRS
based routing, the “brs_lcr” global configuration option have to be changed to
4 or 5. Then the routing will
check both the pricing and the routing, which you can 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)
Fields have the following
meanings:
-Id: database identifier.
Auto increment
-Gateway: gateway id (called)
-Direction: called prefix
-QualityPercent: how much
the quality will contribute to the final result. If price is very important for
us, set this value lower. Default is 50%
-Accuracy: how accurate the
final result will be. If we set it too high, then we probably will have only
one route as the best. If we set it too low then too little discrimination will
be made between routes. So, the final result (AutoPriority) will be lowered
only if we have too wrong acl, asr or price.
Default is 30%. This default
means that the AutoPriority will change only if price will change with 2-3 amount
or asr will change with at least 15% (considering asr between 10 and 80, price
between 0 and 40 and QualityPercent as 50%)
-ASRDay: last day ASR
(automatically calculated every day)
-ACLDay: last day ACL
(automatically calculated every day)
-ASRMonth: last month ASR
(automatically calculated every month in the last day)
-ACLMonth: last month ACL
(automatically calculated every month in the last day)
-MinASR, MaxASR,
MinACL,MaxACL: when asr or acl reach the min value, then the line is considered
very wrong. When it reaches the max values, then the line is considered very
good. Must be configured manually for every direction, because the statistics
will change dramatically by country
-MinPrice, MaxPrice: min-max
prices/minute. set it to a very wrong price to that direction and the max value
to a very good one. Calculate it with consideration to billing step and min
minutes (so you must fill in as 1/1 price)
-PriceCalcSec: we estimate
the price values with this value to get a gross value
-TryedCount: how much time we
have tried this alternative route until now. Helps us the decide how to
increment NextTry. It will grow only until 7
-NextTry: we will route calls
to this route beginning with this date. Will grow exponentially until 1 month.
-NextTryCount: we will route
NextTryCount calls on this route next time. ( > CurrTryCount)
-CurrTryCount: counter to
know how many times we have routed in this direction
-AutoPriority: the current
priority calculated from these values and from the price settings (the result)
To see how much a parameter
change will modify the final AutoPriority value, you can find a demo named
AutoPriorityDemo in MManage, Config menu - > Utilities. Before changing any
value in the BSR table, please play a little with this demo.
Mizu server and gateway will
make automating 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 failovering:
when an outbound gateway has wrong global statistics
-direction failovering:
when only a few direction (prefix) statistics are wrong on an outbound gateway
-failovering on subsequent called number
-in-call failovering (this is also called as “rerouting”)
The failovering 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, 2: yes-must
-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.
Skip this chapter if you
are not using VoIP-GSM gateways.
Best quality (ASR and ACD)
SIM channels can be reserved for sip or h323 originated calls.
In the sim table the reserverfor
field can have the following values:
0=cannotreserve:
this channel will not be reserved
1=sip:
always reserve only for SIP (manually assigned)
2=h323:
always reserve only for H323 (manually assigned)
3=ISDN:
always reserve only for ISDN (manually assigned)
4=dynamic:
can be allocated by the server dynamically (hourly check) -this is the default
value
5=sipdynamic:
allocated automatically for SIP
6=h323dynamic:
allocated automatically for H323
7=
ISDNdynamic: allocated automatically for ISDN
For every simpacket you can
restrict the maximum allowed reservations by the maxalloc field. (useful
to not reserve all channel from the same simpacket)
To setup the channel
reservation use the following configuration values (mserver, simplatform
config):
-reserveforh323:
reserve capacity for h323. reservations will be disabled if less than 1
-reserveforsip:
reserve capacity for sip . reservations will be disabled if less than 1
By example if you set the
reserveforsip field to 5, you can be sure that 5 channels always remain free to
be used by calls received with SIP protocol (H323 originated calls didn’t
consume all your channels)
The number portability module
can be used to alter the routing if the number is ported to another operator
for MNP (mobile number portability) or LNP (local number portability) reasons.
More specifically it can
influence the routing in one of the following ways:
·
route the call to the server
specified by newdomain:newport (The fwdtootherdomains
must have to be set to at least 1 for domain routing to have effect.)
·
route the call to the SIP server
specified by sipserverid (or by carrierid with a lookup from tb_carriermap)
·
change the called number as
specified by the newnumber field
·
add a prefix to the called number
as specified by the providerpx field
You can set the ported
numbers form the MManage “Number Portabilty” form or you can automate the
process by programmatically changing the tb_portednumbers database
table. The Export/Import wizard from the file menu can be used to easily
populate this table (from CSV or other sources).
You can control the server
number portability handling by the “checknumport” global configuration:
-1: auto (will turn to 4 if there are entries in the
tb_portednumbers table)
0=not check
1=check for changed prefix only (replace)
2=check for changed number only
3=check for changed domain only
4=check for changed server id only
5=check for changed prefix only (insert)
9=check all
tb_portednumbers:
id: autoincrement database primary key
number: original (normalized) called (B) number
sipserverid: change the SIP server id to this
carrierid: change the SIP server id to this via the tb_carriermap
lookup table
providerpx: new prefix (for example instead of 3630 changed to
3620)
newnumber: the changed number
newdomain: the new service provider ip or domain
newport: service port (defaults to 5060)
priority: checked for duplicate numbers
datum: record insertion date
You must have the
providerpx OR sipserverid OR carrierid OR newnumber OR newdomain:newport
specified.
If certain numbers must go to
certain carriers (SIP servers) then you might use the tb_carriermap table to
add the carriers and just use the carrierid in the tb_portednumbers table. This
way you can easily manage the carriers used for LNP.
An important step for the
number portability configuration is the access of the number mapping data. This
can be set in the following ways:
·
Add the number mapping manually
·
Create some tool/script to
download the data into the mizu table database (and run in periodically from
scheduled tasks)
The data can be extracted from a remote database,
http/ftp file download or via an API
·
Access the data via an API at
runtime (HTTP GET). This can be slow
Country specific:
Country specific operator
lookup and LNP lookup can be configured with the numporttype global config
option.
Currently the following
values are defined:
·
0: default
·
1: Brazil specific
·
2: Mexico specific
For more complex number portability
handling with CADUP and
SPID rewrite per operator, you can also use the tb_routingprefix and tb_directions
table to store these informations (spid and cnl fields). A detailed description
about the whole process can be found here.
You might use the mimport
application to import the numbers (will require customization for you data
source and format).
The current implementation is
for Brazil, but
that can be adjusted for any country with similar requirements for LNP.
For Mexico specific LNP see
the number_portability_mexic.pdf guide and download the mexic specific mimport from here.
Enum lookups can be used to
route the calls to other SIP servers directly bypassing the PSTN network to
reduce the costs and improve the quality of the calls.
Mizu Servers and Gateways has
built-in prepaid and postpaid billing.
The pricing must be set from MManage
–Prices Settings form
You can list and compare the
prices for different directions in the Price List.
The Billing and Invoice
generation are done from the “Billing” form.
A quick tutorial can be found
here.
The Billing module
conforms to the Hungarian laws and can be modified to fit for other countries.
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.
Field descriptions:
Title: the name of the
invoice group
Schedule: how often the
report will be generated
DueIn: allowed time for payment in day (used only if the report is an invoice)
Status: billing status
Invoice Type: specifies
the format of the invoice
Group By: specifies the
format of the invoice
Separate by caller: every
caller will receive a separate invoice (used for billing to end-users)
MailTo: list of email
address where to send the generated report
Last Invoice Sent:
date-time when the invoice was emailed to the recipient
Last Payment Received:
date-time when the payment was received
Direction name: name of the
billing entry
Type: specify the type of
the price. For example the prices used when billing to endusers, or our minute
costs to service providers.
Price calculations will be
saved directly in the CDRs, thus can be used in prepaid billing. In the CDR
records, the following fields are used for price calculation:
-costprovider:
used to calculating the minute price they needs to paid to service provider
(Tmobile for example)
-costenduser:
used for billing to our endusers (sip endusers, traffic senders)
-costcompany:
can be used for profit calculations
-costsales:
sales commission. If not set, than will be calculated by the commission value
in users settings
-costother:
can be used for any custom price calculation
Action: How to handle the
calculated price in reporting. For example in “profit” calculations whe have
expenses (prices paid for service providers) and incomings (from our endusers).
Thus we can simply subtract the expenses from the incomings to get the “profit”
Billing Steps: provider
specific billing interval in sec
Min. Amount: the minimum
payable duration in sec
Free Amount: you may have
packets when the first X second is free
Free After: you may have
packets when after X seconds the conversation is free
Currency: different providers
may have different currency. Used for billing.
VAT Included: if the
pricelist applied for this user is with VAT included. Set to 0 if VAT is not
included. Used for billing.
VAT Value: the amount of VAT
applied for the pricelist. Will have effect only if “VAT Included” is checked
Convert to NET value: if you
have defined the pricelist with included VAT, you should check this option, otherwise
you overcomplicate the billing process. Thus the VAT value will be subtracted
from the price, and you will have NET values in CDR records (try to use net
values whenever possible). If you need to generate invoice, make sure that all
your prices are set without VAT (net) or you have checked the “Convert to NET
value” checkbox.
Convert to XXX: if you have
defined the pricelist in other currency than the native
(configurations->currency), than your prices will be automatically converted
to native currency in CDR records.
Reseller: price created by
resellers. Usually should be changed only by resellers (from web portal)
A leg grace: used for IVR
billing. If the user will spend too much time using the IVR.
Traffic Direction: here you
have to define the rules when the current pricing will be applied
Usually
only one field needs to be specified here (for example all traffic from MizuTech
SRL -caller)
The
caller field will check the caller parent also, but the called field will not
check the parent.
These
directions will be checked in priority order on routing and billing
ValidSince, ValidUntill: the
pricelist may be applied only after a specified date-time
Prefix: called number prefix
(this will be loaded after “best fit”). Set to ‘*’ to be applied to all
directions
Price: the actual price
CPrice: the price converted
in your currency (“currency” entry in the Configuration form and converted
after the values specified in the “Currency Converter” form)
Time Definitions: the time
period when this rule is applied
Diff between enduserprice and
providerprice means that price will be calculated by extracting the provider
cost from the enduser cost for an already existing cdr record. Cannot be used
for realtime (prepaid) price calculations. Usually used when calculating
“profit” values.
By clicking on the “Clone”
button, you can easily duplicate a price list (it is very useful when you have
to add only a few modification to a long pricelist)
The Billing button is a
shortcut to the billing form (does not make the billing automatically)
Importing price definitions
from file are done by clicking on the “Import from file” button.
First of all you must create
a packet (middle column) defining the general packet properties and the
conditions when it will be used. Then you can import a price list for the packet
(right column -> “Import from file” button).
The imported file must be
comma separated CSV file format.
You can use the Excel ->
Save As functionality to export any Excel sheet as CSV file. You can also
easily edit any CSV file in Excel. (Don’t leave empty columns before the
columns with data)
The file must have the
following fields (columns), in this order:
1.
prefix (direction definition;
mandatory)
2.
price (flat price; mandatory)
3.
peak price (if a separate preak
time price is required; you might also use a separate packet for peak/offpeak)
4.
offpeak price (if a separate
off-preak time price is required; you might also use a separate packet for
peak/offpeak)
5.
billing step (if you need
different billing step by prefix instead of defining the same for the whole
packet)
6.
minammount (if you need different
minimum billed amount instead of defining the same for the whole packet)
7.
mindigits (this prefix will match
only if the called number length is at least mindigits)
8.
maxdigits (this prefix will match
only if the called number length is at most maxdigits)
Only the first two columns
(prefix and price) are mandatory. The rest can be omitted or their value can be
empty.
If you use the “default peak
time definition”, the peak settings will be loaded from the global configuration
(peaktimebegin and peaktimeend values). If this is not suitable (different
service providers may calculate with different peak-offpeak definitions), you
can set up the peak time definition manually (start – end hour).
If you use flat price, than
leave the peak and offpeak price fields empty and vice-versa.
Importing price files may
take some time, depending from your network connection speed.
Pricing example:
-a separate provider cost
tariff for each of your carriers (where you are forwarding your outgoing calls)
-one enduser cost tariff for
your wholesale traffic senders (or a separate tariff for each of them)
-one enduser cost tariff for
your enduser or create a few groups (like premium and regular) and setup
different pricing for each of them
On the List tab you
can list all prices for a packet (by using the “Packet” list box) or to a
direction (by entering a direction name or a prefix to the filter box)
On the Least Cost tab
you can compare the prices from different service providers.
The Reference Packet usually
is the price for your end-users.
Only peak (max) prices are
compared for every direction.
On the Directory Check tab,
lookups from the directory table are possible ( directory name – prefix match).
The
server automatically calculates the price field for every incoming CDR record,
based on price settings ( Section 4.5.1)
The
following prices are calculated:
-enduser cost: used for invoicing for costumers
-provider cost: cost that needs to be paid for service
operators
-sales cost: sales commission. If not defined in price
setup, then will be loaded from users’ settings (“commission”) if any
-company cost: usually used for profit calculations
-other cost: for any other purpose
Billing
can be done from
1.
the “Users and Devices” form, Billing tab, by clicking on the “Generate
&Invoice or Report” button (billing for the actual user)
2.
set up required directions and click on the “Billing” form (in this
manner, billing reports can be generated for more users)
The
billing process will always take in consideration the selected date interval.
Billing form:
1. On the Customized
Billing tab after selecting the required date-time interval and direction,
the prices are calculated after predefined parameters (price/minute,
billingstep). So you can do simple calculations using this form.
2. The CDR Prices tab
will load the “enduser cost” and “provider cost” directly from cdr records
(already calculated after real-time price settings)
3. Generating Reports and
Invoices tab
Used for billing and
reporting.
Fields explanations:
Provider: you must select the
invoice emmitent here. By clicking on the “…” button, you can customize the
company invoicing details.
Delete old invoices: if
checked, than will clear the invoice files directory before saving the new
ones.
Include inactive users:
uncheck this checkbox, if you don’t want to generate reports (invoices) for
inactive users (inactive for the selected period)
Include child users: for
example you can select a Reseller as direction source, and all “child” users
will be included in billing (where the parent id will point to that reseller)
Include CDR records: include
call detail records in appendix
Language: language of the
invoice
Grouping: you can select any
grouping options to be generated as appendix for the report
Price values: select the
price field from the CDR record after which the billing are done.
Reporting: you can
automatically save the generated reports or invoices to file, or open it one by
one (you can decide what to do for every report -save, print or just preview)
Format: file format (text,
pdf) or printing
Real
Invoice: if you would like only a quick report for the selected user(s), you
can do it by setting this option to “Don't generate real invoices”. If you choose to generate real invoices, than it will
take special processing for it (required for bookkeeping)
If you have selected a
reseller, you should choose the “For Resellers” option. In this manner a real
invoice only for the reseller company is generated. (A report will be generated
for all child endusers, but those report are skipped from the bookkeeping)
Invoice Comment: any comment
here. This will not be shown on the report
Money Precision: how many
floating point digit would you like in money fields.
Completion date: defaults to
the end of filling period if not modified
Method of payment: can be specified
here, or loaded from user setting.
By clicking on the
“&Generate report for the selected directions” button, you can generate the
actual invoice(s)
4. Invoices and Payments
The invoice records for the
selected user(s) are in this form. You can watch the debt for every user by
checking the topmost record debt value.
By right clicking on a
invoice record a menu will appear. From
5. You can change the price
settings whenever you want, but don’t forget to Rebill your CDR records
after the new settings. All CDR prices will be recalculated for the selected
time interval and direction. Users and simcards credits will NOT be modified by
rebilling!
6. Individual invoice
On this tab you can create
invoices manually (not automatically generated from cdr records)
Note: prior to generate
pdf report you should configure the installed print to pdf driver to save
automatically in the specified directory. The default pdf printer can be configured
in the MManage menu on the Settings-> Options from. The “pdfcreator” driver
is included in the MManage install package.
For printing jobs, the
default configured printer will be used.
The automatic prepaid
credit expirity can be configured with the following settings:
Creditunit:
how many credit means 1 day
Creditelapseunit:
prepaid credits will be elapsed automatically after this period is elapsed.
Creditelapseunit means the credit amount for 1 day. For example if you set it
to 40 and the user will buy 5000 ft credit, than it will elapse after 4 month
Maxcreditelapsedays:
max number of days when the credit will elapse
Accelapsedays: the number of days from creditelapsedt when the account will
expire (account number will be suffixed
with _elps ans set to temporarydisabled)
tb_users.
Creditelapsedt: date-time when the credit will be expired
tb_users.Accelapsedt:
date-time when the account will be expired
For
this to work, you must set the “accountcanelapse” global config option to
“true”. The credit expire date is calculated when the credit is added.
*You can set prepaid
credit by the “Add with elapse” button to elapse automatically.
Monthly payments can be set for users by completing the tb_fees
table. Can be accessed from the Users Form -> Billing tab.
The following fields are defined:
Userid:
the user where the payment belongs
Datum:
record insertion date
Name:
the title of the payment
Value:
net price
Usable:
can be calculated in minute price (1 if yes, default is 0)
Ival:
-1:
one time
0: monthly as soon as possible
Other: internal in days
Lastbilled:
last time when the it was invoiced
Description:
any comment here
To make the billing stricter,
you might also set the following global parameters:
blocknotbilledcalls: 0=no
(default),1=if best match packet is not found,2=if no exact packet match with
prefix,3=block if not assigned directly for the user,4=check also tarifflist
prefix,5=check also parent tarifflist
blocknotprofitablecalls 0=no
(default),1=yes,2=yes also if equal,3=block also when it is not set
vgetpriceexactmatch: 0=no
(default), 1=yes for resellers, 2= yes for all
notbilledcallerr=0 0=default
(error with 2 priority),1=error,2=critical
You can set currency in 3
places:
- -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 ‘,’
You can use this form for
your cash-flow administration regarding your voip business.
Recharge codes used if you
have prepaid cards printed.
You can generate random
prepaid codes here.
Prepaid account can be
charged over the website or by ivr:
Website operation:
-user authentication
(tb_users.username and password)
-check if pincard is valid
(tb_prepaidcodes)
-increase credit for the user
(tb_users.credit)
IVR operation:
-automatic user
authentication based on sip registration or require entering the phone number
to be charged
-require pincode
-check if pincard is valid
(tb_prepaidcodes)
-increase credit for the user
(tb_users.credit)
-goodbye message
Every cdr record are handled
by the billing module. Prices are determined by the v_getprice stored
parameters.
v_getprice parameters:
@type tinyint: type of the
billing. 1=enduser cost, 2= provider cost, 3=sales cost, 4 = company profit, 5
= other cost
@callednorm varchar(26):
normalized callednumber. example: 36301111111 (B number)
@callerid int: database id of
the caller user
@callernum varchar(26):
caller number (A number)
@techprefix varchar(4): 3
digit tech prefix if exists
@calledid int: database id of
the called user
@calledpacket int: simpacket
if exists
@timetype1 tinyint: time
period
@timetype2 tinyint: time
period
@timetype3 tinyint: time
period
@timetype4 tinyint: time
period
@currday smallint: weekday
number (Monday is 1)
@currhour smallint: call
midtime hour
@currmin smallint: call
midtime minute
@parentid int = 1: database
id for the parent of the caller user
timetypes are considered when you doesn’t set a concrete
start-end period in the price list, and you choose from a predefined pattern
(peak, offpeak, weekend, weekday, holiday,evening, night). the following
timetypes are defined:
0: Disabled
1: Start-End Time
2: Peak
3: Offpeak
4: Weekday
5: Weekend
6: Offpeak and weekend
7: Evening
8: Night
9: Holiday
10: All times
11: Other Times (Rest)
example: v_getprice
'1','36301234567',6555,'003615555555','150',666,-1,4,2,99,99,4,11,41,500
The v_getprice stored
procedure will return the following fields:
tb_billentries.currency,tb_billingtimes.isdiff,tb_billingtimes.origprice,tb_billingtimes.price,
tb_billentries.billingstep,
tb_billentries.minammount,tb_billentries.freeammount,tb_billentries.freeafter,tb_billentries.vatincluded,
tb_billentries.vatvalue,
tb_billentries.converttonative,tb_billentries.converttovat
According to returned billing
settings, the price is calculated accordingly.
If there are no price
defined, than default price are loaded. (if set)
If there are no sales
price defined, than will be loaded from user setting (commission)
For enduser prices,
the discounts and userreductions are applied if set so. Then the user credit
is updated.
If there are any error
with the billing process, than the default prices are applied if exists.
Billing verification:
List the required CDR records
with “Show minute price option”
You can find the billing logs
if you search for the called number in the server logs.
Copy the required v_getprice
log in the direct query form.
Check if the returned values
are as expected.
Invoices and payments are
stored in tb_invoices in the database. So the invoices can be
searched, recreated and storno invoice can be built based on existing invoices
(conforming to Hungarian laws).
The last invoice number
are loaded from database before every new invoice and incremented. Thus the
invoice number increment is guaranteed the by database engine transactional
behavior.
The following fields are
defined:
ID: autoincrement database
primary key
Type:
0=All or Recreate
(technical)
1=Report
2=Proform
3=Advance
4=Invoice
5= CreditNote
6=Storno
7=Correction
8=Payment (technical:
payment received)
Copynum: printed copies
CompanyID: emmitent company
ID (tb_billsources)
UserID: costumer ID from
tb_users (if any)
User_name: costumer name or
company name
User_address: costumer
address
User_regnum: costumer
registration number
User_euregnum:
costumer eu registration number
User_bank: consumer
bankdetails (cont and address)
Payment_type: mode of the
payment (Ex: bank-transfer)
Datum: record date-time
Invoicenum: the number of the
invoice
Invoiceid: deprecated
Invoicefrom: billing period
begin time
Invoiceuntill: billing period
endtime
Invoicegenerated: invoice
print time (optional)
Invoicesent: invoice sent
time (optional)
Completitiondate: completition
date
Duedate: payment due date
Language: invoice language
Vat: VAT percent
VatValue: sum of VAT
InvoicePrice_Net: final net
price
InvoicePrice: final price
PaymentReceived: date-time of
the payment
Debt: sum of all debt
Pending: all sum before due
date
Comment: invoice comment
InvoiceImage: saved ivoice
file
tb_invoice_entries:
Id: autoincrement database
primary key
Invoiceid: foreign key to
tb_invoices
datum: record insert date
description: product
description with code
fromdate: billing period if
applied
todate: billing period if
applied
Ammount: ammount
AmmountName: name of the
amount (minute)
AmmountPrice: unit price
(net)
The emmitent (company)
settings are stored in the tb_providers table. Only one company entry
can be stored (conform to Hungarian laws). Once the company details are
inserted to the database, the company name cannot be changed anymore.
Creditelapseunit: prepaid credits will be elapsed automatically after
this period is elapsed. Creditelapseunit means the credit amount for 1 day. For
example if you set it to 40 and the user will buy 5000 ft credit, than it will elapse
after 4 month
Currency: the currency type is loaded from the “currency”
global configuration or from the billed user currency setting.
The price setup currency
settings also can affect the currency settings.
Currency conversions: if the pricelist is not in the native currency
format (set by the “currency” global config option), than the server can
convert to it automatically based on tb_currencies. You can change the
conversion rates from MManage -> Billing -> Currency converter
Language: the invoice language can be controlled from the
invoice form.
PDF Printer and delay: set this on MManage -> Menu->
Options
Time format: if to separe duration values to day/hour/min/sec or
display only in seconds. (MManage -> Menu-> Options)
Money precision and
rounding and separator are stored in
the tb_currency_precizion table, accessible from the Billing form.
MINSPEACHLENONROUTE: the minimum calculated max speechlength when the
call will be routed
There are various built-in
prepaid and postpaid payment method implemented. Payments are tracked in the
tb_invoices table and can be queried later for statistics and reports (Billing
-> Reports form)
All credit changes for
prepaid users should be logged in this user. Never modify the credit directly.
Use the “Modify” button from Users and device -> Billing page if direct
modification is required.
Invoices for postpaid user can be generated from the Billing
-> Invoices
Chargecards can be generated from Billing -> Pincodes
CallingCards:
There is a special user type
called “callingcards” but any usual user can act as a calling card.
Users can access the system
via Web or IVR typing a pincode. The pincode will represent the “pincode”
column from the user table or the username+password combination for enduser or
only the username field for calling cards.
PayPal: direct or indirect handling of PayPal payments are
supported. Search for “paypal” in the global configuration to setup. See the
FAQ for the details about the configuration.
Your users are allowed to use
e-payment and to pay directly with their credit card. Most of the
available merchant gateways are supported.
Credit Card and eCheck
processing support for every major Internet Payment Gateway using secure data
communications using up to 128-bit SSL encryption and Digital
Certificates.
The Credit Card
validity checks decrease expenses that result from attempting to authorize
invalid credit cards.
The current list of supported payment
gateways include:
3DSI EC-Linx
|
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.
If the “resellerbilling”
global config option is set, than reseller cdr records are stored in the
tb_cdrresellers and billed accordingly.
To define a “base tariff” for
the reseller the “Is Public” option is used from the “Price Settings” form
(usually applied to an “enduser cost” packet.)
This will be the prices that will have to be paid by resellers to the service
owner.
Reseller can create their base
tariff (by setting the “resellerid” in tb_billentries) usually from a web
portal. Multiple packets are allowed and packets can be assigned to other users
or resellers directly from web (in the same way like on the “Users and Devices”
form -> “Billing” tab -> Billing packet setting.
Resellers usually will create
their own price lists by cloning an existing list or their base tariff list.
For early billing set the
reseller stage field to 9.
Top reseller statistics can
be viewed on the “Statistics” form by checking the “OC” and the “PR”/”PFR”
fields.
The following features can be used to use various promotions
to (new) users:
·
First X seconds are free
You might create packets when the first few seconds
are not billed.
Just use the “Free amount” option on the Price Setup
form for this
·
Call X direction for only … cent
Just setup a separate packet with lowered prices for
this.
Use only the directions (prefixes) you wish to promote.
·
10 USD free to direction X
Set the “packetcredit” field in tb_users to 10
Create a special packet with the desired directions
(prefixes). Set the “isforpacket” field to 1 for this packet(s)
With these settings the cost of the call is calculated
with this special packet(s) and the cost will be deducted from the “packetcredit”
field instead of the real “credit” field.
·
You can offer some directions for
the users where they can call Y minutes for free
The followings fields have to be used for this from
the tb_users table:
o
freeminutes: free minutes included
o
freesms: number of free sms
messages included
o
freeminutesleft: remaining free seconds!
(this field will be modified by the server. No more free minutes when reach to
0)
o
freesmsleft: remaining free sms
(this field will be modified by the server. No more free sms when reach to 0)
o
freedirections: numbers separated
by comma or a prefix where the free minutes or sms can be used (it can be also
a whole number). Empty value for this allows free calls to all directions.
o
freedays: set to a positive value
if you wish the free minutes to be reset after this number of days (recurring
free minutes). Set to 0 to disable reset. (By reset we mean that the freeminutesleft
will be set to freeminutes)
o
freebegindt: freedays begin
date-time
For this feature to be used you might have to set the
“checkfreeminutes” global config option to 2. You might also set the “freedirections”
global config option to restrict the directions that can be allowed by the
tb_users. Freedirections field (if you let this field to be modified freely by
the users, for example to select one preferred number or destination prefix)
Example SQL to add 100 free minutes ad 30 SMS for a
set of users to prefix 4411:
update tb_users set freeminutes = 100, freesms
= 30, freeminutesleft=100*60, freesmsleft=30, freedirections =’4411’,
freebegindt=getdate(),freedays=31 where id in (X,Y,Z)
To add 10 free minutes for new users, just set the
default value for the “freeminutes” field to 10 in the database.
·
Offer some free minutes for all
new users (restricted by user IP)
There is
another possibility by restricting the maximum number of calls or call duration
from a source address by the following global settings:
o
maxcallperip: max number of calls
from the same IP
o
maxdurationperip: max call
duration from the same IP
o
maxcostperip: max call cost per IP
o
maxcallperperiod: the period for
the above (1.0 means one day)
o
maxcallperuserid: the above will
be set to this user only (set to -1 for all users)
Additionally
to IP restriction you should set as much other restrictions as possible to
restrict your server attack surface, such restricting the usage to one user
(maxcallperuserid), set user as prepaid, set max lines and daily/monthly limits
on the account as other best practices discussed in this documentation.
See the “Security and account limiting” section,
Call forward billing: 2 cdr record will be generated. A->B and B->C
Call forward from IVR: one
cdr will be generated. Whether we charge the call to the IVR or only bill the
forwarded call can be controlled by “resetdurationonfwd”
Call transfer by SIP
signaling: the second call is completely different from the first call. Billing
goes normally (2 calls)
Call transfer with dtmf (*5*):
only one call leg is billed
Conference with dtmf (*1*):
separate cdr will be generated for all call legs
Conference by sip:
technically separate calls. Will be billed normally (2 cdr)
Call forwarding from
IVR (2-leg calls):
CDR’s generated based on “ivrbilling”
global and user setting: 0: one CDR including the forwarded call, 1: load duration
only from forwarded call, 2: generate 2 CDR records (A leg + B leg), 3=both
merged,4=merged with short a-leg,5=only b-leg billing if call is connected
Ø
ivrbilling is 0: (server side) 1
CDR will be generated with total client call duration. The billing will be done
after the final called user (the IVR accessnumber when the call was not
forwarded. Otherwise the final destination number)
Ø
ivrbilling is 1: (client side) 1
cdr will be generated. The call duration will be set after B-leg call duration
and billed accordingly
Ø
ivrbilling is 2: (both) 2 (or
more) cdr will be generated (when there was call forwarding action). The 2 cdr
record can be billed separately after different billing tables
Ø
ivrbilling is 3: (both merged) 1
cdr will be generated, but the enduserprice can be loaded from different
billing tables (2-leg merged)
Ø
ivrbilling is 4: (both merged with
short a-leg) 1 cdr will be generated, but the enduserprice can be loaded from
different billing tables (2-leg merged). The A leg duration is shortened (only
the time spent with IVR until the call forward action)
Ø
ivrbilling is 5: (server side if
connected –mostly the same like ivrbilling 0) 1 CDR will be generated. If the
call was not connected then all duration will be billed (you can setup
different billing for these calls by marking the entry as “is ivr call” and set
the “called” to the access number. If the call is connected, then the B-leg
will be billed (possibly after a different billing packet)
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.
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.
Other not so important MManage modules are described below.
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
From this form, direct SQL queries
can be done against the Mizu backend. Use it carefully!
With this utility, the
conversations on Mizu gateways can be listened in real-time.
VoIP test calls can be done
here.
Upload/download files from
gateways.
Use this form to login
directly in gateways and on the server.
Database administration tool.
Only for database experts!
Direct link to the Costumers
website if you have any.
Numbers allocated by
authorities. You may add new endusers with telnumbers set to a free number from
this database. Don’t forgot to set the “free” field to 0 if the number is
allocated to an enduser.
The web interface will get
free numbers for newly registered users from this database too.
You can define tasks for
technical support with the ease of this form.
Any quick note here to be
shared between the support and admin users.
Mizu server can treat
holidays as weekend in routing and billing if the “autoholiday”
global config is set to “1”.
If the autoholiday is set to
0, than you can configure the holiday routing and billing manually (by
selecting the “holiday” pattern from the time pattern list)
In the “Holidays” Form
you can set the holidays.
The isholiday value
can have the following values:
1:
the time period is considered as holiday
0:
the time period is considered as workday (even if is weekend)
Then you must set the time
interval (fromdate-todate).
Prefixlist can contain ‘*’ or 2,3 or 4 digit prefixes separated
by comma.
If the prefix list is empty
or it contains ‘*’ than will be applied to for all directions.
Allocated and used phone
numbers can be tracked on the “Phone Numbers” form.
Numbers allocated to users or
sipproxyes must be marked (set “free” to 0)
The location can
contain the id of the user where the number belongs. This is very important for
sip proxy users where the number is not stored as the record username or number
(usually for virtual servers). If set so, the server will know where to route
the incoming call. Otherwise the routing must be configured in the MManage.
With the scheduled tasks form
you can define tasks that will be executed by the server at regular time
intervals. Two type of task is allowed: launching as program or running an SQL command.
Depending on completition the
server can initiate the following actions:
o
Send Email
o
Send SMS
o
Ring a phone number
o
Restart the VoIP service
o
Restart the SQL service
o
Reboot the server
For SQL the condition will be
success if the first field value is a positive number (first row/first col).
Otherwise (no record, null record, non number, zero or negative number) the
result will be treated as “fail”.
The following keyword can be
used with the email and sms actions:
·
SQLRESULT: will be replace with
the sql query result set (all rows and columns)
·
{FIELD}: any field returned by the
query (replace the FIELD with a valid returned field from your query)
·
{SQL}: any SQL result (replace the
SQL with a select statement like {SELECT TOP 10 * from tb_cdrs})
·
USERID: it can be used in the
above SQL to be replaced with tb_users.id if the query was against tb_users
·
***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}
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.
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.
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
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
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.
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.
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.
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).
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)
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).
The MAgent application is
used by callcenter operators as a sip client and database frontend.
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
Simple VoIP client window
where the operator are free to make calls to any number
Call to any client presented
in the central database.
Will handle calls
automatically if the operator is part of a campaign.
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!
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
·
User 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
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 endpoing
sending to different address using different via branh values)
The first session receiving
200 OK is the winner. For the others a CANCEL is sent.
Note: there are other ways to
create multi-session calls such as call rerouting, p2p, forwarding, transfer or
conference.
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.
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
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
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.
-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 *