Course12:Basic - Physical Interfaces

From innovaphone-wiki

Jump to: navigation, search

Howto configure analog and ISDN interfaces



As we will do some practice later on, you should load the Analog_or_ISDN_interfaces_Book start configurations to your devices.


Each innovaphone gateway has analogue, SIP or ISDN interfaces and can work as media-gateway in order to convert ISDN/analogue signals to VoIP (and vice versa). Depending on the device type, you will have a combination of PRI, BRI and analogue ports. They can be used to connect a PBX to an ISDN provider or to connect ISDN or analogue phones, faxes and modems. SIP interfaces can be used to connect to a SIP provider as trunk line and are available on all gateway devices.

Please note that there are some devices with analogue ports to connect analogue endpoints (FXS) and others with analogue ports to connect to a PSTN provider (FXO).

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 interface-concept

As shown in the picture above, the PRI interface of the second device registers at the PBX running on the first device. By this method you can bundle any number of interfaces on one PBX.

A BRI/PRI license is required in order to activate an ISDN interface on the device (some devices however have all required interface-licenses already built-in). Also, to convert analogue or ISDN calls to VoIP, DSP licenses are needed (one per concurrent call on that interface).

The DSP is a piece of hardware which enables transcoding between two different media types.
There are two different media types:
  • IP (VoIP)
  • TDM (ISDN, analogue, conference)
So a DSP would be needed when making a call from a VoIP phone (IP) to an ISDN (TDM) or analogue device. Also for a call from a VoIP phone to a conference circuitry on a gateway.

No DSP-License (a.k.a. channel license) would be needed for a call between two VoIP phones or between two ISDN interfaces on the same device. If a VoIP call has ISDN or analogue interfaces on both ends (e.g. a call from one ISDN interface on one box to an ISDN interface on another box), a DSP licenses is required on both ends.

Please note that no DSP nor interface licenses are needed for calls from/to SIP trunks (which are a special occasion of IP (VoIP) calls).

The configuration of an 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 (but in older gateway series only, this has been fixed meanwhile). 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.


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.


In older gateway generations, only FXS interfaces (where you usually connect a phone to) were supported. Therefore, all analogue interfaces were called "TELn". Nowadays, some gateways also support FXO interfaces however. In this course, we do not talk about FXO though.

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.

Some of the innovaphone link_intern.png gateways offer FXS or FXO interfaces. The link_intern.png adapters offer different amount of FXS interfaces.

Note - adapters do not provide PBX functionality.

CONF (Conference)

Some of the innovaphone gateways feature a conference interface called CONF.

This interface can handle multiple concurrent calls and can mix the audio stream to provide audio conferencing service. Also, if the caller supports video or application sharing, it can distribute the video and application sharing data to the participants in a conference.

There is nothing that needs to be configured for this interface. However, you need to understand that a CONF interface is one of the TDM interfaces. When VoIP phone call into a conference, DSP channels and hence licenses are needed.

The CONF interface is usually used in combination with the fish-help.png Conference and fish-help.png Bc Conference objects in the PBX. The number of conference channels available on a device can be seen on the screenshot.png device's home page.

For further details regarding the resources required for conferencing, you may want to read fish-help.png Conferences, Resources and Licenses.


There are some more physical interfaces, which are less commonly used.


When you call a TEST interface, the built-in music on hold is played. No DSP channels required.


When you call a TONE interface, a dial tone is played. No DSP channels required.

You can configure the type of dial tone played.


When you call a ECHO interface, your voice is echoed back with a slight delay. This is for test purposes as you can exercise a connection with needing anyone at the other end. No DSP channels required.


Virtual signalling interfaces (internal use only).


This interface can send and receive FAX devices and is used by the innovaphone Fax Server application.


SIP interfaces are used to connect to a SIP provider for IP trunk line services. No DSP channels required.


GW interfaces are used to connect to foreign VoIP destinations in special scenarios (e.g. for VoIP peers which do not support registration). No DSP channels required.

Fax Devices connected to FXS Interfaces

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 IP411RIGHT 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 Lines

Bundling 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 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.

The distribution of outgoing calls to all registered interfaces works, because when there is more than one registration on a Trunk Line PBX object (as is the case when it is served by more than one interface), it will send outgoing calls to all the registrations in a round-robin fashion (that is, each call is delivered on the next interface).

When a registration reports one of the fish-help.png Rerouting Causes for such a call, the call is passed to the next available registration. Such a re-routing cause might for example be a No circuit/channel available cause which happens if a PSTN trunk line is fully engaged.

This effectively implements a screenshot.png hunt group.

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 IP411RIGHT connected to a BRI makes for a nice 2-port splitter).

SIP Interfaces

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).


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.

Some more notes on the PBX Trunk Object

Setting the CGPN for diverted Calls (CLNS)

Consider the following straight forward scenario:

screenshot.png External call forwarded to extern

This will for example happen if a user has a call forward to his own mobile phone.

