BICCI Technical Specification

A PDF version of this document is available here.

Call Control Interface (CCI)

Call Control Interface (CCI) Specification

About This Manual

This is Edition 7.20141001, last updated 2014-10-25, of The Call Control Interface (CCI) Specification, for Version 1.1 release 7.20141001 of the OpenSS7 package.

Preface

Notice

Software in this document and related software is released under the AGPL (see GNU Affero General Public License). Please note, however, that there are different licensing terms for some of the manual package and some of the documentation. Consult permission notices contained in the documentation of those components for more information.

This document is released under the FDL (see GNU Free Documentation License) with no invariant sections, no front-cover texts and no back-cover texts.

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.

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.

A current version of this specification is normally distributed with the OpenSS7 package, openss7-1.1.7.20141001.²

Version Control

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. 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. OpenSS7 Corporation reserves the right to revise this software and documentation for any reason, including but not limited to, conformity with standards promulgated by various agencies, utilization of advances in the state of the technical arts, or the reflection of changes in the design of any techniques, or procedures embodied, described, or referred to herein. OpenSS7 Corporation is under no obligation to provide any feature listed herein.

$Log: cci.texi,v $
Revision 1.1.2.2  2011-02-07 02:21:37  brian
- updated manuals

Revision 1.1.2.1  2009-06-21 10:52:47  brian
- added files to new distro

ISO 9000 Compliance

Only the TeX, texinfo, or roff source for this maual is controlled. An opaque (printed, postscript or portable document format) version of this manual is a UNCONTROLLED VERSION.

Disclaimer

OpenSS7 Corporation disclaims all warranties with regard to this documentation including all implied warranties of merchantability, fitness for a particular purpose, non-infrincement, or title; that the contents of the manual 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 or contract, negligence or other tortious action, arising out of or in connection with any use of this documentation or the performance or implementation of the contents thereof.

U.S. Government Restricted Rights

If you are licensing this Software on behalf of the U.S. Government ("Government"), the following provisions apply to you. If the Software is supplied by the Department of Defense ("DoD"), it is classified as "Commercial Computer Software" under paragraph 252.227-7014 of the DoD Supplement to the Federal Aquisition Regulations ("DFARS") (or any successor regulations) and the Government is acquiring only the license rights granded herein (the license rights customarily provided to non-Government users). If the Software is supplied to any unit or agency of the Government other than DoD, it is classified as "Restricted Computer Software" and the Government’s rights in the Software are defined in paragraph 52.227-19 of the Federal Acquisition Regulations ("FAR") (or any successor regulations) or, in the cases of NASA, in paragraph 18.52.227-86 of the NASA Supplerment to the FAR (or any successor regulations).

Acknowledgements

The OpenSS7 Project was funded in part by:

Thanks to the subscribers to and sponsors of The OpenSS7 Project. Without their support, open software like this would not be possible.

As with most open source projects, this project would not have been possible without the valiant efforts and productive software of the Free Software Foundation, the Linux Kernel Community, and the open source software movement at large.

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.

Figure 1. 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:

It is call oriented.
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).
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.
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.
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.

Figure 2. UNI Data Model

2.2.2 NNI

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

It is circuit oriented.
It employs quasi-associated signalling in that the path taken by signalling and the path taken by the circuits are not necessarily related.
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.
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.

Figure 3. NNI Data Model

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.

Table 1. CCI Service Primitives

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.

Figure 4. Sequence of Primitives: Call Control Information Reporting Service

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.

Figure 5. Sequence of Primitives: Call Control User Address Service

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 .

Figure 6. Sequence of Primitives: Call Control User Bind Service

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.

Figure 7. Sequence of Primitives: Call Control User Unbind Service

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.

Figure 8. Sequence of Primitives: Call Control Receipt Acknowledgement Service

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.

Figure 9. Sequence of Primitives: Call Control Options Management Service

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.

Figure 10. Sequence of Primitives: Call Control Error Acknowledgement Service

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.

Figure 11. Sequence of Primitives: Call Control UNI Overview

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

The sequence of primitives in a successful call setup is defined by the time sequence diagram shown in Figure 12. The sequence of primitives for the call response token value determination is shown in Figure 13 (procedures for call response token value determination are discussed in section 4.1.3 and 4.1.4.)

Figure 12. Sequence of Primitives: Call Control Call Setup Service

Figure 13. Sequence of Primitives: Call Control Token Request Service

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.

Figure 14. Sequence of Primitives: Call Reattempt - CCS Provider

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

Figure 15. Sequence of Primitives: Call Reattempt - Dual Seizure

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.

Figure 16. Sequence of Primitives: Call Control Successful Call Establishment Service

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.

Figure 17. Sequence of Primitives: Call Control Network Suspend Service: Successful

Figure 18. Sequence of Primitives: Call Control Network Suspend Service: Unsuccessful

Figure 19. Sequence of Primitives: Call Control User Suspend Service

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.

Figure 20. Sequence of Primitives: Call Control Resume Service: Successful

