Hardware Installation

LogIn

By default, Sangoma's NetBorder Session Controller (NSC) has the following default IP settings (unless otherwise specified during installation):

IP: 192.168.168.2
Netmask: 255.255.255.0
Gateway: N/A

You can login to the web interface by going to http://192.168.168.2/ and login using the following default credentials:

If this is SBC version 3.0.x then the root password will be "SangomaDefaultPassword"

If you installed NSC by yourself then use the credentials you specified during the installation.

Open

You can later change the default password by going to "System -> Password"

You should land in the "Control Panel" page, which contains a dashboard with all NSC services. All of them will be stopped except for SSH which is enabled by default in case a technical support engineer requires it. You can turn it off if you wish.

If you do not have a license yet, you will get a warning message indicating that the license is not installed. You must get a license from Sangoma before proceeding. If you do not see the "License not installed" warning, then your license was pre-installed in your system by Sangoma.

Open

You can navigate using either the left menu or the top-level menu, both provide a quick access to all system configuration sections.

Upload License

Sangoma SBC Appliances

• By default Sangoma SBC appliances comes with a valid SBC license as per product SKU number.

• This section can be skipped unless upgrading capacity with a new License file.

Sangoma SBC VM & VM Hybrid

• VM and VM Hybrid SBC software is shipped with no License.

• Sangoma Sales will send you an appropriate SBC License file based on product SKU number.

• License will have to be updated as per instructions below.

• For more detailed information refer to: SBC Licensing and Installation

License installation and update is done from the menu "System -> License".
Even if the license is already installed, you can upload a new license or verify your current license details there.

If you want to install the license for the first time or update to a new license, click "Choose File" and upload the .tar.gz license file provided by Sangoma. Then click "Upload".

After uploading the license you will see the details of the uploaded license.

Note: In this example, the license has a limit of 500 sessions. Different vendors have a different concept of what a "session" is. In NSC things are much simpler. A session is a call leg. In a typical call where 2 parties are involved, you require 2 sessions (one for each leg of the call, the incoming leg and the outgoing leg), therefore a license with 500 sessions allows you to have 250 concurrent calls in your SBC. Sangoma's NetBorder Session Controller do not require extra licensing for registered peers (SIP REGISTER message), SIP trunks or any other SIP entity.

Configure Network Settings

Network settings are configured from the menu "Configuration -> IP Settings"

This menu has 2 type of interfaces: "Signaling Interfaces" and "Media Interfaces"

Signaling interfaces are all ethernet devices connected to the server either via PCI(e) or embedded in the mother board.

Media interfaces are special DSP's (Digital Signal Processor) which are accesible through any ethernet network any of the signaling interfaces is attached to. These media interfaces are sometimes embedded within a Sangoma PCI(e) card (ie D500, D100 devices) and sometimes are completely stand-alone processors that  are just attached to the same network (D150).

Configuring "Signaling Interfaces"

You must start by configuring all the signaling interfaces you'll use. You can click "Edit" for each network interface you want to configure.

Note: From the network configuration interface you can also set the hostname, default gateway and the DNS servers. If you use DHCP for any of the interfaces you won't be able to specify a default gateway or DNS servers.

Note: You can also add VLAN interfaces or interface aliases (Virtual IP) by clicking in the proper "Add" button at the bottom of the network configuration page. 

In the above example, interfaces named "sngdsp0" and "sngdsp1" are Sangoma ethernet interfaces that give access to Sangoma's media interfaces (DSPs). Unless you are configuring a server for "software transcoding" mode or you have D150 media interfaces, then you need to configure those network interfaces and you must assign an IP to them.

Configuring Media Interfaces

Media interfaces are the actual DSPs that perform RTP streaming, transcoding etc. These media interfaces are also network devices and therefore require IP configuration (IP addr, Netmask, Gateway etc).

For the case of any appliance using a D100 (media interface without an external ethernet port) the IP address assigned can be any IP because the interface will remain "hidden" within the appliance and the RTP packets end up using the IP of the signaling network interfaces.

The first step to configure media interfaces is select the media mode in which NSC will operate. There is 2 media interface IP modes: "Hidden" and "Exposed". By default the hidden mode will be chosen when you go to "Configuration -> IP Settings -> Media Interfaces". You must click "Modify" to change it and/or to perform the initial media interface discovery.

The "Hidden" mode is simpler to operate. In this mode all the media interfaces are hidden within the system and all the IP traffic generated by the media interfaces is routed/forwarded through the NSC host operating system and NATed. This mode is simpler because you don't have to worry about multiple IP addresses for your media interfaces. The media interfaces will still need an IP, but there is no possible conflict with your network as those interfaces will be hidden within NSC. You just have to choose a network that does not conflict with your real networks (ie, 192.168.168.0/24). The disadvantage of this mode is that all RTP is relayed thru the NSC host and therefore has an impact in the CPU load. Hidden mode works fine for call loads of up to 1,500 calls (3,000 call legs/sessions). If you require higher density you need to use "Exposed".

