Course11:Basic - Analog or ISDN interfaces

From innovaphone-wiki

Jump to: navigation, search

Howto configure analog and ISDN interfaces with innovaphone



Each innovaphone gateway has analog or ISDN interfaces and can work as media-gateway in order to convert ISDN/analog signals to VoIP (and vice versa). Depending on the device type, you will have a combination of PRI, BRI and analog ports. They can be used to connect a PBX to an ISDN provider or to connect ISDN or analog phones, faxes and modems. Please note that it is not possible to use an analog interface to connect to a PSTN provider. innovaphone a/b ports work only in FXS mode, this allows only analog endpoints to be connected to them.

The most important fact to understand is that even though interfaces are physically bound to a device, they can logically belong to a different device (be registered at a different PBX).

screenshot.png ISDN-interface_concept

As shown in the picture above, the PRI interface of the second device registers at the PBX working on the first device. By this method you can bundle any number of analog or ISDN interface on one PBX, as it is needed for the respective installation.

A BRI/PRI license is required in order to activate an ISDN interface on the device. You can choose on any device, the number of ISDN interfaces and DSPs to be used.

The DSP is a piece of hardware which enables transcoding between two different media types.
There are three different media types for most innovaphone devices:
  • IP(VoIP)
  • ISDN
  • analog (as of V7 innovaphone devices with analog ports have all DSPs activated by default)

So a DSP would be needed when making a call from a VoIP phone to an ISDN or analog device. No DSP (i.e. channel license) would be needed for a call between two VoIP phones. A often misunderstood fact is that a call from an analog phone to an ISDN device will use two DSPs. First the analog voice must be converted to VoIP and then the VoIP stream must be converted to ISDN.

The configuration of an ISDN or analog interface can be divided in three parts:
  • the physical interface config
  • the 'logical' interface config
  • the interface routes

Physical Interface Config

This part of the configuration is about getting the physical link on the respective interface up and running. The settings can be found in the screenshot.png configuration menu of every innovaphone device.

Usually you can deduct the interface type from the name used in the configuration menu (e.g. PRI1, BRI1). Unfortunately the name TEL is used for BRI interfaces but also for analog interfaces. However after you get accustomed to the different innovaphone devices and their capabilities, this issue shouldn't be a problem.

Let's have a look at the specific interface types. As always use innovaphone Wiki to get a detailed overview of all configurable options. In this book we will concentrate on the most important points.

The PRI/BRI Interface

Physical Config Menu

As with every ISDN interface you should first decide if it should work in NT or TE mode. Usually the default option, the TE mode, is used, since this mode is needed to connect to an ISDN provider. The NT mode is used when connecting a ISDN device (e.g. phone) or when configuring a soft migration scenario. In a soft migration the interfaces to the old PBX are in NT mode, in order to simulate the ISDN provider. In most scenarios the clock mode of the interface should be left in its default state. This will result in a NT interface providing a synchronization clock, while a TE interface will accept synchronization from its NT counterpart.

Protocol Config Menu

Here you can choose the ISDN protocol type (i.e. EDDS1, QSIG or other US specific protocols) for this interface. The EDSS1 protocol has gained worldwide acceptance for ISDN subscribers and is also common outside Europe. This protocol is used when connecting to an ISDN provider or when connecting ISDN devices to the PBX.
The QSIG protocol is an enhancement of the EDSS1 protocol and is used to interconnect PBX-systems over ISDN trunks. The advantage of QSIG over EDDS1 in this specific scenario is that the it can transport a wider range of PBX features over the ISDN line. However keep in mind that an ISDN interface configured to use the QSIG protocol can never be used as an ISDN trunk to the PSTN.

A BRI only setting is the option to set the mode of the interface. You can choose between a Point-to-Point or a Point-to-Multipoint link.

screenshot.png MSN-DDI

A Point to Multipoint (PtMP) trunk can be used only with BRI interfaces. The ISDN provider assigns different subscriber numbers (Multiple Subscriber Number - MSN) to this ISDN line. A BRI line can have up to 10 MSNs assigned to it. The numbers can be randomly assigned from a number pool assigned to the provider and are often in no relation to another. The PtMP trunk is often used to connect small size companies or home-offices.

A Point to Point (PtP) trunk can be used with both BRI and PRI interfaces. The ISDN provider will assign its customer a trunk line number and a range of allowed extension numbers. This type of trunk line is only limited by the amount of B-channels offered by your physical ISDN connection (PRI or BRI).

Interop / State / Statistics Config Menu

The Interop menu is used for special/unusual configuration. By using this menu you can hand-pick which H.323 option/information will get converted to their corresponding ISDN message.

The State menu is useful to check the current status of the interface. Also when having a PRI interface, it is possible to see which of the 30 B-channels are currently in use.

