Course12:Basic - Physical Interfaces
Howto configure analog and ISDN interfaces
Preparation
Concept
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).
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)
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
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.
PRI/BRI (ISDN)
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.
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.
TEL (FXS)
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.
Note - adapters do not provide PBX functionality.
CONF (Conference)
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 Conference and Bc Conference objects in the PBX. The number of conference channels available on a device can be seen on the device's home page.
For further details regarding the resources required for conferencing, you may want to read
Others
TEST
When you call a TEST interface, the built-in music on hold is played. No DSP channels required.
TONE
When you call a TONE interface, a dial tone is played. No DSP channels required.
You can configure the type of dial tone played.
ECHO
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.
SIG
Virtual signalling interfaces (internal use only).
FAX
This interface can send and receive FAX devices and is used by the innovaphone Fax Server application.
SIP
SIP interfaces are used to connect to a SIP provider for IP trunk line services. No DSP channels required.
GW
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
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 ticking the Busy on Busy / No Call Waiting check-mark.
Another option to disable secondary calls to the fax extension it to set the Busy On ... Calls property in the User object used for the fax extension in the PBX to 1.
The logical interface config
The 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
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
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
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.
Interface Routes
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.
Example:
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
Bundling Lines
Bundling Lines
Example:
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.
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
This effectively implements a hunt group.
Fax Modem Calls
Fax Modem Calls
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.
Data Modem Calls
Data Modem Calls
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
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 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 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
- 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)
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).
Recording
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 pcap2wav tool.
Note: It is also possible to do recording on VoIP Interfaces
Some more notes on the PBX Trunk Object
Setting the CGPN for diverted Calls (CLNS)
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 tick the Set Calling=Diverting No check-mark in the 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)
Partial Rerouting
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 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 ). See
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
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
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.
Caution!
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 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
- set a CFU for Henry Jekyll to Number 00043650876
- to test the call forward, call 15 from Edward Hyde's IP232
- the IP111 will 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
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
- on the IP222, switch to the Administration app, select Triton and Set as default account
- in
Maintenance / Diagnostics / Logging tick the Gateway Calls and Gateway Routing check-mark - cklick on syslog there
- on the IP222, call 070317300915 (this is Henry Jekyll who now has a CFU)
- have a look at the syslog
At this point, you will see an incoming call in the syslog and an immediate attempt for a partial rerouting:
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!