Call Control Interface (CCI)

Call Control Interface

Preface

Security Warning

Permission to use, copy and distribute this documentation without modification, for any purpose and without fee or royalty is hereby granted, provided that both the above copyright notice and this permission notice appears in all copies and that the name of OpenSS7 Corporation not be used in advertising or publicity pertaining to distribution of this documentation or its contents without specific, written prior permission. OpenSS7 Corporation makes no representation about the suitability of this documentation for any purpose. It is provided “as is” without express or implied warranty.

OpenSS7 Corporation disclaims all warranties with regard to this documentation including all implied warranties of merchantability, fitness for a particular purpose, non-infringement, or title; that the contents of the document are suitable for any purpose, or that the implementation of such contents will not infringe on any third party patents, copyrights, trademarks or other rights. In no event shall OpenSS7 Corporation be liable for any direct, indirect, special or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with any use of this document or the performance or implementation of the contents thereof.

OpenSS7 Corporation is making this documentation available as a reference point for the industry. While OpenSS7 Corporation believes that these interfaces are well defined in this release of the document, minor changes may be made prior to products conforming to the interfaces being made available.

Abstract

This document is a Specification containing technical details concerning the implementation of the Call Control Interface (CCI) for OpenSS7. It contains recommendations on software architecture as well as platform and system applicability of the Call Control Interface (CCI).

This document specifies a Call Control Interface (CCI) Specification in support of the OpenSS7 Integrated Service Digital Network (ISDN) and ISDN User Part (ISUP) protocol stacks.¹ It provides abstraction of the call control interface to these components as well as providing a basis for call control for other call control signalling protocols.

Purpose

The purpose of this document is to provide technical documentation of the Call Control Interface (CCI). This document is intended to be included with the OpenSS7 STREAMS software package released by OpenSS7 Corporation. It is intended to assist software developers, maintainers and users of the Call Control Interface (CCI) with understanding the software architecture and technical interfaces that are made available in the software package.

Intent

It is the intent of this document that it act as the primary source of information concerning the Call Control Interface (CCI). This document is intended to provide information for writers of OpenSS7 Call Control Interface (CCI) applications as well as writers of OpenSS7 Call Control Interface (CCI) Users.

Audience

The audience for this document is software developers, maintainers and users and integrators of the Call Control Interface (CCI). The target audience is developers and users of the OpenSS7 SS7 and ISDN stack.

Disclaimer

Although the author has attempted to ensure that the information in this document is complete and correct, neither the Author nor OpenSS7 Corporation will take any responsibility in it.

Revision History

Take care that you are working with a current version of this documentation: you will not be notified of updates. To ensure that you are working with a current version, check the OpenSS7 Project website for a current version.

Only the texinfo or roff source is controlled. A printed (or postscript) version of this document is an UNCONTROLLED VERSION.

     cci.texi,v
     Revision 0.9.2.14  2008-09-20 11:04:27  brian
     - added package patchlevel
     
     Revision 0.9.2.13  2008-08-03 06:03:29  brian
     - protected agains texinfo commands in log entries
     
     Revision 0.9.2.12  2008-08-03 05:05:13  brian
     - conditional @syncodeindex frags out automake, fails distcheck
     
     Revision 0.9.2.11  2008-07-11 09:36:11  brian
     - updated documentation
     
     Revision 0.9.2.10  2008-04-29 07:10:36  brian
     - updating headers for release
     
     Revision 0.9.2.9  2007/08/14 12:16:57  brian
     - GPLv3 header updates
     
     Revision 0.9.2.8  2007/06/27 08:42:05  brian
     - added MTPI spec document
     
     Revision 0.9.2.7  2007/06/17 01:55:58  brian
     - updates for release, remove any later language
     
     Revision 0.9.2.6  2006/08/26 09:17:03  brian
     - better release file generation
     
     Revision 0.9.2.5  2006/08/23 11:02:50  brian
     - corrections
     
     Revision 0.9.2.4  2006/08/22 12:44:12  brian
     - documentation updates
     
     Revision 0.9.2.3  2006/01/04 08:04:11  brian
     - corrected documentation
     
     Revision 0.9.2.2  2006/01/03 12:00:35  brian
     - documentation updates
     
     Revision 0.9.2.1  2006/01/02 11:51:36  brian
     - new CCI texinfo file
     
     Revision 0.8.2.3  2003/07/12 19:12:29  brian
     Update draft revision 4.
     
     Revision 0.8.2.2  2003/03/23 19:56:50  brian
     Finalizing isdn.
     
     Revision 0.8.2.1  2003/02/21 12:00:35  brian
     Updated primitive interface and Q.764 conformance.
     
     Revision 0.8  2002/11/17 15:06:36  brian
     Added initial documentation for call control interface.

1 Introduction

This document specifies a STREAMS-based kernel-level instantiation of the ITU-T Call Control Interface (CCI) definition. The Call Control Interface (CCI) enables the user of a call control service to access and use any of a variety of conforming call control service providers without specific knowledge of the provider's protocol. The service interface is designed to support any network call control protocol and user call control protocol. This interface only specifies access to call control service providers, and does not address issues concerning call control and circuit management, protocol performance, and performance analysis tools.

This specification assumes that the reader is familiar with ITU-T state machines and call control interfaces (e.g., Q.764, Q.931), and STREAMS.

1.1 Related Documentation

• 1993 ITU-T Q.764 Recommendation
• 1993 ITU-T Q.931 Recommendation
• System V Interface Definition, Issue 2 - Volume 3

1.1.1 Role

This document specifies an interface that supports the services provided by the Integrated Services Digital Network (ISDN) and ISDN User Part (ISUP) for ITU-T applications as described in ITU-T Recommendation Q.931 and ITU-T Recommendation Q.764.² These specifications are targeted for use by developers and testers of protocol modules that require call control service.

1.2 Definitions, Acronyms, Abbreviations

Application Context

Object Identifier

Calling Party

The Calling Party.

Called Party

The Called Party.

Operations Class

One of 5 ISO/OSI Transport Protocol Classes.

MAP

Mobile Applications Part

TCAP

Transaction Capabilities Application Part

SCCP

Service Connection Control Part

MTP

Message Transfer Part

TR

Transaction Sub-Layer

TC

Component Sub-Layer

IMSI

International Mobile Station Identifier

MSISDN

Mobile Station ISDN Directory Number (E.164)

ITU

International Telecommunications Union

ITU-T

International Telecommunications Union – Telecom Sector

OSI

Open Systems Interconnect

ISO

International Organization for Standardization

MAP User

A user of the Mobile Application Part (MAP) Interface.

MAP Provider

A provider of the Mobile Application Part (MAP) Interface.

MAPI

The Mobile Application Part (MAP) Interface.

MS

Mobile Station.

Components

Transaction components as defined in ITU-T Recommendation Q.771.

QoS

Quality of Service

STREAMS

A communication services development facility first available with UNIX System V Release 3.

2 The Call Control Layer

The Call Control Layer provides the means to manage the connection and disconnection of calls. It is responsible for the routing and management of call control signalling between call control-user entities.

2.1 Model of the CCI

The CCI defines the services provided by the call control layer to the call control-user at the boundary between the call control provider and the call control user entity. The interface consists of a set of primitives defined as STREAMS messages that provide access to the call control layer services, and are transferred between the CCS user entity and the CCS provider. These primitives are of two types; ones that originate from the CCS user, and others that originate from the CCS provider. The primitives that originate from the CCS user make requests to the CCS provider, or respond to an indication of an event of the CCS provider. The primitives that originate from the CCS provider are either confirmations of a request or are indications to the CCS user that an event has occurred. Figure 1 shows the model of the CCI.

