Closed User Groups

Introduction

The DSG-SCP platform provides a Closed User Group service that allows users within such groups to contact each other via a short code. This processing is optionally done as an external action prior to billing interaction.

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 the DSG-SCP 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 the DSG-SCP 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.

CUG Call Processing

When a call requiring CUG processing is received, the following logic is used:

1. While no User is found, attempt to find a User (in order):
   1. By Long Number as a Single Number, then
   2. By Long Number as a Number Range in ascending Range Size order, then
   3. By Long Number as a Number Prefix in descending Prefix size, then
   4. If enabled, repeat the previous three steps using Short Code instead of Long Number.
2. If no User is found, ignore further processing and apply the no_user_found action rules.
3. While no match to another User is found, attempt to find another User (in order):
   1. If enabled, by Short Code as an Actual User by Single Number, then Number Range, then Number Prefix, then
   2. By Long Number as an Actual User by Single Number, then Number Range, then Number Prefix, then
   3. If enabled, by Short Code as a Virtual User by Single Number, then Number Range, then Number Prefix, then
   4. By Long Number as a Virtual User by Single Number, then Number Range, then Number Prefix.
4. If configured, while no Number List is found, attempt to find a Number List and check (in order):
   1. If both a Blacklist and a Whitelist match the other party and the Blacklist matches more deeply, ignore further processing and apply the not_allowed_list action rules.
   2. If both a Blacklist and a Whitelist match the other party and the Whitelist matches more deeply, skip further list processing.
   3. If only a Blacklist matches the other party, ignore further processing and apply the not_allowed_list action rules.
   4. If only a Whitelist matches the other party, skip further list processing.
   5. If no Number Lists match the other party and other Whitelists exist for the User’s Group, ignore further processing and apply the not_allowed_list action rules.
5. If the call is not allowed by the User’s Origination/Termination On-Net/Off-Net settings, ignore further processing and apply the not_allowed_user action rules.
6. If a match was found:
   1. If the matched other User has a non-zero Range Size, update its Long Number and Short Code suffix according to the received input digits.
   2. If in an originating call, set the Connect destinationRoutingAddress to the Long Number of the matched other User.
   3. If in a terminating call, and if configured, and if it exists, set the caller Short Code in the Connect callingPartyNumber.
   4. If configured, send the appropriate FurnishChargingInformation/SendChargingInformation message accordingly with the Connect/Continue.

Note that database information is not cached; changes are reflected immediately.

Refer to the CUG configuration documentation for additional detail.

CUG API

The N-Squared DSG-SCP Closed User Groups solution supports a REST API for the management of CUG data. The API is documented in OpenAPI (Swagger) API documents (yaml formatted).

Access the full API here.