Configuration of access rights of system administrators is possible through the admin panel of NGCP. In order to do that, please navigate to Settings → Administrators.

Figure 15. List of System Administrators

You have 2 options:

There are some generic attributes that have to be set for each administrator:

Figure 16. Generic System Administrator Attributes

The second set of attributes is a list of access rights that are discussed in subsequent section of the handbook.

The various access rights of administrators are shown in the figure and summarized in the table below.

Figure 17. Access Rights of System Administrators

Table 2. Access Rights of System Administrators

Label in admin list	Access Right	Description
not shown	Is superuser	The user is allowed to modify data on Reseller level and — among others — is able to modify administrators of other resellers. There should be only 1 user on Sipwise NGCP with this privilege.
Master	Is master	The user is allowed to create, delete or modify other Admins who belong to the same Reseller.
Active	Is active	The user account is active, i.e. the admin user can login on the web panel or authenticate himself on REST API; otherwise user authentication will fail.
Read Only	Read only	The user will only be able to list various data but is not allowed to modify anything. For the web interface this means that Create… and Edit buttons will be hidden or disabled. For the REST API this means that only GET, HEAD, OPTIONS HTTP request methods are accepted, and NGCP will reject those targeting data modification: PUT, PATCH, POST, DELETE.
Show Passwords	Show passwords	The user sees subscriber passwords (in plain text) on the web interface. Admin panel user passwords are stored in an unreadable way (cryptographic hash digest) in the database, while subscriber passwords are basically always stored in plain text. The latter happens on purpose, e.g. to make subscriber data migration possible.
Show CDRs	Call data	This privilege has effect on 2 items that will be displayed on admin panel of NGCP, when Subscriber → Details is selected: PBX Groups list Captured Dialogs list
Show Billing Info	Billing data	Some REST API resources that are related to billing are disabled: HTTP requests on /api/vouchers, /api/topupcash and /api/topupvoucher resources are rejected.
Lawful Intercept	Lawful intercept	If the privilege is selected then the REST API for interceptions (that is: /api/interceptions) is enabled; if the privilege is not selected then the interceptions API is disabled. This means that besides enabling LI in config.yml configuration file one also needs to enable the API via the LI privilege of an administrator user, so that NGCP can really provide LI service.

Block Lists provide a way to control which users/numbers can call or be called, based on a subscriber level, and can be found in the Call Blockings section of the subscriber preferences.

Block Lists are separated into Administrative Block Lists (adm_block_*) and Subscriber Block Lists (block_*). They both have the same behaviour, but Administrative Block Lists take higher precedence. Administrative Block Lists are only accessible by the system administrator and can thus be used to override any Subscriber Block Lists, e.g. to block certain destinations. The following break-down of the various block features apply to both types of lists.

NCOS Levels provide predefined lists of allowed or denied destinations for outbound calls of local subscribers. Compared to Block Lists, they are much easier to manage, because they are defined on a global scope, and the individual levels can then be assigned to each subscriber. Again there is the distinction for user- and administrative-levels.

If case of a conflict, when the Block Lists feature allows a number and NCOS Levels rejects the same number or vice versa, the number will be rejected.

NCOS levels can either be whitelists or blacklists.

6.2.2.2. Creating Rules per NCOS Level

To define the rules within the newly created NCOS Level, click on the Patterns button of the level.

There are 2 groups of patterns where you can define matching rules for the selected NCOS Level:

• NCOS Number Patterns: here you can define number patterns that will be matched against the called number and allowed or blocked, depending on whitelist / blacklist mode. The patterns are regular expressions.
• NCOS LNP Carriers: here you can select predefined LNP Carriers that will be allowed (whitelist mode) or prohibited (blacklist mode) to route calls to them. (See Section 6.4.1, “Local LNP Database” in the handbook for the description of LNP functionality)

Figure 18. NCOS Patterns List

In the NCOS Number Patterns view you can create multiple patterns to define your level, one after the other. Click on the Create Pattern Entry Button on top and fill out the form.

Figure 19. Create NCOS Number Pattern

In this example, we block (since the mode of the level is blacklist) all numbers starting with 439. Click the Save button to save the entry in the level.

There are 2 options that help you to easily define specific number ranges that will be allowed or blocked, depending on whitelist / blacklist mode:

• Include local area code: all subscribers within the caller’s local area, e.g. if a subscriber has country-code 43 and area-code 1, then selecting this checkbox would result in the implicit number pattern: ^431.
• Intra PBX calls within same customer: all subscribers that belong to the same PBX customer as the caller himself.

In the NCOS LNP Carriers view you can select specific LNP Carriers — i.e. carriers that host the called ported numbers — that will be allowed or blocked for routing calls to them (whitelist / blacklist mode, respectively).

Sipwise NGCP performs number matching always with the dialed number and not with the number generated after LNP lookup that is: either the original dialed number prefixed with an LNP carrier code, or the routing number.

An example of NCOS LNP Carrier pattern definition:

Figure 20. Create NCOS LNP Carrier

