NIST Special Publication 500-195

Computer

Systems

Technology

U.S. DEPARTMENT OF

COMMERCE

National Institute of Standards and

Technology

Nisr

NAT L INST. OF STAND & TECH R.I.C.

A ill 03 733751

NIST

PUBLICATIONS

North American ISDN Users' Forum

Agreements on

Integrated Services Digital Network

QC

100

.U57

500-195

1991

C.2

NIST Special Publication 500-195

. 2

North American ISDN Users' Forum

Agreements on

Integrated Services Digital Network

Based on work performed by the

North American ISDN Users' Forum

Shukri A. Wakid and Kathleen M. Roberts, Editors

Advanced Systems Division

Computer Systems Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899

September 1991

U.S. DEPARTMENT OF COMMERCE

Robert A. Mosbacher, Secretary

NATIONAL INSTITUTE OF STANDARDS

AND TECHNOLOGY

John W. Lyons, Director
Reports on Computer Systems Technology

The National Institute of Standards and Technology (NIST) has a unique responsibility for computer

systems technology within the Federal government. NIST's Computer Systems Laboratory (CSL) develops standards and guidelines, provides technical assistance, and conducts research for computers and

related telecommunications systems to achieve more effective utilization of Federal information technology resources. CSL's responsibilities include development of technical, management, physical, and administrative standards and guidelines for the cost-effective security and privacy of sensitive unclassified

information processed in Federal computers. CSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 500 series reports CSL re- search and guidelines to Federal agencies as well as to organizations in industry, government, and

academia.

National Institute of Standards and Technology Special Publication 500-195

Natl. Inst. Stand. Technol. Spec. Publ. 500-195, 150 pages (Sept. 1991)

CODEN: NSPUE2

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1991

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
North American ISDN Users' Forum

Agreements on ISDN

ABSTRACT

This document compiles the existing NIU-Forum agreements for an ISDN developed and approved in the NIUForum as of November 1990. These agreements cover: Layer 1 BRI at the U, and S/T reference points; Layer

1 PRI at the U reference point; Layer 2 BRI and PRI; Layer 3 BRI Basic Call Control for Class I equipment;

Layer 3 PRI Basic Call Control for Class II equipment; and Generic Control procedures for Class I BRI

Supplementary Services. In addition, this document references the Conformance tests which have been

completed by the NIU-Forum. These include: Layer 1 BRI S/T interface; and Layer 2 BRI LAPD. Finally, this document contains the Application Profile for four of the Incoming Call Management applications which have

been submitted to the NIU-Forum.

KEYWORDS

application profile; basic call control; basic rate interface; conformance test; customer premises equipment; data

link layer; implementation agreements; ISDN; LAPD; network layer; network termination; NIU-Forum; physical

layer; primary rate interface; S/T interface; terminal adaptor; terminal equipment; U Interface.

iii
NOTICE OF DISCLAIMER

These agreements were developed and approved by organizations participating in the North

American ISDN Users' Forum (NIU-Forum) meetings as of November 1990. In the February 1991

meeting, participants tn the Plenary agreed to publish all agreements approved as of November

1990. The National Institute Of Standards And Technology (NIST) makes no representation or

warranty, express or implied with respect to the sufficiency, accuracy, or use of any information

OR OPrNION contained herein. The use of this information or opinion is at the risk of the user. Under no ctrcumstances shall NIST be liable for any damage or injury incurred by any person

arising out of the sufficiency, accuracy, or use of any information or opinion contained herein.

iv
ACKNOWLEDGMENTS

NIST would like to acknowledge all of the members and participants, past and present, in the North American

ISDN Users' Forum for their valuable contributions to this document.

WORKSHOP AND WORKING GROUP CHAIRS

IUW Chair IIW Chair

Claude Stone Don Auble

First Nat'l Bank of Chicago

Ameritech Services

IUW INDUSTRY GROUPS

Computer and Telecommunications

Financial/Services Government Services Manufacturing

Small Business

Rick Zipes

Martin Risbergs James Johnson

Karl Schohl George Abbott

Mitel American Airlines U.S. Air Force GM

North Carolina State University

IUW AD HOC COMMITTEES

Applications Review

Public Policy and Strategic Planning

EDI

Broadband ISDN

Scott Beale David Norem

Claude Stone Bob Doxey

Aeronautical Radio, Inc.

First Nat'l Bank of Chicago

Pacific Bell IUW APPLICATION FAMILIES

Network Management/ISDN

Aclministration Call Management

CPE Compatibilities and Capabilities

Network Interconnectivity

Messaging and Answering

Issues

Hiawatha Cotton

Scott Beale

Pat Krause Rick Zipes Karen Patten Karen Patten

Bill Selmeier

U.S. Air Force

Aeronautical Radio, Inc. McDonald's Corporation

Mitel AT&T Bell Labs

AT&T Bell Labs

Dowty Network Systems, Inc. UW EXPERT GROUPS

Applications Analysis

Applications Software Interface ISDN Conformance Testing

Network Management

ISDN Security

Satellite, Radio, and Mobile

Signalling

Supplementary Services

Bob Sherry

Cheng Chen

Matt Martini Tom Russotto Jonathan Katz

John Kennedy

John Kantonides

Chris Wallace

AT&T Bell Labs

Teleos Communications

NYNEX

American Computer

TASC

Northern Telecom Canada Ltd. AT&T Bell Labs

Bell Northern Research

IIW PROFILE TEAMS

Call Management

CPE Compatibilities and Capabilities

Messaging and Answering

Network Interconnectivity

Network Management/ISDN

Administration

Security

George Gawrys

Bob Larribeau Glenn Ehley

Ira Clark Tom Russotto

William Few

AT&T

Fujitsu

Siemens Stromberg-Carlson

DGM&S

American Computer

DoD

UW AD HOC COMMITTEES

Versions Gerry Hopkins Bell Atlantic

EXECUTIVE STEERING COMMITTEE STANDING GROUPS

Applications Services Group

Finance Committee

Matt Thomson

James Kendrick

Northern Telecom

Aeronautical Radio, Inc.

v

TABLE OF CONTENTS

ABSTRACT iii

NOTICE OF DISCLAIMER iv ACKNOWLEDGMENTS v

1 Introduction 1-1

1.1 Purpose of this Document 1-1

1.2 Evolution of this Document 1-1

1.3 Document Organization 1-1 1.4 NIU-Forum Overview 1-2

1.4.1 Purpose of the Forum 1-2

1.4.2 NIU-Forum/NIST Relationship 1-2

1.4.3 NIU-Forum Organization and Procedures 1-3

1.4.3.1 ISDN Users' Workshop (IUW) 1-3 1.4.3.2 ISDN Implementors' Workshop (IIW) 1-4

1.4.4 ISDN Versions 1-4

1.5 Point of Contact 1-4

2 Future ISDN Versions 2-1

3 Implementation Configurations 3-1

4 Implementation Agreements 4-1

4.1 ISDN Lower Layer Specifications 4-1

4.1.1 Layer 1 Basic Rate Interface (BRI) 4-1

4.1.1.1 U Reference Point 4-1

4.1.1.2 S and T Reference Points 4-1

4.1.2 Layer 1 Primary Rate Interface (PRI) 4-1

4.1.2.1 U Reference Point 4-2

4.1.2.2 Future S and T Reference Points 4-3

4.1.3 Layer 2 BRI and PRI 4-3

4.1.4 Layer 3 BRI and PRI 4-3

4.1.4.1 Circuit-Switched Call Control Procedures 4-3

4.1.4.1.1 Basic Call Control Procedures 4-3

4.1.4.1.2 Supplementary Services Control Procedures 4-4

4.1.4.2 Packet-Switched Call Control Procedures 4-5

4.2 Future Basic Bearer Services Specification 4-6

4.2.1 Future Minimal Set of BRI Services 4-6

4.2.2 Future Minimal Set of PRI Services 4-6

4.3 Future Supplementary Services Specification 4-6

4.4 ISDN Terminal Adaptation Specification 4-7

4.4.1 Future Circuit-Mode Data Terminal Adaptation 4-7

4.4.2 Packet-Mode Data Terminal Adaptation 4-7

4.5 ISDN Management Specification 4-7

4.5.1 Future Layer 1 BRI 4-7

4.5.2 Future Layer 1 PRI 4-7

4.5.3 Future Layer 2 and 3, BRI and PRI 4-8

4.6 Future Common Channel Signalling — Signalling System #7 4-8

5 ISDN Conformance Test Specifications 5-1

5.1 Layer 1 BRI 5-1 5.2 Future Layer 1 PRI 5-1

5.3 Layer 2 BRI 5-1 5.4 Future Layer 2 PRI 5-2

5.5 Future Layer 3 5-2

vii
6 Future Application Software Interface (ASI)

7 Application Profiles 7-1

7.1 NIU-Forum Application Profiles 7-1

7.1.1 Application Profile Conformance 7-1

7.2 Application Profile Families 7-1

7.2.1 ISDN Call Management 7-1

7.2.1.1 Abstract 7-2

7.2.1.2 User Description 7-2

7.2.1.3 ISDN Application Breakdown 7-2

7.2.1.3.1 Service Logic 7-4

7.2.1.4 Call Transfer with Associated Data Service Element 7-4

7.2.1.4.1 User Environment 7-8

7.2.1.4.2 Alternative Architectures 7-8

7.2.1.4.3 Information Flow 7-8

7.2.1.4.4 Network Signalling Requirements — Protocol Identification 7-11

7.2.1.4.5 Protocol Description 7-11

7.2.1.5 Call Delivery with Associated Data Service Element 7-14

7.2.1.5.1 User Environment 7-14

7.2.1.5.2 Alternative Architectures 7-16

7.2.1.5.3 Information Flow 7-16

7.2.1.5.4 Network Signalling Requirements — Protocol Identification 7-19

7.2.1.5.5 Protocol Description 7-19

7.2.1.6 Call Back on Busy/Abandonment Service Element 7-21

7.2.1.6.1 User Environment 7-21

7.2.1.6.2 Architecture 7-21

7.2.1.6.3 Information Flow 7-23

7.2.1.6.4 Network Signalling Requirements 7-23

7.2.1.6.5 Protocol Description 7-23

7.2.1.7 Terminal Connectivity Service Element 7-26

7.2.1.7.1 User Environment 7-26

7.2.1.7.2 Information Flow 7-26

7.2.1.7.3 Network Protocol Requirements 7-28

7.2.1.7.4 Protocol Description 7-28

7.2.1.8 Protocol Summary and Status 7-29

7.2.2 Future ISDN CPE Compatibility/Capability 7-30

7.2.3 Future ISDN Network Interconnectivity 7-30

7.2.4 Future Messaging and Answering 7-30

7.2.5 Future Bandwidth Negotiation 7-30

7.2.6 Future Network Management/ISDN Administration 7-30

8 References 8-1

Appendix A. NIU 90-301 Implementation Agreement of the North American ISDN Users' Forum for Layer 3

Signalling Specification for the Minimal Set of Circuit-Switched Bearer Services for the ISDN Basic Rate

Interface/Class I A-l

A.1 Abstract A-l

A.2 Introduction A-2

A.3 NIU 90-301 Delta List A-2

Appendix B. NIU 90-302 Implementation Agreement of the North American ISDN Users' Forum for Layer 3

Signalling Specification for the Minimal Set of Circuit-Switched Bearer Services for the ISDN Primary

Rate Interface/Class H B-l

B. l Abstract B-l B.2 Introduction B-2

B.3 NIU 90-302 Delta List B-2

viii
1 Introduction

The purpose of the ISDN Agreements document, its organization and an overview of the North

American ISDN Users' Forum (NIU-Forum) are described in the following subsections.

1.1 Purpose of this Document

Participants in the February 1991 NIU-Forum Plenary meeting, approved a motion to publish all agreements reached among the members as of November 1990. This document is a compilation

of these NIU-Forum agreements for an ISDN.

1.2 Evolution of this Document

New versions of this document will be issued as progress is made in developing and approving

implementation agreements, conformance tests, and application profdes within the NIU-Forum.

It is the intent of the NIU-Forum, that each new version be compatible with previous versions. Therefore, each revision will supersede preceding versions, as each new version wdl include all of the unchanged agreements from previous versions, as well as errata pages for previously

approved agreements.

1.3 Document Organization

The ISDN Agreements document is organized into specific sections as follows:

• Section 1 Introduction — The purpose of this document, the document organization, and an overview of the structure and organization of the NIU-Forum.

• Section 2

ISDN Versions — A specific interoperable subset of an ISDN which functions in a multi- vendor environment.

• Section 3 Implementation Configurations — A categorization of the ISDN capabdities, based upon

access and equipment class information.

• Section 4

Implementation Agreements — The Implementation Agreements (IAs) are developed by

both implementor and user representatives participating in the NIU-Forum Expert Working

Groups. The IAs provided in this section allow for expeditious development of ISDN

capabilities, and promote interoperability of ISDN communications equipments.

• Section 5 ISDN Conformance Test Specifications — Conformance Test (CT) suites for an ISDN

are detailed in this section of the agreements.

• Section 6

Application Software Interface — The Application Software Interface (ASI) section will focus on the definition of a common application interface for accessing and administering

ISDN services provided by Network Adapters.

NIU-Forum Agreements On ISDN l-l
• Section 7

Application Profiles — The Application Profiles (APs) contain the recommended set of

agreements and specifications for all layers and aspects of ISDN communication which

must be present to support a particular users' application or set of applications (application

family).

• Section 8

References — The References section provides a listing of documents identified but not included in this publication.

1,4 NIU-Forum Overview

The following text introduces the NIU-Forum purpose and organization.

1.4.1 Purpose of the Forum

The Integrated Services Digital Network (ISDN) is defined in a group of international recommendations for a worldwide communications network for the exchange of all information

(voice, data, and image) among all users, independent of any manufacturer, service provider, or implementation technology.

ISDN recommendations are being developed by the International Telephone and Telegraph

Consultative Committee (CCITT). In North America, the ISDN standards are being developed by

Committee Tl, which is accredited by the American National Standards Institute (ANSI) and

sponsored by the Exchange Carriers Standards Association (ECSA).

The result is one extensive standard with a tremendous variety of options and parameters. This

is necessary to meet all the possible needs and technologies for which the standards could be used. However, to ensure interoperability and terminal portability within the ISDN network and its attendant terminals and other Customer Premises Equipment (CPE), a uniform subset of these options and parameters must be selected. Each application usually only requires a subset of

functionality and in order for products to work together in a multi-vendor environment, common

sets of options must be selected.

To cope with this proliferation of choices and to provide practical products and services which

meet users' needs, the specification process must be extended to include Application Profiles,

Implementation Agreements, and Conformance tests to promote interoperability.

1.4.2 NIU-Forum/NIST Relationship

The North American ISDN Users' Forum has created a user voice in the implementation of ISDN

and ISDN applications and has helped to ensure that the emerging ISDN environment meets users' application needs. The NIU-Forum is sponsored by the National Institute of Standards and

Technology (NIST). The precise relationship of the NIU-Forum, NIST, and other business concerns is defined by the "Cooperative Research and Development Agreement: The Consortium on ISDN Based Systems." 1

1-2

i For more information, contact the NIU-Forum Administrator (see sec. 1.5). NIU-Forum Agreements on ISDN
1.4.3 NIU-Forum Organization and Procedures

The actual work of the NIU-Forum is accomplished in two workshops; the ISDN Users' Workshop

(IUW) and the ISDN Implementors' Workshop (IIW). These workshops, which consist of various

working groups and special project teams, meet several times a year and develop the following

products: Application Requirements, Application Analyses, Application Profiles, Implementation

Agreements, Conformance Criteria, and an Applications Software Interface. The IUW produces

Application Requirements which describe potential applications of ISDN and the features which

may be required.

The HW develops Application Analyses, Application Profiles, Implementation Agreements,

Conformance Criteria, and an Applications Software Interface which provide the technical detail necessary to implement an Application Requirement in an interoperable manner.

The activities within the two workshops are coordinated by the NIU-Forum Executive Steering

Committee. While specifics of the NIU-Forum organization follow, particulars relating to the procedures for the NIU-Forum are found in the "North American ISDN Users' Forum Practices Manual."2

1.4.3.1 ISDN Users' Workshop (IUW)

The IUW is responsible for identifying, defining, and prioritizing user requirements, as well as working with the HW to define and approve agreements necessary to support the implementation

of user requirements. Membership in the IUW is open to any organization. Users participating

in the IUW are organized into seven Industry Groups: Manufacturing Industries, Process

Industries, Service Industries, Small Business, Financial Services, Government, and Computing and

Telecommunications Industries. The IUW organization emphasizes the synergy present when

organizations from the same industry segment work together to define applications. Activities within the IUW are coordinated by the IUW Steering Committee.

The IUW work program is based on identifying potential user applications and structuring the IIW

work to satisfy the user applications. Any user can request consideration for a particular ISDN

application. The request should be for an application which could be used to support business

related operations. It is important that ISDN solutions to business problems be based on business

considerations which include:

• cost reductions

• productivity enhancements

• standard application interfaces

• and performance improvements.

For a detailed description of the "User Application" Processing within the ISDN Users' Workshop,

please refer to section 1.3.4.2 of the North American ISDN Users' Forum (NIU-Forum) Working

Agreements for the Integrated Services Digital Network (ISDN) — Publication 1, (Ref. [32]).

2 For more information, please contact the NIU-Forum Administrator (see sec. 1.5). NIU-Forum Agreements On ISDN 1-3
1.4.3.2 ISDN Implementors' Workshop (HW)

The IIW is responsible for developing Application Analyses, Application Profiles, Implementation

Agreements, Conformance Criteria, and an Applications Software Interface in support of IUW

defined Application Requirements. The IIW also provides technical advice and consultation to the IUW, sponsors multi-vendor demonstrations and trials, and provides formal liaisons with

appropriate organizations such as the Corporation for Open Systems (COS), the Open Systems

Interconnection (OSI) Implementors' Workshop (OIW), or the ANSI Accredited Standards

Committee Tl. Membership in the IIW is open to any organization.

The IIW Steering Committee is responsible for coordinating the activities of the IIW groups. The

IIW is organized into the following groups:

• Applications Analysis Working Group (WG)

» Application Profile Teams

• Expert WGs

• ISDN Conformance Test (ICOT) WG.

The Applications Analysis WG develops an analysis of the user's application requirements, which

serves as a basis for development of the Application Profile by the Applications Profile Teams.

The Expert WGs produce the Implementation Agreements that are generally based on ANSI

standards. In addition, there is an Expert WG defining an Applications Software Interface. The

ICOT WG defines conformance requirements and develops abstract test suites for Implementation

Agreements and Application Profiles.

1.4.4 ISDN Versions

A version defines and specifies ISDN as it exists at a certain point in time as derived from existing national and international standards and other consensus activities. Each version should be

completely compatible with earlier versions. Manufacturers and service providers would be

expected to develop ISDN offerings based on a particular version.

1.5 Point of Contact

Further information about the NIU-Forum can be obtained by contacting:

NIU-Forum Secretariat National Institute of Standards and Technology

Building 223, Room B364

Gaithersburg, Maryland 20899

(301) 975-2937

For information regarding specific groups or activities within the NIU-Forum please refer to the appropriate representative listed in Attachment 2 of section 1 in the North American ISDN Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network (ISDN) —

Publication 1, (Ref. [32]), which lists the chairs, vice chairs, secretariats, and emeriti members of

the NIU-Forum Executive Steering Committee (ESC), IIW, and IUW.

NIU-Forum Agreements on ISDN
2 Future ISDN Versions

Editor's Note: This section is reserved for future agreements regarding the definition and

specification of ISDN Versions. Refer to section 2.0 of the North American ISDN Users' Forum

(NIU-Forumj Working Agreements for the Integrated Services Digital Network (ISDN) —

Publication 1, (Ref. [32]), for information regarding the current status of this work within the NIUForum.

NIU-Forum Agreements On ISDN 2-1

3 Implementation Configurations

The ISDN architecture is intended to interconnect all user and network equipments, in a ubiquitous

fashion, to provide a common network encompassing all possible communication scenarios. Because of this broad scope, the national standards for the ISDN could not be universally applied

to all the conceivable combinations of equipment types, access arrangements and applications. The

concept of implementation configurations is introduced to allow specific ISDN capabilities

(procedures) to be associated with a class of equipment, an access arrangement, or an application.

The use of the equipment class/access arrangement terminology permits clarification of the circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capability

applies only to a subset of four possible configurations.

The implementation configurations, which were defined by the NIU-Forum Signalling Working

Group (SWG), have been applied to the Layer 3 circuit-switched signalling protocols only. Future work will evaluate the implementation configuration concept for applicability to all agreements

emerging from the NIU-Forum.

The following text provides the current description of implementation configurations from the SWG:

The concept of equipment classes is introduced in this document to permit certain procedures to be associated with a particular application or class of equipment, e.g., station equipment versus

(Private Branch Exchange (PBX). Specifically, two classes of equipment are defined on the basis of two fundamental attributes.

The first attribute relates to the possibility of an exchange of signals occurring beyond the public

network's point of contact with the interface (i.e., between the equipment directly connected to the public network and ISDN terminals or telephones connected to that equipment). For example, some user equipment may support subtending Basic Access digital subscriber loops and/or analog

telephone loops. For Class I equipment, the network makes no provision for such an arrangement

and assumes the Class I equipment constitutes the endpoint of the communication. Conversely,

in the case of Class II equipment, the procedures at the network take into account that communication between Class II equipment (with which it communicates directly) and other equipment (with which the network does not have direct contact) may occur. As an example, Class

II equipment may support digital and/or analog subscriber loops. Use of Class II equipment also involves the possibility of having interworking occur beyond the equipment with which the network

has direct contact. Therefore, it is reasonable for Class II equipment to provide the network with an interworking notification, for both outgoing and incoming calls, when either the calling or called party respectively, is a non-ISDN user. Class II equipment may also send an interworking

notification, if a private network exists beyond the Class n equipment and interworking to a non- ISDN facility within that network takes place. When an interface is associated with Class I equipment, it is assumed that multiple pieces of equipment may exist and communicate with the network over the D-channel. However, in this case, all equipment is assumed to be ISDN-capable

and is considered as the endpoint of the communication. Therefore, interworking notification should not be accepted from Class I equipment.

The second attribute relates to the manner in which a SETUP message, the message which initiates an ISDN call, should be presented to the user equipment. When Class I equipment is applied on

NIU-Forum Agreements On ISDN 3-1
a particular interface, the network should broadcast the SETUP message associated with each call that terminates on that interface, since interaction between the network and multiple pieces of user equipment should be supported. On the other hand, the network should not broadcast SETUP

messages associated with terminating calls to an interface on which Class II equipment is being

used. Here, a single piece of user equipment is assumed to be involved in all communication with

the network.

To the extent possible, it is desirable to have one set of requirements for ISDN call control apply

to all ISDN user configurations. However, in cases for which integrated procedures are not

appropriate, the call control procedures associated with Equipment Class I will differ from those

associated with Equipment Class II. Unless otherwise noted, the assumption should be that a

particular procedure/capability should be provided for both classes of equipment on both basic and

primary rate access. However, use of the equipment class terminology permits clarification of the circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capability

applies only to a subset of four possible configurations which are labeled as follows.

Table 3-1. Implementation Configurations

Class I Class n

BRI

PRI

IB IIB

IP IIP

In other words, a capability that applies to Class I equipment may be provided on basic access

interfaces (IB) and/or primary rate access interfaces (IP). Similarly, a capability that applies to Class II equipment may be provided on basic access interfaces (IIB) and/or primary rate access

interfaces (IIP).

The notation shown in the table above is used within this implementation agreement to indicate when protocol or procedures are only expected to be supported for a particular class and/or are limited to a particular type of interface, i.e., basic or primary rate interface.

NIU-Forum Agreements on ISDN
4 Implementation Agreements

The Implementation Agreements (IAs) generated by the NIU-Forum IIW provide the agreements

for implementing the American National Standard (ANS) specifications for an ISDN. These IAs were developed and approved by both industry and user representatives participating in the Expert

Working Groups, as well as the NTU-Forum Plenary. The IAs exist to expedite the development

of ISDN capabilities, to promote interoperability of ISDN communications equipments, and to provide a universal, multi-vendor implementation. The following text details the IAs.

3

4.1 ISDN Lower Layer Specifications

The ISDN lower layer specifications define the Layer 1, 2, and 3 requirements of an ISDN.

Network signalling, via the D-channel, is the focus of these agreements but, where appropriate, user data specifications of Layers 1, 2, and 3 have been included. These IAs were developed in the Signalling Expert Working Group (SWG) of the IIW. These IAs provide a framework and a

set of protocol procedures for accessing an ISDN so that systems implemented according to these agreements can successfully intemperate. The following text details the ISDN lower layer IAs.

4.1.1 Layer 1 Basic Rate Interface (BRI)

The ISDN Basic Rate Interface (BRI) physical layer specifications are defined for their specific reference point of application. These reference points are S, T and U, providing the user and

network interfaces for Terminal Equipment (TE) and Network Termination (NT) equipments. The

following IAs are defined for the BRI physical layer.

4.1.1.1 U Reference Point

The IA (NIU 89-101) for the U reference point states: the physical layer of the Basic Access

Interface at the U reference point is specified in ANS Tl.601-1988, Integrated Services Digital

Network —Basic Access Interface for Use on Metallic Loopsfor Application on the Network Side

of the NT —Layer 1 Specification, (Ref. [12]).

The IA has adopted the ANS Tl.601-1988 (Ref. [12]) standard without exception.

4.1.1.2 S and T Reference Points

The IA (NIU 89-105) for the S/T reference point states: the physical layer of the Basic Access

Interface at the S and T reference points is specified in ANS T1.605- 1989, Integrated Services

Digital Network —Basic Access Interface at S and T Reference Points —Layer 1 Specification,

(Ref. [16]).

The IA has adopted the ANS Tl.605-1989 (Ref. [16]) standard without exception.

4.1.2 Layer 1 Primary Rate Interface (PRI)

The ISDN Primary Rate Interface (PRI) physical layer specifications are defined for their specific reference point of application. These reference points are the S, T and U, providing the user and

The NTU-Forum Plenary document numbers (e.g., NIU 89-101) are included for reference purposes

only, as every numbered implementation agreement is included in the present document in its entirety.

NIU-Forum Agreements On ISDN 4-1
network interfaces for TE and NT equipments. The following IAs are defined for the PRI physical

layer.

4.1.2.1 U Reference Point

The IA (NTU 89-103) for the U reference point states: the physical layer of the Primary Access

Interface is governed by ANS Tl.403- 1989, Carrier to Customer Installation — DS1 Metallic

Interface, (Ref. [10]), and CCITT Recommendation 1.431-1988, Primary Rate User — Network

Interface —Layer 1 Specification, (Ref. [24]).

The following provisions of ANS Tl.403-1989 (Ref. [10]), are excluded from the ISDN Primary Rate Interface IA:

1. section 5.3.1: The bit rate tolerance of +/-200 bil/s.

2. section 5.6: The minimum pulse density requirements of this section.

3. section 6.1: The superframe format (SF).

4. section 6.3: The complete section.

5. section 8.0: The reference to the superframe format (SF).

6. section 8.3: The text in paragraph 8.3.1.1 and footnote 7 (8.3.1.2).

7. section 8.4.1: Footnote 9.

8. section 9/Figure 9: Provisions for the use of the RJ48M connector.

9. Table 1: This Table. 10 Table 2: The illustration in Table 2 of Robbed-Bit Signalling.

The following provisions of ANS Tl.403-1989 (Ref. [10]), shall be modified for the ISDN Primary

Rate Interface IA:

1. section 5.3.2: The text of this section is replaced by the statement, "The line code is B8ZS except as noted in section 7."

2. section 7.0: The reference to the pulse density requirements of section 5.6 is inappropriate. The text is replaced by: "The provision of Clear

Channel Capability (CCC) depends upon the use of the B8ZS line code,

though the use of ZBTSI is one interim method that may be employed

by agreement of the network and the user."

The provisions of ANS Tl.403-1989 (Ref. [10]), shall be supplemented by the provisions of section 4.4 of the CCnT Recommendation 1.431-1988, (Ref. [24]).

This IA is currently based upon the ANS Tl.403-1989 (Ref. [10]), standard (the DS1

specification). The ANSI accredited technical subcommittee T1E1 has recently completed a standard for the ISDN Primary Access Interface at the reference points S, T and U (ANS T1.408- 1990, Integrated Services Digital Network (ISDN) —Primary Rate Customer Installation Metallic

Interfaces — Layer 1 Specification, Ref. [11]). This IA is currently undergoing changes to reference it.4

4 This IA (NIU 89-103) has been revised to adopt ANS Tl.408-1990 (Ref. [1 1]) without exception.

This revision (NTU 91-103 Rl) is still undergoing approval by the NIU-Forum, and will be

published in the next version of the NIU-Forum ISDN Agreements document.

4-2 NIU-Forum Agreements on ISDN
4.1.2.2 Future S and T Reference Points

Editor's Note: This section is reserved for future agreements regarding the Layer 1 PRI S and T

Reference Points. Refer to section 4.1.2 of th&North American ISDN Users' Forum (NfU-Forwn)

Working Agreements for the Integrated Services Digital Network (ISDN) — Publication 1 , (Ref.

[32]), for information regarding the current status of this work within the NTU-Forum.

4.1.3 Layer 2 BRI and PRI

The ISDN Basic Rate Interface (BRI) and Primary Rate Interface (PRI) access arrangements

specifies one common IA for the D-channel Layer 2 data link.

The IA (NIU 89-210) for the ISDN data link layer states: the data link layer of the D-channel is specified in ANS Tl.602-1989, ISDN Data-Link Layer Signalling Specification for Application at the User-Network Interface, (Ref. [13]).

The IA has adopted the ANS Tl.602-1989 (Ref. [13]) standard with the following, additional

clarifications:

1) Both automatic and non-automatic Terminal Endpoint Identifier (TEI) assignment terminals

shall be allowed to connect to a passive bus. Automatic TEI assignments are preferred, since it would be the responsibility of the user to ensure that different TEIs are used by each different terminal for non-automatic TEI allocation equipment.

2) It is recommended that the data link monitor function be operated on at least one link associated with each TEI.

