Figure 15. 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:

Figure 16. Outbound Peering Rule Properties

Then click Save to add the rule to your group.

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.

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 17. Create Inbound Peering Rule

An inbound peering rule has the following properties:

Figure 18. Inbound Peering Rule Properties

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

Figure 19. Peering Servers Overview

The selection of peering groups and peering servers for outgoing calls is done in the following way:

In order to find out this probability knowing the weights of peering servers, use the following script:

#!/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";
 }
?>

Let us say you have 2 peering servers, one with weight 1 and another with weight 2. At the end — running the script as below — you will have the following traffic distribution:

# lcr_weight_test.php 1 2

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

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 tried as a fallback. All the servers within the group are tried one after another until the call succeeds. If no more servers are left in the current peering group, the next group which matches the outbound peering rules is used.

The default call routing uses statically configured peering group priorities to decide where to send the calls. This solution is useful when you have an external SBC that makes all the routing decisions and is described in the Routing Order Selection section. Sipwise C5 also allows you routing calls to the cheapest SIP peers saving your termination cost.

To enable LCR routing, do the following:

When the LCR routing is enabled, the selection of peering groups would be the following:

Let us consider a short example. There are two peering groups (PG1 and PG2) that can deliver calls to New York (e.g. 12121234567) and they have the following rates:

PG1 has only one rate that matches the dialed number, so that it will be taken into account, PG2 has two rates and the longest will be selected. The call will be routed to PG1 servers first as it has a cheaper price and can fail-over to PG2 servers.

The Sipwise C5 LCR feature together with the codec filtering, media transcoding, header manipulations, SIP, and RTP encryption and other SBC features make an external SBC unnecessary. This simplifies your VoIP network and cuts deployment and operation costs.

If a peering server requires the sip:provider PRO 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 view of your peer host.

Figure 20. Select Peering Server Preferences

To configure this setting, open the Remote Authentication tab and edit the following three preferences:

Unfortunately, the credentials configured above are not yet automatically used to register the sip:provider PRO 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/ngcp-sems/etc/reg_agent.conf.tt2, then execute ngcpcfg apply 'added upstream credentials'.

The overview of emergency call processing is as follows:

Figure 21. Simple Emergency Call Handling

Configuring Emergency Numbers is also done via Rewrite Rules.

For Emergency Calls from a subscriber to the platform, you need to define an Inbound Rewrite Rule For Callee, which adds a prefix emergency_ to the number (and can rewrite the number completely as well at the same time). If the proxy detects a call to a SIP URI starting with emergency_, it will enter a special routing logic bypassing various checks which might make a normal call fail (e.g. due to locked or blocked numbers, insufficient credits or exceeding the max. amount of parallel calls).

To route an Emergency Call to a Peer, you can select a specific peering group by adding a peering rule with a callee prefix set to emergency_ to a peering group.

In order to normalize the emergency number to a valid format accepted by the peer, you need to assign an Outbound Rewrite Rule For Callee, which strips off the emergency_ prefix. You can also use the variables ${caller_emergency_cli}, ${caller_emergency_prefix} and ${caller_emergency_suffix} as well as ${caller_ac} and ${caller_cc}, which are all configurable per subscriber to rewrite the number into a valid format.