1.1 Introduction

1.2 About ISDN

1.2.1 About ISDN Protocols and Protocol Layering

1.2.2 About Information Exchange Between Layers

1.2.3 About ISDN Carriers

1.2.4 ISDN Functional Devices and Reference Points

1.3 About the AG ISDN Software

1.3.1 AG ISDN Product Configurations

1.3.2 About the AG ISDN ACU Configuration

1.3.3 About the AG ISDN LAPD Configuration

1.3.4 Reference Points Supported by AG ISDN

1.4 About AG ISDN Software Components

1.4.1 About the Readme File

1.4.2 About the AG ISDN Function Libraries

1.4.3 About ISDN Protocol Stack Downloadable Object Modules

1.4.4 About the AG Configuration File

1.4.5 About the Demonstration Programs

1.5 Other Components

1.5.1 About CT Access

1.6 Developing an AG ISDN Application

The AG ISDN product allows you to create powerful applications that interact with ISDN services in a variety of ways, using CT Access and one or more AG boards.

This chapter:

• Briefly discusses ISDN carriers, protocols and layers.

• Explains how the AG ISDN product provides several interfaces to ISDN services.

• Lists and describes the AG ISDN software components.

• Lists and describes other hardware and software components required in an AG ISDN application.

• Outlines the application development process.

Integrated Services Digital Network (ISDN) is a continually evolving international standard for networking a wide range of services, including voice and non-voice services. The network is completely digital, from one end to the other: voice information is digitized and sent in digital form. Signaling information is sent separately from voice information, using a method called common channel signaling (CCS).

ISDN communications can be described at many levels, from the way bits are transferred from machine to machine to the sets of messages computers pass to one another. A scheme for communication at a certain level is called a protocol.

In the late 1970's, the International Standards Organization (ISO) established the Open Systems Interconnect (OSI) model for communication. ISDN is based on this model. In OSI, seven separate levels, or layers, of communication are defined. The first three layers, called the chained layers, are the lowest levels. The chained layers are:

• The physical layer (layer 1). This is the electrical and mechanical layer. Protocols for this layer describe, on an electrical and mechanical basis, the methods used to transfer bits from one device to another. One protocol used at this layer is CCITT recommendation I.430/I.431.

• The data link layer (layer 2). This is the layer above the physical layer. Protocols for this layer describe methods for error-free communication between devices across the physical link. One protocol used at this layer is CCITT recommendation Q.921, also known as Link Access Procedures on the D Channel (LAPD).

• The network layer (layer 3). This is the layer above the data link layer. Protocols for this layer describe methods for transferring information between computers. They also describe how data is routed within and between networks. One protocol used at this layer is CCITT recommendation Q.931.

Layers higher than these are end-to-end layers. They describe how information is exchanged and delivered end-to-end. They also define process-to-process communication, and describe application-independent user services, user interfaces and applications, etc.

Figure 1. OSI Protocol Layering Model

The functionality provided by a layer includes the services and functions of all of the layers below it. A Service Access Point (SAP) is the point at which a layer provides services to the layer directly above it. With each SAP is associated a unique Service Access Point Identifier (SAPI).

Cooperation between entities on the same layer is governed by a peer-to-peer protocol specific to the layer and the entity. To exchange information between two or more layer entities, a connection must be established between the layer entities using the protocol of the layer directly below. Connections are provided by a layer between two or more SAPs.

Data message units are conveyed between peer-to-peer entities at the lowest layer by means of a physical connection. Layer (n+1) requests services from layer n via primitives. These primitives allow the logical exchange of information and control between two adjacent layers.

Figure 2. Message Primitives Exchanged Between Layers

Four types of primitives are exchanged between adjacent layers:

• REQUEST (RQ), e.g., ACU_CONN_RQ

  A layer issues this type to request a service from the layer directly below it.

• INDICATION (IN), e.g., ACU_CONN_IN

  A layer providing a service issues this primitive type to notify the layer above it of any specific activity that is related to the service. An INDICATION that a layer receives may be the result of an activity performed by the layer directly below it that is related to a REQUEST given by a peer entity.

• RESPONSE (RS), e.g., ACU_CONN_RS

  A layer issues this primitive type to acknowledge the receipt of an INDICATION from a lower layer.

• CONFIRM (CO), e.g., ACU_CONN_CO

  A layer providing a requested service issues this primitive type to confirm that the activity has been completed.

ISDN is transmitted over standard T1 and E1 carriers. T1 and E1 are typically four-wire digital transmission links. T1 is used mainly in the United States, Canada, Hong Kong, and Japan. E1 is used in most of the rest of the world.

Data on a T1 or E1 trunk is transmitted in channels. Each channel carries information digitized at 64000 bits per second (bps). For primary rate ISDN, T1 carries 24 channels. E1 carries 32 channels.

With primary-rate ISDN, the channels are usually used as follows:

• On a T1 trunk, 23 of the 24 channels carry data: voice, audio, data and/or video signals. These channels are called bearer channels (B channels). On an E1 trunk, 30 of the 32 channels are bearer channels.

