Bearer Independent Call Control (BICC)

CCI-BICC

Section: Call Control Interface (CCI) (7)
Updated: 2008-10-31
Index Return to Main Contents

NAME

cci_bicc, bicci - Call Control Interface - Corrigendum for Q.765 Conformance

SYNOPSIS

#include <ss7/cci.h>
#include <ss7/cci_bicc.h>
#include <ss7/bicc_ioctl.h>

int bicc_stream = open(/dev/bicc, flags);

DESCRIPTION

This Corrigendum describes the formats and rules that are specific to BICC[1]. The Corrigendum must be used along with the generic CCI as defined in cci(7) when implementing a CCS provider that will be configured with the BICC call processing layer.

Primitives and Rules for Q.1920 Conformance

The following are the rules that apply to the CCI primitives for Q.1920 compatibility.

CALL CONTROL ADDRESSES

Format

The format of call control addresses is as follows:

Parameters

cc_addr_length: Specifies or indicates the length of the call control address. If a call control address is not included in the primitive, this parameter must be coded zero (0).
cc_addr_offset: Specifies or indicates the offset of the address from the begining of the primitive. If a call control address is not included with the primitive, this parameter must be coded zero (0).

Address Format

The format of the call control addresses for Q.1920 conforming CCS providers is as follows:

typedef struct bicc_addr {
    ulong scope;  /* the scope of the identifier */
    ulong id;     /* the identifier within the scope */
    ulong cic;    /* circuit id code within the scope */
} bicc_addr_t;

Address Fields

scope: Specifies or indicates the scope of the call control address. See Scope , below.
id: Specifies or indicates the identifier within the scope.
cic: Specifies or indicates the Circuit Identification Code significant with the scope.

Scope

The scope of the address is one of the following:

BICC_SCOPE_CT: Specifies or indicates that the scope of the call control address is a BICC circuit. The identifier within the scope is an identifier which uniquely identifies a circuit to the CCS provider. Circuit scope addresses may also be used to specify or indicate circuit groups, trunk groups, signalling relations and signalling points. When used in an indication or confirmation primitive, the CCS provider includes the Circuit Identification Code associated with the circuit in the address.
For multi-rate calls where multiple circuits are involved, the circuit scoped address specifies the lowest numerical Circuit Identification Code in the group of circuits.
BICC_SCOPE_CG: Specifies or indicates that the scope of the call control address is a BICC circuit group. The identifier within the scope is an identifier which uniquely identifies a circuit group to the CCS provider. Circuit group scope addresses may also be used to specify or indicate signalling relations and signalling points. When used in an indication or confirmation primitive, the CCS provider includes the Circuit Identification Code associated with the circuit group (lowest numerical value CIC in the circuit group range).
BICC_SCOPE_TG: Specifies or indicates that the scope of the call control address is a BICC trunk group. The identifier within the scope is an identifier which uniquely identifies a trunk group to the CCS provider. Trunk group scope addresses may also be used to specify or indicate circuits, signalling relations and signalling points. The Circuit Identification Code must be used to specify a circuit within the trunk group.
BICC_SCOPE_SR: Specifies or indicates that the scope of the call control address is a BICC signalling relation. The identifier within the scope is an identifier which uniquely identifies a signalling relation to the CCS provider. Signalling relation scope addresses may also be used to specify or indicate circuits and signalling points. The Circuit Identification Code must be used to sepcify a circuit (equipped or unequipped) within the signalling relation.
BICC_SCOPE_SP: Specifies or indicates that the scope of the call control address is a BICC signalling point. The identifier within the scope is an identifier which uniquely identifies a local signalling point to the CCS provider. Signalling point scope addresses may only indicate local signalling points. The Circuit Identification Code is unused and should be ignored by the CCS user and will be coded zero (0) by the CCS provider.
BICC_SCOPE_DF: Specifies or indicates that the scope of the call control address is the default scope. The identifier within the scope and Circuit Identification Code are unused and should be ignored by the CCS user and will be coded zero (0) by the CCS provider.

Rules

Rules for scope:

---: In primitives in which the address parameter occurs, the scope field setting indicates the scope of the address parameter.
---: Only one call control address can be specified with a single scope.
---: Not all scopes are necessarily supported by all primitives. See the particular primitive in this Corrigendum.

Rules for addresses:

---

The address contained in the primitive contains the following:

*: A scope.
*: An identifier within the scope or zero (0).
*: A circuit identification code within the scope or zero (0).

---

If the scope of the address is BICC_SCOPE_DF, then both the identifier and circuit identification code fields should be coded zero (0) and will be ignored by the CCS user or provider.

---

If the scope of the address is BICC_SCOPE_SP, then the circuit identification code field should be coded zero (0) and will be ignored by the CCS user or provider.

---

In all other scopes, the circuit identification code is optional and is coded zero (0) if unused.

OPTIONAL PARAMETERS

Format

The format of the optional parameters for Q.1920 conforming CCS providers is as follows:

Parameters

cc_opt_length: Specifies or indicates the length of the optional parameters associated with the primitive. For Q.1920 conforming CCS providers, the format of the optional parameters is the format of the Optional Parameters list (without the pointer or End of Optional Parameters octets) as specified in Q.1920.
cc_opt_offset: Specifies the offset of the optional parameters from the beginning of the block.

Rules

Rules for optional parameters:

---: The optional parameters provided by the CCS user may be checked for syntax by the CCS provider. If the CCS provider discovers a syntax error in the format of the optional parameters, the CCS provider should respond with a CC_ERROR_ACK(7) primitive with error [CCBADOPT].
---: For some primitives, specific optional parameters might be interpreted by the CCS provider and alter the function of some primitives. See the specific primitive descriptions later in this Corrigendum.
---: Except for optional parameters interpreted by the CCS provider as specified later in this Corrigendum, the optional parameters are treated as opaque and the optional parameter list is only checked for syntax. Opaque parameters will be passed to the BICC message without examination by the CCS provider.
---: To perform specific functions, additional optional parameters may be added to BICC messages by the CCS provider.
---: To perform specific functions, optional parameters may be modified by the CCS provider before being added to BICC messages.

Local Management Primitives

CC_INFO_ACK

This primitive is interpreted as described in CC_INFO_ACK(7) with the following protocol-specific considerations:

Parameters

Flags

Rule

CC_BIND_REQ

This primitive is interpreted as described in CC_BIND_REQ(7) with the following protocol-specific considerations:

Parameters

cc_addr_length: Indicates the length of the address to bind.
cc_addr_offset: Indicates the offset of the address to bind from the beginning of the block.
cc_setup_ind: Indicates the maximum number of setup (or continuity check) indications that will be outstanding for the listening stream.
cc_bind_flags: Indicates the options assocated with the bind. See ``Flags'', below.

Flags

The bind flags can be as follows:

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(7)). 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(7) primitive. The token assigned by the CCS provider can then be used by the CCS user in a subsequent CC_SETUP_RES(7) 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.

Rules

Rules for address specification:

---: The address contained in the primitive as indicated by cc_addr_length and cc_addr_offset parameters. The address can be of any BICC scope.
---: If the CC_DEFAULT_LISTENER flag is set, the parameters cc_addr_length and cc_addr_offset should be coded zero, and will be ignored by the CCS provider.