4.1.4 Layer 3 BRI and PRI

The ISDN BRI and PRI access arrangements will utilize the Layer 3 Signalling protocol as defined

by ANS Tl.607-1990, ANS Tl.608-1990 and ANS Tl.610-1990 (Refs. [17, 18, 20]). These

specifications apply to two distinct connection types: circuit-switched and packet-switched. The

following text details the IAs for ISDN Layer 3 signalling.

4.1.4.1 Circuit-Switched Call Control Procedures

The circuit-switched Layer 3 signalling protocol shall be responsible for the establishment,

maintenance and tear-down of basic signalling connections and supplementary service signalling

connections which utilize circuit-switched access. The following text details the circuit-switched

call control procedures.

4.1.4.1.1 Basic Call Control Procedures

The IAs (NIU 300 Series) for the ISDN Basic Call Control procedures state: the circuit-switched

network layer protocol is specified in the ANS Tl.607-1990, Digital Subscriber Signalling System

No. 1 (DSS1) —ISDN Layer 3 Signalling Specification for Circuit-Switched Bearer Service, (Ref.

[17]).

The IAs have adopted ANS Tl.607-1990 (Ref. [17]), according to the implementation

configurations, as follows:

NIU-Forum Agreements On ISDN 4-3
Class I BRI (IB)

The Class I BRI (IB) basic call control signalling IA (NIU 90-301) is included in Appendix A.

• Future Class I PRI (IP)

Editor's Note: This section is reserved for future agreements regarding Class I PRI (IP) basic call control signalling. Refer to section 4.1.4.1 of the North American ISDN Users' Forum (NIUForum) Working Agreements for the Integrated Services Digital Network (ISDN) — Publication

1, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

• Future Class II BRI (IIB)

Editor's Note: This section is reserved for future agreements regarding Class II BRI (IIB) basic

call control signalling. Refer to section 4.1.4.1 of the North American ISDN Users' Forum (NIUForum) Working Agreements for the Integrated Services Digital Network (ISDN) — Publication

1, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

• Class II PRI (IIP)

The Class E PRI (IIP) basic call control signalling IA (NIU 90-302) is included in Appendix B.

4.1.4.1.2 Supplementary Services Control Procedures

The IAs (NTU 310 Series) for the ISDN Supplementary Services Control procedures are based

upon ANS Tl.610-1990, Digital Subscriber Signalling System No. 1 (DSS1) —Generic Procedures

for the Control of ISDN Supplementary Services, (Ref. [20]). The following text details the IAs.

• Class I BRI (IB)

The IA (NIU 89-311) for the Class I BRI (IB) Supplementary Services Control procedures states: The generic procedures for the control of ISDN Supplementary Services for Class I equipment on

a Basic Rate Interface (BRI) is specified in ANS Tl.610-1990 (Ref. [20]).

The following changes shall apply to the ANS Tl.610-1990 (Ref. [20]) specification:

1. In section 4, the Keypad protocol only applies during the establishment phase of a call; 2. In section 5.2.2.1, the option of using the dummy call reference for sending a call- associated feature request is removed.

3. In section 2.1.3, section 6, and Appendix I, the Common Information Element Category

of the Functional Protocol is removed;

4. In section 7, the FACILITY and REGISTER messages are removed;

5. In section 8, the Facility information element is removed;

6. In Annex A, the Terminal Identification procedures for assignment of USID and TID at subscription time are removed;

7. In Annex B, section 2.1, the words "in the Called party number information element in one or more INFORMATION messages" should be changed to "in the Called party

number information element in one INFORMATION message;"

8. Remove Appendix III General Description of Component Encoding Rules.

9. The scope of this implementation agreements is applicable only to the ISDN Basic Access

Rate as applied to Class I equipment.

NIU-Forum Agreements on ISDN
Future Class I PRI (IP)

Editor's Note: This section is reserved for future agreements regarding Class I PRI (IP)

Supplementary Services Control procedures. Refer to section 4.1.4.1 of the North American ISDN

Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network

(ISDN) — Publication 1, (Ref. [32]), for information regarding the current status of this work

within the NIU-Forum.

• Future Class II BRI (IIB)

Editor's Note: This section is reserved for future agreements regarding Class II BRI (IIB)

Supplementary Services Control procedures. Refer to section 4.1.4.1 of the North American ISDN

Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network

(ISDN) — Publication 1, (Ref. [32]), for information regarding the current status of this work

within the NIU-Forum.

• Future Class II PRI (IIP)

Editor's Note: This section is reserved for future agreements regarding Class II PRI (IIP) Supplementary Services Control procedures. Refer to section 4.1.4.1 of the North American ISDN

Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network

(ISDN) — Publication 1, (Ref. [32]), for information regarding the current status of this work

within the NIU-Forum.

4.1.4.2 Packet-Switched Call Control Procedures

The Lower Layer Special Interest Group (LLSIG), of the OSI Implementors' Workshop (OIW),

has the responsibility of developing the IAs for packet-switched connections. Their work overlaps

with the packet-switched services provided by an ISDN. Therefore, the SWG has the responsibility

to review the LLSIG's IAs and provide to the LLSIG any additional information/clarification necessary to align these IAs with those defining the ISDN.

The packet-switched layer 3 signalling protocol shall be responsible for the establishment,

maintenance and tear-down of basic signalling connections and supplementary service signalling

connections which utilize packet-switched access. The following text details the packet-switched

call control procedures.

The IA (NIU 89-320) for the ISDN Basic Call Control procedures states: the packet-switched

network layer protocol is specified in the CCITT Recommendation Q.93 1-1988 (also designated

CCITT Recommendation 1.451-1988), ISDN User-Network Interface Layer 3 Specification,

5 (Ref.

[26]).

The following agreements have been reached concerning the use of CCITT Recommendation

Q.93 1-1988, (Ref. [26]):

5 This IA will be aligned with ANS Tl .608-1990, Digital Subscriber Signalling System No. 1 (DSS1

)

—Signalling Specificationfor X.25 Packet Switched Bearer Service (Ref. [18]) when ANS T1.608-

1990 is stable. Please refer to section 4.1.4.2 of the North American ISDN Users' Forum (NIUForum) Working Agreements for the Integrated Services Digital Network (ISDN) — Publication

1 (Ref. [32]) for more information on this alignment

NIU-Forum Agreements On ISDN 4.5
1. On a BRI supporting the ISDN virtual circuit service, all of CCITT Recommendation Q.931-

1988 (Ref. [26]) section 6, except for 6.1.1 and 6.2.1 (the sections covering the circuit-switched access case), shall apply. The following sections also apply; 3.2 (messages for packet-mode access connection control), 4-4.5 (section specifying general information element handling and encoding),

4.7 (information elements for packet communications).

2. On a PRI supporting the ISDN virtual circuit service all of Q.931-1988 (Ref. [26]) section 6, except for 6.1.1 and 6.2.1 (the sections covering the circuit-switched access case), 6.1.2.2, 6.2.2.2 and 6.4.2 (the sections specifying the D-channel ISDN virtual circuit service case), shall apply.

The following sections also apply: 2.2 (packet-mode access connection states), 3.2 (messages for packet-mode access connection control), 4-4.5 (section specifying general information element

handling and encoding), 4.7 (information elements for packet communications).

3. On a BRI or PRI supporting the Unrestricted 64 kbit/s circuit-mode service, CCITT

Recommendation Q.931-1988 (Ref. [26]) sections 6.1.1, 6.2.1, 6.4.1 and 6.4.3 shall apply. The

following sections also apply: 2.1 (circuit-mode connection states), 3.1 (messages for circuit-mode

connection control), 4-4.5 (section specifying general information element handling and encoding).

4.2 Future Basic Bearer Services Specification

The ISDN basic bearer services specifications define the minimal set of bearer services provided

by an ISDN. The specifications outline the set of essential bearer services, and their attributes, to be provided by an ISDN. The IAs developed for the bearer services will provide a specification

outlining the required bearer services and their respective characteristics. The following text will

detail the ISDN basic bearer services IAs.

4.2.1 Future Minimal Set of BRI Services

Editor's Note: This section is reserved for future agreements regarding the minimal set of ISDN

Basic Rate Interface (BRI) bearer services. Refer to section 4.2.1 of the North American ISDN

Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network

(ISDN) — Publication I, (Ref. [32]), for information regarding the current status of this work

within the NIU-Forum.

4.2.2 Future Minimal Set of PRI Services

Editor's Note: This section is reserved for future agreements regarding the minimal set of ISDN

Primary Rate Interface (PRI) bearer services. Refer to section 4.2.2 of the North American ISDN

Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network

(ISDN) — Publication 1, (Ref. [32]), for information regarding the current status of this work

within the NIU-Forum.

4.3 Future Supplementary Services Specification

Editor's Note: This section is reserved for future agreements regarding the ISDN supplementary

services specifications. Refer to section 4.3 of the North American ISDN Users' Forum (NIUForum) Working Agreements for the Integrated Services Digital Network (ISDN) — Publication

1, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

NIU-Forum Agreements on ISDN
4.4 ISDN Terminal Adaptation Specification

The ISDN Terminal Adaptation specifications define the requirements for attaching a non-ISDN

terminal to an ISDN. This attachment is performed across the R reference point, with the specification of the R reference point providing the necessary characteristics, attributes and

functions such that successful interoperability between the non-ISDN and the ISDN is achieved.

The IAs developed for terminal adaptation provide a specification of the R reference point

requirements. The following text details the ISDN terminal adaptation IAs.

4.4.1 Future Circuit-Mode Data Terminal Adaptation

Editor's Note: This section is reserved for future agreements regarding circuit-mode data terminal

adaptation which will define the R reference point requirements when circuit-switched connections

are provided by an ISDN. Refer to section 4.4.1 of the North American ISDN Users' Forum (NIUForum) Working Agreements for the Integrated Services Digital Network (ISDN) — Publication

1, (Ref. [32]), for the information regarding the current status of this work within the NTU-Forum.

4.4.2 Packet-Mode Data Terminal Adaptation

The packet-mode data terminal adaptation IAs define the aspects of the packet-mode services to be used by the packet-mode DTE, the access requirements, and the functions of the Terminal

Adaptor provided across the R reference point. These IAs were developed in the LLSIG of the OSI Implementors' Workshop. Refer to section 7 of the NIST OSI Implementors' Workshop

Stable Implementation Agreements for OSI Protocols (Ref. [42]).

4.5 ISDN Management Specification

The ISDN Management specifications provide the operations and maintenance requirements for the various access interfaces and protocol levels of the ISDN. The IAs are to be developed in the Network Management Expert Working Group (NMWG) of the IIW. The following text details the ISDN Management IAs.

4.5.1 Future Layer 1 BRI

Editor's Note: This section is reserved for future agreements regarding Layer 1 ISDN management

specification, for a Basic Rate Interface (BRI). Refer to section 4.5.1 of the North American ISDN

Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network

(ISDN) — Publication 1, (Ref. [32]), for information regarding the current status of this work

within the NIU-Forum.

4.5.2 Future Layer 1 PRI

Editor's Note: This section is reserved for future agreements regarding Layer 1 ISDN management

specification, for a Primary Rate Interface (PRI). Refer to section 4.5.2 of the North American

ISDN Users' Forum (NIU-Forum) Working Agreementsfor the Integrated Services Digital Network

(ISDN) — Publication 1, (Ref. [32]), for information regarding the current status of this work

within the NIU-Forum.

NIU-Forum Agreements On ISDN 4-7
4.5.3 Future Layer 2 and 3, BRI and PRI

Editor's Note: This section is reserved for future agreements regarding Layer 2 and 3 ISDN

management specification, for a Basic Rate Interface (BRI) and a Primary Rate Interface (PRI).

Refer to section 4.5.3 of the North American ISDN Users' Forum (NIU-Forum) Working

Agreements for the Integrated Services Digital Network (ISDN) —Publication 1, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

4.6 Future Common Channel Signalling — Signalling System #7

Editor's Note: This section is reserved for future agreements regarding common channel signalling

system, ANSI Signalling System #7 (Refs. [1, 2, 3, 4, 5, 6, 19]. Refer to section 4.6 of the North

American ISDN Users' Forum (NIU-Forum) Working Agreements for the Integrated Services

Digital Network (ISDN) —Publication I, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

NIU-Forum Agreements on ISDN
5 ISDN Conformance Test Specifications

The NIU-Forum's Conformance Test (CT) specifications provide test suites to be used to verify the conformance of ISDN equipments to the designated specification. They are written in abstract form so that multiple test equipment vendors may provide implementations of the test suite. The

ISDN Conformance test specifications are developed in the ISDN Conformance Test (ICOT)

Working Group, and its subordinate Expert Working Groups: the Abstract Conformance Test Group for Layer 1 (ACT1) and the Abstract Conformance Test Group for Layers 2 and 3 (ACT23).

The following text details the Conformance Tests for ISDN equipments.

5.1 Layer 1 BRI

The Basic Rate Interface (BRI) Layer 1 Conformance Test specifications provide the requirements

for verifying equipment conformance at Layer 1 of the ISDN BRI user-network interface. The

following text details the Conformance Tests for Layer 1 operation of a BRI.

• Future "U" Interface

Editor's Note: This section is reserved for future agreements regarding the Layer 1 BRI

conformance test abstract test suites, and conformance criteria to the ANS Tl.601-1988 (Ref. [12]). Refer to section 5.1 of the North American ISDN Users' Forum (NIU-Forum) Working Agreements

for the Integrated Services Digital Network (ISDN) —Publication 1, (Ref. [32]), for information

regarding the current status of this work within the NRJ-Forum.

• The "S/T" Interface

The CT defining the conformance criteria and abstract test suites to verify equipment

implementation conformance to the BRI S and T interface as specified in ANS Tl.605- 1989 (Ref.

[ 16]) is defined by the NIU-Forum specification, NKJ 90-002 (NIU-F/HW/ICOT-90-040) Integrated

Services Digital Network (ISDN) Conformance Testing, Layer 1 Basic Rate SIT Interface, User

Side, (Ref. [33]).

5.2 Future Layer 1 PRI

Editor's Note: This section is reserved for future agreements regarding the Layer 1 PRI

conformance test abstract test suites, and conformance criteria to the ANS Tl.601-1988 (Ref. [12]). Refer to section 5.2 of the North American ISDN Users' Forum (NIU-Forum) Working Agreements

for the Integrated Services Digital Network (ISDN) —Publication 1, (Ref. [32]), for information

regarding the current status of this work within the NIU-Forum.

5.3 Layer 2 BRI

The Layer 2 Conformance Test specifications, for the BRI and PRI access arrangements, provide

the requirements for verifying equipment conformance at Layer 2 of the ISDN BRI/PRI. The

ISDN test suite development process is aligned with ISO 9646 (Ref. [43]), OSI Conformance

Testing Methodology and Framework, Parts 1-3. The following text details the Conformance Tests

for Layer 2 operation of an ISDN.

NIU-Forum Agreements On ISDN 5-1
The CT defining the abstract test suites to verify equipment implementation conformance to the Layer 2 of an ISDN at the user-network interface is defined by the NIU-Forum specification, NTU

91-0076 (NTU-Forum/irW/ICOT/ACT-9 1/22.2 V1.2) "Integrated Services Digital Network (ISDN)

Conformance Testing, Layer 2 Basic Rate Interface, Link Access Procedure, D-channel (LAPD),

User Side," (Ref. [34]). This conformance test suite is for the Link Access Procedure D-channel

(LAPD) data link protocol and is described in Tree and Tabular Combined Notation (TTCN). Its use is for ISDN terminal equipments attaching to the user side of a Basic Access interface.

The CT defines the conformance criteria to the ANS Tl.602- 1989 (Ref. [13]) and to the CCITT

Recommendation Q.921-1988 (Ref. [25]) (Note: These specifications are the same text). The

purpose of the Abstract Test Suite is to provide the most complete protocol conformance test coverage as is possible, not to be completely exhaustive. The LAPD Test Suite has many

additional test cases for TEI Management procedures and system related cases which are covered

in the body of the CCITT Recommendation Q.921-1988 text (Ref. [25]) but not in the CCITT

Recommendation Q.921-1988 state transition tables.

5.4 Future Layer 2 PRI

Editor's Note: This section is reserved for future agreements regarding the Layer 1 PRI

conformance test abstract test suites, and conformance criteria to the ANS Tl.602-1989 (Ref. [13]).

5.5 Future Layer 3

Editor's Note: This section is reserved for future agreements regarding the Layer 3 Conformance

Test specifications, for BRI and PRI access arrangements. Refer to section 5.4 of the North

American ISDN Users' Forum (NIU-Forum) Working Agreements for the Integrated Services

Digital Network (ISDN) — Publication 1, (Ref. [32]), for the information regarding the current

status of this work within the NIU-Forum.

5-2

6

NIU-Forum Agreements on ISDN
6 Future Application Software Interface (ASI)

Editor's Note: This section is reserved for future agreements regarding the definition and

specification of the Application Software Interface. Refer to section 6.0 of the North American

ISDN Users' Forum (NIL1 -Forum) Working Agreementsfor the Integrated Services Digital Network

(ISDN) — Publication 1, (Ref. [32]), for information regarding the current status of this work

within the NTU-Forum.

NIU-Forum Agreements On ISDN 6-1

7 Application Profiles

Since the inception of the NIU-Forum, the goal has been to provide an ISDN that users want and

need, and to do so in a way that promotes application interoperability in a multi-vendor

environment. Application profiles are the final step in the functional standardization process to achieve this goal.

7.1 NIU-Forum Application Profiles

An application profile provides an overall specification of the ISDN elements and the application

elements necessary to provide a specific, interoperable application for an ISDN. A profile supports a particular application, or a set of applications, specifying the ISDN standards to use, the options

to implement within each standard, the layered protocol configuration and the application's usage

of the ISDN's attributes. Please refer to section 7.1.1 of the North American ISDN Users' Forum

(NIU-Forum) Working Agreements for the Integrated Services Digital Network (ISDN) —

Publication 1, (Ref. [32]), for a description of the process for developing Application Profiles.

7.1.1 Application Profile Conformance

It is essential that the Application Profile teams identify criteria that the implementor must meet

in order to claim compliance with the Application Profile. It is intended that a tester agency be

established (e.g., the Corporation for Open Systems) which applies ICOT-derived conformance tests in order to verify a product's relative sufficiency of interoperability against a testbed which applies

standardized testing methodologies (e.g., ISO 9646, Ref. [43]). Real multi-vendor interoperability

is achieved in an interoperability testing environment which validates the Application Profile's compliance amongst participatory users and vendors.

7.2 Application Profile Families

The NTU-Forum ISDN applications have been categorized into one of six "application families." The families provide a means of assimilating applications based upon a commonality of usage.

Each family has been assigned its own Application Profile team to develop the Application Profiles for the family. The following Application Profile teams have been identified:

• ISDN Call Management

• ISDN CPE Compatibility/Capability

• ISDN Network Interconnectivity

• Messaging and Answering

• Bandwidth Negotiation

• Network Management/ISDN Administration

The following text details the Application Profile IAs.

7

7.2.1 ISDN Call Management

The ISDN Call Management Profile team has completed an Application Profile, NIU 90-003, for incoming call management which covers all of the following applications:

The NIU-Forum Plenary document numbers (e.g., NIU 90-003) are included for reference purposes

only, as every numbered application profile is included in the present document in its entirety.

NIU-Forum Agreements On ISDN 7-1
Title User Req't Document Number

• Database Information to Corporate Security 810005

• New Account Customer Inquiry Handling 840023

• Customer Service Call Handling 840024

• Automatic Callback for Financial Services 840025

7.2.1.1 Abstract

This application profile provides the User Descriptions, Alternative Architectures, Information

Hows, and recommended Protocol Stacks for the Incoming Call Management Applications (User

Application Requirements Data Form Numbers: 810005, 840023, 840024, 840025, Refs. [35, 36,

37, 38]). The Incoming Call Management Applications involve customer service agents who

currently receive incoming calls, ask the caller for their member number, and input that data into a terminal connected to a host application. ISDN will be used to automate the transfer of the

Caller's ID to the host. In addition, agents may transfer the call to an additional agent who should

be able to continue the call without having to request the same information from the caller again.

ISDN will be used to effect the call transfer and allow the second agent to bring up the right

application screen without repeating questions. Finally, when all the agents are busy, the caller's number should be captured for later callback. ISDN will be used to capture the caller's number

and allow callback later. ISDN can be used to connect the agent's terminal to the host.

7.2.1.2 User Description

Customer service agents currently receive incoming calls, ask the caller for their member number,

and then input the member number into a terminal connected to a host application to obtain the customer information. Agents may transfer the customer to another agent to provide a different

service. The second agent has to again ask for the member number and enter a transaction to receive the customer information. The second agent may access a different host application. In addition, when all agents are busy, the caller's number should be captured for later callback.

7.2.1.3 ISDN Application Breakdown

The user's proposed application and the breakdown of the application into service elements can be seen in figure 7-1.

• Call Transfer with Associated Data Service Element

Agent 1 wishes to transfer a voice call from the Customer to agent 2. The voice call is transferred to agent 2. Certain information associated with the terminal session is transferred to the host to which agent 2 is attached, so that the appropriate screen can be

delivered to agent 2.

• Call Delivery with Associated Data Service Element

The customer places a voice call in order to speak to an agent. The call arrives at a

Central Office (Co) or Customer Premises switch (PBX). The switch delivers the voice

NIU-Forum Agreements on ISDN
CALLER AGENT 1 2. Call Delivery <

with ^

Associated

Data

3. Call Back

on

Busy/

Abandonment

1. Call Transfer

with

Associated Data

Figure 7-1. User Proposed Application Service Breakdown.

NIU-Forum Agreements On ISDN 7-3
call to agent l.

