Howto:Looping in a innovaphone Gateway

Please note: this article describes a slightly different configuration than the one created by the box wizard for IP6000 and IP800.

Summary

This article will describe the essentials of a simple loop in scenario. This article will not describe how to configure your BRI/PRI interfaces. Because the CGPN mappings differ from case to case, we will assume that our trunk number is +49 (5085) 970.

In our test scenario we will use a IP6000, which is looped in between an old PBX and the trunk line to the ISDN provider. To keep it simple, the old PBX will have only one PRI line to its ISDN provider. We assume that ISDN providers behavior is like DT AG or Arcor. The configuration of CGPN/CDPN mappings may vary significant from described in case your have other ISDN provider. For more information about specific configuration for other providers please check related articles.

Our goal is to correctly loop in the innovaphone PBX, without making changes at the old PBX. Also we want to add some new IP - phones, which are registered and connected to the IP6000.

The nice thing is,when we want to replace the old Pbx extensions with new Ip phones - you only need to make a external call diversion to your own extension , example the Old Pbx extension is 10 - we make an call diversion on this old Phone( extension 10) to 05085 970 10 - so if any Old Pbx User dials the extension 10 the call will be forwarded to the Isdn and the looped in innovaphone Pbx will catch the call and route it to the new Ip phone extenstion 10.

Applies To

This information applies to

IP6010
IP6000
IP3000
IP811
IP810
IP800
IP311 *
IP305 *

* the Gateway has no hardware relay. This is why it has no hardware fallback mechanism, in case that the Gateway is cut from power.  
Also this type of gateway is not able, to use the 'Enable PCM' option for physically relaying ISDN - Data channels between two 
ISDN(BRI/PRI) interfaces.

Configuration

PBX - Objects

I assume that the ISDN interfaces of the IP6000 are configured correctly. We will use the PRI1 ISDN interface to connect to the ISDN provider, while the PRI2 interface will be used to connect to the old PBX.

First we will create the PBX objects. The Trunk line Object is needed to get the calls to the ISDN provider. We also need an "Extern" Gateway object. This Gateway is used to get calls to unknown PBX objects to the "old PBX". Afterwards the user objects are configured. For our example we will configure only one user, which uses an ip phone and is registered at the IP6000.

After creating this objects, it is important to change the General PBX Settings, so that calls to unknown numbers get routed to the External Gateway.

After having configured the PBX settings, we will configure the Gateways.

Interface mappings

Like described before, we will use only the PRI1 and the PRI2 interface of the IP6000. The PRI1 interface is connected to the ISDN provider, the PRI2 interface to the old PBX. If you need another PRI line, then use also the PRI3 interface to connect to the provider and the PRI4 interface to the old PBX. It is important to keep this sequence of interfaces (PRI1,PRI3 to provider & PRI2,PRI4 to old PBX) in case that the IP6000 is disconnected from its power supply. A hardware relay in the IP6000 will then transfer the ISDN calls from PRI1<->PRI2 and PRI3<->PRI4 automatically, even while the IP6000 is without power.

This described hardware releay is also in the IP3000 and IP800 but not in the IP305 in case of powering off the Gateway.

Now the PRI1 interfaces gets registered at the PBX trunkline object and the PRI2 interface is registered at the EXTERN Gateway. Another important setting is to enable the "Enable PCM" checkbox. This will preserve DSP channels. The PBX will recognize if a call has just to be routed from PRI1 to PRI2 and will not use DSP to convert the Media Channels.

Also for Modem support connected at the Old Pbx the PCM feature will help - the data will not be converted into IP instead handled directly over the ISDN PCM bus - that avoids Modem conenction problems via IP.

By activating the Enable T.38 Flag on the interface, the T.38 protocoll is used for transporting Fax over IP. If it is planned to connect a fax machine to the IP-PBX, it is mandatory to activate this flag.

