AU651451B2

AU651451B2 - An application program interface

Info

Publication number: AU651451B2
Application number: AU16391/92A
Authority: AU
Inventors: Frank Bergler
Original assignee: Alcatel NV
Current assignee: Alcatel Lucent NV
Priority date: 1991-05-29
Filing date: 1992-05-18
Publication date: 1994-07-21
Anticipated expiration: 2012-05-18
Also published as: EP0515967A3; NO921996D0; IE921716A1; EP0515967A2; 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

P

i r r i P/00/011 28/5/91 Regulation 3.2 65145 1

AUSTRALIA

Patents Act 1990 t(t.9.

C

C C

ORIGINAL

COMPLETE SPECIFICATION STANDARD PATENT C I.

t t Cc t Invention Title: "AN APPLICATION PROGRAM INTERFACE" The following statement is a full description of this invention, including the best method of performing it known to us:- 2 To be able to connect various application programs of personal computers (PC) with a PC card for an integrated services digital network (ISDN), an application program interface (API) is needed. Such an application program interface is to make it possible to use PC application programs independently of the type and manufacturer of the PC card for the ISDN network ("ISDN Wann geht die Puste aus?", Funkschau, No. 23, 1989, pages 24-31).

A prior art application program interface, the so-called Common ISDN API, ensures that PC application programs 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 ITR6 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 the connection between a plurality of different application program modules and a network interface of an integrated services digital network, the application program interface containing a service program module (packet data, S 25 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 contain- ing means for exchanging the message sets between the application program modules and the network interface.

Unlike conventional application program interfaces, which, since networkoriented, contain only one common message set, one common call connect message, for all services, the modular construction of the application program interface according to the 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.

-me- 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 al- ready defined for the individual services by international standards (CCITT, ETSI, ECMA, etc.) will be specified for the incividual 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 in prior art solutions, no changes are required in the other service program modules of the S application program interface, because an independent service program module is Sprovided for each service.

S 15 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.

An embodiment of the invention will now be explained with reference to the 20 accompanying drawing.

The single figure of the drawing is a block diagram of an application program interface in accordance with the invention.

As shown in the figure, an application program interface in accordance with the invention, API, is connected to a plurality of different application program modules e 25 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, henceforth called "API" for short, 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 CCITT, ETSI, ECMA, etc.), if present, will be used as a basis for each service.

C

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 hereto.

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 Telephony), 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 *9 S 15 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 2 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, 25 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, 7 kHz) 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 SReserved 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, national protocols (1TR6, VN2, etc.) in the respective existing (PC) network in- terface ACID, each application program module jE 15 can be created completely independently based solely on standardised functions.

ii

Y

6

ANNEXURE

Telephony: (Voice Call) VC Dial VC Answer VC Terminate VC Alerted VC Connected VC Disconnected VC Engaged VC Incoming Call VC Result l VC Conference VC Drop S' VC Transfer VC Hold VC Reconnect VC Booking VC Camp On VC Divert VC Enquire t I 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 PD GET PARENTS 'F11

I

7 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 t It 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: VI 10 Modem Dial Connected Incoming Call V 110 Answer Terminate Disconnected VIIO Send V110 Receive Parameter 7 Result Videotex as specified in ETSI: ETS 300079: c r tr

I

I r Basic Videotex Messages VTX Establish VTX Release VTX Data VTX Reset VTX Set Param VTX Read Param VTX 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 X.213.

Claims

1. An application program interface providing the connection between a plurality of different application program modules and a network interface of an integrated services digital network, the application program interface containing a service program module 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 and the network interface, said application program interface further 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, an application program interface, 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.

2. An application program interface as claimed in claim 1 wherein each message queue contains at least one input message queue and at least one output message queue which are contained in the network interface and are connectable with the application program modules. 20 3. An application program interface as claimed in claim 1 or claim 2, comprising a first service program module for procedures for packet data according to CCITT Recommendation X 213.

4. An application program interface as claimed in claim 3, comprising a second service program module for procedures for bit-rate adaptation according to CCITT Recommendation V.110/V.120. An application program interface as claimed in claim 4, comprising a third service program module for procedures for telephony according to a European Computer Manufacturers' Association Recommendation.

6. An application program interface as claimed in claim 5, comprising a fourth service program module for procedures for teletex according to CCITT Recommendation X.213.

7. An application program interface as claimed in claim 6, comprising a fifth service program module for procedures for fax group 4 according to CCITT C C C C C Recommendation X.213.

8. An application program interface as claimed in claim 7, comprising a sixth service program module for procedures for videotex according to ETSI Recommendation ETS 300079.

9. An application program interface, substantially as herein described with reference to the figure of the accompanying drawing. DATED THIS NINETEENTH DAY OF MAY 1994 ALCATEL N.V. 0 *0 i **i0 o e I e ABSTRACT The object is to implement an application program interface for integrated ser- vices digital networks so that application programs can be generated independently of network protocols (Layer 1, 2; ITR6, VN2) and independently of the respective implementation of service features. The application program interface contains for each network service an inde- pendent service program module (Telephony, FAX, Packet data, Teletex, with a message set representing procedures as specified by standards (CCITT, Figure. 1t 1 .1 f K