8 Certain information that is delivered to the switch with the voice call (probably the calling party's number) is delivered to a host application, so that the host

application can deliver an appropriate screen to agent 1.

• Call Back on Busy/Abandonment Service Element

This service allows an available agent to place calls to customers who have received busy

or abandoned the call prior to delivery to an agent.

• Terminal Connectivity Service Element

The agents data terminal is connected to the host via an ISDN link.

7.2.1.3.1 Service Logic

Figure 7-2 shows the sequence of services put together to provide Incoming Call Management

Applications. The Terminal Connectivity Service Element may be optional and a Call coming in without the associated data (Calling Line Identification (CLID) may be available for Call Transfer

with associated data.

7.2.1.4 Call Transfer with Associated Data Service Element

In this service a call is already active between agent 1 and the caller. Agent 1 could then perform

any of the following:

1. Blind Transfer — Transfer the call to a second agent and disconnect before the second agent answers.

2. Transfer with Consulting — Transfer the call to a second agent, discuss the call with

the second agent, then complete the transfer.

3. Consult — Agent 1 calls the second agent to discuss the call and then disconnects

agent 2.

The components are shown in figure 7-3.

The sequence of events for each type is:

Blind Transfer

a. Agent 1 places the caller on hold.

b. Agent 1 places a call to agent 2 and invokes transfer.

c. Agent 1 hangs up.

d. Agent 2 is selected directly or by an intervening CO/PBX (Automatic Call

Distributor (ACD) function).

8 The topic of how the switch decides to deliver the call to a particular agent has not been described

as part of this application, but may have some bearing on implementation.

7-4 NIU-Forum Agreements on ISDN
Terminal

Connectivity

Direct Connect

Terminal

Incoming Call

Incoming Call With

Associated Data

Disconnect

Call Back on Busy/Abandonment

(Receive Call)

Call Back on Busy/Abandonment

(Place Call)

Disconnect

Transfer

Call Transfer with Associated Data

END

Figure 7-2. Incoming Call Management Application Logic Row.

NIU-Forum Agreements On ISDN 7-5
Caller

Figure 7-3.

Agent 2

Caller

Screen

ISDN Network

Voico Call

Other Data

(e.g,, CLib, Key)

HOST

Caller

Screen

Agent 1

May

be

the Same

HOST

Call Transfer with Data Service Element Description.

7-6 NIU-Forum Agreements on ISDN
e. Agent 2 receives the voice call, while concurrently a host9 application brings up

an appropriate screen based on some information delivered with the call to agent

2.

Transfer with Consulting

a. Agent 1 places the caller on hold.

b. Agent 1 places a call to agent 2.

c. Agent 2 is selected directly or by an intervening CO/PBX (ACD function).

d. Agent 2 receives the voice call, while concurrently a host application brings up

an appropriate screen based on some information delivered with the call to agent

2.

e. Agent 1 talks with agent 2.

f. Agent 1 transfers the caller to agent 2 and disconnects.

Consulting

a. Agent 1 places the caller on hold.

b. Agent 1 places a call to agent 2.

c. Agent 2 is selected directly or by an intervening CO/PBX (ACD function).

d. Agent 2 receives the voice call, while concurrently a host application brings up

an appropriate screen based on some information delivered with the call to agent

2.

e. Agent 1 talks with agent 2.

f. Agent 2 disconnects.

The information being passed along with the call will be called the Key. The Key may be any of

the following:

• a database key used by the agent's application,

the Calling Party Number,

an Application or Screen ID,

some other information used by the users application,

• or a combination of the above.

9 The host that the application is running on may be the same for both agents or different. NIU-Forum Agreements On ISDN 7-7
7.2.1.4.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

IBM 3270f type terminals

An IBM-compatible host

SNA (Systems Network Architecture) host networks.

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

7.2.1.4.2 Alternative Architectures

Two architectures for this application have been proposed and adopted (March 1989 and June 1989

NTU-Forum). The first architecture calls for the Call information to be delivered to the agent's

station or terminal adaptor (TA)10 and then have that device transmit it to the host application (see

fig. 7-4). If the agent's station is sufficiendy intelligent (e.g., a personal computer), the station could run the application locally.

The second architecture calls for the Host to provide the central office or customer premises switch

with the Key, and that Key is passed to agent 2's Host (see fig. 7-5). The call is delivered to the

agent's station normally. The data terminal could be attached to the host direcdy or be attached using the ISDN Terminal Connectivity Service Element described in section 7.2.1.7.

7.2.1.4.3 Information Flow

The information flow diagrams show that data that must be sent between nodes necessary to provide the service described. Signalling messages that are normally present (i.e., confirmation

messages, error messages, disconnect) are not shown for simplicity if they are not necessary to explain the working of the service.

The information flow for Architecture 1 — Smart Terminal/TA can be seen in figure 7-6.

Agent 1 places a call (Call Setup) which is delivered to agent 2's station with the Key (carried as User to User information). Agent 2's station could generate an appropriate screen using the Key

Trademark of IBM Corporation

This requires intelligence not normally associated with a TA to satisfy the requirement that any

3270-like device were to be able to use this service. A separate functional entity, and Intelligence

Unit (IU), will be described as providing the service of relaying Call information to the host In

effect this unit would upgrade the 3270 to an intelligent terminal with an attached voice terminal. The TA-intelligence unit will have to be able to have a separate session to the host running, so the data can be passed. Alternately, but more complex, the Intelligence Unit would have to be able

to understand the screens being passed between the host and the terminal and insert information

in the data stream.

7-8 NIU-Forum Agreements on ISDN
Figure 7-4. Call Transfer with Data Service Element Architecture 1 — Smart Terminal/TA.

ISDN

Switched Network

NIU-Forum Agreements On ISDN 7-9
Agent 1 Agent 2

DIB

D I I DIB

I PBX/CO

Call Setup

(Key)

PBX/CO

Call Setup

(Key)

Call Transfer

Figure 7-6. Call Transfer with Data Service Element Smart Terminal/TA — Information Flow

Diagram.

7-10 NIU-Forum Agreements on ISDN
or the station could then transfer the Key to the host. The host application would then select and

transmit the appropriate screen to agent 2's terminal.

The information flow for Architecture 2 — Switch Host interface can be seen in figure 7-7.

The call would be initiated by agent 1 selecting to transfer via the terminal. The terminal would

transfer this information to the host ("Init Call"). The host would then transmit this to the PBX/CO

along with the Key as User to User information ("Init Call (Key)"). The PBX/CO the second agent

is attached to would transmit the call setup information to agent 2's station. Simultaneously the PBX/CO would send the call setup information (including the user to user information containing

the Key) to the host computer. The host selects and transmits the appropriate screen to agent 2's

terminal.

In both flows, if consulting is desired instead of completing the transfer, agent 2 would disconnect.

7.2.1.4.4 Network Signalling Requirements — Protocol Identification

The network signalling requirements for providing this service with each architecture are shown

in figures 7-8 and 7-9. Not shown is how the call was originally received, since it may have come

in via ISDN or POTS. The requirement for this capability is that the end-points involved in the

call transfer must be connected via end-to-end ISDN signalling so that user-to-user information can be exchanged.

In the figures 7-8 and 7-9 any connection between two devices without a specific protocol marked

may use any applicable protocol including a proprietary one.

7.2.1.4.5 Protocol Description

The messages and protocol elements described below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the application being described, even through they may be required for other reasons, such as routing

of the call.

7.2.1.4,5.1 Call Setup User Information

The Key can be carried from the origination to destination terminal in the SETUP message

described in NTU 90-301 (see Appendix A) and NTU 90-302 (see Appendix B). The SETUP

Message described as sent to the network and by the network to the called user to initiate call establishment.

The information element used to carry the Key would be the User-User information element

described as follows: "The purpose of the User-user information element is to convey information

between ISDN users. This information is not interpreted by the network, but rather is carried transparently and delivered to the remote user(s). There are no restrictions on the content of the user information."

NIU-Forum Agreements On ISDN 7-11
Agent 1 Agent 2

HOST 1

Notificatio

Init Call

n of Call

Initiation

Call Transfer

PBX/CO

(ACD)

Init Call (Key)

Call Transfer

PBX/CO

(ACD)

Call Setup

IKejO

HOST 2

User Info iKey)

Call

SEND(SCREEN)

Setup

Figure 7-7.

Host 1 and Host 2 may be the same PBX/CO and PBX/CO' may be the same

Call Transfer with Data Service Element Switch Host Interface — Information Flow

Diagram.

Agent 1 Agent 2

ISDN\ ISDN

BRI

HOST

if

ISDN ISDN

BRI

PBX/CO

(ACD)

PBX/CO

(ACD) HOST

Figure 7-8. Call Transfer with Data Service Element Smart Terminal/TA

Requirements.

Network Signalling

7-12 NIU-Forum Agreements on ISDN
Agent 1 Agent 2

D 0 0 ODD

HOST

ISDN

(SCAI)

ISDN

ISDN

Network

ISDN

PBX/CO

(ACD)

PBX/CO

(ACD) ISDN

(SCAI)

HOST

Figure 7-9. Call Transfer with Data Service Element Switch Host Interface Requirements.

Network Signalling

NIU-Forum Agreements On ISDN 7-13
7.2.1.4.5.2 Call Transfer

Proposed baseline text for the Normal Call Transfer supplementary service exists within T1S 1.2/91

-

309, Supplementary Service — Normal Call Transfer Stage 1, 2, and 3, (Ref. [22]). u

There is no consensus on the protocol description for this service yet.

7.2.1.4.5.3 Host-Switch Messages

The functions that need to be provided to allow this service are the following:

• Send User-User information (Key) and initiate a call.

Receive User-User information (Key) on an incoming call.

Possibly initiate the call transfer operation, this could be done from the voice terminal

directly.

The Host Computer messages are being described in the ANSI Switch-Computer Applications

Interface (SCAI) Working Document, T1S 1.1/9 1-387 (Ref. [23]). Section 5 of the SCAI working

document described the DATA/VOICE COORDINATION ASE "which may be used by an

Application Process on either a switch or a computer to exchange information and commands for the purpose of coordinating voice and data services." The protocol definition is currently for further study.

7.2.1.5 Call Delivery with Associated Data Service Element

In this service an agent is available to receive an incoming call. When a customer's call is presented to the agent an appropriate screen is displayed on the agent's data terminal that relates to the caller or the application being provided by the agent (see fig. 7-10).

The sequence of events is as follows:

a. Caller places a call to the phone number of the "Call Delivery service user" (800

number in some User's application).

b. An agent is selected by the CO/PBX (ACD function).

c. The agent receives the voice call, while concurrently a host application brings up an

appropriate screen (based upon the calling party's number).

7.2.1.5.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

IBM 3270 type terminals

11 There is also ongoing work within ANSI to define Explicit Call Transfer and Single Step Call Transfer Supplementary Services.

7-14 NIU-Forum Agreements on ISDN
Caller

Calling Party

Number

Figure 7-10. Call Delivery with Data Service Element Description.

NIU-Forum Agreements On ISDN
An IBM-compatible host SNA host networks.

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

7.2.1.5.2 Alternative Architectures

Two architectures for this application have been proposed and adopted (March 1989 and June 1989

NIU-Forum). The first architecture calls for the Call information to be delivered to the agent's

station or terminal adaptor (TA)12 and then have that device transmit it to the host application (see

fig. 7-11). If the agent's station is sufficiently intelligent (e.g., a personal computer), the station could run the application locally.

The second architecture calls for the Host to provide the central office or customer premises switch

with the Key, and that Key is passed to agent 2's Host (see fig. 7-12). The call is delivered to the agent's station normally. The data terminal could be attached to the host directly or be attached

using the ISDN Terminal Connectivity Service Element described in section 7.2.1.7.

7.2.1.5.3 Information Flow

The information flow diagrams show the data that must be sent between nodes necessary to provide

the service described. Signalling messages that are normally present (i.e., confirmation messages,

error messages, disconnect) are not shown for simplicity, if they are not necessary to explain the working of the service.

The information flow for Architecture 1 — Smart Terminal/TA can be seen in figure 7-13.

The call is delivered to the agent's station with the Calling Party Number (CPN). The station will generate an appropriate screen locally or by interacting with a host application.

The information flow for Architecture 2 — Switch Host interface can be seen in figure 7-14.

The Switch transmits the call setup information to the agent's station and the host computer

simultaneously. The host selects and transmits the appropriate screen.

12 This requires intelligence not normally associated with a TA to satisfy the requirement that any

3270-like device were to be able to use this service. A separate functional entity, and Intelligence

Unit (IU), will be described as providing the service of relaying Call information to the host. In

effect this unit would upgrade the 3270 to an intelligent, terminal with an attached voice terminal. The TA-intelligence unit will have to be able to have a separate session to the host running, so the data can be passed. Alternately, but more complex, the Intelligence Unit would have to be able

to understand the screens being passed between the host and the terminal and insert information

in the data stream.

7-16 NIU-Forum Agreements on ISDN
Agent 1

Caller

IU

ISDN

Switched Network

a o a a a a a

Calling

Party

Number

HOST

Figure 7-11. Call Delivery with Data Service Element Architecture 1 — Smart Terminal/TA.

Agent 1

Caller

ISDN

Switched Network

00

DO

a ODD

Calling Party

Number HOST

Figure 7-12. Call Delivery with Data Service Element Architecture 2 — Switch Host Interface.

NIU-Forum Agreements On ISDN 7-17
PBX/CO PBX/CO HOST

Call Setup Call Setup

(CLID) Call Setup

(CLID) Call Setup

__JCUD)__

Callinfo

(CLID)

SEND(SCREEN)

Figure 7-13. Call Delivery with Data Service Element Smart Terminal/TA

Diagram.

Information Flow

PBX/CO PBX/CO HOST

Call Setup

Figure 7-14. Call Delivery with Data Service Element Switch Host Interface Diagram.

Information Flow

7-18 NIU-Forum Agreements on ISDN
7.2.1.5.4 Network Signalling Requirements — Protocol Identification

In order to implement this service, certain signalling capabilities are required in the user and carrier networks. Figures 7-15 and 7-16 identify what are the signalling requirements at each point in the network. As can be seen in me diagrams the requirements for signalling within the network are the same for the smart terminal and switch-host scenarios, but there are differences within the premises.

EAMF stands for Equal Access Multi-Frequency which can be used to pass the Calling Party

Number. Any connection between two devices without a specific protocol marked may use any

applicable protocol including a proprietary one.

7.2.1.5.5 Protocol Description

The messages and protocol elements described below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the application being described, even through they may be required for other reasons, such as routing

of the call.

7.2.1.5.5.1 Call Setup User Information

The Calling Party Number can be carried from the origination to destination terminal in the SETUP message described in NTU 90-301 (see Appendix A) and NIU 90-302 (see Appendix B).

The SETUP message is described as sent to the network and by the network toward the called user

to initiate call establishment.

The Information needed to carry the Calling Party Number is described in a paragraph titled Calling Party Number. "The Purpose of the Calling party number information element is to identify the origin of the call." The information element may say that the number is not available, the application must be able to handle this situation appropriately.

7.2.1.5.5.2 Host-Switch Messages

The necessary function required by this service is die handling of the incoming Calling Party

Number.

The Host Computer messages are being described in the ANSI Switch-Computer Applications

Interface (SCAI) Working Document, T1S1. 1/91-387 (Ref. [23]). Section 5 of the SCAI working

document described the DATA/VOICE COORDINATION ASE "which may be used by an

Application Process on either a switch or a computer to exchange information and commands for the purpose of coordinating voice and data services." The protocol definition is currently for further study.

NIU-Forum Agreements On ISDN 7-19
Agent Station

Caller

D O D BCD

ana ODD

ISDN

or POTS

Originating

Office

Caller

Screen

ISDN

BRI/

ISDN

or EAMF

Transit

Switch

or CO

ISDN PBX/CO

(ACD) HOST

Figure 7-15. Call Delivery with Data Service Element Smart Terminal/TA

Requirements.

Optional

Network Signalling

Caller

ISDN

or POTS

Agent Station

Originating

Office

ISDN

Transit

Switch

or CO

TSDN PBX/CO

(ACD)

ISDN

or HOST

EAMF SCAI

Figure 7-16. Call Delivery with Data Service Element Switch Host Interface — Network Signalling

Requirements.

7-20 NIU-Forurn Agreements on ISDN
7.2.1.6 Call Back on Busy/Abandonment Service Element

In this service, no agents are available to receive an incoming call. The caller may do any of the following:

1. Receive Busy (possible reasons: all agents busy, maximum queue size),

2. Receive an Announcement (i.e., "All Lines are Busy, An agent will call you back

when one becomes available") followed by disconnect,

3. be placed in a queue (possibly with an announcement "Wait for the next available agent, if you hangup, an agent will return your call") for the next available agent and

then disconnect.

The caller's phone number will be recorded so that an agent can call back later (see fig. 7-17).

This service cannot be invoked, unless the call is delivered to the final switch.

The sequence of events is as follows:

a. Caller places a call to the phone number of the "Call Delivery service user" (800

number in one user's application).

b. The calling line id is recorded by a host application.

c. The treatment may be busy, an announcement and disconnect, or being placed in a queue. If the caller was placed in a queue, they subsequently disconnected.

d. Agent obtains the number from the application software and places a call.

7.2.1.6.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

IBM 3270 type terminals

• An IBM-compatible host

SNA host networks.

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

7.2.1.6.2 Architecture

Two architectures for this application have been proposed and adopted (March 1989 and June 1989

NIU-Forum). The first architecture calls for the information to be delivered to the agent's terminal

and the second to a host computer. Only the second architecture is considered here because there

NIU-Forum Agreements On ISDN 7-21
Caller

Call

Call

Back

C£ll

PBX/CO

(ACD)

Call Info j

HOST

D D

0 0 0 0 0 0

Caller

Screen

Agent Station

Figure 7-17. Call Back on Busy/Abandonment Service Element Description.

7-22 NIU-Forum Agreements on ISDN
is no mechanism to pass information about calls that have never reached a station (i.e., Caller disconnects, PBX returns busy) to a station.

7.2. 1.6J Information Flow

The flow diagrams show the general information flow necessary to provide the service described.

Some messages that are normally present (i.e., confirmation messages, error messages, disconnect) are not shown if they are not necessary to explain the working of the service.

The flow diagram for call abandonment can be seen in figure 7-18. The call setup information,

including Calling Party Number (CPN) goes across the network. The Switch transmits the call setup information (CPN) to the host computer. The caller then "Disconnects" and the host computer is informed, so it puts the number in a list for later callback. At a later time, the agent

interacts with the host and selects a callback number. The agent can then either generate the call via the host or dial the number using the phone. Figure 7-19 is the flow diagram for the case where the caller receives busy or hears an announcement.

7.2.1.6.4 Network Signalling Requirements

The network signalling requirements for this service are the same as for Call Delivery using the Switch to Host interface (see fig. 7-16).

7.2.1.6.5 Protocol Description

The messages and protocol elements described below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the application being described, even through they may be required for other reasons, such as routing

of the call.

7.2.1.6.5.1 Call Setup User Information

The Customer identifier can be carried from the origination to destination terminal in the SETUP

message described in NTU 90-301 (see Appendix A) and NTU 90-302 (see Appendix B). The

SETUP message is described as sent by the calling user to the network and by the network to the

called user to initiate call establishment.

The Information needed to carry the Calling Party Number is found in the paragraph titled Calling

Party Number. "The purpose of the Calling party number information element is to identify the

origin of the call." The information element may say that the number is not available, the application must be able to handle this situation appropriately.

7.2.1.6.5.2 Host-Switch Messages

The necessary function required by this service is the handling of the incoming Calling Party

Number.

The Host Computer messages are being described in the ANSI Switch-Computer Applications

Interface (SCAI) Working Document, T1S1. 1/91-387 (Ref. [23]).

NIU-Forum Agreements On ISDN 7-23
0 0 D BO Oil

ID PBX/CO

Call Setup

isconnect

CallSetup_^_

PBX/CO

Call Setup

(CLID)

Disconnect

Call Setup

Cut Through

HOST

Callinfo

JCLID)

.Disconnect

Init Call

(CLID)

Notification

Initiation

o a d o a

a o o

d a o

Query Disconnects

* Placement of the Call could be from a Phone

Figure 7-18. Call Back on Busy/Abandonment Service Element Information How Diagram

Abandonment.

7-24 NIU-Forum Agreements on ISDN
* Placement of the Call could be from a Phone

Figure 7-19. Call Back on Busy/Abandonment Service Element Information Row Diagram — Busy.

NIU-Forum Agreements On ISDN 7-25
Section 5 of the SCAI working document described the DATA/VOICE COORDINATION ASE

"which may be used by an Application Process on either a switch or a computer to exchange

information and commands for the purpose of coordinating voice services." The protocol is currently for further study.

7.2.1.7 Terminal Connectivity Service Element

This service provides connectivity between a terminal and a host using an ISDN link. This is illustrated in figure 7-20.

The sequence of events is as follows:

a. The user causes a call to be placed from the terminal to a port on the

host/controller.

13

b. Upon connection of the call the data transport protocol is initiated.

c. When the data session is complete the call is disconnected.

7.2.1.7.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

• IBM 3270 type terminals

An IBM-compatible host SNA host networks.

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

7.2.1.7.2 Information Flow

The information flow diagrams show the data that must be sent between nodes necessary to provide

the service described. Signalling messages that are normally present (i.e., confirmation messages,

error messages, disconnect) are shown for simplicity if they are not necessary to explain the working of the service.

The flow diagram in figure 7-21 shows the general information flow necessary to provide the described service.

The use of some ISDN features for security (i.e., CLID) may be required, but are not part of the user application description (text or figures).

7-26 NIU-Forum Agreements on ISDN
BRI

PBX

or CO

Switch

BRI or PRI

Figure 7-20. Terminal Connectivity Service Element — Description.

Terminal CO/PBX CO/PBX HOST

Call Setup

(Phone Number)

Connect

Call Setup

Connect

Call Setup

Connect

Normal Call

Initiation Sequence

Channel Open

Data Message Data Communication

Protocol

Data Message

Data Message

Data Message

Conversation Complete

Disconnect Disconnect Disconnect Normal Call

Completion

(Either side may

initiate)

Figure 7-21. Terminal Connectivity Service Element Flow Diagram.

NIU-Forum Agreements On ISDN 7-27
7.2.1.7.3 Network Protocol Requirements

The network protocol requirements for this service can be seen in figure 7-20. As shown in that figure, there needs to be ISDN connectivity between the terminal and the point where it is attached

to the computer or controller.

The higher layer protocols for carrying the user data are not described here. The Network

Interconnectivity Profile Team should provide the higher level protocol specification when

completing Application Profiles for the User Application Requirements Data Forms numbered:

830008, 830009, 960009 (Refs. [39, 40, 41]).

7.2.1.7.4 Protocol Description

The messages and protocol elements described below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the application being described, even through they may be required for other reasons, such as routing

of the call.

The protocol described in NIU 90-301 (see Appendix A) and NIU 90-302 (see Appendix B) can be used for the setup and breakdown of the call being made to carry the data protocol.

The only information element that may have a direct bearing on the service is in the SETUP

message described as "sent by the calling user to the network and by the network to the called user

to initiate call establishment." The information element is the Bearer Capability Information

Element. The user can ask for the appropriate information transfer capability and transfer mode.

7-28 NIU-Forum Agreements on ISDN
7.2.1.8 Protocol Summary and Status

The following is a summary of the protocol requirements of the Incoming Call Management

Application.

Table 7-2. Protocol Requirements for Incoming Call Management Application Profile

Annlication

Service Element

Protocol Element Document Status

Call Transfer

With Associated Data

User—User NTU 90—301 & NIU

90—302

Implementation

Agreements

See

Appendices

B and C of

this document

Call Transfer T1S1.2/91—309 (Ref.

[22]) Proposed

Protocol

Definition

Host—Switch T1S1. 1/91—387 SCAI

Working Document,

(Ref. [23])

Service

Definition

Call Delivery

With Associated Data

Calling Party

Number

NTU 90—301 & NTU

90—302

Implementation

Agreements

See

Appendices

B and C of

this document

Host—Switch T1S 1.1/9 1—387 SCAI

Working Document

(Ref. [23])

Service

Definition

Terminal Connectivity Bearer Capability NTU 90—301 & NTU

90—302

Implementation

Agreements

See

Appendices

B and C of

this document

Higher Layer Network

Interconnectivity

Family

In Progress

Call Back Calling Party

Number

NTU 90—301 & NTU

90—302

Implementation

Agreements

See

Appendices

B and C of

this document

Host—Switch T1S1. 1/91—387 SCAI

Working Document

(Ref. [23])

Service

Definition

Legend Near Completion — Implementation Agreements are near completion.

Protocol definition — The protocol is currently being defined. Service definition — Ground work for starting protocol work is being done.

NIU-Forum Agreements On ISDN 7-29
7.2.2 Future ISDN CPE Compatibility/Capability

Editor's Note: This section is reserved for future agreements regarding ISDN CPE

Compatibility/Capability. Refer to section 7.2.2 of the North American ISDN Users' Forum (NIUForum) Working Agreements for the Integrated Services Digital Network (ISDN) — Publication

1, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

7.2.3 Future ISDN Network Interconnectivity

Editor's Note: This section is reserved for future agreements regarding ISDN Network

Interconnectivity. Refer to section 7.2.3 of the North American ISDN Users' Forum (NIU-Forum)

Working Agreements for the Integrated Services Digital Network (ISDN) — Publication 1, (Ref.

[32]), for information regarding the current status of this work within the NIU-Forum.

7.2.4 Future Messaging and Answering

Editor's Note: This section is reserved for future agreements regarding Messaging and Answering.

Refer to section 7.2.4 of the North American ISDN Users' Forum (NIU-Forum) Working

Agreements for the Integrated Services Digital Network (ISDN) —Publication 1, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

7.2.5 Future Bandwidth Negotiation

Editor's Note: This section is reserved for future agreements regarding Bandwidth Negotiation.

Refer to section 7.2.5 of the North American ISDN Users' Forum (NIU-Forum) Working

Agreements for the Integrated Services Digital Network (ISDN) —Publication 1, (Ref. [32]), for information regarding the current status of this work within the NIU-Forum.

7.2.6 Future Network Management/ISDN Administration

Editor's Note: This section is reserved for future agreements regarding Network

Management/ISDN Administration. Refer to section 7.2.6 of the North American ISDN Users' Forum (NIU-Forum) Working Agreements for the Integrated Services Digital Network (ISDN) —

Publication 1, (Ref. [32]), for information regarding the current status of this work within the NIUForum.

7-30 NIU-Forum Agreements on ISDN
8 References

8.1 ANS documents

[I] ANS Tl . 1 1 1

- 1988, Telecommunications —Signalling System Number 7 (SS7) —Message Transfer Part (MTP).

[2] ANS Tl. 112-1988, Telecommunications — Signalling System Number 7 (SS7) — Signalling

Connection Control Part (SCCP).

[3] ANS Tl.l 13-1988, Telecommunications —Signalling System Number 7 (SS7) —ISDN User Part

(ISUP).

[4] ANS Tl.l 14-1988, Telecommunications — Signalling System Number 7 (SS7) — Transactions

Capability Application Part (TCAP).

[5] ANS Tl. 115-1989, Telecommunications — Signalling System Number 7 (SS7) —Monitoring and

Measurements.

[6] ANS Tl.l 16-1989, Telecommunications — Signalling System Number 7 (SS7) — Operations,

Maintenance, Administration and Provisioning (OMAP).

[7] ANS Tl.216-1991, ISDN Management —Basic Rate Physical Layer.

[8] ANS Tl.217-1991, ISDN Management —Primary Rate Physical Layer.

[9] ANS Tl.218-1991, ISDN Management —Data Link and Network Layers.

[10] ANS Tl.403-1989, Telecommunications — Carrier to Customer Installation — DS1 Metallic

Interface.

[II] ANS Tl.408-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Primary

Rate — Customer Installation Metallic Interfaces —Layer 1 Specification.

[12] ANS Tl.601-1988, Telecommunications —Integrated Services Digital Network (ISDN) —Basic Access Interface for Use on Metallic Loops for Application on the Network Side of the NT-Layer

1 Specification.

[13] ANS Tl.602- 1989, Telecommunications —Integrated Services Digital Network (ISDN) —DataLink Layer Signalling Specification for Application at the User-Network Interface.

[14] ANS Tl.603-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Minimal

Set of Bearer Services for the Primary Rate Interface.

[15] ANS Tl.604-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Minimal

Set of Bearer Services for the Basic Rate Interface.

[16] ANS Tl.605-1989, Telecommunications —Integrated Services Digital Network (ISDN) —Basic Access Interface at S and T Reference Points — Layer 1 Specification.

NIU-Forum Agreements On ISDN 8-1
[17] ANS Tl .607- 1990, Telecommunications —Integrated Services Digital Network (ISDN) —Digital

Subscriber Signalling System Number I (DSS1) - Layer 3 Signalling Specification for Circuit- Switched Bearer Service.

[ 1 8] ANS Tl .608- 1990, Telecommunications - Integrated Services Digital Network (ISDN) —Digital

Subscriber Signalling System Number 1 (DSS1) — Signalling Specification for X.25 PacketSwitched Bearer Service.

[19] ANS Tl.609-1990, Telecommunications — Integrated Services Digital Network (ISDN)

Interiorking between the ISDN User-Network Interface Protocol and the Signalling System

Number 7 (SS7) ISDN User Part.

[20] ANS Tl.610-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Digital

Subscriber Signalling System Number 1 (DSS1) — Generic Procedures for the Control of ISDN

Supplementary Services.

[21] ANS Tl.612-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Terminal

Adaptation Using Statistical Multiplexing.

[22] T1S1.2/91-309 (T1S 1.2/89-299), Supplementary Service —Normal Call Transfer Stage 1, 2 and

3.

[23] T1S1. 1/91-387 (T1S 1.1/90-077), Switch-Computer Applications Interface (SCAI) Working

Document.

8.2 CCITT Documents

[24] CCITT Recommendation 1.431-1988, ISDN Primary Rate User-Network Interface — Layer 1

Specification.

[25] CCITT Recommendation Q.921-1988 (also designated CCITT Recommendation 1.441- 1988), ISDN

User-Network Data Link Layer Specification.

[26] CCITT Recommendation Q.93 1-1988 (also designated CCITT Recommendation 1.451-1988), ISDN

Primary Rate User-Network Interface —Layer 3 Specification.

[27] CCITT Recommendation V.120-1988, Support by an ISDN of Data Terminal Equipment with Vseries Type Interfaces with Provision for Statistical Multiplexing.

[28] CCITT Recommendation X.25- 1984, Interface between Data Terminal Equipment (DTE) and Data

Circuit-Terminating Equipment (DCE)for Terminals Operating in the Packet Mode and Connected

to Public Data Networks by Dedicated Circuit.

[29] CCITT Recommendation X.3 1-1988, Support of Packet Mode Terminal Equipment by an ISDN.

[30] CCITT Recommendation 1.231-1988, Circuit-Mode Bearer Service Categories.

[31] CCITT Recommendation 1.232-1988, Packet-Mode Bearer Services Categories.

8-2 NIU-Forum Agreements on ISDN
8.3 NIU-Forum Documents14

[32] NIU Publication 1, North American ISDN Users' Forum (NIU-Forum) Working Agreements for

the Integrated Services Digital Network (ISDN), 01 June 1990.

[33] NIU 90-002 (NIU/IIW/ICOT/90-40), Integrated Services Digital Network (ISDN) Conformance

Testing, Layer 1 Basic Rate SIT Interface, User Side, 1990.

[34] NIU 91-007 (NIU/IIW/ICOT/ACT23/9 1-22.2 V1.2), Integrated Services Digital Network (ISDN)

Conformance Testing, Layer 2 Basic Rate Interface, Link Access Procedure, D-channel (LAPD),

User side, 1991.

[35] NIU-Forum User Application Requirements Data Form 810005, "Database Information to Corporate Security".

[36] NIU-Forum User Application Requirements Data Form 840023, "New Account Customer Inquiry

Handling".

[37] NIU-Forum User Application Requirements Data Form 840024, "Customer Service Call Handling

(Incoming Call Management)".

[38] NIU-Forum User Application Requirements Data Form 840025, "Automatic Callback for Financial Services".

[39] NIU-Forum User Application Requirements Data Form 830008, "Asynchronous to SNA/SDLC".

[40] NIU-Forum User Application Requirements Data Form 830009, "Synchronous Terminal to Controller".

[41] NIU-Forum User Application Requirements Data Form 960009, "Asynchronous Access to Host

Computer".

8.4 Other Documents

[42] NIST Special Publication 500-183, Stable Implementation Agreements for Open Systems

Interconnection Protocols, Version 4, Edition 1, December 1990.

[43] ISO 9646, Information Processing Systems, OSI Conformance Testing Methodology and

Framework. Parts 1-5, 1989.

14 These documents are available by contacting the NIU-Forum Administrator, NIST, Building 222

.

Room B364, Gaithersburg, MD 20899.

NIU-Forum Agreements On ISDN 8-3

APPENDIX A.

NIU 90-301

Implementation Agreement

of the North American ISDN Users' Forum

Layer 3 Signalling Specification for the Minimal Set of Circuit-Switched Bearer Services for the ISDN Basic Rate Interface/Class I.

Baseline Text American National Standard Tl.607-1990:

Integrated Services Digital Network (ISDN) —

Layer 3 Signalling Specification for Circuit-Switched Bearer Service for Digital Subscriber Signalling System Number 1 (DSS1).

Base Standards

CCITT Recommendation Q.931 (1988):

ISDN User-Network Interface Layer 3 —

Specification For Basic Call Control. ANSI Tl.607-1990

ANSI T1.604*:

Integrated Services Digital Network (ISDN) —

Minimal Set of Bearer Services for the Basic Rate Interface.

A.l Abstract

This Implementation Agreement specifies procedures for establishing, maintaining, and clearing connections at the Integrated Services Digital Network (ISDN) user-network interfaces and are mandatory for the support of the minimal

set of circuit-switched bearer services specified by ANSI Tl.604- 1990* Integrated Services Digital Network (ISDN) — Minimal Set of Bearer Services for the Basic Rate Interface, (Ref. [15]). Procedures for circuit-mode digital,

circuit-mode speech and circuit-mode voiceband data bearer services are as specified in the baseline text ANS

Tl.607-1990, Integrated Services Digital Network (ISDN) —Digital Subscriber Signalling System Number 1 (DSS1

)

— Layer 3 Signalling Specification for Circuit-Switched Bearer Service, (Ref. [17]) as further resolved by this agreement. The packet-mode data service is included in this document as a bearer service. Procedures for the packet-mode bearer service will be detailed in another document.

Subject to further discussion.

NIU-Forum Agreements On ISDN A-l
A.2 Introduction

The original implementation agreement (NIU 90-301) was reached by marking up the text of ANS T1.607- 1990,

(Ref. [17]) to reflect the clarifications of text and selection of options. This appendix translates the implementation

agreement markup into a listing of these clarifications and selections, (i.e., this appendix lists the differences [the "delta"] between the implementation agreement marked up ANS Tl.607-1990, and the original text of ANS T1.607-

1990).

A.3 NIU 90-301 Delta List"

The IA has adopted the ANS Tl.607-1990*" (Ref. [17]) standard with the following clarifications of the text, and

selection of options:

ANS Tl.607-1990

SECTION/TABLE NUMBER/NAME

Section 1 General

Section 1.1 Scope and Purpose

Section 2.2

States associated with the global reference

call

Section 3 Message functional definition and content Item (b), Subitem (2)

Section 3.1 Messages for circuit-mode connection control Table 1 — Messages for circuit-mode connection

control

Section 3.1 Messages for circuit-mode connection control Table 1 — Messages for circuit-mode connection

control

IMPLEMENTATION AGREEMENTS - CLARIFICATION OF TEXT AND

SELECTION OF OPTIONS

Delete "1. General" heading.

Replace this section with Attachment A of this document.

Delete this section including subsections.

Delete last sentence from the Note: "Annex D

contains a description of the information element

usage for symmetric NT2-NT2 interfaces."

Change "NOTIFY 3.1.7" to "*NOTTFY".

Add the following footnote below table 1: "* See

section 5.8.4 for treatment of this message."

Note that this Delta List was developed in "good faith" by NIST as a simple equivalent representation of

the actual agreements. It has been reviewed and approved by the editors of the Signalling Working Group

as per recommendation of the Executive Steering Committee.

This documents can be purchased from: American National Standards Institute, 1 1 West 42nd Street New

York, NY 10036.

A-2 NIU-Forum Agreements on ISDN
Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Change the "Channel Identification/Direction" cell from "both (Note 1)" to "u -> n".

Change the "Channel Identification/Length" cell from

"2-*" to "2-3".

Change the "Progress Indicator/Direction" cell from

"both" to "n -> u".

Change the "Progress Indicator/Length" cell from

"2-4" to "2,4".

Delete "Display" row.

Delete Notes 1, 4, 5.

Delete the last sentence from Note 3.

Change Note "6 Included if the network optionally

provides additional information describing tones." to "6 The network will always provide this IE."

Change the "Channel Identification/Length" cell from

"2-*" to "2-3".

Delete reference to "Note 2" in the "Progress

indicator/Type" cell.

Change the "Progress Indicator/Length" cell from

"2-4" to "2, 4".

Delete "Display" row.

NIU-Forum Agreements On ISDN A-3
Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.4 CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Delete Notes 2, 3, 4.

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Change the "Channel Identification/Direction" cell from "both (Note 1)" to "u -> n (Note 1)".

Change the "Channel Identification/Length" cell from

"2-*" to "3".

Change the "Progress indicator/Direction" cell from

"both" to "n -> u".

Change the "Progress Indicator/Length" cell from "2- 4" to "2, 4".

Delete the following rows:

• "Display";

• "Connected number";

• "Connected subaddress";

• "Low Layer compatibility".

Change Note 1 from "Included in the network-to-user

direction for support of the procedures in Annex D."

to "The coding of this IE should be always 'Exclusive

B'."

Delete the following from Note 3: "or in connection

with the provision of in-band tones and patterns."

Delete Notes 4, 5, 7, 8, 9.

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

A-4 NIU-Forum Agreements on ISDN
Section 3.1.4 CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.4 CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.4 CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.6 INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6 INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6 INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6 INFORMATION

Table 7 — INFORMATION message content

Delete "Display" row.

Delete Notes 1, 2.

Change Note 3 from "Included if the network

optionally provides additional information describing

tones." to "Included if the network is required to turn Alerting off."

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Change the "Cause/Length" cell from "4-32" to "4- 10".

Delete the following rows:

• "Display";

• "Connected Number";

• "Connected subaddress".

Delete Notes 1, 2, 4, 5.

Change Note 3 to: "Included if the network must

turn tones on or off, or turn ALERTING off."

Change the "Call Reference/Length" cell from

"2-*" to "2-3".

Delete "Display" row.

Change the "Keypad Facility/Length" cell from

"2-34" to "3-34".

Delete Notes 2, 3.

NIU-Forum Agreements On ISDN A-5
Section 3.1.6 INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6 INFORMATION

Table 7 — INFORMATION message content

Add the following to the end of Note 4 ("The Keypad

facility information element.."): "When INFO is sent u -> n, this IE must be present."

Change Note 5 from "Included if the network

optionally provides additional information describing

tones." to "Included if the network is required to turn tones off."

Section 3.1.7 NOTIFYDelete this section.

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Change "Direction" in table header from "both" to "n -> u".

Change the "Direction" cell in the following rows

from "both" to "n -> u":

• "Protocol discriminator";

• "Call reference";

• "Message type";

• "Cause";

• "Progress Indicator".

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" cell from

"2-32" to "2,4-10".

Delete "Display" row.

Delete Notes 2, 3.

Change Note 4 from "Included if the network

optionally provides additional information describing

tones." to "Included when tones or some

announcement are provided in-band."

Change the "Call reference/Length" cell from "2-*"

to "2-3".

A-6 NIU-Forum Agreements on ISDN
Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Change the "Cause/Length" cell from "2-32" to "2,4- 10".

Delete the following rows:

• "Display";

• "Connected number";

• "Connected subaddress".

Delete Notes 3, 4, 6, 7.

Change Note 5 from "Included if the network

optionally provides additional information describing

tones." to "Included if the network must turn tones or Alerting off."

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" cell from "2-32" to "2, 4-

10".

Delete the following rows:

• "Display";

• "Connected number"

• "Connected subaddress".

Delete Notes 3, 4, 6, 7.

Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Change Note 5 from "Included if the network

optionally provides additional information describing

tones." to "Included if the network is required to turn tones on or off."

Change the "Call Reference/Length" cell from

"2-*" to "2-3".

Delete the following rows:

• "Repeat Indicator";

• "Network-Specific Facilities";

• "Display".

NIU-Forum Agreements On ISDN A-7
Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

A-8

Delete from the "Bearer Capability/Type" cell the reference to Note 2.

Change the "Bearer Capability/Length" cell from

"4-13" to "4-8".

Change the "Channel Identification/Length" cell from

"2-*" to "2-3".

Change the "Progress Indicator/Direction" cell from

"both" to "n -> u".

Change the "Progress Indicator/Length" cell from

"2-4" to "2,4".

Change the "Calling party number/Length" cell from

"2-*" to "2-19".

Change the "Called party address/Length" cell from

"2-*" to "2-18".

Change the "Transit Network Selection/Length" cell from "2-*" to "2-7".

Change the "Higher Layer Compatibility/Length" cell from "2-4" to "2-5".

Delete Notes 1, 2, 5, 6, 7.

Add to the end of Note 8: "The digits in this EE are 0 to 9, *, and #."

Change Note 9 from "Included if the network

optionally provides additional information describing

tones." to "The network will always provide this IE."

Add to the end of Note 13: "The network should

transport this IE transparently. This EE is optional on

the user side."

NIU-Forum Agreements on ISDN
Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.12 SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Add to the end of Note 15: "The network should

transport this IE transparently. This IE is optional on

the user side. The total length is 2 to 16 octets."

Add to the end of Note 16: "The network should

transport this IE transparently. This IE is optional on

the user side."

Add to the end of Note 17: "The network will treat this IE on sending and receiving as described in the User-User supplementary service Implementation

Agreement."

Delete "and 7kHz audio" from Note 20.

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Section 3.1.12 SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Change the "Channel Identification/Type" cell from

"M" to "M*".

Section 3.1.12 SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Add the following footnote before Note 1: "* The

coding of the channel ID should always be 'Exclusive

B'."

Section 3.1.12 Change the "Channel Identification/Length" cell SETUP ACKNOWLEDGE from "3-*" to "3". Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12 Change the "Progress Indicator/Length" cell from "2- SETUP ACKNOWLEDGE 4" to "2,4".

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12 Delete "Display" row. SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12 SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Change Note 1 to: "The only valid value for progress

indicator is 8 (refer to section 4.5.21 octet 4). Included in connection with the provision of in-band

information/patterns.

NIU-Forum Agreements On ISDN A-9
Section 3.1.12 Delete Notes 2, 3. SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12 SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.13 STATUS

Change Note 4 from "Included if the network

optionally provides additional information describing tones (e.g., activate dial tone)." to "Included if the network is required to turn on dial tone."

Change the first sentence from "This message is sent by the user or the network in response to a STATUS

ENQUIRY message or at any time during a call to report certain error conditions as listed in 5.8." to "This message is sent by the user in response to a STATUS ENQUIRY message sent by the network, or by either the user or the network to report certain error conditions as listed in 5.8."

Section 3.1.13 STATUS

Table 14 — STATUS message content

Change the "Call Reference/Length" cell "2-*" to "2-

3".

Section 3.1.13 STATUS

Table 14 — STATUS message content

Change the "Cause/Length" cell from "4-32" to "4- 10".

Section 3.1.13 STATUS

Table 14 — STATUS message content

Delete "Display" row.

Section 3.1.13 STATUS

Table 14 — STATUS message content

Delete Notes 1, 2.

Section 3.1.14 STATUS ENQUIRY

Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Change "This message is sent by the user or the network at any time to solicit a STATUS message

from the peer layer 3 entity." to "This message is sent by the network during the active state to solicit a STATUS message from the peer layer 3 entity."

Change "Direction" in the table header from "both" to "n -> u".

Change the "Direction" cell in the following rows

from "both" to "n -> u":

• "Protocol discriminator";

• "Call reference";

• "Message type".

A- 10 NIU-Forum Agreements on ISDN
Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Change "Call Reference/Length" cell from "2-*" to "2-3".

Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.2 Messages used with the global call reference

Section 4.2 Protocol Discriminator

Section 4.2 Protocol Discriminator

Figure 2 — Protocol Discriminator

Section 4.2 Protocol Discriminator

Table 19 — Protocol Discriminator

Section 4.3 Call Reference

Section 4.3 Call Reference

Section 4.3 Call Reference

Section 4.3 Call Reference

Section 4.3 Call Reference

Section 4.4 Message Type

Table 20 — Message types

Delete "Display" row.

Delete Notes 1, 2.

Delete this section including subsections.

Add the following paragraph after the second

paragraph. "The only value supported for call control messages is described below, in Figure 2."

Change "ANSI T1.607" to "Q.931".

Change "ANSI T1.607" to "Q.931" in the row labeled "0000 1000".

Change the first sentence of the third paragraph from

"... for a basic user-network interface, and a call reference value of two octets for a primary rate interface." to "and a maximum of 2. The network

will send one octet call reference value (CRV) unless

all 127 available codepoints are occupied."

Delete the fourth paragraph "As a network option ... one or two octets."

Add "The Dummy Call Reference and the Global Call Reference are not supported for BRI/Class I circuit- switched calls." after figure 5.

Delete the last sentence from the eighth paragraph

"The call reference ... (e.g., Restart procedures)."

Delete Note 2 ("The numerical value ... defined in 3.2.").

Add an asterisk (*) to the beginning of the "NOTIFY"

row.

NIU-Forum Agreements On ISDN A-ll
Section 4.4 Message Type

Table 20 — Message Types

Section 4.5.1 Coding Rules

Section 4.5.1 Coding Rules

Figure 7 — Formats of information elements

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Add as a footnote "* See section 5.8.4 for treatment of this message type."

Delete the last 3 sentences of the fourth paragraph

"Two types of ... octet elements."

Delete Figure 7 (b). Single octet information element

format (type 2).

Delete "Repeat Indicator" row.

Delete reference to Note 6 in row "Bearer capability".

Change the "Bearer capability/max length" cell from

"13" to "8".

Change the "Cause/max length" cell from "32" to "10".

Change the "Cause/max. no. of occurrences" cell from

"3" to "2".

Change the "Channel identification/max length" cell from "(Note 4)" to "3".

Delete the following rows:

• "Network-specific facilities";

• "Notification indicator";

• "Display";

• "Connected number";

• "Connected subaddress".

Change the "Calling Party Number/max length" cell from "(Note 4)" to "19".

Change the "Called Party Number/max length" cell "(Note 4)" to "18".

A-12 NIU-Forum Agreements on ISDN
Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1 Coding Rules

Table 21 — Information element identifier coding

Delete reference to Note 2 in the "Transit Network

selection" row.

Change the "Transit Network selection/max length"

cell from "(Note 4)" to "7".

Delete "4" from the "Transit Network Selection/max.

no. of occurrences" cell.

Delete the following rows:

• "Restart indicator" and

• "Escape for extension".

Delete Notes 3, 4, and 6.

Section 4.5.1 Coding Rules

Figure 8 — Information element format using escape

for extension

Delete this figure.

Section 4.5.2 Extensions of codesets

Change "T1.608" to "NIU 89-320" in the first bullet

in the fourth paragraph.

Section 4.5.2 Extensions of codesets

Change the ninth paragraph to: "Codeset 7

information elements shall be handled according to the procedures for unrecognized information elements

(see 5.8.7.1) by the first exchange."

Section 4.5.2 Extensions of codesets

Section 4.5.3 Locking shift procedure

New codeset identification coding

Section 4.5.4 Non-locking shift procedures

Section 4.5.4 Non-locking shift procedures

Temporary codeset identification coding

Section 4.5.4 Non-locking shift procedures

Temporary codeset identification coding

Delete the tenth paragraph ("Codeset 6 ... bilateral agreements.").

Change "T1.608" to "NIU 89-320" in row "codeset

5".

Delete "(a) process the non-locking ... below." from

the second paragraph.

Change "T1.607" to "NIU 90-301" in row "codeset

0".

Change "T1.608" to "NIU 89-320" in row "codeset

5".

NIU-Forum Agreements On ISDN A-13
Section 4.5.5 Bearer capability

Section 4.5.5 Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer capability

Section 4.5.5 Bearer capability

Information transfer capability (octet 3) coding

Section 4.5.5 Bearer capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5 Bearer capability

Information transfer rate (octet 4) coding

Section 4.5.5 Bearer capability

Information transfer rate (octet 4) coding

In the second paragraph change "13 octets" to "8

octets".

Change octet 4, bit 8 from "0/1" to "1".

Delete octets

• 4a*;

• 4b*;

• 5b* Note 2;

• 5b* Note 3;

• 5c*;

• 5d*.

Change octet 5a*, bit 8 from "0/1" to "1".

Delete Notes 1, 2, and 3.

Delete "or V.120" from the end of Note 4.

Add the following after Figure 11: "Octets 6 and 7

are included for information only and shall not be

used for circuit-switched calls. The coding and

application for these octets are included in another

document."

Delete row "10001 7 kHz audio".

Change the title to "Information transfer rate (octet

4)".

Delete the following rows:

• "10011 384kbit/s";

• "10100 1472 kbit/s (see Note 2)";

• "10101 1536 kbit/s".

Change Note 1 to: "The bearer capability is bidirectional symmetric at the information transfer

rate specified in octet 4."

A- 14 NIU-Forum Agreements on ISDN
Section 4.5.5 Bearer capability

Information transfer rate (octet 4) coding

Section 4.5.5 Bearer capability

Section 4.5.5 Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5 Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5 Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5 Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5 Bearer capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5 Bearer capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5 Bearer capability

Negotiation (octet 5a) coding

Section 4.5.5 Bearer capability

User rate (octet 5a) coding

Section 4.5.5 Bearer capability

Section 4.5.5 Bearer capability

Section 4.5.6 Call state Global interface state value (octet 3) coding

Delete Note 2.

Delete the codings of octets 4a (structure, configuration, establishment) and 4b (symmetry).

Delete "and optionally octets 5b, 5c, and 5d as defined below." from row "00001".

Delete "and G.725 7 kHz audio" from row "00101".

Delete rows "00111" and "01000".

Delete Note 2.

Delete row "1 asynchronous".

Delete the second and third sentences from the Note.

Delete row "1 In-band negotiation possible".

Delete all code points except "01111 56 kbit/s CCrTT Recommendation V.6."

Delete all text relating to octet 5b (i.e., sections labeled "Octet 5b for CCITT Recommendation V. 100

or X.30 rate adaption" and "Octet 5b for CCITT

Recommendation V.120 rate adaption").

Delete all tables and text referring to octets 5c

(number of data bits excluding parity bit, parity

information) and 5d (duplex mode, modem type).

Delete this coding.

NIU-Forum Agreements On ISDN A-15
Section 4.5.7 Called party number

Section 4.5.7 Called party number

Type of number (octet 3) coding

Section 4.5.7 Called party number

Section 4.5.7 Called party number

Numbering plan identification (octet 3) coding

Change the second paragraph to: "The maximum

length of this information element is 18 octets."

Delete the following rows:

• "Oil network specific number (see Note 4)" and

• "111 reserved for extension".

Delete Note 4.

Delete the following rows: "0011 Data numbering plan (CCITT

Recommendation X.121)";

"0100 Telex numbering plan (CCITT

Recommendation F.69)";

• "1111 Reserved for extension"

.

Section 4.5.7 Called party number

Section 4.5.9 Calling party number

Add Attachment B of this document after the following:

"Number digits (octets 4, etc.) This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering and dialing plan."

Change the second paragraph from: "The maximum

length of this information element is network

dependent." to "The maximum length of this information element is 19 octets."

Section 4.5.9 Calling party number

Type of number (octet 3) coding

Section 4.5.9 Calling party number

Type of number (octet 3) coding

Section 4.5.9 Calling party number

Numbering plan identification (octet 3) coding

Delete the following rows:

• "011 network specific number (see Note 4)" and

• "111 reserved for extension".

Delete Note 4.

Delete the following rows: "0100 Telex numbering

Recommendation F.69)" and

• "1111 Reserved for extension".

plan (CCITT

Section 4.5.9 Add Attachment C of this document after the Calling party number following:

"Number digits (octets 4, etc.) This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering or dialing plan."

A-16 NIU-Forum Agreements on ISDN
Section 4.5.10

Calling party subaddress

Section 4.5.11 Cause

Section 4.5.11 Cause

Figure 17 — Cause information element

Section 4.5.11 Cause

Figure 17 — Cause information element

Section 4.5.11 Cause

Figure 17 — Cause information element

Section 4.5.11 Cause

Recommendation (octet 3a) coding

Section 4.5.11 Cause

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Add a new paragraph at the end of the section: "In the network to user direction (n —> u), the coding

and delivery of this IE depends on the definition of

the Calling Line ID service."

Change the second sentence of the first paragraph

from "The maximum length of this information

element is 32 octets." to "The maximum length of this information element is 10 octets."

Change octet 3, bit 8 from "0/1" to "1".

Delete octet 3a*.

Delete the Note.

Delete this coding and its associated Notes 1 and 2.

Add the following sentence to the end of the paragraph under "Diagnostics (octet 5)": "If more

than one IE is identified in a diagnostic, they should

be ordered as IE's normally appear in a message."

Change the "diagnostics" cell of the first three code

points to "Not used".

Change the "Normal call clearing/diagnostics" cell from "(see Note 12)" to "Not used".

Add to the "User busy/diagnostics" cell: "(see Note

10)"

Change the "call rejected/diagnostics" cell from "(see

Note 12, user supplied diagnostic) (see Note 4)" to "Not used".

Delete row "Number changed".

NIU-Forum Agreements On ISDN A-17
Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Add "(see Note 10)" to the "Network out of

order/diagnostics" cell.

Add "(see Note 10)" to the "Requested circuit or channel not available/diagnostics" cell.

Delete row "Quality of service unavailable".

Change the "Requested facility not subscribed/

diagnostics" cell from "Facility identification (see

Note 1)" to "Not used".

Change the "Bearer capability not authorized/

diagnostics" cell from "(see Note 3)" to "Not used".

Delete row "Bearer capability not presently available".

Delete row "Service or option not available,

unspecified".

Change the "Bearer capability not implemented/

diagnostics" cell from "(see Note 3)" to "Not used".

Delete row "Channel type not implemented".

Change the "requested facility no implemented/

diagnostics" cell from "Facility identification (see

Note 1)" to "Not used".

Delete rows "Only restricted digital information

bearer capability is available" and "Service or option not implemented, unspecified".

Delete row "Identified channel does not exist".

Change the "incompatible destination/diagnostics" cell from "Incompatible parameter (see Note 2)" to "Not

used".

A-18 NIU-Forum Agreements on ISDN
Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Figure 18 —Coding of the diagnostic field for causes

57, 58 and 65

Section 4.5.12 Channel identification Figure 19 — Channel

element

Section 4.5.12 Channel identification Figure 19 — Channel identification information

element

Section 4.5.12 Channel identification Interface identifier present (octet 3) coding

Section 4.5.12 Channel identification Interface identifier present (octet 3) coding

Section 4.5.12 Channel identification Interface type (octet 3) coding

Section 4.5.12 Channel identification Interface type (octet 3) coding

Section 4.5.12 Channel identification Information channel selection (octet 3) coding

Section 4.5.12 Channel identification

Delete row "Invalid message, unspecified".

Change the "Recovery on timer expiry/diagnostics"

cell from "Timer number (see Note 9)" to "Not used".

Delete Notes 2, 3, 4, 5, 7, 9, 11, 12.

Delete Figure 18 and text for octets 5, 5a, and 5b.

Delete Notes 1, 2, 3, 4.

Delete row "1 Interface explicitly ... with octet 3.1."

