Course12:Advanced - Gateway Interfaces

From innovaphone-wiki

Jump to: navigation, search

This book describes all gateway interfaces configurable with innovaphone and their different working modes.




As already discussed in the innovaphone overall Product Design book in your iCE basic training course, the relay (as configured in the fish-help.png Gateway/General tabs) is the software component within innovaphone devices that handles access to various physical or external interfaces (such as e.g. ISDN basic rate, primary rate or analogue FXS). It manages the interface in terms of status and physical configuration and provides the necessary protocols (such as ISDN, QSIG, CAS, POTS) to implement both signalling and media channel.

The relay main functions are
  • providing a connection to the PSTN
  • providing a connection to third party devices and PBXs via ISDN, VoIP or analog lines
  • providing supplementary services like:
    • supply audio media via HTTP streams
    • supply different dial tones (needed for example in the soft migration scenario)
    • supply a PBX with a conference server
  • provides an alternative Call Server software called Gatekeeper, needed for special scenarios like PBX trunking
To interface to the VoIP world and in particular to provide access to its interfaces for VoIP endpoints registered to the PBX, the relay will screenshot.png maintain individual registrations to the PBX for each interface. This way, the interfaces are seen as standard VoIP endpoints from the PBX.

For calls from the PBX to the interfaces and vice versa, the call signalling protocols are translated and the media data is converted as required.

Aside from its physical interfaces, the relay also supports a number of further interface types, such as SIP trunks, virtual interfaces and the conferencing engine.

As the PBX cannot maintain any outgoing registrations itself, interfaces that require a registration themselves (such as SIP trunks where the subscriber needs to register with the provider) can be handled by the relay too. In this case, it will maintain screenshot.png 2 parallel VoIP registrations, one to the fish-help.png SIP provider and one to the PBX. The SIP provider registration is then treated just like any physical interface. This pair of registrations is known as a fish-help.png SIP interface.

The TEST, ECHO and TONE interfaces are known as fish-help.png virtual interfaces. Calls to these will be terminated locally in the relay.
Virtual interfaces will never originate calls. Calls directed to these interfaces will play music on hold (TEST), dial-tones (TONE) or echo any incoming media (ECHO).

The HTTP interface (a.k.a webmedia) will connect any call and will screenshot.png retrieve the media stream played to the caller from a (possibly remote) web server. Custom music on hold or announced played in IVR type situations can thus be provided by customers on a web server (either an innovaphone gateway with SSD drive or a standard web server such as IIS or Apache).

Some of the gateways feature a fish-help.png conferencing engine that provides mixing capabilities for a number of calls (currently up to 60, depending on the gateway used).

Call Routing

In many cases, calls from interfaces to on-behalf registrations are straight back and forth without any manipulation. However, in certain scenarios, call routing can be more sophisticated.

The relay's fish-help.png routing table provides a very powerful mechanism to configure the call routing depending on the called and calling party numbers, as well as the interfaces involved. Many call properties, such as calling and called party numbers can be manipulated as well. Call alternatives can be implemented, for example to fall back to an emergency trunk line when your standard trunk line is not available.

This book is about the interfaces the relay provides. There is another book on the same topic discussing the routing engine.

Physical Interfaces

Layer 1, 2 and 3 properties of physical interfaces such as POTS or ISDN are configured in the fish-help.png Interfaces/PRI/Physical, fish-help.png Interfaces/BRI/Physical and fish-help.png Interfaces/FXS/Physical tabs (for some older devices, the ISDN BRI interfaces are called TEL instead, causing some confusion with the POTS interfaces).

ISDN Interfaces

For ISDN BRI and PRI interfaces, the most important settings are the NT or TE mode and the ISDN protocol (set in the fish-help.png Interfaces/PRI/Physical and fish-help.png Interfaces/BRI/Physical tabs, respectively). The interface needs to be in TE mode when it connects to your carrier interface (which is always in NT mode).

The signalling protocol (set in the fish-help.png Interfaces/PRI/Protocol and fish-help.png Interfaces/BRI/Protocol tabs) will usually be EDSS1 when you connect to your telecommunication carrier. NI1, 5ESS and DMS100 are American ISDN protocol flavours rarely found in Europe.

