In the following discussion the use of CAPI is compared with that of the AT Command Set as an API for developers who want to design applications which exploit the services of the ISDN.

At the outset it should be recognised that the AT Command Set is used for call establishment and control between the DTE and its associated DCE via a serial port by means of AT commands. The DCE, called a digital modem in the US and a Terminal Adapter in Europe, may be an internal PC card or an external device. CAPI is used with internal PC cards. CAPI supports all the popular Operating Systems and the AT command set, used with a DCE as an external device, is independent of the Operating System employed by the DTE.

A comparative analysis of the advantages and disadvantages between the two DTE to DCE communication techniques should take account of the following points:

(i) Bandwidth and Data Throughput Considerations

Under normal circumstances all adapters are limited by the fact that the data from the DTE is restricted by the serial port to a maximum throughput of 115 kb/sec. Current B channel aggregation algorithms employed by adapters achieve throughputs of 112 kb/sec. Adapters have access to a maximum of two B channels and this limits synchronous data access to the ISDN.

With CAPI, B channel aggregation algorithms are available for ISDN cards which support basic rate access and throughputs of 126 kb/sec have been achieved over the combined B channels. The effect of this enhanced throughput for CAPI applications is readily seen in video applications.

There are, in addition, several CAPI cards on the market which support access to multiple B channels and these may be used by applications which require more bandwidth. In Europe, Narrowband ISDN offers a bandwidth of up to 30 X 64 kb/sec while in the US and Japan a bandwidth of up to 23 X 64 kb/sec is allowed.

The inability of adapters to provide access to the full bandwidth which ISDN offers significantly restricts the range and variety of applications which they can support. Quality video applications, for example, employ a bandwidth of 6 X 64 kb/sec.

(ii) Design Flexibility

As applications that work with a specific adapter cannot invoke services which are not supported by the adapter, it is clear that the functionality of the application will be limited by the hardware. The feature list of the adapter is defined when its chipsets are programmed during manufacture. It is very difficult to extend these features at a later stage. This point is illustrated in point (v) below.

(iii) Standards Issues for Adapters

Applications which are designed to work with adapters, i.e. employ AT commands to communicate with and invoke the services of adapters, must, therefore, be tailored to work with a specific range of adapters.

(iv) Standards Issues for CAPI Applications

CAPI is a standard recognised by the European Telecommunications Standards Institute (ETSI). All CAPI applications may be designed without consideration of the hardware as these applications will work satisfactorily on all CAPI cards. In the discussion on the steps involved in call establishment, the role of the BCC IE Information Element was highlighted. It was also emphasised that CAPI applications employ a coding in their messaging system between the application and CAPI which is a mirror image of that employed by the Information Elements in the CCITT defined Layer 3 messages.

CAPI supports the full range of important Information Elements as defined by the CCITT so applications can be programmed to fully exploit all the key services of the ISDN. In summary, CAPI has been designed specifically to allow applications developers fully exploit the full range of services offered by this network.

(v) Design Issues

The implications of the standards issues may best be summarised by a specific example. Say, for example, a developer wishes to provide asynchronous PPP to synchronous PPP conversion to enable applications access the Internet in conformity with the RFC 1618 standard. If this is implemented for a CAPI application it will work on all CAPI systems.

A similar development implemented for adapters (which do not already have this conversion capability) may be employed only with those adapters which use the same programmable chipset. The programming changes must be implemented with a proprietary code which alone can communicate with the chipset.

The design effort is, therefore, both time consuming, costly and has limited applicability.

This example highlights the scope provided by CAPI for independent developers to exploit the full range of services of the ISDN by means of innovative applications which can be marketed to all CAPI card users. In a similar way it explains why it can make commercial sense for CAPI developers to extend existing applications by means of standard software design.