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”.
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.
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. |
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 +
^(00|\+)([1-9][0-9]+)$
\2
50
International to E.164
Replace 0
by Austrian country code 43
:
^0([1-9][0-9]+)$
43\1
50
Austria National to E.164
When routing a call, the rewrite processing is stopped after the first match of a rule. If you have two rules (e.g. a generic one and a more specific one), where both of them would match some numbers, set the Priority value of the specific rule lower than for the generic rule, so the specific one is tried first. The lower the value, the more precedence it gets. |
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 +
^(00|\+)([1-9][0-9]+)$
\2
50
International to E.164
Replace 0
by Austrian country code 43
:
^0([1-9][0-9]+)$
43\1
50
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 |
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
^43([1-9][0-9]+)$
0\1
50
E.164 to Austria National
Prefix 00
for international caller
^([1-9][0-9]+)$
00\1
51
E.164 to International
Note that both of the rules would match a number starting with |
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.
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:
The web username needs to be unique. The system will return a fault if you try to use the same web username twice. |
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”. |
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 |
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. |
If you want to terminate calls at or allow calls from 3rd 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.
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:
Default Billing Profile
Click Save to store the peering contract.
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:
test group
1
peering to a test carrier
Then click add to create the group.
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:
test-gw-1
2.3.4.5
5060
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:
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 |
For each peering server, you can define rewrite rules similar to the rewrite rules in the section called “Defining Domain Dialplans”.
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.