The two QSIG flavours are only used if you connect to a legacy ISDN PBX using a tie line. Unfortunately, there are a number of different setups for QSIG connections. This will be discussed in a later chapter of this book.

For basic rate interfaces (BRI, a.k.a. S0, especially in Germany), you need to specify also if your interface runs in point-to-point or point-to-multipoint mode.

Point-to-multipoint refers to the fact that you can attach multiple terminal equipment interfaces to the one network termination interface. This was intended to connect multiple (up to 8) ISDN phones to your carrier trunk line. However, even if you connect only one terminal equipment interface to your trunk line (e.g. your innovaphone gateway only), your NT interface may be in point-to-multipoint mode. So you need to find out from your carrier which mode it is in.

As a point-to-multipoint interface can support multiple devices, it is not just a cable, but it is defined as a digital bus. This must be wired properly and termination resistors have got to be present. However, since in many installations there is just one device attached to the network termination interface and a straight CAT-3 (or better) patch cable is used, the termination is often missing. This will result in unreliable communication. You may thus turn on the 100 Ohm Termination property in the fish-help.png Interfaces/BRI/Physical settings, which will provide the necessary termination.

Nowadays, the more important difference between both modes is that a point-to-multipoint interface has up to 10 subscriber numbers assigned. These may or may not be assigned sequentially (that is, you may have subscriber numbers 12340, 12341, ..., 12349 if you are lucky. You may however have assigned a number of unrelated numbers such as 12345, 37261, 98263, ...). In contrast, point-to-point interfaces usually have a subscriber number range assigned (e.g. 12300 to 12399).

Analogue FXO Interfaces

There is rarely a need to change anything in the fish-help.png physical settings of the analogue interfaces.

You may however want to change the Busy on Busy / No Call Waiting or No Call Transfer on Hook-On properties in the fish-help.png Signalling tab.

Analogue FXO Interfaces

Some special configuration must be done for analog trunk interfaces (e.g. on the IP38). See fish-help.png Configure an analogue Trunk line with IP38 for details. FXO interfaces are not used in the Advanced Training.

VoIP interfaces

Once the physical properties of the interfaces are defined, you need to specify the use of the interfaces in the fish-help.png Gateway/General area. This is also true for virtual and VoIP interfaces (which do not have any physical properties).

Let us first have a look at the VoIP interfaces defined in fish-help.png Gateway/GK.

In the same way as ISDN interfaces lead the world of classical telephony, VoIP interfaces (GW1-12) (as configured in the fish-help.png Gateway/GK tab) are interfaces to the world of Voice over IP. If your gateway needs to communicate with other devices via VoIP, access to these devices may be configured as a VoIP interface.

They can represent different types of equipment:
  • an innovaphone PBX
  • other innovaphone gateways
  • VoIP terminal equipment, for example IP telephones (uncommon, preferred to be registered in the PBX)
  • third-party VoIP gateways, as a gateway to telephone switches for analog lines (FX0) for example.
  • Third party VoIP Pbx´s
  • further gatekeepers for call control
  • and others
Each VoIP interface defines access to a device or group of devices. Consider screenshot.png the example shown in the Overview chapter of this book. It is pretty obvious that the SIP Provider C interface can be implemented as a GWx VoIP interface. However, VoIP Instance C (as well as VoIP Instance A and VoIP Instance B) can too, as they are VoIP connections to an innovaphone PBX.

The Protocol Configuration

The first part of the fish-help.png Gateway/Interfaces/VOIP configuration is about the signalling protocol used. There are 4 signalling protocol options to choose from:
  • H.323
  • SIP
  • TSIP
  • SIPS
SIP, TSIP and SIPS are all flavours of the SIP protocol. TSIP is an abbreviation and stands for SIP over TCP. As expected, when using this protocol the SIP messages use TCP as transport layer protocol, instead of UDP. SIPS is based on TCP like TSIP, but it will use TLS to encrypt the signalling information exchanged between two endpoints.