Figure 21. Sequence of Primitives: Call Control Resume Service: Unsuccessful

Figure 22. Sequence of Primitives: Call Control User Resume Service

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.

Figure 23. Sequence of Primitives: Rejecting a Call Setup

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.

Figure 24. Sequence of Primitives: Call Failure

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:

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
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:

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;
invoked by both CCS users, with a request from each of the CCS users, leading to interaction (A) with both CCS users;
invoked by the CCS provider, leading to interaction (B) with both CCS users.
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.

Figure 25. Sequence of Primitives: CCS User Invoked Release

Figure 26. Sequence of Primitives: Simultaneous CCS User Invoked Release

Figure 27. Sequence of Primitives: CCS Provider Invoked Release

Figure 28. Sequence of Primitives: Simultaneous CCS User and CCS Provider Invoked Release

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.

Figure 29. Sequence of Primitives: Call Control NNI Overview

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

Figure 31. Sequence of Primitives: Call Control Call Setup Service: Overlap Sending

Figure 32. Sequence of Primitives: Call Control Token Request Service

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.

Figure 33. Sequence of Primitives: Call Reattempt - CCS Provider

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

Figure 34. Sequence of Primitives: Call Reattempt - Dual Seizure

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.

Figure 35. Sequence of Primitives: Call Setup Continuity Test Service: Required: Successful

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.

Figure 36. Sequence of Primitives: Call Setup Continuity Test Service: Previous: Successful

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.

Figure 37. Sequence of Primitives: Continuity Test Service: Successful

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.

Figure 38. Sequence of Primitives: Call Setup Continuity Test Service: Unsuccessful

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.

Figure 39. Sequence of Primitives: Continuity Test Service: Unsuccessful

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.

Figure 40. Sequence of Primitives: Call Control Successful Call Establishment Service

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.

Figure 41. Sequence of Primitives: Call Control Suspend and Resume Service

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.

Figure 42. Sequence of Primitives: CCS User Rejection of a Call Setup Attempt

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.

Figure 43. Sequence of Primitives: Call Failure

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:

a CC_RELEASE_REQ from the CCS user, followed by a CC_RELEASE_CON from the CCS provider; or
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:

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;
invoked by both CCS users, with a request from each of the CCS users, leading to interaction (A) with both CCS users;
invoked by the CCS provider, leading to interaction (B) with both CCS users;
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.

Figure 44. Sequence of Primitives: CCS User Invoked Release

Figure 45. Sequence of Primitives: Simultaneous CCS User Invoked Release

Figure 46. Sequence of Primitives: CCS Provider Invoked Release

Figure 47. Sequence of Primitives: Simultaneous CCS User and CCS Provider Invoked Release

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:

a CC_RESET_REQ from the CCS user, followed by a CC_RESET_CON from the CCS provider; or
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:

invoked by one CCS user, leading to interaction (A) with that CCS user and interaction (B) with the peer CCS user.
invoked by both CCS users, leading to interaction (A) with both CCS users;
invoked by the CCS provider, leading to interaction (B) with both CCS users;
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.

Figure 48. Sequence of Primitives: CCS User Invoked Reset

⁵

Figure 49. Sequence of Primitives: Simultaneous CCS User Invoked Reset

⁶

Figure 50. Sequence of Primitives: CCS Provider Invoked Reset

⁷

Figure 51. Sequence of Primitives: Simultaneous CCS user and CCS Provider Invoked Reset

⁸

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

Figure 52. Sequence of Primitives: Successful Blocking Service

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

Figure 53. Sequence of Primitives: Successful Unblocking Service

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

Figure 54. Sequence of Primitives: Successful Query Service

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 user. This stream will be used by the CCS provider for setup indications for that call control address.

if a stream is bound as a listener stream, it is still able to initiate outgoing call setup requests.

cc_bind_flags

See "Flags" below.

Flags

CC_DEFAULT_LISTENER: When set, this flag specifies that this stream is the "default listener stream." This stream is used to pass setup indications (or continuity check requests) for all incoming calls that contain protocol identifiers that are not bound to any other listener, or when a listener stream with cc_setup_ind value of greater than zero is not found. Also, the default listener will receive all incoming call indications that contain no user data (i.e., test calls) and all maintenance indications (i.e., CC_MAINT_IND). Only one default listener stream is allowed per occurrence of CCI. An attempt to bind a default listener stream when one is already bound should result in an error (of type [CCADDRBUSY]).
CC_TOKEN_REQUEST: When set, this flag specifies to the CCS provider that the CCS user has requested that a "token" be assigned to the stream (to be used in the call response message), and the token value be returned to the CCS user via the CC_BIND_ACK primitive. The token assigned by the CCS provider can then be used by the CCS user in a subsequent CC_SETUP_RES primitive to identify the stream on which the call is to be established.
CC_MANAGEMENT: When set, this flag specifies to the CCS provider that this stream is to be used for circuit management indications for the specified addresses.
CC_TEST: When set, this flag specifies to the CCS provider that this stream is to be used for continuity and test call indications for the specified addresses.
CC_MAINTENANCE: When set, this flag specifies to the CCS provider that this stream is to be used for maintenance indications for the specified addresses.