Rules for setup indications:

---

If the number of setup indications is non-zero, the stream is bound as a listening stream. Listening streams will receive all calls, test calls, and continuity tests that are incoming on the address bound.

*: If the address bound is of scope BICC_SCOPE_CT, only incoming calls on the bound circuit will be delivered to the listening stream.
*: If the address bound is of scope BICC_SCOPE_CG, only incoming calls on the bound circuit group will be delivered to the listening stream.
*: If the address bound is of scope BICC_SCOPE_TG, only incoming calls on the bound trunk group will be delivered to the listening stream (this is the normal case).
*: If the address bound is of scope BICC_SCOPE_SR, only incoming calls on the bound signalling relation (from the associated remote point code) will be delivered to the listening stream.
*: If the address bound is of scope BICC_SCOPE_SP, only incoming calls on the bound local signalling point will be delivered to the listening stream.
*: If the address bound is of scope BICC_SCOPE_DF, all incoming calls will be delivered to the listening stream.
*: Streams bound at one scope takes precedence over a stream bound at another scope in the order: circuit, circuit group, trunk group, signalling relation, signalling point and default scope.

---

Once a stream has successfully bound as a listening stream, it should be prepared to receive incoming calls, test calls and continuity tests.

Rules for bind flags:

---: For Q.1920 conformance, the CC_DEFAULT_LISTENER will receive all incoming calls, test calls, continuity tests, circuit management indications and maintenance indications that have no other listening stream. There can only be one stream bound with the CC_DEFAULT_LISTENER flag set.
---: Only one of CC_DEFAULT_LISTENER, CC_MANAGEMENT, CC_TEST and CC_MAINTENANCE may be set.
---: Streams bound with the CC_MANAGEMENT flag set will receive only circuit management indications and will not receive any calls.
---: Streams bound with the CC_TEST flag set will receive only continuity test and test call indications and will not receive normal calls, circuit management or maintenance indications.
---: Streams bound with the CC_MAINTENANCE flag set will receive only maintenance indications and will not receive any circuit management indications or calls.

CC_BIND_ACK

This primitive is interpreted as described in CC_BIND_ACK(7) with the following protocol-specific considerations:

Parameters

cc_addr_length: Indicates the length of the address to bind.
cc_addr_offset: Indicates the offset of the address to bind from the beginning of the block.
cc_setup_ind: Indicates the maximum number of setup (or continuity check) indications that will be outstanding for the listening stream.

Flags

See CC_BIND_REQ(7) in this Corrigendum.

Rules

See CC_BIND_REQ(7) in this Corrigendum.

CC_OPTMGMT_REQ

This primitive is interpreted as described in CC_OPTMGMT_REQ(7) with the following protocol-specific considerations:

Parameters

Flags

Rules

Call Setup Primitives

CC_SETUP_REQ

This primitive is interpreted as described in CC_SETUP_REQ(7) with the following protocol-specific considerations:

Parameters

cc_call_type: Specifies the type of call to be set up. See ``Call Types'', below.
cc_user_ref: Specifies the CCS user call reference to be associated with the call setup request. The CCS provider will use this user call reference in any indications given before the CC_SETUP_CON(7) primitive is issued.
cc_call_flags: Specifies the options associated with the call. See ``Flags'', below.
cc_cdpn_length: Specifies the length of the called party number. For Q.1920 conforming CCS providers, the format of the called party number is the format of the Called Party Number parameter (without the parameter type or length octets) as specified in Q.1920
cc_cdpn_offset: Specifies the offset of the called party number from the beginning of the block.

Call Types

Q.1920 conforming CCS providers must support the following call types:

CC_CALL_TYPE_SPEECH: The call type is speech. This call type corresponds to a Q.1920 transmission medium requirement of Speech.
CC_CALL_TYPE_64KBS_UNRESTRICTED: The call type is 64 kbit/s unrestricted digital information. This call type corresponds to a Q.1920 transmission medium requirement of 64 kbit/s Unrestricted Digital Information.
CC_CALL_TYPE_3_1kHZ_AUDIO: The call type is 3.1 kHz audio. This call type corresponds to a Q.1920 transmission medium requirement of 3.1 kHz Audio.
CC_CALL_TYPE_64KBS_PREFERRED: The call type is 64 kbit/s preferred. This call type corresponds to a Q.1920 transmission medium requirement of 64 kbit/s Preferred.
CC_CALL_TYPE_2x64KBS_UNRESTRICTED: The call type is 2 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.1920 transmission medium requirement of 2 x 64 kbit/s Unrestricted Digital Information.
CC_CALL_TYPE_384KBS_UNRESTRICTED: The call type is 384 kbit/s unrestricted digital information. This call type corresponds to a Q.1920 transmission medium requirement of 384 kbit/s Unrestricted Digital Information.
CC_CALL_TYPE_1536KBS_UNRESTRICTED: The call type is 1536 kbit/s unrestricted digital information. This call type corresponds to a Q.1920 transmission medium requirement of 1536 kbit/s Unrestricted Digital Information.
CC_CALL_TYPE_1920KBS_UNRESTRICTED: The call type is 1920 kbit/s unrestricted digital information. This call type corresponds to a Q.1920 transmission medium requirement of 1920 kbit/s Unrestricted Digital Information.

Flags

Q.1920 conforming CCS providers must support the following flags:

The following flags correspond to bits in the Nature of Connection Indicators parameter of Q.1920:

BICC_NCI_ONE_SATELLITE_CCT, BICC_NCI_TWO_SATELLITE_CCT: When one of these flags is set it indicates that either one or two satellite circuits are present in the connection. Otherwise, it indicates that no satellite circuits are present in the connection.
BICC_NCI_CONT_CHECK_REQUIRED, BICC_NCI_CONT_CHECK_PREVIOUS: When one of these flags is set it indicates that either a continuity check is required on the connection, or that a continuity check was performed on a previous connection. Otherwise, it indicates that a continuity check is not required on the connection.
BICC_NCI_OG_ECHO_CONTROL_DEVICE: When set it indicates that an outgoing half echo control device is included on the connection. Otherwise, it indicates that no outgoing half echo control device is included on the connection.

The following flags correspond to bits in the Forward Call Indicators parameter of Q.1920:

BICC_FCI_INTERNATIONAL_CALL: When this flag is set, the call is to be treated as an international call. Otherwise, the call is to be treated as a national call.
BICC_FCI_PASS_ALONG_E2E_METHOD_AVAILABLE, BICC_FCI_SCCP_E2E_METHOD_AVAILABLE: When one of these flags is set, either the pass along end-to-end method is available or the SCCP end-to-end method is available. Otherwise, no end-to-end method is available and only link-by-link method is available.
BICC_FCI_INTERWORKING_ENCOUNTERED: When this flag is set, interworking has been encountered on the call. Otherwise, no interworking has been encountered on the call.
BICC_FCI_E2E_INFORMATION_AVAILABLE: When this flag is set, end-to-end information is now available. Otherwise, no end-to-end information is available.
BICC_FCI_ISDN_USER_PART_ALL_THE_WAY: When this flag is set, ISDN User Part has been used all the way on the call. Otherwise, ISDN User Part has not been used all the way.
BICC_FCI_ORIGINATING_ACCESS_ISDN: When this flag is set, the originating access is ISDN. Otherwise, the originating access is non-ISDN.
BICC_FCI_SCCP_CLNS_METHOD_AVAILABLE, BICC_FCI_SCCP_CONS_METHOD_AVAILABLE, BICC_FCI_SCCP_ALL_METHODS_AVAILABLE: When one of these flags is set, either the connectionless SCCP method is available, the connection oriented SCCP method is available, or both methods are available. Otherwise, no SCCP method is indicated as available.