In the above example we created a rule that blocks calls to "LNP_Carr1" carrier, supposing we use blacklist mode of the NCOS Level.

	Currently NGCP does not support filtering of individual phone numbers in addition to LNP Carrier matching. In other words: combining phone number and LNP Carrier patterns is not possible.

There might be situations when phone number patterns may not be strictly aligned with telephony providers, for instance in case of full number portability in a country. In such cases using NCOS LNP Carriers patterns still allows for defining NCOS levels that allow / block calls to mobile numbers, for example. In order to achieve this goal you have to list all LNP carriers in the NCOS patterns that are known to host mobile numbers.

The sip:provider CE provides subscriber preference allowed_ips to restrict the IP addresses that subscriber is allowed to use the service from. If the REGISTER or INVITE request comes from an IP address that is not in the allowed list, the sip:provider CE will reject it with a 403 message. Also a voice message can be played when the call attempt is rejected (if configured).

By default, allowed_ips is an empty list which means that subscriber is not restricted. If you want to configure a restriction, navigate to Settings→Subscribers, search for the subscriber you want to edit, press Details and then Preferences and press Edit for the allowed_ips preference in the Access Restrictions section.

Press the Edit button to the right of empty drop-down list.

You can enter multiple allowed IP addresses or IP address ranges one after another. Click the Add button to save each entry in the list. Click the Delete button if you want to remove some entry.

Go to your Subscriber Preferences and click Edit on the Call Forward Type you want to set (e.g. Call Forward Unconditional).

If you select URI/Number in the Destination field, you also have to set a URI/Number. The timeout defines for how long this destination should be tried to ring.

If you want multiple destinations to be executed one after the other, you need to change into the Advanced View when editing your call forward. There, you can select multiple Destination Set/Time Set pairs to be executed.

A Destination Set is a list of destinations to be executed one after another.

A Time Set is a time definition when to execute this Destination Set.

6.3.2.2. Configuring Time Sets

Click on Manage Time Sets in the advanced call-forward menu to see a list of available time sets. By default there are none, so you have to create one.

You need to provide a Name, and a list of Periods where this set is active. If you only set the top setting of a date field (like the Year setting in our example above), then it’s valid for just this setting (like the full year of 2013 in our case). If you provide the bottom setting as well, it defines a period (like our Month setting, which means from beginning of April to end of September). For example, if a CF is set with the following timeset: "hour { 10-12 } minute { 20-30 }", the CF will be matched within the following time ranges:

• from 10.20am to 10:30am
• from 11.20am to 11:30am
• from 12.20am to 12:30am

	the period is a through definition, so it covers the full range. If you define an Hour definition 8-16, then this means from 08:00 to 16:59:59 (unless you filter the Minutes down to something else).

If you close the Time Sets management, you can assign your new time set to the call forwards you’re configuring.

The local LNP database provides the possibility to define LNP Carriers (the owners of certain ported numbers or number blocks) and their corresponding LNP Numbers belonging to those carriers. It can be configured on the admin panel in Settings→Number Porting or via the API. The LNP configuration can be populated individually or via CSV import/export both on the panel and the API.

6.4.1.4. LNP Routing Procedure

Calls to non-authoritative Carriers

When a call arrives at the system, the calling and called party numbers are first normalized using the Inbound Rewrite Rules for Caller and Inbound Rewrite Rules for Callee within the rewrite rule set assigned to the calling party (a local subscriber or a peer).

If the called party number is not assigned to a local subscriber, or if the called party is a local subscriber and has the subscriber/domain preference lnp_for_local_sub set, the LNP lookup logic is engaged, otherwise the call proceeds without LNP lookup. The further steps assume that LNP is engaged.

If the call originated from a peer, and the peer preference caller_lnp_lookup is set for this peer, then an LNP lookup is performed using the normalized calling party number. The purpose for that is solely to find the LNP prefix of the calling peer, which is then stored as source_lnp_prefix in the CDR. If the LNP lookup does not return a result (e.g. the calling party number is not populated in the local LNP database), but the peer preference default_lnp_prefix is set for the originating peer, then the value of this preference is stored in source_lnp_prefix of the CDR.

Next, an LNP lookup is performed using the normalized called party number. If no number is found (using a longest match), no further manipulation is performed.

If an LNP number entry is found, and the Routing Number is set, the called party number is replaced by the routing number. Also, if the Authoritative flag is set in the corresponding LNP Carrier, and the called party number is not assigned to a local subscriber, the call is rejected. This ensures that numbers allocated to the system but not assigned to subscribers are dropped instead of routed to a peer.

If the system is serving a local subscriber with only the routing number assigned (but not e.g. the premium number mapping to this routing number), the subscriber will not be found and the call will either be rejected if the called party premium number is within an authoritative carrier, or the call will be routed to a peer. This is due to the fact that the subscriber lookup is performed with the dialled number, but not the routing number fetched during LNP. So make sure to assign e.g. the premium number to the local subscriber (optionally in addition to the routing number if necessary using alias numbers) and do not use the LNP routing number mechanism for number mapping to local subscribers.