The CCI allows the CCS provider to be configured with any call control layer user (such as an ISDN user call control application) that also conforms to the CCI. A call control layer user can also be a user program that conforms to the CCI and accesses the CCS provider via putmsg(2s) and getmsg(2s) system calls.

2.2 CCI Services

The features of the CCI are defined in terms of the services provided by the CCS provider, and the individual primitives that may flow between the CCS user and the CCS provider.

The services supported by the CCI are based on three distinct modes of communication, user-network interface (UNI) User mode, user-network interface (UNI) Network mode, and network-network interface (NNI). In addition, the CCI supports services for local management.

2.2.1 UNI

The main features of the User-Network Interface mode of communication are:

1. It is call oriented.
2. It employs facility associated signalling in that the signalling interface and circuits that are controlled by that signalling interface are bound by physical configuration. (For example, 23B+D, 2B+D).
3. The protocol has two aspects to the interface: one side of the interface follows the User protocol whereas the other side of the interface follows the Network protocol.
4. The user side of the protocol has no formal maintenance or monitoring procedures and therefore reports most if not all system events to the user.
5. The network side of the protocol has formal maintenance and monitoring procedures and therefore reports most if not all system events to maintenance.

2.2.1.1 Address Formats

Addresses specifying all the calls and channels known to the provider are specified with scope ISDN_SCOPE_DF and identifier zero (0).

Customer/Provider Group

A customer/provider group has a different interpretation on the User and Network side of the call control interface. In User mode, the provider group is a group of all equipment groups that are serviced by the same network provider. In Network mode, the customer group is a group of all equipment groups to which the same service is provided to the same customer by the network.

Customer/provider groups are identifier using a unique customer/provider group identifier within the CCS provider. Addresses specifying all of the equipment groups in a customer/provider group and specified with scope ISDN_SCOPE_XG and the customer/provider group identifier.

Equipment Group

An equipment group is a group of all transmission groups (B- and D-channels) terminating at the same location. For User mode this corresponds to all the B- and D-channels terminating on the same network provider exchange. For Network mode this corresponds to all the B- and D-channels terminating on the same customer site.

Equipment groups are identified using a unique equipment group identifier within the CCS provider. Addresses specifying all of the B- and D-channels making up an equipment group are specified with scope ISDN_SCOPE_EG and the equipment group identifier.

Facility Group

A facility group is a group of D-channels (data links) controlling a set of B-channels. This corresponds to the signalling interface. For regular interfaces, a signalling relation consists of a single signalling interface. Where multiple signalling interfaces are used to control the same range of channels (e.g. primary and backup interfaces), all signalling interfaces belong to the same facility group.

The B-channels that make up a facility group are channels that share the same dial plan and routing characteristics for telephone calls. A facility group is associated with an equipment group.

Facility groups are identified using a unique facility group identifier within the CCS provider. Addresses specifying all of the channels in a facility group are specified with scope ISDN_SCOPE_FG and the facility group identifier. An ISDN Channel Identifier is only unique within a facility group.

Transmission Group

A transmission group is the group of all D- and B-Channels associated with a given Q.931 signalling interface. For example, a typical PRI interface would consist of 23B+D, where there is one signalling interface (the D-Channel) with 23 B-Channels associated with the D-Channel. The 1 D-Channel and 23 B-Channels form a single transmission group associated with the physical interface. Every D- or B-Channel belongs to one transmission group and occupies a single time slot within that transmission group.

Transmission groups are identified using a unique transmission group identifier within the CCS provider. Addresses specifying all of the channels in a transmission group are specified with scope ISDN_SCOPE_TG and the transmission group identifier. Transmission groups can also be specified using scope ISDN_SCOPE_FG and the Channel Identifier of one of the channels in the facility group.

Channel

A channel refers to a specific B-Channel within a transmission and facility group.

Channels are identified using a unique channel identifier within the CCS provider. Addresses specifying a specific channel are specified with scope ISDN_SCOPE_CH and the channel identifier. Channels can also be specified using scope ISDN_SCOPE_FG, the facility group identifier, and the Channel Identity of the channel within the facility group.

Data Link

A data link corresponds to a specific D-channel used for the control of channels. Data links can be grouped into facility groups.

Data links are identified using a unique data link identifier within the CCS provider. Addresses specifying all of the channels controlled by a data link are specified with scope ISDN_SCOPE_DL and the data link identifier.

2.2.2 NNI

The main features of the Network-Network Interface mode of communication are:

1. It is circuit oriented.
2. It employs quasi-associated signalling in that the path taken by signalling and the path taken by the circuits are not necessarily related.
3. The protocol has one aspect and is peer-to-peer: that is, both sides of a signalling interface follow the same protocol in the same way.
4. The network side of the protocol has formal maintenance and monitoring procedures and therefore reports most if not all system events to maintenance.

2.2.2.1 Address Formats

Addresses specifying all of the circuits known to the provider are specified with scope ISUP_SCOPE_DF and identifier zero (0).

Signalling Points

A signalling point is the SS7 signalling point (central office) that the provider represents. A CCS provider can represent more than one signalling point.

A signalling point is identifier using a unique signalling point identifier within the CCS provider. Addresses specifying all of the circuits in signalling point are specified with scope ISUP_SCOPE_SP and the signalling point identifier.

Signalling Relations

A signalling relation is a relationship between a local signalling point and a remote signalling point. A signalling relation consists of a single signalling interface.

Signalling relations are identified using a unique signalling relation identifier within the CCS provider. Addresses specifying all of the circuits in a signalling relation are specified with scope ISUP_SCOPE_SR and the signalling relation identifier. An ISUP Circuit Identification Code is only unique within a signalling relation.

Trunk Groups

A trunk group is a group of circuits that share the same routing characteristics for telephone calls. A trunk group is associated with a signalling relation. For the NNI, a signalling relation is the combination of local MTP Point Code and remote MTP Point Code.

A trunk group is identified using a unique trunk group identifier within the CCS provider. Addresses specifying all of the circuits in a trunk group are specified with scope ISUP_SCOPE_TG and the trunk group identifier.

Circuit Groups

A circuit group is a group of circuits that share the same common transmission facility (e.g, E1 span) and is therefore impacted by any failure of the transmission facility. All of the individual channels of an E1 span that are used to carry calls are members of the circuit group.

Circuits groups are identified using a unique circuit group identifier within the CCS provider. Addresses specifying all of the circuits within a circuit group are specified with scope ISUP_SCOPE_CG and the circuit group identifier. Circuit groups can also be specified using scope ISUP_SCOPE_SR and the Circuit Identification Code of one of the circuits within the circuit group.

Circuits

A circuit refers to a specific time slot within a digital facility.

Circuits are identified using a unique circuit identifier within the CCS provider. Addresses specifying a specific circuit are specified with scope ISUP_SCOPE_CT and the circuit identifier. Circuits can also be specified using scope ISUP_SCOPE_CG, the circuit group identifier, and the Circuit Identification Code of the circuit within the group. Circuits can also be specified using scope ISUP_SCOPE_SR, the signalling relation identifier, and the Circuit Identification Code of the circuit within the signalling relation.

2.2.3 Local Management

The CCI specifications also define a set of local management functions that apply to UNI and NNI modes of communication. These services have local significance only. Tables 1, 2 and 3 summarizes the CCI service primitives by their state and service.

3 CCI Services Definition

