Mizu Softswitch Administrator’s Guide VoIP Server documentation Mizu Server is a software soft switch solution
running on Microsoft Windows platforms that can replace traditional
hardware based PBX and ISDN solutions. 2010 - Mizutech 2/11/2010
This document provides an
overall technical description of Mizu VoIP platform. For non technical user guides please check out
our website. Your installation may not include all modules described in this
document and you will notice small changes if you program version doesn’t
conform with the documented version!
1.3.
Contact and tech support25
2.1.7.
Alerting and Daily report26
2.1.12. Direct
command interface27
2.1.14.
Selfcheck and reporting27
3.1. Server
configuration checklist30
3.5. Server
backup, recovery and maintenance33
3.5.2. Using
Backup database tables33
3.5.4.
Saving recorded voice34
3.5.5.
Alternative backup deletion35
4.3.15.
Callcenter Statistics57
4.4.11. SIM
Channel reservation by caller protocol87
4.4.12.
Number portability database88
4.5.8.
Invoice and payment storage99
4.5.9.
Enviroment variables101
4.8.2. Gateway
Basic Settings131
4.8.3.
Gateway Advanced Settings132
4.8.6.
Handling incoming calls from GSM network140
4.8.7.
Operator friendly gsm termination141
4.8.8. How
to setup a gateway behind a NAT*143
4.9.10.
Campaign and global settings155
4.10.3.
Calls from database165
4.10.5. Automatic
software upgrades165
4.11.9.
Call Waiting and queuing169
4.11.17.
Calling Card services175
4.11.18.
Phone to Phone (P2P) calls176
4.11.20.
Web (account access)179
5.1. How to
make a H323 call directly to a GW (without the gatekeeper) 183
5.2.
Sometimes the voice channel is breaking down. How can I improve the voice
quality?183
5.4. How
can I make test calls?183
5.5. How to
check the call quality on a specific channel?183
5.7. Server
Recovery (in a separate app and db server configuration) 184
5.8. No
incoming calls (no new calls in current call list in peak time) 184
5.9. Calls
in „routing” status185
5.10. SIP
caller cannot call185
5.11. SIP
called cannot be called185
5.14. No
voice (caller and called cannot hear each-other)186
5.15. Too
many wrong calls on a simpacket (low ASR/ACL)186
5.16. Not
enough or too many calls on a sim or simpacket186
5.17. Calls
are routed to wrong simcards186
5.20. SIM
cards with low credit186
5.21. GSM
Gateway not working187
5.22. GSM
Gateway malfunctions187
5.23. Wrong
disconnect reasons187
5.24.
MManage cannot connect to the server188
5.26.
Server software problem (service unavailable)188
5.27.
Server OS, Database or Hardware problem (server unavailable) 188
5.28. How
to restart the server service. 188
5.29. How
to restart the server box. 188
5.30. How
to restart a GSM gateway. 189
5.31. How
are the incoming calls from the gsm network handled?. 189
5.32.
Routing test calls to a dedicated gateway189
5.33. How
to disable PIN request on GSM gateways189
5.34. What
are the minimal global settings that must be correct on servers?. 190
5.35. How
to add a new traffic sender?190
5.36. How
to add a new sip enduser?190
5.37. How
to add a new Mizu VoIP-GSM gateway to the server?190
5.38. How
to add new simcards (sim packet)?190
5.39. How
to add a new simcard?190
5.40. How
to set up basic routing?191
5.41. How
to set up basic billing?191
5.42. Where
can I check the logs and traces?191
5.43. The
conversation volume is too loud. How can I change the volume?. 191
5.44. How
to register your Mizu Gateway to a H323 gatekeeper?. 191
5.45. What
ports are used in the system?191
5.46. My
gateway restarts too often192
5.47. H323
signaling problems192
5.48. How
to set up the automatic credit recharge?192
5.49. The
automatic credit recharge is not working192
5.50. How
to monitor the credit automation?193
5.51.
Gateway and channels are inactive193
5.52. How
calls are processed193
5.53. How
to set up holiday billing194
5.54. How
to treat specific weekends as weekdays194
5.55. How
the different currencies are handled?194
5.56.
SimChange settings from the command line194
5.57. How
to reenable blacklisted but good numbers195
5.58. How
are different currencies handled?195
5.60. How
the check your ASR (or ACD, SL, CDRC) for the traffic sender “A” in the last
week.196
5.61. How
to add endusers (basic settings)196
5.62. Basic
callcenter tasks197
5.65. How
to reserve GSM capacity for a certain protocoll199
5.66. PDF
creation in MManage199
5.67. How
to setup a new virtual server instance200
5.68.
Handling dynamic & private ip/port201
5.71.
Redirect or forward sessions to other domains203
5.72.
Delete old database backup204
5.75. How
to scan your SP for live numbers205
5.76.
Routing calls from virtual servers206
5.77.
Routing calls to virtual servers206
5.78. How
to add plugins in MManage206
5.79.
Request/response target address207
5.81.
Automatic prepaid credit expirity209
5.82.
Simple prefix rewrite209
5.83. Short
number and internal billing210
5.84.
Cropping sound on ring when playing voice (ringtone, announcement or any other
promt210
5.85. How
to play user credit in IVR210
5.87.
Running Mizu Server in proxy mode212
5.89.
Ringtone for IVR forwarded calls214
5.90. CLI
settings / A and B numbers / Dial plan214
5.91.
Possibile NATs and firewalls216
5.92. How
to disable CLI for all outgoing calls217
5.93. How
to change the database username/password217
5.94.
Performance optimizations218
5.95. How
to reset a failowered gateway/direction218
5.96. How
to remove the 3 digit techprefix system wide setting. 218
5.97. How
to enable H.323 modules?219
5.98. How
to add an SMS provider?219
Version
MizuServer
v4.1 Administrator’s Guide
Revisited
Febr 4, 2010
You will notice smal changes
if you program version doesn’t conform with the documented version!
Copyright
Mizu
server and other MizuVoIP software is copyrighted by MizuTech SRL. -Copyright ©2006-2010 MizuTech SRL.
This
document may not be copied or readdressed in whole or part without the
expressed, written consent from MizuTech SRL.
Disclaimer:
MizuTech SRL. reserves the right to change any information found in this
document without any written notice to the user.
License Agreement
You
must accept the license agreement (LicenseAgreement) before you use any Mizu hardware
or software component!
Trademark Acknowledgement
LINUX
is a registered trademark of Linus Torvalds in the
Windows
and Microsoft SQL Server is a trademark of Microsoft Corporation, registered in
the United States and other countries.
Oracle
is a registered trademark of Oracle Corporation.
OpenH323 (used in test tools) are licensed under
MPL: http://www.mozilla.org/MPL/MPL-1.0.html. Source code is included on
the install CD.
Other
logos, products, brand names and service names contained in this document are
the property of their respective owners (trademarks or registered trademarks of
their respective companies)
This
document describes the administration of Mizu Gateways, SoftSwitches,
CallCenters and SimBanks. A unique set of proprietary software and hardware
based capabilities and processes in VoIP network planning and network
management.
These
components are designed to cover the telecommunication needs for small to very
large companies and VoIP carriers. The main power of the system is the sophisticated
VoIP components, which are strongly used in today’s telecommunication
infrastructures.
The Mizu components can be used as standalone or as centralized
intelligent VoIP/ISDN/GSM platform, capable to handle millions of
minutes/months.
Ø MS-SQL backend (Express or
Full versions)
Ø Ethernet 10/100/1000 Base-T
Ø Static IP, PPPoE (DSL or
cable modem), DialUpISDN,VPN
Ø Encrypted communications
Ø Virtual servers
Ø STUN/ICE Support
Ø NAT Support
Ø Near-End and Far-End NAT
traversal
Ø Multi-homed and multi-domain
support
Ø 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
Ø 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 ultrawideband)
Ø G.726 (16,24,32,40 KHz)
Ø G.722
Ø T.38
Ø DTMF
Ø Custom 1 kbits codec
Ø All other codecs for
pass-trough
Ø Voice:
·
Adaptive de-jitter buffer
·
Voice Activity Detection/Silence Suppression
·
Recording conversations (In
Stereo caller/callee left/right)
·
QoS
·
Packet saver technology
Ø 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,
callernumber
Ø GeoIP database
Ø Automatic SIM allocation:
Rules can be defined on multiple levels: global,
partner, gateway, engine, simpacket, simcard, time
-Static
-will not
modify gw settings
-Limits
-sl
(day/month)
-packet
allowed intervals
-min/max
lines for partner
-Priorities
-sim
partnerm, sim, gw
-Desired
-desired
minute on packet
-packet
multiplier
-Rotate
-“minrotateival”,
“desired”, “maxrotateival”
-Price
-min/max
pricediff on obj, maxpricepermin for system/partner
-Timetable
-BRS
-LCR
-and many
other options
Ø Flexible Rate Definition
(peak/offpeak/flat/custom,
enduser/provider/reseller/sales, etc)
Ø Automatic and Real Time billing
(CDR records already includes the prices)
Ø Prepaid and Postpaid
platforms
Ø Call Credit Limit Control
Ø Unlimited reseller accounts
Ø Callshops
Ø Directions (traffic
sender,prefix,gateway,sim packet) and time based billing.
Ø Reporting and price
comparisons (LCR)
Ø Invoice generation in
different formats, PDF generation, email scheduler and invoice printing
Ø Complete call rating &
accounting services for complex rating schemes
Ø Currency and VAT can be set
for every packet. Time zone can be changed.
Ø Automatic online currency
conversion
Ø 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
Ø H.323 Standard Features
(v.1,2,3,4)
SIP-H.323 protocol conversion (Signaling and media when needed)
Ø Full H.323 proxy
Ø H.225.0 Call Signaling
Ø Fast Connect/Fast Start
Ø H.245
Ø H245 tunneling
Ø H245 in setup
Ø DTMF send/receive
Ø Watchdog
Ø Direct endpoint call
signaling.
Ø Gatekeeper routed: call
signaling (H.225.0).
Ø Gatekeeper routed: call
signaling (H.225.0) and control channel (H.245)
Ø Gatekeeper routed: call
signaling (H.225.0), control channel (H.245) and voice
Ø RTP Port Range (For
firewalls)
Ø Child Gatekeeper capability
Ø Backup Gatekeeper capability
Ø Gatekeeper clustering support
(neighbors, parent/child, alternates)
GSM
components are not included with the default standard install and the required
hardware is for extra costs.
Please
contact us about the possibilities.
Hardware Components
No
hardware components are required for H323 and SIP newtworks.
VoIP-GSM
hardware listing:
VoIP-GSM gateway
-8
channel gateway, best fit to any cheap DSL connection
-up
to 64 simcard/gateway
-SIM
server interworking capability
-Integrated
antenna splitter
SIM Server
-up
to 750 simcard
VoIP-GSM Server
-industrial
PC
-fault
tolerant
-server
failovering capability
-distributed
architecture
Built in watchdogs to monitor the operation of the
system components
GSM features
Ø Dual Band (900 / 1800 MHz or
850 / 1900 MHz)
Ø Half rate, full rate,
enhanced full rate, SMS, USSD
Ø SIM server support
Ø Integrated antenna splitter
Ø 8 channels/box
Ø Up to 8 SIM cards per engine
Ø Multiple ways to handle
incoming calls
Ø Call Forwarding
Ø Sending and receiving SMS
messages
Ø Email To SMS Feature
Ø Inter gateway SIM routing
Ø SIM server interworking
Ø GSM cell selection and
locking
Ø DTMF send/receive
Ø CLI restriction
Ø SIM Rerouting
Ø Locking to a given gsm cell
Ø Automatic SIM credit request
and charge
Ø Voice Recording and
Playback (In Stereo caller/callee
left/right)
Ø SIM server interworking
Ø Virtual Channels
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
Ø Centralized configuration
and management for all software and hardware components
Ø MManage:
o -easy to use, mdi style
o -almost every data query is
parameterized with traffic direction and time
o -all data in one place
o -lots of data can be obtained
from sl,asr,acl forms
o -global system analysis
Ø Create and edit network
elements
Ø Remote maintenance of Mizu
gateways
Ø Display of system
information
Ø Realtime call status view
Ø Service restart functions
Ø Display of the current
status of each gateway and channel
Ø Real time call supervision
(with many grouping options)
Ø Real time channel
supervision (with many grouping options)
Ø Statistics (Text based and
graphical ASR,ACD,SL, etc) on any traffic direction and time scale
Ø Disconnect Reasons (with
many grouping options)
Ø CDR monitoring, retrieval,
direct CDR access
Operator Console
Ø Global system analysis!
Ø Routing pattern selection
Ø Routing time selection
Ø Failovering (in case of
channel, gateway, direction etc errors)
Ø Best Route Selection
Ø Billing module
Ø Balance module
Ø Real Time Capacity check
Ø Ability to insert queries
directly into the database
Ø Blacklist filtering
Ø Self-analysis tools
Ø Detailed logging (multiple
levels). Detailed call tracing capability
Ø Call simulations
Ø Reseller/Agent Registration
and Management
Ø Capacity and system load
reports
Ø Import/Export from/to any
format (SQL, text, excel, etc)
Ø CRM Integration
Ø Restore and Backup
Ø 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.
Some
class 5 features will work only with SIP
protocoll
H323
GK doesn’t support username/password authentication
RADIUS
is compatibile only with some servers
Full
remote administration supported.
Continous
email support.
24/7
emergency phone support.
Visit
http://www.mizu-voip.com for more details.
Depending on licensing, some
modules may not be available in your release!
The
Mizu Soft switch (Server) is the “brain” of the system. Depending on your
needs, you can connect as many gateways as you want. Small companies can use
“all in one” solutions, where the gateway and the server are placed in the same
box. Large organizations will divide the server in multiple units, adding more
power and fault tolerance. Up to 6 gateways the server can be used with the
built-in database engine. With more gateways or users it is strongly
recommended to use one or more separate database servers (MS-SQL or ORACLE).
The soft switch is built from several modules: sip stack, h323 stack, sip –
h323 conversion module, media server, ACL, routing, billing, alerting.
The
Mizu SIP stack was written in C++. It’s very fast and robust, currently used by
voip service providers handling thousands of users.
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.
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 records after each call. Thus the billing
can work nearly real-time. (very important for prepaid systems). You can
generate various reports and invoices based on a set of predefined rules.
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 server on a single pc. These are completly
separate billing/routing/signaling entitites.
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.
Administrative
tasks and class5 service requests can be handled by the command line TCP
interface.
Template
portal is available with source code. All common enduser tasks can be done via
a user friendly web interface (new user registration, download CDR records,
show statistics, setup call forwarding, payment, etc)
Various
system tersholds will checked reltime and the server will do the corresponding
actions automatically. The same module is responsible for daily/weekly/monthly
email or SMS reports and alerts for administrators and users.
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 route the simcards in other Mizu
gateways.
Mizu
VoIP-GSM Gateways can take advantage of an external simbank, so you can have
all your simcards in one place, easing the maintenance and administration
tasks.
server service: the brain of the system
H323 GK: standard H323 gatekeeper
SIP Server: sip stack
Media Server: rtp routing
VGW: voip-gsm gateway, the most
essential part of the client
client service: this service supervises the
gsm gateway and gives a clear interface to the server
MManage: smart client software,
capable to manage the whole system
supervisor service: this service supervises the mserver
alerter
service: collects
statistical information and reports it
recplayer: can play g729, g723,
encrypted, raw PCM and wave files
loganalizer: log file parser
gwtest: handle
gsm terminal (no h323)
ipmux: packet
saver client and server
serveremulator: server
interface to gk
simalloctest: test
the automatic sim allocation
smtp_test: test
smtp functionality
tariffcalc: estimate
sim packet real price
tcperver: tcp
server for test
udptest: udp
through test
valerterclient: alerter
sw which can be installed on client computers
vchargecards: manage
chargecards
vclientinterface: platform
specific functions for the gw
partnerclient: admin
sw. for our partners
pricesettings: for
packet price configuration
routingandprices: for
config. routes, prices and sim packet priorities
servertest: brute
force test for the server
supervisor: supervises
the server
updater: automatically
updates client software from the server ftp
mediasrv: media
server for routing rtp packets
businesslgc: controls
the routing, registration, endpoint list, endpoint creation, udp initialization
VPC
Simple
monitoring software fot business purposes. Each partners (gateway or simcard
owners, traffic senders, etc) can have their own VPC to monitorize their own
traffic and create reports.
VPC
Setup
You
can give the VPC for any of your partners. The partners can login to the VPC
with they username and password configured in the “Users and Devices” form in MManage.
Usually only “Owner” users will receive VPC access.
You
can define what users can see in their VPC by setting the “Can watch sim
packets”, “Can watch users/devices” and “Access Rights” in the user
configuration form (billing tab). See section 4.3.1 for more details.
The
VPC included with MManage has the capability to login as a superuser. To do so,
you have to enter your partner username, but use the admin password (from
the “ad” account). Then you have access
to the “Add Query” button in the VPC. Here you can add,delete or modify the
existing queries and their access rights.
In
the “rights_allow” field you can put a list of user id, “all” or “nobody”
fields. The same for the “rights_deny”. Thus you can configure which partner
can see and execute which queries.
When
properly set up, Mizu software doesn’t need too many administration tasks. The
routing will adjust automatically to the external conditions. Every software
module has auto repair features. However if you have millions of minutes/month,
you may have to watch the system parameters every day.
3.1.1. Softwares
Windows
2003/2008 server, MSSQL 2000,2005 or 2008
3.1.2. Firewall
-allow
servers, FTP, IIS, MSSQL, SMTP, remote destop (3386,3389)
-block:
all others, file sharing, ms network
3.1.3. Services and memory
Autorestart
critical services
For
more than 3 Gb set boot.ini: /3GB /PAE
3.1.4. Licensing
Setup
configuration with the proper software(s)
3.1.5. Config
Setup
FTP and Voice directory NTFS access
3.1.6. MSSQL
Change
port to 2223
Disable
pipes
Check
configuration in Management Client
Skip this chapter if you are
not using VoIP-GSM gateways.
In
order to get a working system, here is a checklist which may help you:
1.
Connect the gateway(s) and/or the server to the network.
2.
Install the MManage programs in a separate PC used for monitoring your Mizu
devices. network (you can find it on the Mizu install CD which is shipped with
every product)
3.
Set up the gateway(s) and/or the server network parameters with the VnetCfg
utility
4.
Put your simcards into the gateway (see the image below)
5.
Connect to the gateway or server with the MManage (by typing its ip address and
username/password in the login form)
The
default username/password is admin/tpwdadmin
6.
Set up the basic parameters from the “Configurations” form
Be careful.
7.
Set up one ore more packets for the simcards in the “SIM Packets”
Be careful with the following settings: prepaid/postpaid, allowedpartners
8.
Set up the simcards. You can add simcards manually, but it’s easier to wait for
them to register. Then you only have to
modify its packets, owners and the recharging settings (“Simcards” form)
9. Add some traffic sender in the “Users and
Devices” form.
Be careful with the authorization settings
10.
Set up the routing (“Routing” form)
Add at least one routing pattern (name it
as you wish)
Add at least one entry to its priority
list (your newly created packet or some other direction)
11.
Set up advanced routing –Optional
Firewall, prefix rules, BRS, etc
12.
Set up the billing module –Optional
13.
You are ready to accept traffic now.
You
should check at least the followings every day:
-Current Calls –to quickly check if
you have the required amount of traffic
-GSM Channels (channels with
problems are marked with red)
-Quality Statistics by traffic
senders and terminating gateways
-Run a global system analysis
(“Analyze” form)
-Check
your cash flow (“billing” form) to check if your routing is still profitable
-Logs
(errors and critical levels)
-Analyze
your traffic by using the “Advanced Statistics” form
-Remove
blacklisted but good numbers
You
can configure your database engine to do the backup tasks. If you don’t have
this possibility, the Mizu Server can also make database backups. Set the
following configuratuions:
dbmaint_backuplevel: 0=no
backups,1=daily,2=daily,monthly,weekly,3=hourly,daily,monthly,weekly,4=keep
lots of files
dbmaint_backupdbdir:
local path (accessible for the server)
dbmaint_backupdbnetworkdir:
path accessible for the database engine (it is neccesarry when the database is
located on a separate box. Othervise can be left empty –default to
dbmaint_backupdbdir)
To
keep your active size smaller, you can move the content of big database tables
to another database. For example cdr records older than 5 month, etc. This
backup database will be easily accessed by the MManage.
dbmaint_backuptables: backup cdr records and other tables to
xxx_backup: 0=no,1=cdrs,2=extended,3=all
Frequently
used and important tables are backed up daily, the other monthly.
The
amount of data that is backed up can be controlled by the “dbmaint_removecdrs” (meassured in days. is direct proportional with
this setting)
If
the dbmaint_backuptables is set to 2, than the amount of data can be controlled
by the dbmaint_removeother value.
Logs
are removed after dbmaint_removelogs
days.
The
backup databases are created with the same name as the current database with a “backup_”
prefix.
If
you want to place the backup tables to a separate server, you must set that
backup server as a linked server in the main database and set the “linkedserver” config option in the
server inifile.
The
backup intervals can be controlled by the “dbmaint_backuplevel”
option: //0=no
backups,1=daily,2=daily,monthly,weekly,3=hourly,daily,monthly,weekly,4=full,5=keep
lots of files
(be aware that if you set it
to 0, than the other option will have no effect)
In
order to take advantage of the backup database, you must set the “Secondary
database” option in MManage to
“Autodetect” or “Secondary DB”. When set to autodetect, it will attempt to load
data from the backup database if the query date is set to more than 1 month
later (it will failback to main database if is set to earlier than 2 week). In
this case the “untill” date is modified automatically to yesterday midnight
when needed.
For
the MManage to be able to connect to the backup database, the “backupdatabaseaddress” must be set up correctly when a separate
database is used.
The
server will optimize the database engine automatically.
dbmaint_do:
enable/disable the daily and the monthly maintanance
dbmaint_removelogs:
Trunk log tables and remove logfiles after x days
Serverftpvoice:
where to store recorded audio
Serverftpdailydir:
set to true to create separate directory for recorded voices daily
Keeprecorded:
days to keep voice records
Voicebackupdir:
backup your recorded voices to this secondary location
Keepbackuprecorded:
days to keep the voice backups
The voice recording option
can be set for any user by checking the “Record” checkbox on the user
configuration form in MManage.
Conversation will be saved in
the directory specified by the “serverftpvoice” global config option.
A separate backup can be
created in the directory specified by the “voicebackupdir” global config
option.
Out of date recorded files
can be deleted by setting the “keeprecorded” option accordingly (days to keep).
Recorded files can are
compressed and encrypted by default.
On new server installation,
make sure that the voice directory are accessible via ftp for the MManage (for
listening on the “CDR Record” form). To make things easier it is preferable to
setup the ftp passwords the same as the database login.
You
can define an alternative backup deletion method by the following values:
Deldbbackup: delete old backup files after this day
elapsed
Dbbackupdir:
delete from this directory and its subdirectories
You can automate backup
cleanup by setting the following global config values:
Deldbbackup: days to keep (-1
disables cleenups)
Dbbackupdir: database backup
directory
dbdelbackupdir1,
dbdelbackupdir1, dbdelbackupdir3: database
backup subdirectories
This feature is useful, when
the database engine don’t have cleanup feature.
You
must always have a working recovery plan.
Here
is a template with dual server configuration:
if the
application server fails (the server directly connected to the internet, with
your public ip
1. call your ISP support to change the internet
cable to the backup server, and when it will be available connect to the
"backupserver" with the remote desktop "root" account
-on the backup server do the following:
2. enable the "mserver" service
3. launch the start batch file (from gk
directory)
4. check the
vservdebuglog and the MManage
if the backup
server fails (the server behind the main server, with private ip)
-connect to the main server
with the remote desktop "root" account
-On the main server, do the
followings:
1. launch the stop batch file (from the gk
directory)
2. Enable and Start the SQLSERVER service
3. Restore latest database
4. launch the start batch file
5. check the
vservdebuglog and MManage (you must have current calls)
6. you are ready
Although
the server and the gateway are PC based, you will newer have to login to the
PC. All administration tasks are done from MManage.
The
MManage program group is shipped with all Mizu Hardware components. Occasionally
you may visit our website to download the newer versions. The software is
shipped as a standard windows install package. Requirements are:
-Windows
2000/XP/Vista/Win7/2003/2008
-At
least 1024x768 screen resolution for better operation
-You
may need a headset for tescalls
-Network
connection
Double
click on the install exe and follow the instructions.
During
the install procedure the following modules
and files will be copied:
-MManage.exe
–tha main executable
-VPC.exe
–admin version
-VSQLRouter
service –for compressing and encrypting sql requests and answers
-VoIP
client programs (SIP and H323)
-Adobe
Acrobat Reader –optional (can be
canceled during the install process)
-Cute
PDF Writer – pdf printer driver used for reports and invoice pdf creation -optional (can be canceled during the install process)
-Utilty
programs: tariffcalc.exe, smtptest.exe, rptest.exe etc
-Required
dll files
-Help
files
-Uninstall.exe
-Other
files (depending of your install package configuration, OS version, etc)
When
properly installed, you are ready to login on your server(s) and/or your
gateways. If you have a central server, all administration tasks can be done
connecting only to the server. If your gateways are running without a server, you
must connect to each gateway separately for doing administration tasks.
The
following values are required on login:
App
Server: server ip address
DB
Server: databse ip address (“default” can be used if the same as “App Server”
address )
DB:
Application and database instance (because a single server can hold several
virtual server)
Username:
login name
Password:
login password
Use
encryption: encrypt and compress the server comunication (requires the “vsqlrouter” service to run)
Almost all tasks are done by selecting an item from
the left side of the main form. For detailed descriptions please read below.
In
the Menu you can find common tasks such as “Settings”, “Save As”, etc. The
selected action usually has effect only on the current active form.
From the File
Menu you can save, print or export the selected form. Usual database
operations are performed from the Edit
Menu. In the Favorites Menu
you can see the most frequently used items. In the Tools Menu you can find a set of helper applications
explained later in this document.
In the Settings
Menu the most important form is
the “Select Direction” which
will filter almost all listing used in MManage.Here you can define your
preference regarding the traffic direction including Source and Destination.
You can filter on Item Type, Item, Group, Number Prefix, Packet and SIM Card. For example you may select one SIM ID, and
when loading logs, you will see only the messages related to the selected
simcard.
In the left-bottom side of the form, you can find an
edit box used for quick search. You can use the ‘*’ character in the begin
and the end of expressions. (For example when searching for CDR records).
Most of the report will be filtered after the
selected Date Interval also.
In
the Thresholds you can set some thresholds used for MManage. This setting doesn’t
have any effects on the server or gateway. Server and gateway thresholds may be
set up from the Configurations Form explained below. In the Options Windows (still from the
Tools Menu), you can set up several important MManage parameters.
In
the Help Menu you have access
to documentation.
In the Licensing box you can see your server parameters (there is no
effect if you change these values, because these ar used only for informing
you). Depending on licensing, some
modules may not be available in your release! Occasionally you may need to
know the software version you use, which you can find in the About box.
Example: How the check your ASR for
the traffic sender “A” in the last week.
1.
In the date-time drop-down list, select the “Last Week” field
2.
In the “Select Direction” form set the “Source” (left side) “Type” to traffic
sender, and select “A” in the “Name” drop-down list (or type “A” manually)
3.
Launch the “Basic Statisitcs” form under Monitoring.
4.
Clear the “Group by” option (select the
first “-“ line)
5.
Make sure the ASR checkbox is checked
6.
Click on (Re)Load
7.
Depending on current server config and current load this query may take some
time (on a usual configuration this will take 2 second)
With
the ease of the inport –export wizard, accessible from MManage File menu, you
can import and export data from/to a lots of data formats.
The
following file types and databases are supported:
Access
Excel
DSN
CSV
Text
IBM-DB2
Interbase
MS-SQL
MySQL
Oracle
Paradox
DBF,dBase,FoxPro
Other
datasources wich can be accessed by
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
Usually
this is the most frequently used form by the technical support. You can see the status of each gsm channel on your
gateway(s).
Status
Filter:
Existing lines: List only current running
channels. (this doesn’t mean that the channel is workable. We list all channels
who have reported there status in the last 5 minutes)
Good lines: only workable lines are
listed. (ok status and with enough credit)
Credit problem: will list the channels
with low credit and when the credit request/recharge functionality doesn’t work
properly
Wrong lines: list all “bad” channels
Last week detected: all active simcards in the
last week
All: all channels including
disabled ones
Sim distribution: all existing simcards
Not used postpaid: Some simcards may not receive calls for many
days due to some misconfigurations. You may check this list occasionally to be
sure that all of your postpaid simcards are working.
Active and not used: Working simcard without
calls on it
Monitor: simcards grouped on gsm
channels. You may detect missing “holes” very easily by scrolling down this
list. This listing is almost the same as in the “Line Monitor” form.
Field
Explanations:
ID: database unique identifier
SIM ID: sim identification number
(you can find this number written on the simcard)
IMEI: unique gsm engine
identifier
Monitor: the status of the channel.
The following values are defined:
-unknown: you may have to reload
-missing: no simcard detected
-sim disabled: the “enabled” property of the simcard
is set to false. No calls are routed to that simcard.
-gw disabled: the “enabled” property of the gateway
is set to false. No calls are routed to that gateway.
-gw missing: no status from this gateway for more
than 8 minutes
-sim missing: no status from this simcard for more
than 8 minutes
-sim temp. disabled: the simcard “temporarily
disabled” property is set to true. You must reenable the simcard to receive
calls.
-gw temp. disabled:
the gateway “temporarily disabled” property is set to true. You must
reenable the gateway to receive calls.
-packet disabled: : the “enabled” property of the
simpacket is set to false. No calls are routed to the members of that packet.
-closed: the channel is in the “closed” status. Can
be for simchange or maybe is in restart.
-failovered: call quality has dropped below the
predefined values, so the sim priority is lowered
-cannot get credit: credit automation malfunction.
There are simcards from which the operator may restrict the credit request if
they have no credit. Also you may need to check the packet settings related to
the credit request. Check the logs too.
-wrong statistics: wrong ASR or ACD in that channel
in the current day
-wrong ASR: the ASR is low in that channel in the
current day
-wrong ACL: the ACD is low in that channel in the
current day
-expired: the simcard has reached the predefined
limits (you can configure this limits in the SIM Packets form)
-low credit: not enough credit on this simcard.
Check if you have enough chargecards and the credit automation is working
correctly.
-autodisabled: same as failovered
-ready (in black): no calls have been routed in the
last 10 minutes on that channel (but the simcard is working without problems)
Status: channel status as reported
by the gateway. Can have the following values: Gateway Disabled, Off (no info),
Not Active, Gateway Disconnected, Closed, Not Ready, Ready, Dialing, Ringing,
Speaking, Call Ending, DTMF, Simulating Outgoing, Simulated Incoming, Routing
to SIMID, Routing to Alias, Routing
Line: the number of the gsm
channel (usually from 0 to 7)
SimPos: the position of the active
simslot in the current engine (usually from 0 to 7)
SIM Owner: the owner of the SIM Card
PartnerID: The database ID of the
owner user
CanWatchPartnerID: database id of the partner
who can see this simcard in there VPC
Packet: the type of the SIM Card
TodaySpeachLength: the number of active
minutes on the current simcard since 00:00
ThisMonthSpeachLength: the number of active
minutes on the current simcard since the first day of the current month
ThisMonthSpeachLengthPeak: the number of minutes since
the first day of the current month in peaktime
ThisMonthSpeachLengthOffPeak: the number of minutes
since the first day of the current month in offpeak times
ThisMonthSpeachLengthWeekend: the number of minutes
since the first day of the current month in weekends
Username: Gateway Alias
Credit: current credit on the
simcards. Refreshed after all calls, and corrected after credit requests (VAT
included!)
InitialCredit: you may save the initial
credit of the simcard here
Tpercek: special field for TMobile
Tminutes
AllowedPartners: comma separated list of
allowed partners and traffic senders. ‘*’ will allow all. You may restrict the
access on gateway or simpacket level instead of setting it for all simcards
separately. Try to use the packet “allowedpartners” setting and leave it as ‘*’
for the simcards!
Prepaid: loaded from the packet
settings (1 if prepaid, 0 if postpaid)
Datum: the date when the simcard
was inserted in the database (first use)
Comment: you may place any comment
here
LastError: last error message
received from the gateway related to the actual simcard
LastLog: last log message received
from the gateway related to the actual simcard
LastFailedCalls: the number of subsequent
failed calls (not connected calls)
LastWrongCalls: the number of subsequent
wrong calls (below the predefined speech length)
LastGoodCalls: : the number of subsequent
good calls (above the predefined speech length)
FieldStrength: combination of last
reported field strength value in percent (0-100%) and the rx quality (from 0 to
7. 9 is invalid).
Value = field strength*10+rxqual (divide with 10 to get the fieldstrength. The
remaining is the rxqual)
Pin: the security code of the
simcard
LastRecTime: : the date-time of the
last message received from the simcards. Every channel will send status
messages in every 2 minutes and on status changes
LastCallerid: the destination id of the
last call attempt
LastDialedNum: the called party number of
the last call on the simcard
LastCallBegin: the date-time of the last
call attempt on the simcard
LastCallEnd: the date-time of the last
call attempt on the simcard
Enabled: set to 0 to disable the
simcards instead of deleting it
TemporarilyDisabled: you can disable the
simcard temporarily for maintenance tasks by setting this value to 1
DisabledUntil: used for automatic failovering.
If the value is above the current time, the simcard is in failovered state
DisabledCause: last disable cause
explained
ReenabledCount: how many times have the
simcard reenabled after a failover
LastReenabled: the date-time of the last
reenabling operation
TodayCallCount: call attempts from 00:00
ThisMonthCallCount: call attempts from the
first day of the current month
AllCallCount: all call attempts on the
simcard until now
AllWrongCalls: all wrong calls on the
simcard until now (speech length below the predefined value)
AbsolutePriority: if you set it higher then
on other sims, all calls will be routed here primary
Priority: routing priority boost
Filtering: determines how we check
the blacklist and the known numbers
0-no filter:
allow all numbers
1-allow
blacklist „sure” level: 0,1 and 2 (tb_blacklist)
2- allow
blacklist „sure” level: 0 and 1
3-allow only
blacklist „sure” level: 0
4-block all
blacklist
5-allow only
known numbers (listed in tb_knowngoodnumbers)
6- allow only
known numbers that are 100% ok (sure is 1 in tb_knowngoodnumbers)
Co_....: fields used by server
for fake call and sms simulations
BestDirection: used for automatic
simallocation
BestPrice: used for automatic
simallocation
EngineID: the corresponding engine
(tb_engines.id)
Credit automation related
fields:
CheckCredit: credit calculation or request/charge
operations needed
CrequestEnabled: automatic credit request
enabled/disabled (1/0)
LastCreditRequestTry: the date-time of the last
credit request command issued by the server
AllCreditRequestCount: the number of credit requests
LastCreditAnswer: the date-time of the last answer
to the credit request command
CreditRequestFails: subsequent failed credit
request. Check the credit automation logs if this goes above 3
LastCreditRequestFail: : the date-time of the last
failed credit request
ManualCreditRequestNeed: when set to 1, the server
will request the credit from the simcard in 5 minutes
ChargeEnabled: automatic recharge is enabled/disabled
(1/0)
MustCharge: when set to 1, the server will charge
the simcard in 5 minutes
LastCreditChargeTry: the date-time of the last
credit charge command issued by the server
LastChargeCardID: the database identifier of the
last charge card used for this simcard
LastChargecardPrice: the value of the last charge
card used for this simcard
CreditWhenCharged: the credit value after the last
recharge operation
AllChargeTryCount: number of charge operations until
now
AllChargePrice: the sum of the total charge card
value
FailedCharges: subsequent failed charge requests.
Check the credit automation logs if this goes above 3
LastChargeSuccess: the date-time of the last
successfully completed charge operation
LastChargeFail: the date-time of the last failed
charge operation
CreditDiffErrors: too big difference detected on sim
credit reports
Shows
the main quality parameters of your system.
CDRC:
call attempt count
SL:
speech length (duration in minutes)
ASR:
average success ration (percent)
ACL,
ACD: average call length, average call duration (in second)
You
can select any direction in the “Select Directions” Box, to check only that
specific traffic. Also there are some simple groupings available:
-No
grouping: will display the total sum. Chart views are supported only with this
option
-Group
by Called Gateway: list of destination gateway statistics
-Group
by Traffic Sender: list of statistics by source
-Group
by SIM Packet: statistics by SIMCard type
-Group
by Provider Direction: statistics by called number prefix (first 4 digits)
This
is an extended version of Basic Statistics. You can find more grouping options
here.
Additional
reports:
-ASRB:
average success ration, but here the “success” means a minimum amount of
duration. Configurable in Settings Menu -> Thresholds Box
-ACT:
average connect time. The time elapsed from setup until the connect in seconds
-PF:
profit. This require your billing module to be properly configured
-SUCC:
successful call count (same as ASR but not in percent)
-CCC:
concurrent (simultaneous) call count
-RTP:
media channel statistics
You
can make the grouping by minute in this form by checking the “on minute” box.
The
following “grouopby” options are available:
-:
display summary data (no groupby)
Caller
and Called: group by caller and called users
Caller:
group by caller (source) user
Called:
group by called (destination) user
Traffic
Sender: group by caller (source) user, but show only traffic senders
Called
Gateway: group by called (destination)
user, but show only gsm gateways
GSM
Engine: group by called gsm channels
Gateway,
Packet and SIM Card: group by called simcard (and show the actual gateway and
packet)
SIM
Card: group by called simcard
Caller
IP: group by caller ip address
Week
–absolute: group by week, but with sum (don’t groupby to months)
Day
–absolute : group by day, but with sum (don’t groupby to weeks)
Hour
–absolute: group by hour, but with sum (don’t groupby to day)
Week:
group by weeks
Day:
group by days
Hour:
group by hours
Minute:
group by minutes
Day
Compare: comapare current weekday with last week the same day
Called
SIM Packet: group by called simcards
group
Partner/Day:
group by partner and day
Partner/Hour:
group by partner and hour
Partner/Minute:
: group by partner and minute
Called
Country: : group by called user country
Called
Direction: : group by callednumber zone
Provider
direction (prefix):: group by callednumber prefix
Provider
direction (name): group by callednumber
direction
Direction
and packet: group by prefix and simpacket
Provider
direction and packet: group by callednumber zone and simpacket
By
caller root endusers: group by billed or company callerusers
Disconnect
codes in graphical form by any traffic direction.
The
server will collect the reason in the most appropriate format depending on the protocols
used. For example for a call from voip to gsm if the disconnect was caused by
the gsm party, then you will se the GSM network reason code here. Otherwise, if
the disconnect source was the caller party, and then you will see H323 or SIP
reason codes here.
The
most common reason codes are the followings:
-SIP,
Bye: normal SIP close code
-SIP,
CANCEL: the call was canceled by the caller (not connected call)
-H323,
Remote endpoint application cleared call: normal H323 disconnect
-H323,
Remote endpoint stopped calling: the call was canceled by the caller (not
connected call)
-GSM,
Normal call clearing: normal GSM close code
-GSM,
-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.
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)
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 preiod. You can restrict the listing by defining the source,
severity or filtering.
You
will get detailed system analysis in this module. Thus you can see through the
system by only one mouse click. Malfunctions are colored in red.
After every call (and SMS, etc), a new CDR is stored
in the database tb_cdrs table (and in tb_cdrresellers when the reseller option
is used).
CDR records can be filtered, analiyzed, exported and
lots of vital statistics are based on this records.
CDR records will contain the following fields:
Id: database identifier. Auto increment
Datum: the date-time when the CDR were inserted into
the database (call end time)
Callstartdate: call start time (first INVITE sent or
received)
Callenddate: first disconnect code or CANCEL/BYE
received or sent
Connectdate: first 200 OK received or ACK for 200 OK
sent
Connecttime: time elapsed until call fail or call
pickup (routing+ringing time)
Workenddate: used for callcenters and represents the
time when the operator have finished to work with the current client (CRM
updates, etc)
Realduration: speech length
Discparty: disconnect origination. 1=called or gsm,
2=caller or h323, 3=router (server)
Discreason: disconnect reason code. Explanations in
tb_reasoncodes
Callerid: caller database id from tb_users
Callerip: the origination ip
Callernumber: caller phone number (or sip username)
Calledid: called database id from tb_users
Simid: called simid (if any)
Calledline: Engine (phone line) or the called proxy
authorization id (from tb_proxyauth)
Calledip: the ip address of the called party
OrigCalledNumber: received called party number (not
modified)
Callednumber: techprefix and the normalized called
number. If the server will block the call too early,
than you may have the “origcallednumber” here (no techprefix and normalization)
DialedNumber (calleddialed): the forwarded called
number (sometimes only the “callednumber” will be
insterted here)
Rtpsent: rtp packets from caller to called. 0 if no
rtp routing. At least 1 if routed. If remains 1, then routing has failed
In
case of sip this means rtp packets received from the called and sent to caller
successfully
Rtprec: rtp packets from called to caller. 0 if no
rtp routing. At least 1 if routed. If remains 1, then routing has failed
In
case of sip this means rtp packets received from the caller and sent to called
successfully
Rtplost: lost rtp packets
Rtpcodec: voice codec name
Rtpname: used for gateways
Rtpframes: rtp payload framed in one udp packet
Signalin: audio signal strength into the playback
device
Signalout:
audio signal strength received from the audio recorder device
Jittertime: used when jitter time is reported by
gateways or softphones
Tpercek: hungarian specific. deprecated
Costprovider: call cost to the provider (ex. Tmobile)
Costenduser: cost for the caller in global currency (ex:
a sipuser or traffic sender)
Costenduseru: cost for the caller in user currency
Costsales: sales commission if any
Costcompany: price for the reseller company
Costadditional (costother): used for reseller prices
(in the main cdr)
Recfileid: if we have recorded the voice, then after
this field we can found the recorded file
Mark (marker): for special CDR records: EMAIL
(e-mail), SMS (sms), FAX (fax calls), FAIL (failowered), RER (rerouted), FWD (forwarded), TRANS (transferred), CONF
(conference), PRED (predictive) and to signal other important call types
Opworktime: used in callcenters to store the actual
operator worktime
Opwaittime: used in callcenters to specify how much
time the operator have been waiting for the current cal
Billingstep: loaded from price settings (endusercost
packet)
Unitprice: loaded from price settings (endusercost
packet)
Billingentry: loaded from price settings
(endusercost packet)
Origduration: all original duration (because the
“realduration” field can be modified on IVR 2 leg billings or when hidden
charges are applied)
Resellerid: top reseller id in tb_cdrs. Actual
reseller id in tb_cdrresellers
Accessnumber: set when the call have been made
trough a specified IVR access number
Origcallerid: used when the caller id have been
modified during the call. For example the caller can be a “traffic sender” but
after ANI or PIN authorization there is an enduser inpersonalisation
Alegduration: used for 2 leg calls (first calleg
with ivr)
Blegduration: used for 2 leg calls (seconf calleg
from ivr after callforward)
Comment: with details about the call setup and
disconnect. Can contain a shortened message exchange log.
Rtpsent and rtprec is 0 when
media routing has failed (if we don’t route the media, or the terminating
endpoint don’t send media info to us, the system will set there values to 1, so
this condition will be true)
All prices in the cdr
records are calculated with VAT included!
Duration
lists of several traffic types.
Statistics
related to callcenter operations: Campaign and operator statistics.
StartTime: operator first login in TAgent
in the current day
EndTime: operator last seen time in
the current day
WorkTime: time when TAgent was
running
ActiveTime: time when the operator is
in “Automatic Call” form and not paused
OpWaitTime (WaitTime): the time elapsed from a
new call request untill the first call connect. Smaller times represent more
effectiveness. (the reason for the predective dialer is to reduce this time to
minimum). The value will be stored for each connected cdr record.
OpWorkTime (PTime): The time elapsed from
hangup untill new call request. This will represent the time spent by the
operator for data postprocessing. Quick operators will have smaller opworktimes
(but can be affected by the ammount of data to store) . The value will be
stored for each connected cdr record.
TotalWorktime: Tagent runtime in that day
ActiveWorktime: When the automatic dialing
form is active and not in paused
Called: number of called clients
Completed: clients marked as
completed. Useful for meassuring the operators effectiveness.
Invited: clients marked as invited.
Useful for meassuring the operators effectiveness.
Recalls: clients marked as need
recall
CDRC,SL,ASR,ACL: traditional statistics.
More details here.
This form will allow to manage the users of the
system (Endusers, SÍP users, Administrators, Tech. Support users)
You can list
the users with the following filters:
-ActiveNow: gateways with received status in the
last 5 minute or endusers active (register or invite received) in the last 3
hour
-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
ID: database id. Auto increment
Type: user type
0=enduser
(usually a sip user). Operator if isoperator set to
1, power user if set to 2, calling card when set to 6, enduser if 0
1=reseller
company (usually a sip reseller)
4=sim,gw or
traffic owner (sim partnerid or gateway
parentid show this id)
5=traffic_sender
(parentid can be a simowner or a gatewayowner)
6=sales (parentid is the reseller id)
8=gsmgw, (parentid is the
gatewayowner)
9=sipproxy, (parentid is the gatewayowner)
10=h323gw, (parentid is the gatewayowner)
11=isdngw,
(parentid is the gatewayowner)
12=sms,
fax,email gateway
14=support
(can operate with MManage, has ftp account)
15=admin (can
see and modify everything)
ParentID:
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 userid separated by comma (all
number will ring when the actual user will be called)
BelongsToCompany: when a company has more then one
subscriber. Used for example for short sip numbers.
IsCompany: if the current user actually is a company
RGMode: how to use the ringgroup: 0=forked call,
1=round robin
Name: user first an last –name
Country: sip phone country (important for prefix
rules)
ContactName: additional name
UseCallingCard: if has calling card (usable with pin
codes)
CanDial: example: for sipuser is 1. for simowners is
0
Phone: user phone number (but not the sip phone)
Email: where the user can be contacted
Address: where the user can be contacted
Billaddress: where to send the invoices
TelNumber: sip telnumber.users can be contacted if
we call there username or telnumber
ShortTelnumber: sip short telnumber (for example if
several users has the same BelongsToCompany field)
DisplayName: how the user will be displayed. Can be
null
Username: the most important field. Used in
authentification.
Password: password applicable everywhere (sip, web,
VPC, etc)
Ip: sipphone, sipproxy or gsmgateway ip address. The
server will overwrite with the last known ip address
AuthIp: if we want to authenticate after ip, not
after username/password
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
AddDate: when the user has been inserted in the
database
Rights: rights on user interfaces
0: no access
10: cannot login (disabled)
20: can login but no rights
30: a normal user
40: sales
50: admin
60: general admin
AddedBy: the user id who have added this user
(sales, web registration, etc)
Commission: used for sales to define their comission
percent from the enduser price
Reduction: sales user can give to enduser some
percent (substracted from their comission)
LateFee: applicable when the user is late paying the
invoice cost
PacketID: billing for users, traffic senders
BillingDay: usually 1 (the first day in every month)
Qualification: the importance for the user. From 0
to 10. for example if the user has big priority, then we route its calls to
better routes
Postpaid: if the user will prepaid or postpaid
PaymentMode: Check (0), Bank Tranfer (1), Cash (2),
Else (3)
ContractNumber: contract for end-users
Allowedpartners:
Allowed traffic senders for
the gateway, or allowed gateways for traffic senders.
A list of user id searated
by comma or ‘*’
Note that parent users will be checked too
Enabledprefixes: can be one prefix (with any length)
or a list of prefixes with 3,4 or 5 digit separated by comma.
Can
be used for trafic senders and gateways too. No need to setup a separate
routing pattern if you use this restriction.
EnabledTechPrefixes: enabled techprefixes for the
specified gateway (3 digit length numbers separated by comma)
BlockPrefixes: list of called prefixes that will be
blocked for the user (techprefix will not be considered here). Numbers listed
here must have 7 digit
length and separated with comma.
ContractState: the status of the contract
0-
Unknown
1-
Not applicable
2
-In Progress
3 -Active
4 -Terminated
ContractComment: additional comment for sales
Credit: when postpaid, then we also can set a max amount
(which will reset in every month)
Enabled: if disabled, it behaves as if it were deleted
DomainName: sipproxy domain name
Port: signaling port
TransIp: secondary signaling ip
TransPort: secondary signaling port
RouteRtpCaller: routing mode if this endpoint is the
caller
0=check called
settings –this is the preferred settings
1=don't touch
the sdp and the rtp
2=sdp correction
if necessary
3=route rtp if
both behind nat
4= route rtp
if caller is behind nat
5= route rtp
if called is behind nat
6= route
rtp if any endpoint is behind nat
7=always route
rtp
RouteRtpCalled: routing mode if this endpoint is the
called
0=check caller settings
1=don't touch
the sdp and the rtp
2=sdp correction
if necessary –this is the preferred
settings
3= route rtp
if both behind nat
4= route rtp
if caller is behind nat
5= route rtp
if called is behind nat
6= route rtp
if any endpoint is behind nat
7=always route
rtp
Rtp settings
will be checked first for the called and then the caller (so if the caller RouteRtpCaller settings is not 0, then
it will overwrite the called RouteRtpCalled settings)
RtpIp: last rtp ip
RtpPort: last rtp port
ServerRtpPort: last bind (we try to use the same for
every user)
NatDetected:
0= no and don’t change, 1=no but can be changed, 2=yes but can be
changed, 3 yes, and don’t change it
NatDetectDisabled: deprecated
Status: 0=inactive,1=registered, 2=speaking (if
statusdate is too old, then treat as 0)
StatusDate: last status change
CalledNumber: last called number
CalledID: last called id
Discount1: discount percent. users can have
discounts in for max 3 directions
Direction1: prefix. users can have discounts in for
max 3 directions
Discount2: discount percent. users can have
discounts in for max 3 directions
Direction2: prefix. users can have discounts in for
max 3 directions
Discount3: discount percent. users can have discounts
in for max 3 directions
Direction3: prefix. users can have discounts in for
max 3 directions
TechPrefix:
The server can authorize
and/or route the traffic after the incoming techprefix.
Sip users can have
techprefixes too. this is usually common for reseller company users.
If no techprefix is
specified, then it will be loaded from tb_pxrules if any.
Sim owners and vpc users can
have a list of prefixes separated by comma.
If no techprefix is
specified, 111 will be inserted for incoming called numbers.
If the techprefix is „-1”,
then the original techprefix will be forwarded.
If the techprefix is „-2”,
then the original techprefix will be inserted in cdr record (but not forwarded).
If the techprefix is empty,
then only the normalized callednumber will be forwarded.
The following techprefixes
are reserved for the server: 111,222,999.
Only 3 digit techprefix is
allowed. If your
traffic sender needs another techprefix length, you must rewrite the incoming
number in the “Prefix Rules” form.
Example: protcoll: sip, Type: ip,
value: your traffic sender ip, rewritefrom: oldtechprefix, rewriteto:
newtechprefix.
Addtechprefix: we insert this number before the
callednumber if the caller don’t send its calls with tech prefix
MaxLines: max concurrent calls allowed
maxlinetouse: deprecated
CurrCallCount: current running calls (usable for traffic senders)
enablefakegw: if we don’t have capacity, we can
route h323 calls to a fake gateway to prevent congestions
candisablesim: if the router will check the disableduntil
field from tb_sims
alarmat: we can ring the sipuser if it is set
forwardonbusy: telnumber where we have to forward
the calls when busy
forwardonnoanswer:
telnumber where we have to forward the calls when we have no answer
forwardalways: rerouting
voicemail: if we can send messages as email
mincreditonroute: if user has less credit, then we
don’t even route the call
regtimeout: reregistration interval for sip proxies
maxsubsfail: we set the „nopriority” field when we
reach „maxsubsfail” failed calls
subsfails: successive calls with duration smaller than
20 sec
nopriority: this gateway has lowered priority in the
routing until this date
noprioritycount: successive lowered priority
countminasr:
minasr: minimum asr before failovering
minacl: minimum acl before failovering
mincallcount: min. Cdr records to calculate minasr
and minacl
lastrouted: last call time (applies to caller
devices and users or to callers when it is a proxy)
lastcalled: last call time (applies to called devices and users)
active: applicable for gsm gateways.
display: text to display instead of username
description: important comment
comment: any comment
lastrectime: last status receive from this gsm
gateway
realgw: we can have fake voip-gsm gateways
temporarilydisabled: gsmgw is temporarily disabled
onlytestcalls: we allow only calls with techprefix
999
testprefix: we allow only this techprefix
datum: when the user has bee inserted into the
database
mustbeactive: if the gsm gateway must be active.
Will do actions if this field is 1 and the gateway is not active
notactivecount:
how many time we found that the gw is not active
channelcount: gsm channel count
minline: minimum active lines. If we found less line
active, then we do actions
nominlinecount:
: how many time we found that the
gw has not enough line
prioritypartner: this partner will have priority on
this gateway
callerpriority: this caller prefix will have
priority on this gateway
calledpriority: this called prefix will have
priority on this gateway
autopriority: set by server. If the gateway is
wrong, then we lower the priority until this time
absolutepriority: if we set it greater then for
other gateways, all calls will be routed here, until it is filled, regardless
to other routing settings
priority: gateway priority
swversion: gateway sw version
lastrestart: gateway last restart
cutg711: if a better codec exists for the caller
(g723 or g729) than PCMU and PCMA will be not offered to the called party
pingtime: deprecated
avgkbitssec: deprecated
maxkbitssec: deprecated
bandwidth: deprecated
restartcount: gsm sw restart count
pcrestartcount: gsm gw (pc) restart count
lasterror: last error message from this gw
lastlog: last log message from this gw
sendonlyrec: where to send sip messages.
0 = received address and the
address in the signaling
(via,contact,etc)
1=send only to the source
address
2=send only to address
specified in the signaling
callsigaddr: h323 port
isfake: we can have fake voip-gsm gateways
forwardearlystart: if we can send media parameters
before callstart (OK for INVITE). 2 if check called
changesptoring: if we have to change the session in
progress message to ring. . 2 if check called
identityforward: we can toward these kinds of
usernames and the other we rewrite to „identityrewrite”
identityrewrite: if the caller username don’t match
the identityforward prefix, then we rewrite it
PlayAdv: if we can play advertisements for this user
Maxmonthlycredit: max allowed credit/month even if
the user is postpaid (in ft not in filler)
Maxmonthlycreditend: max Maxmonthlycredit (because we increase Maxmonthlycredit by
maxmonthlycreditinc every month if the user was active)
onlylocalaccess: traffic sender traffic will not be
forwarded (can call only local users from tb_users and tb_numbers)
Maxmonthlycreditinc: determines how much money we
add to Maxmonthlycredit every month
ContractNumber:
Contact Status:
0-Unknown
1-Not applicable
2-In Progress
3-Active
4-Terminated
Contract comment: any usefully comment for sales
here
Noanswertimeout: will redirect if no answer received
Denyaddr: because the server will try to send the
sip messages to all possibile addresses, sometime it will missroute. With this
setting you can restrict the address posibilities. Check the FAQ for more
details.
sendfakealert: used for gsm gateways. Specifies the
timeout in sec after that the gsm gateway will send an alert to voip even if no
ringing have been received from gsm network. Set to 0 or -1 to disable. Gsm
gateway settings will overwrite the traffic sender settings if is not set to -1
sendsmsalert: use for support and admin acounts.
Will send sms notification to the configured “phone” when a critical error
occurs
sendemailalert: use for support and admin acounts.
Will send email notification to the configured “email” when a critical error
occurs
sendsmsreport: daily sms report for support and
admins
senddailyemail: daily email report for support and
admins
convertdtmf: applicable for sipproxy users
-0: DTMF messages will be
forwarded as received from client
-1:
INFO and RTP DTMF messages will be converted to InBand
-2:
INFO and RTP DTMF messages will be forwarded and converted to InBand too.
-9:
don’t forward INFO
sendmonthlyemail: monthly email report for support
and admins
Missed by SMS: notify about missed calls by sms.
Usually used for endusers
Missed by Email: notify about missed calls by email.
Usually used for endusers
Can watch sim packets: list of packetid separated by
comma, used for VPC access. The actual partner can see this simpackets with his
VPC account
Can watch users/devices: list of users and gateways
id separated by comma, used for VPC access. The actual partner can see this
devices with his VPC account
Access Rights: specify wich fielss are allowed for
the user in the VPC application
0:
simcard and traffic sender fields are not shown
1: simcard
related fields are not shown (simid, packetname)
2:
traffic sender related fields are not shown (name, username)
3:
all fields are shown
CLI: CLIR
and CLIP settings
0:
forward always (forward asserted as normal number always!). will not hide, even if caller was set so
1:
normal handling (forward asserted as normal number) -default
2:
forward as asserted identity always (identityrewrite asserted)
3:
forward as asserted identity only to trusted domains (identityrewrite
asserted)
4:
normal hide (no idenityrewrite forwarding)
5:
force hide (no asserted identity too!). always hided
IsOperator: specif if the user is a callcenter
operator (1) or a normal enduser (0) or
power user (2)
Choosecodecs: list of supported rtp payload formats
in priority order separated by comma. Only one will be selected. Don’t set this
field to disable
selecting
only one code.
If set, than only one codec will be left in
the sdp (plus the dtmf codecs). This will help, when the server answer to
invitation with more than one codec in the 200.
The client should answer with the final codec
in the ACK, but many endpoint fail to do so.
SessionTimer: use session keepalive.
-0: don’t use
-1: load from global config
-2: autodetect (and using the sesskeepalive interval
from the global configuration)
-Other: use with the specified timeout (minutes)
For example if
we set it to 5, than a UPDATE or reINVITE will be sent in every 5 minute to the
other party. Please note, that the session keepalive is not the same with NAT
keepalive (wich is used with every endpoint automatically)
Default users:
Owner mycompany: template for owner
GsmGw LOCAL_GW: used for advanced gateways.
IP=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
Administarton
of Mizu Gateways, Other GSM Gateways, H323 Endpoints, SIP Proxies, ISDN
Gateways and other compatible devices.
The fields are the same as for the Users (see above)
If the actual
sipproxy require authentification, then we store the accounts in this table
Id: database identifier. Auto increment
Priority: Account priority (accounts will be used in
priority order or in round-robin if they have equal priority)
Username: sip username used in authentification
Password: sip password used in authentification
CallerNumber: usually the same as username. If left
as blank, then the server use the actual caller username.
Credit: account balance. When it reach 0, then we
switch to the next account if any
DateEntered: record insertion date
LastUsed: the date-time when the server was routed
some calls with this account
ProxyID: to which proxy the account belongs
Enabled: set to 0 to disable the usage of this
account
SubsFails: the number of subsequent wrong calls with
this account. If subsfails will reach a predefined value (30 as default), it
means that there is some problem with this account or the money/time limit have
been expired, and the server will switch to the next account if any
Grouping
of several items will ease the administrations tasks. The following type of
items can be grouped:
SIM
Packets
Users
Gateways
Traffic
Senders
Useful
when you have arranged your users in certain hierarchies. For example reseller
chain relationship.
Resellers can have an unlimited
child-parent relationship (limited by the ”maxresellers” global config
options).
To
define the relationships we use the tb_users id and parented fields.
Registration and authentication
User
authentification can be done multiple ways (AuthType field in the user table).
Registration
and authorization answers are cached in the Mizu server, so for subsequent
requests from the same ip:port doesn’t have to query the database again. This
means that if you change the password in the database it may take some time
until it is considered.
Mizu
server has built-in DOS attach protection. This means (among others) that after
a few unsuccessful registration (wrong password) request from a UA, that will
be banned for a time. This banned list can be cleared from the server console
with the “delbanned” command. Even whole IP ranges can be banned. For example
if there are too much meaningless or not authenticated request from an IP
address (probably the attacher), than that IP address will be banned for a time
period and the incoming messages from that IP will be silently dropped.
Users
and devices will be allowed to access the system (and create new dialogs) only
if they pass basic authorization which can be set from MManage -> Users and
Devices -> Edit tab.
For
IVR access the server will authenticate the actual enduser based on the A
number or will request a PIN code.
Basic authorization
Dialog
authentication can be performed in the following ways:
-Open
Relay: if you set the NeedAuth to 0 for a user, then your server becomes an
open relay (this is forbidden by the “enforcestrongauth” global config by
default)
-Authentication
based on IP address: for this you have to set NeedAuth to 1 and enter the peer
IP address in the AuthIp field (can be a list of ip address separated by comma).
Instead of IP address you can also use a domain names here.
-Authentication
based on tech prefix: this is mainly used in h323 network. Set the NeedAuth to
2 and enter a valid techprefix for the user (which is usually a traffic sender)
-IP
and techprefix: NeedAuth must be set to 3. The “TechPrefix” and “AuthIp” fields
must be set correctly
-Username/password
authentication: usually for your sip endusers. NeedAuth must be set to 4.
Username and password fields must be
accordingly
-Authentication
based on username: A number authentication. NeedAuth must be set to 5 and with
a valid username
-IP
and port based authentication: gives you better security than just IP
authentication and also it is useful when you have more traffic sender from the
same domain. NeedAuth must be set to 6. Port and IP have to be set accordingly.
(port is stored in the callsigaddr field in tb_users. You need to edit it if
needed)
-Username
and IP: both username and ip authmust match
*SIP endusers are usually
authenticated based on username and password.
*Traffic senders (carriers)
are usually authenticated based on IP address.
Access numbers
Access
numbers are special users. You will have to create them like usual users but
their ivrid have to be set to a valid campaign id. (which is then linked with
an IVR script)
For
callback access you also need to set the “iscallback” user field properly. Read
the “callback” services for more details.
IVR authentication
For
IVR calls the server will do a “callingcardauth” global config option based
authentication.
Please
note that in this case the caller device is already authenticated based on
basic authorization settings. The IVR needs to find an enduser to allow further
operation, like call forward.
The
server can authenticate the user based on the following methods:
Ø ANI/CLI authentication: if
the CLI is known and this method is allowed.
A
number authentication can be used to try user authentication for a call coming
from a traffic sender. If user is found with the actual A number then the
caller will be authenticated as the enduser, othervise will be authenticated as
traffic sender. In this case you can require a PIN number from the user.
Configuration
options:
anumberhandling global configuration
·
0=disabled
·
1=only add
·
2= only accept
·
3=add and accept (default)
·
4=only a number access (no pincode request)
enableanumberlookup per user configuration. You
need to set it to 1 for traffic senders.
A
numbers can be also registered by the users on a web interface or by sending an
SMS in the proper predefined format.
Ø PIN (calling-card) based
authentification:
When
the A number is not known or the A number based authentication is disabled, the
IVR have to ask the user for a valid PIN code.
This
can be done by the CallingCardAuthentication IVR action.
After
the server collects the DTMF digits it will lookup the database for a valid
user entry. The authentication can be based on username, password or
username+password or depending on the “callingcardauth” global config option which can have the following
values:
·
0=calling card username or any user username + password or username +
pin (default)
·
1=callingcard username
·
2= callingcard password
·
3= callingcard username+password
·
4=any username
·
5=any password
·
6=any username+password
·
7=any username+password or username+pin
·
8=username for callingcard and username+password or username+pin for
other users (default)
·
9=pin
·
10=password or pin
User
rights
User
rights can be further restricted by several configuration option.
The
most useful tool for this is the routing
table. You can define were a certain user or a user group can initiate calls.
The
following restrictions can be applied per user:
Allowedusers: list of the users or
groups (prefixed with 'g') that is allowed to call the user. This can be used
to restrict the access to an access number for example.
AllowedPartners: comma separated list of
allowed partners and traffic senders. ‘*’ will allow all. You may restrict the
access on gateway or simpacket level instead of setting it for all simcards
separately. Try to use the packet “allowedpartners” setting and leave it as ‘*’
for the simcards!
Enabledprefixes: can be one prefix (with
any length) or a list of prefixes with 3,4 or 5 digit separated by comma.
Can be used for trafic senders and
gateways too. No need to setup a separate routing pattern if you use this
restriction.
EnabledTechPrefixes: enabled techprefixes for
the specified gateway (3 digit length numbers separated by comma)
BlockPrefixes: list of called prefixes
that will be blocked for the user (techprefix will not be considered here).
Numbers listed here must have 7 digit
length and separated with comma.
MaxLines: max concurrent calls
allowed (separate value for peak or offpeak)
Maxmonthlycredit: max allowed credit/month
even if the user is postpaid
Maxmonthlycreditend: max Maxmonthlycredit (because we increase Maxmonthlycredit by
maxmonthlycreditinc every month if the user was active)
Onlylocalaccess: traffic sender traffic
will not be forwarded (can call only local users from tb_users and tb_numbers)
Maxmonthlycreditinc: determines how much money
we add to Maxmonthlycredit every month
Access Rights: specify wich fielss are
allowed for the user in the VPC application
0: simcard and traffic sender fields
are not shown
1: simcard related fields are not
shown (simid, packetname)
2: traffic sender related fields are
not shown (name, username)
3: all fields are shown
Global configuration options:
MAXSPEACHLEN: max allowed call duration in sec
allowedusers: max ring time in sec
callmaxwait: max waittime allowed for
operators between calls (for administrative purposes)
enforcestrongauth: enforce authorization and
strong passwords
Try
to avoid prioritizations by users, gateways, simpackets or channels
(absolutepriority, priority, allowedpartners, prioritypartners, etc)
Almost
all kind of configuration can be set up by using only the “routing” form.
The
firewall rules are checked first when a call are initiated (SETUP or INVITE
received), so this is the most effective way to block some unwanted traffic
sender.
All
ip address are allowed except those are listed if the ip with ‘*’ is 1.
Otherwise
(if the ip ‘*’ is set to 0) all address are blocked except those that are listed here.
During
the routing process you can modify the caller and called number with the
dialplan stored procedure (v_dialplan)
v_dialplan
can be called several times during the routing depending on the
checkdialplan1-4 global config option.
For
CLI and A number rewrite it is enough to set checkdialplan4 to true (after
routing) and check/rewrite the numbers using the LIKE operator (wildcards are
enabled).
Input
parameters:
@calledat TINYINT, /*1=first check, 2=after
authentication, 3=before routing out, 4=after routing out*/
@protocoll TINYINT, /*0=SIP, 1=H323, 2=GSM,
3=Other*/
@fromip varchar(22), /*caller ip address*/
@fromport SMALLINT, /*caller port*/
@callerid int, /*caller device database id from tb_users*/
@callernumber varchar(35), /*caller number or
sip username*/
@callername varchar(35), /*caller name or
displayname*/
@calledid INT, /*called device database id from tb_users*/
@origcallednumber varchar(35), /*called number as
received*/
@techprefix VARCHAR(10), /*called number
tech prefix*/
@normcallednumber varchar(35) /*normalized (changed) called number*/
Some
of the input values are not set at earlier stage. For example when calledat is
1 then the callerid will be 0 because the caller is still not know at this
stage.
Usualy
only the called number have to be rewritten, but you can also change other
values.
Accepted
output values:
-emty
string: no effect
-_REJECT:
will disconnect the call
-callednumber: will change the called number
-callednumber,origcallednumber,techprefix,callernumber,callerid,calledid
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