Bearer Independent Call Control (BICC)
Description: OpenSS7 Project Status SS7 Stack BICC
CCI-BICC
Section: Call Control Interface (CCI) (7)
Updated: Wed, 07 Jan 2009 01:41:41 GMT
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>
TRADEMARKS
- OpenSS7tm
- is a trademark of OpenSS7 Corporation.
- Linux®
- is a registered trademark of Linus Torvalds.
- UNIX®
- is a registered trademark of The Open Group.
- Solaris®
- is a registered trademark of Sun Microsystems.
Other trademarks are the property of their respective owners.
IDENTIFICATION
-
The OpenSS7 Project: Package OpenSS7 version 0.9.2 released Wed, 07 Jan 2009 01:41:41 GMT.
Copyright©1997-2008OpenSS7 Corp.
All Rights Reserved.
(See roff source for permission notice.)
Index
- NAME
- SYNOPSIS
- DESCRIPTION
- Primitives and Rules for Q.1920 Conformance
- CALL CONTROL ADDRESSES
- OPTIONAL PARAMETERS
- Local Management Primitives
- CC_INFO_ACK
- CC_BIND_REQ
- CC_BIND_ACK
- CC_OPTMGMT_REQ
- Call Setup Primitives
- CC_SETUP_REQ
- CC_SETUP_IND
- CC_SETUP_RES
- CC_SETUP_CON
- CC_CALL_REATTEMPT_IND
- CC_SETUP_COMPLETE_REQ
- CC_SETUP_COMPLETE_IND
- Continuity Check Phase
- CC_CONT_CHECK_REQ
- CC_CONT_CHECK_IND
- CC_CONT_TEST_REQ
- CC_CONT_TEST_IND
- CC_CONT_REPORT_REQ
- CC_CONT_REPORT_IND
- Call Establishment Primitives
- CC_MORE_INFO_REQ
- CC_MORE_INFO_IND
- CC_INFORMATION_REQ
- CC_INFORMATION_IND
- CC_INFO_TIMEOUT_IND
- CC_PROCEEDING_REQ
- CC_PROCEEDING_IND
- CC_ALERTING_REQ
- CC_ALERTING_IND
- CC_PROGRESS_REQ
- CC_PROGRESS_IND
- CC_IBI_REQ
- CC_IBI_IND
- Call Established Primitives
- CC_SUSPEND_REQ
- CC_SUSPEND_IND
- CC_SUSPEND_RES
- CC_SUSPEND_REJECT_REQ
- CC_RESUME_REQ
- CC_RESUME_IND
- CC_RESUME_RES
- CC_RESUME_REJECT_REQ
- Call Termination Primitives
- CC_REJECT_REQ
- CC_CALL_FAILURE_IND
- CC_DISCONNECT_REQ
- CC_RELEASE_REQ
- CC_RELEASE_IND
- Management Primitives
- CC_RESTART_REQ
- CC_RESET_REQ
- CC_RESET_IND
- CC_RESET_RES
- CC_RESET_CON
- CC_BLOCKING_REQ
- CC_BLOCKING_IND
- CC_BLOCKING_RES
- CC_BLOCKING_CON
- CC_UNBLOCKING_REQ
- CC_UNBLOCKING_IND
- CC_UNBLOCKING_RES
- CC_UNBLOCKING_CON
- CC_QUERY_REQ
- CC_QUERY_IND
- CC_QUERY_RES
- CC_QUERY_CON
- FILES
- REFERENCES
- TRADEMARKS
- IDENTIFICATION
This document was created by
man2html,
using the manual pages.
Time: 01:41:39 GMT, January 07, 2009