• On a T1 or E1 trunk, one channel carries signaling information for all B channels. This is called the D channel.

  

  Figure 3. T1 Trunk (Standard Configuration)

In setups with multiple T1 ISDN trunks, a Non-Facility Associated Signaling (NFAS) configuration is often used. In this configuration, the D channel on one of the ISDN trunks carries signaling for all channels on several other trunks. This leaves channel 24 free on each of the other trunks to be used as another B channel. (See Figure 4.)

Figure 4. Sample NFAS Configuration

NFAS configurations are not supported on E1 trunks.

ISDN equipment is classified into a number of categories by international and United States domestic standards¹. Among those categories are the following:

• TE1 - ISDN end-user terminating equipment, class 1, which terminates a single ISDN trunk.

• NT2 - Network terminating equipment, class 2. NT2 equipment can support more than one primary rate trunk, switch channels between different trunks, and take primary synchronization from the T1 or E1 network.

• NT1 - Physically terminates the local loop. In Europe, the NT1 equipment is the network in I.411-compliant installations. In the USA, NT1 is often referred to as the CSU, a separate box on the customer premises.

• LE - Local Exchange equipment.

The interface between each category is called a point:

• The interface between TE1 and NT2 equipment is the S point.

• The interface between NT2 and NT1 equipment is the T point.

• The interface between NT1 and LE equipment is the U point.

Figure 5 illustrates the component categories and associated reference points:

Figure 5. ISDN Service Points and Equipment Classification

Alliance Generation (AG) ISDN protocol software allows you to write CT Access applications that communicate with T1 or E1 trunks to perform voice processing functions and call control using ISDN Common Channel Signaling protocols.

AG ISDN software is designed to use one or more AG digital boards (such as the AG Quad, AG 4000, AG-T1, or AG-E1 boards) as the physical interface to trunk lines. In addition to line interfaces, these boards also feature powerful on-board digital signal processing (DSP) resources that can handle much of the call control and voice processing overhead.

Using AG ISDN software, you can access ISDN services in three ways:

• You can configure the AG ISDN software so an application can perform call control and other operations, using the standard CT Access Natural Call Control API.

  This AG ISDN configuration is called the NCC configuration. For more information about this access method, see the AG ISDN for Natural Call Control Developer's Manual.

• You can access ISDN services at the ACU SAPI. Using the AG ISDN Messaging API, an application can then perform a wide range of Q.931 ISDN D channel functions.

  This AG ISDN configuration is called the ACU configuration. This access method is discussed in this manual.

• You can access ISDN services at the data link layer (Layer 2). Using the AG ISDN Messaging API, an application can then send and receive I-frame data in LAPD messages. This data typically consists of Q.931 messages.

  This AG ISDN configuration is called the LAPD configuration. This access method is discussed in this manual.

Specify the configuration to use when initializing the ISDN protocol stack, as described in Section 4.4.1.

The AG ISDN ACU configuration allows access to Q.931 (layer 3) call control, using the AG ISDN Messaging API. Your application can send and receive switch- and country-invariant D channel messages using this interface. Access at this level allows you direct control over D channel messages and greater control over the contents of these messages.

In this configuration (shown in Figure 6), one or more instances of the AG ISDN protocol stack run on the AG board, one for each D channel. The stack runs in ACU stack mode. In this mode, the protocol stack implements all ISDN layer 2 and layer 3 functionality. The application uses the AG ISDN messaging API to command an entity in the stack called the ACU, which in turn commands the D channel through the lower ISDN layers. Events received by the stack from the D channel are placed in the same event queue as other /CT Access events, allowing the application to access ISDN events in the same way that other events are accessed.

B channel information is routed to the DSP resources through the AG board's MVIP switch. The switch has certain default behavior, described in Section 3.3. Alternatively, the switch can be controlled using the CT Access Switching service.

Figure 6. AG ISDN Application Architecture (ACU Configuration)

Access at the data link layer is useful if an application must support a private data link protocol, or if the user wishes to create a complete Q.931 protocol at the application level. At this level, the messages sent and received by the application constitute LAPD frames.

The AG ISDN protocol stack runs in LAPD stack mode, as shown in Figure 7. In this mode, the protocol stack implements ISDN layer 2 functionality. No ACU is present. Instead, the application uses the AG ISDN Messaging API to send LAPD frames directly to the data link layer (layer 2).

Events coming from the data link layer are placed in the same event queue as other CT Access events, allowing the user to access ISDN events in the same way that other events are accessed.

As in other configurations, B channel information is routed to the DSP resources through the AG board's MVIP switch. The switch has certain default behavior, described in Section 3.3. Alternatively, the switch can be controlled using the CT Access Switching service.

Figure 7. AG ISDN Application Architecture (LAPD Configuration)

As depicted with the solid arrows at the upper left of Figure 8, the AG ISDN product supports access across the S and the T reference points. At the ACU SAP, access to S/T is transparent.