Next, if the the LNP carrier does not have the Skip Rewriting option set, the LNP Rewrite Rules for Callee are engaged. The rewrite rule set used is the one assigned to the originating peer or subscriber/domain via the rewrite_rule_set preference. The variables available in the match and replace part are, beside the standard variables for rewrite rules:

• ${callee_lnp_prefix}: The prefix stored in the LNP Carrier
• ${callee_lnp_basenumber}: The actual number entry causing the match (may be shorter than the called party number due to longest match)

Typically, you would create a rewrite rule to prefix the called party number with the callee_lnp_prefix by matching ^([0-9]+)$ and replacing it by ${callee_lnp_prefix}\1.

Once the LNP processing is completed, the system checks for further preferences to finalize the number manipulation. If the originating local subscriber or peer has the preference lnp_add_npdi set, the Request URI user-part is suffixed with ;npdi. Next, if the preference lnp_to_rn is set, the Request URI user-part is suffixed with ;rn=LNP_ROUTING_NUMBER, where LNP_ROUTING_NUMBER is the Routing Number stored for the number entry in the LNP database, and the originally called number is kept in place. For example, if lnp_to_rn is set and the number 1800123 is called, and this number has a routing number 1555123 in the LNP database, the resulting Request-URI is sip:1800123;rn=1555123@example.org.

Finally, the destination_lnp_prefix in the CDR table is populated either by the prefix defined in the Carrier of the LNP database if a match was found, or by the default_lnp_prefix prefrence of the destination peer or subscriber/domain.

Emergency numbers per geographic location are mapped to different routing prefixes not deriveable from an area code or the emergency number itself. This is why a global emergency mapping table related to resellers is introduced, allowing to map emergency numbers to their geographically dependent routing numbers.

The geographic location is referenced by a location ID, which has to be populated by a north-bound provisioning system. No towns, areas or similar location data is stored on the NGCP platform. The locations are called Emergency Containers on NGCP.

The actual emergency number mapping is done per location (per Emergency Container), using the so-called Emergency Mapping entries. An Emergency Mapping entry assigns a routing prefix, valid only in a geographic area, to a generic emergency number (for example 112 in Europe, 911 in the U.S.A.) or a country specific one (for example 133).

	As of mr4.5 version, the NGCP performs an exact match on the emergency number in the emergency routing table.

Emergency Containers may be assigned to various levels of the client hierarchy within NGCP. The following list shows such levels with each level overriding the settings of the previous one:

	Please be aware that Customer Location is not necessarily identical to the "location" identified through an Emergency Container.

Once the emergency routing prefix has been retrieved from the emergency mapping table, call processing continues in the same way as in case of simple emergency call handling.

The administrative web panel of NGCP provides the configuration interface for emergency mapping. Please navigate to Settings → Emergency Mapping menu item first, in order to start configuring the mapping.

An Emergency Container must be created, before the mapping entries can be defined. Press Create Emergency Container to start this. An example of a container is shown here:

Figure 22. Creating an Emergency Container

You have to select a Reseller that this container belongs to, and enter a Name for the container, which is an arbitrary text.

	The platform administrator has to create as many containers as the number of different geographic areas (locations) the subscribers are expected to be in.

As the second step of emergency mapping provisioning, the Emergency Mapping entries must be created. Press Create Emergency Mapping to start this step. An example is shown here:

Figure 23. Creating an Emergency Mapping Entry

The following parameters must be set:

Once all the necessary emergency mappings have been defined, the platform administrator will see a list of containers and mapping entries:

Figure 24. Emergency Mapping List

The emergency number mapping is now defined. As the next step, the platform administrator has to assign the emergency containers to Customers / Domains / Customer Locations or Subscribers. We’ll take an example with a Customer: select the customer, then navigate to Details → Preferences → Number Manipulations. In order to assign a container, press the Edit button and then select one container from the drop-down list:

Figure 25. Assigning an Emergency Mapping Container

Rewrite Rules for Emergency Mapping

Once emergency containers and emergency mapping entries are defined, the NGCP administrator has to ensure that the proper number manipulation takes place, before initiating any emergency call towards peers.

	Please don’t forget to define the rewrite rules for peers — particularly: Outbound Rewrite Rules for Callee — as described in Normalize Emergency Calls for Peers Section 5.6.5.3, “Normalize Emergency Calls for Peers” section of the handbook.

6.5.2.2. Bulk Upload or Download of Emergency Mapping Entries

The Sipwise NGCP offers the possibility to upload / download emergency mapping entries in form of CSV files. This operation is available for each reseller, and is very useful if a reseller has many mapping entries.

Downloading Emergency Mapping List

One has to navigate to Settings → Emergency Mapping menu and then press the Download CSV button to get the list of mapping entries in a CSV file. First the reseller must be selected, then the Download button must be pressed. As an example, the entries shown in "Emergency Mapping List" picture above would be written in the file like here below:

EmergCont_1,133,E1_133_
EmergCont_1,144,E1_144_
EmergCont_2,133,E2_133_

The CSV file has a plain text format, each line representing a mapping entry, and contains the following fields:

• Container name, as defined in Emergency Containers
• Emergency Number
• Emergency Prefix