At this point we will have to do some mappings at the ISDN interfaces. The main goal of the interface mappings is to correctly convert the international & national ISDN number flags. The second goal is to uniform the incoming CDPN, so the PBX routing can be simplified to handle only one kind of number format.

Administration/Gateway/Interface PRI1

At the PRI1 interface we can manipulate the incoming and outgoing patry numbers(CGPN & CDPN).

for incoming calls (ISDN->PBX)
- CDPN:
  - we chop away the international or national prefixes. By this method, all calls that will reach the PBX will have a CDPN in local area format.
- CGPN:
  - we replace the international & national ISDN number flags with dialable numbers(i.e. I->00 and n->0)

for outgoing calls (PBX->ISDN)
- CGPN & CDPN:
  - we add depending on the calling number the appropriate ISDN types(international,national,subscriber)
  - it is also important to use the numbering plan options to mark outgoing calls as ISDN type. If they are not marked as such, it is possible that the ISDN provider will not accept outgoing CGPN.

Administration/Gateway/Interface PRI2

On the PRI2 interface (our connection to the old PBX)we will do the following mappings:

for incoming calls (oldPBX->IP6000)
- CGPN:
  - we again chop away the international or national prefixes. In addition to that we must consider the possibility of a call beeing rerouted in the old PBX. In this scenario the CGPN will not contain the local trunk number, so that we only need to change the international/national flags.
- CDPN:
  - At this point, it is only required to replace the international & national ISDN number flags with dialable numbers

for outgoing calls (IP6000->oldPBX)
- CGPN & CDPN:
  - we add depending on the calling number the appropriate ISDN types(international,national,subscriber)

We are almost finished. Now we have to configure the routes between the interfaces.

Routes

Since the interface mappings are only used for the correct conversion and uniformization of incoming and outgoing numbers, the whole looping logic is contained by the Routes. Thats why we will go through every route separately. Pease note that most of the routes have CDPN aswell as CGPN mapings. For improving the compatibility with different ISDN provider and PBX manufacturers, we will enable on all routes the interworking flag.

Route1(From Carrier to PBX)

This route relays calls into the PBX. Since we already uniformized the CDPN to a subscriber format, we only need to remove the subscriber prefix. The remaining part of the CDPN is the phone extension.

Route2(From PBX to Carrier)

Under normal circumstances it suffices to transmit a CGPN in subscriber format to the ISDN provider. He will then correctly format the CGPN depending on the CDPN.(e.g. when calling an international number the provider will change the CGPN form '970'123 to '00495085970'123). The problem for outgoing calls(to the provider) is when the customer wants to use the CLIP - no screening feature. When this feature is enabled by the provider, he will no longer check the CGPN. (e.g. when calling an international number the provider will not change the CGPN. The called international phone will not be able to call back, due to uncorrect CGPN). This is the reason why we will handle outgoing international calls separately in the routes.

Route2-Branch1(From PBX to Carrier - international call):

If the CDPN is starting with '00' the outgoing call target is international. We now have to check the existing CGPN format. To understand why we use 4 different mappings on this route, you must consider the following lines. A call from the PSTN calls a phone at the IP6000/oldPBX. However this phone is to forward the calls to a recipient in the PSTN(e.g. mobile phone). Since the call originally entered the PBX using our Trunkline - PBX object, a leading '0' was prepended to the CGPN. We now have 4 possibilites:

If the CGPN is starting with '000' it must be an international number. In this case we will only cut away the leading '0' and be done with the mapping.
If the CGPN is starting with '00' it must be an national number. Since this is a call to a international number, we must get the CGPN in internalional format.
If the CGPN is starting with '0' it must be an local number. Again, because this is a call to a international number, we must get the CGPN in internalional format.
Finally we also have the possibility that the call origins from a phone registered at the IP6000 or at the oldPBX. In this case we will also need to use an international CGPN format.

Route2-Branch2(From PBX to Carrier - national call):

The logic for this route is analog to Route2-Branch1.

Route3(From OldPBX to IP6000)

