3. Administrative Configuration

To be able to configure your first test clients, you will need a SIP domain and some subscribers in this domain. Throughout this steps, let’s assume you’re running the NGCP on the IP address 1.2.3.4, and you want this IP to be used as SIP domain. This means that your subscribers will have an URI like user1@1.2.3.4.


	You can of course set up a DNS name for your IP address (e.g. letting sip.yourdomain.com point to 1.2.3.4) and use this DNS name throughout the next steps, but we’ll keep it simple and stick directly with the IP as a SIP domain for now.


	Once you started adding subscribers to a SIP domain, and later decide to change the domain, e.g. from 1.2.3.4 to sip.yourdomain.com, you’ll need to recreate all your subscribers in this new domain. It’s currently not possible to easily change the domain part of a subscriber.

Go to the Administrative Web Panel (Admin Panel) running on https://<ce-ip>:1443/ and follow the steps below. The default user on the system is administrator with the password administrator, if you haven’t changed it already in the section called “Securing your Server”.

3.1. Creating Domains

Go to System Administration→Domains. You’ll see a form Create Domain, where you have to provide the name of your SIP domain. In our example we’ll put in 1.2.3.4 there and click add. The newly created domain now shows up under Edit Domains.

Defining Domain Dialplans


	On the NGCP, every phone number is treated in E.164 format <country code><area code><subscriber number>. With domain dialplans, you can set regular expressions as rewrite rules to normalize user-provided numbers to the required format.

Within every of your SIP domains, you can define rewrite rules for the caller and the callee. This is used to define what an end user can dial for outbound calls, and what is displayed as the calling party on inbound calls. To define these rules, click on your newly created domain.


	In Europe, the following formats are widely accepted: +<cc><ac><sn>, 00<cc><ac><sn> and 0<ac><sn>. Within this section, we will use these formats to show how to use rewrite rules to normalize and denormalize number formats.

Inbound Rewrite Rules for Caller

These rules are used to normalize user-provided numbers (e.g. passed in From Display Name or P-Preferred-Identity headers) into E.164 format. In our example, we’ll normalize the three different formats mentioned above into E.164 format.

Strip leading 00 or +

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

Replace 0 by Austrian country code 43:

Match Pattern: ^0([1-9][0-9]+)$
Replacement Pattern: 43\1
Description: Austria National to E.164


	When routing a call, the rewrite processing is stopped after the first match of a rule, starting from top to bottom. If you have two rules (e.g. a generic one and a more specific one), where both of them would match some numbers, drag&drop the rules into the appropriate order.

Inbound Rewrite Rules for Callee

These rules are used for the number the end user dials to place a call. In our example, we again allow the three different formats mentioned above, so we put in the same rules as for the caller.

Strip leading 00 or +

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

Replace 0 by Austrian country code 43:

Match Pattern: ^0([1-9][0-9]+)$
Replacement Pattern: 43\1
Description: Austria National to E.164

Our provided rules will only match if the caller dials a numeric number. If he dials an alphanumeric SIP URI, none of our rules will match and no rewriting will be done. You can however define rules for that as well. For example, you could allow your end users to dial support and rewrite that to your support hotline using the match pattern ^support$ and the replace pattern 43800999000 or whatever your support hotline number is.

Outbound Rewrite Rules for Caller

These rules are used to rewrite the calling party number for a call to an end user. For example, if you want the device of your end user to show 0<ac><sn> if a national number calls this user, and 00<cc><ac><sn> if an international number calls, put the following rules there.

Replace Austrian country code 43 by 0

Match Pattern: ^43([1-9][0-9]+)$
Replacement Pattern: 0\1
Description: E.164 to Austria National

Prefix 00 for international caller

Match Pattern: ^([1-9][0-9]+)$
Replacement Pattern: 00\1
Description: E.164 to International


	Note that both of the rules would match a number starting with `43`, so drag&drop the national rule to be above the international one (if it’s not already the case).

