ISDN Overview

ISDN (Integrated Services Digital Network) is a digital communications line that allows for the transmission of voice, data, video and graphics, at very high speeds, over standard communication lines.

The increasing need to transfer large volumes of EDI data, in particular CAD/CAM drawings, has focused attention upon high speed, low cost, communication. The traditional X.25 service over a Packet Switched Data Network (PSDN) has been a good general-purpose communications sub-system. However, its bandwidth and cost mean that it has become increasingly unsuitable for present day EDI requirements.

X.25 over ISDN provides both the transfer speed and cost benefits required by the new scenario in conjunction with the X.25 protocol. (X.25 is a communications protocol that defines both the structure of the data packets that comprise the protocol, as well as the manner in which they will be used.)

Two types of ISDN line interface are available, Basic Rate (BRI) and Primary Rate (PRI). An ISDN line consists of two different channel types:

• B-Channel – Carries bearer services, such as digital data, video, and voice.
• D-Channel – Carries control and signalling information and can also carry packet mode data.

BRI includes two 64 kbps (kilobits per second) B-channels and one 16 kbps D channel. PRI in Europe consists of 30 B channels and one 64 kbps D channel, while in North America and Japan 23 B channels and one 64 kbps D channel are provided.

ISDN Bearer services (those that permit data to be sent from one network to another, using only the lower three layers of the OSI model) can be offered in one of two transfer modes. Circuit mode offers a connection over a circuit switched network and provides a dedicated end-to-end connection for delay-critical applications such as voice, video and real-time data. Packet mode offers a connection via a packet switched network.

Packet Switching

Packet Switched Network devices fall into two categories, Data Terminal Equipment (DTE), e.g. a PC, and Data Circuit-terminating Equipment (DCE), such as a modem or packet switch. These are normally located at the carrier’s facilities.

The ability to offer packet switching services is broken down into two types: X31 Case A and X.31 Case B.

In scenario A, ISDN does not provide packet mode services but rather provides circuit mode access to a packet handler. In essence, the DTE at the user’s site uses ISDN to establish a circuit switched connection to the Packet Switched Public Data Network’s (PSPDN) DCE. Access to the trading partner’s DTE is then conducted across the PSPDN using the ISDN B channel, as the D channel is reserved for signalling in this scenario (as it cannot carry the circuit switched data).

In scenario B, the PSPDN capability is ‘embedded’ into ISDN and packet services are offered. When a connection is formed, the packet handling function is this time part of the ISDN network. This allows the user (DTE) to see the local exchange as a DCE and in turn permits a connection between trading partners (DTE to DTE).

As the local exchange has packet switch capability and will therefore be able to handle X.25 packets on arrival (i.e. the D channel does not have to be reserved for signalling), communication can take place on either the B or D channel. In the OFTP environment, the D channel is used.

ISDN support in DI products

The following products provide ISDN support:

• EPIC
• ODEX Enterprise
• DINET
• BACS.IP
• DEVILS
• ODEXplus
• ODEX/400
• ODEX/MVS

CAPI Overview

Common ISDN API (CAPI) is an application-programming interface used to access ISDN equipment. CAPI enables applications to access ISDN adapters in a straightforward manner and allows unrestricted use of their functions through a standardized software interface. This interface, which offers a single point of access to different ISDN services such as data, voice and fax can then be used by applications.

The use of CAPI allows applications to communicate over ISDN lines without having to cater for differences in hardware manufacturers’ specifications. Furthermore, in the event of future hardware developments, applications will remain unaffected, as CAPI will make any changes transparent to the application.

CAPI includes a number of important features including:

• Support for basic call features, such as call setup and call clearing
• Support for multiple B channels for data and/or voice connections
• Support for one or more BRI (Basic Rate Interfaces) and PRI (Primary Rate Interfaces) on one or more ISDN adapters.
• A transparent interface for protocols above Layer 3 in the OSI 7 Layer model.