Uploading Emergency Mapping List

Uploading a CSV file with emergency mapping entries may be started after pressing the Upload CSV button. The following data must be provided:

• Reseller: selected from the list
• Upload mapping: the CSV file must be selected after pressing the Choose File button
• Purge existing: an option to purge existing emergency mapping entries that belong to the selected reseller, before populating the new mapping data from the file

Figure 26. Uploading Emergency Mapping Data

The CSV file for the upload has the same format as the one used for download.

Adding additional SIP headers to the initial INVITEs relayed to the callee (second leg) is possible by modifying the following template file: /etc/ngcp-config/templates/etc/ngcp-sems/etc/ngcp.sbcprofile.conf.customtt.tt2. The following section can be changed:

header_filter=whitelist
header_list=[%IF kamailio.proxy.debug == "yes"%]P-NGCP-CFGTEST,[%END%]
P-R-Uri,P-D-Uri,P-Preferred-Identity,P-Asserted-Identity,Diversion,Privacy,
Allow,Supported,Require,RAck,RSeq,Rseq,User-Agent,History-Info,Call-Info
[%IF kamailio.proxy.presence.enable == "yes"%],Event,Expires,
Subscription-State,Accept[%END%][%IF kamailio.proxy.allow_refer_method
== "yes"%],Referred-By,Refer-To,Replaces[%END%]

By default the system will remove from the second leg all the SIP headers which are not in the above list. If you want to keep some additional/custom SIP headers, coming from the first leg, into the second leg you just need to add them at the end of the header_list= list. After that, as usual, you need to apply the changes. In this way the system will keep your headers in the INVITE sent to the destination subscriber/peer.

	DO NOT TOUCH the list if you don’t know what you are doing.

Sometimes you may need to filter some audio CODEC from the SDP payload, for example if you want to force your subscribers to do not talk a certain codecs or force them to talk a particular one. To achieve that you just need to change the /etc/ngcp-config/config.yml, in the following section:

sdp_filter:
      codecs: PCMA,PCMU,telephone-event
      enable: yes
      mode: whitelist

In the example above, the system is removing all the audio CODECS from the initial INVITE except G711 alaw,ulaw and telephone-event. In this way the callee will be notified that the caller is able to talk only PCMA. Another example is the blacklist mode:

sdp_filter:
      codecs: G729,G722
      enable: yes
      mode: blacklist

In this way the G729 and G722 will be removed from the SDP payload. In order to apply the changes, as usual, you need to run ngcpcfg apply Enable CODEC filtering .

It may be useful and mandatory - specially with NGN interconnection - to enable SIP History header and/or Diversion header for outbound requests to a peer or even for on-net calls. In order to do so, you should enable the following preferences in Domain’s and Peer’s Preferences:

For the purpose of external SIP-PBX interconnect with sip:provider CE the platform admin should create a subscriber with multiple aliases representing the numbers and number ranges served by the SIP-PBX.

To configure the Subscriber, go to Settings→Subscribers and click Details on the row of your subscriber. There, click on the Preferences button on top.

You should look into the Number Manipulations and Access Restrictions sections in particular, which control the calling and called number presentation.

Enable preference Number Manipulations→e164_to_ruri for routing inbound calls to SIP-PBX. This ensures that the Request-URI will comprise a SIP-URI containing the dialed alias-number as user-part, instead of the user-part of the registered AOR (which is normally a static value).

The following sections describe the recommended configuration for correct call routing and CLI presentation according to the SIPconnect 1.1 recommendation.

6.7.3.1. Rewrite rules

The SIP PBX by default inherits the domain dialplan which usually has rewrite rules applied to normal Class 5 subscribers with inbound rewrite rules normalizing the dialed number to the E.164 standard. If most users of this domain are Class 5 subscribers the dialplan may supply calling number in national format - see Section 5.6, “Configuring Rewrite Rule Sets”. While the SIP-PBX trunk configuration can be sometimes amended it is a good idea in sense of SIPconnect recommendation to send only the global E.164 numbers.

Moreover, in mixed environments with the sip:provider CE Cloud PBX sharing the same domain with SIP trunking (SIP-PBX) customers the subscribers may have different rewrite rules sets assigned to them. The difference is caused by the fact that the dialplan for Cloud PBX is fundamentally different from the dialplan for SIP trunks due to extension dialing, where the Cloud PBX subscribers use the break-out code to dial numbers outside of this PBX.

The SIPconnect compliant numbering plan can be accommodated by assigning Rewrite Rules Set to the SIP-PBX subscriber. Below is a sample Rewrite Rule Set for using the global E.164 numbers with plus required for the calling and called number format compliant to the recommendation.

Inbound Rewrite Rule for Caller

• Match Pattern: ^(00|\+)([1-9][0-9]+)$
• Replacement Pattern: \2
• Description: International to E.164
• Direction: Inbound
• Field: Caller

Inbound Rewrite Rule for Callee

• Match Pattern: ^(00|\+)([1-9][0-9]+)$
• Replacement Pattern: \2
• Description: International to E.164
• Direction: Inbound
• Field: Callee

