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.
You can navigate using either the left menu or the top-level menu, both provide a quick access to all system configuration sections.
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.
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.
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".
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).
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.
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.
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.
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)
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.
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.
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.
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.
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).
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".