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:

• Monavacon Limited
• OpenSS7 Corporation

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.

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

2.2 CCI Services

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

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

2.2.1 UNI

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

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

2.2.1.1 Address Formats

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

Customer/Provider Group

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

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

Equipment Group

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

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

Facility Group

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

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

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

An ISDN Channel Identifier is only unique within a facility group.

Transmission Group

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

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

Channel

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

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

Data Link

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

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

2.2.2 NNI

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

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

2.2.2.1 Address Formats

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

Signalling Points

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

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

Signalling Relations

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

Signalling relations are identified using a unique signalling relation identifier within the CCS provider. Addresses specifying all of the circuits in a signalling relation are specified with scope ISUP_SCOPE_SR and the signalling relation identifier.

An ISUP Circuit Identification Code is only unique within a signalling relation.

Trunk Groups

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

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

Circuit Groups

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

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

Circuits

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

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

2.2.3 Local Management

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

3 CCI Services Definition

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

3.1 Local Management Services Definition

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

3.1.1 Call Control Information Reporting Service

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

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

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

3.1.2 CCS Address Service

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

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

The sequence of primitives is shown in Figure 5.

3.1.3 CCS User Bind Service

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

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

The sequence of primitives is shown in Figure 6 .

3.1.4 CCS User Unbind Service

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

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

The sequence of primitives is shown in Figure 7.

3.1.5 Receipt Acknowledgement Service

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

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

3.1.6 Options Management Service

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

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

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

3.1.7 Error Acknowledgement Service

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

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

3.2 User-Network Interface Services Definition

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

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

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

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

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

3.2.1 Call Setup Phase

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

The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the destination CCS user is unable to accept the CC_SETUP_IND (see call failure and call reject primitive definitions).

3.2.1.1 User Primitives for Successful Call Setup

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

3.2.1.2 Provider Primitives for Successful Call Setup

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

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

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

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

3.2.2 Call Establishment Phase

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

3.2.2.1 User Primitives for Successful Call Establishment

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

3.2.2.2 Provider Primitives for Successful Call Establishment

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

3.2.2.3 Provider Primitives for Successful Call Setup

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

3.2.3 Call Established Phase

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

3.2.3.1 Suspend Service

User Primitives for Suspend Service

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

Provider Primitives for Suspend Service

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

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

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

3.2.3.2 Resume Service

User Primitives for Resume Service

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

Provider Primitives for Resume Service

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

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

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

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

3.2.4 Call Termination Phase

3.2.4.1 Call Reject Service

User Primitives for Call Reject Service

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

Provider Primitives for Call Reject Service

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

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

3.2.4.2 Call Failure Service

Provider Primitives for Call Failure Service

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

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

3.2.4.3 Call Release Service

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

The Release procedure invokes the following interactions:

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

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

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

User Primitives for Release Service

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

Provider Primitives for Release Service

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

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

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

3.2.5 Call Management

3.2.5.1 User Primitives for Call Management

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

3.2.5.2 Provider Primitives for Call Management

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

3.3 Network-Network Interface Services Definition

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

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

3.3.1 Call Setup Phase

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

The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the destination CCS user is unable to accept the CC_SETUP_IND (see call release primitive definition).

3.3.1.1 User Primitives for Successful Call Setup

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

3.3.1.2 Provider Primitives for Successful Call Setup

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

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

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

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

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

3.3.2 Continuity Test Phase

The continuity test service is only applicable to the NNI.

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

Upon entering the continuity test phase, it is the responsibility of the CCS user to establish a loop back on the call control address (signalling interface and circuit(s)) or to attach tone generation and detection devices to the call control address (signalling interface and circuit(s)).

3.3.2.1 Continuity Test Successful

User Primitives for Successful Continuity Test

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

Provider Primitives for Successful Continuity Test

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

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

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

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

3.3.2.2 Continuity Test Unsuccessful

User Primitives for Unsuccessful Continuity Test

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

Provider Primitives for Unsuccessful Continuity Test

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

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

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

3.3.3 Call Establishment Phase

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

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

3.3.3.1 User Primitives for Successful Call Establishment

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