Outbound Rewrite Rule for Caller

• Match Pattern: ^([1-9][0-9]+)$
• Replacement Pattern: +\1
• Description: For the calls to SIP-PBX add plus to E.164
• Direction: Outbound
• Field: Caller

Outbound Rewrite Rule for Callee

• Match Pattern: ^([1-9][0-9]+)$
• Replacement Pattern: +\1
• Description: For the calls to SIP-PBX add plus to E.164
• Direction: Outbound
• Field: Callee

Assign the aforementioned Rewrite Rule Set to the SIP-PBX subscribers.

	Outbound Rewrite Rules for Callee shall NOT be applied to the calls to normal SIP UAs like IP phones since the number with plus does not correspond to their SIP username.

6.7.3.3. Forwarding number

The following is our common configuration that covers the calling number presentation in a variety of use-cases, including the incoming calls, on-net calls and Call Forward by the platform:

• Domain’s Preferences: inbound_uprn = Forwarder’s NPN
• Domain’s Preferences: outbound_from_user = UPRN (if set) or User-Provided Number
• Domain’s Preferences: outbound_pai_user = UPRN (if set) or Network-Provided Number
• Domain’s Preferences: outbound_history_info = UPRN (if the called user expects History-Info header)
• Domain’s Preferences: outbound_diversion = UPRN (if the called user expects Diversion header)
• Domain’s Preferences: outbound_to_user = Original (Forwarding) called user if the callee expects the number of the subscriber forwarding the call, otherwise leave default.

The above parameters can be tuned to operator specifics as required. You can of course override these settings in the Subscriber Preferences if particular subscribers need special settings.

	On outgoing call from SIP-PBX subscriber the Network-Provided Number (NPN) is set to the cli preference prefilled with main E.164 number. In order to have the full alias number as NPN on outgoing call set preference extension_in_npn = Y.

Externally forwarded call. If the call forward takes place inside the SIP-PBX it can use one of the following specification for signaling the diversion number to the platform:

• using Diversion method (RFC 5806): configure Subscriber’s Prefererences: inbound_uprn = Forwarder’s NPN / Received Diversion
• using History-Info method (RFC 7044): NGCP platform extends the History-Info header received from the PBX by adding another level of indexing according to the specification RFC 7044.

SIP-PBX can use either Static or Registration Mode. While SIPconnect 1.1 continues to require TLS support at MUST strength, one should note that using TLS for signaling does not require the use of the SIPS URI scheme. SIPS URI scheme is obsolete for this purpose.

Static Mode. While SIPconnect 1.1 allows the use of Static mode, this poses additional maintenance overhead on the operator. The administrator should create a static registration for the SIP-PBX: go to Susbcribers, Details→Registered Devices→Create Permanent Registration and put address of the SIP-PBX in the following format: sip:username@ipaddress:5060 where username=username portion of SIP URI and ipaddress = IP address of the device.

Registration Mode. It is recommended to use the Registration mode with SIP credentials defined for the SIP-PBX subscriber.

	The use of RFC 6140 style "bulk number registration" is discouraged. The SIP-PBX should register one AOR with email-style SIP URI. The sip:provider CE will take care of routing the aliases to the AOR with e164_to_ruri preference.

6.7.4.1. Trusted Sources

If a SIP-PBX cannot perform the digest authentication, you can authenticate it by its source IP address in sip:provider CE. To configure the IP-based authentication, go to the subscriber’s preferences (Details→ Preferences→Trusted Sources) and specify the IP address of the SIP-PBX in the Source IP field.

To authenticate multiple subscribers from the same IP address, use theFrom field to distinguish these subscribers.

When this feature is configured for a subscriber, the sip:provider CE authenticates all calls that arrive from the specified IP address without challenging them.

	If the same IP address and the FROM field are mistakenly specified as trusted for different subscribers, the sip:provider CE will not know which subscriber to charge for the call and will randomly select one.

For a subscriber to manage his voicebox via IVR, there are two ways to access the voicebox. One is to call the URI voicebox@yourdomain from the subscriber itself, allowing password-less access to the IVR, as the authentication is already done on SIP level. The second is to call the URI voiceboxpass@yourdomain from any number, causing the system to prompt for a mailbox and the PIN. The PIN can be set in the Voicemail and Voicebox section of the Subscriber Preferences.

The following list shows you how the voicebox menu is structured.

A message/greeting is a short message that plays before the caller is allowed to record a message. The message is intended to let the caller know that you are not able to answer their call. It can also be used to convey other information like when you will be available, other methods to contact you, or other options that the caller can use to receive assistance.

The IVR menu has three types of greetings.

The Voicemail system allows you to save and organize your messages into folders. There can be up to ten folders.

This section shows flowcharts of calls to the voicemail system. Flowcharts contain the name of prompts as they are identified among Asterisk voice prompts.

6.9.5.1. Listening to New Messages

Figure 27. Flowchart of Listening to New Messages

6.9.5.2. Changing Voicemail Folders

Figure 28. Flowchart of Changing Voicemail Folders

6.9.5.3. Mailbox Options

