IE921716A1

IE921716A1 - Application program interface

Info

Publication number: IE921716A1
Application number: IE171692A
Authority: IE
Inventors: Frank Bergler
Original assignee: Alcatel Nv
Priority date: 1991-05-29
Filing date: 1992-07-01
Publication date: 1992-12-02
Also published as: EP0515967A3; NO921996D0; EP0515967A2; AU651451B2; EP0515967B1; FI922438A0; ES2127200T3; NO306750B1; AU1639192A; FI922438A; DE59209575D1; FI106084B; DK0515967T3; NO921996L; DE4117510A1; ATE174179T1

Abstract

It is the object to implement an application program interface for integrated-services networks so that application programs can be generated independently of network protocols (layer 1, 2; 1TR6, VN2) and independently of the respective implementation of features. The application program interface receives an independent service program module for each network service (telephony, telefax, packet data, teletex ...) each having a communication record representing function sequences and oriented by standards (CCITT, ETSI ...). <IMAGE>

Description

This invention relates to an application program.

To be able to connect various application programs of personal computers (PC) with a PC card for an integrated 5 services digital network (ISDN), an application program interface (API) is needed, such an application program interface makes it possible to use PC application programs independently of the type and manufacture of the PC card for the ISDN network (ISDN - Wann geht die puste aus?, Funkschau, No. 23, 1989, pages 24-31).

One prior art application program interface, the socalled Common ISDN API, ensures that PC application programs (e.g., for file transfer, terminal emulation) are adapted to the ISDN environment independently of the PC ISDN card.

This application program interface, however, is not yet usable internationally for different ISDN protocols for the ISDN D channel (PC-Kommunikation, Ende des Chaos?, Funkschau, No. 8, 1989, pages 26-30).

The common ISDN API is designed specifically for the ISDN protocol 1TR6 of the German Bundespost, so that for protocols in other countries, such as France or the USA, the application programs have to be adapted.

Accordingly, an object of the present invention is to implement an application program interface which enables different PC application programs to be adapted to an integrated services digital network, the application programs being generable independently of the individual network protocols and the different implementations of service features by these protocols .

According to the present invention there is provided an application program interface providing a connection between a plurality of different application program modules (Appl, App2, App3) and a network interface (ACID) of an integrated services digital network (ISDN), the application program interface (API) containing a service program module (packet data, Telephony, Teletex, FAX Gr 3/4) for each service of the network, each service program module containing a message set representing specified procedures for the individual service, and the application program interface containing means for exchanging the message sets between the application program modules (Appl, App2, App3) and the network interface (ACID).

Unlike conventional application program interfaces, which, being network-oriented, contain only one common message set, e.g., one common call connect message, for all services, the modular construction of the application program interface according to the present invention eliminates the hitherto existing complexity (the more services, the more complex). Thus, changes are readily possible at any time and no longer necessitate changing all application program modules.

The division of the integrated network services into the individual service program modules for the (basic) services, such as packet data, telephony, FAX group 3/4, teletex, etc., such that each service program module contains a message set representing specified procedures, permits each application program module to be created above layer 3 of the OSI (Open System Interconnection) model independently of the subsequent specific implementation of each application program module in accordance with (national) protocols. Advantageously, procedures already defined for the individual services by international standards (CCITT, ETSI, ECMA, etc.) will be specified for the individual services.

Even if a service has not been standardised yet, a self-generated message set can be offered which can be readily changed after standardisation, since, unlike prior art solutions, no changes are required in the other service program modules of the application program interface, because an independent service program module is provided for each service.

To exchange the message sets between the application program modules and the network interface, it suffices to provide the application program interface with registers for storing each start call and each release call, so that an exchange is possible by means of associated message queues.

One exemplary embodiment of the invention will now be explained with reference to the accompanying single figure drawing which is a block diagram of an application program interface in accordance with the invention.

As shown in the drawing, an application program interface API in accordance with the invention is connected to a plurality of different application program modules Appl, App2 , App3, which can be run on a personal computer, for example. It forms an interface to a network interface ACID of an integrated services digital network ISDN.

The application program interface API contains an independent service program module Packet data, Telephony, Bit-rate adaptation, Teletex, FAX Gr 3/4. Videotex - for each service of the network ISDN. Each of the service program modules contains a message set representing specified procedures (on OSI Layer 3).

Advantageously, an internationally agreed standard (e.g., CCITT, ETSI, ECMA, etc), if present, will be used as a basis for each service.

In the present embodiment, CCITT Recommendation X.213 is used for the services Packet data, Teletex, and FAX Group 3/4. The procedures for the services Bit-rate adaptation and Videotex are specified in CCITT Recommendation V.110/V.120 and in ETSI Recommendation ETS 300079, respectively. For Telephony, an ECMA standard may be used. Examples of the respective message sets are given in the annex provided at the end of the description.