Rules

Rules for call reference:

---: If the BICC user wishes to setup multiple outgoing calls on the same stream, the BICC user associates a user call reference with each of the setup requests so that the indication, confirmation and acknowledgment primitives can be associated with the specific call setup request.
---: User call references are only necessary if multiple outgoing calls are to setup at the same time.
---: User call references only need by valid until a setup confirmation, call reattempt indication, release indication or call failure indication has been received in response to the setup request. A setup confirmation will contain a CCS provider call reference which can be used to distinguish the call from other calls to the CCS provider.

Rules for call type:

---: All Q.1920 conforming CCS provider must support the following call types:
CC_CALL_TYPE_SPEECH,
CC_CALL_TYPE_64KBS_UNRESTRICTED,
CC_CALL_TYPE_3_1kHZ_AUDIO and
CC_CALL_TYPE_64KBS_PREFERRED.
---: Support for other call types is optional and implementation-specific.

Rules for flags:

---: Q.1920 conforming CCS providers must support all of the flags listed above.
---: Only one of the following flags may be set:
BICC_NCI_ONE_SATELLITE and
BICC_NCI_TWO_SATELLITE.
---: Only one of the following flags may be set:
BICC_NCI_CONT_CHECK_REQUIRED and
BICC_NCI_CONT_CHECK_PREVIOUS.
---: Only one of the following flags may be set:
BICC_FCI_PASS_ALONG_E2E_METHOD_AVAILABLE and
BICC_FCI_SCCP_E2E_METHOD_AVAILABLE.
---: Only one of the following flags may be set, and only if BICC_FCI_SCCP_E2E_METHOD_AVAILABLE is also set:
BICC_FCI_SCCP_CLNS_METHOD_AVAILABLE,
BICC_FCI_SCCP_CONS_METHOD_AVAILABLE and
BICC_FCI_SCCP_ALL_METHODS_AVAILABLE.

CC_SETUP_IND

This primitive is interpreted as described in CC_SETUP_IND(7) with the following protocol-specific considerations:

Parameters

cc_call_ref: Indicates the CCS provider-assigned call reference associated with the call.
cc_call_type: Indicates the type of call to be set up. For Q.1920 conforming CCS providers, the call type can be one of the call types listed in this Corrigendum under CC_SETUP_REQ(7).
cc_call_flags: Indicates the options associated with the call. Q.1920 conforming CCS providers indicate the flags listed in this Corrigendum under CC_SETUP_REQ(7).
cc_addr_length: Indicates the length of the call control address (circuit(s)) upon which the call setup is indicated.
cc_addr_offset: Indicates the offset of the call control address from the start of the block.
cc_cdpn_length: Indicates the length of the called party number. For Q.1920 conforming CCS providers, the format of the called party number is the format of the Called Party Number parameter (without the parameter type or length octets) as specified in Q.1920
cc_cdpn_offset: Indicates the offset of the called party number from the beginning of the block.
cc_opt_length: Indicates the length of the optional parameters associated with the IAM, excluding the end of optional parameters tag.
cc_opt_offset: Indicates the offset of the options from the beginning of the block.

Rules

Rules for call reference:

---: The BICC provider will indicate a unique call reference to the CCS user which is used to associate response and request primitives with the call setup indication.
---: Provider call references will always be indicated.
---: Provider call references are only valid until a call failure or release indication has been issued by the CCS provider.
---: Provider call references are only valid for streams upon which the CC_SETUP_IND(7) is issued, or for streams upon which the call was accepted by the CCS user with a CC_SETUP_RES(7) primitive.
---: Provider call references are unique across the provider.

Rules for call type:

---: The rules for call type in section CC_SETUP_REQ(7) in this Corrigendum also apply to the CC_SETUP_IND(7). All Q.1920 conforming CCS providers must support the following call types:
CC_CALL_TYPE_SPEECH,
CC_CALL_TYPE_64KBS_UNRESTRICTED,
CC_CALL_TYPE_3_1kHZ_AUDIO and
CC_CALL_TYPE_64KBS_PREFERRED.
---: Support for additional call types is optional and implementation-specific.

Rules for setup flags:

---: The rules for setup flags in section CC_SETUP_REQ(7) in this Corrigendum also apply to the CC_SETUP_IND(7).

Rules for addresses:

---: Call control addresses in the CC_SETUP_IND(7) are of scope BICC_SCOPE_CT and identify the circuit(s) upon which the call setup is indicated.
---: For multi-rate calls, the call control address indicates the base circuit (numerically lowest Circuit Identification Code) of the multi-rate call.

CC_SETUP_RES

This primitive is interpreted as described in CC_SETUP_RES(7) with the following protocol-specific considerations:

Parameters

cc_call_ref: Specifies the call reference of the CC_SETUP_IND(7) to which the CCS user is responding.
cc_token_value: Specifies the token of a stream upon which to accept the call setup.

Rules

Rules for call reference:

---: The call reference specified by the CCS User must be a call reference which was previously indicated by the CCS provider in an outstanding CC_SETUP_IND(7). Otherwise the CCS provider will respond with a CC_ERROR_ACK(7) primitive with error [CCBADCLR].

Rules for token value:

---: If the token is the token value of the stream upon which the corresponding CC_SETUP_IND(7) was received, or zero (0), then the call setup will be accepted on the stream upon which the CC_SETUP_IND(7) was received.
---: If the token is non-zero and different from the listening stream, the call setup will be accepted on the specified stream.

CC_SETUP_CON

This primitive is interpreted as described in CC_SETUP_CON(7) with the following protocol-specific considerations:

Parameters

cc_user_ref: Indicates the CCS user call reference that was specified in the CC_SETUP_REQ(7). This call reference is used by the CCS user to associated the CC_SETUP_CON(7) with an outstanding CC_SETUP_REQ(7) primitive.
cc_call_ref: Indicates the CCS provider call reference that is to be associated with the call. This call reference is used by the CCS provider to identify the call and is to be used by the CCS user in all subsequent primitives referencing the call.
cc_addr_length: Indicates the length of the identifier of the circuit upon which the call setup is confirmed.
cc_addr_offset: Indicates the offset of the identifier from the start of the block.

Rules

Rules for call reference:

---: The CCS user call reference will be the same as the call reference provided by the user in the CC_SETUP_REQ(7) primitive.
---: The CCS provider call reference will follow the rules of the CC_SETUP_IND(7) in this Corrigendum.

Rules for addresses:

---: The call control address indicated in the CC_SETUP_CON(7) is a BICC_SCOPE_CT (circuit scoped) call control address which identifies the circuit(s) upon which the outgoing call will be connected.
---: For multi-rate calls, the call control address specifies the base circuit (lowest numerical Circuit Identification Code) for the multi-rate call.