Valid States

This primitive is valid in state CCS_UNBND (see State/Event Tables).

New State

The new state is CCS_WACK_BREQ.

Acknowledgements

The CCS provider will generate one of the following acknowledgements upon receipt of the CC_BIND_REQ primitive:

— Successful: Correct acknowledgement of the primitive is indicated via the CC_BIND_ACK primitive.
— Non-fatal errors: These errors will be indicated via the CC_ERROR_ACK primitive. The applicable non-fatal errors are as follows:

[CCSYSERR]

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

[CCOUTSTATE]

The primitive was issued from an invalid state.

[CCBADADDR]

The call control address was in an incorrect format or the address contained illegal information. It is not intended to indicate protocol errors.

[CCNOADDR]

The CCS user did not provide a call control address and the CCS provider could not allocate an address to the user.

[CCADDRBUSY]

The CCS user attempted to bind a second stream to a call control address with the cc_setup_ind number set to a non-zero value, or attempted to bind a second stream with the CC_DEFAULT_LISTENER flag value set to non-zero.

[CCBADFLAG]

The flags were invalid or unsupported, or the combination of flags was invalid. This error is returned if more than one of CC_TEST, CC_MANAGEMENT, or CC_MAINTENANCE flags are set.

[CCBADPRIM]

The primitive format was incorrect (i.e. too short).

[CCACCESS]

The user did not have proper permissions.

4.1.6 Bind Protocol Address Acknowledgement

CC_BIND_ACK

This primitive indicates to the CCS user that the specified call control user entity has been bound to the requested call control address and that the specified number of connect indications are allowed to be queued by the CCS provider for the specified network address.

Format

The format of the message is one M_PCPROTO message block, and its structure is the following:

typedef struct CC_bind_ack {
        ulong cc_primitive;             /* always CC_BIND_ACK */
        ulong cc_addr_length;           /* length of address */
        ulong cc_addr_offset;           /* offset of address */
        ulong cc_setup_ind;             /* setup indications */
        ulong cc_token_value;           /* setup response token value */
} CC_bind_ack_t;

Parameters

cc_primitive: Indicates the primitive type.
cc_addr_length: Is the length of the call control address that was bound.
cc_addr_offset: Is the offset from the beginning of the M_PCPROTO block where the call control address begins.
cc_setup_ind: Is the accepted number of setup indications allowed to be outstanding by the CCS provider for the specified call control address. If its value is zero, this stream cannot accept CC_SETUP_IND messages. If its value is greater than zero, then the CCS user can accept CC_SETUP_IND messages up to the value specified in this parameter before having to respond with a CC_SETUP_RES or a CC_DISCONNECT_REQ message.
cc_token_value: Conveys the value of the "token" assigned to this stream that can be used by the CCS user in a CC_SETUP_RES primitive to accept a call on this stream. It is a non-zero value, and is unique to all streams bound to the CCS provider.

The proper alignment of the address in the M_PCPROTO message block is not guaranteed.

Rules

The following rules apply to the binding of the specified call control address to the stream:

If the cc_addr_length field in the CC_BIND_REQ primitive is zero, then the CCS provider is to assign a call control address to the user.
The CCS provider is to bind the call control address as specified in the CC_BIND_REQ primitive. If the CCS provider cannot bind the specified address, it may assign another call control address to the user. It is the call control user’s responsibility to check the call control address returned in the CC_BIND_ACK primitive to see if it is the same as the one requested.

The following rules apply to negotiating cc_setup_ind argument:

The cc_setup_ind number in the CC_BIND_ACK primitive must be less than or equal to the corresponding requested number as indicated in the CC_BIND_REQ primitive.
Only one stream that is bound to the indicated call control address may have a negotiated accepted number of maximum setup indications greater than zero. If a CC_BIND_REQ primitive specifies a value greater than zero, but another stream has already bound itself to the given call control address with a value greater than zero, the CCS provider should assign another protocol address to the user.
If a stream with cc_setup_ind number greater than zero is used to accept a call, the stream will be found busy during the duration of that call and no other streams may be bound to that call control address with a cc_setup_ind number greater than zero. This will prevent more than one stream bound to the identical call control address from accepting setup indications.
A stream requesting a cc_setup_ind number of zero should always be legal. This indicates to the CCS provider that the stream is to be used to request call setup only.
A stream with a negotiated cc_setup_ind number greater than zero may generate setup requests or accept setup indications.

If the above rules result in an error condition, then the CCS provider must issue a CC_ERROR_ACK primitive to the CCS user specifying the error as defined in the description of the CC_BIND_REQ primitive.

Valid States

This primitive is in response to a CC_BIND_REQ primitive and is valid in the state CCS_WACK_BREQ.

New State

The new state is CCS_IDLE.

4.1.7 Unbind Protocol Address Request

CC_UNBIND_REQ

This primitive request that the CCS provider unbind the CCS user entity that was previously bound to the call control address.