This section describes the services of the CCI primitives. Time-sequence diagrams that illustrate the sequence of primitives are included. (Conventions for the time-sequence diagrams are defined in ITU-T X.210.) The format of the primitives will be defined later in this document.

3.1 Local Management Services Definition

The services defined in this section are outside the scope of international standards. These services apply to UNI (User and Network), and NNI modes of communication. They are invoked for the initialization/de-initialization of a stream connected to the CCS provider. They are also used to manage options supported by the CCS provider and to report information on the supported parameter values.

3.1.1 Call Control Information Reporting Service

This service provides information on the options supported by the CCS provider.

• CC_INFO_REQ: This primitive request that the CCS provider return the values of all the supported protocol parameters. This request may be invoked during any phase.
• CC_INFO_ACK: This primitive is in response to the N_INFO_REQ primitive and returns the values of the supported protocol parameters to the CCS user.

The sequence of primitive for call control information management is shown in Figure 4.

3.1.2 CCS Address Service

This service allows a CCS user to determine the bound call control address and the connected call control address for a given call reference associated with a stream. It permits the CCS user to not necessarily retain this information locally, and allows the CCS user to determine this information from the CCS provider at any time.

• CC_ADDR_REQ: This primitive requests that the CCS provider return information concerning which call control address the CCS user is bound as well as the call control address upon which the CCS user is currently engaged in a call for the specified call reference.
• CC_ADDR_ACK: This primitive is in response to the CC_ADDR_REQ primitive and indicates to the CCS user the requested information.

The sequence of primitives is shown in Figure 5.

3.1.3 CCS User Bind Service

This service allows a call control address to be associated with a stream. It allows the CCS user to negotiate the number of setup indications that can remain unacknowledged for that CCS user (a setup indication is considered unacknowledged while it is awaiting a corresponding setup response or release request from the CCS user). This service also defines a mechanism that allows a stream (bound to a call control address of the CCS user) to be reserved to handle incoming calls only. This stream is referred to as the listener stream.

• CC_BIND_REQ: This primitive request that the CCS user be bound to a particular call control address and negotiate the number of allowable outstanding setup indications for that address.
• CC_BIND_ACK: This primitive is in response to the CC_BIND_REQ primitive and indicates to the user that the specified CCS user has been bound to a call control address.

The sequence of primitives is shown in Figure 6 .

3.1.4 CCS User Unbind Service

This service allows the CCS user to be unbound from a call control address.

• CC_UNBIND_REQ: This primitive request that the CCS user be unbound from the call control address that it had previously been bound to.

The sequence of primitives is shown in Figure 7.

3.1.5 Receipt Acknowledgement Service

• CC_OK_ACK: This primitive indicates to the CCS user that the previous (indicated) CCS user originated primitive was received successfully by the CCS provider.

An example showing the sequence of primitives for successful receipt acknowledgement is depicted in Figure 8.

3.1.6 Options Management Service

This service allows the CCS user to manage options parameter values associated with the CCS provider.

• CC_OPTMGMT_REQ: This primitive allows the CCS user to select default values for options parameters within the range supported by the CCS provider.

Figure 9 shows the sequence of primitives for call control options management.

3.1.7 Error Acknowledgement Service

• CC_ERROR_ACK: This primitive indicates to the CCS user that a non-fatal error has occurred in the last CCS user originated request or response primitive (listed in Figure 10), on the stream.

Figure 10 shows the sequence or primitives for the error management primitive.

3.2 User-Network Interface Services Definition

This section describes the required call control service primitives that define the UNI interface.

The queue model for UNI is discussed in more detail in ITU-T Q.931. For Q.931 specific conformance considerations, see Addendum for Q.931 Conformance.

The queue model represents the operation of a call control connection in the abstract by a pair of queues linking the two call control addresses. There is one queue for each direction of signalling transfer. The ability of a user to add objects to a queue will be determined by the behaviour of the user removing objects from that queue, and the state of the queue. The pair of queues is considered to be available for each potential call. Objects that are entered or removed from the queue are either as a result of interactions at the two call control addresses, or as the result of CCS provider initiatives.

• A queue is empty until a setup object has been entered and can be returned to this state, with loss of its contents, by the CCS provider.
• Objects may be entered into a queue as a result of the action of the source CCS user, subject to control by the CCS provider.
• Objects may also be entered into a queue by the CCS provider.
• Objects are removed from the queue under the control of the receiving CCS user.
• Objects are normally removed under the control of the CCS user in the same order as they were entered except:
  • if the object is of a type defined to be able to advance ahead of the preceding object, or
  • if the following object is defined to be destructive with respect to the preceding object on the queue. If necessary, the last object on the queue will be deleted to allow a destructive object to be entered \- they will therefore always be added to the queue. For example, "release" objects are defined to be destructive with respect to all other objects.

Table 3 shows the ordering relationship among the queue model objects.

3.2.1 Call Setup Phase

A pair of queues is associated with a call between two call control addresses (facility group and channel(s)) when the CCS provider receives a CC_SETUP_REQ primitive at one of the call control addresses resulting in a setup object being entered into the queue. The queues will remain associated with the call until a CC_RELEASE_REQ or CC_RELEASE_IND (resulting in a release object) is either entered into or removed from a queue. Similarly, in the queue from the called CCS user, objects can be entered into the queue only after the setup object associated with the CC_SETUP_RES has been entered into the queue. Alternatively, the called CCS user can enter a release object into the queue instead of the setup object to terminate the call. The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the destination CCS user is unable to accept the CC_SETUP_IND (see call failure and call reject primitive definitions).

3.2.1.1 User Primitives for Successful Call Setup

• CC_SETUP_REQ: This primitive requests that the CCS provider setup a call to the specified destination (called party number).
• CC_MORE_INFO_REQ: This primitive requests that the CCS provider provide more information to establish the call. This primitive is not issued for en bloc signalling mode.
• CC_INFORMATION_REQ: This primitive requests that the CCS provider provide more information (digits) in addition to the destination (called party number) already specified in the CC_SETUP_REQ and subsequent CC_INFORMATION_REQ primitives. This primitive is not issued for en block signalling mode.
• CC_SETUP_RES: This primitive requests that the CCS provider accept a previous call setup indication on the specified stream.

3.2.1.2 Provider Primitives for Successful Call Setup

• CC_CALL_REATTEMPT_IND: This primitive indicates to the calling CCS user that an event has caused call setup to fail on the selected address and that a reattempt should be made (or has been made) on another call control address (facility group and channel(s)). This primitive is only issued by the CCS provider if the CCS user is bound at the channel level rather than the facility group or equipment group levels.
• CC_SETUP_IND: This primitive indicates to the CCS user that a call setup request has been made by a user at the specified call control address (facility group and channel(s)).
• CC_MORE_INFO_IND: This primitive indicates to the CCS user that more information is required to establish the call. This primitive is not issued for en block signalling mode.
• CC_INFORMATION_IND: This primitive indicates to the CCS user more information (digits) in addition to the destination (called party number) already indicated in the CC_SETUP_IND and subsequent CC_INFORMATION_IND primitives. This primitive is not issued for en block signalling mode.
• CC_INFO_TIMEOUT_IND: This primitive indicates to the called CCS user that a timeout occurred while waiting for additional information (called party number). The receiving CCS User should determine whether sufficient address digits have been received and either disconnect the call with the CC_DISCONNECT_REQ primitive or continue the call with CC_SETUP_RES. This primitive is not issued for en block signalling mode.
• CC_SETUP_CON: This primitive indicates to the CCS user that a call setup request has been confirmed on the indicated call control address (channel(s)).