The interface of CAPI is located between Layer 3 and Layer 4, and provides a point of reference for applications and higher-level protocols.

CAPI 2, which has replaced CAPI 1.1, allows applications to access multiple devices and multiple interfaces within those devices. Data Interchange Plc products supporting CAPI all support CAPI 2.

CAPI Messages

The communication between an application and CAPI occurs asynchronously using messages defined within CAPI. A message sent in either direction is always followed by an appropriate reply.

Messages initiated by the application are called Requests. A Request is followed by a corresponding message from CAPI called a Confirmation.

Messages initiated by CAPI are called Indications and the corresponding message from the application is called a Response.

The messages communicated are always ended by the appropriate suffix for that message type (_REQ, _CONF, _IND and _RESP).

Every message sent between the application and CAPI contains an identifying message number. When a Request is sent from an application to CAPI, the Confirmation sent in reply will always contain the same message number as the request. Indications sent from CAPI to the application are numbered uniquely and the application is prohibited from sending a Response unless it is in reply to an Indication. CAPI will ignore any such messages that are sent from the application.

The messages sent between applications and CAPI are split into three categories.

1. Messages concerning the ISDN signalling protocol, which are used on the D-channel
2. Messages concerning logical connections (B or D-channel)
3. Administrative messages

Of these three categories the signalling messages and the logical connection messages provide a useful insight into understanding how a request for a connection is managed.

Example Signalling Messages

Example Logical Connection Messages

Message Queues

The actual communication between the application and CAPI utilises message queues. There is a single message queue for CAPI and one message queue for each registered application.

Messages sent from the application (Requests) are placed into the CAPI message queue for processing. In the reverse direction messages sent from an ISDN controller (Indications) are placed into the message queue of the addressed application.

Utilising Message Queues

Before an application can send messages to CAPI, it must first register itself with CAPI. This is performed using the CAPI_REGISTER function, which is called by CAPI to assign the application a unique ID and to setup the application’s message queue.

All messages sent by the application are placed into the CAPI message queue, using the CAPI_PUT_MESSAGE function. In the event that the CAPI message queue cannot accept any more messages, this function will return an error.

CAPI manages the queue for each of the registered applications. Applications call the CAPI_GET_MESSAGE to obtain any new messages from this queue.

The CAPI functions such as the PUT and GET functions are made available to Windows applications in the CAPI2032.DLL. This DLL is copied to the local machine during the installation of the CAPI hardware and associated software.

CAPI Example: Establishing an outgoing call

The application first requests an outgoing physical connection and CAPI provides confirmation of this back to the application. CAPI then notifies the application that a physical connection has been activated and the application sends a response back.

The application then sends through a request to initiate a logical connection over the B-channel. This request is acknowledged by a corresponding confirmation from CAPI. CAPI then indicates to the application that a logical connection has been activated and the application sends a response back.

CAPI Configuration

As CAPI allows applications to control ISDN hardware devices, the configuration of a local CAPI device, such as an Eicon Diva Pro Card with ODEX Enterprise, is very straightforward. The installation of such a card will copy the required CAPI2032.DLL onto the machine and enable ODEX to control the ISDN interface.

RCAPI

The functions provided by CAPI can also be used to control remote hardware devices, such as a Cisco 801 or a Bintec X1000 router.

CAPI is currently only supported on the 800 series Cisco routers. The 801 has been successfully tested with ODEX applications and the 803 is also compatible.

The 801 router is not modular and so cannot accept additional hardware. It is limited to a single Ethernet connection and a single BRI connection (plus an RS232 console port).

The router needs to have IOS version 12.1(2)T or above

In some scenarios, for example when using a Cisco 801 router, additional third party software may be required to enable the application to remotely access the CAPI functions. When using the Cisco 801 router, the RVS-COM Lite software is required to allow a machine on the local area network to initiate calls on the Cisco router.

CAPI support in DI products

The following products provide CAPI support:

• ODEX Enterprise
• ODEXplus
• DEVILS