The general intention in this set of Questions and Answers is to show how an ISDN application can be programmed to exploit the full range of features which are supported by the ISDN. An example of such a feature is Calling Line ID.

The specific case addressed in the following Q & A session is one which describes the establishment of a call over the D channel by means of the layer 3 signalling protocol Q931. The process concludes with the selection of the B channel protocol which is required to support the application over the ISDN connection after the call has been established.

The importance of the call establishment case is that it shows how different applications require specific Bearer Services and how this support is negotiated over the D channel. In this regard the importance of the Bearer Channel Capability Information Element (BCC IE) is emphasised and fully described. The BBC IE is associated with the Additional Information Element Field which forms part of the Layer 3 Protocol, Q931, (see Q931 messages formats). This Information Element (IE) contains the Bearer Services required by the application. Various coding examples of this IE are shown in the Tables 1, 2, 3, 4, 5, 6, 7, 8, 9 to demonstrate how different bearer capabilities are catered for.

The relationship between the programming of an ISDN Application and the Layer 3 IE code is discussed in the following way. The actual value of the Layer 3 IE code required is determined by the Application and forms part of the messaging information between the Application and the API employed. It is then communicated to layer 3 so that the appropriate layer 3 message will include this information.

Some APIs use coded messages to communicate with the application with a format which is similar to the coding format employed for the IE part used in layer 3 messages.

In these cases the programmability of applications which communicate with these APIs can be extended as required by following the comprehensive coding rules for layer 3 as described for this layer in the CCITT Blue Book. In this way standard coding rules can be applied to the programming of applications whenever extended network functionality is required in the application. The extended functionality of the application is supported by all ISDN hardware systems that support this particular API.

This approach can be extended beyond the BCC IE.

It may be employed by the software which is used for application development to extend and modify applications by directly employing CCITT Blue Book coding for the many IEs which can be used in the Additional Information field to augment the messages used by the Layer 3 protocol. These are the messages which control ISDN calls. In this way Calling Line ID, for example, may be used in applications behind a PABX to monitor what calls should be allowed or barred (see How is Calling Party Number used for Controlling Calls made via an ISDN PABX ?). The relevant coding for the software is readily available from the CCITT Blue Book.

This convenience is enhanced by the apparent transparency of the API to Application Messages when the coding employed by the API is similar to that employed in layer 3 messages. This type of API, such as CAPI, provides a powerful environment for the development of sophisticated applications. It can be readily exploited to cater for the complete range of network features and services supported by the ISDN. (See the Role of APIs in ISDN).

The subsequent steps described below in the call setup procedure are concluded by showing how the application communicates with the signalling protocol by telling the incoming call what protocols should be implemented over the B channel. This is implemented by communication between the application, the API and Layer 3 at both the originating and terminating ends. In this regard note that there must be consistency between the B channel protocols selected for the different layers. The relationship between CAPI messages and layer 3 messages is shown in Figure 1. The terminating end is in an appropriate waiting or listening state so that it is ready to deal with incoming calls by being adequately equipped to check its capability to provide the necessary bearer service support for the call. The relevant bearer services required by the application is contained in the BCC IE Information Element of the layer 3 Setup message of the incoming call.

The match of an incoming call to a listening application is a function of subaddressing or DDI as well as BCC IE and High Layer (HL) and Low Layer Compatibility (LLC) IE compatibility.

Alternatively, the TEI part of the Address Field in Layer 2, LAPD protocol may be used to identify the Terminal Equipment(s), TEs, addressed by the incoming call (with the Called Number IE of the layer three Setup message). This procedure, employs Logical Terminal Profiles, to map the Called Subscriber Number with the corresponding layer 2 address information used by LAPD to communicate with its TEs in the customer's premises. The mapping may indicate that there is one TE, which is referred to as a point to point connection, or more than one TE (point to multipoint) to communicate with.

(All interlayer communication is implemented by means of primitives and these will be dealt with in detail in a forthcoming paper.)