The analog TEL interface

A TEL interface should normally operate without further adjustments in the Physical or Signaling configuration menu.

Using these parameters, the interface can be adjusted to special conditions like long distance analogue lines or loud working environments. Again, have a look at the corresponding wiki Help pages to read more about the possible settings.

Please note that analogue interfaces differ in terms of their use - that is connection of analogue subscriber devices (phones, faxes) via FXS-interface; or connection towards an analogue trunk line - called FXO interface.

innovaphone offers gateways or adapters providing either FXS or FXO interfaces.
The link_intern.png IP302 and the adapters link_intern.png IP22, IP24 and IP28 offer different amount of FXS interfaces. Note - adapters do not provide PBX functionality.

For FXO interfaces, innovaphone offers the link_intern.png IP38 PBX which provides 8 analogue trunk lines.

Fax Devices

The PBX supports call waiting and so do analogue interfaces.

However, when a fax is connected, presenting an additional call to the fax device when it i already engaged in a fax transmission does not make sense. Even worse, it would disturb the current transmission. This is why you want to disable secondary calls to a fax extension right away.

This can be done on the interface level by screenshot.png ticking the Busy on Busy / No Call Waiting check-mark.

Another option to disable secondary calls to the fax extension it to screenshot.png set the Busy On ... Calls property in the User object used for the fax extension in the PBX to 1.

The logical interface config

After setting up the physical link for the interface, you must configure the outgoing/incoming number mapping and associate (register) it to a PBX.

The screenshot.png GW - Interfaces menu allows to configure the PBX at which the interface should register. The settings will vary depending on the signalling protocol in use. In most scenarios it is best to use the H.323 as signalling protocol.

Next you must configure the number mappings that have to be done at the interface. There are two automated mapping configurations for Point-to-Multipoint or for Point-to-Point trunks. As a third option it is possible to configure the mappings manually. It is recommended to always use the automated mappings first and then adjust them manually if needed.

The interface maps

At this point you can manipulate the calling or called numbers for outgoing or incoming calls. The idea is to bring the numbers passing the interface in an unified format. For incoming calls this is a format understood by the PBX, i.e. extensions. Outgoing calls must have a number format known in the PSTN.

innovaphone divides all manipulable numbers in four categories:
  • CGPN-In: the Calling Party Number coming from the PSTN or connected device to the PBX
  • CDPN-In: the Called Party Number coming from the PSTN or connected device to the PBX
  • CGPN-Out: the Calling Party Number coming from the PBX to the PSTN or connected device
  • CDPN-Out: the Called Party Number coming from the PBX to the PSTN or connected device
The interface maps are the only point where the PSTN specific number formats can be interpreted and converted in PBX specific numbers, and vice versa.

Incoming calls

For calls coming from the PSTN the numbers can have three different flags. These flags are unknown in the PBX and must therefore be converted.

As an example the ISDN flags used in Germany are:

International (I) - equivalent to 00
National(N) - equivalent to 0
Subscriber(S) - local area call marking, no number map

screenshot.png Number-maps-incoming

As you can see in the picture above, not only the ISDN flags must be substituted but also the CDPN must be converted to a PBX extension.

Outgoing calls

For outgoing calls the mappings discussed in the previous part (incoming calls) must be reversed. The PBX - extension must be mapped to its corresponding PSTN number and the ISDN flags must be inserted in the CDPN and CGPN. Additionally you must consider that the ISDN has a numbering plan attribute. For incoming calls this attribute can be ignored but outgoing calls should have the numbering plan attribute set to ISDN. If this is not configured CLIP will not work because the ISDN provider will reject the CGPN numbers received from the PBX.

screenshot.png Number-maps-outgoing

Interface Routes

When registering an interface to a PBX, the corresponding routes are automatically created. These routes allow to decide where calls shall be sent to (e.g. another interface or PBX) depending on the CDPN. Also they allow to further manipulate the incoming and outgoing CDPN and CGPN.

Such an automatic generated route will always create a logical endpoint representing the PBX. This special endpoints are named according to the interface that created them, i.e. RB[1-2] (BRI) , RT[1-4] (TEL), RP[1-4] (PRI) and RAB[1-8] (analog TEL). Even though the names are slightly different, they have in common that always represent the PBX (registration point of the interface) as routing endpoint.


If you configure the BRI1 interface of your IP302 and register it at the local PBX, you will automatically generate two routes:
  • BRI1 -> RB1 - for calls going from the BRI interface to the PBX
  • RB1 -> BRI1 - for calls going from the PBX to the BRI interface

Special scenarios

When working with ISDN interfaces, there may come up several other requirements.

In particular, these are

  • bundling of ISDN lines if the amount of interfaces offered in one gateway is not sufficent
  • realisation of fax modem calls via ISDN
  • realisation of data modem calls via ISDN