If the CCS provider is unable to establish a call, it indicates this to the request by a CC_CALL_REATTEMPT_IND. This is shown in Figure 14.

The sequence of primitives for call reattempt on dual seizure are shown in Figure 15.

3.2.2 Call Establishment Phase

During the call establishment phase, a pair of queues has already been associated with the call between the selected call control addresses (facility group and channel(s)) during the setup phase.

3.2.2.1 User Primitives for Successful Call Establishment

• CC_PROCEEDING_REQ: This primitive requests that the CCS provider indicate to the call control peer that the call is proceeding and that all necessary information has been received.
• CC_ALERTING_REQ: This primitive requests that the CCS provider indicate to the call control peer that the terminating user is being alerted.
• CC_PROGRESS_REQ: This primitive requests that the CCS provider indicate to the call control peer that the specified progress event has occurred.
• CC_IBI_REQ (CC_DISCONNECT_REQ): This primitive requests that the CCS provider indicate to the call control peer that in-band information is now available. This will also invite the peer to release the call.
• CC_CONNECT_REQ: This primitive requests that the CCS provider indicate to the call control peer that the call has been connected.
• CC_SETUP_COMPLETE_REQ: This primitive request that the CCS provider complete the call setup.

3.2.2.2 Provider Primitives for Successful Call Establishment

• CC_PROCEEDING_IND: This primitive indicates to the CCS user that the call control peer is proceeding and that all necessary information has been received.
• CC_ALERTING_IND: This primitive indicates to the CCS user that the terminating user is being alerted.
• CC_PROGRESS_IND: This primitive indicates to the CCS user that the specified progress event has occurred.
• CC_IBI_IND (CC_DISCONNECT_IND): This primitive indicates to the CCS user that in-band information is now available. It also invites the CCS user to release the call.
• CC_CONNECT_IND: This primitive indicates to the CCS user that the call has been connected.
• CC_SETUP_COMPLETE_IND: This primitive indicates to the CCS user that the call has completed setup.

3.2.2.3 Provider Primitives for Successful Call Setup

The sequence of primitives in a successful call establishment is defined by the time sequence diagrams as shown in Figure 16.

3.2.3 Call Established Phase

Flow control of the call is done by management of the queue capacity, and by allowing objects of certain types to be inserted to the queues, as shown in Table X.

3.2.3.1 Suspend Service

User Primitives for Suspend Service

• CC_SUSPEND_REQ: This primitives requests that the CCS provider temporarily suspend a call at the network, or indicate user suspension of a call.
• CC_SUSPEND_RES: This primitive indicates to the CCS provider that the CCS user (Network) is accepting the request for suspension of the call.
• CC_SUSPEND_REJECT_REQ: This primitive indicates to the CCS provider that the CCS user (Network) is rejecting the request for suspension of the call, and the cause for rejection.

Provider Primitives for Suspend Service

• CC_SUSPEND_IND: This primitive indicates to the CCS user that an established call has been temporarily suspended at the network, or by the remote user.
• CC_SUSPEND_CON: This primitive confirms to the requesting CCS user (User) that the call has been temporarily suspended at the network.
• CC_SUSPEND_REJECT_IND: This primitive indicates to the requesting CCS user (User) that the request to suspend the call has been rejected by the network, and the cause for rejection.

Figure 17 and Figure 18 show the sequence of primitives for suspend service. The sequence of primitives may remain incomplete if a CC_RESET or a CC_RELEASE primitive occurs.

The sequence of primitives to suspend a call is defined in the time sequence diagram as shown in Figure 17 and Figure 18.

3.2.3.2 Resume Service

User Primitives for Resume Service

• CC_RESUME_REQ: This primitive request that the CCS provider resume a previously network suspended call, or indicates that the user has resumed a call.
• CC_RESUME_RES: This primitive indicates to the CCS provider that the CCS user (Network) is accepting the request for resumption of the call.
• CC_RESUME_REJECT_REQ: This primitive indicates to the CCS provider that the CCS user (Network) is rejecting the request for resumption of the call, and the cause for rejection.

Provider Primitives for Resume Service

• CC_RESUME_IND: This primitive indicates to the CCS user that a previously suspended call has been resumed at the network, or by the remote user.
• CC_RESUME_CON: This primitive confirms to the requesting CCS user (User) that the call has been resumed at the network.
• CC_RESUME_REJECT_IND: This primitive indicates to the requesting CCS user (User) that the request to resume the call has been rejected by the network, and the cause for rejection.

Figure 20 and Figure 21 show the sequence of primitives for resume service. The sequence of primitives may remain incomplete if a CC_RESET or a CC_RELEASE primitive occurs.

The sequence of primitives to resume a call is defined in the time sequence diagram as shown in Figure 20 and Figure 21.

The sequence of primitives as shown above may remain incomplete if a CC_RESET or CC_RELEASE primitive occurs (see Table 3). A CCS user must not issue a CC_RESUME_REQ primitive if no CC_SUSPEND_REQ has been sent previously. Following a reset procedure (CC_RESET_REQ or CC_RESET_IND), a CCS user may not issue a CC_RESUME_REQ to resume a call suspended before the reset procedure was signalled.

3.2.4 Call Termination Phase

3.2.4.1 Call Reject Service

User Primitives for Call Reject Service

• CC_REJECT_REQ: This primitive indicates that the CCS user receiving the specified CC_SETUP_IND requests that the specified call indication be rejected.

Provider Primitives for Call Reject Service

• CC_REJECT_IND: This primitive indicates to the calling CCS user that the call has been rejected.

The sequence of events for rejecting a call setup attempt at the UNI is defined in the time sequence diagram shown in Figure 23.

3.2.4.2 Call Failure Service

Provider Primitives for Call Failure Service

• CC_CALL_FAILURE_IND: This primitive indicates to the called CCS user that an event has caused the call to fail and indicates the reason for the failure and the cause value associated with the failure. The CCS user is required to release the call using the indicated cause value in a CC_DISCONNECT_REQ primitive.

The sequence of events for error indications is described in the time sequence diagram shown in Figure 24.

3.2.4.3 Call Release Service

The call release procedure is initialized by the insertion of a release object (associated with a CC_DISCONNECT_REQ, CC_RELEASE_REQ, or CC_REJECT_REQ) in the queue. As shown in Table 3, the release procedure is destructive with respect to other objects in the queue, and eventually results in the emptying of queues and termination of the call. The Release procedure invokes the following interactions:

1. A CC_DISCONNECT_REQ from the CCS user, followed by a CC_RELEASE_IND from the CCS provider and a subsequent CC_RELEASE_RES from the CCS user; or
2. A CC_DISCONNECT_IND from the CCS provider, followed by a CC_RELEASE_REQ from the CCS user and a subsequent CC_RELEASE_CON from the CCS provider.

The sequence of primitive depends on the origin of the release action. The sequence may be:

1. invoked by the CCS user, with a request from that CCS user, leading to interaction (A) with that CCS user and interaction (B) with the peer CCS user;
2. invoked by both CCS users, with a request from each of the CCS users, leading to interaction (A) with both CCS users;
3. invoked by the CCS provider, leading to interaction (B) with both CCS users.
4. invoked independently by one CCS user and the CCS provider, leading to interaction (A) with the originating CCS user and (B) with the peer CCS user.

User Primitives for Release Service