CC_CALL_REATTEMPT_IND

This primitive is interpreted as described in CC_CALL_REATTEMPT_IND(7) with the following protocol-specific considerations:

Parameters

cc_user_ref: Indicates the CCS user call reference for the call. This reference identifies the corresponding CC_SETUP_REQ(7) primitives to the CCS user for which the call reattempt need be performed.
cc_reason: Indicates the reason for the reattempt. See ``Reasons'', below.

Reasons

The reason, indicated by cc_reason, can be one of the following values:

BICC_REATTEMPT_DUAL_SEIZURE: Indicates that the circuit was seized by a controlling exchange during the initial setup of the call (i.e, before any backward message was received).
BICC_REATTEMPT_RESET: Indicates that the circuit was reset during the initial setup of the call (i.e, before any backward message was received).
BICC_REATTEMPT_BLOCKING: Indicates that the circuit was blocked during the initial setup of the call (i.e, before any backward message was received).
BICC_REATTEMPT_T24_TIMEOUT: Indicates that COT failure occurred on the circuit (due to T24 timeout).
BICC_REATTEMPT_UNEXPECTED: Indicates that an unexpected message was received for the call during the initial setup of the call (i.e, before any backward message was received).
BICC_REATTEMPT_COT_FAILURE: Indicates that COT failed on the circuit (due to transmission of COT message indicating failure).
BICC_REATTEMPT_CIRCUIT_BUSY: Indicates that the specified circuit was busy.

Rules

Rules for call reference:

---: The CCS user call reference is a call reference associated with an outstanding CC_SETUP_REQ(7) primitive to which the CCS provider is responding.

Rules for reason:

---: The Q.1920 conforming CCS provider will provide one of the reasons listed above.
---: The BICC_REATTEMPT_DUAL_SEIZURE reason will only be indicated if the CCS user represents a non-controlling exchange for the associated trunk group.
---: The BICC_REATTEMPT_T24_TIMEOUT reason will only be indicated if the outgoing call includes a continuity test and a positive CC_CONT_REPORT_REQ(7) was not issued to the CCS provider by a test stream within T24.
---: The BICC_REATTEMPT_COT_FAILURE reason will only be indicated if the outgoing call includes a continuity test and a negative CC_CONT_REPORT_REQ(7) was issued to the CCS provider by a test stream within T24.
---: The BICC_REATTEMPT_CIRCUIT_BUSY reason will only be indicated if the stream issuing the CC_SETUP_REQ(7) primitive is bound to a circuit (BICC_SCOPE_CT) and the circuit is busy with another call.

CC_SETUP_COMPLETE_REQ

This primitive is interpreted as described in CC_SETUP_COMPLETE_REQ(7) with the following protocol-specific considerations:

Rules

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if a CCS provider conforming to Q.1920 receives a CC_SETUP_COMPLETE_REQ(7) for a call reference in the CCS_ANSWERED state (CCS_ICC_ANSWERED), the CCS provider will ignore the primitive.

CC_SETUP_COMPLETE_IND

This primitive is interpreted as described in CC_SETUP_COMPLETE_IND(7) with the following protocol-specific considerations:

Rules

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if a CCS provider conforming to Q.1920 issues a CC_SETUP_COMPLETE_IND(7) for a call reference in the CCS_ANSWERED state, the CCS user may ignore the primitive.

Continuity Check Phase

CC_CONT_CHECK_REQ

This primitive is interpreted as described in CC_CONT_CHECK_REQ(7) with the following protocol-specific considerations:

Parameters

cc_addr_length: Specifies the length of the circuit test address (circuit) upon which the continuity check is to be performed.
cc_addr_offset: Specifies the offset of the circuit test address from the start of the block.

Rules

Rules for addresses:

---: The parameter cc_addr_length cannot be zero: i.e, an address must be provided or the CCS provider should respond with CC_ERROR_ACK(7) with an error of [CCNOADDR].
---: The address provided must be of scope BICC_SCOPE_CT and must provide the identifier of the circuit upon which the CCS user is requesting a continuity check.
---: The specified circuit identifier must be equipped else the CCS provider should response with CC_ERROR_ACK(7) and an error of [CCBADADDR].

CC_CONT_CHECK_IND

This primitive is interpreted as described in CC_CONT_CHECK_IND(7) with the following protocol-specific considerations:

Parameters

cc_call_ref: Indicates the CCS provider call reference.
cc_addr_length: Indicates the length of the identifier of the circuit upon which the continuity check is to be performed.
cc_addr_offset: Indicates the offset of the address from the start of the block.

Rules

Rules for call reference:

---

Rules for addresses:

---: The parameter cc_addr_length cannot be zero: i.e, an address must be provided or the CCS provider should respond with CC_ERROR_ACK(7) with an error of [CCNOADDR].
---: The address provided must be of scope BICC_SCOPE_CT and must provide the identifier of the circuit upon which the CCS user is requesting a continuity check.
---: The specified circuit test address (circuit identifier) must be equipped else the CCS provider should response with CC_ERROR_ACK(7) and an error of [CCBADADDR].

CC_CONT_TEST_REQ

This primitive is interpreted as described in CC_CONT_TEST_REQ(7) with the following protocol-specific considerations:

This primitive is only supported when the Loop Back Acknowledgment is used as a national option under Q.1920 For compatibility with CCS providers not supporting the national option, if such a CCS provider receives a CC_CONT_TEST_REQ(7) while waiting for a CC_CONT_REPORT_IND(7), the CCS provider should silently discard the primitive.

Parameters

cc_call_ref: Specifies the CCS provider call reference.
cc_addr_length: Indicates the length of the call control address (BICC_SCOPE_CT circuit identifier) upon which the continuity check is to be performed.
cc_addr_offset: Indicates the offset of the call control address from the start of the block.

Rules

Rules for addresses:

---: The parameter cc_addr_length cannot be zero: i.e, an address must be provided or the CCS provider should respond with CC_ERROR_ACK(7) with an error of [CCNOADDR].
---: The address provided must be the identifier of the circuit upon which the CCS user is requesting a continuity check.
---: The specified circuit identifier must be equipped else the CCS provider should response with CC_ERROR_ACK(7) and an error of [CCBADADDR].

CC_CONT_TEST_IND

This primitive is interpreted as described in CC_CONT_TEST_IND(7) with the following protocol-specific considerations:

This primitive is only supported when the Loop Back Acknowledgment is used as a national option under Q.1920 For compatibility with CCS providers not supporting the national option, such a CCS provider will issue a CC_CONT_TEST_IND(7) in response to a CC_CONT_CHECK_REQ(7) following the CC_OK_ACK(7).

Parameters

cc_call_ref: Specifies the CCS provider call reference.
cc_addr_length: Specifies the length of the identifier of the circuit upon which the continuity check is to be performed.
cc_addr_offset: Specifies the offset of the address from the start of the block.

Rules

Rules for call reference:

---: The CCS provider assigned call reference is used to associate an outstanding continuity test indication (CC_CONT_CHECK_IND(7) or call setup indication CC_SETUP_IND(7) including a continuity test (BICC_NCI_CONT_CHECK_REQUIRED).

Rules for addresses:

---: The parameter cc_addr_length cannot be zero: i.e, an address must be provided or the CCS provider should respond with CC_ERROR_ACK(7) with an error of [CCNOADDR].
---: The address provided must be the identifier of the circuit upon which the CCS user is requesting a continuity check.
---: The specified circuit identifier must be equipped else the CCS provider should response with CC_ERROR_ACK(7) and an error of [CCBADADDR].

CC_CONT_REPORT_REQ

This primitive is interpreted as described in CC_CONT_REPORT_REQ(7) with the following protocol-specific considerations:

Parameters

cc_user_ref

Specifies the CCS User assigned call reference.

cc_call_ref

Specifies the CCS Provider assigned call reference.

cc_result

Specifies the result of the continuity test, whether success or failure. For Q.1920 conforming CCS provider, the result parameter can be one of the following values:

BICC_COT_SUCCESS: Indicates that the continuity check test was successful.
BICC_COT_FAILURE: Indicates that the continuity check test failed.

cc_addr_length

Specifies the length of the identifier of the circuit upon which the continuity check is to be performed.

cc_addr_offset

Specifies the offset of the address from the start of the block.

Rules

Rules for addresses:

---: The parameter cc_addr_length cannot be zero: i.e, an address must be provided or the CCS provider should respond with CC_ERROR_ACK(7) with an error of [CCNOADDR].
---: The address provided must be the identifier of the circuit upon which the CCS user is requesting a continuity check.
---: The specified circuit identifier must be equipped else the CCS provider should response with CC_ERROR_ACK(7) and an error of [CCBADADDR].

CC_CONT_REPORT_IND

This primitive is interpreted as described in CC_CONT_REPORT_IND(7) with the following protocol-specific considerations:

Parameters

cc_call_ref

Indicates the CCS provider assigned call reference.

cc_result

Indicates the result of the continuity test, whether success or failure. For Q.1920 conforming CCS provider, the result parameter can be one of the following values:

BICC_COT_SUCCESS: Indicates that the continuity check test was successful.
BICC_COT_FAILURE: Indicates that the continuity check test failed.

Rules

Rules for call reference:

---

Call Establishment Primitives

CC_MORE_INFO_REQ

This primitive is interpreted as described in CC_MORE_INFO_REQ(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

---: This primitive is not directly supported by Q.1920 conforming CCS providers. For compatibility with Q.931 conforming CCS providers, if the Q.1920 conforming CCS provider receives a CC_MORE_INFO_REQ(7) in state CCS_WRES_SIND, it should invoke any interworking procedures and silently discard the primitive.

CC_MORE_INFO_IND

This primitive is interpreted as described in CC_MORE_INFO_IND(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

---: This primitive may optionally be issued by a Q.1920 conforming CCS provider in the overlap signalling mode, if the appropriate timer has expired and the CCS provider has not received an indication that the provided address is complete.

CC_INFORMATION_REQ

This primitive is interpreted as described in CC_INFORMATION_REQ(7) with the following protocol-specific considerations:

Parameters

cc_call_ref: Specifies the CCS provider assigned call reference for the call.
cc_subn_length: Specifies the length of the subsequent number. For Q.1920 conforming CCS providers, the format of the called party address is the format of the Subsequent Number parameter (without the parameter type or length octets) as specified in Q.1920
cc_subn_offset: Specifies the offset of the subsequent number from the beginning of the block.

Rules

Rules for issuing primitive:

---: This primitive will only be issued before any CC_PROCEEDING_IND(7), CC_ALERTING_IND(7), CC_PROGRESS_IND(7) or CC_IBI_IND(7) has occurred on the stream while in the CCS_WCON_SREQ state. If not, the CCS provider should respond with a CC_ERROR_ACK(7) primitive with error [CCOUTSTATE].
---: This primitive must not be issued if the preceding CC_SETUP_REQ(7) contained a called party address which was complete (i.e, contains a ST code following the digits). If it is, the CCS provider should respond with a CC_ERROR_ACK(7) with error [CCBADADDR].
---: This primitive must not be issued if the trunk group or circuit to which the stream is bound is configured for en bloc operation. If it is, the CCS provider should respond with a CC_ERROR_ACK(7) with error [CCNOTSUPP].

CC_INFORMATION_IND

This primitive is interpreted as described in CC_INFORMATION_IND(7) with the following protocol-specific considerations:

Parameters

cc_call_ref: Indicates the CCS provider assigned call reference.
cc_subn_length: Indicates the length of the subsequent number. For Q.1920 conforming CCS providers, the format of the subsequent number is the format of the Subsequent Number parameter (without the parameter type or length octets) as specified in Q.1920
cc_subn_offset: Indicates the offset of the subsequent number from the beginning of the block.

Rules

Rules for issuing primitive:

---: This primitive will only be issued by the CCS provider before any CC_PROCEEDING_REQ(7), CC_ALERTING_REQ(7), CC_PROGRESS_REQ(7) or CC_IBI_REQ(7) has been received in state CCS_WCON_SREQ.
---: This primitive will not be issued by the CCS provider if the preceding CC_SETUP_REQ(7) contained a complete called party address (i.e, contains an ST code following the digits), or if the trunk group or circuit is configured for en bloc operation.

CC_INFO_TIMEOUT_IND

This primitive is interpreted as described in CC_INFO_TIMEOUT_IND(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

---: If the Q.1920 conforming CCS provider encounters interworking on a call and is not expecting an address complete message, and timer T11 expires, the CCS provider will issue this primitive to the CCS user.
---: Upon receipt of this primitive, it is the CCS user's responsibility to determine whether the address digits are sufficient and to issue a CC_SETUP_RES(7) or CC_REJECT_REQ(7) primitive.

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if the CCS user receives a CC_INFO_TIMEOUT_IND(7)

CC_PROCEEDING_REQ

This primitive is interpreted as described in CC_PROCEEDING_REQ(7) with the following protocol-specific considerations:

Parameters

cc_flags: Specifies the options associated with the call. Indicates the flags associated with the primitive. See ``Flags'', below.

Flags

For Q.1920 conforming CCS providers, call flags can be an of the following: Q.1920 conforming CCS provider must support the following flags:

The following flags correspond to bits in the Backward Call Indicators parameter of Q.1920:

BICC_BCI_NO_CHARGE, BICC_BCI_CHARGE: When one of these flags is set, it indicates that the call is not to be charged, or the call is to be charged. Otherwise, it indicates that there is no indication with regard to charging.
BICC_BCI_SUBSCRIBER_FREE, BICC_BCI_CONNECT_FREE: When one of these flags is set, it indicates that the terminating subscriber is free, or that the connection is free. Otherwise, no indication is given.
BICC_BCI_ORDINARY_SUBSCRIBER, BICC_BCI_PAYPHONE: When one of these flags is set, it indicates that the call has terminated to an ordinary subscriber, or that the call has terminated to a pay phone.
BICC_BCI_PASS_ALONG_E2E_METHOD_AVAILABLE, BICC_BCI_SCCP_E2E_METHOD_AVAILABLE: When one of these flags is set, either the pass along end-to-end method is available, or the SCCP end-to-end method is available. Otherwise, no end-to-end method is available and only link-by-link method is available.
BICC_BCI_INTERWORKING_ENCOUNTERED: When this flag is set, interworking has been encountered on the call. Otherwise, to interworking has been encountered on the call.
BICC_BCI_E2E_INFORMATION_AVAILABLE: When this flag is set, end-to-end information is now available. Otherwise, no end-to-end information is available.
BICC_BCI_ISDN_USER_PART_ALL_THE_WAY: When this flag is set, ISDN User Part has been used all the way on the call, Otherwise, ISDN User Part has not be used all the way.
BICC_BCI_HOLDING_REQUESTED: When this flag is set, holding is requested. Otherwise, holding is not requested.
BICC_BCI_TERMINATING_ACCESS_ISDN: When this flag is set, the terminating access is ISDN. Otherwise, the terminating access is non-ISDN.
BICC_BCI_IC_ECHO_CONTROL_DEVICE: When set, this flag indicates that an incoming half echo control device is included on the connection. Otherwise, it indicates that no incoming half echo control device is included in the connection.
BICC_BCI_SCCP_CLNS_METHOD_AVAILABLE, BICC_BCI_SCCP_CONS_METHOD_AVAILABLE, BICC_BCI_SCCP_ALL_METHODS_AVAILABLE: When one of these flags is set, either the connectionless SCCP method is available, the connection oriented SCCP method is available, or both methods are available. Otherwise, no SCCP method is indicated as available.

Rules

Rules for issuing primitive:

---: This primitive can only be issued by the CCS user before any CC_ALERTING_REQ(7), CC_PROGRESS_REQ(7) or CC_IBI_REQ(7) has been issued while in state CCS_WRES_SIND.

CC_PROCEEDING_IND

This primitive is interpreted as described in CC_PROCEEDING_IND(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

---: This primitive will only be issued by the CCS provider before any CC_ALERTING_IND(7), CC_PROGRESS_IND(7) or CC_IBI_IND(7) has been issued while in state CCS_WCON_SREQ.

CC_ALERTING_REQ

This primitive is interpreted as described in CC_ALERTING_REQ(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

---: This primitive can only be issued by the CCS user before any CC_PROGRESS_REQ(7) or CC_IBI_REQ(7) has been issued while in state CCS_WRES_SIND.

CC_ALERTING_IND

This primitive is interpreted as described in CC_ALERTING_IND(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

---: This primitive will only be issued by the CCS provider before any CC_PROGRESS_IND(7) or CC_IBI_IND(7) has been issued while in state CCS_WCON_SREQ.

CC_PROGRESS_REQ

This primitive is interpreted as described in CC_PROGRESS_REQ(7) with the following protocol-specific considerations:

Parameters

cc_event: Indicates the progress event. See ``Events'', below.
cc_flags: Indicates the options flags. See ``Flags'', below.

Events

For Q.1920 conforming CCS providers, this can be one of the following:

BICC_EVNT_ALERTING: Indicates that the called party is being alerted. This event is indicated only if a CC_PROCEEDING_IND(7) primitive has already been received.
BICC_EVNT_PROGRESS: Indicates that the call is progressing with the specified optional parameters.
BICC_EVNT_IBI: This event is indicated only by the CC_IBI_IND(7) primitive and will not appear here.
BICC_EVNT_CALL_FORWARDED_ON_BUSY: This event indicates that the call has been forwarded on busy and the optional parameters (if any) contain the attributes of the forwarding (e.g., redirecting number, etc.).
BICC_EVNT_CALL_FORWARDED_ON_NO_ANSWER: This event indicates that the call has been forwarded on no answer and the optional parameters (if any) contain the attributes of the forwarding (e.g., redirecting number, etc.).
BICC_EVNT_CALL_FORWARDED_UNCONDITIONAL: This event indicates that the call has been forwarded unconditionally and the optional parameters (if any) contain the attributes of the forwarding (e.g., redirecting number, etc.).

Flags

Options flags can be one of the following:

BICC_EVNT_PRESENTATION_RESTRICTED: When set, this flag indicates that the event indication is not to be presented to the caller. Otherwise, the event may be presented to the caller.

Rules

Rules for issuing primitive:

---: This primitive can only be issued by the CCS user before any CC_IBI_REQ(7) has been issued while in state CCS_WRES_SIND.

Rules for progress event:

---: Q.1920 conforming CCS providers must support the complete list of progress events listed above.
---: When this primitive is issued with the event BICC_EVNT_ALERTING, it must follow the rules for the primitive CC_ALERTING_REQ(7).
---: When this primitive is issued with the event BICC_EVNT_IBI, it must follow the rules for the primitive CC_IBI_REQ(7).

Rules for progress flags:

---: The flag BICC_EVNT_PRESENTATION_RESTRICTED cannot be set when the event is BICC_EVNT_ALERTING, BICC_EVNT_PROGRESS or BICC_EVNT_IBI.

CC_PROGRESS_IND

This primitive is interpreted as described in CC_PROGRESS_IND(7) with the following protocol-specific considerations:

Parameters

cc_event

Indicates the progress event. The event can be any of the events listed in this Corrigendum under CC_PROGRESS_REQ(7).

cc_flags

Indicates the options flags.

BICC_EVNT_PRESENTATION_RESTRICTED: When set, this flag indicates that the event indication is not to be presented to the caller. Otherwise, the event may be presented to the caller.

Rules

Rules for issuing primitive:

---: This primitive will only be issued by the CCS provider before any CC_IBI_IND(7) has been issued while in state CCS_WCON_SREQ.

Rules for progress event:

---: Q.1920 conforming CCS providers must support the complete list of progress events listed above.
---: This primitive will not be issued by the CCS provider with event BICC_EVNT_ALERTING or event BICC_EVNT_IBI: instead, a CC_ALERTING_IND(7) or CC_IBI_IND(7) event will be issued.

Rules for progress flags:

---: The flag BICC_EVNT_PRESENTATION_RESTRICTED cannot be set when the event is BICC_EVNT_PROGRESS.

CC_IBI_REQ

This primitive is interpreted as described in CC_IBI_REQ(7) with the following protocol-specific considerations:

Rules

CC_IBI_IND

This primitive is interpreted as described in CC_IBI_IND(7) with the following protocol-specific considerations:

Rules

Call Established Primitives

CC_SUSPEND_REQ

This primitive is interpreted as described in CC_SUSPEND_REQ(7) with the following protocol-specific considerations:

Parameters

cc_flags

Specifies options associated with the suspend.

CC_SUSRES_NETWORK_INITIATED: When this flag is set, it indicates that the suspend was network originated. When this flag is not set, it indicates that the suspend was ISDN subscriber initiated.

Rules

Rules for issuing primitive:

---

For Q.1920 conforming CCS providers, suspend can be requested by independently either via local provider or the remote provider. A call can be:

*: Not Suspended
*: Locally Suspended
*: Remotely Suspended
*: Locally and Remotely Suspended

---

Requests to locally suspend a call which is already locally suspended should be ignored by the CCS provider.

CC_SUSPEND_IND

This primitive is interpreted as described in CC_SUSPEND_IND(7) with the following protocol-specific considerations:

Parameters

cc_flags

Specifies options associated with the suspend.

CC_SUSRES_NETWORK_INITIATED: When this flag is set, it indicates that the suspend was network originated. When this flag is not set, it indicates that the suspend was ISDN subscriber initiated.

Rules

Rules for issuing primitive:

---

For Q.1920 conforming CCS providers, suspend can be requested by independently either via local provider or the remote provider. A call can be:

*: Not Suspended
*: Locally Suspended
*: Remotely Suspended
*: Locally and Remotely Suspended

---

Indications of remote suspension of a call which is already remotely suspended will not be issued by the CCS provider.

CC_SUSPEND_RES

This primitive is interpreted as described in CC_SUSPEND_RES(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if the CCS provider receives a CC_SUSPEND_RES(7) in the CCS_WRES_SUSIND or CCS_SUSPENDED states, the CCS provider should ignore the CC_SUSPEND_RES(7) primitive and move directly to the CCS_SUSPENDED state if it has not already done so.

CC_SUSPEND_REJECT_REQ

This primitive is interpreted as described in CC_SUSPEND_REJECT_REQ(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if the CCS provider receives a CC_SUSPEND_REJECT_REQ(7) in the CCS_WRES_SUSIND or CCS_SUSPENDED states, the CCS provider should reply with a CC_ERROR_ACK(7) primitive with error [CCNOTSUPP].

CC_RESUME_REQ

This primitive is interpreted as described in CC_RESUME_REQ(7) with the following protocol-specific considerations:

Parameters

cc_flags

Specifies options associated with the resume.

CC_SUSRES_NETWORK_INITIATED: When this flag is set, it indicates that the resume was network originated. When this flag is not set, it indicates that the resume was ISDN subscriber initiated.

Rules

CC_RESUME_IND

This primitive is interpreted as described in CC_RESUME_IND(7) with the following protocol-specific considerations:

Parameters

cc_flags

Specifies options associated with the resume.

CC_SUSRES_NETWORK_INITIATED: When this flag is set, it indicates that the resume was network originated. When this flag is not set, it indicates that the resume was ISDN subscriber initiated.

Rules

CC_RESUME_RES

This primitive is interpreted as described in CC_RESUME_RES(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if the CCS provider receives a CC_RESUME_RES(7) in the CCS_WRES_SUSIND or CCS_ANSWERED states, the CCS provider should ignore the CC_RESUME_RES primitive and move directly to the CCS_RESUMEED state if it has not already done so.

CC_RESUME_REJECT_REQ

This primitive is interpreted as described in CC_RESUME_REJECT_REQ(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if the CCS provider receives a CC_RESUME_REJECT_REQ(7) in the CCS_WRES_SUSIND or CCS_ANSWERED states, the CCS provider should reply with a CC_ERROR_ACK(7) primitive with error [CCNOTSUPP].

Call Termination Primitives

CC_REJECT_REQ

This primitive is interpreted as described in CC_REJECT_REQ(7) with the following protocol-specific considerations:

Rules

Rules for issuing primitive:

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if the CCS provider receives a CC_REJECT_REQ(7) in the CCS_WRES_SIND(CCS_ICC_WAIT_COT or CCS_ICC_WAIT_ACM) states, the provider should perform an automatic release procedure and move to the CCS_WAIT_RLC state.

CC_CALL_FAILURE_IND

This primitive is interpreted as described in CC_CALL_FAILURE_IND(7) with the following protocol-specific considerations:

Parameters

cc_cause: Indicates the cause of the failure. See ``Causes'', below.

Causes

The cc_cause can have one of the following values:

BICC_CALL_FAILURE_COT_FAILURE: Indicates that the continuity check on the circuit failed. This applies to incoming calls only.
BICC_CALL_FAILURE_RESET, BICC_CALL_FAILURE_RECV_RLC: Indicates that the circuit was not completely released by the distant end. This applies to incoming calls only.
BICC_CALL_FAILURE_BLOCKING: Indicates that the circuit was blocked during call setup. This applies to incoming calls only.
BICC_CALL_FAILURE_T2_TIMEOUT, BICC_CALL_FAILURE_T3_TIMEOUT, BICC_CALL_FAILURE_T6_TIMEOUT: Indicates that the call was suspended beyond the allowable period. This applies to all established calls.
BICC_CALL_FAILURE_T7_TIMEOUT: Indicates that there was no response to the call setup request. This applies to outgoing calls only.
BICC_CALL_FAILURE_T8_TIMEOUT: Indicates that the call failed waiting for a continuity check report from the distant end. This applies to incoming calls only.
BICC_CALL_FAILURE_T9_TIMEOUT: Indicates that the call failed while waiting for the distant end to answer. This applies to outgoing calls only.
BICC_CALL_FAILURE_T35_TIMEOUT: Indicates that additional information (digits) were not received from the caller within a sufficient period. This applies to incoming calls only.
BICC_CALL_FAILURE_T38_TIMEOUT: Indicates that the call was suspended beyond the allowable period. This applies to all established calls.
BICC_CALL_FAILURE_CIRCUIT_BUSY

Rules

CC_DISCONNECT_REQ

This primitive is interpreted as described in CC_DISCONNECT_REQ(7) with the following protocol-specific considerations:

Rules

For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to Q.1920, if the CCS provider receives a CC_DISCONNECT_REQ(7), the provider should respond with CC_ERROR_ACK(7) with the error [CCNOTSUPP].

CC_RELEASE_REQ

This primitive is interpreted as described in CC_RELEASE_REQ(7) with the following protocol-specific considerations:

Parameters

cc_cause: Indicates the cause of the release. See ``Causes'', below.

Causes

Cause can be one of the following values:

CC_CAUS_UNALLOCATED_NUMBER: Unallocated (unassigned) number
CC_CAUS_NO_ROUTE_TO_TRANSIT_NETWORK: No route to specified transit network.
CC_CAUS_NO_ROUTE_TO_DESTINATION: No route to destination.
CC_CAUS_SEND_SPECIAL_INFO_TONE: Send special information tone.
CC_CAUS_MISDIALLED_TRUNK_PREFIX: Misdialled trunk prefix.
CC_CAUS_PREEMPTION: Preemption.
CC_CAUS_PREEMPTION_CCT_RESERVED: Preemption --- circuit reserved for reuse.
CC_CAUS_NORMAL_CALL_CLEARING: Normal call clearing.
CC_CAUS_USER_BUSY: User busy.
CC_CAUS_NO_USER_RESPONDING: No user responding.
CC_CAUS_NO_ANSWER: No answer from user (user alerted).
CC_CAUS_SUBSCRIBER_ABSENT: Subscribed absent.
CC_CAUS_CALL_REJECTED: Call rejected.
CC_CAUS_NUMBER_CHANGED: Number changed.
CC_CAUS_REDIRECT: Redirect to new destination.
CC_CAUS_OUT_OF_ORDER: Destination out of order.
CC_CAUS_ADDRESS_INCOMPLETE: Invalid number format (address incomplete).
CC_CAUS_FACILITY_REJECTED: Facility rejected.
CC_CAUS_NORMAL_UNSPECIFIED: Normal unspecified.
CC_CAUS_NO_CCT_AVAILABLE: No circuit/channel available.
CC_CAUS_NETWORK_OUT_OF_ORDER: Network out of order.
CC_CAUS_TEMPORARY_FAILURE: Temporary failure.
CC_CAUS_SWITCHING_EQUIP_CONGESTION: Switching equipment congestion.
CC_CAUS_ACCESS_INFO_DISCARDED: Access information discarded.
CC_CAUS_REQUESTED_CCT_UNAVAILABLE: Requested circuit/channel not available.
CC_CAUS_PRECEDENCE_CALL_BLOCKED: Precedence call blocked.
CC_CAUS_RESOURCE_UNAVAILABLE: Resource unavailable, unspecified.
CC_CAUS_NOT_SUBSCRIBED: Requested facility not subscribed.
CC_CAUS_OGC_BARRED_WITHIN_CUG: Outgoing calls barred within closed user group.
CC_CAUS_ICC_BARRED WITHIN_CUG: Incoming calls barred within closed user group.
CC_CAUS_BC_NOT_AUTHORIZED: Bearer capability not authorized.
CC_CAUS_BC_NOT_AVAILABLE: Bearer capability not presently available.
CC_CAUS_INCONSISTENCY: Inconsistency in designated outgoing caccess information and subscriber class.
CC_CAUS_SERVICE_OPTION_NOT_AVAILABLE: Service or option not available, unspecified.
CC_CAUS_BC_NOT_IMPLEMENTED: Bearer capability not implemented.
CC_CAUS_FACILITY_NOT_IMPLEMENTED: Requested facility not implemented.
CC_CAUS_RESTRICTED_BC_ONLY: Only restricted digital information bearer capability is available.
CC_CAUS_SERIVCE_OPTION_NOT_IMPLEMENTED: Service or option not implemented, unspecified.
CC_CAUS_USER_NOT_MEMBER_OF_CUG: User not member of closed user group.
CC_CAUS_INCOMPATIBLE_DESTINATION: Incompatible destination.
CC_CAUS_NON_EXISTENT_CUG: Non-existent closed user group.
CC_CAUS_INVALID_TRANSIT_NTWK_SELECTION: Invalid transit network selection.
CC_CAUS_INVALID_MESSAGE: Invalid message, unspecified.
CC_CAUS_MESSAGE_TYPE_NOT_IMPLEMENTED: Message type non-existent or not implemented.
CC_CAUS_PARAMETER_NOT_IMPLEMENTED: Information element/parameter non-existent or not implemented.
CC_CAUS_RECOVERY_ON_TIMER_EXPIRY: Recovery on timer expiry.
CC_CAUS_PARAMETER_PASSED_ON: Parameter non-existent or not implemented --- passed on.
CC_CAUS_MESSAGE_DISCARDED: Message with unrecognized parameter discarded.
CC_CAUS_PROTOCOL_ERROR: Protocol error, unspecified.
CC_CAUS_INTERWORKING: Interworking, unspecified.
CC_CAUS_UNALLOCATED_DEST_NUMBER: Unallocated destination number.
CC_CAUS_UNKNOWN_BUSINESS_GROUP: Unknown business group.
CC_CAUS_EXCHANGE_ROUTING_ERROR: Exchange routing error.
CC_CAUS_MISROUTED_CALL_TO_PORTED_NUMBER: Misrouted call to a ported number.
CC_CAUS_LNP_QOR_NUMBER_NOT_FOUND: Numnber portability query on release (QoR) number not found.
CC_CAUS_PREEMPTION: Preemption.
CC_CAUS_PRECEDENCE_CALL_BLOCKED: Precedence call blocked.
CC_CAUS_CALL_TYPE_INCOMPATIBLE: Call type incompatible with service request.
CC_CAUS_GROUP_RESTRICTIONS: Call blocked due to group restrictions.

Rules

CC_RELEASE_IND

This primitive is interpreted as described in CC_RELEASE_IND(7) with the following protocol-specific considerations:

Parameters

cc_cause: Indicates the cause of the release. Cause can be one of the cause value listed in this Corrigendum under CC_RELEASE_REQ(7).

Rules

Management Primitives

CC_RESTART_REQ

This primitive is interpreted as described in CC_RESTART_REQ(7) with the following protocol-specific considerations:

Rules

For compatibility between CCS providers conforming to Q.931 and CCS provider conforming to Q.1920, if the CCS provider conforming to Q.1920 receives a CC_RESTART_REQ(7), the provider should respond with CC_ERROR_ACK(7) with the error [CCNOTSUPP].

CC_RESET_REQ

This primitive is interpreted as described in CC_RESET_REQ(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_RESET_IND

This primitive is interpreted as described in CC_RESET_IND(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_RESET_RES

This primitive is interpreted as described in CC_RESET_RES(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_RESET_CON

This primitive is interpreted as described in CC_RESET_CON(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_BLOCKING_REQ

This primitive is interpreted as described in CC_BLOCKING_REQ(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_BLOCKING_IND

This primitive is interpreted as described in CC_BLOCKING_IND(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_BLOCKING_RES

This primitive is interpreted as described in CC_BLOCKING_RES(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_BLOCKING_CON

This primitive is interpreted as described in CC_BLOCKING_CON(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_UNBLOCKING_REQ

This primitive is interpreted as described in CC_UNBLOCKING_REQ(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_UNBLOCKING_IND

This primitive is interpreted as described in CC_UNBLOCKING_IND(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_UNBLOCKING_RES

This primitive is interpreted as described in CC_UNBLOCKING_RES(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_UNBLOCKING_CON

This primitive is interpreted as described in CC_UNBLOCKING_CON(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.
BICC_MAINTENANCE_ORIENTED, BICC_HARDWARE_FAILURE_ORIENTED: When one of these flags is set it indicates that either maintenance oriented or hardware failure oriented blocking is to be performed. If both or neither of these flags are set, the primitive will fail with error [CCBADFLAG].

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_QUERY_REQ

This primitive is interpreted as described in CC_QUERY_REQ(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_QUERY_IND

This primitive is interpreted as described in CC_QUERY_IND(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_QUERY_RES

This primitive is interpreted as described in CC_QUERY_RES(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

CC_QUERY_CON

This primitive is interpreted as described in CC_QUERY_CON(7) with the following protocol-specific considerations:

Parameters

cc_flags

Indicates the options flags.

BICC_GROUP: When set, this flag indicates that the operation is to be performed on a group of call control addresses and that any circuit identifier in the specified call control address is to be interpreted by the CCS provider as a circuit group identifier.

cc_addr_length

Indicates the length of the address which consists of a circuit identifier.

cc_addr_offset

Indicates the offset of the address from the start of the block.

Rules

FILES

<ss7/cci.h>, <ss7/cci_ioctl.h>.

REFERENCES

[1]: ANSI T1.BICC.1-2000 to T1.BICC.7-2000, Specifications of the Bearer Independent Call Control (BICC), 2000, ANSI, American National Standards Institute.
[2]: CCI Revision 1.0.0, Call Control Interface (CCI) Specification, Draft 1, April 2003, (Edmonton), B. Bidulock, OpenSS7 Corporation. <http://www.openss7.org/docs/cci.pdf>