Figure 29. Flowchart of Changing Mailbox Options

6.9.5.4. Leaving a Message

Figure 30. Flowchart of Leaving a Voice Message

The call error announcements are grouped under Early Rejects section. Unfold the section and click Upload next to the sound handles (Names) that you want to use. Choose a WAV file from your file system, and click the Loopplay setting if you want to play the file in a loop instead of just once. Click Save to upload the file.

The call error announcements are played to the user in early media hence the name "Early Reject". If you don’t provide the sound files for any handles they will not be used and the sip:provider CE will fallback to sending the error response code back to the user.

The exact error status code and text are configurable in the /etc/ngcp-config/config.yml file, in kamailio.proxy.early_rejects section. Please look for the announcement handle listed in below table in order to find it in the configuration file.

There are some early reject scenarios when either no voice announcement is played, or a fixed announcement is played. In either case a SIP error status message is sent from NGCP to the calling party. It is possible to configure the exact status code and text for such cases in the /etc/ngcp-config/config.yml file, in kamailio.proxy.early_rejects section. The below table gives an overview of those early reject cases.

Go to your Subscriber Preferences and click Edit on the Call Forward Type you want to set (e.g. Call Forward Unconditional).

You should select Conference option in the Destination field and leave the URI/Number empty. The timeout defines for how long this destination should be tried to ring.

Sound Sets can be defined in Settings→Sound Sets. To create a new Sound Set, click Create Sound Set. Then click the Files button.

Upload the following files:

	You may use 8 or 16 bit mono WAV audio files.

Then set the preference sound_set on the Domain or Subscriber level in order to assign the Sound Set you have just created to the subscriber (as usual the subscriber preference overrides the domain one).

There are 2 ways of joining a conference: with or without PIN code. The actual way of joining the conference depends on Subscriber settings. A subscriber who has activated the conference through call forwarding may set a PIN in order to protect the conference from unauthorized access. To activate the PIN one has to enter a value in Subscriber → Details → Preferences → Internals → conference_pin field.

Figure 31. Setting Conference PIN

In case the PIN protection for the conference is activated, when someone calls the subscriber who has enabled the conference, the caller is prompted to enter the PIN of the conference. Upon the successful entry of the PIN the caller hears the announcement that he is going to be placed into the conference and at the same time this is announced to all participants already in the conference.

The following 2 sections show flowcharts with voice prompts that are played to a caller when he dials the conference.

6.12.4.1. Conference Flowchart with PIN Validation

Figure 32. Flowchart of Conference with PIN Validation

6.12.4.2. Conference Flowchart without PIN

Figure 33. Flowchart of Conference without PIN

To enable the feature first edit config.yml and enable there apps: malicious_call: yes and kamailio: store_recentcalls: yes. The latter option enables kamailio to store recent calls per subscrbriber UUID in the redis DB (the amount of stored recent calls will not exceed the amount of provisionined subscribers).

Next step is to create a system sound set for the feature. In Settings→Sound Sets either use your already existing Sound Set or create a new Sound Set and then assign it to your domain or subscribers. In the Sound Set there is a fileset malicious_call_identification→mailicious_call_report for that purpose.

Once the Sound Set is created the Subscriber’s Preferences Malicious Call Identification must be enabled under Subcriber → Preferences → Applications menu. The same parameter can be set in the Customer’s preferences to enable this feature for all its subscribers.

The final step is to create a new Rewrite Rule and to route calls to, for instance *123 → MCID application. For that you create a Calee Inbound rewrite rule ^(\*123)$ → malicious_call

Finaly you run ngcpcfg apply Enabling MCID to recreate the templates and automatically restart depended services.

As a subscriber, to report a malicious call you call to either malicious_call or to your custom number assigned for that purpose. Please note that you can report only your last received call. You will hear the media reply from the Sound Set you have previosuly configured.

To check reported malicious calls as the plafrom operator open Settings→Malicious Calls tab where you will see a list of registered calls. You can selectively delete records from the list and alternatively you can manage the reported calls by using the REST API.

By default the expiration time for the most recent call per subscriber is 3600 seconds (1 hour). If you wish to prolong or shorten the expiration time open constants.yml and set there recentcalls: expire: 3600 to a new value, and issue ngcpcfg apply Enabling MCID afterwards.

Profile sets define containers for profiles. The idea is to define profile sets with different profiles by the administrator (or the reseller, if he is permitted to do so). Then, a subscriber with administrative privileges can re-assign profiles within his profile sets for the subscribers of his customer account.

Profile Sets can be defined in Settings→Subscriber Profiles. To create a new Profile Set, click Create Subscriber Profile Set.

You need to provide a reseller, name and description.

To create Profiles within a Profile Set, hover over the Profile Set and click the Profiles button.

Profiles within a Profile Set can be created by clicking the Create Subscriber Profile button.

Checking the Default Profile option causes this profile to get assigned automatically to all subscribers, who have the profile set assigned. Other options define the user preferences which should be made available to the subscriber.

	When the platform administrator selects Preferences of the Subscriber Profile he will get an empty page like in the picture below, if none or only certain options are selected in the Subscriber Profile.