Format

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

typedef struct CC_unbind_req {
        ulong cc_primitive;             /* always CC_UNBIND_REQ */
} CC_unbind_req_t;

Parameters

cc_primitive: Indicates the primitive type.

Valid States

This primitive is valid in the CCS_IDLE state.

New State

The new state is CCS_WACK_UREQ.

Acknowledgements

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

— Successful: Correct acknowledgement of the primitive is indicated via the CC_OK_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:

[CCOUTSTATE]

The primitive was issued from an invalid state.

[CCSYSERR]

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

4.1.8 Call Processing Options Management Request

CC_OPTMGMT_REQ

This primitive allows the CCS user to manage the call processing parameter values associated with the stream.

Format

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

typedef struct CC_optmgmt_req {
        ulong cc_primitive;             /* always CC_OPTMGMT_REQ */
        ulong cc_call_ref;              /* call reference */
        ulong cc_opt_length;            /* length of option values */
        ulong cc_opt_offset;            /* offset of option values */
        ulong cc_opt_flags;             /* option flags */
} CC_optmgmt_req_t;

Parameters

cc_primitive: Specifies the primitive type.
cc_call_ref: Specifies the call reference for which to manage options.
cc_opt_length: Specifies the length of the default values of the options parameters as selected by the CCS user. These values will be used in subsequent CC_SETUP_REQ primitives on the stream that do not specify values for these options. If the CCS user cannot determine the value of an option, it value should be set to CC_UNKNOWN. If the CCS user does not specify any option paramter values, the length of this field should be set to zero.
cc_opt_offset: Specifies the offset of the options parameters from the beginning of the M_PROTO message block.
cc_opt_flags: See "Flags" below.

Flags

Valid States

This primitive is valid in the CCS_IDLE state.

New State

The new state is CCS_WACK_OPTREQ.

Acknowledgements

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

— Successful: Acknowledgement is via the CC_OK_ACK primitive. At successful completions, the resulting state is CCS_IDLE.
— Non-fatal errors: These errors are indicated in the CC_ERROR_ACK primitive. The resulting state remains unchanged. The applicable non-fatal errors are defined as follows:

[CCSYSERR]

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

[CCOUTSTATE]

The primitive was issued from an invalid state.

[CCBADOPT]

The option parameter values specified are outside the range supported by the CCS provider.

[CCBADCLR]

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

[CCBADFLAG]

The flags were invalid or unsupported, or the combination of flags was invalid.

[CCBADPRIM]

The primitive format was incorrect (i.e. too short).

[CCACCESS]

The user did not have proper permissions.

4.1.9 Call Processing Options Management Acknowledgement

CC_OPTMGMT_ACK

This primitive allows the CCS user to manage the call processing parameter values associated with the stream.

Format

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

typedef struct CC_optmgmt_ack {
        ulong cc_primitive;             /* always CC_OPTMGMT_ACK */
        ulong cc_call_ref;              /* call reference */
        ulong cc_opt_length;            /* length of option values */
        ulong cc_opt_offset;            /* offset of option values */
        ulong cc_opt_flags;             /* option flags */
} CC_optmgmt_ack_t;

Parameters

Flags

Valid States

This primitive is valid in any state.

New State

The new state is unchanged.

Acknowledgements

4.1.10 Error Acknowledgement

CC_ERROR_ACK

This primitive indicates to the CCS user that a non-fatal error has occurred in the last CCS user originated primitive. This may only be initiated as an acknowledgement for those primitives that require one. It also indicates to the user that no action was taken on the primitive that caused the error.

Format

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

typedef struct CC_error_ack {
        ulong cc_primitive;             /* always CC_ERROR_ACK */
        ulong cc_error_primitive;       /* primitive in error */
        ulong cc_error_type;            /* CCI error code */
        ulong cc_unix_error;            /* UNIX system error code */
        ulong cc_state;                 /* current state */
        ulong cc_call_ref;              /* call reference */
} CC_error_ack_t;

Parameters

cc_primitive: Identifies the primitive type.
cc_error_primitive: Identifies the primitive type that cause the error.
cc_error_type: Contains the Call Control Interface error code.
cc_unix_error: Contains the UNIX system error code. This may only be non-zero if the cc_error_type is equal to [CCSYSERR].
cc_state: Identifies the state of the interface at the time that the CC_ERROR_ACK primitive was issued by the CCS provider.
cc_call_ref: Identifies the CCS provider or CCS user call reference associated with the request or response primitive that was in error. If no call reference is associated with the request or response primitive that caused the error, this field is coded zero (0) by the CCS provider.

Valid Error Codes

The following error codes are allows to be returned:

[CCSYSERR]: A system error has occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]: The primitive was issued from an invalid state.
[CCBADADDR]: The call control address as specified in the primitive was in an incorrect format, or the address contained illegal information.
[CCBADDIGS]: The digits provided in the called party number or subsequent number specified in the primitive are of an incorrect format or are invalid.
[CCBADOPT]: The options values as specified in the primitive were in an incorrect format, or they contained illegal information.
[CCNOADDR]: The CCS provider could not allocate an address.
[CCADDRBUSY]: The CCS provider could not use the specified address because the specified address is already in use.
[CCBADCLR]: The call reference specified in the primitive was incorrect or illegal.
[CCBADTOK]: Token used is not associated with an open stream.
[CCBADFLAG]: The flags specified in the primitive were incorrect or illegal.
[CCNOTSUPP]: Specified primitive type is not known to the CCS provider.
[CCBADPRIM]: The primitive was of an incorrect format (i.e. too small, or an offset it out of range).
[CCACCESS]: The user did not have proper permissions.

Valid States

This primitive is valid in all states that have a pending acknowledgement or confirmation.

New State

The new state is the same as the one from which the acknowledged request or response was issued.

4.1.11 Successful Receipt Acknowledgements

CC_OK_ACK

The primitive indicates to the CCS user that the previous call control user originated primitive was received successfully by the call control provider. It does not indicate to the CCS user any call control protocol action taken due to the issuance of the last primitive. The CC_OK_ACK primitive may only be initiated as an acknowledgement for those user-originated primitives that have no other means of confirmation.

Format

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

typedef struct CC_ok_ack {
        ulong cc_primitive;             /* always CC_OK_ACK */
        ulong cc_correct_prim;          /* primitive being acknowledged */
        ulong cc_state;                 /* current state */
        ulong cc_call_ref;              /* call reference */
} CC_ok_ack_t;

Parameters

cc_primitive: Identifies the primitive.
cc_correct_prim: Identifies the successfully received primitive type.
cc_state: Identifies the state of the interface at the time that the CC_OK_ACK primitive was issued by the CCS provider.
cc_call_ref: Identifies the CCS provider or CCS user call reference associated with the request or response primitive that was in error. If no call reference is associated with the request or response primitive that caused the error, this field is coded zero (0) by the CCS provider.

Valid States

This primitive is issued in states CCS_WACK_UREQ and CCS_WACK_OPTREQ.

New State

The resulting state depends on the current state (see State/Event Tables, Tables B-7 and B-8.).

4.2 Primitive Format and Rules

This section describes the format of the UNI (User and Newtork) and NNI primitives and the rules associated with these primitives. The default values of the options parameters associated with a call may be selected via the CC_OPTMGMT_REQ primitive.

4.2.1 Call Setup Phase

The following call control service primitives pertain to the setup of a call, provided the CCS users exist, and are known to the CCS provider.

4.2.1.1 Call Control Setup Request

CC_SETUP_REQ

This primitive requests that the CCS provider make a call to the specified destination.

Format

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

typedef struct CC_setup_req {
        ulong cc_primitive;             /* always CC_SETUP_REQ */
        ulong cc_user_ref;              /* user call reference */
        ulong cc_call_type;             /* call type */
        ulong cc_call_flags;            /* call flags */
        ulong cc_cdpn_length;           /* called party number length */
        ulong cc_cdpn_offset;           /* called party number offset */
        ulong cc_opt_length;            /* optional parameters length */
        ulong cc_opt_offset;            /* optional parameters offset */
        ulong cc_addr_length;           /* connect to address length */
        ulong cc_addr_offset;           /* connect to address offset */
} CC_setup_req_t;

Parameters

cc_primitive: Specifies the primitive type.
cc_user_ref: Specifies a reference number known to the CCS user that uniquely identifies the current setup request. When this value is non-zero, it permits the CCS User to have multiple outstanding setup requests pending on the same stream. Responses made by the CCS provider to the CC_SETUP_REQ primitive will contain this CCS user call attempt reference.
cc_call_type: Specifies the type of call to be set up. Call types supported are dependent upon the CCS provider and protocol, see the addendum for call types for specific protocols.
cc_call_flags: Specifies a bit field of call options. Call flags supported are depeddent upon the CCS provider and protocol, see the addendum for call flags for specific protocols.
cc_cdpn_length: Specifies the length of the called party number parameter that conveys an address identifying the CCS user to which the call is to be established. This field will accommodate variable length numbers within a range supported by the CCS provider. If no called party address is provided by the CCS user, this field must be coded to zero. The coding of the called party number is protocol and provider-specific.
cc_cdpn_offset: Is the offset of the called party number from the beginning of the M_PROTO message block.
cc_opt_length: Specifies the length of optional parameters to be conveyed in the call setup. This field will accomodate variable length addresses within a range supported by the CCS provider. If no optional parameters are provided by the CCS user, this field must be coded to zero. The format of optional parameters are protocol and provider-specific, see the addendum for the format of optional parameters for specific protocols.
cc_opt_offset: Specifies the offset of the optional parameters from the beginning of the M_PROTO message block.
cc_addr_length: Specifies the length of the call control address parameter that conveys the call control address (circuit, circuit group) of the CCS user entity to which the call is to be established. The semantics of the values in the CC_SETUP_REQ is identical to the values in the CC_BIND_REQ.
cc_addr_offset: Specifies the offset of the call control address from the beginning of the M_PROTO message block.