The protocol options depend on if you choose H.323 or one of the SIP flavours. Therefore, if you try to change the protocols, you will see that the fish-help.png menu options differ between H.323 and SIP. For this reason, you should always delete all settings when changing the protocol, to ensure that you don't run into problems from previously configured settings.

For both H.323 and SIP various Interop Tweaks are available. As the name suggests, these are workarounds for interoperability problems and you should not use any of them unless you experience such problems.

The Registration Mode

Both H.323 and SIP support connections with and without registration.

In unregistered mode, a VoIP interface just sends calls to the far end when necessary. Similarly, it accepts calls from the far end at any time. It is not necessary for the interface to identify itself to the far end (nor vice versa). As a result, no access credentials such as user/account-name or password have to be configured. This mode is selected using Gateway without Registration. Please note that this mode will also accept incoming calls from the far end.

In registered mode, there is a client/server relationship between the interface and the far end and the client must establish a session with the server prior to any call sent. This process is known as registration. To set up the registration, credentials such as account and password may be required. This mode is selected using Register as Endpoint or Register as Gateway. The difference between them is subtle and applies only to the H.323 protocol. The information is sent to the far end as part of the registration request. The far end (usually a gatekeeper) may or may not use this information. innovaphone devices (both the relay's gatekeeper and the PBX) ignore it. When H.323 is used, all entries in the Alias List table are sent to the far end and the Password from the Authorization box is used. Depending on the gatekeeper used, you may need to specify both Name and Number. For the innovaphone PBX, either is sufficient. When SIP is used, the first Name entry in the Alias List table is used as registration id, and the Name and Password properties from the Authorization box are used for authentication. In many cases, the name used for registration and the account used for authentication will be identical. In such cases, you may leave the Name property in the Authorization box empty

The latter 2 modes define an interface that registers itself with the far end. However, it is also possible to accept registrations from the far end instead (reversing the client/server relationship). This mode is selected using Gatekeeper / Registrar and requires a special license. All entries in the Alias List are accepted as registering accounts, but all of them need to use the same Password from the Authorization box.

The remaining mode, ENUM is an extension of the Gateway without Registration mode. It performs an fish-help.png ENUM lookup on a call-by-call base to find the appropriate far end for each outgoing call. Incoming calls are treated like Gateway without registration mode interfaces. Like all gateway modes, ENUM is available for both SIP and H.323. However, a single ENUM interface will talk either SIP or H.323, depending on the Protocol setting. So if you want to support calls from and to both SIP and H.323, you will need to define multiple ENUM-type GW interfaces.

SIP interfaces in Gateway without Registration mode and H.323 interfaces in Gatekeeper mode support call restriction using the Mask property. By default, only incoming calls from the IP address specified in the Address property are allowed. If a network mask is specified, calls from all addresses in the same network are allowed. This is useful when for example a SIP proxy uses a farm of IP interfaces to send calls. ENUM interfaces always allow incoming calls from any IP address (that is, they behave as if the Mask property would be set to

Finding the far End

Determination of the far end (that is, where the calls or the registrations are sent to) depends on the Mode and Protocol used .

When using H.323 with Gateway without Registration, the far end simply is determined by the IP address given as Address.

When using H.323 with Register as Endpoint or Register as Gateway, the far end is determined by the IP address given as Address too. Also, if an alternate Address is specified and the registration with the primary Address fails, the alternate address is tried (providing a redundant fall-back mechanism exists). However, if no Address is given, gatekeeper discovery will be performed.

When using SIP both with Gateway without Registration, Register as Endpoint and Register as Gateway, the remote end is determined by fish-help.png analysing the Domain and Address properties. Usually, you simply specify the domain name your SIP provider gave to you. A fall-back mechanism is only used if the domain is given, a SIP SRV record is retrieved and there is an alternate server specified in the DNS response.

Media Properties

When a call is received or originated by an interface and a media channel is established to carry the voice data, the fish-help.png Media Properties are used to control the media channel negotiation.

Local Network Coders are negotiated when the far end is within the local network as defined in the Local Networks settings of the fish-help.png IP4/General/Settings tab. These should be "better" codecs to make sure better voice quality is used when a call is within the local network where bandwidth is not an issue.

Both ends of a call will negotiate one of the implemented voice codecs. Each side can suggest its preferred codec (defined in General Coder Preference and Local Network Coder), still allowing all others . However, when the Exclusive property is set, any other codec will be rejected. This makes sense in special scenarios, for example fax or modem calls.

There is a special, non-voice codec called T.38 which provides for reliable fax G3 transmission. This will be offered and accepted only if the Enable T.38 property is set.

It is pretty important to understand that media properties are effective only if the media channel actually is terminated in or passes through the device. As discussed in the VoIP Protocols books in your iCE Basic Training course, media channels are established end-to-end, whereas signalling connections are established hop-by-hop. So media properties are ineffective if the media channel does not terminate within the device. Obviously, calls to or from local interfaces (such as ISDN and POTS) will have their media channel terminated here, so the media properties apply. The same is true for all the virtual interfaces (such as TONE, TEST, ECHO and CONF). For the screenshot.png HTTP interface (which provides access to pre-recorded voice streams on a web server) this might be less obvious though. Finally, for calls where media-relay is applied to (either because the Media-Relay property is set in the media properties or because Private Networks have been defined in the fish-help.png IP4/General/Settings tab and the far end is not in one of them) the media properties apply too.

PCM Mode

Enable PCM is a very important and often forgotten parameter. It enables the usage of an internal PCM bus for transporting media data between two physical interfaces in the same device. Using the internal PCM the media (i.e. voice or modem) data will not be converted to VoIP. Instead, it will be routed directly between the 2 interfaces using the internal PCM switch circuitry. This however will only happen if both ends (Interfaces) have set the Enable PCM property to turned on.

This PCM mode helps you save DSP channels. Then a DSP channel is only needed for call setup. As soon as it can be determined that the call will end up in the same device it originated from and the device has a PCM bus available (depending on the gateway model) and the Enable PCM property is set on both ends, the DSP channel is released. No DSP is then needed for the remainder of a PCM call.

For most calls, PCM mode provides better performance, eliminating the delay and QoS issues associated with carrying media over IP. This is especially true for modem and fax (if not using T.38) calls. The only drawback is that there is no echo cancellation and DTMF detection done on the media channel.

Here is an example:

Call comes in on a gateway's ISDN interface, gets routed to an innovaphone PBX (installed on another gateway) - and then back (because the call can not be delivered to this PBX) to the same gateway where the incoming call arrived and out on another ISDN interface towards a legacy PBX.

"Gateway without registration" Scenario

Gateway without registration mode is used to communicate with a remote endpoint that does not require registration (no registration required on the far end). It also works the other way round, so a gateway in this gateway mode accepts incoming calls without registration from the far end. This mode can be used for SIP or H.323.

The example shows a connection between 2 legacy PBX´s via innovaphone gateways via IP.

Other examples include amongst others

  • a SIP provider that does not need registration (for example fish-help.png Tele2 sweden sip trunk), although from firmware v12r1 on, it is recommended to use a SIPx interface for this (see below)
  • a third party device that works without registration (example fish-help.png Linksys FXO gateway)

With this mode, no configuring of registration name/number is needed as there is no registration. This configuration suffices calling between both sides.

As you have no registration (no RAS registration data) you might experience an unpleasant behaviour - because the gateway never knows if the other side is "up and running " or not. So any call attempt will take a time-out before re-routing (if configured) can take place. This will cause extra delays in call processing.

Also, this mode cannot be used for QSIG tunnelling (see the QSIG chapter later in this book).

"Register as ..." Scenario

The most widely used scenario for Register as ... mode registration has already been discussed in the basic training and the Overview chapter of this book. It is the screenshot.png registration of physical interfaces of an innovaphone gateway to the innovaphone PBX.

However, the same mechanism can be used e.g. to integrate an innovaphone gateway to a 3rd party gatekeeper. In the example below, an IP6000 is used as an ISDN PRI gateway for a Cisco call manager.

"Gatekeeper/Registrar" Scenario

The Gatekeeper/Registrar mode needs an extra fish-help.png Gatekeeper License. If you don't have this license, this mode is not shown.

In innovaphone scenarios, this mode is rarely used as it is almost always preferred to use the PBX as a gatekeeper!

However, there are some fish-help.png special scenarios where you need to use it.

One prominent example is (possibly multi-point) legacy PBX-trunking with QSIG tunnelling over IP:

In this scenario, the gateway in site A works as a gatekeeper and the gateways in site B and C register (as gateway) with this gatekeeper. This way, all legacy PBXs can call each other (using site A's gatekeeper as call switching engine).

Please note that you must make sure that there are no 2 gatekeeper instances with the same gatekeeper ID within a single network. If for example, site A would run a PBX in addition, its gatekeeper ID (known as System Name in the fish-help.png PBX/Config/General configuration) must differ from the relay gatekeeper's gatekeeper ID!

There are certain limitations involved when you use the Gatekeeper / Registrar mode. This mode is not intended to manage a large number of registering clients. It is OK to have 50 clients, but for larger number of clients you will need to use the PBX. This is due to 2 facts: call routing is slightly less performing and the size of the configuration data is limited: In the Alias list section you specify the name and/or number of the registering clients (their registration credentials). The total size of the resulting config file (all lines starting with config change) must not exceed 64kB. Also, the total line length of a config file line must not exceed 2048 byte and finally the number of words on a config line is limited. So if you run into a configuration size problem, you can try to use shorter aliases, or split it into 2 GWx entries. As a rule of thumb you can add up to 32 aliases to one gatekeeper.

SIP Interfaces

SIP interfaces are a specialized version of the more generic VoIP interfaces. They handle both the registration to a remote peer which talks SIP (e.g. a SIP provider) as well as the internal registration to the PBX. As such, they offer a substantial configuration simplification.

Always use SIP interfaces if possible, instead of the more genereic GWx VoIP interfaces!

SIP Trunks

Nowadays, trunk lines are often implemented using pure IP connection, known as SIP trunks. In an innovaphone gateway, a SIP trunk is treated much like any other interface type. The interface type connect a PBX to a SIP trunk is known as SIP interface. There is a screenshot.png dedicated area available in the relay for the configuration of SIP interfaces.

One thing that is a bit special for SIP interfaces is that they have registrations in two directions: one towards the PBX's trunk line using H.323 (just like ISDN interfaces have) and the other towards the SIP provider using SIP.

The latter (registration to the PBX) is - just like for the physical interfaces - done in the Internal Registration part of the configuration dialogue. The first (registration to the SIP provider) in the screenshot.png upper part.

As you can see, there are quite a lot of settings available there and not all of them are self-explanatory. This is due to the fact that SIP trunks are not as well standardized as ISDN lines are.

Fortunately, innovaphone puts a fair amount of effort in the creation of SIP provider profiles. Such a profile greatly simplifies the configuration of a specific SIP provider. You can screenshot.png select the available SIP provider profiles from a drop down on the bottom of the SIP area.

This simplifies the configuration as you need no longer be concerned with the specific interop settings - you simply specify your account data and you're done.

SIP Interfaces, SBC and the DMZ

The innovaphone SIP interfaces available in the gateway layer implement all functions that an SBC would provide for a SIP trunk connection
  • protocol translation (SIP vs. H.323)
  • security offloading (e.g. encrypted/unencrypted conversion)
  • media pin-holing (NAT traversal, ICE/STUN/TURN)
  • media anchoring (media-relay)
  • header manipulation (for SIP interop issues)
In the majority of all installations, the SIP interface will screenshot.png reside on the same innovaphone gateway that also runs the PBX. This is perfectly fine and will work well (note: the SIP interface does not need an external IP address!). It is therefore the recommended configuration.

However, in more complicated installations the customer may request to have the SIP trunk located in the DMZ.

This can be done by placing a separate innovaphone device into the DMZ (this can be any device that has a gateway level, e.g. an IP0011).

Other SIP Interface Types

SIP interfaces are short-cut configurations for VoIP interfaces in Register as Gateway mode with SIP protocol. There is no added functionality. They are intended to interface to a SIP trunk line provider when the Type drop-down menu-box is set to screenshot.png Provider.

Open Federation and Closed Federation, as the name suggests, will be used to setup Federation scenarios.

SIP without Registration

From v12r1 on, SIP peers which run in without registration mode can also be handled with a SIPx interface. Before, such connections could only be configured using 2 GWx interfaces.

Virtual Interfaces

The gateways have the fish-help.png virtual interfaces TONE, TEST, HTTP, ECHO and CONF. These are not physical interfaces, but virtual interfaces, implemented within the device.


The gateways have an internal TEST interface. It only makes sense to use it as a destination for a call. If a call arrives at the TEST interface, it is connected and the hold music stored in the non-volatile memory is played. Subsequently dialled digits are ignored.


The gateways have an internal TONE interface. It only makes sense to use it as a destination for a call. If a call arrives at the TONE interface, it is not forwarded, but the dial tone configured for the interface is played (the incoming call is acknowledged with SETUP_ACK and a media channel is set up). The call is rejected if a further digit is dialled or if the original call contained other digits already dialled. The TONE interface can be used to play a caller a public dial tone, even though the call has not yet been connected to a “genuine” public exchange line. This happens particularly with least-cost-routing scenarios, where the call can only be switched once some of the dialled digits have been analysed. The TONE interface can process a number of calls simultaneously. The dial tone played is set in the gateway/interfaces, there are different TONE types (for different countries).
That interface is also important for SIP trunks because there is no "dial tone" played as is the case with ISDN.


The non-configurable, internal interface HTTP is only usable as the destination for a call. If a call is received on this interface, music on hold, an announcement or some other spoken information is played from a web server.


This is for testing purpose. A route to an ECHO interface, and calling to this interface creates an echo, so you can hear yourself, mainly used for DECT deployment


The CONF interface is used for conferencing solutions, see fish-help.png Gateway/Interfaces. It does multi-party audio, video and application-sharing conferences. It is usually used in combination with fish-help.png BC Conference or fish-help.png Conference PBX object.

This CONF interface is not available on all gateway platforms. It is also not available on the virtualized PBX (IPVA).

To see if a device has a CONF interface, see the Hardware section in the respective data sheet on the wiki (e.g. fish-help.png IP1130 Features for the IP1130). If it has, the data sheet will say something like Digital Signal Processor (DSP) for up to 30 voice/audio conference channels.


The FAX is used together with the innovaphone Faxserver application. More information in fish-help.png Gateway/Interfaces

Registered Interfaces

For scenarios where a gateway interface is registered to the innovaphone PBX, a convenient configuration short-cut is available. It is used when you use the Internal Registration property set in the fish-help.png interface configuration.

This configuration option is an easy way to register interfaces with an innovaphone PBX. It creates an implicit H.323 or SIP registration along with 2 straight routes between the interface and the VoIP interface:

It thus behaves as though you were creating a separate GWx VoIP interface in Register as Gateway mode and defining appropriate routes.

This configuration method is much simpler and less error prone and thus strongly recommended.

The implicit VoIP interfaces are named R plus a short-hand notation for the interface involved plus the index of the interface (optional). So for the BRI2 interface of an IP811, the implicit VoIP interface would be called RB2.

Interface Type
SIPx (SIP client)
BRIx (basic rate ISDN)
PRIx (primary rate ISDN)
TEST (constant MoH)
TONE (dialtone)
HTTP (webmedia HTTP client)
ECHO (test echo)
SIGx (virtual signalling)
CONF (conference)


The CDPN/CGPN fish-help.png interface mappings - configured at fish-help.png Gateway/Interfaces - may be configured individually for each interface. They are used to modify the CDPN/CGPN for in and outgoing calls, if necessary.

The following maps can be defined:
  • CGPN-In: inbound calling party number
  • CDPN-In: inbound called party number
  • CGPN-Out: outbound calling party number
  • CDPN-Out: outbound called party number
"In/outbound" here is always meant as screenshot.png seen from the routing engine.

Interface maps are used to "normalize" numbers received from (or, less likely, sent to) interfaces so that within the routing engine all numbers from all interfaces have the same format. Moreover, the routing engine just deals with numbers as digit strings. However, from the ISDN, numbers come in various flavours, such as international, national, subscriber or unknown (you know that from the basic training), known as type of number. Interface maps are used to re-format such numbers to pure digit strings, e.g.
  • international 497031730090 -> 00497031730090
  • subscriber 730090 -> 07031730090
(these samples assume that the country is Germany, the area code 07031 and the trunk access code is 0). When sending the call into the routing engine these flags get deleted. Therefore, you need to map them into according numbers.

Multiple maps can be defined for a single type of mapping (e.g. CGPN-In). This is useful as numbers may be presented in different formats. This is the case with ISDN interfaces for example.

The maps defined for the ISDN trunk line interface in this example are as follows:
  • Calling Party In (CGPN-In). These are the numbers of the calling party for calls from the ISDN into the gateway. Numbers flagged as international (e.g. 437206200680) will have 00 prefixed (resulting in 00437206200680). Numbers flagged as national (e.g. 51142356) will have 0 prefixed (resulting in 051142356). All other numbers (such as 730090 flagged as subscriber or 07031730090 flagged as unknown) will be left unchanged. As a result, the numbers are seen by the routing engine just like a user would dial them (excluding a PBX trunk access prefix)
  • Called Party In (CDPN-In). These are the called numbers for calls from the ISDN into the gateway, in other words, your local extension called. Numbers flagged as national (such as 70317300915) will have 703173009 stripped, leaving extension 15. Numbers flagged as subscriber (such as 7300915) will have 73009 stripped, leaving extension 15. All other numbers are left unchanged, however, these should not appear on this trunk anyway. Note though that in a paranoid world, your ISDN carrier could send the called party number flagged as international (e.g. 4970317300915). This however is very unlikely and we have never seen such behaviour. If it happens to you, simply add a CDPN-In map for such numbers
  • Calling Party Out (CGPN-Out). These are the numbers of the calling party for calls from the gateway to the ISDN. Numbers starting with 00 (such as 00437206200680) will have the 00 removed and will be flagged as international (resulting in 437206200680). Numbers starting with 0 (such as 0703173009) will have the 0 removed and will be flagged as national (resulting in 703173009). All other numbers (which are assumed to be local PBX extensions) will have the trunk line's subscriber number prefixed and be flagged as subscriber
  • No maps are applied to the Called Party Number Out (which are the called numbers for calls from the gateway to the ISDN), assuming that the calling user simply dialled the right number
These maps are applied only once when the call setup passes the respective interface. When overlapped dialling is used, the target number may not be present or may be incomplete at this moment. So matching full target numbers will fail! If for example, you intend to prefix a call-by-call carrier selection prefix for an outgoing call to a certain country, you could try to define a map like
  • unknown 0043 -> 010900043
(assuming 01090 is the carrier prefix). However, while this will work when block dialling is used, it will not work when overlapped sending is used. In this latter case, the setup for the outgoing call will be empty when it passes the interface (see this fish-help.png wiki article for an exception). You need to use maps in the routing table instead of interface maps for this (see the Routing Engine book).

The maps also translate the numbering plan identification properly. In our example, outgoing calling numbers (sent to the ISDN carrier) are set to have the ISDN numbering plan. Calls originating from the innovaphone PBX will always carry the Private numbering plan identification.

SIP and Type of Address / Numbering Plan Identification

SIP does not know about the phone number type of number and numbering plan properties. However, the innovaphone SIP stack implementation will present an otherwise digit-only user part of a URI which starts with a plus (+) sign (e.g. +497031730090) as an international type. All others will be presented as unknown type of number.

H.323 and Type of Address / Numbering Plan Identification

H.323 (being a descendant of Q.931) fully supports the type of number and numbering plan properties like ISDN does.

Automatic Maps

Number mapping can be tricky and it is more than easy to make a mistake here. This is why there is a very convenient configuration short-cut available called Interface Maps in the fish-help.png interface configuration dialogue.

This is for interfaces connecting to a traditional ISDN trunk line. You just need to select point-to-point or point-to-multipoint interface style, define your ISDN trunk line parameters (such as subscriber number and area code) and the maps are created automatically. Since it is so much easier to use, this method is strictly recommended!


Innovaphone gateways support the QSIG ISDN protocol on fish-help.png Interfaces/BRI/Protocol BRI and fish-help.png Interfaces/PRI/Protocol PRI interfaces. There are three different types of interconnection with third party PBX's with QSIG.

QSIG Interworking

fish-help.png QSIG Interworking is a feature of the innovaphone H.323 and SIP protocol stacks. The feature allows to translate H.323 and SIP supplementary services into QSIG supplementary services and vice-versa. So having a legacy PBX connected with an innovaphone gateway via QSIG and an e.g. innovaphone PBX we can interwork features between both, like name display, call diversion, call transfer, call completion and path replacement. H.323 to QSIG interworking supports more features than SIP to QSIG interworking, so this is the recommended protocol to use for connecting multi-brand legacy PBXs.

There are various interworking configuration tips with third party PBX´s like
fish-help.png AAstra/Ericsson MD110 interworking
fish-help.png Alcatel Omni PCX interworking
fish-help.png Hicom 150/HiPath 300 interworking
fish-help.png HiPath4000 interworking in our wiki.

QSIG Tunnelling

QSIG Tunnelling is a loose term we use for QSIG Generic Functional Procedures. This is essentially a method to communicate proprietary features through a non-proprietary tunnel via QSIG. So the method to establish this tunnel is defined, but the content communicated through the tunnel is not.

When 2 PABXs use QSIG tunnelling, they exchange proprietary information through a standard mechanism. In practice this means that the two (or more) PABXs need to be of the same brand. However, we can take advantage because we can implement the tunnel mechanism without understanding the proprietary features sent within.

For this to work, we need to establish an RAS-based connection, that is, a registration to the other side. The RAS protocol lets us exchange information so that we know there is innovaphone gear on both ends. If we detect this, we can send QSIG generic function packets via H.323. This works thus only with VoIP interfaces in Register as ... mode and only via H.323.

On the ISDN/QSIG level, there is no need for a special configuration as generic functions are a defined part of QSIG. So it is up to the PABX to use tunnelling or not. In fact, you will see that this is configured within the legacy PBX (e.g. in a Hicom/HiPath, this mode is known as fish-help.png Cornet-NQ).

Having said this, QSIG tunnelling obviously cannot be "interworked" (as the features communicated within the tunnel are not understood by the gateways).

QSIG Trunking

QSIG trunking is used when connecting 2 or more different PBX´s of different types (via IP). It differs from the 2 modes above in a way that neither the QSIG tunnelling mechanism is used nor interworking is applied. As a result, this will work with SIP and Gateway without Registration mode VoIP interfaces too. However, only basic call features will be available.

Fax/Modem bypass

Fax/modem bypass is currently supported by the IPxx10, IP30X and IP22, 24, 28 series.

When fax or modem signals are detected, the channel automatically switches from the current voice coder to a high bit-rate coder such as G.711 coder (according to the parameter FaxModemBypass). In addition, the channel is automatically reconfigured.

To transport analog modem data via a RTP channel, the following requirements must be fulfilled:

1) A network connection with no packet loss

2) A frame size of 20 ms is required

3) Disable T.38 on the TELx port where the modem is connected

4) Enable G711A or G711U exclusively

Please read also the wiki article on fish-help.png gateway synchronisation.


To see if modem bypass is in use, open the URL http://gateway-ip-address/debug.xml on your device and enable the following trace flags:

DSP control messages
DSP data messages
DSP pcm trace
TCP/UDP Traffic

You have to start the trace (wireshark), while the modem transports its data. The trace will contain the information "switch to modem bypass", if modem bypass is used.

Personal tools