For the exchange of message sets between the application program modules Appl, App2, App3 and the network interface ACID, the API contains registers for storing each start call and each release call of a message set for an application program module. Each call includes information identifying the desired service (e.g., Telephony, e.g., in the header.

In response to a start call (or release call), a message queue forming a channel is assigned (or released) for the exchange of a message set.

Advantageously, each message queue contains at least one input message queue InQ and at least one output message queue OutQ, which are contained in the network interface ACID and are connectable with the application program modules Appl, App2, App3.

Each stored application program module is assigned one output message queue OutQ, so that two or more application program modules can be assigned to one network interface ACID. Of course, there may also be two or more network interfaces ACID, which are then connectable analogously. In that case, it is possible to assign one application program module to two or more network interfaces ACID by simple registration in the API.

The routing of messages to the appropriate destination (ACID, Appl, App2, App3) is achieved by a conventional mapping mechanism, preferably starting from the PC.

Application program modules are registered in the API with a start call. By means of a defined bit field it is determined which incoming messages are to be routed to this application program module. The bit field can be represented as follows: Bit 0 Telephony (3.1 kHz, 7kHz) Bit 1 FAX Group 3 Bit 2 FAX Group 4 Bit 3 Teletex Bit 4 Videotex Bit 5 Packet data Bit 6 Bit-rate adaptation . Reserved for other services.

Thus, corresponding message queues can be readily setup.

With the aid of a release call, an associated message queue can be released.

Because of the modular construction of the API, an integrated services digital network can be adapted by addition or removal of service program modules.

Since, in addition, the service program modules are based on internationally standardised (if possible) procedures which are independent of the actual implementation according to, e.g., national protocol (1TR6, VN2, etc.) in the respective existing (PC) network interface ACID, each application program module can be created completely independently based solely on standardised functions .

ANNEX Telephony: (Voice Call) VC Dial VC Answer VC Terminate 10 VC Alerted VC Connected VC Disconnected VC Engaged VC Incoming Call 15 VC Result VC Conference VC Drop VC Transfer VC Hold 20 VC Reconnect VC Booking VC Camp On VC Divert VC Enquire 25 VC Broker VC Intrusion VC Pickup VC Direct Speech Packet data as specified in X.213 (CCITT): PD = Packet data, QOS - Quality of Service DATA MANAGEMENT PD SET QOS 35 PD GET PARENTS CONNECTION PHASE / RELEASE PHASE PD CONNECT REQ / DISCONNECT REQ PD CONNECT CONF PD CONNECT IND / DISCONNECT IND DATA TRANSFER PHASE PD CONNECT RESP PD DATA REQ PD DATA IND PD DATA ACK REQ PD DATA ACK IND PD EXP DATA REQ PD EXP DATA IND RESET SERVICE PD RESET REG PD RESET CON PD RESET IND PD RESET RESP RESULT MESSAGE PD RESULT Bit-rate adaptation as specified in V.110 (CCITT) Global Type: V110 Modem V110 Dial VI10 Connected V110 Incoming Call VI10 Answer VI10 Terminate VI10 Disconnected V110 Send V110 Receive VI10 Parameter V110 Result Videotex as specified in ETSI: ETS 300079: Basic Videotex Messages VTX Establish VTX Release VTX Data VTX Reset VTX Set Param VTX Read Param XTX Set Read Param VTX TFI VTX TC Error Optional Videotex Messages VTX Channel Open VTX Channel Close VTX Channel Error VTX Begin Application VTX End Application VTX TPD Begin VTX TPD End VTX DFK VTX Escape Global Definition for Videotex Messages VTX ADDR VTX Appl VTX D UUI VTX B CUD VTX Cause VTX X3 Param Fax Group 3/4 corresponding to Packet data as specified in

Claims

CLAIMS :

1. Application program interface (API) providing a connection between a plurality of different application program modules (Appl, App2, App3) and a network interface 5 (ACID) of an integrated services digital network (ISDN), the application program interface (API) containing a service program module (packet data, Telephony, Teletex, FAX Gr 3/4) for each service of the network, each service program module containing a message set representing specified procedures 10 for the individual service, and the application program interface containing means for exchanging the message sets between the application program modules (Appl, App2, App3) and the network interface (ACID).

2. An application program interface (API) as claimed 15 in claim 1, comprising registers for storing each start call and each release call of a message set for an application program module, each call containing information identifying the individual service.

3. An application program interface (API) as claimed 20 in claim 2, wherein for a stored start call, a message queue forming a channel is assigned to an application program module for exchanging a message set, and wherein for a stored release call, said message queue is released.

4. An application program interface (API) as 25 claimed in claim 3, wherein each message queue contains at least one input message queue (InQ) and at least one output message queue (OutQ) which are contained in the network interface (ACID) and are connectable with the application program modules (Appl, App2, App3). 30 5. An application program interface (API) as claimed in any preceding claim, comprising a service program module (Packet data) for procedures for packet data according to CCITT Recommendation X.213. 6. An application program interface (API) as 35 claimed in any preceding claim, comprising a service program module (Bit-rate adaptation) for procedures for bit-rate adaptation according to CCITT Recommendation V.110/V.120. 7. An application program interface (API) as claimed in any preceding claim, comprising a service program module (Telephony) for procedures for telephony according to an ECMA (European Computer Manufacturers' Association)

5. Recommendation.

6. 8. An application program interface (API) as claimed in any preceding claim, comprising a service program module (Teletex) for procedures for teletex according to CCITT Recommendation X.213.

7. 10 9. An application program interface (API) as claimed in any preceding claim, comprising a service program module (FAX) for procedures for fax group 4 according to CCITT Recommendation X.213. 10. An application program interface (API) as 15 claimed in any preceding claim, comprising a service program module (Videotex) for procedures for videotex according to ETSI Recommendation ETS 300079.

8. 11. An application program interface substantially as hereinbefore described with reference to the accompanying 20 drawing.