| ISUPI Technical SpecificationDescription: OpenSS7 Resources Library.A PDF version of this document is available here. Call Control Interface (CCI)Call Control Interface (CCI) SpecificationAbout This ManualThis is Edition 7.20141001, last updated 2014-10-25, of The Call Control Interface (CCI) Specification, for Version 1.1 release 7.20141001 of the OpenSS7 package. PrefaceNoticeSoftware in this document and related software is released under the AGPL (see GNU Affero General Public License). Please note, however, that there are different licensing terms for some of the manual package and some of the documentation. Consult permission notices contained in the documentation of those components for more information. This document is released under the FDL (see GNU Free Documentation License) with no invariant sections, no front-cover texts and no back-cover texts. AbstractThis document is a Specification containing technical details concerning the implementation of the Call Control Interface (CCI) for OpenSS7. It contains recommendations on software architecture as well as platform and system applicability of the Call Control Interface (CCI). This document specifies a Call Control Interface (CCI) Specification in support of the OpenSS7 Integrated Service Digital Network (ISDN) and ISDN User Part (ISUP) protocol stacks.1 It provides abstraction of the call control interface to these components as well as providing a basis for call control for other call control signalling protocols. PurposeThe purpose of this document is to provide technical documentation of the Call Control Interface (CCI). This document is intended to be included with the OpenSS7 STREAMS software package released by OpenSS7 Corporation. It is intended to assist software developers, maintainers and users of the Call Control Interface (CCI) with understanding the software architecture and technical interfaces that are made available in the software package. IntentIt is the intent of this document that it act as the primary source of information concerning the Call Control Interface (CCI). This document is intended to provide information for writers of OpenSS7 Call Control Interface (CCI) applications as well as writers of OpenSS7 Call Control Interface (CCI) Users. AudienceThe audience for this document is software developers, maintainers and users and integrators of the Call Control Interface (CCI). The target audience is developers and users of the OpenSS7 SS7 and ISDN stack. Revision HistoryTake care that you are working with a current version of this documentation: you will not be notified of updates. To ensure that you are working with a current version, check the OpenSS7 Project website for a current version. A current version of this specification is normally distributed with the OpenSS7 package, openss7-1.1.7.20141001.2 Version ControlAlthough the author has attempted to ensure that the information in this document is complete and correct, neither the Author nor OpenSS7 Corporation will take any responsibility in it. OpenSS7 Corporation is making this documentation available as a reference point for the industry. While OpenSS7 Corporation believes that these interfaces are well defined in this release of the document, minor changes may be made prior to products conforming to the interfaces being made available. OpenSS7 Corporation reserves the right to revise this software and documentation for any reason, including but not limited to, conformity with standards promulgated by various agencies, utilization of advances in the state of the technical arts, or the reflection of changes in the design of any techniques, or procedures embodied, described, or referred to herein. OpenSS7 Corporation is under no obligation to provide any feature listed herein. $Log: cci.texi,v $ Revision 1.1.2.2 2011-02-07 02:21:37 brian - updated manuals Revision 1.1.2.1 2009-06-21 10:52:47 brian - added files to new distro ISO 9000 ComplianceOnly the TeX, texinfo, or roff source for this maual is controlled. An opaque (printed, postscript or portable document format) version of this manual is a UNCONTROLLED VERSION. DisclaimerOpenSS7 Corporation disclaims all warranties with regard to this documentation including all implied warranties of merchantability, fitness for a particular purpose, non-infrincement, or title; that the contents of the manual are suitable for any purpose, or that the implementation of such contents will not infringe on any third party patents, copyrights, trademarks or other rights. In no event shall OpenSS7 Corporation be liable for any direct, indirect, special or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action or contract, negligence or other tortious action, arising out of or in connection with any use of this documentation or the performance or implementation of the contents thereof. U.S. Government Restricted RightsIf you are licensing this Software on behalf of the U.S. Government ("Government"), the following provisions apply to you. If the Software is supplied by the Department of Defense ("DoD"), it is classified as "Commercial Computer Software" under paragraph 252.227-7014 of the DoD Supplement to the Federal Aquisition Regulations ("DFARS") (or any successor regulations) and the Government is acquiring only the license rights granded herein (the license rights customarily provided to non-Government users). If the Software is supplied to any unit or agency of the Government other than DoD, it is classified as "Restricted Computer Software" and the Government’s rights in the Software are defined in paragraph 52.227-19 of the Federal Acquisition Regulations ("FAR") (or any successor regulations) or, in the cases of NASA, in paragraph 18.52.227-86 of the NASA Supplerment to the FAR (or any successor regulations). AcknowledgementsThe OpenSS7 Project was funded in part by: Thanks to the subscribers to and sponsors of The OpenSS7 Project. Without their support, open software like this would not be possible. As with most open source projects, this project would not have been possible without the valiant efforts and productive software of the Free Software Foundation, the Linux Kernel Community, and the open source software movement at large. 1 IntroductionThis document specifies a STREAMS-based kernel-level instantiation of the ITU-T Call Control Interface (CCI) definition. The Call Control Interface (CCI) enables the user of a call control service to access and use any of a variety of conforming call control service providers without specific knowledge of the provider’s protocol. The service interface is designed to support any network call control protocol and user call control protocol. This interface only specifies access to call control service providers, and does not address issues concerning call control and circuit management, protocol performance, and performance analysis tools. This specification assumes that the reader is familiar with ITU-T state machines and call control interfaces (e.g., Q.764, Q.931), and STREAMS. 1.1 Related Documentation
1.1.1 RoleThis document specifies an interface that supports the services provided by the Integrated Services Digital Network (ISDN) and ISDN User Part (ISUP) for ITU-T applications as described in ITU-T Recommendation Q.931 and ITU-T Recommendation Q.764.3 These specifications are targeted for use by developers and testers of protocol modules that require call control service. 1.2 Definitions, Acronyms, Abbreviations
2 The Call Control LayerThe Call Control Layer provides the means to manage the connection and disconnection of calls. It is responsible for the routing and management of call control signalling between call control-user entities. 2.1 Model of the CCIThe CCI defines the services provided by the call control layer to the call control-user at the boundary between the call control provider and the call control user entity. The interface consists of a set of primitives defined as STREAMS messages that provide access to the call control layer services, and are transferred between the CCS user entity and the CCS provider. These primitives are of two types; ones that originate from the CCS user, and others that originate from the CCS provider. The primitives that originate from the CCS user make requests to the CCS provider, or respond to an indication of an event of the CCS provider. The primitives that originate from the CCS provider are either confirmations of a request or are indications to the CCS user that an event has occurred. Figure 1 shows the model of the CCI. ![]() Figure 1. Model of the CCI
The CCI allows the CCS provider to be configured with any call control layer user (such as an ISDN
user call control application) that also conforms to the CCI. A call control layer user can also be
a user program that conforms to the CCI and accesses the CCS provider via 2.2 CCI ServicesThe features of the CCI are defined in terms of the services provided by the CCS provider, and the individual primitives that may flow between the CCS user and the CCS provider. The services supported by the CCI are based on three distinct modes of communication, user-network interface (UNI) User mode, user-network interface (UNI) Network mode, and network-network interface (NNI). In addition, the CCI supports services for local management. 2.2.1 UNIThe main features of the User-Network Interface mode of communication are:
2.2.1.1 Address FormatsAddresses specifying all the calls and channels known to the provider are specified with scope Customer/Provider GroupA customer/provider group has a different interpretation on the User and Network side of the call control interface. In User mode, the provider group is a group of all equipment groups that are serviced by the same network provider. In Network mode, the customer group is a group of all equipment groups to which the same service is provided to the same customer by the network. Customer/provider groups are identifier using a unique customer/provider group identifier within the
CCS provider. Addresses specifying all of the equipment groups in a customer/provider group and
specified with scope Equipment GroupAn equipment group is a group of all transmission groups (B- and D-channels) terminating at the same location. For User mode this corresponds to all the B- and D-channels terminating on the same network provider exchange. For Network mode this corresponds to all the B- and D-channels terminating on the same customer site. Equipment groups are identified using a unique equipment group identifier within the CCS provider.
Addresses specifying all of the B- and D-channels making up an equipment group are specified with
scope Facility GroupA facility group is a group of D-channels (data links) controlling a set of B-channels. This corresponds to the signalling interface. For regular interfaces, a signalling relation consists of a single signalling interface. Where multiple signalling interfaces are used to control the same range of channels (e.g. primary and backup interfaces), all signalling interfaces belong to the same facility group. The B-channels that make up a facility group are channels that share the same dial plan and routing characteristics for telephone calls. A facility group is associated with an equipment group. Facility groups are identified using a unique facility group identifier within the CCS provider.
Addresses specifying all of the channels in a facility group are specified with scope
An ISDN Channel Identifier is only unique within a facility group. Transmission GroupA transmission group is the group of all D- and B-Channels associated with a given Q.931 signalling interface. For example, a typical PRI interface would consist of 23B+D, where there is one signalling interface (the D-Channel) with 23 B-Channels associated with the D-Channel. The 1 D-Channel and 23 B-Channels form a single transmission group associated with the physical interface. Every D- or B-Channel belongs to one transmission group and occupies a single time slot within that transmission group. Transmission groups are identified using a unique transmission group identifier within the CCS
provider. Addresses specifying all of the channels in a transmission group are specified with scope
ChannelA channel refers to a specific B-Channel within a transmission and facility group. Channels are identified using a unique channel identifier within the CCS provider. Addresses
specifying a specific channel are specified with scope Data LinkA data link corresponds to a specific D-channel used for the control of channels. Data links can be grouped into facility groups. Data links are identified using a unique data link identifier within the CCS provider. Addresses
specifying all of the channels controlled by a data link are specified with scope
![]() Figure 2. UNI Data Model
2.2.2 NNIThe main features of the Network-Network Interface mode of communication are:
2.2.2.1 Address FormatsAddresses specifying all of the circuits known to the provider are specified with scope Signalling PointsA signalling point is the SS7 signalling point (central office) that the provider represents. A CCS provider can represent more than one signalling point. A signalling point is identifier using a unique signalling point identifier within the CCS provider. Addresses
specifying all of the circuits in signalling point are specified with scope Signalling RelationsA signalling relation is a relationship between a local signalling point and a remote signalling point. A signalling relation consists of a single signalling interface. Signalling relations are identified using a unique signalling relation identifier within the CCS provider. Addresses
specifying all of the circuits in a signalling relation are specified with scope An ISUP Circuit Identification Code is only unique within a signalling relation. Trunk GroupsA trunk group is a group of circuits that share the same routing characteristics for telephone calls. A trunk group is associated with a signalling relation. For the NNI, a signalling relation is the combination of local MTP Point Code and remote MTP Point Code. A trunk group is identified using a unique trunk group identifier within the CCS provider. Addresses specifying all of
the circuits in a trunk group are specified with scope Circuit GroupsA circuit group is a group of circuits that share the same common transmission facility (e.g, E1 span) and is therefore impacted by any failure of the transmission facility. All of the individual channels of an E1 span that are used to carry calls are members of the circuit group. Circuits groups are identified using a unique circuit group identifier within the CCS provider. Addresses specifying
all of the circuits within a circuit group are specified with scope CircuitsA circuit refers to a specific time slot within a digital facility. Circuits are identified using a unique circuit identifier within the CCS provider. Addresses specifying a specific
circuit are specified with scope ![]() Figure 3. NNI Data Model
2.2.3 Local ManagementThe CCI specifications also define a set of local management functions that apply to UNI and NNI modes of communication. These services have local significance only. Tables 1, 2 and 3 summarizes the CCI service primitives by their state and service. 3 CCI Services DefinitionThis section describes the services of the CCI primitives. Time-sequence diagrams that illustrate the sequence of primitives are included. (Conventions for the time-sequence diagrams are defined in ITU-T X.210.) The format of the primitives will be defined later in this document. ![]() Table 1. CCI Service Primitives
3.1 Local Management Services DefinitionThe services defined in this section are outside the scope of international standards. These services apply to UNI (User and Network), and NNI modes of communication. They are invoked for the initialization/de-initialization of a stream connected to the CCS provider. They are also used to manage options supported by the CCS provider and to report information on the supported parameter values. 3.1.1 Call Control Information Reporting ServiceThis service provides information on the options supported by the CCS provider.
The sequence of primitive for call control information management is shown in Figure 4. ![]() Figure 4. Sequence of Primitives: Call Control Information Reporting Service
3.1.2 CCS Address ServiceThis service allows a CCS user to determine the bound call control address and the connected call control address for a given call reference associated with a stream. It permits the CCS user to not necessarily retain this information locally, and allows the CCS user to determine this information from the CCS provider at any time.
The sequence of primitives is shown in Figure 5. ![]() Figure 5. Sequence of Primitives: Call Control User Address Service
3.1.3 CCS User Bind ServiceThis service allows a call control address to be associated with a stream. It allows the CCS user to negotiate the number of setup indications that can remain unacknowledged for that CCS user (a setup indication is considered unacknowledged while it is awaiting a corresponding setup response or release request from the CCS user). This service also defines a mechanism that allows a stream (bound to a call control address of the CCS user) to be reserved to handle incoming calls only. This stream is referred to as the listener stream.
The sequence of primitives is shown in Figure 6 . ![]() Figure 6. Sequence of Primitives: Call Control User Bind Service
3.1.4 CCS User Unbind ServiceThis service allows the CCS user to be unbound from a call control address.
The sequence of primitives is shown in Figure 7. ![]() Figure 7. Sequence of Primitives: Call Control User Unbind Service
3.1.5 Receipt Acknowledgement Service
An example showing the sequence of primitives for successful receipt acknowledgement is depicted in Figure 8. ![]() Figure 8. Sequence of Primitives: Call Control Receipt Acknowledgement Service
3.1.6 Options Management ServiceThis service allows the CCS user to manage options parameter values associated with the CCS provider.
Figure 9 shows the sequence of primitives for call control options management. ![]() Figure 9. Sequence of Primitives: Call Control Options Management Service
3.1.7 Error Acknowledgement Service
Figure 10 shows the sequence or primitives for the error management primitive. ![]() Figure 10. Sequence of Primitives: Call Control Error Acknowledgement Service
3.2 User-Network Interface Services DefinitionThis section describes the required call control service primitives that define the UNI interface. The queue model for UNI is discussed in more detail in ITU-T Q.931. For Q.931 specific conformance considerations, see Addendum for Q.931 Conformance. The queue model represents the operation of a call control connection in the abstract by a pair of queues linking the two call control addresses. There is one queue for each direction of signalling transfer. The ability of a user to add objects to a queue will be determined by the behaviour of the user removing objects from that queue, and the state of the queue. The pair of queues is considered to be available for each potential call. Objects that are entered or removed from the queue are either as a result of interactions at the two call control addresses, or as the result of CCS provider initiatives.
Table 3 shows the ordering relationship among the queue model objects. ![]() Figure 11. Sequence of Primitives: Call Control UNI Overview
3.2.1 Call Setup PhaseA pair of queues is associated with a call between two call control addresses (facility group and channel(s)) when the
CCS provider receives a The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the destination
CCS user is unable to accept the 3.2.1.1 User Primitives for Successful Call Setup
3.2.1.2 Provider Primitives for Successful Call Setup
The sequence of primitives in a successful call setup is defined by the time sequence diagram shown in Figure 12. The sequence of primitives for the call response token value determination is shown in Figure 13 (procedures for call response token value determination are discussed in section 4.1.3 and 4.1.4.) ![]() Figure 12. Sequence of Primitives: Call Control Call Setup Service
![]() Figure 13. Sequence of Primitives: Call Control Token Request Service
If the CCS provider is unable to establish a call, it indicates this to the request by a ![]() Figure 14. Sequence of Primitives: Call Reattempt - CCS Provider
The sequence of primitives for call reattempt on dual seizure are shown in Figure 15. ![]() Figure 15. Sequence of Primitives: Call Reattempt - Dual Seizure
3.2.2 Call Establishment PhaseDuring the call establishment phase, a pair of queues has already been associated with the call between the selected call control addresses (facility group and channel(s)) during the setup phase. 3.2.2.1 User Primitives for Successful Call Establishment
3.2.2.2 Provider Primitives for Successful Call Establishment
3.2.2.3 Provider Primitives for Successful Call SetupThe sequence of primitives in a successful call establishment is defined by the time sequence diagrams as shown in Figure 16. ![]() Figure 16. Sequence of Primitives: Call Control Successful Call Establishment Service
3.2.3 Call Established PhaseFlow control of the call is done by management of the queue capacity, and by allowing objects of certain types to be inserted to the queues, as shown in Table X. 3.2.3.1 Suspend ServiceUser Primitives for Suspend Service
Provider Primitives for Suspend Service
Figure 17 and Figure 18 show the sequence of primitives for suspend service. The sequence of primitives may remain
incomplete if a The sequence of primitives to suspend a call is defined in the time sequence diagram as shown in Figure 17 and Figure 18. ![]() Figure 17. Sequence of Primitives: Call Control Network Suspend Service: Successful
![]() Figure 18. Sequence of Primitives: Call Control Network Suspend Service: Unsuccessful
![]() Figure 19. Sequence of Primitives: Call Control User Suspend Service
3.2.3.2 Resume ServiceUser Primitives for Resume Service
Provider Primitives for Resume Service
Figure 20 and Figure 21 show the sequence of primitives for resume service. The sequence of primitives may remain
incomplete if a The sequence of primitives to resume a call is defined in the time sequence diagram as shown in Figure 20 and Figure 21. ![]() Figure 20. Sequence of Primitives: Call Control Resume Service: Successful
![]() Figure 21. Sequence of Primitives: Call Control Resume Service: Unsuccessful
![]() Figure 22. Sequence of Primitives: Call Control User Resume Service
The sequence of primitives as shown above may remain incomplete if a 3.2.4 Call Termination Phase3.2.4.1 Call Reject ServiceUser Primitives for Call Reject Service
Provider Primitives for Call Reject Service
The sequence of events for rejecting a call setup attempt at the UNI is defined in the time sequence diagram shown in Figure 23. ![]() Figure 23. Sequence of Primitives: Rejecting a Call Setup
3.2.4.2 Call Failure ServiceProvider Primitives for Call Failure Service
The sequence of events for error indications is described in the time sequence diagram shown in Figure 24. ![]() Figure 24. Sequence of Primitives: Call Failure
3.2.4.3 Call Release ServiceThe call release procedure is initialized by the insertion of a release object (associated with a
The Release procedure invokes the following interactions:
The sequence of primitive depends on the origin of the release action. The sequence may be:
User Primitives for Release Service
Provider Primitives for Release Service
The sequence of primitives as shown in Figure 25, Figure 26, Figure 27, and Figure 28 may remain incomplete if a
A CCS user can release a call establishment attempt by issuing a ![]() Figure 25. Sequence of Primitives: CCS User Invoked Release
![]() Figure 26. Sequence of Primitives: Simultaneous CCS User Invoked Release
![]() Figure 27. Sequence of Primitives: CCS Provider Invoked Release
![]() Figure 28. Sequence of Primitives: Simultaneous CCS User and CCS Provider Invoked Release
3.2.5 Call Management3.2.5.1 User Primitives for Call Management
3.2.5.2 Provider Primitives for Call Management
3.3 Network-Network Interface Services DefinitionThis section describes the required call control service primitives that define the NNI interface. The queue model for NNI is discussed in more detail in ITU-T Q.764. For Q.764 specific conformance considerations, see Addendum for Q.764 Conformance. For ETSI EN 300 356-1 V3.2.2 specific conformance considerations, see Addendum for ETSI EN 300 356-1 V3.2.2 Conformance. ![]() Figure 29. Sequence of Primitives: Call Control NNI Overview
3.3.1 Call Setup PhaseA pair of queues is associated with a call between the two call control addresses when the CCS provider receives a
The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the destination
CCS user is unable to accept the 3.3.1.1 User Primitives for Successful Call Setup
3.3.1.2 Provider Primitives for Successful Call Setup
The sequence of primitives in a successful call setup is defined by the time sequence diagrams as shown in ‘Figure 30’ and Figure 31. The sequence of primitives for the call response token value determination is shown in Figure 32 (procedures for call response token value determination are discussed in section 4.1.3 and 4.1.4.) ![]() Figure 31. Sequence of Primitives: Call Control Call Setup Service: Overlap Sending
![]() Figure 32. Sequence of Primitives: Call Control Token Request Service
If the CCS provider is unable to establish a call, it indicates this to the request by a ![]() Figure 33. Sequence of Primitives: Call Reattempt - CCS Provider
The sequence of primitives for call reattempt on dual seizure are shown in Figure 34. ![]() Figure 34. Sequence of Primitives: Call Reattempt - Dual Seizure
3.3.2 Continuity Test PhaseThe continuity test service is only applicable to the NNI. During the continuity test phase, a pair of queues has already been associated with the call between the selected call
control addresses (signalling interface and circuit(s)) during the setup phase. The continuity test phase begins when
the CCS provider returns a Upon entering the continuity test phase, it is the responsibility of the CCS user to establish a loop back on the call control address (signalling interface and circuit(s)) or to attach tone generation and detection devices to the call control address (signalling interface and circuit(s)). 3.3.2.1 Continuity Test SuccessfulUser Primitives for Successful Continuity Test
Provider Primitives for Successful Continuity Test
The sequence of primitives in a successful continuity test associated with call setup when continuity check is required on the circuit(s) is defined by the time sequence diagrams as shown in Figure 35. ![]() Figure 35. Sequence of Primitives: Call Setup Continuity Test Service: Required: Successful
The sequence of primitives in a successful continuity test associated with call setup when continuity check is being performed on a previous circuit is defined by the time sequence diagrams as shown in Figure 36. ![]() Figure 36. Sequence of Primitives: Call Setup Continuity Test Service: Previous: Successful
The sequence of primitives in a successful continuity test not associated with call setup is defined by the time sequence diagrams as shown in Figure 37. ![]() Figure 37. Sequence of Primitives: Continuity Test Service: Successful
3.3.2.2 Continuity Test UnsuccessfulUser Primitives for Unsuccessful Continuity Test
Provider Primitives for Unsuccessful Continuity Test
The sequence of primitives for an unsuccessful continuity test associated with a call setup is defined by the time sequence diagrams as shown in Figure 38. ![]() Figure 38. Sequence of Primitives: Call Setup Continuity Test Service: Unsuccessful
The sequence of primitives for an unsuccessful continuity test not associated with a call setup is defined by the time sequence diagrams as shown in Figure 39. ![]() Figure 39. Sequence of Primitives: Continuity Test Service: Unsuccessful
3.3.3 Call Establishment PhaseDuring the call establishment phase, a pair of queues has already been associated with the call between the selected
call control addresses (signalling interface and circuit(s)) during the setup phase. The call establishment phase
begins when the CCS provider returns a Upon entering the call establishment phase, it is the responsibility of the CCS user to remove any loop back from the call control address (signalling interface and circuit(s)) or to remove tone generation and detection devices from the call control address (signalling interface and circuit(s)). 3.3.3.1 User Primitives for Successful Call Establishment
|