3.2. Creating Accounts

An account on the NGCP is a billing container, which contains one or more subscribers for a customer. In this billing container, you can define which Billing Profile is used for calls being placed by the subscribers of this account.

To create a new account, go to User Administration→Accounts and click Create new account. For our first tests, we will use the default values, so just click Save.

You will be presented with an overview of the new account, showing basic Account Information, the Account Balance (which will only get relevant when you start using your own Billing Profile) and the list of Subscribers for this account, which is currently empty.

3.3. Creating Subscribers

In the Subscribers section at the bottom of the account information for the account you created before, click create new to create a new subscriber for this account. You will be presented with the Master Data form, where you have to fill in the following options:

web username: This is the user part of the username the subscriber may use to log into her Customer Self Care Interface. The user part will be automatically suffixed by the SIP domain you choose for the SIP URI. Usually the web username is identical to the SIP URI, but you may choose a different naming schema.


	The web username needs to be unique. The system will return a fault if you try to use the same web username twice.

web password: This is the password for the subscriber to log into her Customer Self Care Interface. It must be at least 6 characters long.
E.164 number: This is the telephone number mapped to the subscriber, separated into Country Code (CC), Area Code (AC) and Subscriber Number (SN). For the first tests, you can set a made-up number here and change it later when you get number blocks assigned by your PSTN interconnect partner. So in our example, we’ll use 43 as CC, 99 as AC and 1001 as SN to form the phantasy number +43 99 1001.


	This number can actually be used to place calls between local subscribers, even if you don’t have any PSTN interconnection. This comes in handy if you use phones instead of soft-clients for your tests. The format in which this number can be dialled so the subscriber is reached has been defined previously in the section called “Defining Domain Dialplans”.

SIP URI: Insert the user part of the URI into the first field (e.g. user1) and select the domain you want to put this subscriber into in the drop-down.

With the default system settings, the user part has to have at least one alphabetic character, so it’s not possible by default to just use a number here. To allow that, on the console set ossbss→provisioning→allow_numeric_usernames to 1 in /etc/ngcp-config/config.yml and execute the command ngcpcfg apply. If you want for example to set a numeric customer id as the SIP user, make sure it does not overlap with actual phone numbers, otherwise these calls will be routed to the SIP user instead of the phone number.

SIP password: The password of your subscriber to authenticate on the SIP proxy. It must be at least 6 characters long.
administrative: If you have multiple subscribers in one account and set this option for one of them, this subscriber can administrate other subscribers via the Customer Self Care Interface.

Click Save to create the subscriber. Repeat the creation of accounts and subscribers for all your test accounts. You should have at least 3 subscribers to test all the functionality of the NGCP.


	At this point, you’re able to register your subscribers to the NGCP and place calls between these subscribers.

3.4. Creating Peerings

If you want to terminate calls at or allow calls from 3^rd party systems (e.g. PSTN gateways, SIP trunks), you need to create SIP peerings for that. To do so, go to System Administration→SIP Peerings. There you can add peering groups, and for each peering group add peering servers. Every peering group needs a peering contract for correct interconnection billing.

Creating Peering Contracts

In order to create peering groups, you must create at least one peering contract. It defines, which billing profile is going to be used for calls to the corresponding peering groups. In this example, we will use the Default Billing Profile, because we haven’t set up proper profiles yet.

In the SIP Peering Contracts section, click create new to add a peering contract. You will be presented with a form to set the billing profile and some contact details for the contract. To create a very basic dummy profile, we will set the following values:

billing profile: Default Billing Profile
First Name: leave empty
Last Name: leave empty
Company: leave empty

Click Save to store the peering contract.

Creating Peering Groups

In System Administration→SIP Peerings, create a new peering group in the section Create Peering Group. You will usually have one peering group per carrier you’re planning to send traffic to and receive traffic from. We will create a test group using the peering contract added before:

Name: test group
Priority: 1
Description: peering to a test carrier
Peering Contract: select the id of the contract created before