• CC_DISCONNECT_REQ: This primitive request that the CCS provider disconnect the B-Channel or indicate tones and announcements present. Tones and announcements should be requested in the CC_IBI_REQ primitive rather than the CC_DISCONNECT_REQ primitive.
• CC_RELEASE_REQ: This primitive requests that the CCS provider disconnect the B-Channel (if not already disconnected) and release the call reference.
• CC_RELEASE_RES: This primitive indicates to the CCS provider that the CCS user has accepted a release indication and has released the call reference.

Provider Primitives for Release Service

• CC_DISCONNECT_IND: This primitive indicates that the remote CCS user or provider has disconnected the B-Channel or has made tones and announcements available. The CCS provider should indicate tones and announcements present only with the CC_IBI_IND primitive rather than the CC_DISCONNECT_IND primitive.
• CC_RELEASE_IND: This primitive indicates that the remote CCS has disconnected the B-Channel and released the call reference.
• CC_RELEASE_CON: This primitive confirms that the remove CCS has disconnected the B-Channel and released the call reference.

The sequence of primitives as shown in Figure 25, Figure 26, Figure 27, and Figure 28 may remain incomplete if a CC_RESTART primitive occurs.

A CCS user can release a call establishment attempt by issuing a CC_DISCONNECT_REQ. The sequence of events is shown in Figure 25, Figure 26, Figure 27, and Figure 28.

3.2.5 Call Management

3.2.5.1 User Primitives for Call Management

• CC_RESTART_REQ: This primitive requests the CCS provider to restart all the call control addresses (signalling interface and channels) for the UNI interface.

3.2.5.2 Provider Primitives for Call Management

• CC_RESTART_CON: This primitive confirms to the requesting CCS user that all call control addresses (signalling interface and channels) for the UNI interface have been restarted and all calls are in the CCS_IDLE state.
• CC_MAINT_IND: This primitive indicates to CCS user that various events have occurred requiring maintenance notification (e.g., restart indication).

3.3 Network-Network Interface Services Definition

This section describes the required call control service primitives that define the NNI interface.

The queue model for NNI is discussed in more detail in ITU-T Q.764. For Q.764 specific conformance considerations, see Addendum for Q.764 Conformance. For ETSI EN 300 356-1 V3.2.2 specific conformance considerations, see Addendum for ETSI EN 300 356-1 V3.2.2 Conformance.

3.3.1 Call Setup Phase

A pair of queues is associated with a call between the two call control addresses when the CCS provider receives a CC_SETUP_REQ primitive at one of the call control addresses resulting in a setup object being entered into the queue. The queues will remain associated with the call until a CC_RELEASE_REQ (resulting in a release object) is either entered into or removed from a queue. Similarly, in the queue from the called CCS user, objects can be entered into the queue only after the setup object associated with the CC_SETUP_RES has been entered into the queue. Alternatively, the called CCS user can enter a release object into the queue instead of the setup object to terminate the call. The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the destination CCS user is unable to accept the CC_SETUP_IND (see call release primitive definition).

3.3.1.1 User Primitives for Successful Call Setup

• CC_SETUP_REQ: This primitive requests that the CCS provider setup a call to the specified destination (called party address).
• CC_MORE_INFO_REQ: This primitive requests that the CCS provider provide more information to establish the call. This primitive is not issued for en block signalling mode.
• CC_INFORMATION_REQ: This primitive requests that the CCS provider provide more information (digits) in addition to the destination (called party number) already specified in the CC_SETUP_REQ and subsequent CC_INFORMATION_REQ primitives. This primitive is not issued for en block signalling mode.
• CC_SETUP_RES: This primitive requests that the CCS provider accept a previous call setup indication on the specified stream.

3.3.1.2 Provider Primitives for Successful Call Setup

• CC_CALL_REATTEMPT_IND: This primitive indicates to the calling CCS user that an event has caused call setup to fail on the selected address and that a reattempt should be made (or has been made) on another call control address (signalling interface and circuit(s)). This primitive is only issued by the CCS provider if the CCS user is bound at the circuit level rather than the circuit group or trunk group level.
• CC_SETUP_IND: This primitive indicates to the CCS user that a call setup request has been made by a user at the specified call control address (circuit(s)).
• CC_MORE_INFO_IND: This primitive indicates to the CCS user that more information is required to establish the call. This primitive is not issued for en block signalling mode.
• CC_INFORMATION_IND: This primitive indicates to the CCS user more information (digits) in addition to the destination (called party number) already indicated in the CC_SETUP_IND and subsequent CC_INFORMATION_IND primitives. This primitive is not issued for en block signalling mode.
• CC_INFO_TIMEOUT_IND: This primitive indicates to the called CCS user that a timeout occurred while waiting for additional information (called party number). The receiving CCS User should determine whether sufficient address digits have been received and either disconnect the call with the CC_DISCONNECT_REQ primitive or continue the call with CC_SETUP_RES.
• CC_SETUP_CON: This primitive indicates to the CCS user that a call setup request has been confirmed on the indicated call control address (circuits(s)).

The sequence of primitives in a successful call setup is defined by the time sequence diagrams as shown in Figure 30 and Figure 31.

The sequence of primitives for the call response token value determination is shown in Figure 32 (procedures for call response token value determination are discussed in section 4.1.3 and 4.1.4.)

If the CCS provider is unable to establish a call, it indicates this to the request by a CC_CALL_REATTEMPT_IND. This is shown in Figure 33.

The sequence of primitives for call reattempt on dual seizure are shown in Figure 34.

3.3.2 Continuity Test Phase

The continuity test service is only applicable to the NNI.

During the continuity test phase, a pair of queues has already been associated with the call between the selected call control addresses (signalling interface and circuit(s)) during the setup phase. The continuity test phase begins when the CCS provider returns a CC_CONT_TEST_IND primitive in response to a CC_SETUP_REQ primitive that had the ISUP_NCI_CONT_CHECK_REQUIRED flag set in the call flags. The continuity test phase also begins when the CCS user responds with a CC_CONT_TEST_REQ primitive in response to a CC_SETUP_IND primitive that had the ISUP_NCI_CONT_CHECK_REQUIRED flag set in the call flags. Upon entering the continuity test phase, it is the responsibility of the CCS user to establish a loop back on the call control address (signalling interface and circuit(s)) or to attach tone generation and detection devices to the call control address (signalling interface and circuit(s)).

3.3.2.1 Continuity Test Successful

User Primitives for Successful Continuity Test

• CC_SETUP_REQ: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, requests that the CCS provider setup a call and include a continuity check before the call is established.
• CC_CONT_CHECK_REQ: This primitive requests that the CCS provider perform a continuity check on the specified call control address (signalling interface and circuit(s)). This primitive is only necessary for performing continuity checks that are not in conjunction with a call.
• CC_CONT_TEST_REQ: This primitive requests that the CCS provider accept an outstanding call setup indication. When the CC_SETUP_IND had the ISUP_NCI_CONT_CHECK_REQUIRED flag set, it indicates to the CCS provider that the necessary loop back device has been install on the call control address (signalling interface and circuit(s)).
• CC_CONT_REPORT_REQ: This primitive requests that the CCS provider indicate to the remote CCS user that the continuity test has succeeded (cc_result is set to ISUP_COT_SUCCESS).

Provider Primitives for Successful Continuity Test