Rules

The following rules apply to the setup of calls to the specified addresses:

If the cc_cdpn_length field in the CC_SETUP_REQ primitive is zero, then the CCS provider is to select a called party number for the call. If the CCS provider cannot select a called party number for the call, the CCS provider responds with a CC_ERROR_ACK primitive with error [CCNOADDR].
If the cc_cdpn_length field in the CC_SETUP_REQ primitive is non-zero, the CCS provider is to setup the call to the specified number. If the CCS provider cannot setup a call of the specified call type to the specified number the call will fail and the CCS provider will return a CC_ERROR_ACK with the appropriate error value (e.g., [CCBADADDR]).

The following rules apply to the call control addresses (trunk groups and circuit identifiers):

If the CCS user does not specify a call control address (i.e. cc_addr_length is set to zero), then the CCS provider may attempt to assign a call control address, assign it a call reference and associate it with the stream for the duration of the call.

The following rules apply to the CCS user call attempt reference:

If the CCS user does not specify a call attempt reference (i.e. the cc_user_ref is set to zero), then the CCS provider can only support one outstanding outgoing call attempt for the stream. If the CCS user specifies a call attempt reference, all replies made by the CCS provider to this CC_SETUP_REQ primitive will contain the CCS user specified call attempt reference until either the call fails or is released, or after the CCS provider sends a CC_SETUP_CON primitive.

Valid States

This primitive is valid in state CCS_IDLE.

New State

The new state depends upon the information provided in the CC_SETUP_REQ message as follows:

If the setup request specifies that a continuity check was performed on a previous circuit, the new state is CCS_WREQ_CCREP (awaiting report of the result of continuity test performed on the previous circuit).
If the setup request specifies that a continuity check is required on the circuit, the new state is CCS_WIND_CTEST (awaiting indication of remote loop back on the circuit).
If the setup request specifies that no continuity test is required on this or a previous circuit and that the called party address contains partial information, the new state is CCS_WIND_MORE (awaiting the indication that more information is required).
If the setup request specifies that no continuity test is required on this or a previous circuit and that the called party address contains complete information, the new state is CCS_WCON_SREQ (awaiting confirmation of the setup request).

Acknowledgements

The following acknowledgements are valid for this primitive:

— Successful Call Establishment: This is indicated via the CC_SETUP_CON primitive. This results in the Call Establishment state. For CC_SETUP_REQ primitives where ISUP_NCI_CONT_CHECK_REQUIRED is set, or where the CCS provider otherwise determines that a continuity check is required on the circuit, success is still indicated via the CC_SETUP_CON primitive. In this case, the CC_SETUP_CON primitive is not sent by the CCS provider unless the continuity check is successful. For CCS_SETUP primitives where ISUP_NCI_CONT_CHECK_PREVIOUS is set, the CC_SETUP_CON primitive is not sent by the CCS provider until the CCS user sends a CC_CONT_REPORT_REQ primitive indicating that continuity check on the previous circuit has been successful. Receipt of the CC_SETUP_CON primitive always results in the Call Establishment state.
— Unsuccessful Call Establishment: This is indicated via the CC_CALL_REATTEMPT_IND, CC_CALL_FAILURE_IND, or CC_RELEASE_IND primitives. For example, a call may be rejected because either the called CCS user cannot be reached, or the CCS provider and/or the called CCS user did not agree on the specified call type or options. This results in the Idle state. Where the CC_CALL_REATTEMPT_IND or CC_RELEASE_IND primitives are sent before the CC_SETUP_CON primitive, the CC_CALL_REATTEMPT_IND or CC_RELEASE_IND primitives will contain the CCS user specified call attempt reference.
— Non-fatal errors: These are indicated via the CC_ERROR_ACK primitive. The applicable non-fatal errors are defined as follows:

[CCSYSERR]

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

[CCOUTSTATE]

The primitive was issued from an invalid state.

[CCBADADDR]

The call control address as specified in the primitive was in an incorrect format, or the address contained illegal information.

[CCBADDIGS]

The called party number was in the incorrect format, or contained illegal information. This is used only to handle coding errors of the number and is not intended to provide for protocol errors. Protocol errors should be conveyed in the CC_CALL_REATTEMPT_IND, CC_CALL_FAILURE_IND or CC_RELEASE_IND primitives.

[CCBADOPT]

The optional parameters were in an incorrect format, or contained illegal information.

[CCNOADDR]

The user did not provide a called party address field and one was required by the call type. The CCS provider could not select a called party address.

[CCADDRBUSY]

The CCS provider could not use the specified address because the specified address is already in use.

[CCBADCLR]

The call reference specified in the primitive was incorrect or illegal (not unique).

[CCBADPRIM]

The primitive was of an incorrect format (i.e. too small, or an offset it out of range).

[CCACCESS]

The user did not have proper permissions for the use of the requested address or options.

4.2.1.2 Call Control Setup Indication

CC_SETUP_IND

This primitive indicates to the destination CCS user that a call setup request has been made by the user at the specified source address.

