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.

Quick setup

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.

Features

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

Requirements

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.

Install

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.

Configuration Wizard

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

Troubleshooting

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

MizuManage

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.

User Management

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

SIP Clients and Trunks

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, other 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.

CDR

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.

Statistics and Monitoring

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

Start/Stop

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.

Upgrade

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

Backup/Restore

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

Settings

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)

Global Configuration

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

Change SBC IP address

If you migrate the SBC to another box or your IP changed, then you will need to set the new IP.

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

Restart your SIP SBC once you changed the IP because this can’t be applied at runtime.

Change SIP server address

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

RTP Routing

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.

SBC behind NAT

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.

Multiple registrations and call fork

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)

Codec

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

Transcoding

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’

Call recording

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)

Chat recording

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.

WebRTC

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.

Push notifications

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.

Security

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.

High availability

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.

Extra features

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

Resources

· SIP SBC Home Page

· Download

· Contact