• CC_SETUP_IND: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, indicates to the CCS user that a call setup including a continuity check is requested.
• CC_CONT_CHECK_IND: This primitive indicates to the CCS user that a continuity check was requested on the specified call control address (signalling interface and circuit(s)). This primitive is only necessary for performing continuity checks that are not in conjunction with a call.
• CC_CONT_TEST_IND: This primitive indicates that the remote CCS user has accepted a call setup indication on the specified call control address (signalling interface and circuit(s)). When the CC_SETUP_IND primitive had the ISUP_NCI_CONT_CHECK_REQUIRED flag set, it indicates to the CCS user that the necessary loop back device has been installed on the remote end of the call control address (signalling interface and circuit(s)). The CCS user receiving this primitive must attach the necessary tone generation and detection devices to the circuit(s) and perform the continuity test.
• CC_CONT_REPORT_IND: This primitive indicates to the CCS user that the continuity test was successful.

The sequence of primitives in a successful continuity test associated with call setup when continuity check is required on the circuit(s) is defined by the time sequence diagrams as shown in Figure 35.

The sequence of primitives in a successful continuity test associated with call setup when continuity check is being performed on a previous circuit is defined by the time sequence diagrams as shown in Figure 36.

The sequence of primitives in a successful continuity test not associated with call setup is defined by the time sequence diagrams as shown in Figure 37.

3.3.2.2 Continuity Test Unsuccessful

User Primitives for Unsuccessful Continuity Test

• CC_SETUP_REQ: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, requests that the CCS provider setup a call and include a continuity check before the call is established.
• CC_CONT_TEST_REQ: This primitive requests that the CCS provider accept an outstanding call setup indication. When the CC_SETUP_IND had the ISUP_NCI_CONT_CHECK_REQUIRED flag set, it also indicates to the CCS provider that the necessary loop back device has been install on the call control address (signalling interface and circuit(s)).
• CC_CONT_REPORT_REQ: This primitive requests that the CCS provider indicate to the remote CCS user that the continuity test has failed (cc_result is set to ISUP_COT_FAILURE).

Provider Primitives for Unsuccessful Continuity Test

• CC_SETUP_IND: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, indicates to the CCS user that a call setup including a continuity check is requested.
• CC_CONT_TEST_IND: This primitive indicates that the remote CCS user has accepted a call setup indication on the specified call control address (signalling interface and circuit(s)). When the CC_SETUP_IND primitive had the ISUP_NCI_CONT_CHECK_REQUIRED flag set, it indicates to the CCS user that the necessary loop back device hass been installed on the remote end of the call control address (signalling interface and circuit(s)). The CCS user receiving this primitive must attach the necessary tone generation and detection devices to the circuit(s) and perform the continuity test.
• CC_CONT_REPORT_IND: This primitive indicates to the CCS user that the continuity test failed.
• CC_CALL_REATTEMPT_IND: This primitive indicates to the calling CCS user that the continuity test failed and that a reattempt should be made (or has been made) on another call control address (signalling interface and circuit(s)). This primitive is only issued by the CCS provider if the CCS user is bound at the circuit level rather than the circuit group or trunk group level.

The sequence of primitives for an unsuccessful continuity test associated with a call setup is defined by the time sequence diagrams as shown in Figure 38.

The sequence of primitives for an unsuccessful continuity test not associated with a call setup is defined by the time sequence diagrams as shown in Figure 39.

3.3.3 Call Establishment Phase

During the call establishment phase, a pair of queues has already been associated with the call between the selected call control addresses (signalling interface and circuit(s)) during the setup phase. The call establishment phase begins when the CCS provider returns a CC_SETUP_CON primitive (or receives a CC_CONT_REPORT_REQ primitive) in response to a CC_SETUP_REQ primitive (that had the ISUP_NCI_CONT_CHECK_REQUIRED flag set). The call establishment phase also begins when the CCS user responds with a CC_SETUP_RES primitive (or receives a CC_CONT_REPORT_IND primitive) in response to a CC_SETUP_IND primitive (that had the ISUP_NCI_CONT_CHECK_REQUIRED flag set).

Upon entering the call establishment phase, it is the responsibility of the CCS user to remove any loop back from the call control address (signalling interface and circuit(s)) or to remove tone generation and detection devices from the call control address (signalling interface and circuit(s)).

3.3.3.1 User Primitives for Successful Call Establishment

• CC_PROCEEDING_REQ: This primitive requests that the CCS provider indicate to the call control peer that the call is proceeding.
• CC_ALERTING_REQ: This primitive requests that the CCS provider indicate to the call control peer that the terminating user is being alerted.
• CC_PROGRESS_REQ: This primitive requests that the CCS provider indicate to the call control peer that the specified progress event has occurred.
• CC_IBI_REQ: This primitive requests that the CCS provider indicate to the call control peer that interworking has been encountered and in-band information is now available. This will also inform the peer CCS user that no connect indication is pending.
• CC_CONNECT_REQ: This primitive requests that the CCS provider indicate to the call control peer that the call has been connected.
• CC_SETUP_COMPLETE_REQ: This primitive requests that the CCS provider complete the call setup. This primitive is used in NNI mode for interworking with UNI mode.

3.3.3.2 Provider Primitives for Successful Call Establishment

• CC_PROCEEDING_IND: This primitive indicates to the CCS user that the call control peer is proceeding.
• CC_ALERTING_IND: This primitive indicates to the CCS user that the terminating user is being alerted.
• CC_PROGRESS_IND: This primitive indicates to the CCS user that the specified progress event has occurred.
• CC_IBI_IND: This primitive indicates to the CCS user that interworking has been encountered and in-band information is now available. It also indicates to the CCS user that no connect indication is pending.
• CC_CONNECT_IND: This primitive indicates to the CCS user that the call has been connected.
• CC_SETUP_COMPLETE_IND: This primitive indicates to the CCS user that the call has completed setup. This primitive is used in NNI mode for interworking with UNI mode.

The sequence of primitives in a successful call establishment is defined by the time sequence diagrams as shown in Figure 40.

3.3.4 Call Established Phase

Flow control of the call is done by management of the queue capacity, and by allowing objects of certain types to be inserted to the queues, as shown in Table X.

3.3.4.1 User Primitives for Established Calls

• CC_SUSPEND_REQ: This primitives requests that the CCS provider temporarily suspend a call.
• CC_RESUME_REQ: This primitive request that the CCS provider resume a previously suspended call.

3.3.4.2 Provider Primitives for Established Calls

• CC_SUSPEND_IND: This primitive indicates to the CCS user that an established call has been temporarily suspended.
• CC_RESUME_IND: This primitive indicates to the CCS user that a previously suspended call has been resumed.

Figure 41 shows the sequence of primitives for suspension and resumption of established calls. The sequence of primitives may remain incomplete if a CC_RESET or a CC_RELEASE primitive occurs. The sequence of primitives to successfully suspend and resume a call is defined in the time sequence diagram as shown in Figure 41.

The sequence of primitives as shown above may remain incomplete if a CC_RESET or CC_RELEASE primitive occurs (see Table 3). A CCS user must not issue a CC_RESUME_REQ primitive if no CC_SUSPEND_REQ has been sent previously. Following a reset procedure (CC_RESET_REQ or CC_RESET_IND), a CCS user may not issue a CC_RESUME_REQ to resume a call suspended before the reset procedure was signalled.

3.3.5 Call Termination Phase

3.3.5.1 Call Reject Service

User Primitives for Call Reject Service

• CC_REJECT_REQ: This primitive indicates that the CCS user receiving the specified CC_SETUP_IND requests that the specified call indication be rejected.

Provider Primitives for Call Reject Service

• CC_REJECT_IND: This primitive indicates to the calling CCS user that the call has been rejected.

The sequence of events for rejecting a call setup attempt at the NNI is defined in the time sequence diagram shown Figure 42.