Note that appliances using D100 cards have no other option but to use "Hidden" mode because the D100 card has no external ethernet port. In practice this is not a problem because D100 users do not reach the high call loads at which "Hidden" mode is limited.

The "Exposed" mode requires more careful configuration as the media interfaces will be exposed to your network (whatever network you plug the ethernet cable to), so you must choose the IP network information carefully to avoid conflicts with other network equipment. The clear advantage of this mode is that RTP does not go through the host operating system, instead the media interfaces send the RTP directly to the external ethernet port to its destination. No interrupt or system load at all in the host operating system for any RTP stream.

The first time you modify the media interfaces configuration you must go through a discovery procedure to find all media interfaces. Unless you are using a D150 device (stand-alone media interface) you should only select the network devices named "sngdsp[N]" for discovery (see "Detect Media Interfaces" field). If you are using a D150 (or several) you must select the ethernet interface the D150 device is attached to (they should share the same broadcast domain).

If you select the "Exposed" IP mode, the web ui will allow you to configure the IP settings for the media interfaces it finds.

In "Hidden" mode you are only asked to provide a starting UDP port range for the RTP streams. You can leave the default if you don't require a particular port range.

Once you click "Save", the web ui will perform the device discovery procedure which will take a few seconds. The discovery procedure will send ethernet broadcast messages to auto-discover Sangoma media interfaces attached to the same network(s) of the selected ethernet interfaces. Once done, you wil receive a report of the hardware found.

In the example above, there is 2 network interfaces (sngdsp0 and sngdsp1) which correspond to one D500 card each. The first network interface (sngdsp0) has 4 media interfaces (also referred to as "media modules"). The network interface "sngdsp1" has attached 5 media interfaces.

Each media interface was assigned a network configuration based on the discovery page input. You can manually edit each media module network configuration by clicking "Edit".
 

Create a Domain

Domains are also known as "Realms" within SIP networks. Adding a domain is not strictly needed to use NSC, however you need it if you want to handle SIP registrations.

You can add a SIP domain by going to "Configuration -> Signaling -> Domains"

All you need to provide to add a domain is the domain name, which should be a FQDN string (ie mycompany.com).

The system will then prompt you to select whether you want to enable "Forward Registration / Authentication". If you want NSC to handle authentication of SIP requests (ie REGISTER, INVITE) using the local user database, you must choose "Disable". If you plan to forward authentication to a third-party server (ie a registrar server or PBX) you must select "Enable" and provide the information of the third-party server that will handle authentication of those SIP requests.

If you wish to create SIP accounts (users) you can click the "Add" button in the domain edit page.

You can create as many domains as you want. Later you can "Bind" a domain to one or more SIP profiles. See the SIP profile configuration for details. Note that the directory of users for that domain will only be valid when using a SIP profile that is bound to that domain.

Create a Routing Plan

A routing plan is a set of rules in XML format that determine the route every call will take. These rules are evaluated for every incoming call. You can route calls based on any SIP request headers, destination number, caller id, source IP etc.

To create a routing plan go to "Configuration -> Call Routing" and type in the name for the routing plan (also referred to as "dial plan"). Use a meaningful name, no spaces (you can use dashes or underscores instead to separate words).

In this case we named our new dialplan "new_dialplan1", then in the next screen you'll get a blank text editor.

The basic routing unit is the "<extension>" element. You can separate logical routing units in a call routing plan using <extensions>. The following routing plan receives an incoming call and connects it to another SIP
server (example IP 10.10.10.1).

This simple dialplan deserves some initial explanation.

The "<condition>" element takes care of matching on call information fields, in this case the field is "destination_number". The "expression" element is a PERL-compatible regular expression. In the above example, the expression "(.*)" matches any sequence of characters, therefore the condition accepts any string that comes in the "destination_number" field of the incoming call.

Inside the <condition> element there is a single "<action>" element (but there could be more). The <action> element accepts 2 attributes, "application" and "data". In this case the application is "bridge", this application is used to bridge an incoming leg to a newly created outbound leg to the specified destination. The "data" attribute is a string. The format of the data string depends on the application executed. For the "bridge" application the data syntax is: "sofia/<profile name>/<destination>" where in this case the profile name is the name of any SIP profile created in NSC. Note: If you want to dial through a SIP Trunk you must use slightly different syntax in the form of "sofia/gateway/<SIP Trunk name>/<destination>" with "gateway" being a keyword to specify a trunk instead of just a profile. At the moment we have not yet created any SIP profile, but we write the name for the SIP profile we plan to use later on (internal). The destination can be in the form of a SIP URL (user@host). In this case we use "$1@10.10.10.1", where the $1 variable is replaced for the first group match of our condition regular expression (the destination number).

