Swyx Knowledgebase

WHITEPAPER

Field of application for Parlay ISDN multiplexers (kb2815)

 

The information in this article applies to:

  • Parlay i8
  • Parlay i60
  • SwyxWare all versions

[ Information | Links ]


Information

The Parlay multiplexers are - basically - ISDN routers. However, the features of these devices are way beyound the feature set of a simplay router. The range of tasks that can be handled by the devices is quite wide, because they can't only route calls, but also react to them, work on them and initiate own calls, if necessary.

There are lots of possible applications for the Parlay i60 and the Parlay i8 . The i8 is available only in one standard configuration with 8 S0-ports, while the modular concept of the i60 allows adaption to a lot of different scenarios. Because of this faxt, this article will focus mainly on the i60, when it comes to hardware descriptions - The i8 offers about the same featureset, when it comes to software, but it is limited to four NT-S0 and four TE-S0 ports, which can't be reconfigured for a different use.

Due to the modular concept of the i60, the available ports of the i60 can be configured freely within a wide range of possibilities. In total, there are four slots for ISDN modules, which can be equipped with either a PRI or a BRI module, except for the first one - This slot always has to carry a PRI module, which must be run in TE mode. This forst slot carries the master-module of the i60, which generates the clock for all other modules. The third and fourth slot don't necessarily have to be equipped with a module, they can be left open, if not needed.

Additional PRI modules can be run in either NT- or TE-mode, while BRI modules (which carry four S0 ports each) can only be used in NT mode. S0 ports to the PSTN can not be provided by the i60! ISDN devices that are connected to the BRI ports must have their own power supply - the internal supply of the BRI modules is very weak. It is theoretically possible to power exactly one ISDN phone per BRI module over the S0 bus, but this is not recommended and should only be used for testing purposes.

The PRI modules come in two different types: One has two BNC connecters, one for the rx- and one for the tx-direction, the other type is equipped with two RJ45 connectors. Since one RJ45 connector both handles the tx- and the rx-direction, there was free space available on the module, which was used for a second RJ45 connector: On this one, the rx- and tx-pairs are crossed. If the link doesn't work when the cable is plugged in, there's a good chance that the rx- and tx-pairs are mixed up, and due to the second RJ45 plug on the PRI module there's no need to look for a crossover-cable. Both of the RJ45 plugs are directly connected with no electronic parts between them, you can use either the one OR the other.

The power supply of the i60 is also quite variable: The i60 can either be powered by its internal switching power supply, which accepts a voltage range from 90 to 260 volts AC, or by the DC input which will accept 48 volts, which is widely available in PBX racks. The 48 volt feature is quite interesting for providers, because the UPS for those racks is often realised in form of a big 48V battery system. The i60, with a maximum input power of 12 watts, should not be a big problem for those systems.

The i60 also provides two serial interfaces on the front panel: One of them (in DCE configuration) is intended to be connected to a PC that has the management software for the Parlay routers (RouteMaker) installed. The second port (DTE configuration) can be used to connect more i60s (daisy chaining), and thus give the user the possibility to administrate them all with one single computer.

More information about the i60 and details about where all the different connectors are located on the device can be found in the i60 installation guide

The i60 is suitable for many different application scenarios, due to its very versatile programming features - in fact, almost all imaginable scenarios can be handled with one or more i60, as long as the project requires the routing and handling of ISDN calls in the broader sense. As a reference, there are two links to .pdf files at the end of this article - The documents show different setups for enterprises as well as for service providers. The documents contain a drawing and a list of the implemented features for each project. These examples give a good overview about the possibilities of the i60. They are a lot better suited for this than a plain list of the internal functions of the i60 would be, since a lot of the routing functions shown in the examples are realised by proper combination of the i60's routing features. A plain command list would simply not be able to clearly show how versatile the i60 can really be used.

Calls can of course be simply routed by means of a list that for example contains source- and target-numbers. The possibilites of the i60 do however exceed this by far. Calls can be handled by different rules, depending on the port they arrive at, while even the single b-channels of the port can be handled as different groups with different routing rules. Time-managed routing is available as well, and during the processing of a call messages can be played to the caller, who can also be given the possibility to control the handling of the call by means of DTMF inputs, which provides the administrator with the possibility of building more or less complex IVR systems.