3.3.5.2 Call Failure Service

The call error procedure is indicated by the removal of a reattempt or failure object (associated with a local event) from the queue. The error procedure is destructive with respect to other objects in the queue, and eventually results in the emptying of queues and termination of the call.

Provider primitives for the Call Failure Service

• CC_CALL_FAILURE_IND: This primitive indicates to the CCS user that an event has caused the call to fail and indicates the reason for the failure and the cause value associated with the failure. The CCS user is required to immediately disconnect the circuit(s) and release the call on any previous legs using the indicated cause value in the primitive.

The sequence of primitives for call failure are shown in Figure 43.

3.3.5.3 Call Release Service

The call release procedure is initialized by the insertion of a release object (associated with a CC_RELEASE_REQ) into the queue. As shown in Table 3, the release procedure is destructive with respect to other objects in the queue, and eventually results in the emptying of queues and termination of the call. The release procedure invokes the following interactions:

1. a CC_RELEASE_REQ from the CCS user, followed by a CC_RELEASE_CON from the CCS provider; or
2. A CC_RELEASE_IND from the CCS provider, followed by a CC_RELEASE_REQ from the CCS user.

The sequence of primitives depends on the origin of the release action. The sequence may be:

1. invoked by one CCS user, with a request from that CCS user, leading to interaction (A) with that CCS user and interaction (B) with the peer CCS user;
2. invoked by both CCS users, with a request from each of the CCS users, leading to interaction (A) with both CCS users;
3. invoked by the CCS provider, leading to interaction (B) with both CCS users;
4. invoked independently by on CCS user and the CCS provider, leading to interaction (A) with the originating CCS user and (B) with the peer CCS user.

User primitives for the Release Service

• CC_RELEASE_REQ: This primitive request that the CCS provider release the call.
• CC_RELEASE_RES: This primitive indicates to the CCS provider that the CCS user has accepted a release indication.

Provider primitives for the Release Service

• CC_RELEASE_IND: This primitive indicates to the CCS user that the call has been released.
• CC_RELEASE_CON: This primitive indicates to the CCS user that the release request has been confirmed.

The sequence of primitives as shown in Figure 44, Figure 45, Figure 46, and Figure 47, may remain incomplete if a CC_RESET primitive occurs.

A CCS user can release a call establishment attempt by issuing a CC_RELEASE_REQ. The sequence of events is shown in Figure 44, Figure 45, Figure 46, and Figure 47.

3.3.6 Circuit Management Services

3.3.6.1 Reset Service

The reset service is used by the CCS user or management to resynchronize the use of the call, or by the CCS provider to report detected loss of a unrecoverable call.

The reset service is only applicable to the NNI.

The reset procedure invokes the following interactions:

1. a CC_RESET_REQ from the CCS user, followed by a CC_RESET_CON from the CCS provider; or
2. a CC_RESET_IND from the CCS provider, followed by a CC_RESET_RES from the CCS user.

The complete sequence of primitives depends upon the origin of the reset action. The reset service may be:

1. invoked by one CCS user, leading to interaction (A) with that CCS user and interaction (B) with the peer CCS user.
2. invoked by both CCS users, leading to interaction (A) with both CCS users;
3. invoked by the CCS provider, leading to interaction (B) with both CCS users;
4. invoked by one CCS user and the CCS provider, leading to interaction (A) with the originating CCS user and (B) with the peer CCS user.

User Primitives for Reset Service

• CC_RESET_REQ: This primitive requests that the CCS provider reset the specified call control address (circuit or circuit group).
• CC_RESET_RES: This primitive indicates to the CCS provider that the CCS user has accepted a reset indication and has performed local reset of the specified call control address (circuit or circuit group).³

Provider Primitives for Reset Service

• CC_RESET_IND: This primitive indicates to the CCS user that the user should reset the specified call control address (circuit or circuit group).
• CC_RESET_CON: This primitive indicates to the CCS user that the specified call control address (circuit or circuit group) has been successfully reset by the peer.

The sequence of primitives are shown in Figure 48, Figure 49, Figure 50, and Figure 51.

3.3.6.2 Blocking Service

The blocking service is used by the CCS user or management to effect local maintenance or hardware blocking on circuits, or by the CCS provider to indicate to CCS user or management the remote maintenance or hardware blocking of circuits.

The blocking service is only applicable to the NNI.

The blocking service provides for the local and remote blocking of call control addresses (signalling interface and circuit or circuit group) either for maintenance oriented or hardware failure purposes.

Blocking should only be invoked from streams that are listening on a circuit group that includes the circuits for which blocking is requested, or the CC_DEFAULT_LISTENER. Maintenance blocking will also only be indicated on streams that are listening on circuit group that includes the circuits for which blocking is requested, or in the absence of such a stream, the CC_DEFAULT_LISTENER. When no stream is available to report maintenance blocking indications, the indication should be responded to by the CCS provider without user or management indication.

User Primitives for Blocking Service

• CC_BLOCKING_REQ: This primitive requests that the specified call control address(es) (signalling interface and circuit or circuit group) be locally blocked either for maintenance oriented or hardware failure purposes.
• CC_BLOCKING_RES: This primitive accepts a request and indicates the call control address(es) (circuit or circuit group) that were remotely blocked for maintenance oriented or hardware failure purposes.⁸

Provider Primitives for Blocking Service

• CC_BLOCKING_IND: This primitive indicates that the CCS user has requested that the specified call control address(es) (signalling interface and circuit or circuit group) be remotely blocked either for maintenance oriented or hardware failure purposes.
• CC_BLOCKING_CON: This primitive indicates that the remote CCS user has confirmed the specified call control address(es) (signalling interfaces and circuit or circuit group) as locally blocked either for maintenance oriented or hardware failure purposes

The sequence of primitives are shown in Figure 51.

3.3.6.3 Unblocking Service

The unblocking service is only applicable to the NNI.

The unblocking service provides for the local and remote unblocking of call control addresses (signalling interface and circuit or circuit group) either for maintenance oriented or hardware failure purposes.

User Primitives for Unblocking Service

• CC_UNBLOCKING_REQ: This primitive requests that the specified call control address(es) (signalling interfaces and circuit or circuit groups) be locally unblocked either for maintenance oriented or hardware failure purposes.
• CC_UNBLOCKING_RES: This primitive accepts a request and indicates the call control address(es) (circuit or circuit group) that were remotely unblocked for maintenance oriented or hardware failure purposes.⁹

Provider Primitives for Unblocking Service

• CC_UNBLOCKING_IND: This primitive indicates that the CCS user has requested that the specified call control address(es) (signalling interface and circuit or circuit group) be remotely blocked either for maintenance oriented or hardware failure purposes.
• CC_UNBLOCKING_CON: This primitive indicates that the remote CCS user has confirmed the specified call control address(es) (signalling interfaces and circuit or circuit group) as locally unblocked either for maintenance oriented or hardware failure purposes.

The sequence of primitives are shown in Figure 52.

3.3.6.4 Query Service

The query service is only applicable to the NNI.

The query service provides for the query of the remote state and blocking level of call control addresses (signalling interface and circuit group).

User Primitives for Query Service

• CC_QUERY_REQ: This primitive request that the specified call control address(es) (signalling interfaces and circuit group) be queried for remote state and blocking level.
• CC_QUERY_RES: This primitive accepts a request and indicates the local state and blocking level for the previously requested specified call control addresses (circuit group).¹⁰

Provider Primitives for Query Service

