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.

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.

7.2.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.

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.

7.4.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 6.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.

7.4.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.

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.

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 subscriber, causing the system to prompt for a mailbox and a PIN.

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.

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.

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).

It is mandatory to configure the PIN code for entrance to the conference on the same subscriber which has the Call Forwarding active. Responsible for this is the conference_pin preference in the Internals section of subscriber preferences.

When calling the conference IVR you are requested to enter this PIN. Upon the successful entry of the PIN the caller hears the announcement that he is going to be placed into a conference and at the same time this is announced to all participants in the conference.

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.