Delete the Note and the reference to it in row "0

Interface implicitly identified".

Delete row "1 other interface: ... (see Note)".

Add the following after Note 3: "4 The combination

of 'Any Channel' (bits 1,2), and 'Exclusive' (bit 4) is invalid."

Delete the text, codings, and figures relating to octets

3.1, 3.2, and 3.3.

Delete the octets 3.1, 3.2, and 3.3.

identification information

Delete the Note.

NIU-Forum Agreements On ISDN A-19
Section 4.5.13 Connected Number

Delete this section.

Section 4.5.14 Connected subaddress

Section 4.5.15 Display

Section 4.5.16 High layer compatibility

Section 4.5.18 Low layer compatibility

Section 4.5.18 Low layer compatibility

Negotiation indicator (octet 3a) coding

Section 4.5.18 Low layer compatibility

Negotiation indicator (octet 3a) coding

Section 4.5.18 Low Layer compatibility

User information layer 3 protocol (octet 7) coding

Section 4.5.19 Network-specific facilities

Section 4.5.20

Notification Indicator

Section 4.5.21 Progress indicator Progress description (octet 4) coding

Section 4.5.21 Progress indicator Progress description (octet 4) coding

Section 4.5.22 Repeat indicator

Section 4.5.23

Restart indicator

Delete this section.

Delete this section.

Change the second paragraph from "The maximum

length of this information element is four octets." to "The maximum length of this information element is five octets."

Delete the second paragraph.

Delete row "1 Out-band negotiation possible".

Delete Note 1.

Change "ANSI T1.607" to "NTU 90-301" in row

"00010".

Delete this section.

Delete this section.

Delete row "000 0100 4 call has returned to the ISDN."

Add the following after Note 2: "3 In the SETUP

message, n -> u, one of two values may be used: 1 or

3."

Delete this section.

Delete this section.

A-20 NIU-Forum Agreements on ISDN
Section 4.5.24

Signal

Figure 32 — Signal information element

Section 4.5.24

Signal

Signal value (octet 3) coding

Section 4.5.25

Transit network selection

Section 4.5.25

Transit network selection

Section 4.5.25

Transit network selection Type of network identification (octet 3) coding

Section 4.5.25

Transit network selection Network identification plan (octet 3) coding

Section 4.5.26 User-user

Section 4.5.26 User-user

Protocol discriminator (octet 3) coding

Section 4.6.1 Operator system access type of access (octet 3) coding

Section 5

Circuit-switched call control procedures

Section 5

Circuit-switched call control procedures

Section 5.1 Call establishment at the originating interface

Add below the figure: "Note In the n -> u direction,

and in the absence of supplementary services, the public network will offer signalling pattern 0 only."

Delete the following rows:

• "intercept tone on";

• "answer tone on";

• "off hook warning tone on";

• "ALERTING on — pattern 5";

• "ALERTING on — pattern 6";

• "ALERTING on — pattern 7".

Change the second sentence of the first paragraph to: "The transit network selection information element

should not be repeated in a message (See Annex C)."

Change the second paragraph to: "The default maximum length of mis information element is 7

octets."

Delete row "Oil international network identification".

Delete row "0011 Data network identification code

(CCITT Recommendation X.121)".

Add the following sentence to the end of the Note

(after the second paragraph): "This IE is included

based on user-user supplementary service description

and user application."

Change "ANSI T1.607" to "NTU 90-301" in row

"0000 1000".

Delete row "10 private/principal".

Delete the fourth paragraph ("As a general principle,

...").

Delete the last sentence of second Note ("Display

information ... network to user.").

Change "ANSI T1.602" to "NTU 89-210" in the last sentence of the first paragraph.

NIU-Forum Agreements On ISDN A-21
Section 5.1.3 Overlap sending

Add the following at the end of section 5.1.3: "However, as an option, the network can determine

that a potentially complete code has been received

following the receipt of address information, and the network could use critical interdigit timing (instead of

T302) to determine whether additional digits are

following. This timing could be 3-5 seconds. If implemented, when this timer expires, a complete

address is assumed and the procedures in Sec. 5.1.5.2

shall be followed. In an INFORMATION message is received and the critical interdigit timing is running,

it shall be stopped."

Section 5.1.4 Invalid call information

Delete the following line from the last paragraph:

"22 'number changed';".

Section 5.1.4 Invalid call information

Add the following two paragraphs to the end of

section 5.1.4: "The network should reject the call request if the SETUP message contains the keypad information

element, and any of the following information

elements: transit network selection, called party

number, or operator system access. In this case, the network should send the calling user equipment a RELEASE COMPLETE message containing cause 28,

'invalid number format (location: public network

serving the local user).'".

"If the network receives a called party number

information element containing more address digits

than expected, as determined by the 'type of number

and numbering plan identification' field, the network

should discard the superfluous digits and route the

call. Similarly, if the transit network selection information element contains more address digits than

expected, as determined by the 'type of network

identification' and 'network identification plan' fields, the network should discard the superfluous digits and

route the call. If the network receives a keypad

information element containing more address digits

than required for completion of digit analysis, the network should discard the superfluous digits

(according to the network dialing plan) and route the

call. If any of these events occur, the local public

network should send the calling user equipment a STATUS message containing National-specific cause

11, 'More digits received than allowed: call is proceeding (location: public network serving the local

user' and the call state information element coded as

call state 1, 'call initiated.' Private networks may

support this procedure, optionally."

A-22 NIU-Forum Agreements on ISDN
Section 5.1.5.1 Call proceeding, en-bloc sending

Delete causes "58 'bearer capability not presently

available';" and "63 'service or option not available,

unspecified';" from the second paragraph.

Section 5.1.5.1 Call proceeding, en-block sending

Section 5.1.5.2 Call proceeding, overlap sending

Section 5.1.5.2 Call proceeding, overlap sending

Section 5.1.5.2 Call proceeding, overlap sending

Add to the second paragraph after "57

"34 'no circuit or channel available';".

authorized":

Delete "58 ...available" and "63 ... unspecified" from

the first paragraph.

Add after "57 ... not authorized": "34 'no circuit or channel available';" in the first paragraph.

Add the following at the end of section 5.1.5.2:

"Other Misdialing Treatments

The Network should be capable of recognizing several types of misdialing. If network-provided tones and

announcements do not apply, the network should

initiate call clearing in response to a misdialing error. If en-bloc sending has been used, the network should

send a RELEASE COMPLETE message to the calling user equipment. If overlap sending has been used, the network should send a DISCONNECT message to the

calling user equipment. The initial clearing message

should contain the appropriate cause information, as

indicated below, and the signal information 'reorder tone on.' If tones and announcements apply, see

section 5.3.4.1. — Vacant code: National-specific cause 4, 'vacant code.'

Section 5.1.6 Notification of interworking at the originating

interface

Section 5.1.6 Notification of interworking at the originating

interface

— Prefix 0 dialed in error: National-specific cause 8, 'prefix 0 dialed in error.' — Prefix 1 dialed in error: National-specific cause 9 'prefix 1 dialed in error.' — Prefix 1 not dialed: National-specific cause 10, 'prefix 1 not dialed.'"

Change (a) in the first paragraph to: "In an

appropriate call control message when a state change

is required (i.e., CONNECT); or,".

Delete from the second paragraph the progress

description value "4 'call has returned to the ISDN'.

Call is now end-to-end and ISDN."

NIU-Forum Agreements On ISDN A-23
Section 5.1.7 Call confirmation indication

Section 5.2 Call establishment at the destination interface

Section 5.2 Call establishment at the destination interface

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Section 5.2.2 Compatibility checking

Section 5.2.3.1 SETUP message delivered by point-to-point data link

Section 5.2.3.2 SETUP message delivered by broadcast data link

Section 5.2.5.1 Response to en-block SETUP

Section 5.2.5.1 Response to en-block SETUP

Section 5.2.5.1 Response to en-block SETUP

Section 5.2.5.3 Called user clearing during incoming call establishment

Change the last sentence of the first paragraph to: "When the user receives the ALERTING message, the user shall enter the Call Delivered state."

Change "ANSI standard T1.602" to "NIU 89-210" in the first sentence of the first paragraph.

Delete the third paragraph ("The SETUP message

offered ... of the data link layer.").

Delete "Display," from the second paragraph "(e.g., Display, Low layer compatibility)."

Add the following to the end of second paragraph.

"In general, a call terminating from a non-ISDN line or from a Public Switched Telephone Network

(PSTN) trunk should be offered to the called user equipment with the 3.1. kHz audio bearer capability."

Change "(e.g., for DDI)" to "(e.g., 7 digits)" in the second sentence of the third paragraph.

Delete the third sentence from the third paragraph.

Delete the third paragraph.

Delete this section.

Combine the first and second sentences of the first paragraph to: "When the SETUP message is delivered by a broadcast data link, the network sends a SETUP message with the Channel identification information element indicating a specific channel with no alternative acceptable."

Delete "(see Note)" from the first sentence of the first paragraph.

Delete the Note after the first paragraph.

Delete the third paragraph ("When the SETUP

message was delivered via a point-to-point data link

...").

Delete the first paragraph.

A-24 NIU-Forum Agreements on ISDN
Section 5.2.5.3 Called user clearing during incoming call establishment

Change the second sentence of the second paragraph

to: "If timer T303 expires (i.e., if no valid message

such as CALL PROCEEDING, ALERTING, or CONNECT has been received), the network shall take

action as follows:

a. If all clearing messages received from the called user equipment contain cause 88,

'incompatible destination,' the call should be

cleared at the calling ISDN interface with cause 18, 'no user responding (location:

public network serving the remote user)' and

signal 'ring-back/audible ringing tone on.'

b. If one or more call clearing messages

with cause 17, 'user busy,' have been

received from the called user equipment, the

call should be cleared at the calling ISDN

interface with cause 17, 'user busy (location:

user).' The signal information should be

coded as 'busy tone on' unless an audible

ringing tone was indicated because timer T

delay (if implemented) previously expired

(see sec. 5.2.1). If audible ringing is being

provided, the signal information should be

coded as 'ring-back/audible ringing tone on.'

c. If no call clearing messages with cause

17 have been received from the called user equipment and at least one call clearing

message with a cause other than 88 has been

received, the call should be cleared at the

calling ISDN interface with cause 21, 'call rejected (location: user),' and signal 'ringback/audible ringing tone on.'".

Section 5.2.5.3 Delete the last sentence from the second paragraph:

Called user clearing during incoming call "When multiple RELEASE COMPLETE ... sent to establishment the originating user (see 5.3)."

Section 5.2.5.3.1 DISCONNECT received prior to expiry of T312Change the second sentence in the second paragraph

from "If an ALERTING message has been received,

... any other cause sent by a called user." to "If an ALERTING message has been received, the cause

sent to the calling user shall be 21 'call rejected'

(location: user)."

NIU-Forum Agreements On ISDN A-25
Section 5.2.5.3.1 DISCONNECT received prior to expiry of T312

Change the third sentence in the second paragraph

from "In only CALL PROCEEDING ... sent by a

called user." to "If only CALL PROCEEDING

messages have been received from called users, the cause sent to the calling user shall be as in 5.2.5.3."

Section 5.2.5.3.2 DISCONNECT received after expiry of timer T312

Change the second sentence in the third paragraph

from "If an ALERTING message has been received,

... any other cause sent by a called user." to "If an ALERTING message has been received, the cause

sent to the calling user shall be 21 'call rejected'

(location: user)."

Section 5.2.5.3.2 DISCONNECT received after to expiry of T312

Change the third sentence in the third paragraph from

"If only CALL PROCEEDING ... by a called user" to

"If only CALL PROCEEDING messages have been

received, the cause sent to the calling user shall be as

in 5.2.5.3."

Section 5.2.5.4 Call failure

Delete all occurrences of "(b) ..." (paragraphs 1, 3, 4)

from this section.

Section 5.2.6 Notification of

interface

interworking at the terminating

Delete this section.

Section 5.2.7 Call accept

Section 5.2.8 Active indication

Add to the end of the second paragraph: "If the CONNECT message is the first response to the SETUP message, it shall contain the channel ID

information element."

Delete the last paragraph of section 5.2.8 ("A user which has ... has been completed").

A-26 NIU-Forum Agreements on ISDN
Section 5.3.2 Exception conditions

Add the following before the Note that appears at the end of this section. — In the case of a SETUP message sent to the user via the broadcast data link, if a

called user terminal sends a first response to the SETUP message after timer T303 has expired (the first expiration of T303 is the SETUP message should not be retransmitted,

and the second expiration of T303 if the SETUP message should be retransmitted —

note that the SETUP message is retransmitted only when no response is received prior to the first expiry of T303,

e.g., the SETUP message should not be

retransmitted when a call clearing message(s)

is received prior to the first expiry of T303),

but before timer T312 expires, the network

should clear the call to that user by sending a RELEASE message. This message

should contain cause 102, 'recovery on timer

expiry' (location: public network serving the

local user.). — In the case of call offering via the broadcast data link, if either timer T310 or T301 expires at the called user interface, the network should initiate call clearing by

sending a RELEASE message to all called user equipment responding to the SETUP

message sent by the network. The

RELEASE message(s) should contain cause

102, 'recovery on timer expiry' (location:

public network serving the local user). — If a call attempt is unsuccessful and a

speech, 3.1 kHz audio call will not be

immediately cleared because inband tones or announcements are being provided, the network should send the calling user a PROGRESS message containing progress message containing progress indicator 8, 'inband information or appropriate pattern now available.'."

Section 5.3.3 Clearing initiated by the user

Delete the last Note in this section.

NIU-Forum Agreements On ISDN A-27
Section 5.3.4.1 Clearing when tones or announcements provided

Add the following at the end of section 5.3.4.1: "To return an inband tone for an unsuccessful speech,

3.1. kHz audio the network should send a PROGRESS message and start a tone timer (value to be specified by network provider) in anticipation of

the user initiating the clearing process. The

PROGRESS message should contain the cause value

indicated in the detailed procedures of Section 5.3, along with progress indicator 8, 'inband information

or appropriate pattern now available.' If the tone timer expires, the network should initiate call clearing

by sending the calling user a DISCONNECT message

containing cause 102, 'recovery on timer expiry.'

The network should then continue clearing the connection to the calling user equipment according to the procedures for sending a DISCONNECT message.

The procedures described above also apply for returning an inband announcement for an unsuccessful

speech, 3.1 kHz audio call, with the exception that the tone timer is not used. Inband announcements should

not be timed; however, it is desirable that the network

Delete an inband announcement after one or two

message cycles, depending on the number specified

by the network provider. In removing the inband

announcement, the network should follow the above

procedures for expiration of the tone timer."

Section 5.3.4.3 Completion of clearing

Delete the last Note at the end of section 5.3.4.3.

Section 5.5 Restart procedure

Delete this section including all subsections.

Section 5.8 Handling of error conditionsChange "T1.607" to "Q.931" in the first sentence of

the first paragraph.

Section 5.8.1 Protocol discrimination error Change "T1.607" to "Q.931" in the first sentence in the first paragraph.

Section 5.8.3.1 Invalid call reference format

Change the second paragraph to: "If the Call reference information element octet 1, bits 1 through

4 indicates a length greater than the maximum length

supported by the receiving equipment (see 4.3), or the Null call reference, or the global call reference is used

to identify a call, then the message shall be ignored."

Section 5.8.3.2 Call reference procedural errors

Delete item "(f) When any message

returned."

shall be

A-28 NIU-Forum Agreements on ISDN
Section 5.8.4 Message type or message sequence errors

Section 5.8.4 Message type or message sequence errors

Section 5.8.4 Message type or message sequence errors

Section 5.8.6.1 Mandatory information element missing

Section 5.8.6.1 Mandatory information element missing

Add as a new paragraph "A NOTIFY message may

also be ignored by the recipient." after the first paragraph (i.e., after the list of cause values).

Change the fourth sentence in the second paragraph

to: "Whenever the network receives an unexpected

RELEASE message, the network shall: disconnect and

release the B-channel; clear the network connection

and the call to the remote user with cause as specified

in 5.2.5.3, or cause in the RELEASE message sent by

the user. If no cause is included, cause 31 'normal,

unspecified' or other causes as specified in 5.8.6.1; return a RELEASE COMPLETE message to the user; release the call reference; stop all timers; and enter the Null state."

Change the second sentence of the third paragraph to: "Whenever the network receives an unexpected

RELEASE COMPLETE message, the network shall: disconnect and release the B-channel; clear the network connection and the call to the remote user with the cause indicated by the user or, if not

included, cause 111 'protocol error, unspecified' or other causes as specified in 5.8.6.1; release the call reference; stop all timers; and enter the Null state."

Change the beginning of the first sentence in the third paragraph to: "When a DISCONNECT message (first clearing message) is received with

Add the following as a new paragraph after the third paragraph: "As an option the network shall follow

the following procedure. The DISCONNECT

message sent to the network should contain cause

information. If the network receives an initial clearing message without a cause information

element, it should accept the message, disconnect the associated channel, and initiate procedures to clear the network connection and the call to the remote user.

If the call is active or if the originating user cleared

the call while in the setup phase, the network should

send cause 16, 'normal clearing (location: user)' to the remote user. It should send cause 21, 'call rejected (location: user)' if the terminating user cleared the call while in the setup phase. The

network should respond to the user initiating call clearing by sending a RELEASE message containing cause 96, 'mandatory information element is missing

(location: public network serving the local user; diagnostic: cause information element identifier).'".

NIU-Forum Agreements On ISDN A-29
Section 5.8.6.2 Mandatory information element content error Change the third paragraph to: "When a DISCONNECT message is received with invalid content of the Cause information element, the action

taken shall be the same as if a DISCONNECT

message with the cause missing was received with the exception that the RELEASE message sent on the

local interface contains cause 100 'invalid information

element contents'."

Section 5.8.7.1 Unrecognized information elements

Add the following to the Note after the first paragraph: "or not implemented by the receiver in a

specific message."

Section 5.8.8 Data-link reset Change "ANSI T1.607" to "NIU 90-301" in the first sentence of the first paragraph.

Section 5.8.9 Data-link failure Change "ANSI T1.607" to "NIU 90-301" in the first sentence of the first paragraph.

Section 5.8.9 Data-link failure Change both occurrences of "ANSI T1.607" in the

first paragraph bullet b) to "NIU 90-301".

Section 5.8.9 Data-link failure Change the first Note after the first paragraph to: "If the transfer mode of the call is circuit-mode, the NIU

90-301 entity may clear the calls."

Section 5.8.10

Status enquiry procedure

Delete the first paragraph.

Section 5.8.11 Receiving a STATUS message

Delete "As an option:" from the second sentence of

the third paragraph ("The determination ...").

Section 5.8.11 Receiving a STATUS messageChange "a)" in the third paragraph to: "If a STATUS

message indicating any call state except the Null state

is received in the Null state, then the receiving entity

shall send a RELEASE COMPLETE message with a

cause 101 'message not compatible with call state' or cause 81 'Invalid Call reference value' and remain in the Null state. Otherwise, no action shall be taken on

receipt of STATUS unless it is in response to STATUS ENQUIRY."

Section 5.8.11 Receiving a STATUS messageDelete "b) If a ..." and "c) If a STATUS message,

indicating the Null ... into the Null state." after the

third paragraph.

Section 5.8.11 Receiving a STATUS message

Delete the last three paragraphs and the last Note in

this section.

Section 5.9 User notification procedure

Delete this section.

A-30 NIU-Forum Agreements on ISDN
Section 6

Packet communication procedures

Change sentence to "See NIU 89-320".

Change the "T302/Default time out value" cell from

"10-15 s" to "16-24 s".

Change the "T302/cause for start" cell from "SETUP

ACKNOWLEDGE sent. Receipt of INFORMATION

restarts T302." to "SETUP ACKNOWLEDGE sent. Receipt of INFORMATION not containing complete

address information restarts T302."

Change the "T302/NORMAL STOP" cell to: "With

sending complete indication, or potentially complete

address information received, as an option, the network can determine that a potentially complete

code has been received following the receipt of

address information, and the network could use

critical interdigit timing (instead of T302) to determine whether additional digits are following.

This timing could be 3-5 seconds. If implemented,

when this timer expires, a complete address is assumed and the procedures in Sec. 5.1.5.2 shall be

followed. In an INFORMATION message is received

and the critical interdigit timing is running, it shall be

stopped."

Section 9.1 Add the following row entry for Timer "Tpot_comp"

Timers in the network side after row "T302":

Table 22 — Timers in the network side

TIMER

NUMBER

DEFAULT

TIME

OUT

VALUE

STATE

OF

CALL

CAUSES

FOR

START

NORMAL STOP AT THE

FIRST

EXPIRY

AT THE

SECOND

EXPIRY

CROSS

REFERENCE

Tpot_comp 3-5 s Overlap

Sending

Potentially

complete

address

information

received

INFORMATION

received

Route

call Timernot

restarted

*

"* optional — as an option, the network can determine that a potentially complete code has been received following the receipt of address information, and the network could use critical interdigit timing (instead of T302) to determine whether additional digits are following. This timing could be 3-5 seconds. If implemented, when this timer expires, a complete address is assumed and the procedures in Sec. 5.1.5.2 shall be followed. In an INFORMATION message is received and the critical interdigit timing is running,

it shall be stopped."

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

NIU-Forum Agreements On ISDN A-31
Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side

Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side

Table 22 — Timers in the network side

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Change the "T303/DEFAULT TIME OUT VALUE"

cell from "4s" to "2.5s".

Change the "T303/NORMAL STOP" cell to "ALERT,

CONNECT, or CALL PROCEEDING received".

Change the "T303/AT THE FIRST EXPIRY" cell to "Retransmit SETUP; re-start T303."

Delete "Note 7" from the "T308/AT SECOND

EXPIRY" cell.

Change "10s" to "5s" in the "T3 10/DEFAULT TIME

OUT VALUE" cell.

Delete "Note 6" from the "T3 10/DEFAULT TIME

OUT VALUE" cell.

Delete the following rows: "T316", "T317", "T321".

Delete the following Notes: 3, 6, 7 at the end of

Table 22.

Change the "T301/CROSS REFERENCE" cell to "Note 3".

Change the "T303/NORMAL STOP" cell to "SETUP

ACKNOWLEDGE, CALL PROCEEDING or RELEASE COMPLETE received".

Delete "(annex D)" from the "T303/AT THE FIRST

EXPIRY" cell.

Change the "T303/CROSS REFERENCE" cell to "optional".

Delete "Note 5" from the "T308/AT THE SECOND

EXPIRY" cell.

A-32 NIU-Forum Agreements on ISDN
Section 9.2 Timers in the user side Table 23 — Timers in the user side

Delete rows "T310", "T316", "T317", "T321".

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Delete Notes 2 and 5 that appear at the end of table

7.

Annex A Delete this section. NOTE: This section has not been addressed.

Annex B, Section B.3.1 Compatibility checking with addressing information

Annex B, Section B.3.2

Network to user compatibility

Change the second sentence under "a)" to: "In the case of a mismatch, the user shall either ignore or

reject the call."

Change the last sentence in this section to: "If a mismatch is detected, then the user shall either ignore or reject the offered call using cause 88 'incompatible

destination'."

Annex B, Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 — Low layer and high layer compatibility

checking; compatibility assured

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4 User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 — Low layer and high layer compatibility

checking; compatibility assured

Annex B, Section B.3.4

User action figures

Figure B.2 —Low layer and high layer compatibility

checking; compatibility assured

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 —Low layer and high layer compatibility

checking; compatibility assured

Figure B.3 —Low layer and high layer compatibility

checking; compatibility not assured

Delete the "point-to-point data link" columns.

Change the "Incompatible/Broadcast data link" cell from "Reject" to "Ignore or Reject".

Delete "Note 3" from the "Incompatible/broadcast

data link" column.

Delete the reference to "Note 1" from the last column.

NIU-Forum Agreements On ISDN A-33
Annex B, Section B.3.4

User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4 User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex C, Section C.l

Introduction

Annex C, Section C.2

Selection not supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex D

Extension for symmetric call operation

Annex E

Network-specific facility selection

Annex F

D-channel backup procedure

A-34

Change "Accept or Reject" to "Accept, Ignore, or Reject" in the Broadcast Data Link column.

Delete Note 1 below figure B.3.

Change "will reject the call if incompatible" to "may

reject the call if incompatible" in Note 2 below figure B.3.

