Click on Create Peering Group to create a new group.

In order to create a group, you must select a peering contract. You will most likely want to create one contract per peering group.

Click on Create Contract create a Contact, then select a Billing Profile.

Click Save on the Contacts form, and you will get redirected back to the form for creating the actual Peering Group. Put a name, priority and description there, for example:

The Priority option defines which Peering Group to favor (Priority 1 gives the highest precedence) if two peering groups have peering rules matching an outbound call. Peering Rules are described below.

Then click Save 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 Details on the row of your new group in your peering group list.

To add your first Peering Server, click on the Create Peering Server button.

Figure 10. Create Peering Server

In this example, we will create a peering server with IP 2.3.4.5 and port 5060:

Figure 11. Peering Server Properties

Click Save to create the peering server.

You can force an additional hop (e.g. via an external SBC) towards the peering server by using the Via Route option. The available options you can select there are defined in /etc/ngcp-config/config.yml, where you can add an array of SIP URIs in kamailio→lb→external_sbc like this:

kamailio:
  lb:
    external_sbc:
      - sip:192.168.0.1:5060
      - sip:192.168.0.2:5060

Execute ngcpcfg apply added external sbc gateways, then edit your peering server and select the hop from the Via Route selection.

Once a peering server has been created, this server can already send calls to the system.

6.6.2.1. Outbound Peering Rules

important
	To be able to send outbound calls towards the servers in the Peering Group, you also need to define Outbound Peering Rules. They specify which source and destination numbers are going to be terminated over this group. To create a rule, click the Create Outbound Peering Rule button.

Figure 12. Create Outbound Peering Rule

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
• Callee Pattern: leave empty
• Caller Pattern: leave empty
• Description: Default Rule

Figure 13. Outbound Peering Rule Properties

Then click Save to add the rule to your group.

tip
	In contrast to the callee/caller pattern, the callee prefix has a regular alphanumeric string and can not contain any regular expression.

tip
	If you set the caller or callee rules to refine what is routed via this peer, enter all phone numbers in full E.164 format, that is <cc><ac><sn>.

tip
	The Caller Pattern field covers the whole URI including the subscriber domain, so you can only allow certain domains over this peer by putting for example @example\.com into this field.

6.6.2.2. Inbound Peering Rules

Starting from mr5.0 release, Sipwise NGCP supports filtering SIP INVITE requests sent by SIP peers. The system administrator may define one or more matching rules for SIP URIs that are present in the headers of SIP INVITE requests, and select which SIP header (or part of the header) must match the pattern declared in the rule.

If the incoming SIP INVITE message has the proper headers, NGCP will accept and further process the request. If the message does not match the rule it will be rejected.

caution
	An incoming SIP INVITE message must match all the inbound peering rules so that NGCP does not reject the request.

In order to create an inbound peering rule you have to select a peering group, press Details and then press Create Inbound Peering Rule button.

Figure 14. Create Inbound Peering Rule

An inbound peering rule has the following properties:

Figure 15. Inbound Peering Rule Properties

• Match Field: select which header and which part of that header in a SIP INVITE message will be checked for matching the pattern
• Pattern: a POSIX regular expression that defines the accepted value of a header; example: ^sip:.+@example\.org$ — this will match a SIP URI that contains "example.org" in the domain part
• Reject code: optional; a SIP status code that will be sent as a response to an INVITE request that does not match the pattern; example: 403
• Reject reason: optional; an arbitrary text that will be included in the SIP response sent with the reject code
• Enabled: a flag to enable / disable the particular inbound peering rule

info

Both of the properties Reject code and Reject reason must be left empty if a peering server (i.e. a specific IP address) is part of more peering groups. Such a configuration is useful when an incoming SIP INVITE request needs to be treated differently in the affected peering groups, based on its content, and that’s why if the INVITE message only partly matches an inbound peering rule it should not simply be rejected.

When all settings for a peering group are done the details of the group look like:

Figure 16. Peering Servers Overview

#!/usr/bin/php
<?php

   // This script can be used to find out actual probabilities
   // that correspond to a list of peering weights.

if ($argc < 2) {
  echo "Usage: lcr_weight_test.php <list of weights (integers 1-254)>\n";
  exit;
 }

$iters = 10000;

$rands = array();
for ($i = 1; $i <= $iters; $i++) {
  $elem = array();
  for ($j = 1; $j < $argc; $j++) {
    $elem["$j"] = $argv[$j] * (rand() >> 8);
  }
  $rands[] = $elem;
 }

$sorted = array();
foreach ($rands as $rand) {
  asort($rand);
  $sorted[] = $rand;
 }

$counts = array();
for ($j = 1; $j < $argc; $j++) {
  $counts["$j"] = 0;
 }

foreach ($sorted as $rand) {
  end($rand);
  $counts[key($rand)]++;
 }

for ($j = 1; $j < $argc; $j++) {
  echo "Peer with weight " . $argv[$j] . " has probability " . $counts["$j"]/$iters . "\n";
 }
?>

# lcr_weight_test.php 1 2

 Peer with weight 1 has probability 0.2522
 Peer with weight 2 has probability 0.7478

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.

To create the following rules, click on the Create Rewrite Rule for each of them and fill them with the values provided below.

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

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.

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.

There are 2 ways to handle calls from local subscribers to emergency numbers in NGCP:

6.7.5.1. Simple Emergency Number Handling Overview

The overview of emergency call processing is as follows:

Figure 18. Simple Emergency Call Handling

Configuring Emergency Numbers is also done via Rewrite Rules.

Once you have finished to define your Rewrite Rule Sets, you need to assign them. For sets to be used for subscribers, you can assign them to their corresponding domain, which then acts as default set for all subscribers. To do so, go to Settings→Domains and click Preferences on the domain you want the set to assign to. Click on Edit and select the Rewrite Rule Set created before.

You can do the same in the Preferences of your subscribers to override the rule on a subscriber basis. That way, you can finely control down to an individual user the dial-plan to be used. Go to Settings→Subscribers, click the Details button on the subscriber you want to edit, the click the Preferences button.

For each peering server, you can use one of the Rewrite Rule Sets that was created previously as explained in Section 6.7, “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.

The sip:provider CE provides a utility that helps with the verification of call routing among local subscribers and peers. It is called Call Routing Verification and employs rewrite rules and peer selection rules, in order to process calling and called numbers or SIP users and find the appropriate peer for the destination.

The Call Routing Verification utility performs only basic number processing and does not invoke the full number manipulation logic applied on real calls. The goal is to enable testing of rewrite rules, rather than validate the complete number processing.

You can access the utility following the path on Admin web interface: Tools → Call Routing Verification.

Expected input data

Examples