Some of the options, like ncos (NCOS level), will enable the definition of that preference within the Subscriber Profile Preferences. Thus all subscribers who have this profile assigned to will have the preference activated by default. The below picture shows the preferences linked to the sample Subscriber Profile:

Invoices can be requested for generation, searched, downloaded and deleted in the invoices interface.

To request invoice generation for the particular customer and period press "Create invoice" button. On the invoice creation form following parameters are available for selection:

All form fields are mandatory.

Generated invoice can be downloaded as pdf file.

To do it press button "Download" against invoice in the invoice management interface.

Respectively press on the button "Delete" to delete invoice.

Invoice template defines structure and look of the generated invoices. The sip:provider CE makes it possible to create some invoice templates. Multiple invoice templates can be used to send invoices to the different customers using different languages.

	At least one invoice template should be created to enable invoice generation. Each customer has to be associated to one of the existent invoice template, otherwise invoices will be not generated for this customer.

Customer can be linked to the invoice template in the customer interface.

6.16.2.2. Invoice Template Content

Invoice template is a XML SVG source, which describes content, look and position of the text lines, images or other invoice template elements. The sip:provider CE provides embedded WYSIWYG SVG editor svg-edit 2.6 to customize default template. The sip:provider CE svg-edit has some changes in layers management, image edit, user interface, but this basic introduction still may be useful.

Template refers to the owner reseller contact ("rescontact"), customer contract ("customer"), customer contact ("custcontact"), billing profile ("billprof"), invoice ("invoice") data as variables in the "[%%]" mark-up with detailed information accessed as field name after point e.g. [%invoice.serial%]. During invoice generation all variables or other special tokens in the "[% %]" mark-ups will be replaced by their database values.

Press on "Show variables" button on invoice template content page to see full list of variables with the fields:

You can add/change/remove embedded variables references directly in main svg-edit window. To edit text line in svg-edit main window double click on the text and place cursor on desired position in the text.

After implementation of the desired template changes, invoice template should be saved Section 6.16.2.3, “Save and preview invoice template content”.

To return to the sip:provider CE invoice template default content you can press on the "Discard changes" button.

	"Discard changes" operation can’t be undone.

Layers

Default template contains three groups elements (<g/>), which can be thinked of as pages, or in terms of svg-edit - layers. Layers are:

• Background: special layer, which will be repeated as background for every other page of the invoice.
• Summary: page with a invoice summary.
• CallList: page with calls made in a invoice period. Is invisible by default.

To see all invoice template layers, press on "Layers" vertical sign on right side of the svg-edit interface:

Side panel with layers list will be shown.

One of the layers is active, and its element can be edited in the main svg-edit window. Currently active layer’s name is bold in the layers list. The layers may be visible or invisible. Visible layers have "eye" icon left of their names in the layers list.

To make a layer active, click on its name in the layers list. If the layer was invisible, its elements became visible on activation. Thus you can see mixed elements of some layers, then you can switch off visibility of other layers by click on their "eye" icons. It is good idea to keep visibility of the "Background" layer on, so look of the generated page will be seen.

Edit SVG XML source

Sometimes it may be convenient to edit svg source directly and svg-edit makes it possible to do it. After press on the <svg> icon in the top left corner of the svg-edit interface:

SVG XML source of the invoice template will be shown.

SVG source can be edited in place or just copy-pasted as usual text.

	Template keeps sizes and distances in pixels.

When edit svg xml source, please change very carefully and thinkfully things inside special comment mark-up "<!--{ }-→". Otherwise invoice generation may be broken. Please be sure that document structure repeats default invoice template: has the same groups (<g/>) elements on the top level, text inside special comments mark-up "<!--{ }-→" preserved or changed appropriately, svg xml structure is correct.

To save your changes in the svg xml source, first press "OK" button on the top left corner of the source page:

And then save invoice template changes Section 6.16.2.3, “Save and preview invoice template content”.

	You can copy and keep the svg source of your template as a file on the disk before start experimenting with the template. Later you will be able to return to this version replacing svg source.

Change logo image

• Make sure that "Select tool" is active.
• Select default logo, clicking on the logo image.
• Press "Change image" button, which should appear on the top toolbar.

After image uploaded save invoice template changes Section 6.16.2.3, “Save and preview invoice template content”.

6.16.2.3. Save and preview invoice template content

To save invoice template content changes press button "Save SVG".

You will see message about successfully saved template. You can preview your invoice look in PDF format. Press on "Preview as PDF" button.

Invoice preview will be opened in the new window.

	Example fake data will be used for preview generation.

Besides generating invoices on demand using web interface, Sipwise NGCP contains an invoice generator script that allows for producing invoices automatically, at regular intervals, for all customers, using the cron system tool.

	Automated invoice generation is deprecated since mr4.0 release of NGCP. The invoice generator script will damage billing records in the database. The rest of the description in "Invoices Generation" section is kept in the handbook for reference purposes only.

Script is located at: /usr/share/ngcp-panel/tools/generate_invoices.pl

In short:

perl /usr/share/ngcp-panel/tools/generate_invoices.pl --send --prevmonth

perl /usr/share/ngcp-panel/tools/generate_invoices.pl --prevmonth

perl /usr/share/ngcp-panel/tools/generate_invoices.pl --sendonly --prevmonth

perl /usr/share/ngcp-panel/tools/generate_invoices.pl --stime="2015-01-01 00:00:00"  --etime="2015-01-31 00:00:00" --regenerate

Some not obvious options:

To see all possible script options use --help or --man:

/usr/share/ngcp-panel/tools/generate_invoices.pl --man

Script will be run periodically as configured by the cron files. Cron files templates can be found at:

After applying your configuration cron file will be located at:

Script uses configuration file located at: /etc/ngcp-invoice-gen/invoice-gen.conf

Except common DB connection configuration following specific options can be defined in the config file:

Comma separated resellers id. Invoice generation will be performed only for the specified resellers.

Comma separated customers id. Invoice generation will be performed only for the specified customers.

Usually is not necessary. Script option --prevmonth will define correct start and end time for the previous month billing period. Generated invoices will include all calls with call start time more then STIME value and less the ETIME value.

Usually is not necessary. Script option --prevmonth will define correct start and end time for the previous month billing period. Generated invoices will include all calls with call start time more then STIME value and less the ETIME value.

Generated invoices will be immediately sent to the customers.

Invoices, already sent to the customers, will be sent again.

Already presented invoices files will be generated again. Otherwise they will stay intouched.

Generate invoices for the already terminated customers too.

Purposed for notifications about invoices generation fails. Not in use now.

All generated invoices can be seen in the invoice management interface Section 6.16.1, “Invoices Management”.

On request each invoice will be sent to the proper customer as e-mail with the invoice PDF in the attachment. Letter content is defined by the invoice email template.

The sip:provider CE makes it possible to customize content of the emails sent on the following actions:

Default email templates for each of the email events are inserted on the initial sip:provider CE database creation. Content of the default template is described in the corresponding sections. Default email templates aren’t linked to any reseller and can’t be changed through sip:provider CE Panel. They will be used to initialize default templates for the newly created reseller.

Each email template refers to the values from the database using special mark-ups "[%" and "%]". Each email template has fixed set of the variables. Variables can’t be added or changed without changes in the sip:provider CE Panel code.

Email will be sent after subscriber or subscriber administrator requested password reset for the subscriber account. Letter will be sent to the subscriber. If subscriber doesn’t have own email, letter will be sent to the customer owning the subscriber.

Default content of the password reset email template is:

Dear Customer,

Please go to [%url%] to set your password and log into your self-care interface.

Your faithful Sipwise system

--
This is an automatically generated message. Do not reply.

Following variables will be provided to the email template:

Email will be sent on the new subscriber creation. Letter will be sent to the newly created subscriber if it has an email. Otherwise, letter will be sent to the customer who owns the subscriber.

	By default email content template is addressed to the customer. Please consider this when create the subscriber with an email.

Dear Customer,

A new subscriber [%subscriber%] has been created for you.

Your faithful Sipwise system

--
This is an automatically generated message. Do not reply.

Following variables will be provided to the email template:

Dear Customer,

Please find your invoice #[%invoice.serial%] for [%invoice.period_start_obj.month_name%], [%invoice.period_start_obj.year%] in attachment of this letter.

Your faithful Sipwise system

--
This is an automatically generated message. Do not reply.

Variables passed to the email template:

	Invoice fields
	[%invoice.serial%] [%invoice.amount_net%] [%invoice.amount_vat%] [%invoice.amount_total%] [%invoice.period_start_obj%] [%invoice.period_end_obj%] The fields [%invoice.period_start_obj%] and [%invoice.period_end_obj%] provide methods of the perl package DateTime for the invoice start date and end date. Further information about DateTime can be obtained from the package documentation: man DateTime

Contact fields example for the "provider". Replace "provider" to client to access proper "customer" contact fields.

[%provider.gender%] [%provider.firstname%] [%provider.lastname%] [%provider.comregnum%] [%provider.company%] [%provider.street%] [%provider.postcode%] [%provider.city%] [%provider.country%] [%provider.phonenumber%] [%provider.mobilenumber%] [%provider.email%] [%provider.newsletter%] [%provider.faxnumber%] [%provider.iban%] [%provider.bic%] [%provider.vatnum%] [%provider.bankname%] [%provider.gpp0 - provider.gpp9%]

Email templates linked to the resellers can be customized in the email templates management interface. For the administrative account email templates of all the resellers will be shown. Respectively for the reseller account only owned email templates will be shown.

To create create new email template press button "Create Email Template".

On the email template form all fields are mandatory:

You can change any of the codes (but not the format) in /etc/ngcp-config/config.yml in the section sems→vsc. After the changes, execute ngcpcfg apply 'changed VSC codes'.

	If you have the EMTAs under your control, make sure that the specified VSCs don’t overlap with EMTA-internal VSCs, because the VSC calls must be sent to the NGCP via SIP like normal telephone calls.