In this situation, the forwarded call will be sent from the PBX to the provider with the original calling party number 0511271. By default, the provider however will try to verify the CGPN against the trunk line's subscriber number (which is 73009). This of course fails and the provider will replace the CGPN by the lowest extension available to the trunk (usually 0). The mobile phone thus will receive +49 7031 73009 0 as calling party number. This of course is unfortunate, as the user can not see the original callers party number.

There are several ways of fixing this.

  • If PR is applicable and works, the provider will send the original PR in the rerouted call
  • if the provider supports clip no screening (CLNS), then the provider will skip the verification of the calling party number and will send the provided one
  • If all this is not possible, a last resort is to screenshot.png tick the Set Calling=Diverting No check-mark in the fish-help.png Trunk object configuration. If so, the outgoing forwarded call will use the number of the diverting party (the user with the call forward) as calling party number. On the mobile phone, the user would at least see that this is a forwarded call (as it shows his own extension as calling party number)
Please note that CLNS requires fish-help.png careful configuration of the outbound calling party number maps. Fortunately, the configuration wizard available in all boxes (described in a later topic) will do this configuration for you.

Partial Rerouting

When an external call comes in through a fish-help.png Trunk object and is routed back through the same Trunk, the PBX will normally create two independent calls (one inbound, one outbound) and loop the media channel back and forth. This is a very common scenario when a call is forwarded to an external destination (such as a cellular phone) by a call forward or an external transfer. This works well, but it consumes 2 channels for each forwarded call! A simple basic rate interface would be fully engaged with only one forwarded call thus!

Partial Rerouting (PR)

If the situation is caused by either a CFU or a CFB (as opposed to a transfer) and the Reroute supported property is set, the Trunk object will try to notify the underlying trunk (e.g. the ISDN interface registered to the Trunk object) to handle this situation directly. On an ISDN line for example, a Call Rerouting or Call Deflection is attempted then.

The benefit of this is that the reroute is handled in the central office's switch and you get rid of the 2 B-channels used in this situation otherwise.

For this to work, the underlying fish-help.png route to the physical interface in the gateway layer configuration must have the Interworking(QSIG,SIP) property set. This is also the place to decide if either partial rerouting or deflection shall be used (under control of the Rerouting as Deflection check-mark). Which type must be used depends on your PSTN provider. If in doubt, you can try it out (no harm if mis-configured, it just doesn't work smile). See fish-help.png How to Configure EDSS1 Partial Rerouting for more details.

screenshot.png Reroute Settings

This feature can be interworked towards E-DSS1, QSIG and SIP.

Please note that both partial rerouting and deflection must be supported by the provider. If the provider does not support it but an attempt is done to use it (cause the Reroute supported check-mark is ticked in the Trunk), the outgoing call will fail!

Explicit Call Transfer (ECT)

If the situation is not caused by a rerouting during call setup time, but later (either a CFNR that transfers the call after an internal extension has been alerted already or a call transfer during a connected call), an fish-help.png Explicit Call Transfer ECT is performed.

For ECT to work, the Interworking(QSIG,SIP) must be set in the routes from/to the PSTN interface as for PR. In addition to that, to enable any kind of external transfer (with or without ECT), you need to tick Enable External Transfer in PBX / Config / General.

As with PR, ECT must be supported by your provider. However, as opposed to PR, if the provider does not support it, the PBX will fall back to the non-ECT method. So 2 channels will be engaged, but the transfer will work. If your provider supports ECT only but no PR, then you need to set Interworking(QSIG,SIP), but not Reroute supported.


Both methods allow call flows where you wil be charged for calls you do not control anymore!

External call transfer during a call can thus be disabled by un-checking the Enable External Transfer check-mark. Partial rerouting situations caused by call forwardings can be disable by setting screenshot.png appropriate filters in the User object's Diversion Filter.

To practice, please configure Call Deflection for the Trunk.
  • turn on Reroute supported in the PBX Trunk object
  • tick the Interworking(QSIG,SIP) check-marks in the routes from and to BRI1
  • tick the Rerouting as Deflection check-marks in the routes from and to BRI1

To trigger the reroute situation

  • screenshot.png set a CFU for Henry Jekyll to Number 00043650876
  • to test the call forward, call 15 from Edward Hyde's IP232
  • the IP111 will screenshot.png alert with a call from unknown (remember that we had configured CLIR before!)

Now we can try the partial rerouting. Unfortunately, it won't work sad

As said before, the PSTN provider must support it and our little PSTN simulation in the IP811 does not!

To see the effect of such a non-supporting provider with partial re-routing

At this point, you will see an incoming call in the syslog and an immediate attempt for a partial rerouting:

screenshot.png Failed PR

However, the caller hears silence only and the call stays in this state forever. Only when the caller hangs up, we see the call clearing in the syslog.

But don't be worried, it's not your fault. In real life, if your PSTN provider supports it, it will just work!

Personal tools