Delete Note 3 ("Attempt low layer compatibility

negotiation (see Annex M).") below Figure B.3.

Delete "optional" from the first paragraph.

Delete this section.

Change the first sentence of the first paragraph to: "The user identifies the selected transit network in the SETUP message."

Delete the second and third paragraphs.

Delete the first sentence of the fourth paragraph.

Delete the last sentence in the sixth paragraph.

Delete the seventh, eighth, and ninth paragraphs.

Delete this section.

Delete this section.

Delete this section.

NIU-Forum Agreements on ISDN
Annex G, Section G.l

Introduction

Add the following at the end of the first paragraph:

"Section 4.5.1 1 identifies the causes supported in NIU

90-301."

Annex G

Cause Definitions

Delete the following sections:

• Section G.2.16 Cause 22 "number changed"

• Section G.3.2 Cause 38 "network out of order"

• Section G.3.7 Cause 45 "preemption"

• Section G.3.8 Cause 46 "precedence call blocked"

• Section G.3.9 Cause 47 "resource unavailable,

unspecified"

• Section G.4.1 Cause 49 "quality of service unavailable"

• Section G.4.4 Cause 58 "bearer capability no

presently available"

• Section G.4.5 Cause 63 "service or option not

available, unspecified"

• Section G.5.2 Cause 66 "channel type not implemented"

• Section G.5.4 Cause 70 "only restricted digital

information bearer capability is available"

• Section G.5.5 Cause 79 "service or option not implemented, unspecified"

• Section G.6.2 Cause 82 "identified channel does

not exist"

• Section G.6.4 Cause 91 "invalid transit network

selection"

• Section G.6.5 Cause 95 "invalid message,

unspecified"

Annex H

Examples of Information elements coding

Annex H, Section H.l

Introduction

Change the status of this section from "informative"

to "normative".

Replace the first and second paragraphs with the following: "These are the only recognized codings of

the following Information Elements for circuit-mode

services: — Bearer capability information element — Channel identification information element".

Annex H

Examples of information elements coding

Delete the following figures and sections:

• Figure "H.3 Coding for 7 kHz Audio"

• Figure "H.6 Coding for synchronous 1472 kbit/s";

• sections H.3.2 (Figures H.9, H.10, H.11);

• H.3.3 (Figures H.12 through H.17);

• H.4 (Figures H.18 through H.21);

Annex H, Section H.3.1

Basic Interface, circuit mode, B-channel

Add Attachment D of this document.

NIU-Forum Agreements On ISDN A-35
Annex I Use of Progress Indicators

Annex I Use of progress indicators

Annex I Use of Progress Indicators

Annex I Use of Progress Indicators

Annex J Examples of Cause Values and location for busy

condition

Annex L

low layer information coding principles

Annex M

Low layer compatibility Negotiation

Annex N

Procedures for establishment of bearer connection

prior to call acceptance

Annex O

Optional procedures for bearer service change

Annex P, Section P.l Introduction

Annex P, Section P.l Introduction

Annex P, Section P.l

Introduction

Annex P, Section P.l Introduction

Annex P, Section P.2

Operator system access requested in keypad facility

information element

Annex P, Section P.2

Operator system access requested in keypad facility

information element

Change the status of this Annex from "Informative"

to "Normative".

Delete the fifth paragraph (' 'Progress Indicator 4 ...").

Delete "or primary" from the left side (between TE

and ISDN) of Figure 1.1.

Delete "Basic or" from the right side (between ISDN

and NT2) of Figure LI

Change "American National Standard T1.607" to "NIU 90-301" in the first sentence of the first paragraph.

Change the first sentence of the first paragraph to: "This annex is part of NIU 90-301."

Delete this annex.

Delete this annex.

Delete this annex.

Delete "optional" from the first sentence.

Delete "or attendant system" from the end of the first sentence in the first paragraph.

Change the last sentence of the first paragraph to: "These procedures apply to the speech and 3.1 kHz

audio bearer services."

Delete "or attendant system" from the first sentence in the second paragraph.

Delete "or attendant system" from the first sentence of

the first paragraph.

Delete "or attendant system" from the last sentence of

the first paragraph.

A-36 NIU-Forum Agreements on ISDN
Annex P, Section P.3 Use of the operator system access information

element

Annex P, Section P.3 Use of the operator system access information

element

Annex P, Section P.3 Use of the operator system access information

element

Annex P, Section P.3 Use of the operator

element

Annex Q

Responding address requirements of the OSI network

layer service

Annex R

Application of the Signal Information Element to Tones and Alerting Patterns

Annex R

Application of the Signal Information Element to Tones and Alerting Patterns Table 21 — Tones

Annex S

Comparison of CCITT Recommendation Q.931 to ANSI T1.607

Delete "or attendant system" from the first sentence of

the first paragraph.

Delete "c) Private/principal ... SETUP message." from

the second paragraph.

Delete "or attendant system" from the third paragraph.

Delete this annex.

Change the status of this Annex from "informative" to "normative".

Delete the following rows: 2, 6, 8.

Delete this annex.

Delete the sixth paragraph.

system access information

NIU-Forum Agreements On ISDN A-37
Attachment A

(of Appendix A)

1. General

1.1 Scope and Purpose

This Implementation Agreement specifies a minimal subset of procedures and codepoints from the American National

Standards Tl .607- 1990 (Ref. [17]) for the establishment, maintenance, and clearing of ISDN connections at the user- to-network interface. This signalling standard is used to support the circuit-switched bearer services specified in ANSI standards T1.603*.

Terminals are not required to support all services. Switches will support all of the mandatory protocols and

codepoints in this implementation agreement. This does not preclude the support of additional services and

procedures. However, equipment must be able to interoperate with equipment supporting only this minimal subset.

1.1.1 Definitions

The ANS Tl.607-1990 (Ref. [17]) assumes that procedures apply generically to ISDN access interfaces, i.e., the document does not distinguish between basic and primary rates access interfaces. In addition, there are no references

to specific applications in that document. The concept of equipment classes is introduced in this document to permit

certain procedures to be associated with a particular application or class of equipment, e.g., station equipment versus PBX. Specifically, two classes of equipment are defined on the basis of two fundamental attributes.

The first attribute relates to the possibility of an exchange of signals occurring beyond the public network's point

of contact with the interface (i.e., between the equipment directly connected to the public network and ISDN

terminals or telephones connected to that equipment). For example, some user equipment may support subtending

Basic Access digital subscriber loops and/or analog telephone loops. For Class I equipment, the network makes no

provision for such an arrangement and assumes the Class I equipment constitutes the endpoint of the communication.

Conversely, in the case of Class II equipment, the procedures at the network take into account that communication

between Class II equipment (with which it communicates directly) and other equipment (with which the network does

not have direct contact) may occur. As an example, Class II equipment may support digital and/or analog subscriber

loops. Use of Class II equipment also involves the possibility of having interworking occur beyond the equipment

with which the network has direct contact. Therefore, it is reasonable for Class II equipment to provide the network

with an interworking notification, for both outgoing and incoming calls, when either the calling or called party

respectively, is a non-ISDN user. Class II equipment may also send an interworking notification if a private network

exists beyond the Class II equipment and interworking to a non-ISDN facility within that network takes place. When

an interface is associated with Class I equipment, it is assumed the multiple pieces of equipment may exist and

communicate with the network over the D-channel. However, in this case, all equipment is assumed to be ISDNcapable and is considered as the endpoint of the communication. Therefore, interworking notification should not be

accepted from Class I equipment.

The second attribute relates to the manner in which a SETUP message should be presented to the user equipment.

When Class I equipment is applied on a particular interfaces, the network should broadcast the SETUP message

associated with each call that terminates on that interface, since interaction between the network and multiple pieces

of user equipment should be supported. On the other hand, the network should not broadcast SETUP messages

Subject to further discussion.

A-38 NIU-Forum Agreements on ISDN
associated with terminating calls to an interface on which Class II equipment is being used. Here, a single piece

of user equipment is assumed to be involved in all communication with the network.

To the extent possible, it is desirable to have one set of requirements for ISDN call control apply to all ISDN user configurations. However, in cases for which integrated procedures are not appropriate, the call control procedures

associated with Equipment Class I will differ from those associated with Equipment Class II. Unless otherwise

noted, the assumption should be that a particular procedure/capability should be provided for both classes of equipment on both basic and primary rate access. However, use of the equipment class terminology permits

clarification of the circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capability applies only to a

subset of four possible configurations which are labeled as follows.

Class I Class n

IB IIB

IP IIP

In other words, a capability that applies to Class I equipment may be provided on basic access interfaces (IB) and/or

primary rate access interfaces (TP). Similarly, a capability that applies to Class II equipment may be provided on

basic access interfaces (IIB) and/or primary rate access interfaces (HP).

The notation shown in the table above is used within this implementation agreement to indicate when protocol or procedures are only expected to be supported for a particular equipment class and/or are limited to a particular type

of interface, i.e., basic or primary rate interface.

NIU-Forum Agreements On ISDN A-39
Attachment B

(of Appendix A)

The various parts of the called party number information element should be coded as follows: — Type of number and numbering plan (octet 3) Bits 7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

1 10 10 0 1 Abbreviated Number in Private Numbering plan

All other values are reserved — Digits (octet 4, etc.)

Bits 7 6 5 4 3 2 1 Meaning

0 110000 0

0 110001 1 0 110 0 10 2

0 110 0 11 3 0 110 10 0 4

0 110 10 1 5 0 110 110 6

0 110 111 7

0 111000 8

0 111001 9

All other values are reserved

Digits should be represented by IA5 characters whose encoding is shown above.

In the network to user direction (n -> u), this IE will be always signaled in the SETUP message, and public network

interfaces will use only one codepoint: local number in ISDN. For private networks, this IE can contain the following codepoints: abbreviated type of number, and private numbering plan, and extra digits such A, B, C, and

D (as per IA5).

A-40 NIU-Forum Agreements on ISDN
Attachment C

(of Appendix A)

The various parts of the calling party number information element should be coded as described below. The

numbering plans are as described in CCITT Recommendations E.164 or X.121. — Type of number and numbering plan (octet 3) follows:

Bits 7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 0 1 0 0 1 1 International number in data numbering plan (Rec. X.121)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

1 10 10 0 1 Abbreviated Number in Private Numbering plan

All other values are reserved — Origin of number and presentation status (octet 3a) follows:

Bits 7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Presentation allowed of user-provided number,

number not screened

0 0 0 0 0 0 1 Presentation allowed of user-provided number,

number passed network screening

0 0 0 0 0 1 0 Presentation allowed of user-provided number,

number failed network screening

0 0 0 0 0 1 1 Presentation allowed of network-provided number

0 1 0 0 0 0 0 Presentation prohibited of user-provided number,

number not screened

0 1 0 0 0 0 1 Presentation prohibited of user-provided number,

number passed network screening

0 1 0 0 0 1 0 Presentation prohibited of user-provided number,

number failed network screening

0 1 0 0 0 1 1 Presentation prohibited of network-provided number

1 0 0 0 0 1 1 Number not available

All other values are reserved

Notes

1 When octet 3a is omitted, the default value of Number Presentation parameter for the signaled DN value

should be used, if it is available. If a value for this parameter is unavailable (i.e., the signaled DN value

either fails screening or is not screened by the SPCS), the presentation parameter value of the default DN

should be used.

2 Octet 3a, bits 7 and 6 are for the Presentation Indicator; bits 2 and 1 are for the Screening Indicator.

NIU-Forum Agreements On ISDN A-41
— Digits (octet 4, etc.)

Digits should be represented by IA5 characters whose encoding is shown below:

Bits 7 6 5 4 3 2 1 Meaning

0 1 1 0 000 0

0 1 1 000 1 1 o 1 1 0 0 10 2

0 1 1 0 0 11 3 0 1 1 0 100 4

0 1 1 0 10 1 5 0 1 1 0 110 6

0 1 1 0 111 7

0 1 I 1000 8

0 1 1 100 1 9

All other values are reserved

Codings At Originating Party Interface

The calling party number information element should only be accepted when in the SETUP message. When

the type of number and numbering plan indicator indicates "local number in the ISDN (E.164) numbering

plan", the calling party number information element should contain a 7-digit local number. When the type

of number and numbering plan indicator indicates "national number in the ISDN (E.164) numbering plan"

the calling party number information element should contain a 10-digit national number.

In the network to user direction (n -> u), the coding and delivery of this IE depends on the definition of

the Calling Line ID service. For private networks, this IE can contain the following codepoints: abbreviated

type of number, and private numbering plan, and extra digits such as A, B, C, and D (as per IA5).

A-42 NIU-Forum Agreements on ISDN
Attachment D

(of Appendix A)

• add the following figures to section H.3.1

8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 1 0 0 1

int int Pref/ D ch. Ch. sel. id type Excl id.

Figure H.7-1. Channel Bl exclusive.

8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 0 0 1 0

int int Pref/ D ch. Ch. sel. id type Excl id.

Figure H.7-2. Channel B2 preferred.

NIU-Forum Agreements On ISDN A-43
8 7 6 5 4 3 2 1

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 1 0 1 0

int int Pref/ D ch. Ch. sel. id type Excl id.

Figure H.7-3. Channel B2 exclusive.

8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 0 0 1 1

int int Pref/ D ch. Ch. sel. id type Excl id.

Figure H.7-4. Any B-channel.

A-44 NIU-Forum Agreements on ISDN
8 7 6 5 4 3 2 1 octet

Channel identification

o 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 0 0 0 0

int int Piety D ch. Ch. sel. id type Excl id.

Figure H.7-5. No B-channel Indicated.

NIU-Forum Agreements On ISDN A-45

APPENDIX B.

NTU 90-302

Implementation Agreement

of the North American ISDN Users' Forum

Layer 3 Signalling Specification for the Minimal Set of Circuit-Switched Bearer Services for the ISDN Class II Primary Rate Interfaces.

Baseline Text American National Standard T 1.607- 1990: Integrated Services Digital Network (ISDN) —

Layer 3 Signalling Specification for

Circuit-Switched Bearer Service for

Digital Subscriber Signalling System Number 1 (DSS1).

Base Standards

CCITT Recommendation Q.931 (1988):

ISDN User-Network Interface Layer 3

Specification For Basic Call Control. ANSI Tl.607- 1990

ANSI Tl.603-1990':

Integrated Services Digital Network (ISDN) —

Minimal Set of Bearer Services for

the Primary Rate Interface.

B.l Abstract

This Implementation Agreement specifies procedures for establishing, maintaining, and clearing connections at the Integrated Services Digital Network (ISDN) user-network interfaces identified as Class II PRI, and are mandatory

for the support of the minimal set of circuit-switched bearer services specified by ANSI Tl.603-1990* Integrated

Services Digital Network (ISDN) — Minimal Set of Bearer Services for the Primary Rate Interface, (Ref. [14]). Procedures for circuit-mode digital, circuit-mode speech and circuit-mode voiceband data bearer services are as specified in the baseline text ANS Tl.607-1990, Integrated Services Digital Network (ISDN) —Digital Subscriber

Signalling System Number 1 (DSS1) —Layer 3 Signalling Specification for Circuit-Switched Bearer Service, (Ref.

[17]), as further resolved by this agreement. The packet-mode data service is included in this document as a bearer

service. Procedures for the packet-mode bearer service will be detailed in another document.

Subject to further discussion

NIU-Forum Agreements On ISDN B-l
B.2 Introduction

The original implementation agreement (NTU 90-302) was reached by marking up the text of ANS T1.607- 1990,

(Ref. [17]) to reflect the clarifications of text and selection of options. This appendix translates the implementation

agreement markup into a listing of these clarifications and selections, (i.e., this appendix lists the differences [the "delta"] between the implementation agreement marked up ANS Tl.607- 1990, and the original text of ANS T1.607-

1990).

B.3 NIU 90-302 Delta List"

The IA has adopted the ANS Tl.607-1990*** (Ref. [17]) standard with the following clarifications of the text, and

selection of options:

ANS Tl.607-1990

SECTION/TABLE NUMBER/NAME

IMPLEMENTATION AGREEMENTS - CLARIFICATION OF TEXT AND

SELECTION OF OPTIONS

Section 1.1 Scope and Purpose

Replace this section with Attachment A of this document.

Section 2.1.1.3 Overlap Sending (U2)

Delete this section.

Section 2.1.2.3 Overlap Sending (N2)

Delete this section.

Section 2.1.2.14 Call Abort (N22)

Delete this section.

Section 3.1 Table 1 — Messages for circuit-mode connection

control

Delete the following message and reference: "INFORMATION 3.1.6".

Section 3.1 Table 1 — Messages for circuit-mode connection

control

Delete the following message and reference: "SETUP

ACKNOWLEDGE 3.1.12".

Section 3.1 Table 1 — Messages for circuit-mode connection

control

Change "NOTIFY 3.1.7" to "NOTIFY*".

Note that this Delta List was developed in "good faith" by NIST as a simple equivalent representation of

the actual agreements. It has been reviewed and approved by the editors of the Signalling Working Group

as per recommendation of the Executive Steering Committee.

These documents can be purchased from: American National Standards Institute, 1 1 West 42nd Street, New

York, NY 10036.

B-2 NIU-Forum Agreements on ISDN
Section 3.1 Messages for circuit-mode connection control

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.1 ALERTING

Table 2 - ALERTING message content

Section 3.1.1 ALERTING

Table 2 — ALERTING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2 CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Add the following footnote below Table 1 "* See

section 5.8.4 for treatment of this message."

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete the following rows:

• "Display";

• "Signal".

Delete Notes 4, 5, 6.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Type" cell from

"0(Note 1)" to "M".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete rows

• "Progress indicator";

• "Display".

Delete Notes 1, 2, 3, 4.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

NIU-Forum Agreements On ISDN B-3
Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Delete the following rows:

• "Display";

• "Signal";

• "Connected number";

• "Connected subaddress";

• "Low layer compatibility".

Change Note 3 to: "Included in the event of

interworking."

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.3 CONNECT

Table 4 — CONNECT message content

Section 3.1.4 CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.4 CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.4 CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5 DISCONNECT

Table 6 — DISCONNECT message content

Delete Notes 4, 5, 6, 7, 8, 9.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Delete the following rows:

• "Display";

• "Signal".

Delete Notes 1, 2, 3.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" from "4-32" to "4-10".

Delete the following rows:

• "Display";

• "Signal"'

• "Connected Number";

• "Connected subaddress".

Section 3.1.5 Delete Notes 1, 2, 3, 4, and 5. DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.6 Delete this section. INFORMATION

B-4 NIU-Forum Agreements on ISDN
Section 3.1.7 NOTIFY

Delete this section.

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8 PROGRESS

Table 9 — PROGRESS message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.9 RELEASE

Table 10 — RELEASE message content

Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" cell from "2-32" to "2, 4-

10".

Delete the following rows:

• "Display";

• "Signal".

Delete Notes 2, 3, 4.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" cell from "2-32" to "2, 4-

10".

Delete the following rows:

• "Display";

• "Signal";

• "Connected number";

• "Connected subaddress".

Delete Notes 3, 4, 5, 6, 7.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Section 3.1.10 Change the "Cause/Length" cell from "2-32" to "2, 4- RELEASE COMPLETE 10". Table 1 1 —RELEASE COMPLETE message content

NIU-Forum Agreements On ISDN B-5
Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.10 RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Delete the following rows:

• "Display";

• "Signal";

• "Connected number";

• "Connected subaddress".

Delete Notes 3, 4, 5, 6, 7.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Delete the following rows:

• "Repeat indicator";

• "Display";

• "Keypad facility";

• "Signal".

Change the "Bearer capability/Type" cell from

"M(Note 2)" to "M".

Change the "Bearer capability/Length" cell from "4- 13" to "4-8".

Change the "Channel identification/Type" cell from

"0(Note 3)" to "M".

Change the "Channel identification/Length" cell from

"2-*" to "5-6".

Change the "Network specific facilities/Length" cell from "2-*" to "2-32".

Change the "Calling party number/Length" cell from

"2-*" to "2-19".

Change the "Called party address/Length" cell from

"2-*" to "2-18".

B-6 NIU-Forum Agreements on ISDN
Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.11 SETUP

Table 12 — SETUP message content

Section 3.1.12 SETUP ACKNOWLEDGE

Section 3.1.13 STATUS

Table 14 — STATUS message content

Change the "Transit network selection/Length" cell from "2-*" to "2-7".

Change the "High layer capability/Length" cell from

"2-4" to "2-5".

Delete Notes 1, 2, 3, 6, 7, 8, 9.

Change Note 4 to: "Included in the event of

interworking."

Change the first sentence of Note 12 to: "The called party number information element is included by the user

Change the first sentence of Note 20 to: "This

information applies to speech and 3.1 kHz audio

bearer services."

Add the following to the end of Note 13: "The

network should transport this EE transparently. This IE is optional on the user side."

Add the following to the end of Note 15: "The

network should transport this EE transparendy. This IE is optional on the user side. The total length is 2

to 16 octets."

Add the following to the end of Note 16: "The

network should transport this IE transparently. This IE is optional on the user side."

Add the following to the end of Note 17: "The

network will treat this IE on sending and receiving as described in the User-User supplementary service Implementation Agreement."

Delete this section.

Change the "Call reference/Length" cell from "2-*" to "2-3".

NIU-Forum Agreements On ISDN B-7
Section 3.1.13 STATUS

Table 14 — STATUS message content

Section 3.1.13 STATUS

Table 14 — STATUS message content

Section 3.1.13 STATUS

Table 14 — STATUS message content

Section 3.1.14 STATUS ENQUIRY

Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14 STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.2.1 RESTART

Table 17 — RESTART message content

Section 3.2.1 RESTART

Table 17 — RESTART message content

Section 3.2.1 RESTART

Table 17 — RESTART message content

Section 3.2.1 RESTART

Table 17 — RESTART message content

Section 3.2.2 RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Change the "Cause/Length" cell from "4-32" to "4- 10".

Delete row "Display".

Delete Notes 1, 2.

Change the first sentence to: "This message is sent by the user or the network during the active state to

solicit a STATUS message from the peer layer 3

entity."

Change the "Call reference/Length" cell from "2-*" to "2-3".

Delete row "Display".

Delete Notes 1, 2.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete row "Display".

Delete Notes 3, 4.

Change the "Call reference/Length" cell from "2-*" to "2-3".

B-8 NIU-Forum Agreements on ISDN
Section 3.2.2 RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Section 3.2.2 RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Section 3.2.2 RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Section 4.2 Protocol discriminator

Section 4.2 Protocol discriminator

Figure 2 — Protocol Discriminator

Section 4.2 Protocol discriminator

Table 19 — Protocol Discriminator

Section 4.3

Call reference

Section 4.3 Call reference

Section 4.3

Call reference Figure 4 — Dummy call reference

Section 4.3 Call reference

Section 4.3

Call reference

Section 4.4 Message type

Table 20 — Message types

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete row "Display".

Delete Notes 3, 4.

Add the following sentence after the first sentence in the second paragraph: "The only value supported for

call control messages is described below in Figure 2."

Change "ANSI T1.607" to "Q.931".

Change "ANSI T1.607" to "Q.931" in row "0000

1000".

Change the third paragraph ("At a minimum ...") to: "At a minimum, all networks and users must be able

to support a call reference value of one and two octets for a primary rate interface."

Delete the first sentence of the fourth paragraph "As

a network ... also be supported."

Change "Figure 4. Dummy call reference" to "Figure

4. Dummy call reference *".

Add the following footnote after Figure 4: "*The

dummy call reference is not supported for primary

rate Class II circuit-switched calls."

Delete Note 1 ("The call reference ... ") at the end of

the section.

Delete the following rows:

• "SETUP ACKNOWLEDGE";

• "INFORMATION".

NIU-Forum Agreements On ISDN B-9
Section 4.4 Message type

Table 20 — Message types

Section 4.5.1 Coding rules

Section 4.5.1 Coding rules Figure 7 — Formats of information elements

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Add the following to the end of row "NOTIFY":

"(see sec. 5.8.4 for treatment of this message type)."

Delete the second, third, and fourth sentences from

the fourth paragraph.

Delete figure (b) Single octet information element

format (type 2).

Delete the following rows:

• "Repeat indicator";

• "Notification indicator";

• "Display";

• "Keypad facility";

• "Signal";

• "Connected number";

• "Connected subaddress";

• "Escape for extension".

Delete reference to "(Note 6)" from "Bearer

capability" row.

Change the "Bearer capability/Max length" cell from

"13" to "8".

Change the "Cause/Max length" cell from "32" to "10".

Change the "Cause/Max no of occurrences" cell from

"3" to "2".

Change the "Channel identification/Max length" cell from "(Note 4)" to "6".

Change the "Network-specific facilities/Max length"

cell from "(Note 4)" to "32".

Change the "Network-specific facilities/Max no. of

occurrences" cell from "4" to "2".

B-10 NIU-Forum Agreements on ISDN
Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Change the "Calling party number/Max length" cell from "(Note 4)" to "19".

Change the "Called party number/Max length" cell from "(Note 4)" to "18".

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Delete reference to "(Note 2)" from "Transit network

selection" row.

Change the "Transit network selection/Max length"

cell from "(Note 4)" to "7".

Section 4.5.1 Coding rules Table 21 — Information element identifier codingDelete "4" from the "Transit network selection/Max

no. of occurrences" cell.

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Table 21 — Information element identifier coding

Section 4.5.1 Coding rules Figure 8 — Information element format using escape

for extension

Change the "High layer compatibility/Max length" cell from "4" to "5".

Delete Notes 3, 4, 6.

Delete this figure.

Section 4.5.2 Extensions of codesets

Change "T1.608" to "NTU 89-320" in the first bullet

in the fourth paragraph.

NIU-Forum Agreements On ISDN B-ll
Section 4.5.2 Extensions of codesets

Replace the tenth paragraph ("Codeset 6 ...") with the following:

Section 4.5.3 Locking shift procedure

New codeset identification table

Section 4.5.4 Non-locking shift procedures

Section 4.5.4 Non-locking shift procedures

Temporary codeset identification table

Section 4.5.4 Non-locking shift procedures

Temporary codeset identification table

Section 4.5.5 Bearer Capability

Section 4.5.5 Bearer Capability

Figure 11 — Bearer capability information element

"Codeset 6 is reserved for information elements

specific to the local network (either public or private).

These information elements can appear in a call establishment (i.e., SETUP, ALERTING, or CONNECT) or first clearing message. As such, they

do not have significance across a national or

international boundary. For these two cases, codeset

6 information elements shall be handled according to the procedures for unrecognized information elements

(see sec. 5.8.7.1) beyond the local network boundary.

Inside a private local network recognized codeset 6

information elements shall be consumed, manipulated,

or passed transparently according to the rule for that information element. Across the boundary between

local networks (e.g., a public and a private network),

recognized codeset 6 information elements shall be

consumed and manipulated according to the rule for

that information element. Inside a private local network, unrecognized codeset 6 information elements

may be passed transparently. Across the boundary

between a private local network and a public local network, unrecognized codeset 6 information elements

shall be either treated as per section 5.8.7.1 or passed

transparently if a bilateral agreement exists."

Change "T1.608" to "NIU 89-320" for codeset 5.

Delete "a) process the nonblocking ... as described

below" from the second paragraph.

Change "T1.607" to "NIU 90-302" for codeset 0.

Change "T1.608" to "NIU 89-320" for codeset 5.

Change "13 octets" to "8 octets" in the second

sentence ("The maximum length ...") of the second

paragraph.

Change octet 4, bit 8 from "0/1" to "1".

B-12 NIU-Forum Agreements on ISDN
Section 4.5.5 Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5 Bearer Capability

Information transfer capability (octet 3) coding

Section 4.5.5 Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5 Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5 Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5 Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5 Bearer Capability

Section 4.5.5 Bearer Capability

User information layer 1 protocol (octet 5) coding

Delete the following octets:

• 4a;

• 4b;

• 5b (Note 2);

• 5b (Note 3);

• 5c;

• 5<L

Change octet 5a, bit 8 from "0/1" to "1".

Delete Notes 1, 2, 3.

Add the following after Note 4: "5 Octets 6 and 7

are included for information only. The coding and

application of these octets are included in another

document."

Delete row "10001 7 kHz audio".

Change the title to "Information transfer rate (octet

4)".

Delete the following rows: "10011 384 kbit/s",

"10100 1472 kbit/s (Note 2)", "10101 1526 kbit/s".

Change Note 1 to: "The bearer capability is bidirectional symmetric at the information transfer

rate specified in octet 4."

Delete Note 2.

Delete all codings and text referring to octet 4a

(structure, configuration, establishment) and octet 4b

(symmetry).

Delete "and optionally octets 5b, 5c, and 5d as defined below." from row "00001".

NIU-Forum Agreements On ISDN B-13
Section 4.5.5 Bearer Capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5 Bearer Capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5 Bearer Capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5 Bearer Capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5 Bearer Capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5 Bearer Capability

Negotiation (octet 5a) coding

Section 4.5.5 Bearer Capability

User rate (octet 5a) coding

Section 4.5.5 Bearer Capability

Section 4.5.5 Bearer Capability

Section 4.5.6 Call state Call state value (octet 3) coding

Section 4.5.6 Call state Call state value (octet 3) coding

Delete "and G.725 7 kHz audio" from row "00101".

Delete rows "00111" and "01000".

Delete Note 2.

Delete row "1 asynchronous".

Delete the second and third sentences from the Note.

Delete row "1 In-band negotiation possible".

Delete all rows except row "01111 56 kbi(/s CCITT

Recommendation V.6".

Delete all text relating to octet 5b (i.e., sections labeled "Octet 5b for CCITT Recommendation V.100

or X.30 rate adaption" and "Octet 5b for CCITT

Recommendation V.120 rate adaption".)

Delete all codings and text referring to octets 5c

(number of data bits excluding parity bit, parity

information) and 5d (duplex mode, modem type).

Delete row "000010 U2 — overlap sending".

Add the following column to the right of the coding:

Symmetric States* 50 — Null

51 — Call Initiated 53 — Outgoing Call Proceeding

54 — Call Delivered

56 — Call Present 57 — Call Received

58 — Connect Request

59 — Incoming Call Proceeding

B-14 NIU-Forum Agreements on ISDN
Section 4.5.6 Call state Call state value (octet 3) coding

Section 4.5.6 Call state Call state value (octet 3) coding

Section 4.5.7 Called party number

Section 4.5.7 Called party number

Type of number (octet 3) coding

Section 4.5.7 Called party number

Type of number (octet 3) coding

Section 4.5.7 Called party number

Type of number (octet 3) coding

Section 4.5.7 Called party number

Numbering Plan Identification (octet 3) coding

Section 4.5.7 Called party number

Numbering plan identification (octet 3) coding

Section 4.5.7 Called party number

Section 4.5.9 Calling party number

510 — Active

511 — Disconnect Request

512 — Disconnect Indication S19 — Release Request

Add the following after the coding: "*Note — For Symmetric states see Annex D."

Delete "N22 — Call abort" from the "010110/

Network State" cell.

Change the second paragraph to: "The maximum

length of this information element is 18 octets."

Delete the following rows:

• "Oil network specific number";

• "111 reserved for extension".

Change the end of Note 2 to: "this information

element cannot be used in combination with Operator

System Access or Transit Network Selection

information elements."

Delete Note 4.

Delete the following rows:

• "0011 data numbering plan";

• "0100 telex numbering plan";

• "1111 reserved for extension".

Change "c)" under the Note to: "this information

element cannot be used in combination with Operator

System Access or Transit Network Selection

information elements."

Add Attachment B of this document after the following:

"Number digits (octets 4, etc.) This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering/dialing plan."

Change the second paragraph from "The maximum

length of this information element is network

dependent." to "The maximum length of this information element is 19 octets."

NIU-Forum Agreements On ISDN B-15
Section 4.5.9 Calling party number

Type of number (octet 3) coding

Section 4.5.9 Calling party number

Type of number (octet 3) coding

Section 4.5.9 Calling party number

Numbering Plan Identification (octet 3) coding

Section 4.5.9 Calling party number

Section 4.5.11 Cause

Section 4.5.11 Cause

Figure 17 — Cause information element

Section 4.5.11 Cause

Figure 17 — Cause information element

Section 4.5.11 Cause

Figure 17 — Cause information element

Section 4.5.11 Cause

Recommendation (octet 3a) coding

Section 4.5.11 Cause

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Delete the following rows:

• "Oil network specific number";

• "111 reserved for extension".

Delete Note 4.

Delete the following rows:

• "0100 telex numbering plan";

• "1111 reserved for extension".

Add Attachment C of this document after the following:

"Number digits (octets 4, etc.) This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering/dialing plan."

Change the second sentence of the first paragraph to: "The maximum length of this information element is 10 octets."

Change octet 3, bit 8 from "0/1" to "1".

Delete octet 3a.

Delete the Note under the figure.

Delete this coding and Notes 1 and 2.

Add the following sentence to the end of the paragraph following "Diagnostics (octet 5)": "If more

than one IE is identified in a diagnostic, they should

be ordered as IEs normally appear in a message."

Change the "unallocated (unassigned) number/

diagnostics" cell to "Not used".

Change the "no route to specified transit network/

diagnostics" cell to "Not used".

B-16 NIU-Forum Agreements on ISDN
Section 4.5.11 Cause

Cause table

Change the "no route to destination/diagnostics" cell to "Not used".

Section 4.5.11 Cause

Cause table

Change "normal call clearing/diagnostics" cell to "Not

used".

Section 4.5.11 Cause

Cause table

Change the "user busy/diagnostics" cell to "(see Note

10)".

Section 4.5.11 Cause

Cause table

Change the "call rejected/diagnostics" cell to "Not

used".

Section 4.5.11 Cause

Cause table

Delete the "number changed/diagnostics" cell.

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Delete the following rows:

• "non-selected user clearing";

• "network out of order";

• "resource unavailable, unspecified";

• "quality of service unavailable";

• "only restricted digital information bearer capability

is available";

• "service or option not implemented, unspecified";

• "invalid transit network selection";

• "invalid message, unspecified".

Change the "No circuit/channel available/diagnostics"

cell to "(see Note 10)".

Section 4.5.11 Cause

Cause table

Delete reference to "(see Note 6)" in the "access information discarded/diagnostics" cell.

Section 4.5.11 Cause

Cause table

Add "(see Note 10)" to the "requested circuit or channel not available/diagnostics" cell.

Section 4.5.11 Cause

Cause table

Delete the corresponding cell in the "diagnostics"

column for the following rows:

• "requested facility not subscribed";

• "bearer capability not authorized";

• "bearer capability not presently available";

• "channel type not implemented";

• "requested facility not implemented".

NIU-Forum Agreements On ISDN B-17
Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Cause table

Section 4.5.11 Cause

Figure 18 — Coding of the diagnostic field for causes

57, 58 and 65.

Section 4.5.11 Cause

Section 4.5.12 Channel identification

Section 4.5.12 Channel identification

Change the "bearer capability not implemented/

diagnostics" cell to "Not used".

Change the "identified channel does not exist/ diagnostics" cell to "Not used".

Delete the "incompatible destination/diagnostics" cell.

Delete the reference to "(see Note 6)" in the "mandatory information element is missing/

diagnostics" cell.

Change the "information element non-existent or not implemented/diagnostics" cell to "Information

element identifier(s) (see Note 8)".

Change the "invalid information element contents/

diagnostics" cell to "Information element

identifier(s)".

Change the "recovery on timer expiry/diagnostics"

cell to "Not used".

Delete the following Notes: 2, 3, 4, 5, 6, 7, 9, 1 1, 12.

Delete this figure and Notes 1 and 2 appearing below

it.

Delete all text referring to octets 5 (attribute number),

5a (rejected attribute), and 5b (available attribute).

Change the last sentence in the first paragraph to: "The default maximum length for this information

element is 6 octets."

Delete the second paragraph.

B-18 NIU-Forum Agreements on ISDN
Section 4.5.12 Change octet 3.1, bit 8 from "0/1" to "1". Channel identification Figure 19 — Channel identification information

element

Section 4.5.12 Delete the reference to "Note 2" of octet 3.2. Channel identification Figure 19 — Channel identification information

element

Section 4.5.12 Delete the references to "(Note 2)" and "Note 4" in Channel identification octet 3.3. Figure 19 — Channel identification information

element

Section 4.5.12 Delete the last sentence of Note 1. Channel identification Figure 19 — Channel identification information

element

Section 4.5.12 Delete Notes 2 and 4. Channel identification Figure 19 — Channel identification information

element

Section 4.5.12

Channel identification Figure 19 — Channel identification information

element

Add the following to the end of Note 3: "For completeness, a pointer to slot map is shown. It is not supported for this IA."

Section 4.5.12 Channel identification Interface identifier present (octet 3) coding

Section 4.5.12 Channel identification Interface type (octet 3) coding

Change row the last row ("1") to: "1 Interface

explicitly identified in octet 3.1."

Delete the following row: "0 basic interface".

Section 4.5.12 Channel identification Information channel selection (octet 3) coding

Section 4.5.12 Channel identification Information channel selection (octet 3) coding

Delete the column "basic interface".

Delete the last two rows ("10" and "11").

Section 4.5.12 Delete Note 3. Channel identification Information channel selection (octet 3) coding

NIU-Forum Agreements On ISDN B-19
Section 4.5.12 Channel identification Interface identifier (octet 3.1) coding

Section 4.5.12 Channel identification Coding standard (octet 3.2) coding

Section 4.5.12 Channel identification Number/map (octet 3.2) coding

Section 4.5.12

Channel identification Channel type/map element type (octet 3.2) coding

Section 4.5.12

Channel identification Channel type/map element type (octet 3.2) coding

Section 4.5.12

Channel identification

Section 4.5.12

Channel identification

Section 4.5.13 Connected number

Section 4.5.14 Connected subaddress

Section 4.5.15 Display

Section 4.5.16 High layer compatibility

Section 4.5.17 Keypad facility

Section 4.5.18 Low layer compatibility

Section 4.5.18 Low layer compatibility

Negotiation indicator (octet 3a) coding

Delete the second sentence ("At subscription time

...").

Delete row "1 0 National Standard ..."

Delete the last row.

Delete the last three rows.

Delete the Note.

Delete all text and Figure 20 referring to "Slot map

(octet 3.3)".

Add the following at the end of the section: "Note —

In the network to user direction (n -> u), the terminating PRI will allow channel negotiation. The

network will support offering calls with preferred Bchannel and the user responds specifying the channel

to be used for the call."

Delete this section.

Delete this section.

Delete this section.

Change the second paragraph to: "The maximum

length of this information element is five octets."

Delete this section.

Delete the second paragraph.

Delete the last row.

B-20 MU-Forum Agreements on ISDN
Section 4.5.18 Low layer compatibility

Negotiation indicator (octet 3a) coding

Section 4.5.18 Low layer compatibility

User information layer 3 protocol (octet 7) coding

Delete Note 1.

Change "ANSI T1.607" to "NIU 90-302" in the first row.

Section 4.5.19 Network-specific facilities

Section 4.5.19 Network-specific facilities

Section 4.5.19 Network-specific facilities

Section 4.5.20

Notification indicator

Change the second sentence of the first paragraph to: "No more than two Network-specific facilities information elements may be included in a single

message."

Change the second paragraph to: "The maximum

length of this information element is 32 octets."

Add Attachment D of this document to the end of this section.

Delete this section.

Section 4.5.21 Progress indicator Progress description (octet 4) coding

Section 4.5.21 Progress indicator

Delete row

ISDN."

*000 0100 4 call has returned to the

Section 4.5.22 Repeat Indicator

Section 4.5.24

Signal

Section 4.5.25

Transit network selection

Add the following Note after Notes 1 and 2 following

the "Progress description (octet 4)" coding: "3 In the SETUP message, in the user to network direction (u -> n) on PRI, one of two values may be used in the progress description field: 'call is not end-to-end

ISDN' (1), or 'calling equipment is non-ISDN' (3). In the SETUP message, in the network to user

direction (n -> u) on PRI, one of two values may be

used in the progress description field: 'call is not end-to-end ISDN' (1), or 'calling equipment is non- ISDN' (3)."

Delete this section.

Delete this section.

Change the first paragraph to: "The purpose of the Transit network selection information element is to identify one requested transit network (See Annex

Q."

NIU-Forum Agreements On ISDN B-21
Section 4.5.25

Transit network selection

Section 4.5.25

Transit network selection Type of network identification (octet 3) coding

Section 4.5.25

Transit network selection Network identification plan (octet 3) coding

Section 4.5.26 User-user

Section 4.5.26 User-user

Protocol discriminator (octet 3) coding

Section 5

Circuit-switched call control procedures

Section 5

Circuit-switched call control procedures

Section 5.1 Call establishment at the originating interface

Section 5.1.1 Call request

Section 5.1.1 Call request

Section 5.1.1 Call request

Section 5.1.1 Call request

Change the second paragraph to: "The default maximum length of this information element is 7

octets."

Delete the last row ("Oil ...").

Delete the last row ("0011 ...").

Add the following to the end of the first paragraph:

"This IE is to be included based on the User-to-user supplementary service description and user

application."

Change "ANSI T1.607" to "NIU 90-302" in the last row of the coding.

Change the third paragraph ("All messages ...") to: "All messages in this standard contain the functional

type of information elements. Functional information

elements are characterized as requiring a degree of

intelligent processing by the Customer Premise

Equipment (CPE) in either their generation or

analysis."

Delete the fifth paragraph ("As a general ..."), the second Note of the section, and the seventh

paragraphs ("In addition ...").

Change "ANSI T1.602" to "NIU 89-210" in the last sentence.

Change the last sentence of the first paragraph to: "The Bearer capability information element is mandatory in the SETUP message."

Change the third paragraph to: "Furthermore, the SETUP message shall also contain all of the call information (i.e., address and facility requests) necessary for call establishment."

Delete the following from the fourth paragraph: "b) the Keypad information ... other call information",

and the Note ("All networks are ...").

Delete the last paragraph ("For overlap ...").

B-22 NIU-Forum Agreements on ISDN
Section 5.1.2 B -channel selection — originating

Delete the following from the first paragraph: "c) any

channel ... alternative c) is assumed."

Section 5.1.2 B -channel selection — originating

Section 5.1.2 B-channel selection — originating

Section 5.1.2 B-channel selection — originating

Delete the last sentence from the third paragraph: case c), the ... with the D-channel."