The bridge application creates a new outbound SIP leg and connects it to the incoming call passing both media and signaling back and forth.

Note: The string "sofia" in the data for the "bridge" application may seem a bit odd, where does it come from?. This string determines that your call will be routed using the "SIP stack" (which happens to be named sofia). 

Finally click "Save" to save your newly created dial plan. You will need this dialplan when creating a SIP profile to direct incoming calls to your dialplan by binding the SIP profile to a dial plan.

Create a SIP Profile

A SIP profile is a SIP UA configuration. NSC can be configured to behave as multiple UA each with a different configuration (and therefore a different set of IP:port pair each).

You can create SIP profiles by going to "Configuration -> Signaling -> SIP Profiles".

For the SIP profile name, use a descriptive name (no spaces) such as "internal", "internal-network", "external-users" etc. Remember a SIP profile is a SIP UA that will be used to communicate with other SIP UA (ie SIP phones) or Servers (ITSP, SIP Proxies etc)

Once you click "Create", you will get a configuration page for the new SIP profile that allows you to specify all the details about your new SIP profile, including the IP information to be used, TLS/SRTP settings, etc. Pay special attention to the following fields:

IP Address: This is the IP address where NSC will listen for calls.

Transport: Most implementations will want to leave the default "UDP+TCP", this means SIP packets will be accepted in both UDP and TCP protocols.

Port: Most of the time you will want to leave the default 5060 port. However, if you are exposing this profile to the public internet, you may want to change it to something different to reduce your exposure (many malicious tools scan for for 5060 to find SIP systems connected to the internet. Although NSC comes with several protection mechanisms to detect scans, you will be better off on the internet by using a different port.

Authenticate Calls: For a quick test, you may want to disable this. This means any SIP calls (INVITE requests) will be accepted and not challenged.

Routing Plan: You have to choose the routing plan you created before ()

As long as you choose the correct configuration on those fields, the rest of the configuration can be left as default for a quick test.

The contextual help on each field will give you information about what each field in the SIP profile does.

When done configuring the SIP profile click "Save".

You can now proceed to optionally bind one or more domains to this SIP profile. When you bind a domain to a SIP profile you are attaching all the user directory of each domain bound for this SIP profile to be able to accept registrations and/or perform authentication of SIP INVITE messages based on the user/password information stored in the domain user directory (or performed via authentication forwarded according to the domain configuration). Note that in order to perform SIP authentication you have to set the "Authenticate Calls" parameter to "Enable".

To bind a domain to a SIP profile simply click "Bind" in the SIP profile modification page:

Then choose the domains you which to bind.

Finally click "Bind". You will see now the domain listed in the SIP profile page.

Apply Configuration

Once you are done configuring the system you must apply the configuration. There are 2 ways to apply them.

1. Most of the pages across the system will notify you as soon as you make changes that require to be applied. You can click there on "Apply Configuration".
2. In the navigation menu, go to "Configuration -> Management -> Apply"

It is not necessary to apply the configuration changes immediately every time you make them. You can go around the web interface making all the changes you need and then only apply them at the end when you're ready to test them or deploy them. Most of the configuration changes require a service restart, however, certain modules such as "Call Routing" and "Domain Users" allow you to apply the configuration changes without restarting the NetBorder Session Controller service. You will see a button such as "Apply Call Routing", which then applies the call routing changes without requiring a restart of the service and the changes will be taken by the running service instead immediately.

Start NetBorder Session Controller (NSC)

You can start all services from the control panel at "Overview -> Dashboard -> Control Panel". Simply click on the "Start" button for the service "NetBorder Session Controller".

Because the "NetBorder Session Controller" service is the main application service, some other services will automatically be started with it, depending on how the service is configured.

Dashboard Overview

Once services are started, you can use the "Dashboard" menus to monitor the status of all your services.

The most important menu is the "Control Panel", which you have already used to start/stop services. By default, the secure shell service (ssh) is the only one started at boot. However, any services that you turn on will be automatically started on next boot as well, if you stop any service, it will also be taken out of the boot sequence.

To check the status of your SIP profiles, go to "Overview -> Dashboard -> SIP Status"

You can then click on "View" to see more details of your profiles, including status of SIP trunks and SIP registrations. 

To check active sessions (and active calls) and its details, go to "Overview -> Dashboard -> Session Status"

Here you can see all the sessions in NSC and their status. Note that every "session" is only one leg of a regular call (typical calls have 2 legs).

Troubleshooting

All services in NSC report logging at different levels. You can consult the application logs at "Reports -> System -> NSC Logs". The most important service logs are the logs for the "NetBorder Session Controller" service, which have their own tab (See below). There you can find relevant information, including SIP messages received and sent from the system.

.

When debugging problems it may be necessary to enable debugging logs for NSC. You can find the core logging level available at "Configuration -> Core". For production systems the recommended level is "Notice", but when performing troubleshooting you should set this to "Debug".