Introduction

This Technical Guide describes the installation and configuration of the components included in the N-Squared Closed User Groups (N2CUG) platform.

This package adds Closed User Group library and runtime functionality to N2SVCD LogicApp implementations to allow users within such groups to contact each other via a short code. It does not provide any applications of its own.

Refer to the core N2SVCD documentation for general principles of and documentation regarding the base components. The N2CUG documentation only describes its own delivered additional components.

CUG Concepts

The Closed User Group service has a number of important concepts (bolded below) within it:

• Group: a named collection of zero or more Users that represents a single CUG. A single Group normally represents a single business as a consumer of the CUG’s services.
• User: the individual endpoints of a Group that are used for number translation and validation. Users always belong to a Group.
• Short Code: a non-geographic number or number prefix, usually 6 digits or fewer, that can be utilised by N2CUG to translate to a geographic endpoint stored as a Long Number or to present to a called party after reverse translation from a Long Number. When defined as a Single Number, a Short Code must be unique within a Group. Otherwise, it may overlap all other numbers freely.
• Long Number: a geographic number or number prefix, usually 7 digits or more, that can be utilised by N2CUG as a routing endpoint (after number manipulation, if necessary) for Short Code translation or for a source reference for calling party presentation. When defined as a Single Number, a Long Number must be globally unique for Actual Users and unique within a Group for Virtual Users. Otherwise, it may overlap all other numbers freely.
• Users may be Virtual, in which case they represent destinations outside the Group.
  • Actual (i.e. non-Virtual) Users must have a Short Code and a Long Number defined.
  • Virtual Users must have a Long Number defined and may optionally have a Short Code defined.
  • Virtual Users can never be the calling party in an originating call nor the called party in a terminating call.
• A User’s Short Code and Long Number may be defined in one of three formats, used preferentially in the following order:
  1. Single Number: a fully-defined number which matches only itself, e.g. 12345.
  2. Number Range: a number pattern specified as a Range Size that matches any number within its range, e.g. 12300 with Range Size 100 gives 123xx, i.e. 12300 through to 12399. Number Ranges match preferentially from lowest Range Size to highest.
  3. Number Prefix: a variable-length number specified as a prefix, e.g. 123 for 123 or 12311111 or 12345. Number Prefixes match preferentially on deepest matched digit length.
• Class: Actual Users have permissions defined as to the types of calls they can make and/or receive. These are specified as flags on the individual user as:
  • the ability to make calls within the CUG (Origination On-Net), and
  • the ability to receive calls from within the CUG (Termination On-Net), and
  • the ability to make calls outside the CUG (Origination Off-Net), and
  • the ability to receive calls from outside the CUG (Termination Off-Net).
• Number List: a uniquely-named set of Number Entries that is defined globally, with individual Groups subscribing to its content as required. Each Number List may either be a Blacklist or a Whitelist, and Groups may subscribe to as many Number Lists as necessary. Both Users and Groups may have their use of a given Number List enabled or disabled individually.
  • Blacklist: a Number List that denies service to (or from) any number on it.
  • Whitelist: a Number List that only allows service to (or from) any number on it.
• Number Entry: a number or number prefix representing an endpoint for the owning Number List. The combination of a Number Entry and whether it is a prefix is unique within a Number List.

N2CUG Logical Components

N2CUG has several logical components:

• The runtime services engine (SVC) for call control using the N2SCP and N2SIP N2SVCD applications. This includes the core CUG query
  library for ad-hoc use in other applications.
• The Graphical User Interface (GUI) for performing interactive administrative actions with CUG data.
• The API endpoint to allow programmatic provisioning actions for CUG data.
• The Database (DB) to provide persistent data storage for CUG data.

Each of these components may have multiple instances in a given deployment in order to provide service continuity or meet performance targets. They also may be installed separately or co-hosted with any other component. However, at least one instance of each core component is required for the N2CUG system as a whole to function.

N2CUG Packages

In order to provide its logical components, several packages are available:

N2CUG Installation

Installation instructions are provided for all N2CUG package types.

The root directory for all N2CUG packages is /usr/share/n2cug. Some packages may install additional files in other locations; these are called out explicitly in individual installation instructions.