"In

Section 5.1.2 B-channel selection — originating

Change the end of the first sentence in the fourth paragraph from "(i.e., a SETUP ACKNOWLEDGE or CALL PROCEEDING message)." to "(i.e., a CALL

PROCEEDING message)."

Change the fifth paragraph to: "The user need not

attach until receiving a: a) CALL PROCEEDING, b)

ALERTING message with the progress indicator 8

'in-band information or appropriate pattern is now

available' or c) a PROGRESS message with the progress indicator 1 'call is not end-to-end ISDN;

further call progress information may be available in- band'. Prior to this time, the network cannot assume

that the user has attached ... (if it has not already

done so)."

Change the first sentence of the last paragraph to: "In case a), if the specified channel is not available,

and in case b) if not channel is available, a RELEASE COMPLETE message with a cause value

of 44 'requested circuit/channel not available' or 34

'no circuit/channel available', respectively, is sent by

the network as described in 5.3."

Section 5.1.3 Overlap sending

Section 5.1.4 Invalid call information

Section 5.1.4 Invalid call information

Delete this section.

Change the first sentence in the first paragraph to:

"If, following the receipt of the SETUP message, the network determines ... cause such as the following:".

Add the following to the end of the first paragraph

after "28 ...": "82 'identified channel does not exist'."

Section 5.1.5.1 Call proceeding, en-bloc sending

Section 5.1.5.2 Call proceeding, overlap sending

Section 5.1.6 Notification of interworking at the originating interface

Add the following to the second paragraph after "58 "34 'no circuit/channel available'."

Delete this section.

Change "a) ..." in the first paragraph to: "a) in an

appropriate call control message when a state change

is required (CONNECT); or,".

NIU-Forum Agreements On ISDN B-23
Section 5.1.6 Notification of

interface

interworking at the originating

Add to the end of "1 ..." in the second paragraph

"(i.e., in a PROGRESS message); or,".

Section 5.1.6 Notification of interworking at the originating

interface

Section 5.1.6 Notification of interworking at the originating

interface

Section 5.1.6 Notification of interworking at the originating

interface

Section 5.1.7 Call confirmation indication

Section 5.2 Call establishment at the destination interface

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Section 5.2.1 Incoming call

Change "2 ..." in the second paragraph to: "2

'destination address is non-ISDN' (i.e., in a CONNECT message);".

Delete "4 ... end-to-end ISDN" from the second

paragraph.

Delete "or more" from the second part of the first sentence in the fourth paragraph.

Change the last sentence in the first paragraph to: "When the user receives the ALERTING message, the user shall enter the Call Delivered state."

Delete the last sentence of the third paragraph ("No

use ...").

Delete the last two sentences of the first paragraph.

Change the last part of the second paragraph from

"(e.g., Display, Low layer compatibility)." to "(e.g., Low layer compatibility.)".

Add the following to the end of the second paragraph:

"In general, a call terminating from a non-ISDN line or from a Public Switched Telephone Network

(PSTN) trunk should be offered to the called user equipment with the 3.1 kHz audio bearer capability."

Delete the first and second sentences of the third paragraph. Delete "However, if... the interface" from

the third sentence. The third paragraph will now

read: "A point-to-point data link shall be used to carry the SETUP message. After sending the SETUP

message, the network starts timer T303."

Delete the fifth paragraph and the Note following this paragraph.

Change the second part of the last sentence in the seventh paragraph from "timers T303 and T312 are

restarted." to "timer 303 is restarted."

B-24 NIU-Forum Agreements on ISDN
Section 5.2.2 Compatibility checking

Section 5.2.3.1 SETUP message delivered by point-to-point data link

Section 5.2.3.1 SETUP message delivered by point-to-point data link

Section 5.2.3.1 SETUP message delivered by point-to-point data link

Section 5.2.3.1 SETUP message delivered by point-to-point data link

Section 5.2.3.2 SETUP message delivered by broadcast data link

Section 5.2.5.1 Response to en-bloc SETUP

Section 5.2.5.1 Response to en-bloc SETUP

Section 5.2.5.2 Receipt of CALL PROCEEDING and ALERTING

Section 5.2.5.2 Receipt of CALL PROCEEDING and ALERTING

Section 5.2.5.2 Receipt of CALL PROCEEDING and ALERTING

Delete the second paragraph ("When the SETUP

message ...").

Delete the following from the first paragraph under

"a) "3) any channel is acceptable."

Delete the paragraph under "b) that reads "In case

3), ...."

Change the first sentence in the third paragraph under

"b)" to: "If in case 1) the B-channel indicated in the

first response message is not the channel offered by

the network, or in case 2) the B-channel indicated in the first response message is unacceptable to the network, it will clear the call by sending a RELEASE

message with cause 6 'channel unacceptable' (see 5.3.2 d)."

Change the first part of "e) ..." to: "e) In case 1) if the indicated B-channel is not available, or in case 2)

if no B-channel is available

Delete this section.

Change the first sentence of the Note to: "A Progress

indicator information element may be included in a CONNECT message (e.g., when an analogue terminal

is connected to an NT2 functional grouping)."

Delete the second paragraph ("When the SETUP

message was delivered via a broadcast ...").

Delete the first paragraph ("When the SETUP

message is delivered on a broadcast ...").

Change the second paragraph to: "Upon receipt of

the first CALL PROCEEDING message from a user, the network shall: stop timer T303; start time T310;

and enter the incoming Call Proceeding state."

Delete the fourth paragraph ("When the SETUP

message was delivered via a broadcast ...").

NIU-Forum Agreements On ISDN B-25
Section 5.2.5.2 Receipt of CALL PROCEEDING and ALERTING

Change the fifth paragraph to: "Upon receipt of the ALERTING message from a user, the network shall: stop timers T303 or T310 (if running) and TDEL (if running); start optional timer T301 (unless another

internal alerting supervision timer function exists; w.g. incorporated in call control); enter the Call Received

state; and send a corresponding ALERTING message

to the calling user."

Section 5.2.5.2 Receipt of CALL PROCEEDING and ALERTING

Delete the sixth paragraph ("When a SETUP message

has been delivered on a broadcast link ...").

Section 5.2.5.3 Called user clearing during Incoming call establishment

Change the first part of the first paragraph to: "If the RELEASE COMPLETE or DISCONNECT message

is received

Section 5.2.5.3 Called user clearing during Incoming call establishment

Delete the second and third paragraphs.

Section 5.2.5.3.1 DISCONNECT received prior to expiry of T312

Delete this section.

Section 5.2.5.3.2 DISCONNECT received after expiry of timer T312

Delete this section.

Section 5.2.5.4 Call failure

Delete the following from the first paragraph: "a) If the SETUP message ... Call Abort state;"

Section 5.2.5.4 Call failure Change "b)" in the first paragraph to: "b) The

network shall also initiate clearing procedures toward

the called user in accordance with 5.3.4, using cause 102 'recovery on timer expiry'."

Section 5.2.5.4 Call failureDelete the second paragraph ("If the network receives

...").

Section 5.2.5.4 Call failure

Delete the following from the third paragraph: "a) If the SETUP ... shall be sent."

Section 5.2.5.4 Call failure Change "b)" in the third paragraph to: "b) The called user shall be cleared in accordance with 5.3.4, using cause 102 'recovery on timer expiry'."

Section 5.2.5.4 Call failure Change the beginning of the first sentence in the fourth paragraph to: "If the network supports timer

T301 and has received a ALERTING message,

Section 5.2.5.4 Call failureDelete from the fourth paragraph: "a) If the SETUP

message was ... shall be sent."

B-26 NIU-Forum Agreements on ISDN
Section 5.2.5.4 Call failure

Section 5.2.6 Notification of interworking at the terminating

interface

Section 5.2.6 Notification of interworking at the termination

interface

Section 5.2.7 Call accept

Section 5.2.8 Active indication

Section 5.2.9 Non-selected user clearing

Section 5.3.2 Exception conditions

Section 5.3.2 Exception conditions

Section 5.3.2 Exception conditions

Section 5.4 In-band tones and announcements

Change "b)" in the fourth paragraph to: "b) The

called user shall be cleared in accordance with 5.3.4, using cause 102 'recovery on timer expiry'."

Change the first item in the list in the second

paragraph from: "— in an appropriate ..." to:

" — in an appropriate call control message when a state change is required (CONNECT); or,".

Delete the third item from the list in the third paragraph: "4 Call has

Add the following to the end of the last paragraph:

"If the CONNECT message is the first response to the SETUP message, it shall contain the channel

identification information element."

Delete the fourth paragraph ("A user that has received

the SETUP via the broadcast data link ...").

Delete this section.

Change in the first paragraph "a)" to: "a) In response

to a SETUP message, the user or network can reject a call (e.g., because of the unavailability of a suitable B-channel) by: responding with a RELEASE

COMPLETE message provided no other response has

previously been sent releasing; the call reference and

entering the Null state."

Delete from the first paragraph: "b) In the case ... user clearing".

Delete from the first paragraph e)l) and e)2) and the Note at the end of the section.

Change the title of this section to "In-band audible

ringing tone and announcements".

NIU-Forum Agreements On ISDN B-27
Section 5.4 In-band tones and announcements

Change the first paragraph to: "It is assumed that the

originating Class II device will provide a busy tone and a reorder tone to the calling user for speech and

3.1 kHz calls. The network will not provide in-band

busy or reorder tone. When in-band audible ringing

tone/announcements not associated with a call state change are to be provided by the network before

reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in- band audible ringing tone/announcement. The

PROGRESS message contains the progress indicator 8 'in-band information or appropriate pattern is now

available'."

Section 5.4 in-band tones and announcements

Change the second paragraph to: "When an audible

ringing tone has to be provided together with a ... is sent simultaneously with the application of the inband

audible ringing tone."

Section 5.4 in-band tones and announcements

Delete Note 1.

Section 5.4 in-band tones and announcements

Change Note 2 to: "When the PROGRESS message

is used, the user may initiate call clearing as a result of the applied in-band audible ringing tone/

announcement, according to procedures specified in 5.3.3."

Section 5.5 Restart procedure

Delete from the second paragraph "b) the interface is a ... exists; or,".

Section 5.5.2 Receipt of RESTART

Change in Note 2 the reference to "ANSI T1.602" to "NIU 89-210".

Section 5.5.2 Receipt of RESTARTChange in Note 2 "b)" to: "b) that correspond to the specified channel or interface."

Section 5.7 Call collisions

Delete the Note at the end of the section.

Section 5.8.2 Message too short Change this paragraph to: "When a message is received that is too short (less than 4 octets) to contain a complete message type information element,

that message shall be ignored."

Section 5.8.4 Message type or message sequence errors Add the following after the first paragraph: "The

NOTIFY message may be ignored by the recipient."

Section 5.8.7.2 Non-mandatory information element content error

Delete the last sentence of the second paragraph

("However, in some ...").

B-28 NIU-Forum Agreements on ISDN
Section 5.8.8 Data link reset

Section 5.8.9 Data link failure

Section 5.8.9 Data link failure

Section 5.9 User notification procedure

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.1 Timers in the network side Table 22 — Timers in the network side

Section 9.2 Timers in the user side

Table 23 — Timers in the user side

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Section 9.2 Timers in the user side Table 23 — Timers in the user side

Section 9.2 Timers in the user side Table 23 — Timers in the user side (Part 2)

Annex A — SDL diagrams

Delete from the first paragraph: "a) For calls in the Overlap ... procedures of 5.3".

Delete from the first paragraph the first sentence of

"a) ..." ("The calls in the ... internally.").

Delete the second sentence of the Note following the

first paragraph ("Note — If the transfer mode ....").

Delete this section.

Delete row "T302".

Delete the second sentence in the "T310/NORMAL

STOP" cell ("If DISCONNECT ...").

Delete rows "T312" and "T321".

Delete Notes 4 and 5.

Add the following to the end of Note 6: "(see Annex

D)".

Delete the following rows:

• "T301";

• "T304".

Delete "SETUP ACKNOWLEDGE" from the "T303/

NORMAL STOP" cell.

Delete the reference to "Note 4" in the "T310/TIMER

NUMBER" cell.

Delete Notes 3 and 4.

Delete this section. NOTE: This section has not been addressed.

NIU-Forum Agreements On ISDN B-29
Section B.3.1 Compatibility checking with addressing information

Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 —Low layer and high layer compatibility

checking; compatibility assured

Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 — Low layer and high layer compatibility

checking; compatibility assured

Section B.3.4

User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Section B.3.4

User action figures

Annex C, Section C.l

Introduction

Annex C, Section C.2

Selection Not Supported

Annex C, Section C.3

Selection Supported

Annex C, Section C.3

Selection Supported

Annex C, Section C.3

Selection Supported

Annex C, Section C.3

Selection Supported

Annex D

Extensions for Symmetric Call Operation