Not all features of the i60 are automatically available, some of them need to be activated with special licenses. It is however not needed to change any hardware, if additional routing features are needed - If an i60 is equipped with all the necessary ports to handle all the lines involved in a project, everything else is only a matter of software or licenses.

When an i60 is used together with a SwyxWare system, it should however be noted that the IVR system (or similar complex systems) should be programmed in the SwyxWare instead of the Parlay i60. The featureset of the SwyxWare is a lot bigger for programming tasks like IVRs, and the management of the call routing scripts and possible changes in it can be done a lot easier with the script editor of the SwyxWare than with the RouteMaker tool for the i60.

When combined with a SwyxWare system, the Parlay routers offer the possibility of a "smooth migration", when an enterprise wants to exchange its classical PBX system with a SwyxWare. If for example the classical PBX was connected directly to a PRI line, an i60 with three PRI ports can be used here, as shown in the following example. The primary port goes to the PSTN, while the other two ports are each configured for NT mode and provide the classical PBX as well as the SwyxWare with the needed PRI line.

Possible migration setup with Parlay i60
Possible migration setup with Parlay i60
Click to enlarge...

To make the migration as easy and transparent as possible, in this scenario the following approach would be taken: All outgoing calls from both the classical PBX as well as the SwyxWare are taken by the i60 and routed to the PSTN, as long as there are free b-channels available. It is of course possible to run into an overload situation, because the SwyxWare as well as the classical PBX can each allocate 30 b-channels if this is not prevented by some configuration changes. Since there are no more than 30 channels available on the PSTN line, the i60 will terminate every additional call with a "busy" signal.

In the Parlay i60 some routing tables will be needed now, but they can easily be managed by the administrator with the RouteMaker software. The only work that has to be done in the classical PBX is that every user activates a call redirection before he has his "old" phone removed. As a conclusion of this article, the mentioned scenario will be explained to make clear how the three components work together.

  1. When a call comes in from the PSTN, the Parlay i60 will look up in its routing table whether the call has to be delivered to the classical PBX or to the SwxWare, and then route the call to PRI2 or PRI3 accordingly. For the caller nothing has changed, he dials the same number as before.

  2. If a SwyxWare user wants to call a user of the classical PBX, he dials the same internal number that he has used before - The SwyxWare is configured to route calls to numbers that are not assigned to internal SwyxWare users out through the gateway and to the Parlay i60. The i60 then checks its routing tables, recognizes that the number belongs to the classical PBX and routes the call accordingly. If the PBX wants to see not only the extension but also the subscriber number when a call comes in from the ISDN line, the i60 can also add the subcriber number before sending the call to the PBX.

  3. A user of the classical PBX who wants to call a user that has already "moved" to the SwyxWare, can dial a "0" (or whatever public line access prefix is configured) in front of the extension to dial out to the i60 first, which then routes the call to the SwyxWare according to its routing tables. There is however an even better way, that makes things a lot easier for the users: As the last activity before he removes his old telephone, each user of the classical system configures an immediate redirection of incoming calls, to his own extension plus a leading "0". Thie means for example that a call that comes in for extension "234" gets redirected to "0234". Every incoming call on the extension "234" in the classical PBX gets now routed out to the i60, which redirects the call to the SwyxWare system - The caller doesn't need to know anything about this, he simply dials the same number that he has always used.

An interesting "side effect" when Parlay routers are used is based on the fact that not all the ISDN interfaces have to be configured for the same ISDN standard. The interfaces can be configured for DSS1 (european ISDN), 1TR6 (old german standard), DASS2 (used in some parts of the UK) and INS (japanese standard). Because of this, the i60 - as well as the samller i8 - can be used as a protocol converter, additionally to all the other features.


Links

As far as software supplied or used by us, includes open source elements the additional terms under https://www.swyx.com/open-source apply in addition. An overview which products from the Swyx portfolio include open source elements and which open source license is relevant can be found under https://www.swyx.com/open-source.

The third-party contact information included in this article is provided to help you find the technical support you need. This contact information is subject to change without notice. Swyx in no way guarantees the accuracy of this third-party contact information nor is responsible for it's content.