In addition, the user can configure an ISDN protocol stack to emulate the network, using the partner_equip field passed to isdnStartProtocol. See Chapter 7 for more details on the parameters available to configure the ISDN protocol stack.

Figure 8. Reference Points Supported by AG ISDN

ISDN is implemented differently around the world. For this reason, NMS provides several versions of its AG ISDN software for different regions. The package for a region contains the software modules you need to allow an AG board to communicate on a T1 or E1 trunk in one or more countries in that region.

The ISDN software package for a given region contains the following:

• A readme file.

• An AG ISDN function library for CT Access.

• Downloadable object modules containing the AG ISDN protocol stack software.

• Sample AG configuration files.

• Header files.

• Demonstration programs, with their source code files and makefiles.

The sections that follow briefly describe each of these components.

Other components, also included, are only used when the AG ISDN protocol stack is running in NCC stack mode. For more information about this mode, see the AG ISDN for Natural Call Control Developer's Manual.

The NCC configuration-specific components are:

• A Trunk Control Program (TCP).

• Several parameter files (.pf files). Each file contains the complete set of AG ISDN parameters. Certain parameters in these files are set to values specific to a certain country or region.

• An adiisd.par file, containing the subset of AG ISDN parameters which can be changed without risking violation of approvals.

This ASCII text file contains release information that does not appear in other documentation. The file is named readme_isdn.txt. Consult this file to learn where the AG ISDN software components are located after installation.

This component runs on the host PC. It is used by the application program to interact with the ISDN protocol stacks running on the AG board.

The library is supplied as an extension to the ADI library. It is a dynamic-link library (DLL) under Windows NT, and it is a shared object under UNIX. The library has different names under different operating systems:

Operating System	CT Access Lib Name
Windows NT	adiisdn.lib and adiisdn.dll
UNIX	libadiisdn.so

Standard AG ISDN header files are also supplied. These are required by your applications to communicate with the ISDN protocol stack on the board.

The following figure describes the include file structure used by an application using AG ISDN in the ACU configuration:

Figure 9. Header File Usage (ACU Configuration)

The following figure describes the include file structure used by an application using AG ISDN in the LAPD configuration:

Figure 10. Header File Usage (LAPD Configuration)

A downloadable object module file contains the basic low-level software which an AG board requires to support ISDN. The module is transferred from the host into on-board memory by the agmon utility when the board boots.

Different module files are supplied for different configurations. The file you use depends upon what board type you are using. For more information about downloadable object modules, see the AG ISDN Installation Manual.

The AG configuration file contains information which agmon reads to determine how to set up your boards for use. This file also contains country-specific information, and defines what trunks are assigned to which D-channels.

Several example files are included, describing ISDN configurations for different boards or regions. You can use these files to create a file describing your hardware and software setup. For details, see the AG ISDN Installation Manual and AG Runtime Configuration and Developer's Manual.

The following demonstration programs are included, with their source code files and makefiles:

Program	Description
isdndemo	Simple call control application that communicates with the ISDN stack in the ACU configuration.
lapddemo	Illustrates establishing a LAPD data link on an ISDN trunk.

For details on these programs, see Chapter 9.

In addition to the AG ISDN software, you will need the following components to build an ISDN protocol application:

• One or more Alliance Generation T1 or E1 trunk interface boards².

• CT Access version 2.1 or later.

• agmon - the AG board loading and monitoring program. This utility is supplied with AG boards and with CT Access.

  WARNING:

  Natural MicroSystems obtains board-level approvals certificates for supported countries. Some countries require that you obtain system-level approvals before connecting a system to the public network. To learn what approvals you require, contact the appropriate regulatory authority in the target country.

CT Access is a complete development environment for telephony applications. It provides a standard set of telephony functions grouped into logical services, each of which has a standard API. CT Access provides functions for telephony-related tasks such as call control, tone and DTMF tone generation and detection, and voice playing and recording.

CT Access includes a service which controls switching on MVIP-compliant devices. You can use this service to make or break connections, send patterns, sample data, etc. This service supports both MVIP-95 and MVIP-90 specifications. Alternatively, you can use the swish standalone utility to control switching interactively or in a batch mode.

For general information about installing and using CT Access, see the CT Access documentation.

To create an AG ISDN application:

Step	Where Step Is Documented
1. Install AG digital drunk interface boards in a system, and any other boards you will need in your application.	The installation manuals for your AG boards
2. Install CT Access.	CT Access Installation Manual
3. Install the AG ISDN software for each country or region that your application will be used in.	AG ISDN Installation Manual
4. Edit your AG configuration file so it describes all boards in your system.	The AG ISDN Installation Manual, the installation manuals for your AG boards, and the AG Runtime Configuration and Developer's Manual
5. Test your hardware installation.	The installation manuals for your AG boards
6. Write your application.	This manual, and the CT Access documentation set

² AG-T1 and AG-E1 boards only support AG ISDN if they are revision D-1 and later. If your AG-T1 or AG-E1 board was purchased prior to June 1996, you may need a hardware upgrade. For more information, contact NMS Developer Support.