This route will handle calls from the oldPBX to the IP6000. We have different branches, to separate calls to a user registered at the IP6000(branch1-3) and phones in the PSTN(branch4). When looking at the routes in Branch 1-3, remember that we didn't cut the trunk number at the interface mappings(because of overlap dialing). Therefor we must now handle separately different CDPN formats(international,national,local).

Route3-Branch1(From Old PBX to PBX - CDPN in international format):

This route handles calls to users registered at the IP6000. We cut away the trunk number and forward the call to the PBX. However we must consider two possibilities for the CGPN. If the caller is a user from the oldPBX, we cut away the local prefix(CGPNhas been uniformized at the interface mapping). There is also the possibility that the original caller is a user in the PSTN. In this case the CGPN, will be a number in the PSTN. In this case we must prepend a leading '0'. In Route2 we will then eventually use the leading '0', to handle the number mapping.

Route3-Branch2(From Old PBX to PBX - CDPN in national format):

The logic for this route is analog to Route3-Branch1.

Route3-Branch3(From Old PBX to PBX - CDPN in local format):

The logic for this route is analog to Route3-Branch1.

Route3-Branch4(From Old PBX to PBX - CDPN differs from trunk number)

Since we already handled calls to users in the PBX, we must no think about users in the PSTN. By prepending a leading '0' to the CDPN, the call will be forwarded to the Trunk Line Object in the PBX. Using the Trunk Line Object it will then be forwarded to ISDN provider. Again, we must handle both possibilities for the CGPN. The logic for the CGPN mapping is equal to the one used in the former Route3 branches.

Route4(From PBX to Old PBX)

This route handles calls to the oldPBX. We will forward the calls to the old PBX with a local area prefix. Therefore we prepend the local area prefix. At the CGPN mappings, we again must consider 2 possibliites. If the calling party is a number in the PSTN, we must chop away the leading '0'. This '0' was prepended, because the call entered the PBX using the Trunk Line Object. In case that the CGPN does not start with '0', the CGPN must be an extension/phone registered at the IP6000. In this case we will prepend the local area prefix.

Special Case - provider sends only extension number as CDPN

Some ISDN providers already cut away the trunk number, before sending it to the PBX. In this case the CDPN would contain only the phone extension(using a Unknown number format). We must also consider that the oldPBX will also expect incoming CDPN in this format. To handle this situation, our interface mappings on the PRI interfaces must be adjusted. Since we don't want to change the routes, we must stay with our uniform number format. The incoming CDPN will be transformed in a local area number.(e.g. 200->'970'200)

Let's start with the PRI1 interface.

On the PRI1 interface we will adjust the handling of incoming numbers with unknown format. Since in some countrys (like Italy) it is also common that every CDPN/CGPN is sent in unknow number format, we will first filter out incoming CDPN/CGPN starting with '0'. This is certainly not a phone extension number, so we will just forward it without further modifying the number. In case that the number does not start with '0', we assume that the provider sends us an abbreviated number(phone extension). We will then prepend our local area prefix to this extension, since our routes will handle only number in this local area format(i.e. starting with 970) correctly.

Now let's have a look at the PRI2 mappings.

On this interface we must consider that incoming calls will also have an abbreviated CGPN/CDPN format. In this case we will make similar adjustments to the PRI1 interface mappings. For outgoing calls we must now cut away the local area prefix of the CDPN, since the oldPBX is expecting the CDPN formatted like a phone extension.

Partial Rerouting

Partial Rerouting (PR) is an ISDN supplementary service.

It realizes a call diversion by the replacement of a call connection from a user-A to a user-B by a call connection from user-A to user-C.

User-A and User-C reside in the PSTN. User-B resides within an innovaphone PBX. User-B activated a diversion (CFU, CFNR) towards user-C.

If the ISDN provider supports this feature we maybe need to add configuration on the routes. please read therefore related articles below.

Howto:Looping in a innovaphone Gateway

Contents

Summary

Applies To