Delete Note 2 ("If an incoming call, ... or

subaddress.").

Delete the reference to "(Note 1)" from the cell in the

first row of the second column.

Delete the "broadcast data link" column.

Delete the reference for "(Note 1)" in the cells in the

first row of the second and third columns.

Delete Notes 1 and 3 (ed. note: Note 3 is still referenced in the figures).

Delete "optional" from the first paragraph.

Delete this section.

Change the first paragraph to: "The user identifies the selected transit network in the SETUP message. One Transit network selection information element is used to convey a single network identification."

Delete the second ("The user may ..."), third ("As the

call ..."), and fourth ("No more than ...") paragraphs.

Delete the last sentence of the sixth paragraph ("The

diagnostic ...").

Delete the seventh ("A network may ...") and eighth

("If the transit ...") paragraphs.

Delete Annex D and replace with Attachment E of

this document.

B-30 NIU-Forum Agreements on ISDN
Annex E, Section E.3

Routing Not Supported

Annex E, Section E.4

Routing Supported

Annex E, Section E.4

Routing Supported

Add the following paragraph before at die end of this section: "When the requested facility can not be

provided an indication shall be returned in the first clearing message with cause 29 'facility rejected'."

Change the first sentence in the fourth paragraph to: "No more than two Network-specific facilities information elements may be used in a SETUP

message."

Delete the last sentence of the fifth paragraph ("The

diagnostic ...").

Annex F

D-channel Backup Procedure

Delete this Annex.

Annex G, Section G.l

Introduction

Add the following to the end of the first paragraph:

"Section 4.5.11 identifies the causes supported in NIU

90-302."

Annex G, Section G.3.8

Cause 46 "precedence call blocked"

Annex H, Section H.l

Introduction

Change "precedence circuits" to "preemptable

circuits".

Change the first paragraph to: "These are the only

recognized codings of the following information

elements."

Annex H, Section H.l

Introduction

Annex H

Examples of Information Elements Coding

Delete the last two bullet items from the second

paragraph.

Delete the following figures and sections:

• Figure "H.3 Coding for 7kHz Audio";

• Figure "H.6 Coding for synchronous 1472 kbit/s";

• Section H.3 Channel identification information

element;

• Section H.4 Called and Calling party subaddress

information element.

Annex I Use of Progress indicators

Annex I Use of Progress indicators

Annex I Use of Progress indicators

Annex M

Low Layer Compatibility Negotiation

Delete the fifth paragraph ("Progress indicator 4 ...").

Delete "or basic" from the left side of Figure 1.1 (between the TE and ISDN).

Delete "or basic" from the right side of Figure 1.1 (between ISDN and NT2).

Delete this Annex.

NIU-Forum Agreements On ISDN B-31
Annex N

Procedures for Establishment of Bearer Connection

Prior to Call Acceptance

Annex O

Optional Procedures for Bearer Service Change

Annex P, Section P.l Introduction

Annex P, Section P.l Introduction

Annex P, Section P.l Introduction

Annex P, Section P.2

Operator system access requested in Keypad facility

information

Section P.4

invalid request

Annex Q

Responding address requirements of the OSI network

layer service

Delete this Annex and replace with Attachment F of

this document.

Delete this Annex.

Delete "optional" from the first sentence in the first paragraph.

Change the last sentence of the first paragraph to: "These procedures apply to the speech, and 3.1 kHz

and audio bearer services."

Change the second paragraph to: "The user may

indicate a request for access to an operator or

attendant system using the Operator system access information element."

Delete this section.

Delete this section.

Delete this Annex.

B-32 NIU-Forum Agreements on ISDN
Attachment A

(of Appendix B)

1. General

1 .1 Scope and Purpose

This Implementation Agreement specifies a minimal subset of procedures and codepoints from the American National

Standards Tl.607- 1990 (Ref. [17]) for the establishment, maintenance, and clearing of ISDN connections at the user- to-network interface. This signalling standard is used to support the circuit-switched bearer services specified in ANS

Tl.604-1990*.

Terminals are not required to support all services. Switches will support all of the mandatory protocols and

codepoints in this implementation agreement. This does not preclude the support of additional services and

procedures. However, equipment must be able to interoperate with equipment supporting only this minimal subset.

1.1.1 Definitions

The ANS Tl.607-1990 (Ref. [17]) assumes that procedures apply generically to ISDN access interfaces, i.e., the document does not distinguish between basic and primary rates access interfaces. In addition, there are no references

to specific applications in that document The concept of equipment classes is introduced in this document to permit

certain procedures to be associated with a particular application or class of equipment, e.g., station equipment versus PBX. Specifically, two classes of equipment are defined on the basis of two fundamental attributes.

The first attribute relates to the possibility of an exchange of signals occurring beyond the public network's point

of contact with the interface (i.e., between the equipment directly connected to the public network and ISDN

terminals or telephones connected to that equipment). For example, some user equipment may support subtending

Basic Access digital subscriber loops and/or analog telephone loops. For Class I equipment, the network makes no

provision for such an arrangement and assumes the Class I equipment constitutes the endpoint of the communication.

Conversely, in the case of Class II equipment, the procedures at the network take into account that communication

between Class II equipment (with which it communicates directly) and other equipment (with which the network does

not have direct contact) may occur. As an example, Class II equipment may support digital and/or analog subscriber

loops. Use of Class II equipment also involves the possibility of having interworking occur beyond the equipment

with which the network has direct contact Therefore, it is reasonable for Class II equipment to provide the network

with an interworking notification, for both outgoing and incoming calls, when either the calling or called party

respectively, is a non-ISDN user. Class II equipment may also send an interworking notification if a private network

exists beyond the Class II equipment and interworking to a non-ISDN facility within that network takes place. When

an interface is associated with Class I equipment, it is assumed the multiple pieces of equipment may exist and

communicate with the network over the D-channel. However, in this case, all equipment is assumed to be ISDNcapable and is considered as the endpoint of the communication. Therefore, interworking notification should not be

accepted from Class I equipment.

The second attribute relates to the manner in which a SETUP message should be presented to the user equipment.

When Class I equipment is applied on a particular interfaces, the network should broadcast the SETUP message

associated with each call that terminates on that interface, since interaction between the network and multiple pieces

of user equipment should be supported. On the other hand, the network should not broadcast SETUP messages

associated with terminating calls to an interface on which Class II equipment is being used. Here, a single piece

of user equipment is assumed to be involved in all communication with the network.

Subject to further discussion. NIU-Forum Agreements On ISDN B-33
To the extent possible, it is desirable to have one set of requirements for ISDN call control apply to all ISDN user

configurations. However, in cases for which integrated procedures are not appropriate, the call control procedures

associated with Equipment Class I will differ from those associated with Equipment Class II. Unless otherwise

noted, the assumption should be that a particular procedure/capability should be provided for both classes of

equipment on both basic and primary rate access. However, use of the equipment class terminology permits

clarification of the circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capability applies only to a

subset of four possible configurations which are labeled as follows.

Class I Class n

IB IIB

IP IIP

In other words, a capability that applies to Class I equipment may be provided on basic access interfaces (IB) and/or

primary rate access interfaces (IP). Similarly, a capability that applies to Class II equipment may be provided on

basic access interfaces (IIB) and/or primary rate access interfaces (HP).

The notation shown in the table above is used within this implementation agreement to indicate when protocol or procedures are only expected to be supported for a particular equipment class and/or are limited to a particular type

of interface, i.e., basic or primary rate interface.

B-34 NIU-Forum Agreements on ISDN
Attachment B

(of Appendix B)

The various parts of the called party number information element should be coded as follows: — Type of number and numbering plan (octet 3) Bits 7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

All other values are reserved — Digits (octet 4, etc.)

Bits 7 6 5 4 3 2 1 Meaning

0 1 1 000 0 0

0 1 1 000 1 1 0 1 1 0 0 1 0 2

0 1 1 00 1 1 3 0 1 1 0 1 0 0 4

0 1 1 0 1 0 1 5 0 1 1 0 1 1 0 6

0 1 1 0 1 1 1 7

0 1 1 1 00 0 8

0 1 1 1 00 1 9

All other values are reserved

Digits should be represented by IA5 characters whose encoding is shown above.

In the network to user direction (n -> u), this IE will be always signaled in the SETUP message, and public network

interfaces will use only one codepoint: local number in ISDN. For private networks, this IE can contain the following codepoints: abbreviated type of number, and private numbering plan, and extra digits such A, B, C, and

D (as per IA5).

NIU-Forum Agreements On ISDN B-35
Attachment C

(of Appendix B)

The various parts of the calling party number information element should be coded as described below. — Type of number and numbering plan (octet 3) follows:

Bits 7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 0 1 0 0 1 1 International number in data numbering plan (Rec. X.121)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

110 10 0 1 Abbreviated Number in Private Numbering plan

All other values are reserved — Origin of number and presentation status (octet 3a) follows:

Bits 7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Presentation allowed of user-provided number,

number not screened

0 0 0 0 0 0 1 Presentation allowed of user-provided number,

number passed network screening

0 0 0 0 0 1 0 Presentation allowed of user-provided number,

number failed network screening

0 0 0 0 0 1 1 Presentation allowed of network-provided number

0 1 0 0 0 0 0 Presentation prohibited of user-provided number,

number not screened

0 1 0 0 0 0 1 Presentation prohibited of user-provided number,

number passed network screening

0 1 0 0 0 1 0 Presentation prohibited of user-provided number,

number failed network screening

0 1 0 0 0 1 1 Presentation prohibited of network-provided number

1 0 0 0 0 1 1 Number not available All other values are reserved

Note 1 — When octet 3a is omitted, the default value of the Number Presentation parameter for the signaled DN

value should be used, if it is available. If a value for this parameter is unavailable (i.e., the signaled DN value either

fails screening or is not screened by the SPCS), the presentation parameter value of the default DN should be used.

Note 2 — Octet 3a, bits 7 & 6, are for the Presentation indicator; bits 2 & 1 are for the screening indicator.

B-36 NIU-Forum Agreements on ISDN
— Digits (octet 4, etc.)

Digits should be represented by IA5 characters whose encoding is shown below:

Bits 7 6 5 4 3 2 1 Meaning

0 1 1 0 0 0 0 o

0 J 1 0yj 0\j 0\j x1 1 u 3 1

1 UU 1 0 2

0 1 1 0 0 11 3 0 1 1 0 100 4

0 1 1 0 10 1 5 0 1 1 0 110 6

0 1 1 0 111 7 0 1 1 1 000 8

0 1 1 100 1 9

All other values reserved

Codings At Originating Party Interface

The calling party number information element should only be accepted when in the SETUP message. When the type

of number and numbering plan indicator indicates "local number in the ISDN (E.164) numbering plan", the calling

party number information element should contain a 7-digit local number. When the type of number and numbering

plan indicator indicates "national number in the ISDN (E.164) numbering plan" the calling party number information

element should contain a 10-digit national number.

In the network to user direction (n -> u). the coding and delivery of this IE depends on the definition of the Calling

Line ID service. For private networks, this IE can contain the following codepoints: abbreviated type of number,

and private numbering plan, and extra digits such as A, B, C, and D. (as per IE5)

NIU-Forum Agreements On ISDN B-37
Attachment D

(of Appendix B)

Network — Specific facilities Information Element Examples

One recommended use for the Network Specific Facilities information element is to indicate which type of network

facilities are being invoked at the specified network. In this arrangement, many different facility types are allowed

to share a single Primary Rate Interface. Examples of the different DS-1 facility types allowed are:

Private Lines

Inwats Circuits Outwats Circuits Foreign Exchange (FX)

Tie Trunks

B-38 NIU-Forum Agreements on ISDN
Attachment E

(of Appendix B)

(editor's note: the sections contained in the brackets are unchanged from the original Annex D)

Annex D — Extensions for symmetric (peer-to-peer) call operation

This annex is part of NIU 90-302.

Symmetric call operation, or peer-to-peer call operation, shall be applied to the switches within a private network

where all switches, such as PBXs and central office switches serving business group users are considered as peers. For example, PBX-to-PBX, PBX-to-Centrex, Centrex-to-Centrex.

D.l Additional message handling

[In symmetric applications, the SETUP message will contain a Channel Identification information element indicating a particular B-channel to be used for the call. A point-to-point data link shall be used to carry the SETUP message.]

The following procedures shall be followed for symmetrical operation. The call control states followed should be

the symmetric states defined in section D.6.

D.l.l Call Request

The initiator of the call shall follow the network side procedures described in section 5.2.1.

D.l.2 B-channel Selection — symmetric interface

[Only B-channels controlled by the same D-channel will be the subject of the selection procedure. The selection procedure is as follows:

a) The SETUP message will indicate one of the following:

1) channel is indicated, no acceptable alternative, or

2) channel is indicated, any alternative is acceptable.

b) In cases 1) and 2), if the indicated channel is acceptable and available, the recipient of the SETUP

message reserves it for the call. In case 2), if the recipient of the SETUP message cannot grant the indicated channel, it reserves any other available B-channel associated with the D-channel.]

c) The recipient of the SETUP message indicates the selected B-channel in a CALL PROCEEDING,

message transferred across the interface and enters the Incoming Call Proceeding state. If an ALERTING or a CONNECT message is received in response to a SETUP message, the call should

continue to be processed, if the channel indicated is acceptable to the initiator of the call, in accordance with Sections D. 1 .5. 1 and D. 1 .8, respectively. Although these are acceptable responses, a CALL PROCEEDING message is the recommended response to a SETUP message.

d)

e) In case 1) if the indicated B-channel is not available, or in case 2) if no B-channel is available, a RELEASE COMPLETE message with a cause value of No. 44 "requested circuit/channel not

NIU-Forum Agreements On ISDN B-39
available" or No. 34 "no circuit/channel available" respectively is returned to the initiator of the

call. The sender of this message remains in the Null state.

f) If the channel indicated in the CALL PROCEEDING, message is unacceptable to the initiator of

the call, it clears the call in accordance with Section 5.3. If an ALERTING or a CONNECT

message is received in response to a SETUP message and the channel indicated is unacceptable

to the initiator of the call, it clears the call in accordance with section 5.3. Although these are acceptable responses, a CALL PROCEEDING message is the recommended response to a SETUP

message.

D.1.3 Invalid Call I/formation

The recipient of a SETUP message shall follow the network side procedures described in section 5.1.4.

D.1.4 Compatibility Checking

The recipient of a SETUP message shall follow the user side procedures described in section 5.2.2.

D.1.5 Call Confirmation

Upon receipt of a SETUP message, the equipment enters the Call Present state. Valid responses to the SETUP

message are a CALL PROCEEDING, or a RELEASE COMPLETE message. If an ALERTING or a CONNECT

message is received in response to a SETUP message, the call should continue to be processed, if the channel

indicated is acceptable to the initiator of the call, in accordance with Sections D.1.5. 1. and D.1.8, respectively.

Although these are acceptable responses, a CALL PROCEEDING message is the recommended response to a SETUP

message.

If the indicated channel is acceptable to the initiator of the call, the initiator shall attach to the indicated B-channel

according to the procedures in Annex N.

D.1.5.1 Receipt of CALL PROCEEDING and ALERTING

The Initiator of a call shall follow the network side procedures in section 5.2.5.2.

D.1.5.2 Clearing during incoming call establishment

The initiator of a call shall follow the network side procedures in section 5.2.5.3.

D.1J.3 Call Failure

The initiator of a call shall follow the network side procedures in section 5.2.5.4.

D.1.6 Clearing by the called user employing user-provided tones/announcements

When tones or announcements are provided in conjunction with call clearing, the party providing the in-band

treatment shall send a PROGRESS message.

D.1.7 Call Accept

The recipient of the call shall follow the user side procedures in section 5.2.7.

B-40 NIU-Forum Agreements on ISDN
D.1.8 Active indication

Upon receipt of a CONNECT message, the initiator of the call shall respond with a CONNECT ACKNOWLEDGE

message and enter the Active State (see sec. 5.2.8 network side procedures).

D.1.9 Call Clearing

D.1.9.1 Normal Call Clearing

Then sender of the DISCONNECT message shall follow the user side procedures in section 5.3.3. The recipient of

the DISCONNECT message shall follow the network side procedures in section 5.3.3.

D.2 Timers for call establishment

The timers described in section 9 table 7 shall be implemented along with the corresponding procedures for action's taken upon expiration of these timers. The default of T310 should be extended to 20 seconds. In addition, timer

T309 shall be mandatory.

D.3 Call collisions

In symmetric arrangements, call collisions can occur when both sides simultaneously transfer a SETUP message

indicating the same channel. In the absence of administrative procedures for assignment of channels to each side of the interface, the following procedure is employed.

First, one side of the interface will be designated the "controlling function" and the other side of the interface will be designated the "responding function". This can be accomplished by administering the Layer 2 Command/

Response bit. The controlling function is assigned "command" and has control of all the channels on the interface. The responding function is assigned "response". Second, for the three possible scenarios where the same channel

is indicated by combinations of preferred and exclusive from the responding function and controlling function, the following procedure is used:

a) "controlling function" preferred, "responding function" preferred:

The "controlling function" preferred channel is awarded and an alternate channel is indicated in the first response to the "responding function" SETUP message.

b) "controlling function" exclusive, "responding function" exclusive:

The "controlling function" exclusive channel is awarded and the "responding function" SETUP

message is cleared with a RELEASE COMPLETE message with cause No. 34 "no circuit/channel

available".

c) "controlling function" preferred, "responding function" exclusive; or "controlling function"

exclusive, "responding function" preferred:

The side of the interface with an exclusive indicator in a SETUP message is awarded the channel

and an alternate channel is indicated in the first response to the side using a preferred indicator in the SETUP message.

Channel identification is allowed in both directions for ALERTING and CONNECT.

NIU-Forum Agreements On ISDN B-41
DA Restart Procedures

See section 5.5.

D.5 Handling of Error Codes

See section 5.8.

D.6 Call control states for symmetric call operation

The state below are used in association with call references other than the global call reference, and apply to symmetric interfaces. The Outgoing side is the side of the symmetric interface that transmits the SETUP message,

while the incoming side is the recipient of the SETUP message.

D.6.1 Null State (SO)

No call exists.

D.6.2 Call Initiated (SI)

This state exists for an outgoing call when the Outgoing Side has sent a request for call establishment to the Incoming Side but has not yet received a response.

D.6.3 Outgoing Call Proceeding (S3)

This state exists for an outgoing call when the Outgoing Side has received acknowledgement that the Incoming Side

has received all call information necessary to effect call establishment.

D.6.4 Call Delivered (S4)

This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that the called user is being alerted.

D.6.5 Call Present (S6)

This state exists for an incoming call when the Incoming Side has not yet responded to the request from the Outgoing Side for call establishment.

D.6.6 Call Received (S7)

This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side that the called user

is being alerted.

D.6. 7 Connect Request (S8)

This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side that the called user has answered the call.

D.6.8 Incoming Call Proceeding (S9)

B-42 NIU-Forum Agreements on ISDN
This state exists for an incoming call when the Incoming Site has sent to the Outgoing Side acknowledgement thai

it has received all call information necessary to effect call establishment.

D.6.9 Active (S10)

This state exists for an incoming call when the Incoming Side has received from the Outgoing Side an acknowledgement of the indication that the called user has answered the call. This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that the called user has answered the

call.

D.6.10 Disconnect Request (Sll)

This state exists when a Side has sent to the other Side a request to disconnect the user information connection and

is waiting for a response.

D.6.11 Disconnect Indication (S12)

This state exists when a Side has received from the other Side a request to disconnect the user information

connection and has not yet responded.

D.6.12 Release Request (S19)

This state exists when a Side has sent to the other Side a request to release the call and has not yet received a response.

NIU-Forum Agreements On ISDN B-43
Attachment F

(of Appendix B)

Annex N — Procedures for Establishment of Bearer Connection Prior to Call Acceptance

This annex is part of NIU 90-302.

N.l General

For some applications, it is desirable to allow the completion of the transmission path associated with a bearer service

prior to receiving call acceptance. In particular, the completion of the backward direction for non-peer communication or both directions for peer-to-peer communication (see Annex D for peer-to-peer call operation) of

the transmission path prior to receipt of a CONNECT message from the called user may be desirable to:

1) allow the called user to provide internally-generated tones and announcements that are sent in-band

to the calling user prior to answer by the called user; or,

2) avoid speech clipping on connections involving an NT2 where delays may occur in relaying the answer indication within the called user equipment.

The procedures described in this annex are applicable to the speech and 3.1 kHz audio bearer services, for non-peer communication of both directions for peer-to-peer communication (see Annex D for peer-to-peer call operation).

N.2 Procedures

Completion of the transmission path prior to receipt of a call acceptance indication shall be provided in three ways:

1 ) For peer-to-peer communications on receipt of a CALL PROCEEDING message or an ALERTING

message indicating completion of successful channel negotiation.

2) For non-peer communication on receipt of an ALERTING message; and

3) For non-peer communications on receipt of a PROGRESS message.

When criteria (1) is used to determine that a transmission path should be established, the sender of the SETUP

message shall connect, both directions of the transmission path upon receipt of either a CALL PROCEEDING

message or an ALERTING message containing an acceptable B-channel indication.

When criteria (2) is used to establish the transmission path, the network shall connect, the backward direction of the transmission path upon receipt of an ALERTING message assuming channel negotiation procedures have been

successful.

When criteria (3) is used to establish the transmission path, the network shall connect, the backward direction of the transmission path upon receipt of a PROGRESS message containing progress indicator 1 "call is not end-to-end

ISDN; further call progress information may be available in-band," assuming that the user has already returned a CALL PROCEEDING message and channel negotiation procedures have been successful.

If an ALERTING message follows a PROGRESS message containing progress indicator 1, it should be treated as an unexpected message.

B-44 NIU-Forum Agreements on ISDN
The network may choose to further restrict when message(s) will result in establishment of the transmission path.

These restrictions may be imposed on a per interface basis to provide an administrative means for limiting potential

misuse of the early connection capabilities.

NIU-Forum Agreements On ISDN B-45

NIST-114A

(REV. 3-89) U.S. DEPARTMENT OF COMMERCE

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

BIBLIOGRAPHIC DATASHEET

1. PUBLICATION OR REPORT NUMBER NIST/SP- 500/195

2. PERFORMING ORGANIZATION REPORT NUMBER

3. PUBLICATION DATE September 1991

4. TITLE AND SUBTITLE

North American ISDN Users' Forum Agreements on ISDN

S. AUTHOR(S)

Shukri Wakid and Kathleen M. Roberts

6. PERFORMING ORGANIZATION (IF JOINT OR OTHER THAN NIST, SEE INSTRUCTIONS)

U.S. DEPARTMENT OF COMMERCE

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

GAITHERSBURG, MD 20899

7. CONTRACT/GRANT NUMBER

8. TYPE OF REPORT AND PERIOD COVERED

Final

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (STREET, CITY, STATE, ZIP)

Same as item #6,

10. SUPPLEMENTARY NOTES

DOCUMENT DESCRIBES A COMPUTER PROGRAM; SF-185, FIPS SOFTWARE SUMMARY, IS ATTACHED.

11. ABSTRACT (A 200-WORD OR LESS FACTUAL SUMMARY OF MOST SIGNIFICANT INFORMATION. IF DOCUMENT INCLUDES A SIGNIFICANT BIBLIOGRAPHY OR

LITERATURE SURVEY, MENTION IT HERE.)

This document compiles the existing NIU-Forum agreements for an ISDN developed and

approved in the NIU-Forum as of November 1990. These agreements cover: Layer 1 BRI at the U, and S/T reference points; Layer 1 PRI at the U reference point;

Layer 2 BRI and PRI; Layer 3 BRI Basic Call Control for Class I equipment;

Layer 3 PRI Basic Call Control for Class II equipment; and Generic. Control

procedures for Class I BRI Supplementary Services. In addition, this document

references the Conformance tests which have been completed by the NIU-Forum.

These include: Layer 1 BRI S/T interface; and Layer 2 BRI LAPD. Finally, this

document contains the Application Profile for four of the Incoming Call Management

applications which have been submitted to the NIU-Forum.

12. KEY WORDS (6 TO 12 ENTRIES; ALPHABETICAL ORDER; CAPITALIZE ONLY PROPER NAMES; AND SEPARATE KEY WORDS BY SEMICOLONS)

application profile; basic call control; basic rate interface; conformance test;

customer-premises equipment; data link layer; implementation agreements; ISDN; LAPD;

network layer; network termination; NIU-Forum; physical layer; primary rate

interface; S/T interface; terminal adaptor; terminal equipment; U Interface.

13. AVAILABILITY UNLIMITED FOR OFFICIAL DISTRIBUTION. DO NOT RELEASE TO NATIONAL TECHNICAL INFORMATION SERVICE (NTIS). ORDER FROM SUPERINTENDENT OF DOCUMENTS, U.S. GOVERNMENT PRINTING OFFICE, WASHINGTON, DC 20402. ORDER FROM NATIONAL TECHNICAL INFORMATION SERVICE (NTIS), SPRINGFIELD, VA 22161.

14. NUMBER OF PRINTED PAGES 150

15. PRICE

ELECTRONIC FORM

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SYSTEMS TECHNOLOGY

Superintendent of Documents

Government Printing Office

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in the series: National Institute of Standards and Technology Special Publication 500-.

Name

Company

Address

City State Zip Code

(Notification key N-503)

iX U.S. GOVERNMENT PRINTING OFFICE: 1991 — 2 8 1- 5 5 7 1+0 490



Ill JL LJ A. Technical Publications

Periodical

Journal of Research of the National Institute of Standards and Technology — Reports NIST

research and development in those disciplines of the physical and engineering sciences in which

the Institute is active. These include physics, chemistry, engineering, mathematics, and computer

sciences.

Papers cover a broad range of subjects, with major emphasis on measurement methodology and

the basic technology underlying standardization. Also included from time to time are survey

articles on topics closely related to the Institute's technical and scientific programs. Issued six times a year.

Nonperiodicals

Monographs — Major contributions to the technical literature on various subjects related to the

Institute's scientific and technical activities. Handbooks — Recommended codes of engineering and industrial practice (including safety codes)

developed in cooperation with interested industries, professional organizations, and regulatory

bodies.

Special Publications — Include proceedings of conferences sponsored by NIST, NIST annual

reports, and other special publications appropriate to this grouping such as wall charts, pocket

cards, and bibliographies.

Applied Mathematics Series — Mathematical tables, manuals, and studies of special interest to

physicists, engineers, chemists, biologists, mathematicians, computer programmers, and others

engaged in scientific and technical work.

National Standard Reference Data Series — Provides quantitative data on the physical and chemical

properties of materials, compiled from the world's literature and critically evaluated. Developed

under a worldwide program coordinated by NIST under the authority of the National Standard

Data Act (Public Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data

(JPCRD) is published bi-monthly for NIST by the American Chemical Society (ACS) and the

American Institute of Physics (AIP). Subscriptions, reprints, and supplements are available from

ACS, 1155 Sixteenth St., NW., Washington, DC 20056.

Building Science Series — Disseminates technical information developed at the Institute on building

materials, components, systems, and whole structures. The series presents research results, test methods, and performance criteria related to the structural and environmental functions and the

durability and safety characteristics of building elements and systems.

Technical Notes — Studies or reports which are complete in themselves but restrictive in their treatment of a subject. Analogous to monographs but not so comprehensive in scope or definitive

in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NIST under the sponsorship of other government agencies.

Voluntary Product Standards — Developed under procedures published by the Department of

Commerce in Part 10, Title 15, of the Code of Federal Regulations. The standards establish

nationally recognized requirements for products, and provide all concerned interests with a basis

for common understanding of the characteristics of the products. NIST administers this program

as a supplement to the activities of the private sector standardizing organizations.

Consumer Information Series — Practical information, based on NIST research and experience,

covering areas of interest to the consumer. Easily understandable language and illustrations provide useful background knowledge for shopping in today's technological marketplace.

Order the above NIST publications from: Superintendent of Documents, Government Printing Office,

Washington, DC 20402.

Order the following NIST publications— FIPS and NISTIRs—from the National Technical Information

Service, Springfield, VA 22161.

Federal Information Processing Standards Publications (FIPS PUB) — Publications in this series

collectively constitute the Federal Information Processing Standards Register. The Register serves

as the official source of information in the Federal Government regarding standards issued by

NIST pursuant to the Federal Property and Administrative Services Act of 1949 as amended,

Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 11717 (38 FR 12315,

dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NIST Interagency Reports (NISTIR)-A special series of interim or final reports on work

performed by NIST for outside sponsors (both government and non-government). In general,

initial distribution is handled by the sponsor; public distribution is by the National Technical

Information Service, Springfield, VA 22161, in paper copy or microfiche form.
Institute of Standards and technology

burg, MD 20899

Business

ir Private Use $300