Figure 11. 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 12. Outbound Peering Rule Properties

Then click Save to add the rule to your group.

Starting from mr5.0 release, Sipwise C5 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, Sipwise C5 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 13. Create Inbound Peering Rule

An inbound peering rule has the following properties:

Figure 14. Inbound Peering Rule Properties

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

Figure 15. 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/perl

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

$num_args = $#ARGV + 1;
if ($num_args < 1) {
    print "Usage: lcr_weight_test.pl <list of weights (integers 1-254)>\n";
    exit 0;
}

my $iters = 10000;
my @rands;

for (my $i=1; $i <= $iters; $i++) {
    my %elem;
    for (my $j=0; $j < $num_args; $j++) {
        my $random = int(rand(2000000000));
        $elem{"$j"} = $ARGV[$j] * $random;
    }
    push(@rands, \%elem);
}

my @counts;
for (my $j=0; $j < $num_args; $j++) {
    $counts["$j"] = 0;
}

foreach my $rand (@rands) {
    my $higher = 0;
    my $higher_key = 0;
    foreach $key (keys %{$rand}) {
        if ($rand->{$key} > $higher) {
            $higher = $rand->{$key};
            $higher_key = $key;
        }
    }
    $counts[$higher_key]++;
}

for (my $j=0; $j < $num_args; $j++) {
    my $prob = $counts[$j]/$iters;
    print "Peer with weight $ARGV[$j] has probability $prob \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.pl 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 Sipwise C5 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 16. 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 Sipwise C5 at your peer hosts. There is however a manual way to do so, until this is addressed.

Create a new file /etc/ngcp-config/templates/etc/ngcp-sems/etc/reg_agent.conf.customtt.tt2 as a copy of /etc/ngcp-config/templates/etc/ngcp-sems/etc/reg_agent.conf.tt2. Configure your peering servers with the corresponding credentials in the new created file /etc/ngcp-config/templates/etc/ngcp-sems/etc/reg_agent.conf.customtt.tt2, then execute ngcpcfg apply "added upstream credentials". IMPORTANT: Be aware that this will force SEMS to restart, which will drop all calls.

The overview of emergency call processing is as follows:

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

emergency_provider_info preference must be defined at domain level with application/xml as content-type and the whole XML with the provider info described. For instance:

<?xml version="1.0" encoding="UTF-8"?>
<emergencyCall.ProviderInfo xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo">
 <DataProviderString>Telekom</DataProviderString>
 <ProviderID>D150</ProviderID>
 <contactURI>sip:+492911234567@telekom.de;user=phone</contactURI>
 <ProviderIDSeries>BNetzA</ProviderIDSeries>
</emergencyCall.ProviderInfo>

emergency_location_object preference can be defined at subscriber level with application/pidf+xml as content-type and the whole XML containing the Geo-location as PIDF-LO.

It can use different location encodings but there are two mandatory elements that need a special value in order to be replaced by Sipwise C5 at the moment of initiating the emergency call:

<retention-expiry>$$expiry$$</retention-expiry>
<timestamp>$$ts$$</timestamp>

An example of XML document with the mandatory elements:

<?xml version="1.0" encoding="UTF-8"?>
<presence
 xmlns="urn:ietf:params:xml:ns:pidf"
 xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
 xmlns:gml="http://www.opengis.net/gml"
 xmlns:gs="http://www.opengis.net/pidflo/1.0"
 xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:123@t-mobile.de">
 <tuple id="arcband">
    <status>
      <gp:geopriv>
        <gp:location-info>
          <gml:location>
            <gs:ArcBand srsName="urn:ogc:def:crs:EPSG:: 4258"
              xmlns:gs="http://www.opengis.net/pidflo/1.0"
              xmlns:gml="http://www.opengis.net/gml">
              <gml:pos>49.8967 8.6228</gml:pos>
              <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001">0</gs:innerRadius>
              <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001">2005</gs:outerRadius>
              <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102">328</gs:startAngle>
              <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102">64</gs:openingAngle>
            </gs:ArcBand>
          </gml:location>
          <con:confidence>100</con:confidence>
          <cl:civicAddress xml:lang="de">
            <cl:LOC>Mobilfunkzelle</cl:LOC>
            <cl:ADDCODE>26201F1080939A</cl:ADDCODE>
          </cl:civicAddress>
        </gp:location-info>
        <gp:usage-rules>
          <gbp:retransmission-allowed>yes</gbp:retransmission-allowed>
          <gbp:retention-expiry>$$expiry$$</gbp:retention-expiry>
        </gp:usage-rules>
      </gp:geopriv>
    </status>
    <timestamp>$$ts$$</timestamp>
  </tuple>
</presence>

emergency_location_object preference can be defined at subscriber level with application/vnd.cirpack.isdn-ext as content-type and the hex string. For instance: 7e Od 04 55 75 69 20 4d 61 6b 65 43 61 6c 6c