Then click add to create the group.

Creating Peering Servers

In the group created before, you need to add peering servers to route calls to and receive calls from. To do so, click on the Name of your created group in the section SIP Peering Groups.

Then add your first peering server in the section Peering Servers. In this example, we will create a peering server with IP 2.3.4.5 and port 5060:

Name: test-gw-1
IP Address: 2.3.4.5
Port: 5060
Weight: 1

Then click add to create the peering server.

You will now see an additional section Peering Rules after your list of peering servers. There you have to define which numbers to route via this peering group.


	If you do not add at least one peering rule to your group, the servers in this group will NOT be used for outbound calls. The NGCP will however allow inbound calls from the servers in this group even without peering rules.

Since the previously created peering group will be the only one in our example, we have to add a default rule to route all calls via this group. To do so, create a new peering rule with the following values:

Callee Prefix: leave empty
Caller Pattern: leave empty
Description: Default Rule

Then click add to add the rule to your group.

The selection of peering servers for outbound calls is done in the following order: 1. Length of the matching peering rules for a call. 2. Priority of the peering group. 3. Weight of the peering servers in the selected peering group. After one or more peering group is matched for an outbound call, all servers in this group are tried, according to their weight (lower weight has more precedence). If a peering server replies with SIP codes 408, 500 or 503, or if a peering server doesn’t respond at all, the next peering server in the current peering group is used as a fallback, one after the other until the call succeeds. If no more servers are left in the current peering group, the next group which matches the peering rules is going to be used.

Creating Dialplans for Peering Servers

For each peering server, you can define rewrite rules similar to the rewrite rules in the section called “Defining Domain Dialplans”. To do so, click on the name of the peering server, and you will be directed to the tab Rewrite Rules.

If your peering servers don’t send numbers in E.164 format <cc><ac><sn>, you need to create Inbound Rewrite Rules for each peering server to normalize the numbers for caller and callee to this format, e.g. by stripping leading + or put them from national into E.164 format.

Likewise, if your peering servers don’t accept this format, you need to create Outbound Rewrite Rules for each of them, for example to append a + to the numbers.

Once you have created peering rules for a peer and you create a second peer in the same peering group, you will see a new option Import Rewrite Rules from another host to copy the peering rules from other peers in this group and replace or add to the ones in the current peer.

Authenticating and Registering against Peering Servers

Proxy-Authentication for outbound calls

If a peering server requires the SPCE to authenticate for outbound calls (by sending a 407 as response to an INVITE), then you have to configure the authentication details in the Preferences tab of your peer host. To do so, click Edit and for example provide the following values:

peer_auth_user: <username for peer auth>
peer_auth_pass: <password for peer auth>
peer_auth_realm: <domain for peer auth>

If you do NOT authenticate against a peer host, then the caller CLI is put into the From and P-Asserted-Identity headers, e.g. "+4312345" <sip:+4312345@your-domain.com>. If you DO authenticate, then the From header is "+4312345" <sip:your_peer_auth_user@your_peer_auth_realm> and the P-Asserted-Identity header is as usual like <sip:+4312345@your-domain.com>. So for presenting the correct CLI in CLIP no screening scenarios, your peering provider needs to extract the correct user either from the From Display-Name or from the P-Asserted-Identity URI-User.


	You will notice that these three preferences are also shown in the Subscriber Preferences for each subscriber. There you can override the authentication details for all peer host if needed, e.g. if every user authenticates with his own separate credentials at your peering provider.

Registering at a Peering Server

Unfortunately, the credentials configured above are not yet automatically used to register the SPCE at your peer hosts. There is however an easy manual way to do so, until this is addressed.

Configure your peering servers with the corresponding credentials in /etc/ngcp-config/templates/etc/sems/etc/reg_agent.conf.tt2, then execute ngcpcfg apply.


	Be aware that this will force SEMS to restart, which will drop running conference calls.