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.
![[Tip]](images/icons/tip.png){kind=icon} | |
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. |
![[Warning]](images/icons/warning.png){kind=icon} | |
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 Section 2.2.3, “Start 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.
| |
You will most likely want to assign Rewrite Rule Set to your domain via Preferences tab. The usage of Rewrite Rule Sets is explained in Section 4.5, “Configuring Rewrite Rule Sets”. |
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:
- 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.
![[Caution]](images/icons/caution.png){kind=icon} | |
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 is defined in Section 4.5, “Configuring Rewrite Rule Sets”. |
![[Important]](images/icons/important.png){kind=icon} | |
NGCP allows single subscriber to have multiple E.164 numbers to be used as aliases for receiving incoming calls. Also NGCP supports "implied" extensions, e.g. if a subscriber has number 012345, but somebody calls 012345100, then it first tries to send the call to number 012345100 (even though the user is registered as myusername), and only after 404 it falls back to the user-part for which the user is registered. |
| |
The interface ensures that any numbers entered conform to the local numbering plan. The numbering plan is defined by a set of three regular expressions, which can be found and edited in |
- 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 |
- 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. |
At some point, you should revise the subscriber Preferences, in particular the CLI options that control what is used as user-provided and network-provided calling numbers.
- For outgoing calls, you may define multiple numbers or patterns to control what a subscriber is allowed to send as user-provided calling numbers using the allowed_clis preference.
- Ifallowed_clis does not match the number sent by the subscriber, then the number configured in cli (the network-provided number) preference will be used as user-provided calling number also.
- You can override any user-provided number coming from the subscriber using the user_cli preference.
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:
-
billing profile:
Default Billing Profile - First Name: leave empty
- Last Name: leave empty
- Company: leave empty
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:
-
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.
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 - Hostname: leave empty
-
Port:
5060 -
Weight:
1
Then click add to create the peering server.
| |
The hostname field for a peering server is optional. Usually, the IP address of the peer is used as domain part in the Request URI. Some peers may require you to set a particular hostname instead of the IP address there, which can be done by filling in this field. The IP address must always be given though, and the request will always be sent to the IP address, no matter what you put into the hostname field. |
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.
| |
Enter all phone numbers in full E.164 format, that is <cc><ac><sn>. |
| |
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(s) 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 |
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 |
| |
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. |
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. |
| |
On the NGCP, every phone number is treated in E.164 format <country code><area code><subscriber number>. Rewrite Rule Sets is a flexible tool to translate the caller and callee numbers to the proper format before the routing lookup and after the routing lookup separately. The created Rewrite Rule Sets can be assigned to the domains, subscribers and peers as a preference. |
You would normally begin with creating Rewrite Rule Sets for the caller and the callee for every of your SIP domains. This is used to control what an end user can dial for outbound calls, and what is displayed as the calling party on inbound calls. The subscribers within a domain inherit Rewrite Rule Sets of that domain, unless this is overridden by a subscriber Rewrite Rule Set preference.
| |
In Europe, the following formats are widely accepted: +<cc><ac><sn>, 00<cc><ac><sn> and 0<ac><sn>. Also, some countries allow the areacode-internal calls where only subscriber number is dialed to reach another number in the same area. 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 +
-
Match Pattern:
^(00|\+)([1-9][0-9]+)$ -
Replacement Pattern:
\2 -
Description:
International to E.164
Replace 0 by caller’s country code:
-
Match Pattern:
^0([1-9][0-9]+)$ -
Replacement Pattern:
${caller_cc}\1 -
Description:
National to E.164
Normalize local calls:
-
Match Pattern:
^([1-9][0-9]+)$ -
Replacement Pattern:
${caller_cc}${caller_ac}\1 -
Description:
Local to E.164
Normalization for national and local calls is possible with special variables ${caller_cc} and ${caller_ac} that can be used in Replacement Pattern and are substituted by the country and area code accordingly during the call routing.
| |
These variables are only being filled in when a call originates from a subscriber (because only then the cc/ac information is known by the system), so you can not use them when a calls comes from a SIP peer (the variables will be just empty in this case). |
| |
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. |
These rules are used to rewrite the number the end user dials to place a call to a standard format for routing lookup. In our example, we again allow the three different formats mentioned above and again normalize them to E.164, 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 caller’s country code:
-
Match Pattern:
^0([1-9][0-9]+)$ -
Replacement Pattern:
${caller_cc}\1 -
Description:
National to E.164
Normalize areacode-internal calls:
-
Match Pattern:
^([1-9][0-9]+)$ -
Replacement Pattern:
${caller_cc}${caller_ac}\1 -
Description:
Local 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
-
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 |
These rules are used to rewrite the called party number immediately before sending out the call on the network. This gives you an extra flexibility by controlling the way request appears on a wire, when your SBC or other device expects the called party number to have a particular tech-prefix. It can be used on calls to end users too if you want to do some processing in intermediate SIP device, e.g. apply legal intercept selectively to some subscribers.
Prefix sipsp# for all calls
-
Match Pattern:
^([0-9]+)$ -
Replacement Pattern:
sipsp#\1 -
Description:
Intercept this call
For each peering server, you can use one of the Rewrite Rule Sets that was created previously as explained in Section 4.5, “Configuring Rewrite Rule Sets” (keep in mind that special variables ${caller_ac} and ${caller_cc} can not be used when the call comes from a peer). To do so, click on the name of the peering server, look for the preference called Rewrite Rule Sets.
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.