Howto:Central SIP trunk with multiple subscriber numbers

From innovaphone-wiki

Jump to: navigation, search


Applies To

This information applies to

V12r2 sr12 and later.

More information

Currently SIP-Providers are offering customers the centralisation of their multiple SIP-trunks on one SIP-trunk. This means that one central SIP-Trunk is assigned with more then one subscriber numbers, often also from different area codes. The provider expects that the innovaphone gateway sends the correct/matching subscriber number, so that the provider can relate the calls to the correct customer location/subscriber number. This should be still possible if the caller hides his own number (CLIR) or in case of redirected external calls using Clip No screening (CLNS).

The following diagram shows a simple scenario of a Funnel PBX with N locations providing a central big sip trunk for all sub-locations.

Image:Simple scenario Funnel PBX.png

The simple solution of mapping internal CGPNs to external subscriber numbers doesn't work for redirected external call and additionally doesn't scale well. Therefore we use a different concept, where each customer subscriber number/location has its own TrunkLine. Registered to each TrunkLine-object is a SIP-interface, in the routing-table we set the UUI info (User-to-User Info) to the correct subscriber number - this UUI is later used by the provider to identify outgoing calls. The SIP-interface doesn't register directly at the SIP-provider but to an innovaphone PBX (we call it from now on "Funnel-PBX"), through it the call is routed to the central SIP-trunk and then to the SIP-provider. The Funnel-PBX has a E164 node tree with appropriate placed Gateway-objects for each customer location and a central breakout object for calls to the PSTN. The Funnel-PBX is independent of the customers other PBXs, i.e. a master PBX with own objects or a slave PBX with "license only" and no PBX-object replication.

It is important to know that this concept comes with some limitations:

  • The provider must use the Identity-Header (P-Preferred-Identity or P-Asserted-Identity) for the evaluation of the correct subscriber number and the From-Header for number presentation.
  • Each subscriber number must have an own TrunkLine object and a SIP-Interface registered to it, in order to set the correct UUI. To have in the customer PBX (not the Funnel-PBX) only one TrunkLine for all users will not work, see explanation above about CLIR and CLNS
  • If the customer PBX uses a flat numbering plan (e.g. all users over all locations are in the root node), you need to use the physical location in order to choose the correct trunk-line object.

Configuration of the Funnel PBX

The Funnel-PBX must have an E164 numbering plan, in order to ensure that all numbers (CGPN and CDPN) sent to the central trunk have the same number format. The TrunkLine object for the central SIP-Trunk must be in the root node. Incoming and outgoing calls use therefore an "international" number format, as seen from the root node (e.g. 31437630 for a Location in NL, Maastricht). The Central-Trunk object must have no number, calls to this object are routed through the Route Root-Node External Calls to propriety of the Funnel-PBX.

Start with configuring your Funnel PBX with the following Objects:

  • Node Objects with the Country Code, in this example the Node Objects for NL (Netherlands) with country code 31 and country-specific escape (in most cases 0)
  • Node Objects with the location and prefix of the location, in this example the Node Objects for the locations Roermond (RM) and Maastricht (MT). Again for each node configure an escape, e.g. 0
  • Gateway Objects with the number matching the PSTN main number of the customer PBX-locations.
  • Trunk Line Object in the Funnel-PBX, having as node attribute root and no number. Here the main SIP-trunk to provider will register.

Although that in some examples the password field is left blank, you should consider security and configure safe passwords for all objects !

Funnel-PBX Objects Create the Funnel PBX Objects like in this example NL with country code 31

Image:Funnel-PBX Objects.png

Node Object General

Create the Node Object with the country code

Image:Node Object General.png and Node Object Node Image:Node Object Node.png

Node Object General

Create the Node Object for the locations like in this example MT with area code 43

Image:Node Object General MT.png and Node Object Node Image:Node Object Node MT.png

Gateway Object General

Create the Gateway Object for the PBX/Gateway in the location. In this example with PBX prefix 7630.

Image:Gateway Object General.png Gateway Object Gateway Image:Gateway Object Gateway.png

Repeat these steps for all the locations in your scenario.

Trunk Line Object

Create a Trunk Line Object Central-Trunk. The number field in the Trunk Line Object is left blank by purpose. The reason is to avoid this number to be displayed in your telephone set after the connection has been established (Connected Number).

Image:Trunk Line Object General.png

You should not configure destinations for Loopback, Incomplete, Invalid, Busy, Rejected and No Answer. This should be handled in the local TrunkLine objects, i.e. on each customer location.

Configuration of a Location PBX-Gateway

The PBX in the locations can be of any type (master or slave) and can use any numbering plan (E164, normal nodes or all users in root node).

The registration to the Funnel PBX is done via a SIP trunk registration to the Gateway Object in the Funnel-PBX. The configuration of the SIP trunk is done using the SIP-profile DE-innovaphoneAG-Funnel_SIP_Trunk (new since v12r2SR12).

Special Case: MSNs

The config above works for DDI-capable SIP-trunks. If a location uses MSNs, then the Funnel-PBX config and the SIP-Trunk config on the location-PBX must be adjusted. For incoming calls (PSTN->PBX), the Funnel-PBX must route calls for MSNs to the corresponding Gateway-object. This is done using NumberMaps, pointing to the number of the corresponding Gateway-object. If the location has only MSNs (no DDI capable trunk), you need to assign the gateway-object the primary MSN. In order to route calls to extensions in the location (e.g. MSN 871234 should be routed to internal extension 212, the NumberMap destination is 'primary msn' + 212). For outbound call, the internal extension is mapped to the corresponding MSN in the routing table of the local PBX. You use the CGPN-maps for this (e.g. 212 -> 003143871234).

The MSN handling is the same as the one described in the E.164 advanced training book.

Personal tools