• CC_QUERY_IND: This primitive indicates that the CCS user has requested that the local state and blocking level for the call control address(es) (signalling interface and circuit group).
• CC_QUERY_CON: This primitive indicates that the remote CCS user has confirmed the specified call control addresses (signalling interface and circuit group) and has returned the remote state and blocking level for each address.

The sequence of primitives are shown in Figure 53.

4 CCI Primitives

This section describes the format and parameters of the CCI primitives (Mapping of CCI Primitives to Q.931 and Mapping of CCI Primitives to Q.764. shows the mapping of CCI primitives of the primitives defined in Q.931 and Q.764). In addition, it discusses the states the primitive is valid in, the resulting state, and the acknowledgement that the primitive expects. (The state/event tables for these primitives are shown in State/Event Tables. The precedence tables for the CCI primitives are shown in Primitive Precedence Tables.) Rules for ITU-T conformance are described in Addendum for Q.931 Conformance and Addendum for Q.764 Conformance to this document.

Tables 5, 6, and 7 provide a summary of the CCS primitives and their parameters.

4.1 Management Primitives

These primitives apply to UNI (User and Network) and NNI.

4.1.1 Call Control Information Request

CC_INFO_REQ

This primitive request the CCS provider to return the values of all supported protocol parameters (see under CC_INFO_ACK), and also the current state of the CCS provider (as defined in State/Event Tables). This primitive does not affect the state of the CCS provider and does not appear in the state tables.

Format

The format of the message is one M_PCPROTO message block and its structure is as follows:

     typedef struct CC_info_req {
             ulong cc_primitive;             /* always CC_INFO_REQ */
     } CC_info_req_t;

     

Parameters

cc_primitive

Indicates the primitive type.

Valid States

This primitive is valid in any state where a local acknowledgement is not pending.

New State

The new state remains unchanged.

Acknowledgements

This primitive requires the CCS provider to generate one of the following acknowledgements upon receipt of the primitive:

• Successful: Acknowledgement of the primitive via the CC_INFO_ACK primitive.
• Non-fatal errors: There are no errors associated with the issuance of this primitive.

4.1.2 Call Control Information Acknowledgement

CC_INFO_ACK

This primitive indicates to the CCS user any relevant protocol-dependent parameters. It should be initiated in response to the CC_INFO_REQ primitive described above.

Format

The format of this message is one M_PCPROTO message block and its structure is as follows:

     typedef struct CC_info_ack {
             ulong cc_primitive;             /* always CC_INFO_ACK */
             /* FIXME ... more ... */
     } CC_info_ack_t;

     

Parameters

The above fields have the following meaning:

cc_primitive

Indicates the primitive type.

Flags

Valid States

This primitive is valid in any state in response to a CC_INFO_REQ primitive.

New State

The state remains the same.

4.1.3 Protocol Address Request

CC_ADDR_REQ

This primitive requests that the CCS provider return information concerning the call control addresses upon which the CCS user is bound or engage in a call.

The format of the message is one M_PROTO message block and its structure is as follows:

     typedef struct CC_addr_req {
             ulong cc_primitive;             /* always CC_ADDR_REQ */
             ulong cc_call_ref;              /* call reference */
     } CC_addr_req_t;

     

Parameters

cc_primitive

Specifies the primitive type.

cc_call_ref

Specifies the call reference for which to obtain the connected address.

Valid States

This primitive is valid in any state.

New State

The new state is CCS_WACK_AREQ.

Rules

• If the call reference is specified as zero (0), then no connected address information will be returned in the CC_ADDR_ACK.

Acknowledgements

The CCS provider will generate on of the following acknowledgements upon receipt of the CC_ADDR_REQ primitive:

• Successful: Correct acknowledgement of the primitive is indicated via the CC_ADDR_ACK primitive.
• Unsuccessful (Non-fatal errors): These errors will be indicated via the CC_ERROR_ACK primitive. The applicable non-fatal errors are as follows:

  CCBADCLR

  The call reference specified in the primitive was incorrect or illegal.
  

  CCSYSERR

  A system error occurred and the UNIX system error is indicated in the primitive.

4.1.4 Protocol Address Acknowledgement

CC_ADDR_ACK

This primitive acknowledges the corresponding request primitive and is used by the CCS provider to return information concerning the bound and connected protocol addresses for the stream.

The format of the message is one M_PROTO message block and its structure is as follows:

     typedef struct CC_addr_ack {
             ulong cc_primitive;             /* always CC_ADDR_ACK */
             ulong cc_bind_length;           /* length of bound address */
             ulong cc_bind_offset;           /* offset of bound address */
             ulong cc_call_ref;              /* call reference */
             ulong cc_conn_length;           /* length of connected address */
             ulong cc_conn_offset;           /* offset of connected address */
     } CC_addr_ack_t;

     

Parameters

cc_primitive

Indicates the primitive type.

cc_bind_length

Indicates the length of the bound call control address.

cc_bind_offset

Indicates the offset of the bound call control address.

cc_call_ref

Indicates the call reference for the connected call control address.

cc_conn_length

Indicates the length of the connected call control address.

cc_conn_offset

Indicates the offset of the connected call control address.

Valid State

This primitive is valid in state CC_WACK_AREQ.

New State

The new state is the state previous to the CC_ADDR_REQ.

Rules

• If the requesting stream is not bound to a call control address, the CCS provider will code the cc_bind_length and cc_bind_offset fields to zero. Otherwise, the CCS provider will return the same call control address that was returned in the CC_BIND_ACK.
• If the requesting stream is not connected to a call, the CCS provider will code the cc_conn_length and cc_conn_offset fields to zero. Otherwise, the CCS provider will indicate the call control address (circuit) upon which the call is connected.

4.1.5 Bind Protocol Address Request

CC_BIND_REQ

This primitive requests that the CCS provider bind a CCS user entity to a call control address (circuit, circuit group) and negotiate the number of setup indications allowed to be outstanding by the CCS provider for the specified CCS user entity being bound.

Format

The format of the message is one M_PROTO message block and its structure is as follows:

     typedef struct CC_bind_req {
             ulong cc_primitive;             /* always CC_BIND_REQ */
             ulong cc_addr_length;           /* length of address */
             ulong cc_addr_offset;           /* offset of address */
             ulong cc_setup_ind;             /* req # of setup inds to be queued */
             ulong cc_bind_flags;            /* bind options flags */
     } CC_bind_req_t;

     
     /* Flags associated with CC_BIND_REQ */
     #define CC_DEFAULT_LISTENER             0x000000001UL
     #define CC_TOKEN_REQUEST                0x000000002UL
     #define CC_MANAGEMENT                   0x000000004UL
     #define CC_TEST                         0x000000008UL
     #define CC_MAINTENANCE                  0x000000010UL
     #define CC_MONITOR                      0x000000020UL

Parameters

cc_primitive

Is the primitive type.

cc_addr_length

Is the length in bytes of the call control (circuit, circuit group) address to be bound to the stream.

cc_addr_offset

Is the offset from the beginning of the M_PROTO block where the call control (circuit, circuit group) address begins.

cc_setup_ind

Is the requested number of setup indications (simultaneous incoming calls) allowed to be outstanding by the CCS provider for the specified protocol address. (If the number of outstanding setup indications equals cc_setup_ind, the CCS provider need not discard further incoming setup indications, but may choose to queue them internally until the number of outstanding setup indications drops below the cc_setup_ind number.) Only one stream per call control address is allowed to have a cc_setup_ind number value greater than zero. This indicates to the CCS provider that this stream is the listener stream for the CCS u