Contents
About 3
Quick setup. 3
Features. 3
Requirements. 4
Install 5
Configuration Wizard. 5
Troubleshooting. 6
MizuManage. 7
User Management 8
SIP Servers. 9
SIP Clients and Trunks. 11
Outbound Routing. 12
Inbound Routing. 13
CDR. 14
Statistics and Monitoring. 14
Start/Stop. 15
Upgrade. 15
Backup/Restore. 15
Settings. 16
Global Configuration. 16
Change SBC IP address. 17
Change SIP server address. 17
Ports. 19
RTP Routing. 20
SBC behind NAT. 20
Calls between endusers/extensions. 21
Multiple registrations and call fork. 22
Codec. 22
Transcoding. 22
Call recording. 24
Chat recording. 25
WebRTC. 26
Push notifications. 26
API 27
Logs. 27
Security. 27
High availability. 27
Extra features. 28
Resources. 30
About
The Mizu SIP SBC is an easy to use software solution to control SIP signaling
and media streams capable to enforce security and to perform various tasks such
as validation of SIP sessions and NAT handling.
The SIP SBC can be installed on
Windows operating systems and runs as an NT service.
Usage instructions in short:
1.
Download the
installer (the free/demo version can be downloaded from here) and install it on a Windows machine
(you can also use a virtual server or VPS)
2.
Launch the
MManage admin client (might be launched automatically by the installer) and follow
the Configuration Wizard (can be found from the Config menu if not started
automatically).
Take special attention at the Network
page (configure with the correct IP address) and SIP Server page (enter the
correct details about your SIP server, you will be able to add more later)
3.
Enable the main
executables on the Windows firewall: mserver.exe, mserverftp.exe, pushkit.exe,
lego.exe.
If you are hosting the SBC behind NAT
and peers will be located on outside network (like softphones connecting from
the public internet), then configure port forwarding on your external router or
NAT device for the ports listed at Config -> Network -> Active ports.
4.
For a quick test,
configure two softphones (use the gateway domain or IP:port as the SIP domain
or outbound proxy setting) and make a test call.
The most important features are
listed below:
·
GUI: comfortable graphical user
interface for configuration, management and monitoring (real-time, CDR's,
statistics)
·
NAT: the SBC has built-in NAT traversal,
support capable to gracefully handle all types of NAT's, firewalls and routers
·
Security: DoS and DDoS attack protection with
intelligent firewall, topology-hiding, access control, call limits, rate
limiter, stream and session protection, blacklist, fraud call detection and
various other thresholds
·
Internetworking: compatible with all SIP devices,
will resolve any incompatibility issues between devices.
·
Routing: intelligent routing of calls can be
done by various rules such as priority, quality and load-balancing
·
Failover: it can detect failed servers and
reroute the calls to others or automatically temporarily disable servers
·
RTP relay: bypass, route or off-route the
media with various enhancements such as NAT handling, QoS and stream control.
It can be set to automatic (will route the media only if necessary) or enforced
by manual settings
·
Transcoding: transcode between various codec's
such as Opus, Speex, G.729, G.723, G.711 (PCMU/PCMA), GSM, iLBC (this is done
automatically by default only when necessary and can be overridden manually)
·
Optional
modules: billing,
user management, registrar, class 5 features, WebRTC-SIP, push notifications, tunneling,
high-speed load balancer (up to 2 000 000 simultaneous calls!)
Contact us with any questions at info@mizu-voip.com.
The mizu SIP SBC can be installed on
any server or PC running Windows OS.
·
OS: Windows
Server 2003/2008/2012/2016/2019/2022 (Windows XP/Vista/7/8/10/11 for home usage
or testing). Both 32 and 64 bit versions are supported. You can use the cheap
Web edition license.
·
CPU: a cheap dual
core cpu for less than 500 parallel calls, a best-buy 4+ core CPU for less than
2000 parallel calls or a high-end CPU for more.
·
RAM: 1 GB RAM for
less than 500 simultaneous calls, 6 GB RAM for less than 2000 simultaneous
calls or 8+ GB for more.
·
Disk: 60 GB HDD (or
more if your traffic is high and wish to store all CDR's or more logs or voice
recording)
Example hardware for 30000 users with
2000 simultaneous calls:
o a best buy 4-8 core AMD Epyc or Intel
Xeon such as Xeon E5-2665 which costs only ~$90
o 8 GB RAM
o 80 GB HDD
We recommend to host the SBC
service on a server with a public static IP, using standard ports (80 for HTTP, 443 for
HTTPS/TLS, 5060 for SIP, 5061 for SIPS).
In case if some other app
on your machine is already listening on these ports then you should stop the
app if unnecessary or otherwise configure your gateway to bind to another IP
(if you have multiple IP addresses) or otherwise configure other ports to be
used by the SIP SBC.
The SIP SBC has a
standard easy to use installer.
Quick tip before to start
the installer: Windows servers might have IIS running by default. Stop it if
not needed (World Wide Web Publishing Service from Services).
1.
Download the SIP
SBC installer from here
2.
Double-click to
start the install process and follow the instructions (requires Administrator
rights)
3.
Once the install
completes, it should automatically start the Admin client with its
Configuration Wizard. This is discussed in the next chapter.
For the basic server configuration you
should walk through the detailed configuration wizard which is started
automatically at first usage or accessible from the “Config” menu.
Don’t change any setting that you don’t
fully understand, just click on the “Next” button in this case. Most of the
settings are self-explanatory with a short description near them and/or a hint
if you hold the mouse over a control.
Pay special attention to the
“Network” and “SIP server” pages:
·
on the Network page enter the
correct IP and NAT configuration ("offer services for")
·
make sure that the ports used by
the SBC (SIP port, Access port, Secure port) are not used by some other
application such as a local web server (in this case either change the SBC
ports or the third party app port or bind them to separate IP address)
·
on the SIP server page enter your
PBX/Softswitch details (later you can add more SIP
servers if needed)
Click “Apply” on the last page to save
the configuration. Check the displayed messages and instructions.
If you select the “(Re)Start the server”
checkbox, then the SBC service should start automatically.
Otherwise start it from the “Control”
menu or use the Windows Service manager and start the “mserver” service.
When you start the service for the first time, it is a good idea to open the
“Analyze” form to check for any potential issues.
Once the service is started, you can
connect with SIP clients or trunks and make calls.
Once the SIP SBC is installed and configured
correctly, there is nothing much to manage as it has full auto-management
capability (such as auto deleting log files, auto fine-tune to your hardware,
automatic user management and others).
If you can’t connect/register or make
calls, check the followings:
·
Make sure that the service is
actually started (check the “mserver” service status in Windows Service
manager)
·
Look for any issues from
MizuManage:
o Have a look at the “Dashboard” form
o Open the “Analyze” form and click on the “Analyze”
button to detect potential issues
o Check any important errors or warnings on the “Logs”
form
o In case of call failure you can check the disconnect
reason from the “CDR” form
·
Make sure that you have basic connectivity
to the important ports such as SIP signaling 5060 and RTP ports
·
Install a SIP softphone (such as X-Lite or MizuPhone)
on the same server where you are running your SBC and make sure that you can
make call to your SIP server from there.
·
If you are making call to a user/extension,
make sure that the called user is registered when you call it
·
If you don’t hear any voice or
there is one way audio then you might change the RTP routing for the user(s) to
“always route RTP” from MizuManage -> Users and devices -> Edit tab or
globally from Config menu -> Configurations -> RTP Relay -> Route.
o Check if there is any firewall blocking the required
ports and if your NAT device/router/firewall correctly forwards the required
ports (Config menu -> Network -> Active ports)
·
Verify the log files. You can find
the logs in the server app folder (near the mserver.exe) -> “logs” subfolder.
You can also open the folder from MManage -> Files Menu -> Folders ->
Server logs.
o In case if you
are using push, then you can find the register from the users by searching for
the followings in the log:
§ EVENT,creating new
registrar server with usr: USERNAME
§ EVENT,reuse registrar
endpoint for USERNAME with callid X
§ EVENT, (fast) new reg
userobj from IP as reg from USERNAME
§ EVENT, (fast) reg
send to USERNAME Welcome back
§ EVENT,force unreg
from upper server USERNAME
o Open the last log file
(“log_xxx.dat”) with a fast text viewer (For example F3 from Total Commander).
To find application errors, open the last log file in the server app directory
and search for “ERROR” and “WARNING”. To find a call, search for “INVITE sip:callednumber”.
o You can modify the trace details with the “loglevel”
configuration option: from 1 to 5.
o Use some network capture tool (such as Wireshark) for further troubleshooting.
·
Contact Mizutech support if the problem persists and you have or wish to buy a license
All administration and monitoring
tasks can be done from the MizuManage (MManage / MizuManagement) admin
client, which is included in the SIP SBC install package.
Using the SBC, you will still need to
use your Softswitch/PBX to manage your Users (authentication, authorization,
and accounting), Routing and any other aspects of your network.
Regardless of this, the SBC also
provides you complete monitoring and GUI based configuration managements, so
you can easily change settings or find connectivity issues.
Always check the status
bar (the bottom text display). MManage rarely displays popups and the
success/error statuses of various operations are displayed on the status bar
instead.
Filters:
Nearly all forms in MManage can be
filtered with the followings:
·
Quick filter:
found in the top-left side in MizuManage. For example type “44*” in the quick
filter box then open the “CDR” form and click “Load”. You should be able to see
all calls to 44….. numbers. Or enter “test” and open the “Users and devices”
form. Click on the load button to see accounts containing the “test” word (in
name, username, address, etc)
·
Direction
filtering: accessible by double clicking on the space below the quick filter or
from the Fields menu -> Filter -> Set direction filter. When you are
doing operation which needs more precision (eg. billing), always use the Set
Directions form and not the quick filter.
·
Date-Time filter:
found in the top-left side in the MizuManage. Useful to restrict statistics,
reports and CDR listing intervals.
Menu:
·
The most
important item is the Configuration wizard (from the Config menu). Use this to
(re)configure your SBC’s most important settings.
·
From the
“Control” menu you can Stop/Start/Restart your server (you can do so also from
windows Services management console)
·
To export data
from the application, use File menu -> “Save As”.
·
From the “Fields”
menu you can manipulate the selected dataset (grids, etc).
The most important settings can be
configured from Config menu -> Configuration Wizard as already discussed in
the previous chapter.
All user records can be managed from the
“Users and devices” form (below the “Access” node in the tree-view).
Users can represent real people,
endpoints, extensions, devices or servers.
The most important user types are the
followings:
·
SIP server for outbound routing. Your
SIP server(s) should be added here.
·
Traffic senders for inbound
routing. Your SIP server(s) should be added also here.
·
Endusers: these are managed by the
SBC automatically.
·
Admin users: you should add
yourself (and/or the administrator) here as it is used for various purposes
such as sending alerts and reports.
The users are stored in the database
tb_users table and they have a lot’s of properties which can be managed from
the “Users and devices” form or (for advanced users only) changing database record
fields (select a user the go to Fields menu -> Show fields).
You don’t need to manage
endusers/extensions on the SBC! In MManage you might see your endusers (extensions) listed
on the “Users and devices” form, however that is only for monitoring purpose
and for the SBC internals, auto created and managed by the SBC. Except your
extension usernames, no authentication credentials (password) or any sensitive
information (such as billing) are stored on the SIP SBC. Use your
Softswitch/PBX for user management.
Listing users
Open the “Users and Devices” form
(below the “Access” section) and (double) click on a user type to have a
listing.
You can apply various filtering using
the user “Type” checkbox-list, the dropdown-list on the top of the form or the already
discussed direction filter or quick filter.
Your SIP servers can be found as “SIP
Server” and “Traffic sender” accounts.
You can easily search for
users using the “quick filter” box. For example to list all outbound routes
whose username or name contains the “carrier” word, select the “SIP Server” and
type “carrier” in the quick filter. The quick filter will also search in other
fields such as IP, name, email and others.
Other listing options are
available also from right click on the “Users and devices” node in the main
tree-view or right click on user type node from within the “Users and devices”
form.
Creating
users
The best way to create new users is to
clone an existing working account with the same user type.
For this, launch the “Users and
Devices” form, select a user type, and click on the “Load” button. Then
select any user entry and click on the “New User” button. Alternatively right click on the “New” button for other
options to add user records.
Endusers are created automatically by the server at first time
when an extension will try to register or call. These enduser records are only
for internal management and statistics reasons. This are the same users as the
extensions on your PBX, but the SBC might have information only about their
username and display number (the SBC does not have to know the password since
the authentications are forwarded to your SIP server). You don’t need to manage
these endusers on the SBC (Keep using your PBX to manage your users).
The username can be also used as a real
phone number; will be used also as the caller-id if not specified otherwise.
Endusers can make voice or video calls, presence and chat directly between them
without the need to be forwarded to your SIP server. (Alternatively you can
disable direct routing between endusers by setting the alloweuserusercalls
global config value to 0).
Traffic sender users are used for receiving traffic from your SIP
servers (PBX, Softswitch, SIP proxy or other SIP device). The authorization
type is usually set to “Auth ip must match” and you have to enter a correct
“Auth Ip” (IP address based authentication).
SIP servers: For outbound traffic you need one (or more) SIP
Server user. The most important parameter here is the “IP” where the VoIP calls
will be sent. Then you will have to configure these also on the Routing form.
To be able to send and receive traffic
to/from another SIP server or carrier you will have to add it as both a
“traffic sender” and “sip server” user.
SIP
Servers
A default/first SIP server record is
automatically created for you once you complete the Configuration Wizard. Use
the “Add Upper SIP server” form (available from “Config” menu -> Users ->
Quick Add) in case if you have more SIP servers where the traffic from the clients’
needs to be sent or accepted from. (Or just create Traffic sender + SIP Server
+ add the SIP server to the Routing).
The most important configuration for
a SIP server is its network address (IP and/or domain name). Also you must
specify the port number if your server is not using the default SIP port (UDP
5060). This can be done by just appending it after the IP after a colon (such
as 11.22.33.44:5678) or as the “port” field in the user table.
Also don’t forget to add the SIP server to the routing (Routing form).
Add SIP Server:
Your upper SIP server(s) can be added
multiple ways:
1.
from the Configuration wizard you
can add your default/first SIP server on the “SIP server” page
2.
from the “Add Upper SIP Server”
form (from Config menu -> Users -> Quick Add)
3.
from the “Users and devices” form
(This is discussed here)
A default/first SIP server can be added
during the configuration wizard. (You can also modify it from right click on
“Configurations” node in the tree-view and select the “Upper server” from the
popup menu).
To add a SIP server open the “Add Upper
SIP server” from Config menu -> Quick add -> Users.
(Alternatively right click on the “Users
and devices” node in the tree-view and select “Add Upper SIP Server”).
Pay attention to the following fields:
IP, domain, port (you can also set the proxy field if needed).
Once you added your server, make sure to
modify the
routing after your needs (if you have
more than one server, then the routing needs to be able to decide somehow which
traffic to send to which server. You can create various rules for this on the
“Routing” form)
When you add a SIP server, this is what
happens:
1.
a Traffic sender account is
created which will handle inbound traffic coming from your SIP server
2.
a SIP server account is created
which will handle outbound traffic to your SIP server
3.
a default routing entry is created
for the above SIP server
Actually, you can “add a SIP server” by
just performing the above 3 tasks (add the Traffic sender and SIP server
accounts from the “Users and devices” form and then add the new server to the
routing from the “Routing” form)
Multiple SIP servers:
You can use one SBC SIP for multiple
SIP servers (if you have more servers) for both outbound and inbound traffic.
Registrar routing:
By default all registrations will be
routed to the default upper SIP server (what you have set during the
configuration wizard or from global configuration search for “fwdregistrations”).
If you have multiple upper SIP
servers and the SIP clients need to register to different servers, make sure to
set the routingforregister global config option
to 1 (from the “Configuration” form).
Then the registrations will be routed
after the routing rules which can be defined on the “Routing” form. The only
exception is the called number since there is no called party in a registration
(this is applicable only for calls).
If the “routingforregister”
is set to 0 (default), then it will forward all registrations to your default
SIP server which you have created during the configuration wizard.
However, if your SIP servers are for
completely different domains/businesses, then you might consider to set-up a
separate SIP SBC for each of them.
Note: The
“routingforregister“ is only for registrations. Call and chat routing are
always performed after your “Routing” settings
Call routing:
·
Outbound calls are always routed
based on routing
rules which you define on the
“Routing” form.
Routing rules can be set for SIP servers (so you must
create “SIP server” user(s) before to be able to work with routing.
·
To be able to accept inbound calls (from your SIP server to SIP clients) you will need
to create “Traffic Sender” user (usually with IP authentication with the Auth
IP set to your SIP server address).
·
Calls between users are handled
automatically.
In case if the calls have to be routed
to the target domain specified by the clients, then set the allowupperserverselection config to 1 and the upperserverlookup
config to 2.
In this case you should just add all
your SIP servers with equal priority for the Routing and the call will be
routed to the domain/IP received from the client (target URI of the SIP
requests).
Check “how to connect?” from the “Help”
menu for the exact details about SIP clients configuration.
For a quick test, register with two
softphone and call from the first account to the second account.
Softphone configuration:
·
domain: your SBC IP or domain
name (and the SIP port if your changed it from the standard 5060 UDP port)
·
proxy: you can leave it empty
·
username / password: loaded from
your SIP server (or from the SBC if you created a special user with
username/password authentication)
Add SIP Client:
There is no need to add endusers,
extensions or SIP clients manually.
Just continue to manage your users as
before: on your SIP server.
You will be able to see the users on the
“Users and devices” form -> Endusers, however these are managed
automatically by the SIP SBC and there is no need to change any settings here
except if you have some extra requirement such as setting call forwarding, call
recording or some other per user setting. The first time a SIP client will
register or make call, a user entry is automatically created by the SBC. This
is mostly for internal usage only, but it also allows you to make per user
changes if necessary. No password of these users are stored on the SIP SBC (The
users are created with “Username” based authentication only, however the SIP
SBC will also check other parameters such as same session / same address for
further account restriction. If you wish, you can create additional users of
your own for various other purposes.
For special purposes you might add users
also manually. There are multiple ways to do this:
·
click on the “New” button from
“Users and Devices”
·
or right click on the “New” button
·
or right click on the “Users and
devices” tree-view node.
·
or from “Config” menu -> “Users”
Outbound Routing
Outbound routing rules are required for
the SIP SBC to properly route the calls to your SIP server(s).
Calls between users are handled
automatically as this will bypass the routing table and it is routed directly unless
if you disable it. However for
outbound routing you need to add a “SIP server” user first and then add it to
your routing rules.
Once you add your upper server as a “SIP
server”, open the “Routing” form.
In the left side you have to define your
pattern which will restrict the condition when the actual route entries can be
used. If all fields are empty and the time definition is set to “All times”
then all patterns will match. You can make restrictions if you make
specifications here (caller, called prefix, time restriction, etc). Make sure
that you increase the priority for the pattern (to be higher than the “general”
pattern where you have not made any restrictions).
On the right side you will have to add
one or more sip proxy users. If you set more than one route with equal priority,
then you have load balancing, LCR or BRS (depending on the “brs_lcr” global config option); otherwise the
traffic will be routed after the prioritizations (will flow to the lower
priority servers only if you have reached the maximum port limitations or
because automatic failover).
If you have only one
server then just create one pattern (left side) enabled for all times and no
any filter set, then assign your SIP server user entry to this pattern (right
side).
For more details please read the routing guide.
Client driven routing
The outbound routing can be influenced
also from the client side.
In this case the client will suggest the
target upper SIP server with the INVITE target URI (so you will configure the
gateway as a SIP proxy in your app and will set the SIP domain to the target
upper SIP server) or by the X-Sy.Uppersrv (address), X-Sy.Uppersrvd (domain),
X-Sy.Upperproxy (proxy) extra SIP headers.
This is considered by the gateway only
if allowupperserverselection global configuration is set to 1. It
can be set also from the Config Wizard -> “SIP Server” page -> “Allow
client driven upper server selection” checkbox.
In this case you should still create the
SIP Server user entries and add them to the Routing (usually with equal
priority, so the target server will be selected based on your app preferences)
Technical details about the upper SIP server select algorithm in short
(in priority order. Top/1 is higher priority):
·
if called is SIP server:
1.
Sy.Upperserver or target URI sent in INVITE
2.
UpperServer cache (usrv = config.GetUpperServer)
3.
SIP server settings from DB
4.
B huser from cache (settings from last target user REGISTER)
·
if called is user:
1.
B huser from cache (settings from last target user REGISTER)
2.
Enduser settings from DB
Dial plans
You can manipulate number format, SIP
headers or the Caller-ID from the following settings:
·
Users and devices form: caller-id,
username, tel numbers (DID match), tech prefix
·
Routing form: you can only specify
routing direction here without number changes
·
Rules form: this is a powerful
module which you can use to change almost anything (including caller-id, called
number format and many others)
·
Global configuration: a few global
configuration options might also affect the dial plan. Right click on the
“Configuration” node and select “Number rewrite” for the details.
·
Prefix rules and the dial plan form:
use the “Rules” form instead when possible.
You can find more details in the VoIP Admin Guide below the Routing section.
Inbound Routing
If you would like to accept traffic from
your servers, you need to have one or more “Traffic sender” user account
created. Usually you can use IP based authentication. For this, add the peer IP
to the “Auth IP” field.
For each incoming call, the server will
first check if the called party is a local user. If not, then the call is
routed according to the rules which are set by the “Routing” form.
One “Traffic sender” user
entry can handle incoming traffic with IP authentication from multiple IP
addresses. Use the “…” button near the “Auth IP List” to add more IP addresses.
Usually there is no need to
setup any routing rule for inbound calls (as these will be calls to local SIP
users which are found automatically).
Traffic between
endusers/extensions is handled automatically.
A CDR (call details report) is generated
for each call on your SIP SBC.
You can access these records by using
the “CDR” form under the “Monitoring” node in the tree-view. By default
only the most important fields are listed (date-time, connect time, call
duration, etc). You can see more details if you check the “All fields”
checkbox.
To quickly list the CDRs that belong to
a user, open the “Users and devices” form. Find the user record, then
right-click on it and select “Set Direction”. Than go back to the CDR record
form and click on the “Load/Reload” button.
You can easily filter calls
with a specific prefix by typing the prefix in the quick search box following
with an asterisk and hit enter. For example searching for 44* will list all CDRs
where the called number begins with 44.
You can also see various
statistics based on these CDRs by using the “Statistics” or the “Disc. Reasons”
forms.
The Mizu SIP SBC provides
endless possibilities for monitoring both real-time and statistics history.
Some of the most important tools are the followings:
Dashboard: a summary of the most important parameters and a
start point for management (Note: You can access various statistics by just
clicking on the Dashboard items. For example click to “CCalls” will show the
current calls)
By using the “Analyze”
form you can have a quick overview about the system and warnings for
malfunctions or configuration suggestions
List the active
sessions: Monitoring -> “Current
Calls” form
Disconnect reasons: Monitoring -> Disc. Reasons will show statistics
about call disconnect codes.
Statistics by SIP
server: Monitoring ->Statistics
-> Group By: called servers (useful if you have multiple server, softswitch
or PBX)
Statistics by users: Monitoring ->Statistics -> Group By: caller
Statistics by day: Monitoring ->Statistics -> Group By: day
Logs: the most important logs can be listed from the
“Logs” form. Detailed logs can be found in log files accessible from Files menu
-> Folders -> Server Logs directory
Other more advanced statistics
can be generated by using the Statistics form and using different
fields/options/grouping/directions.
All statistics can be filtered by the
“set direction” form or the “quick filer” edit-box and by a time interval
selection.
Automatic reports: The SIP SBC can send daily reports for administrators
or email/sms alerts on malfunctions. For this you have to setup an “Admin” user
with a valid email address (From the “Config Wizard” or from “Users and
Devices”). Then set the following user fields to 1 (after your needs): “sendemailalert”, “senddailyemal”,
“sendmonthlyemail”, “sendsmsreport”, “sendsmsalert”.
You can start/stop the SBC service
from:
·
the “Control”
menu in MManage
·
or by the Windows
Service manager locate the “mserver” entry, right click and select “Start” or
”Stop”
Note: the first start might take a
bit longer (around one minute), otherwise the start-up time should be below 10
seconds.
By default when you reinstall the SBC
service, it will keep your old settings and data, thus you can easily upgrade
to new versions.
If you wish to begin with a clean
state, delete (backup first!) the old mserver.sdf
file before launching the installer, thus you will have a clean state with all
your previous settings and data erased.
In case if you wish to upgrade while
keeping all your settings and data, then just do the followings:
1.
Stop the service
(“mserver” from windows services or from Control menu -> Stop Server)
2.
Backup (copy all
files, except the logs, just in case if something will go wrong with the
upgrade)
3.
Install (just run
the new installer, which will overwrite all binaries and will keep your old
settings and data intact)
4.
Start the service
A backup for the SIP SBC can be done
with simple file copy (xcopy) and just copy back the files for restore.
You can back-up all your data and
settings by just copying the mserver.sdf file from the app folder
Alternatively, you might choose to copy
the entire app directory, excluding logs (however these files can be easily
recreated by a reinstall, so you really need only the mserver.sdf).
By default the SBC will automatically
create nightly backups and auto-delete old backups (Search for “backup” in the
global configuration to change this).
The below discussed settings have to be
changed only if you have some special requirements, otherwise the default
settings are optimal out of the box.
Through this guide we often refer to
various configuration keys also called as “global configuration” or “global
config”. All these can be managed from the “Configuration” form (below the
“Other” node in the tree-view).
The SIP SBC has a long list of configurable
settings which you might adjust to turn on/off features or to adjust the SBC behavior
after your needs.
The settings can be categorized in the
following way:
·
global configuration (editable
from the “Configuration Wizard” and from the “Configuration” form)
·
per user configuration (editable
from “Users and devices”)
·
other configurations (editable
form various forms such as “Routing”, “Rules” and others)
You can quickly change any global
configuration from the “Configuration” form (below the “Other” node from the
main tree-view). Just search for your keyword to find the related setting(s).
Most of the changes can be applied
instantly (click on the “Apply Now” button), however some changes (such as local/bind
ip/port reconfiguration) require a restart.
Some settings groups can be accessed by
right clicking on the “Configuration” form.
SBC related options can be listed by
right click on the “Configuration” node and select the “Gateway” from the
popup. Some important gateway related settings are the following:
autocreatereguse: 0=no,1=when fwd authenticated ok
register, 2=always (when we receive the register)
fwdregistration: 0=no,1=only from alternate port,
2=always
fwdregistrations_address/fwdregistrations_domain/fwdregistrations_ip/fwdregistrations_port:
the address of your SIP server (the upper server)
forwardauthentifications: 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
forwardauthpassword: 0=fwd from ep, 1=means 2 if from rtc
for recent users, 2=answer from local always,3=answer from local also for
register, 4=answer from remapped upperusername/upperpassword
If you migrate the SBC to another box
or your IP changed, then you will need to set the new IP (and the domain name
if that was also changed).
There are 2 ways to easily change the
SBC IP:
1.
going through the
Configuration Wizard and make changes on the “Network” page
2.
or right click on
the “Configuration” node in the main tree-view (below the “Other” node) and
select “Network -Basic” and rewrite the IP (bindip, LocalIP, LocalDomain
settings)
Restart your SIP SBC once you changed
the IP because this can’t be applied at runtime.
This is about changing
your SIP server IP address or domain name (the upper SIP server where the calls
are routed and received from) if you are using a single SIP server.
For example if you
migrated your SIP server to a new location or if you have to change the upper
SIP server details for any reason.
In case if you are using
a licensed SIP SBC, make sure that your license allows the usage also with the
new SIP server address.
GUI configuration (this will not rewrite the upper server for existing
users):
You might go trough the
Configuration Wizard again and configure your new SIP server.
Alternatively just search
for “fwdregistrations_” on the “Configurations” form and rewrite it to your new
server address.
Add the new SIP server
user record at the "Users and Devices" form.
Use the Routing form and specify
your custom rules for the server selection.
From SQL:
Replace OLDIP to your old
SIP server IP and the NEWIP to the new SIP server IP address and then run the
following SQL commands to change the upper SIP server address (copy-paste to
the “Direct Query” form and hit the “Go” button):
update
tb_users set hwid = REPLACE(hwid,'OLDIP','NEWIP'), ContractComment =
REPLACE(ContractComment,'OLDIP','NEWIP'), ip = REPLACE(ip,'OLDIP','NEWIP'),
authip = REPLACE(authip,'OLDIP','NEWIP'), domainname = REPLACE(domainname,'OLDIP','NEWIP'),
proxyaddress = REPLACE(proxyaddress,'OLDIP','NEWIP'), transip =
REPLACE(transip,'OLDIP','NEWIP'), name = REPLACE(name,'OLDIP','NEWIP'),
username = REPLACE(username,'OLDIP','NEWIP')
update
tb_users_authip set authip = REPLACE(authip,'OLDIP','NEWIP')
update
tb_settings set valstr = REPLACE(valstr,'OLDIP','NEWIP')
If you (also) use a
domain name, then replace OLDIP to your old SIP server domain and the NEWIP to
the new SIP server domain name and then run the SQL statements again.
Using the SBC with
multiple SIP servers:
The SIP SBC can be
also used with multiple SIP servers. To be able to route the users to their
respective servers (register, call, chat and other sessions) you have the
following possibilities:
1. Specify the upper server from your SIP client instead
(as the SIP server domain for your app config).
To allow client driven upper server selection, set the allowupperserverselection
global config option is set to true.
2. Specify the upper server from the gateway/server
routing rules:
Add the new SIP server
to the “Users and Devices”
Use the
Routing form and specify your custom rules for the server selection.
For the
routing rules to be applied also for register requests, you need to set the routingforregister global config option is set to 1.
3. Both:
You can use
both routing rules and upper server suggestions from your SIP clients.
If the
allowupperserverselection settings is true, then the client suggestion will
overwrite your routing rules.
For all cases, make
sure to create the necessary records from the “Users and devices” form for all
your SIP servers:
·
Add them as “SIP Server” (for
outbound) and as “Traffic Senders” (for inbound, usually with IP
authentication).
·
Then configure them in the
“Routing” after your needs to specify what kind of users/calls have to be
routed to which SIP server.
For example you can just
list them under the “default” pattern with equal priority for load balancing or
configure any rules after your requirements.
Ports
The SIP SBC will listen on several
ports to offer its services: SIP signaling, RTP/RTCP ports range and others.
It is recommended to keep the default
ports since the defaults are optimized for maximum connectivity and/or are
conform to standards.
If these ports are already used by
some software running on the same box, then we recommend to assign a secondary
IP for your server and bind the SBC to this new IP (set the bindip), then
reconfigure the other software’s to use only the old IP (bind to the old IP).
For example IIS can be bound to an IP with the following command:
netsh http add iplisten
ipaddress=IPADDRESS
(replace IPADDRESS with the IP to bind)
If you are hosting the SIP SBC on the
same box where your softswitch is running, then assign a separate IP (bindip)
to the SBC if possible. If this is not possible, then make sure to change the
ports on the SBC to avoid conflicts (if your SIP server is listening on 5060,
then set a different “localport” for the SBC).
The most important ports can be
configured from the Configuration Wizard. Other ports can be configured in the
global config.
The exact port numbers used by the
SBC service can be listed from MManage -> Config menu -> Network - > Active
Ports.
Here is the default list of ports
used by the SBC and their global config options which you can change from the
“Configuration” form if needed.
Mandatory ports:
·
localport UDP and TCP (main SIP
signaling port. Default is 5060)
·
mainaport TCP (main server port
for various purposes such as API and others. Default is 80.)
·
MinRTP-MaxRTP range UDP (for RTP
and RTCP)
Optional ports (good to allow also
these):
·
Remote desktop TCP 3386 (for easy
server administration)
·
TCP 1433 and/or 2223 (for remote
management)
·
adminport TCP (for remote CLI
access from MManage server console. Default is 9885)
·
monitorport TCP (to easy access
logs from remote MManage. Default is 9889)
·
localport+1 TCP (for secure SIP.
Default is 5061 -if you enable TLS for SIP which is known as SIPS)
·
ftpserverport TCP (for remote access
for voice recording . Default so 9710)
·
UDP: 44444 (“voice-here”
functionality in MManage)
·
TCP: 9885, 9886, 9889 (optional
ports for admin console and logs)
Make sure to enable these ports if you
are using a port based firewall.
Make sure that the ports used by the SBC are not used also by some other
application such as a local web server (in this case either change the SBC
ports or the third party app port or bind them to separate IP address).
By default, the SBC will try to handle
RTP/RTCP routing automatically by routing the RTP when the call endpoints are
behind NAT and off-route when direct peer to peer RTP routing will likely
succeed.
However, this default behavior can be
fully reconfigured if you have any specific needs.
RTP routing can be reconfigured either
globally or by endpoint.
·
The global (for all endpoints and
call) RTP routing can be configured from Config menu -> Configurations ->
RTP Relay.
Set to “Bypass” to allow direct peer to peer media
between the endpoints; Set to “Route” to allow the SBC to route the RTP/RTCP;
Set to “Force” to disable all kind of peer to peer functionality;
·
RTP routing by endpoint can be
configure from the “Users and Devices” form -> “Functions” page -> “Media
relay” settings. You can configure it for Endusers, SIP Servers and Traffic
Senders.
Set to “Always route RTP” to force RTP routing for all
calls via that user or device; Set to “SDP correction if necessary” to disable
RTP routing by the gateway; Set to other value if RTP routing should depend on
caller/called NAT be
RTP routing will be automatically forced
if the SBC has to process the media, for example for call recording,
conferencing or DTLS decoding.
See the admin guide “Media Routing” FAQ
point for more details about this topic.
The SBC can be used also behind NAT (located
behind NAT or router, even without internet access).
If your SIP SBC is behind a NAT or
Router, make sure to forward the ports above correctly if you need
connectivity also from external network (SIP clients or SIP server on the
internet. If both of these are behind NAT, then there is no need to enable
these ports).
In this case make sure to set the “Offer
services for” option correctly on the “Network” page of the Configuration
Wizard.
·
Both LAN and
internet: select this if SIP clients might connect also from the public
internet (make sure to set proper port forward on your router in this case)
·
LAN: means all SIP
clients will connect from local LAN, but the SIP traffic might be sent to the
public internet (your SIP server is outside)
·
Force LAN Only:
means that all peers (including your SIP server and all clients) are located on
the local LAN
In other words, here are the possible
uses-cases:
·
SBC on the
public internet:
You can just skip this chapter as you
don’t need to take care about NAT in this case. (SIP clients connecting from
behind NAT are handled automatically)
Set the “Offer services” option to
“Internet only” if your SIP server is also located on the public internet or
“Both LAN and Internet” of your SIP server or other SIP device is located on
the same box or network.
Your “Public IP” and “Bind IP” can be
the same public address in this case.
·
SBC, SIP
server and SIP clients all on local LAN:
In this case you don’t need to set
any port forwarding in this case as all peers will be reachable directly.
Set the “Offer services” option to
“Force LAN only” in this case.
Your “Public IP” and “Bind IP” can be
the same private address in this case.
·
SBC and SIP
clients behind NAT, SIP server on the internet:
If the SIP server or SIP service has
good NAT handling capability, then everything should work just fine by default.
Otherwise setup proper port forwarding on your NAT/router for the above
mentioned ports.
Set the “Offer services” option to
“LAN” in this case.
·
SBC behind
NAT, SIP clients on the public internet:
Set the “Offer services” option to
“Both LAN and Internet” in this case and setup proper port forwarding on your
NAT/router for the above mentioned ports.
Also set the “Public IP” to your
network external IP.
Calls
between endusers/extensions
Calls between endusers can be routed
directly, without the need to route them via your upper SIP server(s), thus
saving your server resources (CPU/memory).
This direct routing is enabled by
default and it can be easily changed by the following global config values
(from the “Configurations” form):
alloweuserusercalls: 0=no (don't check if local target),1=yes,2=disable (drop)
call to endusers
To enable direct routing, set the alloweuserusercalls to 1.
To disable direct routing, set the alloweuserusercalls to 0.
One user can be registered from
multiple locations at the same time and calls can be routed to all of its
devices.
Use the following global
configurations to modify this behavior:
allowforkforsignaling: 0: no,1: partial,2: yes,3: yes and
remember old addresses (send sip request to multiple recipients at once)
The SIP SBC has support for all the
commonly used audio and video codecs:
G.711, OPUS, G.729, G.723, GSM, iLBC,
Speex, G.722, VP8, H.264
The codec is negotiated automatically
for each call depending on SIP client and SIP server capabilities.
The codec used for calls can be also
influenced by the “choosecodecs” user
configuration (which can be also set on the “Users and devices” form -> Functions
page -> Allowed codec setting).
By default, the SBC will try to avoid
transcoding when possible by negotiating a common codec between caller and
called parties. If necessary, it can convert automatically between the SIP
client and server by sending a re-INVITE with all supported codec’s when a 488
answer is received from the caller.
If one of your peers has limited
codec capabilities or the accepted codec(s) doesn’t match with the sender codecs,
then set its “needcodecconversion” to 1 (for
the target user which is usually a SIP Server user or Enduser). This can be also
controlled on the "Functions" page of the "Users and
devices" form.
Change the “convertcodecs”
global config value to the target codec payload list. The default value is 0,8,18
which means PCMU,PCMA and G.729.
The server is able to transcode
between the following codecs: G.711 A-law , G.711 A-law ,G.729, G.723.1, GSM,
OPUS, Speex 2,3,4,5,6 (narrowband, wideband and ultrawideband), G.726 and
G.722. You might also have to set the “choosecodecs”
field for the target user (same as the “convertcodecs” global config value) and
the “convertcodecsforced” global config option to true.
Valid payload values are the
followings:
o PCMU (G.711 u-Law): 0
o PCMA (G.711 A-Law): 8
o GSM (GSM 06.10): 3
o G.722: 9
o G.723: 12
o G.729: 18
o iLBC: 97
o Speex: 104
o Speex wideband: 105
o Speex ultra wideband: 106
o Opus: 110
o Opus wideband: 111
o Opus ultra wideband: 112
Example: If your SIP Server has
support for G.729 and PCMU, then you should enter “18,0” for the choosecodecs
user field (or in the “Users and devices” form -> “Functions” tab ->
“Allowed codec” field.
Be aware that codec transcoding
requires a high amount of CPU usage. For example one CPU (core) can handle
around maximum 20-200 simultaneous transcodings between PCMU and G729 on full
load (depending on your CPU type).
Codec transcoding should be avoided
whenever possible because it will increase the CPU usage and also will degrade
the quality a bit. By default the SIP SBC will try to negotiate a common codec
between the endpoints and transcode only when strictly necessary.
Example configuration if (caller A has only G.711 codec and) called B accepts only G.729:
For the B user set the user
convertcodecs field to 18 and the needcodecconversion field to 1 (The same can
be done also from the SBC GUI -> Users and devices -> Functions tab).
To disable all kind of transcoding on
your server, run the following queries:
update tb_users set needcodecconversion = ‘’,
choosecodecs=’’
update tb_settings set valstr = ‘false’ where
keystr = ‘convertcodecsforced’
update tb_settings set valstr = ‘false’ where
keystr = ‘enabletranscoding’
update tb_settings set valstr = ‘0’ where
keystr = ‘fs_transcode’
update tb_settings set valstr = ‘0’ where
keystr = ‘autocodecconvert’
The voice recording option can be set
for any user by checking the “Voice Record” checkbox on the user configuration
form in MManage (Users and Devices -> Functions tab).
Conversations will be saved in the
directory specified by the “serverftpvoice”
global config option.
The exact location will be:
serverftpvoice\databasename\currentday\voice.xxx
A separate backup can be created in
the directory specified by the “voicebackupdir”
global config option.
Out of date recorded files can be
deleted by setting the “keeprecorded” option
accordingly (days to keep).
Recorded files are compressed and
encrypted by default.
Recorded conversations can be played
on the "CDR" form (Select the "Recorded Conversations"
radio item, select the desired record and click on the Play button) or from the
“Voice Record” form.
You can also export the files as wav
or mp3.
Users can replay the last record by
the following DTMF digits: *4*
Note: call recording can make the
routing and media path longer, disabling peer to peer calls and also will
increase your server I/O and CPU usage.
You can enable/disable call recording
for all users at once from MManage -> Config menu -> Configurations ->
Recording -> Calls.
Recording can be also enabled/disabled by SQL
commands:
To disable recording for all users, execute the
following SQL’s in the “Direct Query” form:
update [tb_users] set
record = 0, RouteRTPCaller = 1, RouteRTPCalled = 1 where type in (0,5,9)
ALTER TABLE [tb_users]
DROP CONSTRAINT [DF_tb_users_record]
ALTER TABLE [tb_users]
ADD CONSTRAINT [DF_tb_users_record] DEFAULT 0 FOR [record]
Update tb_settings, set
valstr = ‘1’ where keystr = ‘defroutertp’
If you wish to enable call recording for all users, execute
the following SQL’s in the “Direct Query” form:
update [tb_users] set
record = 1, RouteRTPCaller = 7, RouteRTPCalled = 7 where type in (0,5,9)
ALTER TABLE [tb_users]
DROP CONSTRAINT [DF_tb_users_record]
ALTER TABLE [tb_users]
ADD CONSTRAINT [DF_tb_users_record] DEFAULT 1 FOR [record]
update tb_settings, set
valstr = ‘7’ where keystr = ‘defroutertp’
To force recording for all calls (even those where the
media would be routed peer-to-peer otherwise), set the following global config
options:
defroutertp=7 (force RTP
routing by default)
alloweuserusercalls=0
(disable upper server routing and media path bypass)
disablep2prtprouting=1
(disable peer to peer media path detection)
The users IM history can be recorded
and stored in server database, tb_messages table.
For this set the “logmessenger” global config option: 0=no,1=on low
load,2=always
You might also disable fast message
forwarding by setting the “fastmessagequeue”
configuration option to 0.
The recorded messages can be seen on the
“Chat Logs” form MManage.
Chat transfer
Both attended and unattended transfer
is supported.
Related global settings:
fs_handletransfer
Specify how to handle WebRTC transfer
requests (whether to handle REFER locally or forward)
-1: auto (if target user is SIP and
not here and no replaces)
0=no (let the WebRTC layer process
the REFER messages as-is)
1: auto (if target user is SIP and no
replaces)
2: always (forward to upper SIP
server),
3: forced (this option should not be
used)
Default is -1
handlerefer
Specify if to handle REFER requests
on SIP stack level
-2: block
-1: block for outbound/allow only for
endusers
0: auto/default (forward as-is or
handle if REFER is not supported by peer ep or if the transfer was made with
Replace)
1: handle as unattended transfer
2: handle as attended transfer
3: forward as a new call
4: just forward the REFER as is
Default is 0
handleincomingreplaces
Specify how to handle transfer
replaces on SIP stack level
-4: don't rewrite also for REFER
-3: don't forward
-2: don't rewrite
-1: auto
0: no (create new INVITE ep)
1: yes with re-auth
2: yes
Default is -1
allowclientinitiatedtransfer
Specify if to allow client initiated
transfer
-1: auto (will allow to local user or
if no billing required)
0: no
1: yes
Default is -1
discontransfer
Specify to disconnect call upon
transfer on SIP stack level
-1: auto
0: no
1: yes on C party connect
2: immediately on succ if no refersub
3: immediately on fail if no refersub
4: always immediately
Default is -1
If you are interested in WebRTC-SIP
protocol conversion then you should use the MRTC gateway which is actually an SBC with the
WebRTC module included by default.
However WebRTC support can be easily
added also into any existing SIP SBC. Contact Mizutech to perform the upgrade.
The SIP SBC has support also for VoIP
push notifications. This is a useful feature to improve the availability of
mobile SIP clients by sending a push notification on incoming call or text
message which will wake-up the client app, thus the call/chat can be delivered
even if the app is closed or the device is sleeping.
Follow this documentation to enable push notification and
integrate push support into your Android/iOS/Web app.
API
The gateway exposes also an API which
can be used to perform or automate various tasks.
The API documentation can be found
here:
https://www.mizu-voip.com/Portals/0/Files/VoIP_Server_API.pdf
For example all upper server
registrations can be removed with a request like this:
http://sbcserveraddress.com/mvapireq/?apientry=upperunreg&u_username=all&authkey=KEY&authid=USERNAME&authmd5=MD5&authsalt=SALT&now=555
Please note that for automation you
can use also other tools such as “Scheduled Tasks” from the admin client or
direct SQL database connection to alter any data such as user
records (tb_users).
See this guide for various integration possibilities.
Logs
You can find the SIP SBC logs from Files
menu -> Folders -> Server log directory. Use a fast text reader to work
with the files such as F3 from Total Commander.
The logs files are managed
automatically by the SBC (auto deleting old log files or if you are low on
disk-space).
You can change the server log level
from Control menu -> Log.
The SBC is based on our Softswitch
core which implements a long list of security measurements which are also
applicable for the SIP SBC. See the details here.
HA, failover and
redundancy is supported for both downstream and upstream.
You can use a second
backup SBC, multiple SBC’s for the same SIP server, handle multiple SIP servers
by the same gateway or for the highest availability: use multiple gateways with
multiple SIP servers.
For high-availability you have a few
options:
·
UAC failover:
endpoint failover to secondary gateway if there are no or bad response of the
REGISTER (or OPTIONS/INVITE requests).
This doesn't depend on any server
side or networking feature and it can be handled entirely by your client app.
·
Automatic or
manual IP or domain rewrite on failure
·
DNS SRV records
·
BGP or dynamic IP
auto-reconfiguration on failure
·
SIP Load Balancer
·
Or other
mechanism what you already using with your VoIP servers
The SBC itself also has several
built-in mechanism to failover among your SIP servers:
·
Basic failover
(auto failover to other server(s) on upper server failure)
·
Routing automatic
(auto prioritization, based on BRS statistics)
·
Routing rules
(upper server prioritizations/failover after pattern and/or destination
priority)
·
Re-Register
(redirect the registration to a working server on bad or no response)
·
Re-Dial (in-call
failover when a bad or no response is received from the upper SIP server)
·
Or simply you
might use a separate SBC for each of your SIP servers
More details can be found
here and here.
Class 5 features should be handled on
your IP-PBX or Softswitch, however the SBC also has some built-in features
which might be useful for you (for example voicemail or call forward). Also for
some functionalities there are no direct mapping between the SIP client and SIP
server so they can be solved only by extra features provided from the SIP SBC
or on your Softswitch (for example conference). Other features don’t depend on SIP
but might be implemented on the server side using some separate protocol
(usually via a HTTP API exposed to clients).
Here are a few of the extra features:
IM/Chat: fast chat routing between SIP clients based on SIP
MESSAGE RFC 3428.
DTMF: For DTMF to work your SIP server
and SIP client must have support for RFC 2833 or SIP INFO. The SBC can also perform the
conversion between these if needed. In-band DTMF conversion is not supported,
however, it is routed as-is, so this method will also work if both your SIP
server and SIP client use this method.
Call forward: can be enabled from users and
devices form -> functions tab. For call forward to work via your server, it
needs to support SIP response code 301 (Moved Permanently) and/or 302 (Moved
Temporarily).
Call transfer: available as specified SIP standards (via all
devices with support for transfer). For call transfer you will need support for
SIP REFER as described in RFC 3515.
Video: Fast video stream routing between endpoints
Special numbers and IVR’s such as music, record/playback, vide record/playback
and others
Presence: Fast presence routing between SIP
clients. For presence to work via your server your software needs support for
PUBLISH/SUBSCRIBE/NOTIFY as specified in RFC 3856.
Barge in: via the “Voice here” form in MManage
Softphones: Mizutech can also offer customized/branded
softphones which works with the SBC or directly with your SIP server: Browser webphone, Windows softphone, Android softphone, iOS softphone,
Symbian dialer,
Other softphones
IVR: The IVR module can be used for various tasks like access numbers,
callback, customer support etc.
You can assign different IVR’s to
different access numbers by using the “Campaigns” form. To create a new
campaign, just click on the + sign and enter a “name” for the new record. The
most important configuration for an IVR campaign is the script. Switch to the
“details” tab to select a “Script”.
Scripts can be created by using the
“IVR” form. The SBC is shipped with several preconfigured script examples, but
you should easily add new scripts or modify the existing ones by following the admin guide
or the IVR documentation.
DTMF triggered actions:
The gateway has built-in functions to
be triggered by DTMF digits, useful for endpoints with no conference or
transfer support. For these to work the PBX module have to be enabled and the handledtmfevent global config option must be set
to 2.
Here are the defined keys:
o create conference or add new user to
conference: *1*number#
o unattended transfer: *9*number#
o transfer with consultation :
*8*number#
o talk with new client while in
transfer: 1
o talk with old client while in
transfer: 3
o disconnecting last conference party:
*5*
o disconnecting conference party:
*6*number#
SMS: by default the SBC is capable to route SMS message as
SIP MESSAGE (RFC 3428). However, it is also possible to use an external service
which can be accessed by a HTTP API. Just set the “smsurl”
smsurl global config option or create SMS GW endpoints if you wish to use more
than one provider. A guide can be found here.
API: the SBC also has a HTTP API which can be used for various tasks. See the
API chapter and the API documentation for the details.
Many others features are enabled for you by
default and some of them can be changed/fine-tuned from configurations, such as
caller-id, ring groups, call hold, call waiting/park/pickup and others.
The SIP SBC is based on the VoIP
Server core thus you can also access almost all of the Softswitch features. See
the Softswitch documentation for the details.
The SBC also does its best to
compensate on missing support. For example the basic presence might work without
SUBSCRIBE/NOTIFY support by using the peer registrar state.
If you are not sure where to find a
specific configuration option, search for your keyword in:
1. “Configurations” form within MManage
2. This guide
3. VoIP server guide (most of the settings can be applied
also for the SIP SBC)
4. Check the other documentations (some of them are relevant also for SIP
SBC)
5. Or ask Mizutech support
·
SIP SBC Home Page
·
Download
·
Contact
Copyright © Mizutech SRL