Kick-off

In case your administrator account has the 2FA feature activated, then the login procedure requires an additional step.

The first time a user with 2FA logins to the admin panel will be asked to register its Sipwise C5 account on an Authenticator app (Google Authenticator or similer OTP app). To do that scan the QR-Code on the app, enter the OTP code in the OTP Code field and click on Sign in.

The next times the user will login on the Admin Panel, he should enter the OTP code in addition to the standard Username and Password.

In case a user has lost its OTP access, it can make a request to the platform’s system administrator to reset its OPT. To reset the OTP access for another user, the system administrator has simply to go to Settings→Administrators page, click the three dots beside the user to administrate and select Reset OTP. Finally click on the Reset button on the pop-up to confirm the operation.

The green bar at the top of the page provide some global utilities like:

The primary navigation is anchored by a global sidebar on the left of the screen, which serves as main menu. The bar contains 5 collapsible trees:

The search field at the summit allows to search for any menu included in the sidebar, while the Favourite pages lists all the pages/menu/elements that have been marked as favorite.

The sidebar can be pinned or automatically collapsed pressing the black arrow or the pin icons at the top of the bar.

The central part of the page is devided in three areas: nav bar, sub-menu and content panel.

There are cases when Sipwise C5 should pass the authentication process for a subscriber. In other words to pass the authentication process of an outbound call from behalf of the subscriber entity (configuration object).

Suppose there is Sipwise C5 and some other Class 5 system (can be just another Sipwise C5). You have recently migrated part of subscribers from another Class 5 system to Sipwise C5. But, you still have SIP peerings (with ITSPs) at that system, and you would like that recently migrated subscribers are still able to terminate calls via that another Class 5 system.

This is when the Remote Authentication parameters start helping you. The call flow in this scenario will be: Sipwise C5→another Class 5 system→SIP peering

And that system (another Class 5 system) will of course treat a call coming to it from Sipwise C5, as if that would be a direct call from the subscriber (indeed it’s not).

This is when you need to be capable of the authentication and Sipwise C5 gives you this possibility.

You will need to go to subscriber’s preferences and to know specific credentials to be used for that, in order to pass the authorization. To configure this setting, open the Remote Authentication tab and edit the following four preferences:

The peer_auth_hf_user preference is optional and can be skipped. It allows you to set a specific username for the Proxy-Authorization header. The peer_auth_registrar_server is also optional. In case it is not set, the REGISTER will be sent to the peer_auth_realm domain. In case there is a scenario where the realm is different from the registrar server domain/IP, the 'peer_auth_registrar_server' can be set. In this case the REGISTER will be sent there and the 'peer_auth_realm' used only as Digest Realm.

As soon as you define those parameters, a call from behalf of the subscriber, which will be terminated at another system, can be successfully authenticated.

This is approximately the same use case as for the 'Subscriber authentication for outbound calls' section, but this time for the registration process. Sipwise C5 can register at remote system, hence placing the location record on behalf of the subscriber.

The reason why you might need Sipwise C5 to register at remote system from behalf of the subscriber:

This is when the 'Remote Authentication' parameters help you again. You need to go to subscriber’s preferences, open the Remote Authentication tab and now additionally enable outbound registration:

Now in common with the preferences you defined previously in the 'Subscriber authentication for outbound calls' section, the registration process will start using given credentials.

It is possible to define which IP Family is preferred by a particular subscriber for sending media (RTP/RTCP), using the following preference:

NAT and Media Flow Control→ipv46_for_rtpproxy, which can be set to:

Both the domain and subscriber preferences contain the NAT and Media Flow Control section, which gives an access to the ipv46_for_rtpproxy preference.

Click on Add 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 three dots of the newly created Peering Group and select Details. Then, select the Peering Severs tab and click on Add_.

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

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 config.yml, where you can add an array of SIP URIs in kamailio.lb.external_sbc like this:

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.

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:

A tagged Emergency Call from a subscriber will have Geo-location information attached to the SDP when emergency_location_object preference is properly set depending on the format defined at subscriber’s emergency_location_format preference.

These are the emergency_location_format formats that Sipwise C5 currently supports:

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, click on the three dots and select Preferences on the domain you want the set to assign to. Edit the rewriting rule 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 on the three dots, then select Preferences button on the subscriber you want to edit.

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