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:

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:

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:

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.

	If you want to add a peering server with an IPv6 address, enter the address without surrounding square brackets into the IP Address column, e.g. ::1.

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:

Then click add to add the rule to your group.

	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.

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 408, 500 or 503, or if a peering server doesn’t respond at all, the next peering server in the current peering group is used as a fallback, one after the other until the call succeeds. If no more servers are left in the current peering group, the next group which matches the peering rules is going to be used.

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.

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.

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 support and rewrite that to your support hotline using the match pattern ^support$ and the replace pattern 43800999000 or whatever your support hotline number is.

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.

	Note that both of the rules would match a number starting with 43, so drag&drop the national rule to be above the international one (if it’s not already the case).

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.

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 System Administration→Domains and click on the domain name 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 tab of your subscribers. That way, you can finely control down to an individual user the dial-plan to be used.

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.