Format

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

typedef struct CC_setup_ind {
        ulong cc_primitive;             /* always CC_SETUP_IND */
        ulong cc_call_ref;              /* call reference */
        ulong cc_call_type;             /* call type */
        ulong cc_call_flags;            /* call flags */
        ulong cc_cdpn_length;           /* called party number length */
        ulong cc_cdpn_offset;           /* called party number offset */
        ulong cc_opt_length;            /* optional parameters length */
        ulong cc_opt_offset;            /* optional parameters offset */
        ulong cc_addr_length;           /* connecting address length */
        ulong cc_addr_offset;           /* connecting address offset */
} CC_setup_ind_t;

Parameters

cc_primitive: Indicates the primitive type.
cc_call_ref: Identifies the call reference that can be used by the CCS user to associate this message with the CC_SETUP_RES or CC_RELEASE_REQ primitive that is to follow. This value must be unique among the outstanding CC_SETUP_IND messages.
cc_call_type: Indicates the type of call to be set up. Call types supported are dependent upon the CCS provider and protocol, see the addendum for call types for specific protocols.
cc_call_flags: Indicates a bit field of call options. Call flags supported are dependent upon the CCS provider and protocol, see the addendum for call flags for specific protocols.
cc_cdpn_length: Indicates the length of the called party number address parameter that conveys an address identifying the CCS user to which the call is to be established. This field will accommodate variable length addresses within a range supported by the CCS provider.
cc_cdpn_offset: Is the offset of the called party number address from the beginning of the M_PROTO message block.
cc_opt_length: Indicates the length of the optional parameters that were used in the call setup.
cc_opt_offset: Indicates the offset of the optional parameters from the beginning of the M_PROTO message block.
cc_addr_length: Indicates the length of the connecting address parameter that conveys the call control address the CCS user entity (circuit) on which the call is being established. The semantics of the values in the CC_SETUP_IND is identical to the values in the CC_BIND_ACK.
cc_addr_offset: Indicates the offset of the connecting address from the beginning of the M_PROTO message block.

Valid States

This primitive is valid in state CCS_IDLE for the indicated call reference.

New State

The new state depends upon the information provided in the CC_SETUP_IND message as follows:

If the setup indication indicates that a continuity check was performed on a previous circuit, the new state is CCS_WIND_CCREP (awaiting the report of continuity test results).
If the setup indication indicates that a continuity check is required on the circuit, the new state is CCS_WREQ_CTEST (awaiting confirmation of installation of loop back device on the circuit).
If the setup indication indicates that no continuity tests are required on this or a previous circuit and that the called party number contains partial information, the new state is CCS_WREQ_MORE (awaiting the request for more information to confirm the partial address).
If the setup indication indicates that no continuity tests are required on this or a previous circuit and that the called party number contains complete information, the new state is CCS_WRES_SIND (awaiting response to the setup indication).

In any event, the number of outstanding setup indications waiting for user response is incremented by one.

Rules

The rules for issuing the CC_SETUP_IND primitive are as follows:

This primitive will only be issued to streams that have been bound with a non-zero negotiated maximum number of setup indications (i.e. on a listening stream), and where the number of outstanding setup indications (call references) for the stream is less than the negotiated maximum number of setup indications.
If the call setup indicated is for a normal call, the stream upon which it is indicated was not bound with the CC_TEST, CC_MANAGEMENT or CC_MAINTENANCE flags set.
If the call setup indicated is for an ISUP test call, the stream upon which it is indicated was bound with the CC_TEST flag set and a non-zero number of negotiated maximum setup indications.

4.2.1.3 Call Control Setup Response

CC_SETUP_RES

This primitive allows the destination CCS user to request that the call control provider accept a previous setup indication. This primitive also indicates that overlap receiving is complete. The CCS use is still expected to complete the setup process by issuing the CCS_PROCEED_REQ, CCS_ALERTING_REQ, CCS_PROGRESS_REQ, CCS_IBI_REQ, CCS_CONNECT_REQ, or CCS_DISCONNECT_REQ messages.

Format

The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as follows:

typedef struct CC_setup_res {
        ulong cc_primitive;             /* always CC_SETUP_RES */
        ulong cc_call_ref;              /* call reference */
        ulong cc_token_value;           /* call response token value */
} CC_setup_res_t;

Parameters

cc_primitive: Indicates the primitive type.
cc_call_ref: Indicates the call reference of the CC_SETUP_RES message. It is used by the CCS provider to associated the CC_SETUP_RES message with an outstanding CC_SETUP_IND message. An invalid call reference should result in error with the error type [CCBADCLR].
cc_token_value: Is used to identify the stream that the CCS user wants to establish the call on. (Its value is determined by the CCS user by issuing a CC_BIND_REQ primitive with the CC_TOKEN_REQ flag set. The token value is returned in the CC_BIND_ACK.) The value of this field should be non-zero when the CCS user wants to establish the call on a stream other than the stream on which the CC_SETUP_IND arrived. If the CCS user wants to establish a call on the same stream that the CC_SETUP_IND arrived on, then the value of this field should be zero.