These topics are discussed in the following subchapters.

Bundling ISDN lines

Bundling ISDN lines

Depending on the size of the installation, it may be required to cluster a number of ISDN interfaces to one PBX (i.e. one trunk line).


A company needs an ISDN trunk for 80 concurrent calls. To implement this, 3 PRI interfaces and 80 channels are needed. Since one IP6010 has a maximum of 60 channels, you would need a second gateway in order to connect the third PRI interface.

screenshot.png ISDN-interface_bundling

To bundle the PRI interfaces you would activate on one of this two gateways the PBX and register all three ISDN interfaces at one PBX object (i.e. Trunk Line object). The number mappings and routes of these interfaces would have the same configuration, since all three trunk lines will use the same ISDN number.
Outgoing calls are distributed by the PBX equally on all three interface, using a Round Robin mechanism. The allocation of incoming calls to the ISDN interfaces cannot be influenced since it is handled by the ISDN provider.

Fax Modem Calls

Fax Modem Calls

When installing analog ports serving a fax device, special attention is needed. innovaphone offers two possibilities to transport fax calls over IP.

The first method is to synchronize all gateways in your LAN to one clock source. This source can be an innovaphone device synchronized to the PSTN or to a NTP server. Since all devices have the same clock rate, it is possible to simulate a continuous cable connection between the analog interfaces and by this use G.711 as codec.

The drawback of this method it is only applicable in a LAN. When connecting two fax devices over a WAN connection the delay and jitter of IP packets is to high. As a result a special fax protocol named T.38 must be used in this case. The T.38 method is less desirable than using the synchronization method, because of a lower data transmission speed.
When connecting a modem to an innovaphone gateway, you have only the first option since the T.38 protocol cannot be used for modem calls.

A very useful fax - feature is the error correction mode (ECM). When enabled on a fax machine, the receiving fax device will check the fax for errors. If any errors were found, the missing fax part will be retransmitted. This is feature may cause longer transmission times, however it will result in a better quality of the received fax. Therefore it is recommend to enable ECM if it is supported by the fax machine.

A possible drawback of ECM is its use in networks with very low QoS - values(e.g. high jitter, delay or packet loss). In this case, ECM may cause the fax transmission to be aborted because of too many retries. Some VoIP specialists argue that ECM should be disabled in such cases, since being able to send a fax with bad quality is better than not sending a fax at all. However, this is not a recommended solution - in this case you would be better advised to check the causes for the bad network connection instead of explaining the customer that he must live with the bad fax quality.

screenshot.png Fax-modem

Data Modem Calls

Data Modem Calls

Although fax calls are strictly speaking only a variant of data modem calls, their requirements on the IP network QoS is much more relaxed than for real modem calls. Unfortunately, as a result, data modem calls generally do not work reliably. Why this?

Fax calls use low speed modem types and there will be a new modem renegotiation with training on a per-page basis. Also, fax nowadays supports error correction (ECM) so that failing pages will be retried. This makes fax transmissions much more robust than data modem calls.

Data modem protocols were designed with the characteristics of analogue lines in mind. They for example care for long delays or some noise (that is, corrupt data) on lines. However, VoIP IP transmission suffer from different type of quality issues, jitter and packet loss. These do not happen in old style PSTN lines and thus, modem protocols do not care for such problems.

So if you must relay data modem calls over VoIP, be sure to
  • create a subnet between the VoIP termination points which has no jitter and no packet loss (e.g. using a dedicated switch)
  • make sure you synchronize all involved VoIP devices (as explained above)
  • try out the resulting setup to make sure it performs as you need it to do

Do not employ VoIP in scenarios, where you do not fully control the environment! If modems on either side may change, or the customer may need to install more or different modems, don't use VoIP to relay the data modem calls as each change in setup may affect the overall performance.

In such cases, consider using dedicated analogue lines or a splitter to break down BRI or PRI lines to a/b ports (for example, an IP302 connected to a BRI makes for a nice 2-port splitter).


Starting from V8 it is possible to do fish-help.png recording on Analog and ISDN interfaces.

Means any call performed via the Analog or ISDN interface will be recorded when the record URL is configured on this interface.
The recorded file will be stored on a WebDAV server (e.g the CF card). It will be stored as a Pcap file, with the a unique call identifier called guid as file name. By analysing the CDRs it is possible to correlate called and calling party number to the recorded file.
The file can simple be played using the wireshark trace tool. It also can be converted into wav format by use of the fish-help.png pcap2wav tool.

Note: It is also possible to do recording on VoIP Interfaces fish-help.png Gateway/GK. Therefore the media stream needs to be routed through the recording VoIP interface. This requires to activate media relay on the interface. Further details will be given in the advanced training SIP topic.
Personal tools