Valid States

This primitive is valid in state CCS_WRES_SIND.

New State

The new state is CCS_WREQ_PROCEED.

Acknowledgements

The CCS provider should generate one of the following acknowledgements upon receipt of this primitive:

— Successful: Successful completion is indicated via the CC_OK_ACK primitive.
— Unsuccesful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The applicable non-fatal errors are defined as follows:

[CCSYSERR]

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

[CCOUTSTATE]

The primitive was issued from an invalid state.

[CCBADCLR]

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

[CCBADTOK]

The token specified is not associated with an open stream.

[CCBADPRIM]

The primitive format was incorrect (i.e. too short).

4.2.1.4 Call Control Setup Confirm

CC_SETUP_CON

This primitive indicates to the calling CCS user that the call control setup request has been sent on the specified call control address (circuit, circuit group). For calls that were requested setup with the ISUP_NCI_CONT_CHECK_REQUIRED flag set in the CC_SETUP_REQ, or for which the CCS provider has otherwise decide to perform continuity check, this also confirms that the continuity check was successful.

Format

The format of this message is one M_PROTO message block. The structure of the M_PROTO message block is as follows:

typedef struct CC_setup_con {
        ulong cc_primitive;             /* always CC_SETUP_CON */
        ulong cc_user_ref;              /* user call reference */
        ulong cc_call_ref;              /* call reference */
        ulong cc_addr_length;           /* connecting address length */
        ulong cc_addr_offset;           /* connecting address offset */
} CC_setup_con_t;

Parameters

cc_primitive: Indicates the primitives type.
cc_user_ref: Indicates the CCS user call attempt reference value which was provided by the CCS user in the CC_SETUP_REQ message. This permits the CCS user to associate this CC_SETUP_CON primitive with the previous CC_SETUP_REQ primitive and permits multiple outstanding CC_SETUP_REQ primitives.
cc_call_ref: Indicates the CCS provider assigned call reference. If the CCS user wishes to establish more than one simultaneous call on a given stream, the CCS user must use this CCS provider indicated call reference in subsequent call control primitives sent to the CCS provider. This permits the CCS provider to associate a CCS user primitive with one of multiple simultaneous calls associated with a given stream.
cc_addr_length: Indicates the length of the connecting address parameter that conveys the call control address of the CCS user entity (circuit) on which the call is being established. The se

BICCI Technical Specification

Description: OpenSS7 SS7 BICC Documentation.

Call Control Interface (CCI)

Call Control Interface (CCI) Specification

About This Manual

Preface

Notice

Abstract

Purpose

Intent

Audience

Revision History

Version Control

ISO 9000 Compliance

Disclaimer

U.S. Government Restricted Rights

Acknowledgements

1 Introduction

1.1 Related Documentation

1.1.1 Role

1.2 Definitions, Acronyms, Abbreviations

2 The Call Control Layer

2.1 Model of the CCI

2.2 CCI Services

2.2.1 UNI

2.2.1.1 Address Formats

Customer/Provider Group

Equipment Group

Facility Group

Transmission Group

Channel

Data Link

2.2.2 NNI

2.2.2.1 Address Formats

Signalling Points

Signalling Relations

Trunk Groups

Circuit Groups

Circuits

2.2.3 Local Management

3 CCI Services Definition

3.1 Local Management Services Definition

3.1.1 Call Control Information Reporting Service

3.1.2 CCS Address Service

3.1.3 CCS User Bind Service

3.1.4 CCS User Unbind Service

3.1.5 Receipt Acknowledgement Service

3.1.6 Options Management Service

3.1.7 Error Acknowledgement Service

3.2 User-Network Interface Services Definition

3.2.1 Call Setup Phase

3.2.1.1 User Primitives for Successful Call Setup

3.2.1.2 Provider Primitives for Successful Call Setup

3.2.2 Call Establishment Phase

3.2.2.1 User Primitives for Successful Call Establishment

3.2.2.2 Provider Primitives for Successful Call Establishment

3.2.2.3 Provider Primitives for Successful Call Setup

3.2.3 Call Established Phase

3.2.3.1 Suspend Service

User Primitives for Suspend Service

Provider Primitives for Suspend Service

3.2.3.2 Resume Service

User Primitives for Resume Service

Provider Primitives for Resume Service

3.2.4 Call Termination Phase

3.2.4.1 Call Reject Service

User Primitives for Call Reject Service

Provider Primitives for Call Reject Service

3.2.4.2 Call Failure Service

Provider Primitives for Call Failure Service

3.2.4.3 Call Release Service

User Primitives for Release Service

Provider Primitives for Release Service

3.2.5 Call Management

3.2.5.1 User Primitives for Call Management

3.2.5.2 Provider Primitives for Call Management

3.3 Network-Network Interface Services Definition

3.3.1 Call Setup Phase

3.3.1.1 User Primitives for Successful Call Setup

3.3.1.2 Provider Primitives for Successful Call Setup