0% found this document useful (0 votes)

163 views348 pages

Call Control ss7 PDF

This document contains 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. OpenSS7 Corporation makes no representation about the suitability of this documentation for any purpose.

Uploaded by

Master

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

163 views348 pages

Call Control ss7 PDF

Uploaded by

Master

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 348

Call Control Interface (CCI) Specification

Call Control Interface (CCI)

Specification
Version 1.1 Edition 1.20110510
Updated October 28, 2011
Distributed with Package openss7-1.1.1.20110510

c 2008-2009 Monavacon Limited

Abstract:
This document is a Specification containing technical details concerning the implementation of the Call Control Interface (CCI) for OpenSS7. It contains recommendations
on software architecture as well as platform and system applicability of the Call Control Interface (CCI). It provides abstraction of the Call Control (CC) interface to these
components as well as providing a basis for Call Control control for other Call Control
protocols.

Brian Bidulock <[email protected]> for

The OpenSS7 Project <http://www.openss7.org/>

Published by:
OpenSS7 Corporation
1469 Jefferys Crescent
Edmonton, Alberta T6L 6T1
Canada
c 2008-2009 Monavacon Limited
Copyright
c 2001-2008 OpenSS7 Corporation
Copyright
c 1997-2000 Brian F. G. Bidulock
Copyright
All Rights Reserved.
Unauthorized distribution or duplication is prohibited.
Permission is granted to copy, distribute and/or modify this document under the terms of the
GNU Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of
the license is included in the section entitled [GNU Free Documentation License], page 318.
Permission to use, copy and distribute this documentation without modification, for any purpose
and without fee or royalty is hereby granted, provided that both the above copyright notice and
this permission notice appears in all copies and that the name of OpenSS7 Corporation not be
used in advertising or publicity pertaining to distribution of this documentation or its contents
without specific, written prior permission. OpenSS7 Corporation makes no representation about
the suitability of this documentation for any purpose. It is provided as is without express or
implied warranty.

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

Short Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 The Call Control Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 CCI Services Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 CCI Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5 Diagnostics Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Addendum for Q.931 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Addendum for Q.764 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Addendum for ETSI EN 300 356-1 V3.2.2 Conformance . . . . . . . . . 271
A Mapping of CCI Primitives to Q.931 . . . . . . . . . . . . . . . . . . . . . . . . 275
B Mapping of CCI Primitives to Q.764 . . . . . . . . . . . . . . . . . . . . . . . . 277
C State/Event Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
D Primitive Precedence Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
E CCI Header File Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

iii

Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISO 9000 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
U.S. Government Restricted Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5
5
5
5
5
5
6
6
6
6
7

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Definitions, Acronyms, Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

The Call Control Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1
2.2

Model of the CCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CCI Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 UNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1.1 Address Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 NNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2.1 Address Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Local Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11
11
11
12
14
14
15

CCI Services Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1

Local Management Services Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.1 Call Control Information Reporting Service . . . . . . . . . . . . . . . . . . . . .
3.1.2 CCS Address Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 CCS User Bind Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 CCS User Unbind Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5 Receipt Acknowledgement Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.6 Options Management Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.7 Error Acknowledgement Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 User-Network Interface Services Definition . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Call Setup Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.1 User Primitives for Successful Call Setup . . . . . . . . . . . . . . . . . . .
3.2.1.2 Provider Primitives for Successful Call Setup . . . . . . . . . . . . . . .
3.2.2 Call Establishment Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.1 User Primitives for Successful Call Establishment . . . . . . . . . .

18
18
18
19
19
20
20
21
22
23
23
24
26
26

Call Control Interface (CCI)

3.2.2.2 Provider Primitives for Successful Call Establishment . . . . . .
3.2.2.3 Provider Primitives for Successful Call Setup . . . . . . . . . . . . . . .
3.2.3 Call Established Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.1 Suspend Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.2 Resume Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Call Termination Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4.1 Call Reject Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4.2 Call Failure Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4.3 Call Release Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 Call Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5.1 User Primitives for Call Management . . . . . . . . . . . . . . . . . . . . . .
3.2.5.2 Provider Primitives for Call Management . . . . . . . . . . . . . . . . . .
3.3 Network-Network Interface Services Definition . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Call Setup Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1.1 User Primitives for Successful Call Setup . . . . . . . . . . . . . . . . . . .
3.3.1.2 Provider Primitives for Successful Call Setup . . . . . . . . . . . . . . .
3.3.2 Continuity Test Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.1 Continuity Test Successful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2.2 Continuity Test Unsuccessful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Call Establishment Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3.1 User Primitives for Successful Call Establishment . . . . . . . . . .
3.3.3.2 Provider Primitives for Successful Call Establishment . . . . . .
3.3.4 Call Established Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4.1 User Primitives for Established Calls . . . . . . . . . . . . . . . . . . . . . . .
3.3.4.2 Provider Primitives for Established Calls . . . . . . . . . . . . . . . . . . .
3.3.5 Call Termination Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5.1 Call Reject Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5.2 Call Failure Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5.3 Call Release Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6 Circuit Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6.1 Reset Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6.2 Blocking Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6.3 Unblocking Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6.4 Query Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26
27
27
27
29
30
30
31
31
34
34
34
35
35
36
36
38
38
40
42
42
42
43
43
44
44
44
45
45
47
47
50
51
52

CCI Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1

Management Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Call Control Information Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Call Control Information Acknowledgement . . . . . . . . . . . . . . . . . . . . .
4.1.3 Protocol Address Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 Protocol Address Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.5 Bind Protocol Address Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.6 Bind Protocol Address Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .
4.1.7 Unbind Protocol Address Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.8 Call Processing Options Management Request. . . . . . . . . . . . . . . . . . .
4.1.9 Call Processing Options Management Acknowledgement . . . . . . . . .
4.1.10 Error Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.11 Successful Receipt Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . .

56
56
57
58
59
60
63
65
66
68
69
71

v
4.2

Primitive Format and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.2.1 Call Setup Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.1.1 Call Control Setup Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.1.2 Call Control Setup Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.1.3 Call Control Setup Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2.1.4 Call Control Setup Confirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.2.1.5 Call Control Reattempt Indication . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.2 Continuity Check Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.2.1 Call Control Continuity Check Request . . . . . . . . . . . . . . . . . . . . 83
4.2.2.2 Call Control Continuity Check Indication . . . . . . . . . . . . . . . . . . 85
4.2.2.3 Call Control Continuity Test Request . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2.4 Call Control Continuity Test Indication . . . . . . . . . . . . . . . . . . . . 89
4.2.2.5 Call Control Continuity Report Request . . . . . . . . . . . . . . . . . . . 90
4.2.2.6 Call Control Continuity Report Indication . . . . . . . . . . . . . . . . . 92
4.2.3 Collecting Information Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2.3.1 Call Control More Information Request . . . . . . . . . . . . . . . . . . . . 93
4.2.3.2 Call Control More Information Indication . . . . . . . . . . . . . . . . . . 95
4.2.3.3 Call Control Information Request . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2.3.4 Call Control Information Indication . . . . . . . . . . . . . . . . . . . . . . . . 98
4.2.3.5 Call Control Information Timeout Indication. . . . . . . . . . . . . . 100
4.2.4 Call Establishment Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.2.4.1 Call Control Proceeding Request. . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.2.4.2 Call Control Proceeding Indication . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.4.3 Call Control Alerting Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.2.4.4 Call Control Alerting Indication . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.2.4.5 Call Control Progress Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.2.4.6 Call Control Progress Indication . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.2.4.7 Call Control In-Band Information Request . . . . . . . . . . . . . . . . 110
4.2.4.8 Call Control In-Band Information Indication . . . . . . . . . . . . . . 112
4.2.4.9 Call Control Connect Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.2.4.10 Call Control Connect Indication . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.2.4.11 Call Control Setup Complete Request. . . . . . . . . . . . . . . . . . . . 116
4.2.4.12 Call Control Setup Complete Indication . . . . . . . . . . . . . . . . . 118
4.2.5 Call Established Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.5.1 Forward Transfer Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.5.2 Forward Transfer Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.2.5.3 Call Control Suspend Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.2.5.4 Call Control Suspend Indication . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.2.5.5 Call Control Suspend Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.2.5.6 Call Control Suspend Confirmation . . . . . . . . . . . . . . . . . . . . . . . 127
4.2.5.7 Call Control Suspend Reject Request . . . . . . . . . . . . . . . . . . . . . 128
4.2.5.8 Call Control Suspend Reject Confirmation . . . . . . . . . . . . . . . . 130
4.2.5.9 Call Control Resume Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.2.5.10 Call Control Resume Indication. . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.2.5.11 Call Control Resume Response . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.2.5.12 Call Control Resume Confirmation . . . . . . . . . . . . . . . . . . . . . . 136
4.2.5.13 Call Control Resume Reject Request . . . . . . . . . . . . . . . . . . . . . 137
4.2.5.14 Call Control Resume Reject Indication. . . . . . . . . . . . . . . . . . . 139

Call Control Interface (CCI)

4.2.6 Call Termination Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.1 Call Control Reject Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.2 Call Control Reject Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.3 Call Control Call Failure Indication . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.4 Call Control Disconnect Request . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.5 Call Control Disconnect Indication. . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.6 Call Control Release Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.7 Call Control Release Indication . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.8 Call Control Release Response . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6.9 Call Control Release Confirmation . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Management Primitive Formats and Rules . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Interface Management Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1.1 Interface Management Restart Request . . . . . . . . . . . . . . . . . . .
4.3.1.2 Interface Management Restart Confirmation . . . . . . . . . . . . . .
4.3.2 Circuit Management Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2.1 Circuit Management Reset Request . . . . . . . . . . . . . . . . . . . . . . .
4.3.2.2 Circuit Management Reset Indication . . . . . . . . . . . . . . . . . . . . .
4.3.2.3 Circuit Management Reset Response . . . . . . . . . . . . . . . . . . . . . .
4.3.2.4 Circuit Management Reset Confirmation . . . . . . . . . . . . . . . . . .
4.3.2.5 Circuit Management Blocking Request . . . . . . . . . . . . . . . . . . . .
4.3.2.6 Circuit Management Blocking Indication . . . . . . . . . . . . . . . . . .
4.3.2.7 Circuit Management Blocking Response. . . . . . . . . . . . . . . . . . .
4.3.2.8 Circuit Management Blocking Confirmation . . . . . . . . . . . . . . .
4.3.2.9 Circuit Management Unblocking Request . . . . . . . . . . . . . . . . .
4.3.2.10 Circuit Management Unblocking Indication . . . . . . . . . . . . . .
4.3.2.11 Circuit Management Unblocking Response . . . . . . . . . . . . . . .
4.3.2.12 Circuit Management Unblocking Confirmation . . . . . . . . . . .
4.3.2.13 Circuit Management Query Request . . . . . . . . . . . . . . . . . . . . .
4.3.2.14 Circuit Management Query Indication . . . . . . . . . . . . . . . . . . .
4.3.2.15 Circuit Management Query Response . . . . . . . . . . . . . . . . . . . .
4.3.2.16 Circuit Management Query Confirmation . . . . . . . . . . . . . . . .
4.3.3 Maintenance Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3.1 Maintenance Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Circuit Continuity Test Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4.1 Circuit Continuity Check Request . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4.2 Circuit Continuity Check Indication . . . . . . . . . . . . . . . . . . . . . .
4.3.4.3 Circuit Continuity Test Request . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4.4 Circuit Continuity Test Indication . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4.5 Circuit Continuity Report Request . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4.6 Circuit Continuity Report Indication. . . . . . . . . . . . . . . . . . . . . .
4.3.5 Collecting Information Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

140
140
142
143
144
146
147
149
151
153
154
154
154
155
156
156
158
159
161
162
164
165
167
168
170
171
173
174
176
177
179
180
180
181
181
183
185
187
188
190
191

Diagnostics Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

5.1
5.2

Non-Fatal Error Handling Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Fatal Error Handling Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

vii

Addendum for Q.931 Conformance . . . . . . . . . . . . . . . . . . . . . . . . 195

Primitives and Rules for Q.931 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Control Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Optional Information Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local Management Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC INFO ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC BIND REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC BIND ACK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC OPTMGMT REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Setup Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Type and Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC CONT CHECK REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC CONT TEST REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC CONT REPORT REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC SUSPEND REJECT REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC SUSPEND REJECT IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RESUME REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RESUME IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RESUME RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RESUME CON. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

195
195
195
197
198
198
198
199
199
199
199
203
205
206
206
206
207
207
207
207
207
207
207
208
208
208
208
208
209
209
209
209
209
209
210
210
210
210
210
210
211
211
211
211
212
212
212

viii

Call Control Interface (CCI)

CC RESUME REJECT REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RESUME REJECT IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Termination Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cause Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC REJECT REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC REJECT IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC CALL FAILURE IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC DISCONNECT REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC DISCONNECT IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RELEASE REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RELEASE IND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RELEASE RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RELEASE CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Management Primitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RESTART REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC RESTART CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q.931 Header File Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

212
212
213
213
216
217
217
217
218
218
218
218
218
219
219
219
219

Addendum for Q.764 Conformance . . . . . . . . . . . . . . . . . . . . . . . . 225

Primitives and Rules for Q.764 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Primitive Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

225
225
225
227
228
228
228
230
230
230
231
234
235
235
236
237
237
237
237
238
238
239
240
240
241
241
241
241
242

ix
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q.764 Header File Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

242
242
244
244
244
244
245
246
246
246
246
247
247
247
248
248
248
248
249
249
249
250
250
253
253
254
254
254
254
255
255
256
256
257
257
258
258
259
259
260
260
260
261

Call Control Interface (CCI)

Addendum for ETSI EN 300 356-1 V3.2.2 Conformance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Primitives and Rules for ETSI EN 300 356-1 V3.2.2 Conformance . . . . . . . .
Local Management Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Setup Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC SETUP REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CC SETUP IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ETSI EN 300 356-1 V3.2.2 Header File Listing . . . . . . . . . . . . . . . . . . . . . . . . . . .

271
271
271
271
271
274

Appendix A

Mapping of CCI Primitives to Q.931 . . . . . 275

Appendix B

Mapping of CCI Primitives to Q.764 . . . . . 277

Appendix C

State/Event Tables . . . . . . . . . . . . . . . . . . . . . . . . . 279

Appendix D

Primitive Precedence Tables . . . . . . . . . . . . . . . 281

Appendix E

Preface

Preface
Notice
Software in this document and related software is released under the AGPL (see [GNU Affero General
Public License], page 307). 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], page 318) with
no invariant sections, no front-cover texts and no back-cover texts.

Abstract
This document is a Specification containing technical details concerning the implementation of the
Call Control Interface (CCI) for OpenSS7. It contains recommendations on software architecture as
well as platform and system applicability of the Call Control Interface (CCI).
This document specifies a Call Control Interface (CCI) Specification in support of the OpenSS7
Integrated Service Digital Network (ISDN) and ISDN User Part (ISUP) protocol stacks.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.
Purpose
The purpose of this document is to provide technical documentation of the Call Control Interface
(CCI). This document is intended to be included with the OpenSS7 STREAMS software package
released by OpenSS7 Corporation. It is intended to assist software developers, maintainers and
users of the Call Control Interface (CCI) with understanding the software architecture and technical
interfaces that are made available in the software package.
Intent
It is the intent of this document that it act as the primary source of information concerning the Call
Control Interface (CCI). This document is intended to provide information for writers of OpenSS7
Call Control Interface (CCI) applications as well as writers of OpenSS7 Call Control Interface (CCI)
Users.
Audience
The audience for this document is software developers, maintainers and users and integrators of the
Call Control Interface (CCI). The target audience is developers and users of the OpenSS7 SS7 and
ISDN stack.

Revision History
Take care that you are working with a current version of this documentation: you will not be
notified of updates. To ensure that you are working with a current version, check the OpenSS7
Project website for a current version.
1

As a future extension to the interface, H.225, BSSAP, and SIP will be supported.

2011-10-28

Preface

A current version of this specification is normally distributed with the OpenSS7 package,
openss7-1.1.1.20110510.2
Version Control
Although the author has attempted to ensure that the information in this document is complete and
correct, neither the Author nor OpenSS7 Corporation will take any responsibility in it. OpenSS7
Corporation is making this documentation available as a reference point for the industry. While
OpenSS7 Corporation believes that these interfaces are well defined in this release of the document,
minor changes may be made prior to products conforming to the interfaces being made available.
OpenSS7 Corporation reserves the right to revise this software and documentation for any reason,
including but not limited to, conformity with standards promulgated by various agencies, utilization
of advances in the state of the technical arts, or the reflection of changes in the design of any
techniques, or procedures embodied, described, or referred to herein. OpenSS7 Corporation is under
no obligation to provide any feature listed herein.
$Log: cci.texi,v $
Revision 1.1.2.2 2011-02-07 02:21:37
- updated manuals
Revision 1.1.2.1 2009-06-21 10:52:47
- added files to new distro

brian

ISO 9000 Compliance

Only the TEX, texinfo, or roff source for this maual is controlled. An opaque (printed, postscript or
portable document format) version of this manual is a UNCONTROLLED VERSION.
Disclaimer
OpenSS7 Corporation disclaims all warranties with regard to this documentation including all implied warranties of merchantability, fitness for a particular purpose, non-infrincement, or title; that
the contents of the manual are suitable for any purpose, or that the implementation of such contents will not infringe on any third party patents, copyrights, trademarks or other rights. In no
event shall OpenSS7 Corporation be liable for any direct, indirect, special or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action or
contract, negligence or other tortious action, arising out of or in connection with any use of this
documentation or the performance or implementation of the contents thereof.
U.S. Government Restricted Rights
If you are licensing this Software on behalf of the U.S. Government ("Government"), the following
provisions apply to you. If the Software is supplied by the Department of Defense ("DoD"), it is classified as "Commercial Computer Software" under paragraph 252.227-7014 of the DoD Supplement
to the Federal Aquisition Regulations ("DFARS") (or any successor regulations) and the Government is acquiring only the license rights granded herein (the license rights customarily provided to
non-Government users). If the Software is supplied to any unit or agency of the Government other
than DoD, it is classified as "Restricted Computer Software" and the Governments rights in the
2

http://www.openss7.org/repos/tarballs/openss7-1.1.1.20110510.tar.bz2

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Preface

Software are defined in paragraph 52.227-19 of the Federal Acquisition Regulations ("FAR") (or any
successor regulations) or, in the cases of NASA, in paragraph 18.52.227-86 of the NASA Supplerment
to the FAR (or any successor regulations).

Acknowledgements
The OpenSS7 Project was funded in part by:
Monavacon Limited
OpenSS7 Corporation
Thanks to the subscribers to and sponsors of The OpenSS7 Project. Without their support, open
software like this would not be possible.
As with most open source projects, this project would not have been possible without the valiant
efforts and productive software of the Free Software Foundation, the Linux Kernel Community, and
the open source software movement at large.

2011-10-28

Call Control Interface (CCI)

Introduction

1 Introduction
This document specifies a STREAMS-based kernel-level instantiation of the ITU-T Call Control
Interface (CCI) definition. The Call Control Interface (CCI) enables the user of a call control
service to access and use any of a variety of conforming call control service providers without specific
knowledge of the providers protocol. The service interface is designed to support any network
call control protocol and user call control protocol. This interface only specifies access to call
control service providers, and does not address issues concerning call control and circuit management,
protocol performance, and performance analysis tools.
This specification assumes that the reader is familiar with ITU-T state machines and call control
interfaces (e.g., Q.764, Q.931), and STREAMS.

1.1 Related Documentation

1993 ITU-T Q.764 Recommendation
1993 ITU-T Q.931 Recommendation
System V Interface Definition, Issue 2 - Volume 3
1.1.1 Role
This document specifies an interface that supports the services provided by the Integrated Services
Digital Network (ISDN) and ISDN User Part (ISUP) for ITU-T applications as described in ITU-T
Recommendation Q.931 and ITU-T Recommendation Q.764.1 These specifications are targeted for
use by developers and testers of protocol modules that require call control service.

1.2 Definitions, Acronyms, Abbreviations

Application Context
Object Identifier
Calling Party
The Calling Party.
Called Party
The Called Party.
Operations Class
One of 5 ISO/OSI Transport Protocol Classes.

MAP

Mobile Applications Part

TCAP

Transaction Capabilities Application Part

SCCP

Service Connection Control Part

MTP

Message Transfer Part

Transaction Sub-Layer

Component Sub-Layer

In a later version of this document H.225, BSSAP, and SIP will also be supported.

2011-10-28

Chapter 1: Introduction

IMSI

International Mobile Station Identifier

MSISDN

Mobile Station ISDN Directory Number (E.164)

ITU

International Telecommunications Union

ITU-T

International Telecommunications Union Telecom Sector

OSI

Open Systems Interconnect

ISO

International Organization for Standardization

MAP User

A user of the Mobile Application Part (MAP) Interface.

MAP Provider
A provider of the Mobile Application Part (MAP) Interface.
MAPI

The Mobile Application Part (MAP) Interface.

Mobile Station.

Components
Transaction components as defined in ITU-T Recommendation Q.771.
QoS

Quality of Service

STREAMS A communication services development facility first available with UNIX System V
Release 3.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

The Call Control Layer

2 The Call Control Layer

The Call Control Layer provides the means to manage the connection and disconnection of calls.
It is responsible for the routing and management of call control signalling between call control-user
entities.

2.1 Model of the CCI

The CCI defines the services provided by the call control layer to the call control-user at the boundary
between the call control provider and the call control user entity. The interface consists of a set of
primitives defined as STREAMS messages that provide access to the call control layer services, and
are transferred between the CCS user entity and the CCS provider. These primitives are of two
types; ones that originate from the CCS user, and others that originate from the CCS provider. The
primitives that originate from the CCS user make requests to the CCS provider, or respond to an
indication of an event of the CCS provider. The primitives that originate from the CCS provider
are either confirmations of a request or are indications to the CCS user that an event has occurred.
Figure 2.1 shows the model of the CCI.

Call Control User
Request/Response
Primitives

Indication/Confirmation
Primitives
Call Control Provider

Figure 2.1: Model of the CCI

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

2.2 CCI Services

The features of the CCI are defined in terms of the services provided by the CCS provider, and the
individual primitives that may flow between the CCS user and the CCS provider.
The services supported by the CCI are based on three distinct modes of communication, usernetwork interface (UNI) User mode, user-network interface (UNI) Network mode, and networknetwork interface (NNI). In addition, the CCI supports services for local management.
2.2.1 UNI
The main features of the User-Network Interface mode of communication are:
2011-10-28

Chapter 2: The Call Control Layer

1. It is call oriented.
2. It employs facility associated signalling in that the signalling interface and circuits that are
controlled by that signalling interface are bound by physical configuration. (For example,
23B+D, 2B+D).
3. The protocol has two aspects to the interface: one side of the interface follows the User protocol
whereas the other side of the interface follows the Network protocol.
4. The user side of the protocol has no formal maintenance or monitoring procedures and therefore
reports most if not all system events to the user.
5. The network side of the protocol has formal maintenance and monitoring procedures and therefore reports most if not all system events to maintenance.
2.2.1.1 Address Formats
Addresses specifying all the calls and channels known to the provider are specified with scope ISDN_
SCOPE_DF and identifier zero (0).
Customer/Provider Group
A customer/provider group has a different interpretation on the User and Network side of the call
control interface. In User mode, the provider group is a group of all equipment groups that are
serviced by the same network provider. In Network mode, the customer group is a group of all
equipment groups to which the same service is provided to the same customer by the network.
Customer/provider groups are identifier using a unique customer/provider group identifier within
the CCS provider. Addresses specifying all of the equipment groups in a customer/provider group
and specified with scope ISDN_SCOPE_XG and the customer/provider group identifier.
Equipment Group
An equipment group is a group of all transmission groups (B- and D-channels) terminating at the
same location. For User mode this corresponds to all the B- and D-channels terminating on the
same network provider exchange. For Network mode this corresponds to all the B- and D-channels
terminating on the same customer site.
Equipment groups are identified using a unique equipment group identifier within the CCS provider.
Addresses specifying all of the B- and D-channels making up an equipment group are specified with
scope ISDN_SCOPE_EG and the equipment group identifier.
Facility Group
A facility group is a group of D-channels (data links) controlling a set of B-channels. This corresponds
to the signalling interface. For regular interfaces, a signalling relation consists of a single signalling
interface. Where multiple signalling interfaces are used to control the same range of channels (e.g.
primary and backup interfaces), all signalling interfaces belong to the same facility group.
The B-channels that make up a facility group are channels that share the same dial plan and routing
characteristics for telephone calls. A facility group is associated with an equipment group.
Facility groups are identified using a unique facility group identifier within the CCS provider. Addresses specifying all of the channels in a facility group are specified with scope ISDN_SCOPE_FG and
the facility group identifier.
An ISDN Channel Identifier is only unique within a facility group.
12

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

The Call Control Layer

Transmission Group
A transmission group is the group of all D- and B-Channels associated with a given Q.931 signalling
interface. For example, a typical PRI interface would consist of 23B+D, where there is one signalling
interface (the D-Channel) with 23 B-Channels associated with the D-Channel. The 1 D-Channel
and 23 B-Channels form a single transmission group associated with the physical interface. Every
D- or B-Channel belongs to one transmission group and occupies a single time slot within that
transmission group.
Transmission groups are identified using a unique transmission group identifier within the CCS
provider. Addresses specifying all of the channels in a transmission group are specified with scope
ISDN_SCOPE_TG and the transmission group identifier. Transmission groups can also be specified
using scope ISDN_SCOPE_FG and the Channel Identifier of one of the channels in the facility group.
Channel
A channel refers to a specific B-Channel within a transmission and facility group.
Channels are identified using a unique channel identifier within the CCS provider. Addresses specifying a specific channel are specified with scope ISDN_SCOPE_CH and the channel identifier. Channels
can also be specified using scope ISDN_SCOPE_FG, the facility group identifier, and the Channel
Identity of the channel within the facility group.
Data Link
A data link corresponds to a specific D-channel used for the control of channels. Data links can be
grouped into facility groups.
Data links are identified using a unique data link identifier within the CCS provider. Addresses
specifying all of the channels controlled by a data link are specified with scope ISDN_SCOPE_DL and
the data link identifier.

Customer/
Provider
Group

Equipment
Group

Facility
Group

Data Links

Equipment
Group

Transmission
Group

Channels

Facility
Group

Data Links

Figure 2.2: UNI Data Model

2011-10-28

Chapter 2: The Call Control Layer

2.2.2 NNI
The main features of the Network-Network Interface mode of communication are:
1. It is circuit oriented.
2. It employs quasi-associated signalling in that the path taken by signalling and the path taken
by the circuits are not necessarily related.
3. The protocol has one aspect and is peer-to-peer: that is, both sides of a signalling interface
follow the same protocol in the same way.
4. The network side of the protocol has formal maintenance and monitoring procedures and therefore reports most if not all system events to maintenance.
2.2.2.1 Address Formats
Addresses specifying all of the circuits known to the provider are specified with scope ISUP_SCOPE_DF
and identifier zero (0).
Signalling Points
A signalling point is the SS7 signalling point (central office) that the provider represents. A CCS
provider can represent more than one signalling point.
A signalling point is identifier using a unique signalling point identifier within the CCS provider.
Addresses specifying all of the circuits in signalling point are specified with scope ISUP_SCOPE_SP
and the signalling point identifier.
Signalling Relations
A signalling relation is a relationship between a local signalling point and a remote signalling point.
A signalling relation consists of a single signalling interface.
Signalling relations are identified using a unique signalling relation identifier within the CCS provider.
Addresses specifying all of the circuits in a signalling relation are specified with scope ISUP_SCOPE_SR
and the signalling relation identifier.
An ISUP Circuit Identification Code is only unique within a signalling relation.
Trunk Groups
A trunk group is a group of circuits that share the same routing characteristics for telephone calls.
A trunk group is associated with a signalling relation. For the NNI, a signalling relation is the
combination of local MTP Point Code and remote MTP Point Code.
A trunk group is identified using a unique trunk group identifier within the CCS provider. Addresses
specifying all of the circuits in a trunk group are specified with scope ISUP_SCOPE_TG and the trunk
group identifier.
Circuit Groups
A circuit group is a group of circuits that share the same common transmission facility (e.g, E1 span)
and is therefore impacted by any failure of the transmission facility. All of the individual channels
of an E1 span that are used to carry calls are members of the circuit group.
Circuits groups are identified using a unique circuit group identifier within the CCS provider. Addresses specifying all of the circuits within a circuit group are specified with scope ISUP_SCOPE_CG
14

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

The Call Control Layer

and the circuit group identifier. Circuit groups can also be specified using scope ISUP_SCOPE_SR
and the Circuit Identification Code of one of the circuits within the circuit group.
Circuits
A circuit refers to a specific time slot within a digital facility.
Circuits are identified using a unique circuit identifier within the CCS provider. Addresses specifying
a specific circuit are specified with scope ISUP_SCOPE_CT and the circuit identifier. Circuits can also
be specified using scope ISUP_SCOPE_CG, the circuit group identifier, and the Circuit Identification
Code of the circuit within the group. Circuits can also be specified using scope ISUP_SCOPE_SR, the
signalling relation identifier, and the Circuit Identification Code of the circuit within the signalling
relation.

Signalling
Point
Message
Transfer
Part

Message
Transfer
Part
Signalling
Relation

Cicuit
Group

Trunk
Group

Circuits

Signalling
Relation

Trunk
Group

Circuit
Group

Circuits

Figure 2.3: NNI Data Model

2.2.3 Local Management

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

2011-10-28

Call Control Interface (CCI)

CCI Services Definition

3 CCI Services Definition

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

Both

Call Setup

Both

Call Establishment

UNI
NNI
Both

Call Established

Both

UNI
Call Termination

Both

Provider Management

UNI
UNI
NNI

CC_INFO_REQ, CC_INFO_ACK, CC_BIND_REQ, CC_BIND_ACK,

CC_UNBIND_REQ, CC_ADDR_REQ, CC_ADDR_ACK, CC_OPTMGMT_REQ, CC_OPTMGMT_ACK, CC_OK_ACK, CC_ERROR_ACK
CC_SETUP_REQ, CC_SETUP_IND, CC_CALL_REATTEMPT_IND,
CC_MORE_INFO_REQ, CC_MORE_INFO_IND, CC_INFORMATION_REQ, CC_INFORMATION_IND, CC_SETUP_RES, CC_SETUP_CON
CC_INFO_TIMEOUT_IND
CC_CONT_REPORT_REQ, CC_CONT_REPORT_IND
CC_PROCEEDING_REQ, CC_PROCEEDING_IND, CC_ALERTING_REQ, CC_ALERTING_IND, CC_PROGRESS_REQ,
CC_PROGRESS_IND, CC_CONNECT_REQ, CC_CONNECT_IND
CC_SUSPEND_REQ, CC_SUSPEND_RES, CC_SUSPEND_IND,
CC_SUSPEND_CON, CC_RESUME_REQ, CC_RESUME_RES,
CC_RESUME_IND, CC_RESUME_CON
CC_SUSPEND_REJECT_REQ,
CC_SUSPEND_REJECT_IND,
CC_RESUME_REJECT_REQ, CC_RESUME_REJECT_IND
CC_CALL_FAILURE_IND, CC_IBI_REQ, CC_IBI_IND,
CC_RELEASE_REQ, CC_RELEASE_IND, CC_RELEASE_RES,
CC_RELEASE_CON
CC_DISCONNECT_REQ, CC_DISCONNECT_IND
CC_RESTART_REQ, CC_RESTART_CON
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
CC_CONT_CHECK_REQ, CC_CONT_CHECK_IND,
CC_CONT_TEST_REQ, CC_CONT_TEST_IND,
CC_CONT_REPORT_REQ, CC_CONT_REPORT_IND

Table 3.1: CCI Service Primitives

2011-10-28

Chapter 3: CCI Services Definition

3.1 Local Management Services Definition

The services defined in this section are outside the scope of international standards. These services apply to UNI (User and Network), and NNI modes of communication. They are invoked for
the initialization/de-initialization of a stream connected to the CCS provider. They are also used
to manage options supported by the CCS provider and to report information on the supported
parameter values.
3.1.1 Call Control Information Reporting Service
This service provides information on the options supported by the CCS provider.
CC_INFO_REQ: This primitive request that the CCS provider return the values of all the supported protocol parameters. This request may be invoked during any phase.
CC_INFO_ACK: This primitive is in response to the N INFO REQ primitive and returns the
values of the supported protocol parameters to the CCS user.
The sequence of primitive for call control information management is shown in Figure 3.1.

CC_INFO_REQ

CC_INFO_ACK

Figure 3.1: Sequence of Primitives: Call Control Information Reporting Service

3.1.2 CCS Address Service

This service allows a CCS user to determine the bound call control address and the connected call
control address for a given call reference associated with a stream. It permits the CCS user to not
necessarily retain this information locally, and allows the CCS user to determine this information
from the CCS provider at any time.
CC_ADDR_REQ: This primitive requests that the CCS provider return information concerning
which call control address the CCS user is bound as well as the call control address upon which
the CCS user is currently engaged in a call for the specified call reference.
CC_ADDR_ACK: This primitive is in response to the CC_ADDR_REQ primitive and indicates to the
CCS user the requested information.
The sequence of primitives is shown in Figure 3.2.
18

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_ADDR_REQ

CC_ADDR_ACK

Figure 3.2: Sequence of Primitives: Call Control User Address Service

3.1.3 CCS User Bind Service

This service allows a call control address to be associated with a stream. It allows the CCS user
to negotiate the number of setup indications that can remain unacknowledged for that CCS user (a
setup indication is considered unacknowledged while it is awaiting a corresponding setup response
or release request from the CCS user). This service also defines a mechanism that allows a stream
(bound to a call control address of the CCS user) to be reserved to handle incoming calls only. This
stream is referred to as the listener stream.
CC_BIND_REQ: This primitive request that the CCS user be bound to a particular call control
address and negotiate the number of allowable outstanding setup indications for that address.
CC_BIND_ACK: This primitive is in response to the CC_BIND_REQ primitive and indicates to the
user that the specified CCS user has been bound to a call control address.
The sequence of primitives is shown in Figure 3.3 .

CC_BIND_REQ

CC_BIND_ACK

Figure 3.3: Sequence of Primitives: Call Control User Bind Service

3.1.4 CCS User Unbind Service

This service allows the CCS user to be unbound from a call control address.
CC_UNBIND_REQ: This primitive request that the CCS user be unbound from the call control
address that it had previously been bound to.
The sequence of primitives is shown in Figure 3.4.
2011-10-28

Chapter 3: CCI Services Definition

CC_UNBIND_REQ

CC_OK_ACK

Figure 3.4: Sequence of Primitives: Call Control User Unbind Service

3.1.5 Receipt Acknowledgement Service

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

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

CC_OK_ACK

*
CC_SETUP_REQ
CC_SETUP_RES
CC_ALERTING_REQ
CC_PROCEEDING_REQ
CC_PROGRESS_REQ
CC_CONT_REPORT_REQ
CC_SETUP_COMPLETE_REQ
CC_RELEASE_REQ
CC_RELEASE_IND
CC_SUSPEND_REQ
CC_RESUME_REQ

Figure 3.5: Sequence of Primitives: Call Control Receipt Acknowledgement Service

3.1.6 Options Management Service

This service allows the CCS user to manage options parameter values associated with the CCS
provider.
CC_OPTMGMT_REQ: This primitive allows the CCS user to select default values for options parameters within the range supported by the CCS provider.

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

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_OPTMGMT_REQ

CC_OK_ACK

Figure 3.6: Sequence of Primitives: Call Control Options Management Service

3.1.7 Error Acknowledgement Service

CC_ERROR_ACK: This primitive indicates to the CCS user that a non-fatal error has occurred in
the last CCS user originated request or response primitive (listed in Figure 3.7), on the stream.
Figure 3.7 shows the sequence or primitives for the error management primitive.

REQ/RES Primitive *

CC_ERROR_ACK

*
CC_SETUP_REQ
CC_SETUP_RES
CC_PROCEEDING_REQ
CC_ALERTING_REQ
CC_PROGRESS_REQ
CC_CONT_REPORT_REQ
CC_MORE_INFO_REQ
CC_SETUP_COMPLETE_REQ
CC_SUSPEND_REQ
CC_RESUME_REQ
CC_RELEASE_REQ
CC_RELEASE_RES

Figure 3.7: Sequence of Primitives: Call Control Error Acknowledgement Service

2011-10-28

Chapter 3: CCI Services Definition

3.2 User-Network Interface Services Definition

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

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

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

A queue is empty until a setup object has been entered and can be returned to this state, with
loss of its contents, by the CCS provider.

Objects may be entered into a queue as a result of the action of the source CCS user, subject
to control by the CCS provider.

Objects may also be entered into a queue by the CCS provider.

Objects are removed from the queue under the control of the receiving CCS user.

Objects are normally removed under the control of the CCS user in the same order as they
were entered except:

if the object is of a type defined to be able to advance ahead of the preceding object, or

if the following object is defined to be destructive with respect to the preceding object on
the queue. If necessary, the last object on the queue will be deleted to allow a destructive
object to be entered \- they will therefore always be added to the queue. For example,
"release" objects are defined to be destructive with respect to all other objects.

Table B.1 shows the ordering relationship among the queue model objects.
22

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_SETUP_REQ
SETUP

CC_SETUP_IND
CC_MORE_INFO_REQ
SETUP ACKNOWLEDGE

CC_MORE_INFO_IND
CC_INFORMATION_REQ
CC_INFORMATION_REQ

CC_OK_ACK
INFORMATION
INFORMATION

CC_OK_ACK
CC_OK_ACK

CC_INFORMATION_IND
CALL PROCEEDING
ALERTING
PROGRESS
CONNECT

CC_SETUP_CON

CC_INFORMATION_IND
CC_SETUP_RES

CC_OK_ACK
CC_PROCEEDING_REQ
CALL PROCEEDING

CC_PROCEEDING_IND

CC_OK_ACK
CC_ALERTING_REQ
ALERTING

CC_ALERTING_IND

CC_OK_ACK
CC_PROGRESS_REQ
PROGRESS

CC_PROGRESS_IND

CC_OK_ACK
CC_CONNECT_REQ
CONNECT

CC_CONNECT_IND
CC_SETUP_COMPLETE_REQ
(Network Side Only)

CC_OK_ACK
CONNECT ACKNOWLEDGE

CC_OK_ACK

CC_SETUP_COMPLETE_IND
(User Side Only)

Figure 3.8: Sequence of Primitives: Call Control UNI Overview

3.2.1 Call Setup Phase

A pair of queues is associated with a call between two call control addresses (facility group and
channel(s)) when the CCS provider receives a CC_SETUP_REQ primitive at one of the call control
addresses resulting in a setup object being entered into the queue. The queues will remain associated
with the call until a CC_RELEASE_REQ or CC_RELEASE_IND (resulting in a release object) is either
entered into or removed from a queue. Similarly, in the queue from the called CCS user, objects can
be entered into the queue only after the setup object associated with the CC_SETUP_RES has been
entered into the queue. Alternatively, the called CCS user can enter a release object into the queue
instead of the setup object to terminate the call.
The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the
destination CCS user is unable to accept the CC_SETUP_IND (see call failure and call reject primitive
definitions).
3.2.1.1 User Primitives for Successful Call Setup
2011-10-28

Chapter 3: CCI Services Definition

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

3.2.1.2 Provider Primitives for Successful Call Setup

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

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_SETUP_REQ
SETUP

CC_SETUP_IND
CC_MORE_INFO_REQ
SETUP ACKNOWLEDGE

CC_MORE_INFO_IND
CC_INFORMATION_REQ
CC_INFORMATION_REQ

INFORMATION
INFORMATION

T302

CC_INFORMATION_IND
CC_INFORMATION_IND
CC_INFO_TIMEOUT_IND
CC_SETUP_RES

CONNECT

CC_SETUP_CON
CC_SETUP_COMPLETE_REQ

CC_OK_ACK
CONNECT ACKNOWLEDGE

CC_OK_ACK

CC_SETUP_COMPLETE_IND

Figure 3.9: Sequence of Primitives: Call Control Call Setup Service

CC_BIND_REQ
(swith TOKEN_REQUEST set)

CC_BIND_ACK
(returns cc_token_value)

Figure 3.10: Sequence of Primitives: Call Control Token Request Service

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

CC_SETUP_REQ

CC_REATTEMPT_IND

Figure 3.11: Sequence of Primitives: Call Reattempt - CCS Provider

The sequence of primitives for call reattempt on dual seizure are shown in Figure 3.12.
2011-10-28

Chapter 3: CCI Services Definition

CC_SETUP_REQ

CC_SETUP_REQ
SETUP

CC_SETUP_IND

SETUP

CC_SETUP_IND
CC_SETUP_RES

CC_REATTEMPT_IND
CONNECT

CC_SETUP_CON

CC_OK_ACK

Figure 3.12: Sequence of Primitives: Call Reattempt - Dual Seizure

3.2.2 Call Establishment Phase

During the call establishment phase, a pair of queues has already been associated with the call
between the selected call control addresses (facility group and channel(s)) during the setup phase.
3.2.2.1 User Primitives for Successful Call Establishment
CC_PROCEEDING_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the call is proceeding and that all necessary information has been received.
CC_ALERTING_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the terminating user is being alerted.
CC_PROGRESS_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the specified progress event has occurred.
CC_IBI_REQ (CC_DISCONNECT_REQ): This primitive requests that the CCS provider indicate to
the call control peer that in-band information is now available. This will also invite the peer
to release the call.
CC_CONNECT_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the call has been connected.
CC_SETUP_COMPLETE_REQ: This primitive request that the CCS provider complete the call
setup.
3.2.2.2 Provider Primitives for Successful Call Establishment
CC_PROCEEDING_IND: This primitive indicates to the CCS user that the call control peer is
proceeding and that all necessary information has been received.
CC_ALERTING_IND: This primitive indicates to the CCS user that the terminating user is being
alerted.
CC_PROGRESS_IND: This primitive indicates to the CCS user that the specified progress event
has occurred.
CC_IBI_IND (CC_DISCONNECT_IND): This primitive indicates to the CCS user that in-band
information is now available. It also invites the CCS user to release the call.
CC_CONNECT_IND: This primitive indicates to the CCS user that the call has been connected.
26

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_SETUP_COMPLETE_IND: This primitive indicates to the CCS user that the call has completed
setup.
3.2.2.3 Provider Primitives for Successful Call Setup
The sequence of primitives in a successful call establishment is defined by the time sequence diagrams
as shown in Figure 3.13.

CC_PROCEEDING_REQ
CALL PROCEEDING

CC_PROCEEDING_IND

CC_OK_ACK
CC_ALERTING_REQ
ALERTING

CC_ALERTING_IND

CC_OK_ACK
CC_PROGRESS_REQ
PROGRESS

CC_PROGRESS_IND

CC_OK_ACK
CC_IBI_REQ
DISCONNECT

CC_IBI_IND

CC_OK_ACK
CC_CONNECT_REQ
CONNECT

CC_CONNECT_IND
CC_SETUP_COMPLETE_REQ
(Network Side Only)

CC_OK_ACK
CONNECT ACKNOWLEDGE

CC_OK_ACK

CC_SETUP_COMPLETE_IND
(User Side Only)

Figure 3.13: Sequence of Primitives: Call Control Successful Call Establishment Service

3.2.3 Call Established Phase

Flow control of the call is done by management of the queue capacity, and by allowing objects of
certain types to be inserted to the queues, as shown in Table X.
3.2.3.1 Suspend Service
User Primitives for Suspend Service
CC_SUSPEND_REQ: This primitives requests that the CCS provider temporarily suspend a call
at the network, or indicate user suspension of a call.
CC_SUSPEND_RES: This primitive indicates to the CCS provider that the CCS user (Network)
is accepting the request for suspension of the call.
CC_SUSPEND_REJECT_REQ: This primitive indicates to the CCS provider that the CCS user
(Network) is rejecting the request for suspension of the call, and the cause for rejection.
Provider Primitives for Suspend Service

2011-10-28

Chapter 3: CCI Services Definition

CC_SUSPEND_IND: This primitive indicates to the CCS user that an established call has been
temporarily suspended at the network, or by the remote user.
CC_SUSPEND_CON: This primitive confirms to the requesting CCS user (User) that the call has
been temporarily suspended at the network.
CC_SUSPEND_REJECT_IND: This primitive indicates to the requesting CCS user (User) that the
request to suspend the call has been rejected by the network, and the cause for rejection.
Figure 3.14 and Figure 3.15 show the sequence of primitives for suspend service. The sequence of
primitives may remain incomplete if a CC_RESET or a CC_RELEASE primitive occurs.
The sequence of primitives to suspend a call is defined in the time sequence diagram as shown in
Figure 3.14 and Figure 3.15.

CC_SUSPEND_REQ
SUSPEND

CC_SUSPEND_IND

CC_SUSPEND_RES
SUSPEND ACKNOWLEDGE

CC_SUSPEND_CON

CC_OK_ACK

Figure 3.14: Sequence of Primitives: Call Control Network Suspend Service: Successful

CC_SUSPEND_REQ
SUSPEND

CC_SUSPEND_IND

CC_SUSPEND_REJECT_REQ
SUSPEND REJECT

CC_SUSPEND_REJECT_IND

CC_OK_ACK

Figure 3.15: Sequence of Primitives: Call Control Network Suspend Service: Unsuccessful

CC_SUSPEND_REQ
NOTIFY

CC_SUSPEND_CON

CC_SUSPEND_IND
CC_SUSPEND_RES

Figure 3.16: Sequence of Primitives: Call Control User Suspend Service

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

3.2.3.2 Resume Service

User Primitives for Resume Service

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

Provider Primitives for Resume Service

CC_RESUME_IND: This primitive indicates to the CCS user that a previously suspended call has
been resumed at the network, or by the remote user.
CC_RESUME_CON: This primitive confirms to the requesting CCS user (User) that the call has
been resumed at the network.
CC_RESUME_REJECT_IND: This primitive indicates to the requesting CCS user (User) that the
request to resume the call has been rejected by the network, and the cause for rejection.
Figure 3.17 and Figure 3.18 show the sequence of primitives for resume service. The sequence of
primitives may remain incomplete if a CC_RESET or a CC_RELEASE primitive occurs.
The sequence of primitives to resume a call is defined in the time sequence diagram as shown in
Figure 3.17 and Figure 3.18.

CC_RESUME_REQ
RESUME

CC_RESUME_IND

CC_RESUME_RES
RESUME ACKNOWLEDGE

CC_RESUME_CON

CC_OK_ACK

Figure 3.17: Sequence of Primitives: Call Control Resume Service: Successful

2011-10-28

Chapter 3: CCI Services Definition

CC_RESUME_REQ
RESUME

CC_RESUME_IND

CC_RESUME_REJECT_REQ
RESUME REJECT

CC_RESUME_REJECT_IND

CC_OK_ACK

Figure 3.18: Sequence of Primitives: Call Control Resume Service: Unsuccessful

CC_RESUME_REQ
NOTIFY

CC_RESUME_CON

CC_RESUME_IND
CC_RESUME_RES

Figure 3.19: Sequence of Primitives: Call Control User Resume Service

3.2.4 Call Termination Phase

3.2.4.1 Call Reject Service
User Primitives for Call Reject Service
CC_REJECT_REQ: This primitive indicates that the CCS user receiving the specified CC_SETUP_
IND requests that the specified call indication be rejected.

Provider Primitives for Call Reject Service

CC_REJECT_IND: This primitive indicates to the calling CCS user that the call has been rejected.
The sequence of events for rejecting a call setup attempt at the UNI is defined in the time sequence
diagram shown in Figure 3.20.
30

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_SETUP_REQ
SETUP

CC_SETUP_IND

CC_REJECT_REQ
RELEASE COMPLETE

CC_REJECT_IND

CC_OK_ACK

Figure 3.20: Sequence of Primitives: Rejecting a Call Setup

3.2.4.2 Call Failure Service

Provider Primitives for Call Failure Service
CC_CALL_FAILURE_IND: This primitive indicates to the called CCS user that an event has
caused the call to fail and indicates the reason for the failure and the cause value associated
with the failure. The CCS user is required to release the call using the indicated cause value
in a CC_DISCONNECT_REQ primitive.
The sequence of events for error indications is described in the time sequence diagram shown in
Figure 3.21.

RESTART
STATUS
DL_ESTABLISH_CON

CC_CALL_FAILURE_IND
CC_DISCONNECT_REQ
DISCONNECT

CC_DISCONNECT_IND

Figure 3.21: Sequence of Primitives: Call Failure

3.2.4.3 Call Release Service

The call release procedure is initialized by the insertion of a release object (associated with a CC_
DISCONNECT_REQ, CC_RELEASE_REQ, or CC_REJECT_REQ) in the queue. As shown in Table 3, the
release procedure is destructive with respect to other objects in the queue, and eventually results in
the emptying of queues and termination of the call.
The Release procedure invokes the following interactions:
A. A CC_DISCONNECT_REQ from the CCS user, followed by a CC_RELEASE_IND from the CCS
provider and a subsequent CC_RELEASE_RES from the CCS user; or
B. A CC_DISCONNECT_IND from the CCS provider, followed by a CC_RELEASE_REQ from the CCS
user and a subsequent CC_RELEASE_CON from the CCS provider.
2011-10-28

Chapter 3: CCI Services Definition

The sequence of primitive depends on the origin of the release action. The sequence may be:
1. invoked by the CCS user, with a request from that CCS user, leading to interaction (A) with
that CCS user and interaction (B) with the peer CCS user;
2. invoked by both CCS users, with a request from each of the CCS users, leading to interaction
(A) with both CCS users;
3. invoked by the CCS provider, leading to interaction (B) with both CCS users.
4. invoked independently by one CCS user and the CCS provider, leading to interaction (A) with
the originating CCS user and (B) with the peer CCS user.

User Primitives for Release Service

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

Provider Primitives for Release Service

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

The sequence of primitives as shown in Figure 3.22, Figure 3.23, Figure 3.24, and Figure 3.25 may
remain incomplete if a CC_RESTART primitive occurs.
A CCS user can release a call establishment attempt by issuing a CC_DISCONNECT_REQ. The sequence
of events is shown in Figure 3.22, Figure 3.23, Figure 3.24, and Figure 3.25.
32

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_DISCONNECT_REQ
DISCONNECT

CC_DISCONNECT_IND
CC_RELEASE_REQ
RELEASE

CC_RELEASE_IND
CC_RELEASE_RES
RELEASE COMPLETE

CC_OK_ACK

CC_RELEASE_CON

Figure 3.22: Sequence of Primitives: CCS User Invoked Release

CC_DISCONNECT_REQ

CC_DISCONNECT_REQ
DISCONNECT

RELEASE

CC_RELEASE_CON

Figure 3.23: Sequence of Primitives: Simultaneous CCS User Invoked Release

DISCONNECT

CC_DISCONNECT_IND
CC_RELEASE_REQ

RELEASE

CC_RELEASE_CON

Figure 3.24: Sequence of Primitives: CCS Provider Invoked Release

2011-10-28

Chapter 3: CCI Services Definition

CC_DISCONNECT_REQ
DISCONNECT

CC_DISCONNECT_IND
CC_RELEASE_REQ

RELEASE

CC_RELEASE_CON

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

3.2.5 Call Management

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

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

3.3 Network-Network Interface Services Definition

This section describes the required call control service primitives that define the NNI interface.
The queue model for NNI is discussed in more detail in ITU-T Q.764. For Q.764 specific conformance
considerations, see [Addendum for Q.764 Conformance], page 225. For ETSI EN 300 356-1 V3.2.2
specific conformance considerations, see [Addendum for ETSI EN 300 356-1 V3.2.2 Conformance],
page 271.

CC_SETUP_REQ
IAM

CC_MORE_INFO_IND

CC_SETUP_IND
CC_MORE_INFO_REQ

CC_INFORMATION_REQ
CC_INFORMATION_REQ

SAM
SAM

CC_OK_ACK
CC_OK_ACK
ACM
CPG
CON

CC_SETUP_CON

CC_INFORMATION_IND
CC_INFORMATION_IND
CC_SETUP_RES

CC_OK_ACK
CC_PROCEEDING_REQ
ACM

CC_PROCEEDING_IND

CC_OK_ACK
CC_ALERTING_REQ
ACM/CPG

CC_ALERTING_IND

CC_OK_ACK
CC_PROGRESS_REQ
ACM/CPG

CC_PROGRESS_IND

CC_OK_ACK
CC_IBI_REQ
ACM/CPG

CC_IBI_IND

CC_OK_ACK
CC_CONNECT_REQ
CON/ANM

CC_CONNECT_IND

CC_OK_ACK

Figure 3.26: Sequence of Primitives: Call Control NNI Overview

3.3.1 Call Setup Phase

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

2011-10-28

Chapter 3: CCI Services Definition

The call establishment procedure will fail if the CCS provider is unable to establish the call, or if the
destination CCS user is unable to accept the CC_SETUP_IND (see call release primitive definition).
3.3.1.1 User Primitives for Successful Call Setup
CC_SETUP_REQ: This primitive requests that the CCS provider setup a call to the specified
destination (called party address).
CC_MORE_INFO_REQ: This primitive requests that the CCS provider provide more information
to establish the call. This primitive is not issued for en block signalling mode.
CC_INFORMATION_REQ: This primitive requests that the CCS provider provide more information
(digits) in addition to the destination (called party number) already specified in the CC_SETUP_
REQ and subsequent CC_INFORMATION_REQ primitives. This primitive is not issued for en block
signalling mode.
CC_SETUP_RES: This primitive requests that the CCS provider accept a previous call setup
indication on the specified stream.
3.3.1.2 Provider Primitives for Successful Call Setup
CC_CALL_REATTEMPT_IND: This primitive indicates to the calling CCS user that an event has
caused call setup to fail on the selected address and that a reattempt should be made (or has
been made) on another call control address (signalling interface and circuit(s)). This primitive
is only issued by the CCS provider if the CCS user is bound at the circuit level rather than the
circuit group or trunk group level.
CC_SETUP_IND: This primitive indicates to the CCS user that a call setup request has been
made by a user at the specified call control address (circuit(s)).
CC_MORE_INFO_IND: This primitive indicates to the CCS user that more information is required
to establish the call. This primitive is not issued for en block signalling mode.
CC_INFORMATION_IND: This primitive indicates to the CCS user more information (digits) in
addition to the destination (called party number) already indicated in the CC_SETUP_IND and
subsequent CC_INFORMATION_IND primitives. This primitive is not issued for en block signalling
mode.
CC_INFO_TIMEOUT_IND: This primitive indicates to the called CCS user that a timeout occurred
while waiting for additional information (called party number). The receiving CCS User should
determine whether sufficient address digits have been received and either disconnect the call
with the CC_DISCONNECT_REQ primitive or continue the call with CC_SETUP_RES.
CC_SETUP_CON: This primitive indicates to the CCS user that a call setup request has been
confirmed on the indicated call control address (circuits(s)).
The sequence of primitives in a successful call setup is defined by the time sequence diagrams as
shown in hundefinedi [hundefinedi], page hundefinedi and Figure 3.27.
The sequence of primitives for the call response token value determination is shown in Figure 3.28
(procedures for call response token value determination are discussed in section 4.1.3 and 4.1.4.)
36

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_SETUP_REQ
IAM

CC_SETUP_IND
CC_MORE_INFO_REQ
(no message)

CC_MORE_INFO_IND
CC_INFORMATION_REQ
CC_INFORMATION_REQ

SAM
SAM

CC_OK_ACK
CC_OK_ACK

T11

CC_INFORMATION_IND
CC_INFORMATION_IND
CC_INFO_TIMEOUT_IND
CC_SETUP_RES

CON

CC_SETUP_CON
CC_SETUP_COMPLETE_REQ

CC_OK_ACK
(no message)

CC_OK_ACK

CC_SETUP_COMPLETE_IND

Figure 3.27: Sequence of Primitives: Call Control Call Setup Service: Overlap Sending

CC_BIND_REQ
(swith TOKEN_REQUEST set)

CC_BIND_ACK
(returns cc_token_value)

Figure 3.28: Sequence of Primitives: Call Control Token Request Service

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

CC_SETUP_REQ

CC_REATTEMPT_IND

Figure 3.29: Sequence of Primitives: Call Reattempt - CCS Provider

The sequence of primitives for call reattempt on dual seizure are shown in Figure 3.30.
2011-10-28

Chapter 3: CCI Services Definition

CC_SETUP_REQ

CC_SETUP_REQ
IAN

CC_SETUP_IND

IAM

CC_SETUP_IND
CC_SETUP_RES

CC_REATTEMPT_IND
CON

CC_SETUP_CON

CC_OK_ACK

Figure 3.30: Sequence of Primitives: Call Reattempt - Dual Seizure

3.3.2 Continuity Test Phase

The continuity test service is only applicable to the NNI.
During the continuity test phase, a pair of queues has already been associated with the call between the selected call control addresses (signalling interface and circuit(s)) during the setup phase.
The continuity test phase begins when the CCS provider returns a CC_CONT_TEST_IND primitive
in response to a CC_SETUP_REQ primitive that had the ISUP_NCI_CONT_CHECK_REQUIRED flag set in
the call flags. The continuity test phase also begins when the CCS user responds with a CC_CONT_
TEST_REQ primitive in response to a CC_SETUP_IND primitive that had the ISUP_NCI_CONT_CHECK_
REQUIRED flag set in the call flags.
Upon entering the continuity test phase, it is the responsibility of the CCS user to establish a loop
back on the call control address (signalling interface and circuit(s)) or to attach tone generation and
detection devices to the call control address (signalling interface and circuit(s)).
3.3.2.1 Continuity Test Successful
User Primitives for Successful Continuity Test
CC_SETUP_REQ: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, requests
that the CCS provider setup a call and include a continuity check before the call is established.
CC_CONT_CHECK_REQ: This primitive requests that the CCS provider perform a continuity check
on the specified call control address (signalling interface and circuit(s)). This primitive is only
necessary for performing continuity checks that are not in conjunction with a call.
CC_CONT_TEST_REQ: This primitive requests that the CCS provider accept an outstanding call
setup indication. When the CC_SETUP_IND had the ISUP_NCI_CONT_CHECK_REQUIRED flag set,
it indicates to the CCS provider that the necessary loop back device has been install on the
call control address (signalling interface and circuit(s)).
CC_CONT_REPORT_REQ: This primitive requests that the CCS provider indicate to the remote
CCS user that the continuity test has succeeded (cc result is set to ISUP_COT_SUCCESS).
Provider Primitives for Successful Continuity Test
CC_SETUP_IND: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, indicates
to the CCS user that a call setup including a continuity check is requested.
38

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

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

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

CC_SETUP_REQ
(with ISUP_NCI_CONT_CHECK_REQUIRED)

IAM

CC_INFORMATION_REQ
CC_INFORMATION_REQ

CC_SETUP_IND
SAM
SAM

CC_OK_ACK
CC_OK_ACK
CC_CONT_TEST_IND
(apply tone and check continuity)

LPA
(depending on protocol, the
CC_CONT_TEST_IND might be
returned from the local
CCS provider)

(with ISUP_NCI_CONT_CHECK_REQUIRED)
(establish loopback)

CC_CONT_TEST_REQ
CC_INFORMATION_IND
CC_INFORMATION_IND

CC_CONT_REPORT_REQ
(success)

COT

CC_OK_ACK

CC_CONT_REPORT_IND
(remove loopback)

CC_SETUP_RES
LPA

CC_SETUP_CON

Figure 3.31: 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 3.32.
2011-10-28

Chapter 3: CCI Services Definition

CC_SETUP_REQ
(with ISUP_NCI_CONT_CHECK_PREVIOUS)

CC_INFORMATION_REQ
CC_INFORMATION_REQ

IAM

CC_SETUP_IND
SAM

(with ISUP_NCI_CONT_CHECK_PREVIOUS)

SAM

CC_OK_ACK
CC_OK_ACK
CC_CONT_REPORT_REQ

CC_INFORMATION_IND
CC_INFORMATION_IND

(success)

COT

CC_CONT_REPORT_IND

CC_OK_ACK

CC_SETUP_RES
CON

CC_SETUP_CON

Figure 3.32: 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 3.33.

CC_CONT_CHECK_REQ
CCR

CC_CONT_CHECK_IND
(establish loopback)

CC_CONT_TEST_REQ
LPA

CC_CONT_TEST_IND
(apply tone and check continuity)

(depending on protocol, the

CC_CONT_CHECK_CON might be
returned from the local
CCS provider)

CC_RELEASE_REQ
(success)

REL

CC_RELEASE_IND
(remove loopback)

CC_RELEASE_RES
RLC

CC_RELEASE_CON

Figure 3.33: Sequence of Primitives: Continuity Test Service: Successful

3.3.2.2 Continuity Test Unsuccessful

User Primitives for Unsuccessful Continuity Test
CC_SETUP_REQ: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, requests
that the CCS provider setup a call and include a continuity check before the call is established.
CC_CONT_TEST_REQ: This primitive requests that the CCS provider accept an outstanding call
setup indication. When the CC_SETUP_IND had the ISUP_NCI_CONT_CHECK_REQUIRED flag set,
40

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

it also indicates to the CCS provider that the necessary loop back device has been install on
the call control address (signalling interface and circuit(s)).
CC_CONT_REPORT_REQ: This primitive requests that the CCS provider indicate to the remote
CCS user that the continuity test has failed (cc result is set to ISUP_COT_FAILURE).
Provider Primitives for Unsuccessful Continuity Test
CC_SETUP_IND: This primitive, with the ISUP_NCI_CONT_CHECK_REQUIRED flag set, indicates
to the CCS user that a call setup including a continuity check is requested.
CC_CONT_TEST_IND: This primitive indicates that the remote CCS user has accepted a call
setup indication on the specified call control address (signalling interface and circuit(s)). When
the CC_SETUP_IND primitive had the ISUP_NCI_CONT_CHECK_REQUIRED flag set, it indicates to
the CCS user that the necessary loop back device hass been installed on the remote end of the
call control address (signalling interface and circuit(s)). The CCS user receiving this primitive
must attach the necessary tone generation and detection devices to the circuit(s) and perform
the continuity test.
CC_CONT_REPORT_IND: This primitive indicates to the CCS user that the continuity test failed.
CC_CALL_REATTEMPT_IND: This primitive indicates to the calling CCS user that the continuity
test failed and that a reattempt should be made (or has been made) on another call control
address (signalling interface and circuit(s)). This primitive is only issued by the CCS provider
if the CCS user is bound at the circuit level rather than the circuit group or trunk group level.
The sequence of primitives for an unsuccessful continuity test associated with a call setup is defined
by the time sequence diagrams as shown in Figure 3.34.

CC_SETUP_REQ
(with ISUP_NCI_CONT_CHECK_REQUIRED)

IAM

CC_SETUP_IND
(with ISUP_NCI_CONT_CHECK_REQUIRED)
(establish loopback)

CC_CONT_TEST_REQ
LPA

CC_CONT_TEST_IND
(apply tone and check continuity)

CC_CONT_REPORT_REQ
(failure)

(depending on protocol, the

CC_CONT_TEST_IND might be
returned from the local
CCS provider)
COT

CC_OK_ACK

CC_CONT_REPORT_IND
(failure)

CC_CALL_REATTEMPT_IND
CC_SETUP_REQ
(with ISUP_NCI_CONT_CHECK_REQUIRED)

IAM

CC_SETUP_IND
(on a different circuit)

Figure 3.34: 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 3.35.
2011-10-28

Chapter 3: CCI Services Definition

CC_CONT_CHECK_REQ
CCR

CC_CONT_CHECK_IND
(establish loopback)

CC_CONT_TEST_REQ
LPA

CC_CONT_TEST_IND
(apply tone and check continuity)

(depending on protocol, the

CC_CONT_CHECK_CON might be
returned from the local
CCS provider)

CC_CONT_REPORT_REQ
(failure)

COT
(failure)

CC_OK_ACK

CC_CONT_REPORT_IND
(remove loopback)

Figure 3.35: Sequence of Primitives: Continuity Test Service: Unsuccessful

3.3.3 Call Establishment Phase

During the call establishment phase, a pair of queues has already been associated with the call
between the selected call control addresses (signalling interface and circuit(s)) during the setup phase.
The call establishment phase begins when the CCS provider returns a CC_SETUP_CON primitive (or
receives a CC_CONT_REPORT_REQ primitive) in response to a CC_SETUP_REQ primitive (that had the
ISUP NCI CONT CHECK REQUIRED flag set). The call establishment phase also begins when
the CCS user responds with a CC_SETUP_RES primitive (or receives a CC_CONT_REPORT_IND primitive)
in response to a CC_SETUP_IND primitive (that had the ISUP_NCI_CONT_CHECK_REQUIRED flag set).
Upon entering the call establishment phase, it is the responsibility of the CCS user to remove
any loop back from the call control address (signalling interface and circuit(s)) or to remove tone
generation and detection devices from the call control address (signalling interface and circuit(s)).
3.3.3.1 User Primitives for Successful Call Establishment
CC_PROCEEDING_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the call is proceeding.
CC_ALERTING_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the terminating user is being alerted.
CC_PROGRESS_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the specified progress event has occurred.
CC_IBI_REQ: This primitive requests that the CCS provider indicate to the call control peer
that interworking has been encountered and in-band information is now available. This will
also inform the peer CCS user that no connect indication is pending.
CC_CONNECT_REQ: This primitive requests that the CCS provider indicate to the call control
peer that the call has been connected.
CC_SETUP_COMPLETE_REQ: This primitive requests that the CCS provider complete the call
setup. This primitive is used in NNI mode for interworking with UNI mode.
3.3.3.2 Provider Primitives for Successful Call Establishment
42

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_PROCEEDING_IND: This primitive indicates to the CCS user that the call control peer is
proceeding.
CC_ALERTING_IND: This primitive indicates to the CCS user that the terminating user is being
alerted.
CC_PROGRESS_IND: This primitive indicates to the CCS user that the specified progress event
has occurred.
CC_IBI_IND: This primitive indicates to the CCS user that interworking has been encountered
and in-band information is now available. It also indicates to the CCS user that no connect
indication is pending.
CC_CONNECT_IND: This primitive indicates to the CCS user that the call has been connected.
CC_SETUP_COMPLETE_IND: This primitive indicates to the CCS user that the call has completed
setup. This primitive is used in NNI mode for interworking with UNI mode.
The sequence of primitives in a successful call establishment is defined by the time sequence diagrams
as shown in Figure 3.36.

CC_PROCEEDING_REQ
ACM

CC_OK_ACK

CC_PROCEEDING_IND

CC_ALERTING_REQ
ACM/CPG

CC_OK_ACK

CC_ALERTING_IND

CC_PROGRESS_REQ
CPG

CC_OK_ACK

CC_PROGRESS_IND

CC_IBI_REQ
ACM/CPG

CC_OK_ACK

CC_IBI_IND

CC_CONNECT_REQ
ANM/CON

CC_OK_ACK

CC_CONNECT_IND

Figure 3.36: Sequence of Primitives: Call Control Successful Call Establishment Service

3.3.4 Call Established Phase

Flow control of the call is done by management of the queue capacity, and by allowing objects of
certain types to be inserted to the queues, as shown in Table X.
3.3.4.1 User Primitives for Established Calls
CC_SUSPEND_REQ: This primitives requests that the CCS provider temporarily suspend a call.
CC_RESUME_REQ: This primitive request that the CCS provider resume a previously suspended
call.
2011-10-28

Chapter 3: CCI Services Definition

3.3.4.2 Provider Primitives for Established Calls

CC_SUSPEND_IND: This primitive indicates to the CCS user that an established call has been
temporarily suspended.
CC_RESUME_IND: This primitive indicates to the CCS user that a previously suspended call has
been resumed.
Figure 3.37 shows the sequence of primitives for suspension and resumption of established calls.
The sequence of primitives may remain incomplete if a CC_RESET or a CC_RELEASE primitive occurs.
The sequence of primitives to successfully suspend and resume a call is defined in the time sequence
diagram as shown in Figure 3.37.

CC_SUSPEND_REQ
SUS

CC_OK_ACK

CC_SUSPEND_IND

CC_RESUME_REQ
RES

CC_OK_ACK

CC_RESUME_IND

Figure 3.37: Sequence of Primitives: Call Control Suspend and Resume Service

The sequence of primitives as shown above may remain incomplete if a CC_RESET or CC_RELEASE
primitive occurs (see Table 3). A CCS user must not issue a CC_RESUME_REQ primitive if no CC_
SUSPEND_REQ has been sent previously. Following a reset procedure (CC_RESET_REQ or CC_RESET_
IND), a CCS user may not issue a CC_RESUME_REQ to resume a call suspended before the reset
procedure was signalled.
3.3.5 Call Termination Phase
3.3.5.1 Call Reject Service
User Primitives for Call Reject Service
CC_REJECT_REQ: This primitive indicates that the CCS user receiving the specified CC_SETUP_
IND requests that the specified call indication be rejected.
Provider Primitives for Call Reject Service
CC_REJECT_IND: This primitive indicates to the calling CCS user that the call has been rejected.
The sequence of events for rejecting a call setup attempt at the NNI is defined in the time sequence
diagram shown Figure 3.38.
44

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_SETUP_REQ
IAM

CC_SETUP_IND
CC_REJECT_REQ
REL
RLC

CC_REJECT_IND

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

3.3.5.2 Call Failure Service

The call error procedure is indicated by the removal of a reattempt or failure object (associated with
a local event) from the queue. The error procedure is destructive with respect to other objects in
the queue, and eventually results in the emptying of queues and termination of the call.
Provider primitives for the Call Failure Service
CC_CALL_FAILURE_IND: This primitive indicates to the CCS user that an event has caused the
call to fail and indicates the reason for the failure and the cause value associated with the
failure. The CCS user is required to immediately disconnect the circuit(s) and release the call
on any previous legs using the indicated cause value in the primitive.
The sequence of primitives for call failure are shown in Figure 3.39.

BLO/CGB/RSC/GRS
Timeout
Unexpected Message

CC_CALL_FAILURE_IND

(Other messages are possibly

exchanged automatically.)

Figure 3.39: Sequence of Primitives: Call Failure

3.3.5.3 Call Release Service

The call release procedure is initialized by the insertion of a release object (associated with a CC_
RELEASE_REQ) into the queue. As shown in Table 3, the release procedure is destructive with respect
to other objects in the queue, and eventually results in the emptying of queues and termination of
the call.
The release procedure invokes the following interactions:
A. a CC_RELEASE_REQ from the CCS user, followed by a CC_RELEASE_CON from the CCS provider;
or
2011-10-28

Chapter 3: CCI Services Definition

B. A CC_RELEASE_IND from the CCS provider, followed by a CC_RELEASE_REQ from the CCS user.

The sequence of primitives depends on the origin of the release action. The sequence may be:
1. invoked by one CCS user, with a request from that CCS user, leading to interaction (A) with
that CCS user and interaction (B) with the peer CCS user;
2. invoked by both CCS users, with a request from each of the CCS users, leading to interaction
(A) with both CCS users;
3. invoked by the CCS provider, leading to interaction (B) with both CCS users;
4. invoked independently by on CCS user and the CCS provider, leading to interaction (A) with
the originating CCS user and (B) with the peer CCS user.
User primitives for the Release Service
CC_RELEASE_REQ: This primitive request that the CCS provider release the call.
CC_RELEASE_RES: This primitive indicates to the CCS provider that the CCS user has accepted
a release indication.
Provider primitives for the Release Service
CC_RELEASE_IND: This primitive indicates to the CCS user that the call has been released.
CC_RELEASE_CON: This primitive indicates to the CCS user that the release request has been
confirmed.
The sequence of primitives as shown in Figure 3.40, Figure 3.41, Figure 3.42, and Figure 3.43, may
remain incomplete if a CC_RESET primitive occurs.
A CCS user can release a call establishment attempt by issuing a CC_RELEASE_REQ. The sequence
of events is shown in Figure 3.40, Figure 3.41, Figure 3.42, and Figure 3.43.

CC_RELEASE_REQ
REL

CC_RELEASE_IND

CC_RELEASE_RES
RLC

CC_RELEASE_CON

CC_OK_ACK

Figure 3.40: Sequence of Primitives: CCS User Invoked Release

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_RELEASE_REQ

CC_RELEASE_REQ
REL

RLC

CC_RELEASE_CON

Figure 3.41: Sequence of Primitives: Simultaneous CCS User Invoked Release

REL

CC_CALL_FAILURE_IND

CC_RELEASE_IND
CC_RELEASE_RES
RLC

CC_OK_ACK

Figure 3.42: Sequence of Primitives: CCS Provider Invoked Release

REL

CC_RELEASE_REQ
CC_RELEASE_IND

RLC

CC_CALL_FAILURE_IND

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

3.3.6 Circuit Management Services

3.3.6.1 Reset Service
The reset service is used by the CCS user or management to resynchronize the use of the call, or by
the CCS provider to report detected loss of a unrecoverable call.
The reset service is only applicable to the NNI.
The reset procedure invokes the following interactions:
A. a CC_RESET_REQ from the CCS user, followed by a CC_RESET_CON from the CCS provider; or
B. a CC_RESET_IND from the CCS provider, followed by a CC_RESET_RES from the CCS user.
The complete sequence of primitives depends upon the origin of the reset action. The reset service
may be:
1. invoked by one CCS user, leading to interaction (A) with that CCS user and interaction (B)
with the peer CCS user.
2011-10-28

Chapter 3: CCI Services Definition

2. invoked by both CCS users, leading to interaction (A) with both CCS users;
3. invoked by the CCS provider, leading to interaction (B) with both CCS users;
4. invoked by one CCS user and the CCS provider, leading to interaction (A) with the originating
CCS user and (B) with the peer CCS user.

User Primitives for Reset Service

CC_RESET_REQ: This primitive requests that the CCS provider reset the specified call control
address (circuit or circuit group).
CC_RESET_RES: This primitive indicates to the CCS provider that the CCS user has accepted
a reset indication and has performed local reset of the specified call control address (circuit or
circuit group).1

Provider Primitives for Reset Service

CC_RESET_IND: This primitive indicates to the CCS user that the user should reset the specified
call control address (circuit or circuit group).
CC_RESET_CON: This primitive indicates to the CCS user that the specified call control address
(circuit or circuit group) has been successfully reset by the peer.
The sequence of primitives are shown in Figure 3.44, Figure 3.45, Figure 3.46, and Figure 3.48.

CC_RESET_REQ
RSC/GRS

CC_RESET_IND

CC_RESET_RES
RLC/GRA

CC_RESET_CON

CC_OK_ACK

Figure 3.44: Sequence of Primitives: CCS User Invoked Reset

Note that the CC_RESET_RES primitive is not required and is only provided for completeness. The CCS
provider is allowed to acknowledge the reset request to the peer CCS user upon receipt of the necessary
protocol messages. This permits automatic completion of the reset service at the receiving CCS provider
without he presence or involvement of a management entity associated with the receiving provider.
Note that in Figure 3.44 additional primitives may be issued by the CCS provider to a CCS call control user
if a CCS call control user is engaged in a call.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_RESET_REQ

CC_RESET_REQ
RSC/GRS

RLC/GRA

CC_RESET_CON

Figure 3.45: Sequence of Primitives: Simultaneous CCS User Invoked Reset

RSC

CC_RESET_IND

CC_RESET_RES

CC_RESET_RES
RLC

CC_OK_ACK

Figure 3.46: Sequence of Primitives: CCS Provider Invoked Reset

CC_RESET_REQ
RSC

CC_RESET_IND
RLC

CC_RESET_CON

CC_RESET_RES

CC_OK_ACK

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

3
4
5

Note that in Figure 3.45 additional primitives may be issued by the CCS provider to a CCS call control user
if a CCS call control user is engaged in a call.
Note that in Figure 3.46 additional primitives may be issued by the CCS provider to a CCS call control user
if a CCS call control user is engaged in a call.
Note that in Figure 3.48 additional primitives may be issued by the CCS provider to a CCS call control user
if a CCS call control user is engaged in a call.

2011-10-28

Chapter 3: CCI Services Definition

3.3.6.2 Blocking Service

The blocking service is used by the CCS user or management to effect local maintenance or hardware
blocking on circuits, or by the CCS provider to indicate to CCS user or management the remote
maintenance or hardware blocking of circuits.
The blocking service is only applicable to the NNI.
The blocking service provides for the local and remote blocking of call control addresses (signalling
interface and circuit or circuit group) either for maintenance oriented or hardware failure purposes.
Blocking should only be invoked from streams that are listening on a circuit group that includes
the circuits for which blocking is requested, or the CC_DEFAULT_LISTENER. Maintenance blocking
will also only be indicated on streams that are listening on circuit group that includes the circuits
for which blocking is requested, or in the absence of such a stream, the CC_DEFAULT_LISTENER.
When no stream is available to report maintenance blocking indications, the indication should be
responded to by the CCS provider without user or management indication.

User Primitives for Blocking Service

CC_BLOCKING_REQ: This primitive requests that the specified call control address(es) (signalling
interface and circuit or circuit group) be locally blocked either for maintenance oriented or
hardware failure purposes.
CC_BLOCKING_RES: This primitive accepts a request and indicates the call control address(es)
(circuit or circuit group) that were remotely blocked for maintenance oriented or hardware
failure purposes.6

Provider Primitives for Blocking Service

CC_BLOCKING_IND: This primitive indicates that the CCS user has requested that the specified
call control address(es) (signalling interface and circuit or circuit group) be remotely blocked
either for maintenance oriented or hardware failure purposes.
CC_BLOCKING_CON: This primitive indicates that the remote CCS user has confirmed the specified call control address(es) (signalling interfaces and circuit or circuit group) as locally blocked
either for maintenance oriented or hardware failure purposes
The sequence of primitives are shown in Figure 3.48.

Note that the CC_BLOCKING_RES primitive is not required and is only provided for completeness. The CCS
provider is allowed to acknowledge the blocking request to the peer CCS user upon receipt of the necessary
protocol messages. This permits automatic completion of the blocking service at the receiving CCS provider
without he presence or involvement of a management entity associated with the receiving provider.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Services Definition

CC_BLOCKING_REQ
BLO/CGB

CC_BLOCKING_IND

CC_BLOCKING_RES
BLA/CGBA

CC_BLOCKING_CON

CC_OK_ACK

Figure 3.48: Sequence of Primitives: Successful Blocking Service

3.3.6.3 Unblocking Service

The unblocking service is only applicable to the NNI.
The unblocking service provides for the local and remote unblocking of call control addresses (signalling interface and circuit or circuit group) either for maintenance oriented or hardware failure
purposes.
User Primitives for Unblocking Service
CC_UNBLOCKING_REQ: This primitive requests that the specified call control address(es) (signalling interfaces and circuit or circuit groups) be locally unblocked either for maintenance
oriented or hardware failure purposes.
CC_UNBLOCKING_RES: This primitive accepts a request and indicates the call control address(es)
(circuit or circuit group) that were remotely unblocked for maintenance oriented or hardware
failure purposes.7
Provider Primitives for Unblocking Service
CC_UNBLOCKING_IND: This primitive indicates that the CCS user has requested that the specified call control address(es) (signalling interface and circuit or circuit group) be remotely blocked
either for maintenance oriented or hardware failure purposes.
CC_UNBLOCKING_CON: This primitive indicates that the remote CCS user has confirmed the
specified call control address(es) (signalling interfaces and circuit or circuit group) as locally
unblocked either for maintenance oriented or hardware failure purposes.
The sequence of primitives are shown in Figure 3.49.

Note that the CC_UNBLOCKING_RES primitive is not required and is only provided for completeness. The
CCS provider is allowed to acknowledge the unblocking request to the peer CCS user upon receipt of the
necessary protocol messages. This permits automatic completion of the unblocking service at the receiving
CCS provider without he presence or involvement of a management entity associated with the receiving
provider.

2011-10-28

Chapter 3: CCI Services Definition

CC_UNBLOCKING_REQ
UBL/CGU

CC_UNBLOCKING_IND

CC_UNBLOCKING_RES
UBA/CGUA

CC_UNBLOCKING_CON

CC_OK_ACK

Figure 3.49: Sequence of Primitives: Successful Unblocking Service

3.3.6.4 Query Service

The query service is only applicable to the NNI.
The query service provides for the query of the remote state and blocking level of call control
addresses (signalling interface and circuit group).
User Primitives for Query Service
CC_QUERY_REQ: This primitive request that the specified call control address(es) (signalling
interfaces and circuit group) be queried for remote state and blocking level.
CC_QUERY_RES: This primitive accepts a request and indicates the local state and blocking level
for the previously requested specified call control addresses (circuit group).8
Provider Primitives for Query Service
CC_QUERY_IND: This primitive indicates that the CCS user has requested that the local state
and blocking level for the call control address(es) (signalling interface and circuit group).
CC_QUERY_CON: This primitive indicates that the remote CCS user has confirmed the specified
call control addresses (signalling interface and circuit group) and has returned the remote state
and blocking level for each address.
The sequence of primitives are shown in Figure 3.50.

DL_ESTABLISH_CON

CC_TIMEOUT_IND
CC_DISCONNECT_REQ
DISCONNECT

CC_DISCONNECT_IND

Figure 3.50: Sequence of Primitives: Successful Query Service

Note that the CC_QUERY_RES primitive is not required and is only provided for completeness. The CCS
provider is allowed to acknowledge the query request to the peer CCS user upon receipt of the necessary
protocol messages. This permits automatic completion of the query service at the receiving CCS provider
without he presence or involvement of a management entity associated with the receiving provider.

Version 1.1 Rel. 1.20110510

4.1.2 Call Control Information Acknowledgement

CC INFO ACK
This primitive indicates to the CCS user any relevant protocol-dependent parameters. It should be
initiated in response to the CC_INFO_REQ primitive described above.
Format
The format of this message is one M_PCPROTO message block and its structure is as follows:
typedef struct CC_info_ack {
ulong cc_primitive;
/* FIXME ... more ... */
} CC_info_ack_t;

/* always CC_INFO_ACK */

Parameters
The above fields have the following meaning:
cc primitive
Indicates the primitive type.
Flags
Valid States
This primitive is valid in any state in response to a CC_INFO_REQ primitive.
New State
The state remains the same.

2011-10-28

Chapter 4: CCI Primitives

4.1.3 Protocol Address Request

CC ADDR REQ
This primitive requests that the CCS provider return information concerning the call control addresses upon which the CCS user is bound or engage in a call.
The format of the message is one M_PROTO message block and its structure is as follows:
typedef struct CC_addr_req {
ulong cc_primitive;
ulong cc_call_ref;
} CC_addr_req_t;

/* always CC_ADDR_REQ */
/* call reference */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference for which to obtain the connected address.

Valid States
This primitive is valid in any state.
New State
The new state is CCS_WACK_AREQ.
Rules
If the call reference is specified as zero (0), then no connected address information will be
returned in the CC_ADDR_ACK.
Acknowledgements
The CCS provider will generate on of the following acknowledgements upon receipt of the CC_ADDR_
REQ primitive:
Successful : Correct acknowledgement of the primitive is indicated via the CC_ADDR_ACK primitive.
Unsuccessful (Non-fatal errors): These errors will be indicated via the CC_ERROR_ACK primitive.
The applicable non-fatal errors are as follows:
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.1.4 Protocol Address Acknowledgement

CC ADDR ACK
This primitive acknowledges the corresponding request primitive and is used by the CCS provider
to return information concerning the bound and connected protocol addresses for the stream.
The format of the message is one M_PROTO message block and its structure is as follows:
typedef struct CC_addr_ack {
ulong cc_primitive;
ulong cc_bind_length;
ulong cc_bind_offset;
ulong cc_call_ref;
ulong cc_conn_length;
ulong cc_conn_offset;
} CC_addr_ack_t;

/*
/*
/*
/*
/*
/*

always CC_ADDR_ACK */
length of bound address */
offset of bound address */
call reference */
length of connected address */
offset of connected address */

Parameters
cc primitive
Indicates the primitive type.
cc bind length
Indicates the length of the bound call control address.
cc bind offset
Indicates the offset of the bound call control address.
cc call ref

Indicates the call reference for the connected call control address.

cc conn length
Indicates the length of the connected call control address.
cc conn offset
Indicates the offset of the connected call control address.
Valid State
This primitive is valid in state CC_WACK_AREQ.
New State
The new state is the state previous to the CC_ADDR_REQ.
Rules
If the requesting stream is not bound to a call control address, the CCS provider will code the
cc bind length and cc bind offset fields to zero. Otherwise, the CCS provider will return the
same call control address that was returned in the CC_BIND_ACK.
If the requesting stream is not connected to a call, the CCS provider will code the cc conn length
and cc conn offset fields to zero. Otherwise, the CCS provider will indicate the call control
address (circuit) upon which the call is connected.

2011-10-28

Chapter 4: CCI Primitives

4.1.5 Bind Protocol Address Request

CC BIND REQ
This primitive requests that the CCS provider bind a CCS user entity to a call control address
(circuit, circuit group) and negotiate the number of setup indications allowed to be outstanding by
the CCS provider for the specified CCS user entity being bound.
Format
The format of the message is one M_PROTO message block and its structure is as follows:
typedef struct CC_bind_req {
ulong cc_primitive;
/* always CC_BIND_REQ */
ulong cc_addr_length;
/* length of address */
ulong cc_addr_offset;
/* offset of address */
ulong cc_setup_ind;
/* req # of setup inds to be queued */
ulong cc_bind_flags;
/* bind options flags */
} CC_bind_req_t;
/* Flags associated with CC_BIND_REQ */
#define CC_DEFAULT_LISTENER
0x000000001UL
#define CC_TOKEN_REQUEST
0x000000002UL
#define CC_MANAGEMENT
0x000000004UL
#define CC_TEST
0x000000008UL
#define CC_MAINTENANCE
0x000000010UL
#define CC_MONITOR
0x000000020UL

Parameters
cc primitive
Is the primitive type.
cc addr length
Is the length in bytes of the call control (circuit, circuit group) address to be bound to
the stream.
cc addr offset
Is the offset from the beginning of the M_PROTO block where the call control (circuit,
circuit group) address begins.
cc setup ind
Is the requested number of setup indications (simultaneous incoming calls) allowed to
be outstanding by the CCS provider for the specified protocol address. (If the number of
outstanding setup indications equals cc setup ind, the CCS provider need not discard
further incoming setup indications, but may choose to queue them internally until the
number of outstanding setup indications drops below the cc setup ind number.) Only
one stream per call control address is allowed to have a cc setup ind number value
greater than zero. This indicates to the CCS provider that this stream is the listener
stream for the CCS user. This stream will be used by the CCS provider for setup
indications for that call control address.
if a stream is bound as a listener stream, it is still able to initiate outgoing call setup
requests.
60

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

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

When set, this flag specifies to the CCS provider that this stream is to be used for
continuity and test call indications for the specified addresses.

CC_MAINTENANCE
When set, this flag specifies to the CCS provider that this stream is to be used for
maintenance indications for the specified addresses.
Valid States
This primitive is valid in state CCS_UNBND (see Appendix C [State/Event Tables], page 279).
New State
The new state is CCS_WACK_BREQ.
Acknowledgements
The CCS provider will generate one of the following acknowledgements upon receipt of the CC_BIND_
REQ primitive:
Successful : Correct acknowledgement of the primitive is indicated via the CC_BIND_ACK primitive.
Non-fatal errors: These errors will be indicated via the CC_ERROR_ACK primitive. The applicable
non-fatal errors are as follows:
2011-10-28

Chapter 4: CCI Primitives

[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADADDR]
The call control address was in an incorrect format or the address contained illegal
information. It is not intended to indicate protocol errors.
[CCNOADDR]
The CCS user did not provide a call control address and the CCS provider could
not allocate an address to the user.
[CCADDRBUSY]
The CCS user attempted to bind a second stream to a call control address with
the cc setup ind number set to a non-zero value, or attempted to bind a second
stream with the CC_DEFAULT_LISTENER flag value set to non-zero.
[CCBADFLAG]
The flags were invalid or unsupported, or the combination of flags was invalid. This
error is returned if more than one of CC_TEST, CC_MANAGEMENT, or CC_MAINTENANCE
flags are set.
[CCBADPRIM]
The primitive format was incorrect (i.e. too short).
[CCACCESS]
The user did not have proper permissions.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.1.6 Bind Protocol Address Acknowledgement

CC BIND ACK
This primitive indicates to the CCS user that the specified call control user entity has been bound to
the requested call control address and that the specified number of connect indications are allowed
to be queued by the CCS provider for the specified network address.
Format
The format of the message is one M_PCPROTO message block, and its structure is the following:
typedef struct CC_bind_ack {
ulong cc_primitive;
ulong cc_addr_length;
ulong cc_addr_offset;
ulong cc_setup_ind;
ulong cc_token_value;
} CC_bind_ack_t;

/*
/*
/*
/*
/*

always CC_BIND_ACK */
length of address */
offset of address */
setup indications */
setup response token value */

Parameters
cc primitive
Indicates the primitive type.
cc addr length
Is the length of the call control address that was bound.
cc addr offset
Is the offset from the beginning of the M_PCPROTO block where the call control address
begins.
cc setup ind
Is the accepted number of setup indications allowed to be outstanding by the CCS
provider for the specified call control address. If its value is zero, this stream cannot
accept CC_SETUP_IND messages. If its value is greater than zero, then the CCS user
can accept CC_SETUP_IND messages up to the value specified in this parameter before
having to respond with a CC_SETUP_RES or a CC_DISCONNECT_REQ message.
cc token value
Conveys the value of the "token" assigned to this stream that can be used by the CCS
user in a CC_SETUP_RES primitive to accept a call on this stream. It is a non-zero value,
and is unique to all streams bound to the CCS provider.
The proper alignment of the address in the M_PCPROTO message block is not guaranteed.
Rules
The following rules apply to the binding of the specified call control address to the stream:
If the cc addr length field in the CC_BIND_REQ primitive is zero, then the CCS provider is to
assign a call control address to the user.
The CCS provider is to bind the call control address as specified in the CC_BIND_REQ primitive.
If the CCS provider cannot bind the specified address, it may assign another call control address
2011-10-28

Chapter 4: CCI Primitives

to the user. It is the call control users responsibility to check the call control address returned
in the CC_BIND_ACK primitive to see if it is the same as the one requested.
The following rules apply to negotiating cc setup ind argument:
The cc setup ind number in the CC_BIND_ACK primitive must be less than or equal to the
corresponding requested number as indicated in the CC_BIND_REQ primitive.
Only one stream that is bound to the indicated call control address may have a negotiated
accepted number of maximum setup indications greater than zero. If a CC_BIND_REQ primitive
specifies a value greater than zero, but another stream has already bound itself to the given
call control address with a value greater than zero, the CCS provider should assign another
protocol address to the user.
If a stream with cc setup ind number greater than zero is used to accept a call, the stream will
be found busy during the duration of that call and no other streams may be bound to that call
control address with a cc setup ind number greater than zero. This will prevent more than one
stream bound to the identical call control address from accepting setup indications.
A stream requesting a cc setup ind number of zero should always be legal. This indicates to
the CCS provider that the stream is to be used to request call setup only.
A stream with a negotiated cc setup ind number greater than zero may generate setup requests
or accept setup indications.
If the above rules result in an error condition, then the CCS provider must issue a CC_ERROR_ACK
primitive to the CCS user specifying the error as defined in the description of the CC_BIND_REQ
primitive.
Valid States
This primitive is in response to a CC_BIND_REQ primitive and is valid in the state CCS_WACK_BREQ.
New State
The new state is CCS_IDLE.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.1.7 Unbind Protocol Address Request

CC UNBIND REQ
This primitive request that the CCS provider unbind the CCS user entity that was previously bound
to the call control address.
Format
The format of the message is one M_PROTO block, and its structure is as follows:
typedef struct CC_unbind_req {
ulong cc_primitive;
} CC_unbind_req_t;

/* always CC_UNBIND_REQ */

Parameters
cc primitive
Indicates the primitive type.
Valid States
This primitive is valid in the CCS_IDLE state.
New State
The new state is CCS_WACK_UREQ.
Acknowledgements
This primitive requires the CCS provider to generate the following acknowledgements upon receipt
of the primitive:
Successful : Correct acknowledgement of the primitive is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): These errors will be indicated via the CC_ERROR_ACK primitive.
The applicable non-fatal errors are as follows:
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCSYSERR]
A system error has occurred and the UNIX system error is indicated in the primitive.

2011-10-28

Chapter 4: CCI Primitives

4.1.8 Call Processing Options Management Request

CC OPTMGMT REQ
This primitive allows the CCS user to manage the call processing parameter values associated with
the stream.
Format
The format of the message is one M_PROTO message block, and its structure is as follows:
typedef struct CC_optmgmt_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
ulong cc_opt_flags;
} CC_optmgmt_req_t;

/*
/*
/*
/*
/*

always CC_OPTMGMT_REQ */
call reference */
length of option values */
offset of option values */
option flags */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference for which to manage options.

cc opt length
Specifies the length of the default values of the options parameters as selected by the
CCS user. These values will be used in subsequent CC_SETUP_REQ primitives on the
stream that do not specify values for these options. If the CCS user cannot determine
the value of an option, it value should be set to CC UNKNOWN. If the CCS user does
not specify any option paramter values, the length of this field should be set to zero.
cc opt offset
Specifies the offset of the options parameters from the beginning of the M_PROTO message
block.
cc opt flags
See "Flags" below.
Flags
Valid States
This primitive is valid in the CCS_IDLE state.
New State
The new state is CCS_WACK_OPTREQ.
Acknowledgements
The CC_OPTMGMT_REQ primitive requires the CCS provider to generate one of the following acknowledgements upon receipt of the primitive:
66

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Successful : Acknowledgement is via the CC_OK_ACK primitive. At successful completions, the

resulting state is CCS_IDLE.
Non-fatal errors: These errors are indicated in the CC_ERROR_ACK primitive. The resulting
state remains unchanged. The applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error has occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADOPT]
The option parameter values specified are outside the range supported by the CCS
provider.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADFLAG]
The flags were invalid or unsupported, or the combination of flags was invalid.
[CCBADPRIM]
The primitive format was incorrect (i.e. too short).
[CCACCESS]
The user did not have proper permissions.

2011-10-28

Chapter 4: CCI Primitives

4.1.9 Call Processing Options Management Acknowledgement

CC OPTMGMT ACK
This primitive allows the CCS user to manage the call processing parameter values associated with
the stream.
Format
The format of the message is one M_PCPROTO message block, and it structure is as follows:
typedef struct CC_optmgmt_ack {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
ulong cc_opt_flags;
} CC_optmgmt_ack_t;

/*
/*
/*
/*
/*

always CC_OPTMGMT_ACK */
call reference */
length of option values */
offset of option values */
option flags */

Parameters
Flags
Valid States
This primitive is valid in any state.
New State
The new state is unchanged.
Acknowledgements

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.1.10 Error Acknowledgement

CC ERROR ACK
This primitive indicates to the CCS user that a non-fatal error has occurred in the last CCS user
originated primitive. This may only be initiated as an acknowledgement for those primitives that
require one. It also indicates to the user that no action was taken on the primitive that caused the
error.
Format
The format of the mssage is one M_PCPROTO message block, and its structure is as follows:
typedef struct CC_error_ack {
ulong cc_primitive;
ulong cc_error_primitive;
ulong cc_error_type;
ulong cc_unix_error;
ulong cc_state;
ulong cc_call_ref;
} CC_error_ack_t;

/*
/*
/*
/*
/*
/*

always CC_ERROR_ACK */
primitive in error */
CCI error code */
UNIX system error code */
current state */
call reference */

Parameters
cc primitive
Identifies the primitive type.
cc error primitive
Identifies the primitive type that cause the error.
cc error type
Contains the Call Control Interface error code.
cc unix error
Contains the UNIX system error code. This may only be non-zero if the cc error type
is equal to [CCSYSERR].
cc state

Identifies the state of the interface at the time that the CC_ERROR_ACK primitive was
issued by the CCS provider.

cc call ref

Identifies the CCS provider or CCS user call reference associated with the request or
response primitive that was in error. If no call reference is associated with the request
or response primitive that caused the error, this field is coded zero (0) by the CCS
provider.

Valid Error Codes

The following error codes are allows to be returned:
[CCSYSERR]
A system error has occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
2011-10-28

Chapter 4: CCI Primitives

[CCBADADDR]
The call control address as specified in the primitive was in an incorrect format, or the
address contained illegal information.
[CCBADDIGS]
The digits provided in the called party number or subsequent number specified in the
primitive are of an incorrect format or are invalid.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or they
contained illegal information.
[CCNOADDR]
The CCS provider could not allocate an address.
[CCADDRBUSY]
The CCS provider could not use the specified address because the specified address is
already in use.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADTOK]
Token used is not associated with an open stream.
[CCBADFLAG]
The flags specified in the primitive were incorrect or illegal.
[CCNOTSUPP]
Specified primitive type is not known to the CCS provider.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out of range).
[CCACCESS]
The user did not have proper permissions.
Valid States
This primitive is valid in all states that have a pending acknowledgement or confirmation.
New State
The new state is the same as the one from which the acknowledged request or response was issued.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.1.11 Successful Receipt Acknowledgements

CC OK ACK
The primitive indicates to the CCS user that the previous call control user originated primitive was
received successfully by the call control provider. It does not indicate to the CCS user any call
control protocol action taken due to the issuance of the last primitive. The CC_OK_ACK primitive
may only be initiated as an acknowledgement for those user-originated primitives that have no other
means of confirmation.
Format
The format of the message is one M_PCPROTO message block, and its structure is as follows:
typedef struct CC_ok_ack {
ulong cc_primitive;
ulong cc_correct_prim;
ulong cc_state;
ulong cc_call_ref;
} CC_ok_ack_t;

/*
/*
/*
/*

always CC_OK_ACK */
primitive being acknowledged */
current state */
call reference */

Parameters
cc primitive
Identifies the primitive.
cc correct prim
Identifies the successfully received primitive type.
cc state

Identifies the state of the interface at the time that the CC_OK_ACK primitive was issued
by the CCS provider.

cc call ref

Valid States
This primitive is issued in states CCS_WACK_UREQ and CCS_WACK_OPTREQ.
New State
The resulting state depends on the current state (see Appendix C [State/Event Tables], page 279,
Tables B-7 and B-8.).

2011-10-28

Chapter 4: CCI Primitives

4.2 Primitive Format and Rules

This section describes the format of the UNI (User and Newtork) and NNI primitives and the rules
associated with these primitives. The default values of the options parameters associated with a call
may be selected via the CC_OPTMGMT_REQ primitive.
4.2.1 Call Setup Phase
The following call control service primitives pertain to the setup of a call, provided the CCS users
exist, and are known to the CCS provider.
4.2.1.1 Call Control Setup Request
CC SETUP REQ
This primitive requests that the CCS provider make a call to the specified destination.
Format
The format of the message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_setup_req {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_call_type;
ulong cc_call_flags;
ulong cc_cdpn_length;
ulong cc_cdpn_offset;
ulong cc_opt_length;
ulong cc_opt_offset;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_setup_req_t;

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

always CC_SETUP_REQ */
user call reference */
call type */
call flags */
called party number length */
called party number offset */
optional parameters length */
optional parameters offset */
connect to address length */
connect to address offset */

Parameters
cc primitive
Specifies the primitive type.
cc user ref

Specifies a reference number known to the CCS user that uniquely identifies the current
setup request. When this value is non-zero, it permits the CCS User to have multiple outstanding setup requests pending on the same stream. Responses made by the
CCS provider to the CC_SETUP_REQ primitive will contain this CCS user call attempt
reference.

cc call type
Specifies the type of call to be set up. Call types supported are dependent upon the
CCS provider and protocol, see the addendum for call types for specific protocols.
cc call flags
Specifies a bit field of call options. Call flags supported are depeddent upon the CCS
provider and protocol, see the addendum for call flags for specific protocols.
72

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

cc cdpn length
Specifies the length of the called party number parameter that conveys an address
identifying the CCS user to which the call is to be established. This field will accommodate variable length numbers within a range supported by the CCS provider. If no
called party address is provided by the CCS user, this field must be coded to zero. The
coding of the called party number is protocol and provider-specific.
cc cdpn offset
Is the offset of the called party number from the beginning of the M_PROTO message
block.
cc opt length
Specifies the length of optional parameters to be conveyed in the call setup. This
field will accomodate variable length addresses within a range supported by the CCS
provider. If no optional parameters are provided by the CCS user, this field must be
coded to zero. The format of optional parameters are protocol and provider-specific,
see the addendum for the format of optional parameters for specific protocols.
cc opt offset
Specifies the offset of the optional parameters from the beginning of the M_PROTO message block.
cc addr length
Specifies the length of the call control address parameter that conveys the call control
address (circuit, circuit group) of the CCS user entity to which the call is to be established. The semantics of the values in the CC_SETUP_REQ is identical to the values in
the CC_BIND_REQ.
cc addr offset
Specifies the offset of the call control address from the beginning of the M_PROTO message
block.
Rules
The following rules apply to the setup of calls to the specified addresses:
If the cc cdpn length field in the CC_SETUP_REQ primitive is zero, then the CCS provider is
to select a called party number for the call. If the CCS provider cannot select a called party
number for the call, the CCS provider responds with a CC_ERROR_ACK primitive with error
[CCNOADDR].
If the cc cdpn length field in the CC_SETUP_REQ primitive is non-zero, the CCS provider is
to setup the call to the specified number. If the CCS provider cannot setup a call of the
specified call type to the specified number the call will fail and the CCS provider will return a
CC_ERROR_ACK with the appropriate error value (e.g., [CCBADADDR]).
The following rules apply to the call control addresses (trunk groups and circuit identifiers):
If the CCS user does not specify a call control address (i.e. cc addr length is set to zero), then
the CCS provider may attempt to assign a call control address, assign it a call reference and
associate it with the stream for the duration of the call.
The following rules apply to the CCS user call attempt reference:
2011-10-28

Chapter 4: CCI Primitives

If the CCS user does not specify a call attempt reference (i.e. the cc user ref is set to zero),
then the CCS provider can only support one outstanding outgoing call attempt for the stream.
If the CCS user specifies a call attempt reference, all replies made by the CCS provider to this
CC_SETUP_REQ primitive will contain the CCS user specified call attempt reference until either
the call fails or is released, or after the CCS provider sends a CC_SETUP_CON primitive.
Valid States
This primitive is valid in state CCS_IDLE.
New State
The new state depends upon the information provided in the CC_SETUP_REQ message as follows:
If the setup request specifies that a continuity check was performed on a previous circuit, the
new state is CCS_WREQ_CCREP (awaiting report of the result of continuity test performed on the
previous circuit).
If the setup request specifies that a continuity check is required on the circuit, the new state is
CCS_WIND_CTEST (awaiting indication of remote loop back on the circuit).
If the setup request specifies that no continuity test is required on this or a previous circuit
and that the called party address contains partial information, the new state is CCS_WIND_MORE
(awaiting the indication that more information is required).
If the setup request specifies that no continuity test is required on this or a previous circuit and
that the called party address contains complete information, the new state is CCS_WCON_SREQ
(awaiting confirmation of the setup request).
Acknowledgements
The following acknowledgements are valid for this primitive:
Successful Call Establishment: This is indicated via the CC_SETUP_CON primitive. This results
in the Call Establishment state. For CC_SETUP_REQ primitives where ISUP_NCI_CONT_CHECK_
REQUIRED is set, or where the CCS provider otherwise determines that a continuity check
is required on the circuit, success is still indicated via the CC_SETUP_CON primitive. In this
case, the CC_SETUP_CON primitive is not sent by the CCS provider unless the continuity check
is successful. For CCS_SETUP primitives where ISUP_NCI_CONT_CHECK_PREVIOUS is set, the
CC_SETUP_CON primitive is not sent by the CCS provider until the CCS user sends a CC_
CONT_REPORT_REQ primitive indicating that continuity check on the previous circuit has been
successful. Receipt of the CC_SETUP_CON primitive always results in the Call Establishment
state.
Unsuccessful Call Establishment: This is indicated via the CC_CALL_REATTEMPT_IND, CC_CALL_
FAILURE_IND, or CC_RELEASE_IND primitives. For example, a call may be rejected because
either the called CCS user cannot be reached, or the CCS provider and/or the called CCS
user did not agree on the specified call type or options. This results in the Idle state. Where
the CC_CALL_REATTEMPT_IND or CC_RELEASE_IND primitives are sent before the CC_SETUP_CON
primitive, the CC_CALL_REATTEMPT_IND or CC_RELEASE_IND primitives will contain the CCS
user specified call attempt reference.
Non-fatal errors: These are indicated via the CC_ERROR_ACK primitive. The applicable non-fatal
errors are defined as follows:
74

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

[CCSYSERR]
A system error has occurred and the UNIX system eror is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADADDR]
The call control address as specified in the primitive was in an incorrect format,
or the address contained illegal information.
[CCBADDIGS]
The called party number was in the incorrect format, or contained illegal information. This is used only to handle coding errors of the number and is not
intended to provide for protocol errors. Protocol errors should be conveyed in the
CC_CALL_REATTEMPT_IND, CC_CALL_FAILURE_IND or CC_RELEASE_IND primitives.
[CCBADOPT]
The optional parameters were in an incorrect format, or contained illegal information.
[CCNOADDR]
The user did not provide a called party address field and one was required by the
call type. The CCS provider could not select a called party address.
[CCADDRBUSY]
The CCS provider could not use the specified address because the specified address
is already in use.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal (not unique).
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out of
range).
[CCACCESS]
The user did not have proper permissions for the use of the requested address or
options.

2011-10-28

Chapter 4: CCI Primitives

4.2.1.2 Call Control Setup Indication

CC SETUP IND
This primitive indicates to the destination CCS user that a call setup request has been made by the
user at the specified source address.
Format
The format of the message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_setup_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_call_type;
ulong cc_call_flags;
ulong cc_cdpn_length;
ulong cc_cdpn_offset;
ulong cc_opt_length;
ulong cc_opt_offset;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_setup_ind_t;

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

always CC_SETUP_IND */
call reference */
call type */
call flags */
called party number length */
called party number offset */
optional parameters length */
optional parameters offset */
connecting address length */
connecting address offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Identifies the call reference that can be used by the CCS user to associate this message
with the CC_SETUP_RES or CC_RELEASE_REQ primitive that is to follow. This value
must be unique among the outstanding CC_SETUP_IND messages.

cc call type
Indicates the type of call to be set up. Call types supported are dependent upon the
CCS provider and protocol, see the addendum for call types for specific protocols.
cc call flags
Indicates a bit field of call options. Call flags supported are dependent upon the CCS
provider and protocol, see the addendum for call flags for specific protocols.
cc cdpn length
Indicates the length of the called party number address parameter that conveys an
address identifying the CCS user to which the call is to be established. This field will
accommodate variable length addresses within a range supported by the CCS provider.
cc cdpn offset
Is the offset of the called party number address from the beginning of the M_PROTO
message block.
cc opt length
Indicates the length of the optional parameters that were used in the call setup.
76

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

cc opt offset
Indicates the offset of the optional parameters from the beginning of the M_PROTO
message block.
cc addr length
Indicates the length of the connecting address parameter that conveys the call control
address the CCS user entity (circuit) on which the call is being established. The
semantics of the values in the CC_SETUP_IND is identical to the values in the CC_BIND_
ACK.
cc addr offset
Indicates the offset of the connecting address from the beginning of the M_PROTO message block.
Valid States
This primitive is valid in state CCS_IDLE for the indicated call reference.
New State
The new state depends upon the information provided in the CC_SETUP_IND message as follows:
If the setup indication indicates that a continuity check was performed on a previous circuit,
the new state is CCS_WIND_CCREP (awaiting the report of continuity test results).
If the setup indication indicates that a continuity check is required on the circuit, the new state
is CCS_WREQ_CTEST (awaiting confirmation of installation of loop back device on the circuit).
If the setup indication indicates that no continuity tests are required on this or a previous circuit
and that the called party number contains partial information, the new state is CCS_WREQ_MORE
(awaiting the request for more information to confirm the partial address).
If the setup indication indicates that no continuity tests are required on this or a previous
circuit and that the called party number contains complete information, the new state is CCS_
WRES_SIND (awaiting response to the setup indication).
In any event, the number of outstanding setup indications waiting for user response is incremented
by one.
Rules
The rules for issuing the CC_SETUP_IND primitive are as follows:
This primitive will only be issued to streams that have been bound with a non-zero negotiated
maximum number of setup indications (i.e. on a listening stream), and where the number
of outstanding setup indications (call references) for the stream is less than the negotiated
maximum number of setup indications.
If the call setup indicated is for a normal call, the stream upon which it is indicated was not
bound with the CC_TEST, CC_MANAGEMENT or CC_MAINTENANCE flags set.
If the call setup indicated is for an ISUP test call, the stream upon which it is indicated
was bound with the CC_TEST flag set and a non-zero number of negotiated maximum setup
indications.

2011-10-28

Chapter 4: CCI Primitives

4.2.1.3 Call Control Setup Response

CC SETUP RES
This primitive allows the destination CCS user to request that the call control provider accept a
previous setup indication. This primitive also indicates that overlap receiving is complete. The CCS
use is still expected to complete the setup process by issuing the CCS_PROCEED_REQ, CCS_ALERTING_
REQ, CCS_PROGRESS_REQ, CCS_IBI_REQ, CCS_CONNECT_REQ, or CCS_DISCONNECT_REQ messages.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_setup_res {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_token_value;
} CC_setup_res_t;

/* always CC_SETUP_RES */
/* call reference */
/* call response token value */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference of the CC_SETUP_RES message. It is used by the CCS
provider to associated the CC_SETUP_RES message with an outstanding CC_SETUP_IND
message. An invalid call reference should result in error with the error type [CCBADCLR].

cc token value
Is used to identify the stream that the CCS user wants to establish the call on. (Its
value is determined by the CCS user by issuing a CC_BIND_REQ primitive with the CC_
TOKEN_REQ flag set. The token value is returned in the CC_BIND_ACK.) The value of
this field should be non-zero when the CCS user wants to establish the call on a stream
other than the stream on which the CC_SETUP_IND arrived. If the CCS user wants to
establish a call on the same stream that the CC_SETUP_IND arrived on, then the value
of this field should be zero.
Valid States
This primitive is valid in state CCS_WRES_SIND.
New State
The new state is CCS_WREQ_PROCEED.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
78

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Unsuccesful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error has occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADTOK]
The token specified is not associated with an open stream.
[CCBADPRIM]
The primitive format was incorrect (i.e. too short).

2011-10-28

Chapter 4: CCI Primitives

4.2.1.4 Call Control Setup Confirm

CC SETUP CON
This primitive indicates to the calling CCS user that the call control setup request has been sent on
the specified call control address (circuit, circuit group). For calls that were requested setup with
the ISUP_NCI_CONT_CHECK_REQUIRED flag set in the CC_SETUP_REQ, or for which the CCS provider
has otherwise decide to perform continuity check, this also confirms that the continuity check was
successful.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_setup_con {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_call_ref;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_setup_con_t;

/*
/*
/*
/*
/*

always CC_SETUP_CON */
user call reference */
call reference */
connecting address length */
connecting address offset */

Parameters
cc primitive
Indicates the primitives type.
cc user ref

Indicates the CCS user call attempt reference value which was provided by the CCS
user in the CC_SETUP_REQ message. This permits the CCS user to associate this CC_
SETUP_CON primitive with the previous CC_SETUP_REQ primitive and permits multiple
outstanding CC_SETUP_REQ primitives.

cc call ref

Indicates the CCS provider assigned call reference. If the CCS user wishes to establish
more than one simultaneous call on a given stream, the CCS user must use this CCS
provider indicated call reference in subsequent call control primitives sent to the CCS
provider. This permits the CCS provider to associate a CCS user primitive with one
of multiple simultaneous calls associated with a given stream.

cc addr length
Indicates the length of the connecting address parameter that conveys the call control
address of the CCS user entity (circuit) on which the call is being established. The
semantics of the values in the CC_SETUP_CON is identical to the values in the CC_BIND_
REQ.
cc addr offset
Indicates the offset of the connecting address from the beginning of the M_PROTO message block.
Valid States
This primitive is valid in state CCS_WCON_SREQ and state CCS_WREQ_CCREP.
80

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

New State
The new state depends on whether an end-of-pulsing signal was present in the called party number
in the associated CC_SETUP_REQ primitive. If an ST signal was present, the new state is CCS_
WREQ_PROCEED, otherwise the new state is CCS_WREQ_MORE. In either case, the call enters the Call
Establishment Phase.

2011-10-28

Chapter 4: CCI Primitives

4.2.1.5 Call Control Reattempt Indication

CC CALL REATTEMPT IND
This primitive indicates to the calling CCS user that the selected address (circuit) is unavailable
and that a reattempt should be made on a new call control address (circuit).
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_call_reattempt_ind {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_reason;
} CC_call_reattempt_ind_t;

/* always CC_CALL_REATTEMPT_IND */
/* user call reference */
/* reason for reattempt */

Call Control Interface (CCI)

CCI Primitives

4.2.2.3 Call Control Continuity Test Request

CC CONT TEST REQ
This message is used either to respond to a CC_SETUP_IND primitive which contains the ISUP_NCI_
CONT_CHECK_REQUIRED flag, or to respond to a CC_CONT_CHECK_IND primitive. Before responding to
either primitive, the CCS User should install a loop back device on the requested channel and then
respond with this response primitive to confirm the loop back.
Format
The format of this message is on M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_cont_test_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_token_value;
} CC_cont_test_req_t;

/* always CC_CONT_TEST_REQ */
/* call reference */
/* token value */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference of the CC_CONT_TEST_REQ message. It is used by the CCS
provider to associate the CC_CONT_TEST_REQ message with an outstanding CC_SETUP_
IND message. An invalid call reference should result in error with the error type
[CCBADCLR].

cc token value
Is used to identify the stream that the CCS user wants to establish the continuity check
call on. (Its value is determined by the CCS user by issuing a CC_BIND_REQ primitive
with the CC_TOKEN_REQ flag set. The token value is returned in the CC_BIND_ACK.) The
value of this field should be non-zero when the CCS user wants to establish the call on
a stream other than the stream on which the CC_CONT_CHECK_IND arrived. If the CCS
user wants to establish a call on the same stream that the CC_CONT_CHECK_IND arrived
on, then the value of this field should be zero.
Valid Modes
This primitive is valid only in NNI mode.
Valid States
This primitive is valid in state CKS WREQ CTEST.
New State
The new state is CKS WIND CCREP.
2011-10-28

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_CONT_REPORT_IND in the case that
the primitive was issued in response to a CC_SETUP_IND, or CC_RELEASE_IND primitive in the
case that the primitive was issued in response to the CC_CONT_CHECK_IND primitive.
Unsuccessful : Unsuccessful completion is indicated via the CC_CONT_REPORT_IND primitive.
Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCSYSERR]
A system error has occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCACCESS]
The user did not have proper permissions for the operation.
[CCNOTSUPP]
The CCS provider does not support the operation.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.2.4 Call Control Continuity Test Indication

CC CONT TEST IND
This message confirms to the testing CCS user that a loop back device has been (or will be) installed on the specified call control address (circuit). Upon receiving this message, the testing CCS
user should connect tone generation and detection equipment to the specified circuit, perform the
continuity test and issue a report using the CC_CONT_REPORT_REQ primitive.
This primitive will only be issued to streams successfully bound with the CC_BIND_REQ primitive
with a non-zero number of setup indications and the CC_TEST bind flag set.
Format
The format of this message is on M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_cont_test_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_cont_test_ind_t;

/*
/*
/*
/*

always CC_CONT_TEST_IND */
call reference */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference associated with the continuity check call for the specified
call control address (circuit identifier).

cc addr length
Indicates the length of the call control address (signalling interface and circuit identifier)
upon which a continuity check is confirmed. The semantics of the values in the CC_
CONT_TEST_IND is identical to the values in the CC_BIND_REQ.
cc addr offset
Indicates the offset of the connecting address from the beginning of the M_PROTO message block.
Valid Modes
This primitive is valid only in NNI mode.
Valid States
This primitive is valid in state CCS_WCON_CREQ.
New State
The new state is CCS_WAIT_COR.

2011-10-28

Chapter 4: CCI Primitives

4.2.2.5 Call Control Continuity Report Request

CC CONT REPORT REQ
This primitive requests that the CCS provider indicate to the called CCS user that the continuity
check succeeded or failed. The CCS user should remove any continuity test tone generator/detection
device from the circuit and verify silent code loop back before issuing this primitive.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_cont_report_req {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_call_ref;
ulong cc_result;
} CC_cont_report_req_t;

/*
/*
/*
/*

always CC_CONT_REPORT_REQ */
user call reference */
call reference */
result of continuity check */

Parameters
cc primitive
Specifies the primitive type.
cc user ref

Specifies the CCS user reference of the associated CC_SETUP_REQ primitive.

This value is non-zero when the CC_CONT_REPORT_REQ primitive
is issued subsequent to a CC_SETUP_REQ primitive which had the flag
ISUP NCI CONTINUITY CHECK PREVIOUS set to indicate the result of the
continuity check on the previous circuit. Otherwise, this value is coded zero.

cc call ref

Specifies the call reference of the associated CC_CONT_TEST_IND primitive for the continuity check call. This value is non-zero when the CC_CONT_REPORT_REQ primitive is
issued in response to a CC_CONT_TEST_IND primitive. Otherwise, this value is coded
zero.

cc result

Specifies the result of the continuity test, whether success or failure. The value of the
cc result is protocol specific. For values representing success and values representing
failure, see the Addendum.

Valid Modes
This primitive is valid only in NNI mode.
Valid States
This primitive is valid in state CCS_WREQ_CCREP.
New State
When issued in response to the CC_CONT_TEST_IND primitive, the new state is CCS_IDLE. When
issued subsequent to a CC_SETUP_REQ primitive, the new state is either CCS_WREQ_MORE or CCS_
WREQ_PROCEED, depending upon whether the sent address contain an ST pulse.
90

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADPRIM]
The primitive format was incorrect.

2011-10-28

Chapter 4: CCI Primitives

4.2.2.6 Call Control Continuity Report Indication

CC CONT REPORT IND
This primitive indicates to the called CCS user that the continuity check succeeded or failed. The
called CCS user can remove the loop back or tone generation/detection devices from the circuit and
the call either moves to the idle state or a call setup state.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_cont_report_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_result;
} CC_cont_report_ind_t;

/* always CC_CONT_REPORT_IND */
/* call reference */
/* result of continuity check */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference associated with the continuity check report as it appeared
in the associated CC_CONT_CHECK_IND primitive.

cc result

Indicates the result of the continuity test, whether success or failure. The value of the
cc result is protocol specific. For values representing success and values representing
failure, see the Addendum.

Valid Modes
This primitive is valid only in NNI mode.
Valid States
This primitive is valid in state CCS_WREQ_CTEST or CCS_WIND_CCREP.
New State
If the primitive is issued subsequent to the CC_SETUP_REQ, the new state is CCS_WCON_SREQ. If the
primitive is issued in response to the CC_CONT_TEST_IND primitive, the new state is CCS_IDLE.

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.3 Collecting Information Phase

The following call control service primitive pertain to the collecting information phase of a call.
During this phase requests for more information are issued and indicated, and additional information
is provided.
4.2.3.1 Call Control More Information Request
CC MORE INFO REQ
This message request more information (digits in the called party address, or optional parameters)
from the calling CCS user. This specifies to the CCS provider that overlap receiving is in effect and
the number of digits received are not sufficient to complete the call.
Format
The format of this message is on M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_more_info_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_more_info_req_t;

/*
/*
/*
/*

always CC_MORE_INFO_REQ */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference for the CC_MORE_INFO_REQ message. It is used by the CCS
provider to associated the CC_MORE_INFO_REQ message with an previous CC_SETUP_IND
message and identify the incoming call.

cc opt length
Indicates the length of the optional parameters associated with the nore information
request.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI (User and Network) mode and for compatibility in NNI mode.
Valid States
This primitive is valid in state CCS_WREQ_MORE.
New State
The new state is CCS_WIND_INFO.
2011-10-28

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_INFORMATION_IND and CC_INFO_
TIMEOUT_IND primitives.
Unsuccessful : Unsuccessful completion is indicated by the CC_CALL_FAILURE_IND primitive
with a protocol specific reason indicating that additional information was not provided within
a sufficient period of time.
Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCSYSERR]
A system error has occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCNOTSUPP]
The CCS provider does not support the operation.
[CCACCESS]
The user did not have proper permissions for the operation.
[CCBADPRIM]
The primitive was incorrectly formatted (i.e. the M_PROTO message block was too
short).

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.3.2 Call Control More Information Indication

CC MORE INFO IND
This message indicates that the calling CCS user needs to provide additional information (called
party address digits) to complete call processing. The CCS user should generate CC_INFORMATION_
REQ primitives, if possible. This is also an indication that overlap receiving is in effect. Appropriate
protocol timers will be started.
In contrast to the the CC_INFORMATION_REQ primitive(s) which are sent by the CCS user in response
to this message, the CC_MORE_INFO_IND message is normally only issued once per call setup.
Format
The format of this message is on M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_more_info_ind {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_more_info_ind_t;

/*
/*
/*
/*

always CC_MORE_INFO_IND */
user call reference */
optional parameter length */
optional parameter offset */

CCI Primitives

4.2.4 Call Establishment Phase

The following call control service primitives pertain to the establishment of a call.
4.2.4.1 Call Control Proceeding Request
CC PROCEEDING REQ
This primitive requests that the CCS provider indicate to the calling CCS user that the call is
proceeding towards the called CCS user. This also means that there is sufficient called party address
information to complete the call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_proceeding_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_proceeding_req_t;

/*
/*
/*
/*
/*

always CC_PROCEEDING_REQ */
call reference */
proceeding flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference for the request. The call reference is used by the CCS
provider to identify the call.

cc flags

Specifies proceeding flags associated with the proceeding request. Proceeding flags are
protocol specific (see the Addendum).

101

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADFLAG]
The specified flags were incorrect or unsupported.
[CCBADOPT]
The optional parameters were in an incorrect format, or contained illegal information.
[CCACCESS]
The user did not have proper permissions for the use of the requested address or
options.
[CCBADPRIM]
The primitive is of an incorrect format or an offset exceeds the size of the M_PROTO
block.

102

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.4.2 Call Control Proceeding Indication

CC PROCEEDING IND
This primitive indicates to the calling CCS user that the call is proceeding to the called CCS user.
This also means that there is sufficient called party address information to complete the call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_proceeding_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_proceeding_ind_t;

/*
/*
/*
/*
/*

always CC_PROCEEDING_IND */
call reference */
proceeding flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. It is used by the CCS provider to indicate the call.

cc flags

Indicates the proceeding flags associated with the proceeding indication. Proceeding
flags are protocol specific (see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the proceeding indication.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI mode (User or Network) or NNI mode.
Valid States
This primitive is valid in state CCS_WREQ_MORE or CCS_WIND_PROCEED.
New State
The new state is CCS_WIND_ALERTING.

2011-10-28

103

Chapter 4: CCI Primitives

4.2.4.3 Call Control Alerting Request

CC ALERTING REQ
This primitive requests that the CCS provider indicate to the calling CCS user that the called CCS
user is being alerted.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_alerting_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_alerting_req_t;

/*
/*
/*
/*
/*

always CC_ALERTING_REQ */
call reference */
alerting flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. It is used by the CCS provider to identify the call.

cc flags

Specifies the alerting flags associated with the alerting request. Alerting flags are
protocol specific (see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the alerting indication.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI mode (User or Network) or NNI mode.
Valid States
This primiitve is valid in states CCS_WREQ_MORE, CCS_WREQ_PROCEED and CCS_WREQ_ALERTING states.
New State
The new state is CCS_WREQ_PROGRESS.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
104

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADFLAG]
The specified flags contained incorrect or unsupported information.
[CCBADOPT]
The optional parameters were in an incorrect format, or contained illegal information.
[CCACCESS]
The user did not have proper permissions for the use of the requested address or
options.
[CCBADPRIM]
The primitive is of an incorrect format or an offset exceeds the size of the M_PROTO
block.

2011-10-28

105

Chapter 4: CCI Primitives

4.2.4.4 Call Control Alerting Indication

CC ALERTING IND
This primitive indicates to the calling CCS user that the called CCS user is being alerted.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_alerting_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_alerting_ind_t;

/*
/*
/*
/*
/*

always CC_ALERTING_IND */
call reference */
alerting flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc flags

Indicates the alerting flags.

cc opt length
Indicates the length of the optional parameters associated with the alerting indication. If no optional parameters are associated with the alerting indication, then this
parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI mode (User or Network) or NNI mode.
Valid States
This primitive is valid in states CCS_WREQ_MORE, CCS_WIND_PROCEED and CCS_WIND_ALERTING.
New State
The new state is CCS_WIND_PROGRESS.

106

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.4.5 Call Control Progress Request

CC PROGRESS REQ
This primitive requests that the CCS provider indicate to the calling CCS user that the call is
progressing towards the called CCS user, with the specified event.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_progress_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_event;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_progress_req_t;

/*
/*
/*
/*
/*
/*

always CC_PROGRESS_REQ */
call reference */
progress event */
progress flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS provider to identify
the call.

cc event

Specifies the progress event. Progress events are protocol specific (see Addendum).

cc flags

Indicates progress flags. Progress flags are protocol specific (see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the progress request. If
no optional parameters are associated with the progress request, then this parameter
must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI mode (User or Network) or NNI mode.
Valid States
This primitive is valid in states CCS_WREQ_PROGRESS.
New State
The new state is CCS_WREQ_PROGRESS.
2011-10-28

107

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADFLAG]
The specified flags contained incorrect or unsupported information.
[CCBADOPT]
The optional parameters were in an incorrect format, or contained illegal information.
[CCACCESS]
The user did not have proper permissions for the use of the requested address or
options.
[CCBADPRIM]
The primitive is of an incorrect format or an offset exceeds the size of the M_PROTO
block.

108

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.4.6 Call Control Progress Indication

CC PROGRESS IND
This primitive indicates to the calling CCS user that the call is progressing towards the called CCS
user with the specified progress event.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_progress_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_event;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_progress_ind_t;

/*
/*
/*
/*
/*
/*

always CC_PROGRESS_IND */
call reference */
progress event */
progress flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc event

Indicates the progress event. Progress events are protocol specific (see Addendum).

cc flags

Indicates progress flags. Progress flags are protocol specific (see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the progress request. If
no optional parameters are associated with the progress request, then this parameter
must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI mode (User or Network) or NNI mode.
Valid States
This primitive is valid instates CCS_WIND_PROGRESS.
New State
The new state is CCS_WIND_PROGRESS.

2011-10-28

109

Chapter 4: CCI Primitives

4.2.4.7 Call Control In-Band Information Request

CC IBI REQ
This primitive request that the CCS provider indicate to the calling CCS user that the in-band
information is now available.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_ibi_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_ibi_req_t;

/*
/*
/*
/*
/*

always CC_IBI_REQ */
call reference */
ibi flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS provider to identify
the call.

cc flags

Specifies the flags associated with the primitive. In band information flags are protocol
specific (see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the in-band information
request. If no optional parameters are associated with the in band information request,
then this parameter must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in NNI mode and in UNI (User and Network) mode for compatibility with
the NNI.
Valid States
This primitive is valid in states CCS_WREQ_MORE, CCS_WREQ_PROCEED, CCS_WREQ_ALERTING, CCS_
WREQ_PROGRESS and CCS_WREQ_CONNECT.
New State
The new state is CCS_WREQ_CONNECT.
110

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADFLAG]
The specified flags contained incorrect or unsupported information.
[CCBADOPT]
The optional parameters were in an incorrect format, or contained illegal information.
[CCACCESS]
The user did not have proper permissions for the use of the requested address or
options.
[CCBADPRIM]
The primitive is of an incorrect format or an offset exceeds the size of the M_PROTO
block.

2011-10-28

111

Chapter 4: CCI Primitives

4.2.4.8 Call Control In-Band Information Indication

CC IBI IND
This primitive indicates to the calling CCS user that there is in-band information now available in
the voice channel.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_ibi_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_ibi_ind_t;

/*
/*
/*
/*
/*

always CC_IBI_IND */
call reference */
ibi flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc flags

Indicates the flags associated with the primitive. In band information flags are provider
and protocol specific (see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the in-band information
indication. If no optional parameters are associated with the in band information
request, then this parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in NNI mode and in UNI (User and Network) mode for compatibility with
the NNI.
Valid States
This primitive is valid in states CCS_WIND_MORE, CCS_WIND_PROCEED, CCS_WIND_ALERTING and CCS_
WIND_PROGRESS.
New State
The new state is CCS_WIND_CONNECT.

112

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.4.9 Call Control Connect Request

CC CONNECT REQ
This primitive requests that the CCS provide indicate to the remote CCS user that the call control
setup has complete and the called CCS use is connected on the call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_connect_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_connect_req_t;

/*
/*
/*
/*
/*

always CC_CONNECT_REQ */
call reference */
connect flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS provider to identify
the call. The call reference is the same value which was indicated in the corresponding
CC_SETUP_IND primitive for the incoming call.

cc flags

Specifies the connect flags associated with the primitive. Connect flags are protocol
specific (see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the connect request. If
no optional parameters are associated with the connect request, then this parameter
must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in NNI mode and in UNI (User) mode.
Valid States
This primitive is only valid for incoming calls in the CCS_WREQ_MORE, CCS_WREQ_PROCEED, CCS_WREQ_
ALERTING, CCS_WREQ_PROGRESS, CCS_WREQ_CONNECT states.
New State
The new state is CCS WIND SCOMP (waiting for indication of setup complete).
2011-10-28

113

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_SETUP_COMPLETE_IND primitive.
Unsuccessful :
Unsuccessful completion is indicated via the CC_CALL_FAILURE_IND,
CC_DISCONNECT_IND or CC_RELEASE_IND primitives.
Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADFLAG]
The specified flags contained incorrect or unsupported information.
[CCBADOPT]
The optional parameters were in an incorrect format, or contained illegal information.
[CCACCESS]
The user did not have proper permissions for the use of the requested address or
options.
[CCBADPRIM]
The primitive is of an incorrect format or an offset exceeds the size of the M_PROTO
block.

114

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.4.10 Call Control Connect Indication

CC CONNECT IND
This primitive indicates that the called CCS user has connected to the call. Upon receving this
primitive the CCS user operating in UNI (Network) mode should connect the calling CCS user to
the call and acknowledge connection of the calling CCS user by responding with the CC_SETUP_
COMPLETE_REQ primitive.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_connect_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_connect_ind_t;

/*
/*
/*
/*
/*

always CC_CONNECT_IND */
call reference */
connect flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call. The call reference is the same value which was indicated in the corresponding
CC_SETUP_CON primitive for the outgoing call.

cc flags

Indicates the connect flags associated with the primitive. Connect flags are protocol
specific (see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the connect indication. If no optional parameters are associated with the connect indication, then this
parameter is coded zero by the CCS provider.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in NNI mode and in UNI (Network) mode.
Valid States
This primitive is valid in state CCS WIND SCOMP.
New State
The new state is CCS_CONNECTED.
2011-10-28

115

Chapter 4: CCI Primitives

4.2.4.11 Call Control Setup Complete Request

CC SETUP COMPLETE REQ
This primitive request that the CCS provider indicate to the remote CCS user that the call control
setup has completed (the calling CCS user is connected) by the requesting CCS user. It is used in
response to the CC_CONNECT_IND primitive.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_setup_complete_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_setup_complete_req_t;

/*
/*
/*
/*

always CC_SETUP_COMPLETE_REQ */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS provider to identify
the call.

cc opt length
Specifies the length of the optional parameters associated with the setup complete
request. If no optional parameters are associated with the setup complete request,
then this parameter must be coded zero. The CCS provider may include additional
protocol-specific optional parameters.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI mode (Network only) and NNI mode for compatibility.
Valid States
This primitive is valid in state CCS WREQ SCOMP.
For compatibility between NNI mode and UNI Network mode, the CCS provider in NNI mode
should acknowledge this primitive with a CC_OK_ACK if it is issued in the CCS_CONNECTED state.
New State
The new state is CCS_CONNECTED.
116

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out of
range).
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

2011-10-28

117

Chapter 4: CCI Primitives

4.2.4.12 Call Control Setup Complete Indication

CC SETUP COMPLETE IND
This primitive indicates to the called CCS user, operating in UNI (User) mode, that the call control
setup was completed (the call is answered and connected) by the calling CCS user. In UNI (User)
mode, the CCS user may defer connecting the receive path to the called CCS user until this message
is received. In response to this primitive, the CCS user should connect the receive path to the called
CCS user and consider the call connected.
CCS users operating in UNI (Network) mode or NNI mode should ignore this primitive if issued by
the CCS provider.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_setup_complete_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_setup_complete_ind_t;

/*
/*
/*
/*

always CC_SETUP_COMPLETE_IND */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitives type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc opt length
Indicates the length of the optional parameters associated with the setup complete indication. If no optional parameters were associated with the setup complete indication,
then this parameter must be coded zero. The CCS provider may include additional
optional protocol-specific optional parameters.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI (User only) mode.
Valid States
This primitive is valid in states CCS WIND SCOMP and CCS_CONNECTED.
New State
The new state is CCS_CONNECTED.

118

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5 Call Established Phase

The following call control service primitives pertain to the Established phase of a call.
4.2.5.1 Forward Transfer Request
CC FORWXFER REQ
This message requests that the CCS provider forward transfer an established call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_forwxfer_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_forwxfer_req_t;

/*
/*
/*
/*

always CC_FORWXFER_REQ */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS provider to identify
the call.

cc opt length
Specifies the length of the optional parameters associated with the forward transfer
request. If no optional parameters were associated with the forward transfer request,
then this parameter must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is only valid in NNI mode.
Valid States
This primitive is valid in state CCS_CONNECTED.
New State
The new state is CCS_CONNECTED.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
2011-10-28

119

Chapter 4: CCI Primitives

Successful : Successful completion is indicated via the CC_OK_ACK primitive.

Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

120

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5.2 Forward Transfer Indication

CC FORWXFER IND
This primitive indicates to the CCS user that the peer CCS user has requested a forward transfer
of an established call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_forwxfer_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_forwxfer_ind_t;

/*
/*
/*
/*

always CC_FORWXFER_IND */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc opt length
Specifies the length of the optional parameters associated with the forward transfer
indication. If no optional parameters were associated with the forward transfer indication, then this parameter must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in NNI mode only.
Valid States
This primitive is valid in state CCS_CONNECTED.
New State
The new state is CCS_CONNECTED.

2011-10-28

121

Chapter 4: CCI Primitives

4.2.5.3 Call Control Suspend Request

CC SUSPEND REQ
This message requests that the CCS provider suspend an established call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_suspend_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_suspend_req_t;

/*
/*
/*
/*
/*

always CC_SUSPEND_REQ */
call reference */
suspend flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS provider to identify
the call.

cc flags

Specifies the suspend flags associated with the suspend request. Suspend flags specify
whether the request is for a user suspend or a network suspend. Suspend flags are
provider and protocol specific (see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the suspend request. If
no optional parameters were associated with the suspend request, then this parameter
must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in mode UNI (User) and NNI.
Valid States
This primitive is valid in state CCS_CONNECTED.
New State
The new state is CCS_SUSPENDED.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
122

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Successful : Successful completion is indicated via the CC_SUSPEND_CON primitive.

Unsuccessful : Unsuccessful completion is indicated via the CC_SUSPEND_REJECT_IND or CC_
RELEASE_IND primitive. The cause value in the CC_SUSPEND_REJECT_IND or CC_RELEASE_IND
primitive indicates the cause of failure.
Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

2011-10-28

123

Chapter 4: CCI Primitives

4.2.5.4 Call Control Suspend Indication

CC SUSPEND IND
This message indicates to the CCS user that the peer CCS user has requested the suspension of an
establisehd call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_suspend_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_suspend_ind_t;

/*
/*
/*
/*
/*

always CC_SUSPEND_IND */
call reference */
suspend flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc flags

Indicates the options associated with the suspend. Suspend flags are mode and protocol
dependent, see the addendum. Indicates the suspend flags associated with the suspend
indication. Suspend flags indicate whether the request is for a user suspend or a network
suspend. Suspend flags are provider and protocol specific (see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the suspend indication. If no optional parameters were associated with the suspend indication, then this
parameter must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in mode UNI (Network) and NNI.
Valid States
This primitive is valid in state CCS_CONNECTED or CCS_SUSPENDED.
New State
The new state is CCS WRES SUSIND for UNI and CCS_SUSPENDED for NNI.

124

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5.5 Call Control Suspend Response

CC SUSPEND RES
This message requests that the CCS provider accept a previous suspend indication.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_suspend_res {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_suspend_res_t;

/*
/*
/*
/*

always CC_SUSPEND_RES */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS provider to identify
the call.

cc opt length
Specifies the length of the optional parameters associated with the suspend response. If
no optional parameters were associated with the suspend response, then this parameter
must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in mode UNI (Network).
Valid States
This primitive is valid in state CCS WRES SUSIND.
New State
The new state is CCS_SUSPENDED.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
2011-10-28

125

Chapter 4: CCI Primitives

[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

126

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5.6 Call Control Suspend Confirmation

CC SUSPEND CON
This message indicates to the CCS user that the CCS provider has confirmed the CCS user request
to suspend an established call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_suspend_con {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_suspend_con_t;

/*
/*
/*
/*

always CC_SUSPEND_CON */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc opt length
Indicates the length of the optional parameters associated with the suspend indication. If no optional parameters were associated with the suspend indication, then this
parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in mode UNI (User).
Valid States
This primitive is valid in state CCS_WCON_SUSREQ.
New State
The new state is CCS_SUSPENDED.

2011-10-28

127

Chapter 4: CCI Primitives

4.2.5.7 Call Control Suspend Reject Request

CC SUSPEND REJECT REQ
This message request that the CCS provider reject a previous suspend indication with the specified
cause.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_suspend_reject_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_suspend_reject_req_t;

/*
/*
/*
/*
/*

always CC_SUSPEND_REJECT_REQ */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS user to identify the
call. Its value should be the same as the value returned by the CCS provider in the
CC_SETUP_IND or CC_SETUP_CON primitive.

cc cause

Indicates the cause for the rejection. Cause values are provider and protocol specific
(see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the suspend reject request. If no optional parameters are associated with the suspend reject request, then
this parameter must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameter are associated with the suspend reject request, then
this parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (Network).
Valid States
This primitive is valid in state CCS WRES SUSIND.
New State
The new state is CCS_CONNECTED if the call is not still suspended in the opposite direction or another
sense (network or user), otherwise the new state remains CCS_SUSPENDED.
128

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

2011-10-28

129

Chapter 4: CCI Primitives

4.2.5.8 Call Control Suspend Reject Confirmation

CC SUSPEND REJECT IND
This message indicates to the requesting CCS user that a previous suspend request for an established
call was rejected and the cause for rejection.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_suspend_reject_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_suspend_reject_ind_t;

/*
/*
/*
/*
/*

always CC_SUSPEND_REJECT_IND */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc cause

Indicates the cause for the rejection. Cause values are provider and protocol specific
(see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the suspend reject
indication. If no optional parameters are associated with the suspend reject indication,
then this parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameter are associated with the suspend reject indication, then
this parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (User).
Valid States
This primitive is valid in state CCS_WCON_SUSREQ.
New State
The new state is CCS_CONNECTED if the call is not still suspended in the opposite direction or another
sense (network or user), otherwise the new state remains CCS_SUSPENDED.

130

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5.9 Call Control Resume Request

CC RESUME REQ
This message requests that the CCS provider resume a previously suspended call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_resume_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_resume_req_t;

/*
/*
/*
/*
/*

always CC_RESUME_REQ */
call reference */
suspend flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS user to identify the
call to the CCS provider. The value should be the same as the value indicated by the
CCS provider in a previous CC_SETUP_IND or CC_SETUP_CON primitive.

cc flags

Specifies the options associated with the resume. Resume flags are provider and protocol dependent (see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the resume request. If
no optional parameters are associated with the resume request, then this parameter
must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameter are associated with the resume request, then this
parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (User) and NNI.
Valid States
This primitive is valid in state CCS_SUSPENDED.
New State
The new state is CCS_CONNECTED if the call is not still suspended in the opposite direction or another
sense (network or user), otherwise the new state remains CCS_SUSPENDED.
2011-10-28

131

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

132

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5.10 Call Control Resume Indication

CC RESUME IND
This message indicates to the CCS user that the peer CCS user has requested that a previously
suspended call be resumed.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_resume_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_flags;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_resume_ind_t;

/*
/*
/*
/*
/*

always CC_RESUME_IND */
call reference */
suspend flags */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc flags

Indicates the options associated with the resume. Resume flags are mode and protocol
dependent, see the addendum.

cc opt length
Indicates the length of the optional parameters associated with the resume indication. If no optional parameters are associated with the resume indication, then this
parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameter are associated with the resume indication, then this
parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (Network) and NNI.
Valid States
This primitive is valid in state CCS_SUSPENDED.
New State
The new state is CCS_CONNECTED if the call is not still suspended in the opposite direction or in
another sense (network or user), otherwise the new state remains CCS_SUSPENDED.

2011-10-28

133

Chapter 4: CCI Primitives

4.2.5.11 Call Control Resume Response

CC RESUME RES
This message requests that the CCS provider accept a previous request to resume a suspended call.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_resume_res {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_resume_res_t;

/*
/*
/*
/*

always CC_RESUME_RES */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS user to identify the
call to the CCS provider. Its value should be the same as the value indicated by a
previous CC_SETUP_IND or CC_SETUP_CON primitive for the call.

cc opt length
Specifies the length of the optional parameters associated with the resume response. If
no optional parameters are associated with the resume response, then this parameter
must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameter are associated with the resume response, then this
parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (Network) and for compatibility in NNI mode.
Valid States
This primitive is valid in state CCS WRES SUSIND.
For compatibility with UNI, NNI should ignore, yet positively acknowledge, this primitive if received
in the CCS_CONNECTED or CCS_SUSPENDED states where the all is not suspended in the sense confirmed.
New State
The new state is CCS_CONNECTED if the call is not still suspended in the opposite direction or another
sense (network or user), otherwise the new state remains CCS_SUSPENDED.
134

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

2011-10-28

135

Chapter 4: CCI Primitives

4.2.5.12 Call Control Resume Confirmation

CC RESUME CON
This message indicates to the requesting CCS user that a previous request to resume a suspended
call has been confirmed.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_resume_con {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_resume_con_t;

/*
/*
/*
/*

always CC_RESUME_CON */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc opt length
Indicates the length of the optional parameters associated with the resume confirmation. If no optional parameters are associated with the resume confirmation, then this
parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameter are associated with the resume confirmation, then this
parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (User).
Valid States
This primitive is valid in state CCS_WCON_SUSREQ.
New State
The new state is CCS_CONNECTED if the call is not still suspended in the opposite direction or another
sense (network or user), otherwise the new state remains CCS_SUSPENDED.

136

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5.13 Call Control Resume Reject Request

CC RESUME REJECT REQ
This message requests that the CCS provider reject a previous requst to resume a suspended call
with the specified cause.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_resume_reject_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_resume_reject_req_t;

/*
/*
/*
/*
/*

always CC_RESUME_REJECT_REQ */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference. The call reference is used by the CCS user to identify the
call to the CCS provider. Its value should be the same as the value indicated in a
previous CC_SETUP_IND or CC_SETUP_CON primitive by the CCS provider for the call.

cc cause

Indicates the cause for the rejection. Cause values are provider and protocol specific
(see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the resume reject request. If no optional parameters are associated with the resume reject request, then
this parameter must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameters are associated with the resume reject request, then
this parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (Network).
Valid States
This primitive is valid in state CCS WRES SUSIND.
New State
The new state is CCS_SUSPENDED.
2011-10-28

137

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

138

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.5.14 Call Control Resume Reject Indication

CC RESUME REJECT IND
This message indicates to the requesting CCS user that a previous request to resume a suspended
call has been rejected and the cause for rejection.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_resume_reject_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_resume_reject_ind_t;

/*
/*
/*
/*
/*

always CC_RESUME_REJECT_IND */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc cause

Indicates the cause for the rejection. Cause values are provider and protocol specific
(see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the resume reject indication. If no optional parameters are associated with the resume reject indication,
then this parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameters are associated with the resume reject indication, then
this parameter must be coded zero.
Valid Modes
This primitive is valid in mode UNI (User).
Valid States
This primitive is valid in state CCS_WCON_SUSREQ.
New State
The new state is CCS_SUSPENDED.

2011-10-28

139

Chapter 4: CCI Primitives

4.2.6 Call Termination Phase

The following call control service primitives pertain to the Termination phase of a call.
4.2.6.1 Call Control Reject Request
CC REJECT REQ
This message is used to reject a call before any request for more information, or request for indication
of proceeding, alerting, progress, or in-band information has been attempted. The message also
includes the cause of the rejection.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_reject_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_reject_req_t;

/*
/*
/*
/*
/*

always CC_REJECT_REQ */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc call ref

Specifies the call reference of the CC_SETUP_IND when the CC_REJECT_REQ primitive is
used in response to the CC_SETUP_IND on a listening stream. Otherwise, this parameter
is coded zero and is ignored by the CCS provider.

cc cause

Specifies the cause for the rejection. Cause values are provider and protocol specific
(see Addendum).

cc opt length
Specifies the length of the optional parameters associated with the reject request. If no
optional parameters are associated with the reject request, then this parameter must
be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameters are associated with the reject request, then this
parameter must be coded zero.
Valid Modes
This primitive is only valid in the UNI mode (User or Network). (NNI users should use the CC_
RELEASE_REQ primitive in the same situation.)
Valid State
This primitive is valid in state CCS_WRES_SIND.
140

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

New State
The new state is CCS_IDLE.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

2011-10-28

141

Chapter 4: CCI Primitives

4.2.6.2 Call Control Reject Indication

CC REJECT IND
This message indicates to the CCS user that a previous setup request has been rejected by the peer
CCS user and indicates the cause of the rejection.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_reject_ind {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_reject_ind_t;

/*
/*
/*
/*
/*

always CC_REJECT_IND */
user call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc user ref

Indicates the CCS user reference of the associated CC_SETUP_REQ primitive that was
rejected.

cc cause

Indicates the cause for the rejection. Cause values are provider and protocol specific
(see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the reject indication. If
no optional parameters are associated with the reject indication, then this parameter
must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameters are associated with the reject indication, then this
parameter must be coded zero.
Valid Modes
This primitive is only valid in the UNI mode (User or Network).
Valid State
This primitive is valid in state CCS_WCON_SREQ.
New State
The new state is CCS_IDLE.

142

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.6.3 Call Control Call Failure Indication

CC CALL FAILURE IND
This primitive indicates to the CCS user that the call on the selected address (circuit, circuit group)
has failed.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_call_failure_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_reason;
ulong cc_cause;
} CC_call_failure_ind_t;

/*
/*
/*
/*

always CC_CALL_FAILURE_IND */
call reference */
reason for failure */
cause to use in release */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc reason

Indicates the reason for the failure. Reasons are provider and protocol specific (see
Addendum).

cc cause

Indicates the cause value for the failure. Cause values are provider and protocol specific
(see Addendum).

cc opt length
Indicates the length of the optional parameters associated with the call failure indication. If no optional parameters are associated with the call failure indication, then this
parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block. If no optional parameters are associated with the call failure indication, then
this parameter must be coded zero.
Valid Modes
This primitive is valid in NNI mode only.
Valid States
This primitive is valid in any state other than CCS_IDLE, CCS_WIND_MORE, CCS_WREQ_INFO, CCS_
WCON_SREQ, and CCS_WIND_PROCEED. In the aforementioned states (other than CCS_IDLE), a CC_
CALL_REATTEMPT_IND should be issued instead.
New State
The new state is CCS_IDLE.
2011-10-28

143

Chapter 4: CCI Primitives

4.2.6.4 Call Control Disconnect Request

CC DISCONNECT REQ
This primitive request that the CCS provider indicate to the calling CCS user that in-band information may now be available in the voice channel reflecting the specified cause. The CC_DISCONNECT_
REQ primitive is an invitation to the remote CCS user to release the call channel.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_disconnect_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_disconnect_req_t;

/*
/*
/*
/*
/*

always CC_DISCONNECT_REQ */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference of the CC_DISCONNECT_REQ message. It is used by the

CCS provider to associated the CC_DISCONNECT_REQ message with an outstanding CC_
SETUP_IND message. An invalid call reference should result in error with the error type
[CCBADCLR].

cc cause

Indicates the cause value for the disconnect.

cc opt length
Indicates the length of the optional parameters associated with the disconnect request.
If no optional parameters are associated with the disconnect request, then this parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid only in UNI (Network or User) mode.
Valid States
This primitive is valid in states CCS_WREQ_MORE, CCS_WREQ_PROCEED, CCS_WREQ_ALERTING and CCS_
WREQ_PROGRESS.
New State
The new state is CCS_WREQ_CONNECT.
144

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

2011-10-28

145

Chapter 4: CCI Primitives

4.2.6.5 Call Control Disconnect Indication

CC DISCONNECT IND
This primitive indicates to the calling CCS user that there is in-band information now available in
the voice channel.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_disconnect_ind {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_disconnect_ind_t;

/*
/*
/*
/*
/*

always CC_DISCONNECT_IND */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference. The call reference is used by the CCS provider to identify
the call.

cc cause

Indicates the cause value for the disconnect.

cc opt length
Indicates the length of the optional parameters associated with the in-band information
request. If no optional parameters are associated with the in band information request,
then this parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid States
This primitive is valid in states CCS_WIND_MORE, CCS_WREQ_INFO, CCS_WIND_PROCEED, CCS_WIND_
ALERTING, CCS_WIND_PROGRESS and CCS_WIND_CONNECT.
New State
The new state is CCS_WIND_CONNECT

146

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.6.6 Call Control Release Request

CC RELEASE REQ
This primitive request that the CCS provider release the call and provide the specified cause value
to the remote CCS user.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_release_req {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_release_req_t;

/*
/*
/*
/*
/*
/*

always CC_RELEASE_REQ */
user call reference */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc user ref

Specifies the user call reference of the CC_SETUP_REQ when the CC_RELEASE_REQ primitive is used in response to the CC_SETUP_REQ and before a CC_SETUP_CON is issued.
Otherwise, this parameter is coded zero and is ignored by the CCS provider.

cc call ref

Specifies the call reference of the CC_SETUP_IND when the CC_RELEASE_REQ primitive is
used in response to the CC_SETUP_IND on a listening stream. Otherwise, this parameter
is coded zero and is ignored by the CCS provider.

cc cause

Specifies the cause of the release. Cause values are CCS provider and protocol specific.
See the addendum for protocol specific values.

cc opt length
Specifies the length of the optional parameters associated with the release request. If
no optional parameters are associated with the release request, then this parameter
must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI (User or Network) and NNI modes.
Valid States
This primitive is valid from any call state other than CCS_IDLE and CCS_WCON_RELREQ.
2011-10-28

147

Chapter 4: CCI Primitives

New State
If the current state is CCS_WRES_RELIND, the new state is CCS_IDLE. If the current state is other
than CCS_WRES_RELIND, the new state is CCS_WCON_RELREQ.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_RELEASE_IND or CC_RELEASE_CON
primitives.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCBADPRIM]
The primitive was of an incorrect format (i.e. too small, or an offset it out
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADOPT]
The options values as specified in the primitive were in an incorrect format, or
they contained illegal information.
[CCACCESS]
The user did not have proper permissions to request the operation or to use the
options specified.
[CCNOTSUPP]
The specified primitive type is not known to or not supported by the CCS provider.

148

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.6.7 Call Control Release Indication

CC RELEASE IND
This primitive indicates that the remote CCS user or CCS provider hsa released the call with the
specified cause value.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_release_ind {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_call_ref;
ulong cc_cause;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_release_ind_t;

/*
/*
/*
/*
/*
/*

always CC_RELEASE_IND */
user call reference */
call reference */
cause value */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc user ref

Indicates the user call reference of the CC_SETUP_REQ when the CC_RELEASE_IND primitive is used in response to the CC_SETUP_REQ and before a CC_SETUP_CON is issued.
Otherwise, this parameter is coded zero and is ignored by the CCS provider.

cc call ref

Indicates the call reference of the CC_SETUP_IND when the CC_RELEASE_IND primitive is
used in response to the CC_SETUP_IND on a listening stream. Otherwise, this parameter
is coded zero and is ignored by the CCS provider.

cc cause

Indicates the cause of the release. Cause values are CCS provider and protocol specific.
See the addendum for protocol specific values.

cc opt length
Indicates the length of the optional parameters associated with the release indication. If
no optional parameters are associated with the release indication, then this parameter
must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI (User or Network) and NNI modes.
Valid States
This primitive is valid in any setup or established call state other than CCS_IDLE and CCS_WRES_
RELIND.
2011-10-28

149

Chapter 4: CCI Primitives

New State
If the current state is CCS_WCON_RELREQ, the new state is CCS_IDLE. If the current state is other
than CCS_WCON_RELREQ, then new state is CCS_WRES_RELIND.

150

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.6.8 Call Control Release Response

CC RELEASE RES
This primitive indicates to the CCS provider that the release of the associated circuit is complete.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_release_res {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_release_res_t;

/*
/*
/*
/*
/*

always CC_RELEASE_RES */
user call reference */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Specifies the primitive type.
cc user ref

cc call ref

cc opt length
Specifies the length of the optional parameters associated with the release response. If
no optional parameters are associated with the release response, then this parameter
must be coded zero.
cc opt offset
Specifies the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI (User or Network) and NNI modes.
Valid States
This primitive is valid in state CCS_WRES_RELIND.
New State
The new state is CCS_IDLE.
2011-10-28

151

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

152

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.2.6.9 Call Control Release Confirmation

CC RELEASE CON
This primitive indicates to the releasing CCS user that the release of the associated circuit is complete.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_release_con {
ulong cc_primitive;
ulong cc_user_ref;
ulong cc_call_ref;
ulong cc_opt_length;
ulong cc_opt_offset;
} CC_release_con_t;

/*
/*
/*
/*
/*

always CC_RELEASE_CON */
user call reference */
call reference */
optional parameter length */
optional parameter offset */

Parameters
cc primitive
Indicates the primitive type.
cc user ref

cc call ref

cc opt length
Indicates the length of the optional parameters associated with the release confirmation. If no optional parameters are associated with the release confirmation, then this
parameter must be coded zero.
cc opt offset
Indicates the offset of the optional parameters from the start of the M_PROTO message
block.
Valid Modes
This primitive is valid in UNI (User or Network) and NNI modes.
Valid States
This primitive is valid in state CCS_WCON_RELREQ.
New State
The new state is CCS_IDLE.

2011-10-28

153

Chapter 4: CCI Primitives

4.3 Management Primitive Formats and Rules

This section describes the format of the UNI (Network and User) and NNI management primitives
and rules associated with these primitives.
4.3.1 Interface Management Primitives
4.3.1.1 Interface Management Restart Request
CC RESTART REQ
This primitive request the CCS provider to restart all the call control addresses (signalling interface
and channels) for the specified UNI interface.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_restart_req {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_restart_req_t;

/*
/*
/*
/*

always CC_RESTART_REQ */
restart flags */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Indicates the length of the call control address (signalling interface and circuit identifiers) upon which a restart was requested. The semantics of the values in the CC_
RESET_REQ is identical to the values in the CC_BIND_REQ.
cc addr offset
Indicates the offset of the reporting address from the beginning of the M_PROTO message
block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.

154

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.1.2 Interface Management Restart Confirmation

CC RESTART CON
This primitive confirms to the requesting CCS user that the restart of the requested call control
addresses (signalling interface and channels) for the specified UNI interface is complete.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_restart_ind {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_restart_ind_t;

/*
/*
/*
/*

always CC_RESTART_IND */
restart flags */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

2011-10-28

155

Chapter 4: CCI Primitives

4.3.2 Circuit Management Primitives

4.3.2.1 Circuit Management Reset Request
CC RESET REQ
This primitive requests that the CCS provider reset the specified call control address(es) (signalling
interface and circuit identifiers) with the CCS user peer. For the NNI this primitive supports both
the Circuit Reset Service as well as the Circuit Group Reset Service.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_reset_req {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_reset_req_t;

/*
/*
/*
/*

always CC_RESET_REQ */
reset flags */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Indicates the length of the call control address (signalling interface and circuit identifiers) upon which a reset is requested. The semantics of the values in the CC_RESET_REQ
is identical to the values in the CC_BIND_REQ.
cc addr offset
Indicates the offset of the reporting address from the beginning of the M_PROTO message
block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Rules
The following rules apply to the reset of call control addresses (signalling interface and circuit
identifiers):
The call control address must contain a signalling interface identifier and one or more circuit
identifiers.
The signalling interface identifier must identify an NNI signalling interface.
When the call control address contains one circuit identifier, a non-group reset will be performed.
When the call control address contains more than one circuit identifier, the CCS provider may
either issue individual circuit resets, or may issue one or more group circuit resets.
156

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Valid Modes
This primitive is only valid for call control address(es) in the NNI mode.
Valid States
This primitive is valid in state CCS_IDLE for the requested address(es).
New State
The new state is CCS WCON RESREQ for the specified address(es).
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_RESET_CON primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCACCESS]
The user did not have sufficient permission to perform the operation on the specified call control addresses.
[CCNOADDR]
The call control address was not provided (cc addr length coded zero).
[CCBADADDR]
The call control address(es) contained in the primitive were poorly formatted or
contained invalid information.
[CCNOTSUPP]
The primitive is not supported for the UNI interface and a UNI signalling interface
identifier was provided in the call control address.
[CCOUTSTATE]
The primitive was issued from an invalid state for the requested address(es).
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

2011-10-28

157

Chapter 4: CCI Primitives

4.3.2.2 Circuit Management Reset Indication

CC RESET IND
This primitive indicates that the peer CCS user has requested that the specified call control address(es) (signalling interface and circuit identifiers) be reset.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_reset_ind {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_reset_ind_t;

/*
/*
/*
/*

always CC_RESET_IND */
reset flags */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Indicates the length of the call control address(es) (signalling interface and circuit
identifiers) that the peer CCS user has requested be reset.
cc addr offset
Indicates the offset of the call control address(es) (signalling interface and circuit identifiers) from the beginning of the M_PROTO message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will not be issued for call control addresses in modes other than NNI mode.
Valid States
This primitive will only be issued for call control addresses for which no reset indication (CCS_IDLE)
is already pending.
New State
The new state is CCS WRES RESIND.

158

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.3 Circuit Management Reset Response

CC RESET RES
This primitive request the CCS provider to complete the reset operation for the specified call control
address(es) (signalling interface and circuit identifiers) which was previously indicated with a CC_
RESET_IND.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_reset_res {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_reset_res_t;

/*
/*
/*
/*

always CC_RESET_RES */
reset flags */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc flags

Indicates options flags for the operation. (See "Flags" below.)

cc addr length
Indicates the length of the call control address(es) (signalling interface and circuit
identifiers) upon which the CCS user has accepted a reset.
cc addr offset
Indicates the offset of the call control address(es) (signalling interface and circuit identifiers) from the beginning of the M_PROTO message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Rules
The following rules apply to the reset of call control addresses (signalling interface and circuit
identifiers):
The set of addresses specified must be a non-empty subset of the addresses which were specified
in the indication primitive to which this primitive is responding.
Only once the primitive is successfully accepted by the CCS provider should the CCS provider
take any actions whatsoever with regard to reset.
Call control addresses included in the call control address list which are not equipped may be
ignored by the CCS provider.
Valid States
This primitive is valid in state CCS WRES RESIND for the specified address(es).
2011-10-28

159

Chapter 4: CCI Primitives

New State
The new state is CCS WACK RESRES for the specified address(es).
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCACCESS]
The user did not have sufficient permission to perform the operation on the specified call control addresses.
[CCNOADDR]
The call control address was not provided (cc addr length coded zero).
[CCBADADDR]
The call control address(es) contained in the primitive were poorly formatted or
contained invalid information.
[CCNOTSUPP]
The primitive is not supported for the UNI interface and a UNI signalling interface
identifier was provided in the call control address.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

160

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.4 Circuit Management Reset Confirmation

CC RESET CON
This primitive confirms to the requesting CCS user that the specified call control address(es) (signalling interface and circuit identifiers) have been successfully confirmed reset to the peer CCS
user.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_reset_con {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_reset_con_t;

/*
/*
/*
/*

always CC_RESET_CON */
reset flags */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Indicates the length of the call control address(es) (signalling interface and circuit
identifiers) upon which the CCS provider has confirmed a reset.
cc addr offset
Indicates the offset of the call control address(es) (signalling interface and circuit identifiers) from the beginning of the M_PROTO message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will only be issued by the CCS provider for call control addresses in the NNI mode.
Valid States
This primitive is valid in state CCS WCON RESREQ for the specified addresses.
New State
The new state is CCS_IDLE for the specified addresses.

2011-10-28

161

Chapter 4: CCI Primitives

4.3.2.5 Circuit Management Blocking Request

CC BLOCKING REQ
This primitive request that the CCS provider locally block the specified call control address(es)
(signalling interface and circuit or circuit group) with the peer CCS user. For the NNI, this primitive
supports both the Circuit Blocking Service as well as the Circuit Group Blocking Service.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_blocking_req {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_blocking_req_t;

/*
/*
/*
/*

always CC_BLOCKING_REQ */
blocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) upon which local blocking is requested. The semantics of the values
in the call control address is described in Section 2.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Rules
The following rules apply to the blocking of call control addresses (signalling interface and circuit
or circuit group identifiers):
If the stream upon which the blocking request is issued is not bound (see CC_BIND_REQ), the
call control address must contain a signalling interface identifier and a circuit or circuit group
identifier.
If the stream upon which the blocking request is bound to a signalling interface and trunk
group, and no call control address(es) are provided (i.e, cc addr length is set to zero), the CCS
provider may interpret the primitive to be requesting blocking on all circuits in the trunk group.
At any time that the primitive is issued without specifying a call control address (i.e,
cc addr length is zero to zero), the CCS provider may assign a call control address or
addresses.
162

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

If the CCS provider fails to assign a call control address or addresses, the primitive will fail
with error [CCNOADDR].
Valid Modes
This primitive is only valid for call control address(es) (signalling interfaces) in the NNI mode.
Valid States
This primitive is valid in state CCS_IDLE for the requested address(es).
New State
The new state is CCS WCON BLREQ for the specified address(es).
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive.
Successful : Successful completion is indicated via the CC_BLOCKING_CON primitive.
Unsuccessful : Unsuccessful completion is indicated via the CC_RELEASE_IND or CC_RESET_IND
primitive.
Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCACCESS]
The user did not have sufficient permission to invoke the operation on the specified
addresses.
[CCFLAGS]

The flags were invalid or unsupported.

[CCNOADDR]
An address or addresses was not provided by the CCS user (i.e., cc addr length
set to zero) and the CCS provider could not assign an address or addresses.
[CCBADADDR]
The call control address contained in the primitive were illegally formatted or
contained invalid information.
[CCNOTSUPP]
The primitive is not supported for the UNI interface and a UNI signalling interface
identifier was provided in the call control address.
[CCOUTSTATE]
The primitive was issued from an invalid state for the requested address(es).
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

2011-10-28

163

Chapter 4: CCI Primitives

4.3.2.6 Circuit Management Blocking Indication

CC BLOCKING IND
This primitive indicates that the peer CCS user has requested that the specified call control address(es) (signalling interface and circuit identifiers) be remotely blocked.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_blocking_ind {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_blocking_ind_t;

/*
/*
/*
/*

always CC_BLOCKING_IND */
blocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies the options flags. See "Flags" below.

cc addr length
Indicates the length of the call control address(es) (signalling interface and circuit
identifiers) that the peer CCS user has requested to be remotely blocked.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will only be issued by the CCS provider for signalling interfaces in the NNI mode.
Valid States
This primitive will only be issued by the CCS provider if the remote blocking state of the specified
address(es) is CCS UNBLOCKED or CCS BLOCKED.
New State
The new remote blocking state will be CCS WRES BLIND for the specified call control addresses.

164

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.7 Circuit Management Blocking Response

CC BLOCKING RES
This primitive requests that the CCS provider respond to the previous blocking indication.
Format
The format is one M_PROTO message block. The structure of the M_PROTO message block is as follows:
typedef struct CC_blocking_res {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_blocking_res_t;

/*
/*
/*
/*

always CC_BLOCKING_RES */
blocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) upon which local blocking is requested. The semantics of the values
in the call control address is described in Section 2.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive is only valid for indications for signalling interfaces in the NNI mode.
Valid States
This primitive is only valid for the previous CC_BLOCKING_IND (call control addresses in the
CCS WRES BLIND state).
New State
The new blocking state of the previously specified call control addresses is the CCS BLOCKED
state.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
2011-10-28

165

Chapter 4: CCI Primitives

Successful : Successful completion is indicated via the CC_OK_ACK primitive.

Unsuccessful :
Unsuccessful
CCS RESET IND primitive.

completion

indicated

via

the

CC_RELEASE_IND

Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCACCESS]
The user did not have sufficient permission to invoke the operation.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.

166

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.8 Circuit Management Blocking Confirmation

CC BLOCKING CON
This primitive confirms a previous blocking request (or indicates failure of a previous blocking
request).
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_blocking_con {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_blocking_con_t;

/*
/*
/*
/*

always CC_BLOCKING_CON */
blocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies the options flags and result of the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) for which local blocking is confirmed.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will only be issued by the CCS provider for signalling interfaces in the NNI mode.
Valid States
This primitive will only be issued by the CCS provider if the local blocking state of the specified
address(es) is CCS WCON BLREQ.
New State
The new local blocking state will be CCS BLOCKED for the specified call control addresses.

2011-10-28

167

Chapter 4: CCI Primitives

4.3.2.9 Circuit Management Unblocking Request

CC UNBLOCKING REQ
This primitive requests that the CCS provider locally unblock the specified call control address(es)
(signalling interface and circuit or circuit group) with the peer CCS user. For the NNI, this primitive
supports both Circuit Unblocking Service as well as the Circuit Group Unblocking Service.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_unblocking_req {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_unblocking_req_t;

/*
/*
/*
/*

always CC_UNBLOCKING_REQ */
unblocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) upon which local unblocking is requested. The semantics of the values
in the call control address is described in Section 2.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Rules
The following rules apply to the unblocking of call control addresses (signalling interface and circuit
or circuit group identifiers):
If the stream upon which the unblocking request is issued is not bound (see CC_BIND_REQ), the
call control address must contain a signalling interface identifier and a circuit or circuit group
identifier.
If the stream upon which the unblocking request is bound to a signalling interface and trunk
group, and no call control address(es) are provided (i.e, cc addr length is set to zero), the CCS
provider may interpret the primitive to be requesting unblocking on all circuits in the trunk
group.
168

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

At any time that the primitive is issued without specifying a call control address (i.e,
cc addr length is zero to zero), the CCS provider may assign a call control address or
addresses.
If the CCS provider fails to assign a call control address or addresses, the primitive will fail
with error [CCNOADDR].
Valid Modes
This primitive is only valid for call control address(es) (signalling interfaces) in the NNI mode.
Valid States
This primitive is valid in state CCS_IDLE for the requested address(es).
New State
The new state is CCS WCON BLREQ for the specified address(es).
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive.
Successful : Successful completion is indicated via the CC_BLOCKING_CON primitive.
Unsuccessful : Unsuccessful completion is indicated via the CC_RELEASE_IND or CC_RESET_IND
primitive.
Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCACCESS]
The user did not have sufficient permission to invoke the operation on the specified
addresses.
[CCFLAGS]

The flags were invalid or unsupported.

2011-10-28

169

Chapter 4: CCI Primitives

4.3.2.10 Circuit Management Unblocking Indication

CC UNBLOCKING IND
This primitive indicates that the peer CCS user has requested that the specified call control address(es) (signalling interface and circuit identifiers) be remotely unblocked.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_unblocking_ind {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_unblocking_ind_t;

/*
/*
/*
/*

always CC_UNBLOCKING_IND */
unblocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies the options flags. See "Flags" below.

cc addr length
\Indicates the length of the call control address(es) (signalling interface and circuit
identifiers) that the peer CCS user has requested to be remotely unblocked.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will only be issued by the CCS provider for signalling interfaces in the NNI mode.
Valid States
This primitive will only be issued by the CCS provider if the remote blocking state of the specified
address(es) is CCS UNBLOCKED or CCS BLOCKED.
New State
The new remote blocking state will be CCS WRES UBIND for the specified call control addresses.

170

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.11 Circuit Management Unblocking Response

CC UNBLOCKING RES
This primitive requests that the CCS provider respond to the previous unblocking indication.
Format
The format is one M_PROTO message block. The structure of the M_PROTO message block is as follows:
typedef struct CC_unblocking_res {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_unblocking_res_t;

/*
/*
/*
/*

always CC_UNBLOCKING_RES */
blocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) upon which local unblocking is requested. The semantics of the values
in the call control address is described in Section 2.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive is only valid for indications for signalling interfaces in the NNI mode.
Valid States
This primitive is only valid for the previous CC_BLOCKING_IND (call control addresses in the
CCS WRES BLIND state).
New State
The new blocking state of the previously specified call control addresses is the CCS UNBLOCKED
state.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
2011-10-28

171

Chapter 4: CCI Primitives

Successful : Successful completion is indicated via the CC_OK_ACK primitive.

Unsuccessful :
Unsuccessful
CCS RESET IND primitive.

completion

indicated

via

the

CC_RELEASE_IND

172

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.12 Circuit Management Unblocking Confirmation

CC UNBLOCKING CON
This primitive confirms a previous unblocking request (or indicates failure of a previous unblocking
request).
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_unblocking_con {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_unblocking_con_t;

/*
/*
/*
/*

always CC_UNBLOCKING_CON */
unblocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies the options flags and result of the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) for which local unblocking is confirmed.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will only be issued by the CCS provider for signalling interfaces in the NNI mode.
Valid States
This primitive will only be issued by the CCS provider if the local unblocking state of the specified
address(es) is CCS WCON UBREQ.
New State
The new local unblocking state will be CCS UNBLOCKED for the specified call control addresses.

2011-10-28

173

Chapter 4: CCI Primitives

4.3.2.13 Circuit Management Query Request

CC QUERY REQ
This primitive requests that the CCS provider query specified call control address(es) (signalling
interface and circuit or circuit group) to the peer CCS user. For the NNI, this primitive supports
the Circuit Group Query Service.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_query_req {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_query_req_t;

/*
/*
/*
/*

always CC_QUERY_REQ */
query flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) upon which the query is requested. The semantics of the values in
the call control address is described in Section 2.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Rules
The following rules apply to the querying of call control addresses (signalling interface and circuit
or circuit group identifiers):
If the stream upon which the query request is issued is not bound (see CC_BIND_REQ), the
call control address must contain a signalling interface identifier and a circuit or circuit group
identifier.
If the stream upon which the query request is bound to a signalling interface and trunk group,
and no call control address(es) are provided (i.e, cc addr length is set to zero), the CCS provider
may interpret the primitive to be requesting status on all circuits in the trunk group.
At any time that the primitive is issued without specifying a call control address (i.e,
cc addr length is zero to zero), the CCS provider may assign a call control address or
addresses.
174

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

The flags were invalid or unsupported.

2011-10-28

175

Chapter 4: CCI Primitives

4.3.2.14 Circuit Management Query Indication

CC QUERY IND
This primitive indicates that the peer CCS user has requested that the specified call control address(es) (signalling interface and circuit identifiers) be queried.
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO message
block is as follows:
typedef struct CC_query_ind {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_query_ind_t;

/*
/*
/*
/*

always CC_QUERY_IND */
query flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies the options flags. See "Flags" below.

cc addr length
Indicates the length of the call control address(es) (signalling interface and circuit
identifiers) that the peer CCS user has requested to be queried.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will only be issued by the CCS provider for signalling interfaces in the NNI mode.
Valid States
This primitive is valid in any state for the specified address(es).
New State
The new query state will be CCS WRES QIND for the specified call control addresses and the
number of outstanding queries for the specified call control addresses will be incremented.

176

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.15 Circuit Management Query Response

CC QUERY RES
This primitive requests that the CCS provider respond to the previous query indication.
Format
The format is one M_PROTO message block. The structure of the M_PROTO message block is as follows:
typedef struct CC_query_res {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_query_res_t;

/*
/*
/*
/*

always CC_QUERY_RES */
blocking flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies options flags for the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) upon which the query is requested. The semantics of the values in
the call control address is described in Section 2.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive is only valid for indications for signalling interfaces in the NNI mode.
Valid States
This primitive is only valid for the previous CC_BLOCKING_IND (call control addresses in the
CCS WRES BLIND state).
New State
The new query state of the previously specified call control addresses is the CCS_IDLE or
CCS WRES QIND state and the query backlog is decremented.
Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
2011-10-28

177

Chapter 4: CCI Primitives

Successful : Successful completion is indicated via the CC_OK_ACK primitive.

Unsuccessful :
Unsuccessful
CCS RESET IND primitive.

completion

indicated

via

the

CC_RELEASE_IND

178

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.2.16 Circuit Management Query Confirmation

CC QUERY CON
This primitive confirms a previous query request (or indicates failure of a previous query request).
Format
The format of this message is one M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_query_con {
ulong cc_primitive;
ulong cc_flags;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_query_con_t;

/*
/*
/*
/*

always CC_QUERY_CON */
query flags */
address length */
address offset */

Parameters
cc primitive
Specifies the primitive type.
cc flags

Specifies the options flags and result of the operation. (See "Flags" below.)

cc addr length
Specifies the length of the call control address (signalling interface and circuit or circuit
group identifiers) for which status is confirmed.
cc addr offset
Specifies the offset of the call control address(es) from the beginning of the M_PROTO
message block.
Flags
The options flags are protocol and provider-specific. For additional information, see the Addendum.
Valid Modes
This primitive will only be issued by the CCS provider for signalling interfaces in the NNI mode.
Valid States
This primitive will only be issued by the CCS provider if the query state of the specified address(es)
is CCS WCON QREQ.
New State
The new query state will be CCS_IDLE for the specified call control addresses.

2011-10-28

179

Chapter 4: CCI Primitives

4.3.3 Maintenance Primitives

4.3.3.1 Maintenance Indication
CC MAINT IND
This primitive indicates that the CCS provider has observed an event on the indicated call control
address(es) which requires a maintenance action.
Format
The format of this message is one M_PROTO message block followed by zero or more M_DATA blocks.
The structure of the M_PROTO message block is as follows:
typedef struct CC_maint_ind {
ulong cc_primitive;
ulong cc_reason;
ulong cc_call_ref;
ulong cc_addr_length;
ulong cc_addr_offset;
} CC_maint_ind_t;

/*
/*
/*
/*
/*

CC CONT TEST REQ
This message is used either to respond to a CC_SETUP_IND primitive which contains the ISUP_
NCI_CONT_CHECK_REQUIRED flag, or to respond to a CC CONT CHECK IND primitive. Before
responding to either primitive, the CCS User should install a loop back device on the requested
channel and then respond with this response primitive to confirm the loop back.
Format
The format of this message is on M_PROTO message block. The structure of the M_PROTO block is as
follows:
typedef struct CC_cont_test_req {
ulong cc_primitive;
ulong cc_call_ref;
ulong cc_token_value;
} CC_cont_test_req_t;

/* always CC_CONT_TEST_REQ */
/* call reference */
/* token value */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

cc token value
Is used to identify the stream that the CCS user wants to establish the continuity
check call on. (Its value is determined by the CCS user by issuing a CC_BIND_REQ
primitive with the CC_TOKEN_REQ flag set. The token value is returned in the CC_BIND_
ACK.) The value of this field should be non-zero when the CCS user wants to establish
the call on a stream other than the stream on which the CC CONT CHECK IND
arrived. If the CCS user wants to establish a call on the same stream that the
CC CONT CHECK IND arrived on, then the value of this field should be zero.
Valid Modes
This primitive is valid only in NNI mode.
Valid States
This primitive is valid in state CKS WREQ CTEST.
New State
The new state is CKS WIND CCREP.
2011-10-28

185

Chapter 4: CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_CONT_REPORT_IND in the case that
the primitive was issued in response to a CC_SETUP_IND, or CC_RELEASE_IND primitive in the
case that the primitive was issued in response to the CC CONT CHECK IND primitive.
Unsuccessful : Unsuccessful completion is indicated via the CC_CONT_REPORT_IND primitive.
Non-fatal errors: Errors are indicated via the CC_ERROR_ACK primitive. The applicable nonfatal errors are defined as follows:
[CCSYSERR]
A system error has occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCACCESS]
The user did not have proper permissions for the operation.
[CCNOTSUPP]
The CCS provider does not support the operation.

186

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.4.4 Circuit Continuity Test Indication

/*
/*
/*
/*

always CC_CONT_TEST_IND */
call reference */
address length */
address offset */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference associated with the continuity check call for the specified
call control address (circuit identifier).

2011-10-28

187

Chapter 4: CCI Primitives

4.3.4.5 Circuit Continuity Report Request

/*
/*
/*
/*

always CC_CONT_REPORT_REQ */
user call reference */
call reference */
result of continuity check */

Parameters
cc primitive
Specifies the primitive type.
cc user ref

Specifies the CCS user reference of the associated CC_SETUP_REQ primitive.

cc call ref

cc result

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

Acknowledgements
The CCS provider should generate one of the following acknowledgements upon receipt of this
primitive:
Successful : Successful completion is indicated via the CC_OK_ACK primitive.
Unsuccessful (Non-fatal errors): Errors are indicated via the CC_ERROR_ACK primitive. The
applicable non-fatal errors are defined as follows:
[CCSYSERR]
A system error occurred and the UNIX system error is indicated in the primitive.
[CCOUTSTATE]
The primitive was issued from an invalid state.
[CCBADCLR]
The call reference specified in the primitive was incorrect or illegal.
[CCBADPRIM]
The primitive format was incorrect.

2011-10-28

189

Chapter 4: CCI Primitives

4.3.4.6 Circuit Continuity Report Indication

/* always CC_CONT_REPORT_IND */
/* call reference */
/* result of continuity check */

Parameters
cc primitive
Indicates the primitive type.
cc call ref

Indicates the call reference associated with the continuity check report as it appeared
in the associated CC CONT CHECK IND primitive.

cc result

Valid Modes
This primitive is valid only in NNI mode.
Valid States
This primitive is valid in state CCS WREQ CTEST or CCS_WIND_CCREP.
New State
If the primitive is issued subsequent to the CC_SETUP_REQ, the new state is CCS_WCON_SREQ. If the
primitive is issued in response to the CC_CONT_TEST_IND primitive, the new state is CCS_IDLE.

190

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Primitives

4.3.5 Collecting Information Phase

The following call control service primitive pertain to the collecting information phase of a call.

2011-10-28

191

Call Control Interface (CCI)

Diagnostics Requirements

5 Diagnostics Requirements
Two error handling facilities should be provided to the call control service user: one to handle
non-fatal errors, ant the other to handle fatal errors.

5.1 Non-Fatal Error Handling Facility

These are errors that do not change the state of the call control service interface or the call reference
as seen by the call control service user, and provide the user the option of reissuing the call control
service primitive with the corrected options specification. The non-fatal error handling is provided
only to those primitive that require acknowledgements, and uses the CC_ERROR_ACK primitive to
report these errors. These errors retain the state of the call control service interface and call reference
the same as it was before the call control service provider received the primitive that was in error.
Syntax errors and rule violations are reported via the non-fatal error handling facility.

5.2 Fatal Error Handling Facility

These errors are issued by the CCS provider when it detects errors that are not correctable by the
call control service user, or if it is unable to report a correctable error to the call control service user.
Fatal errors are indicated via the STREAMS message type M_ERROR with the UNIX system error
EPROTO. The M_ERROR STREAMS message type will result in the failure of all the UNIX system
calls on the stream. The call control service user can recover from a fatal error by having all the
processes close the files associated with the stream, and then reopening them for processing.

2011-10-28

193

Call Control Interface (CCI)

Addendum for Q.931 Conformance

This addendum describes the formats and rules that are specific to ISDN Q.931. The addendum
must be used along with the generic CCI as defined in the main document when implementing a
CCS provider that will be configured with the Q.931 call processing layer.

Primitives and Rules for Q.931 Conformance

The following are the rules that apply to the CCI primitives for Q.931 compatibility.
Common Primitive Parameters
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.931 conforming CCS providers is as follows:
typedef struct isdn_addr {
ulong scope;
ulong id;
ulong ci;
} isdn_addr_t;
#define
#define
#define
#define
#define
#define

ISDN_SCOPE_CH
ISDN_SCOPE_FG
ISDN_SCOPE_TG
ISDN_SCOPE_EG
ISDN_SCOPE_XG
ISDN_SCOPE_DF

/* the scope of the identifier */

/* the identifier within the scope */
/* channel identifier within the scope */

1
2
3
4
5
6

/*
/*
/*
/*
/*
/*

channel scope */
facility group scope */
transmission group scope */
equipment group scope */
customer/provider group scope */
default scope */

Address Fields
scope

CC_CALL_TYPE_13x64KBS_UNRESTRICTED
The call type is 13 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 13.
CC_CALL_TYPE_14x64KBS_UNRESTRICTED
The call type is 14 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 14.
CC_CALL_TYPE_15x64KBS_UNRESTRICTED
The call type is 15 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 15.
CC_CALL_TYPE_16x64KBS_UNRESTRICTED
The call type is 16 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 16.
CC_CALL_TYPE_17x64KBS_UNRESTRICTED
The call type is 17 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 17.
CC_CALL_TYPE_18x64KBS_UNRESTRICTED
The call type is 18 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 18.
CC_CALL_TYPE_19x64KBS_UNRESTRICTED
The call type is 19 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 19.
CC_CALL_TYPE_20x64KBS_UNRESTRICTED
The call type is 20 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 20.
CC_CALL_TYPE_21x64KBS_UNRESTRICTED
The call type is 21 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 21.
CC_CALL_TYPE_22x64KBS_UNRESTRICTED
The call type is 22 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 22.
202

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.931 Conformance

CC_CALL_TYPE_23x64KBS_UNRESTRICTED
The call type is 23 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 23.
CC_CALL_TYPE_24x64KBS_UNRESTRICTED
The call type is 24 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 24.
CC_CALL_TYPE_25x64KBS_UNRESTRICTED
The call type is 25 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 25.
CC_CALL_TYPE_26x64KBS_UNRESTRICTED
The call type is 26 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 26.
CC_CALL_TYPE_27x64KBS_UNRESTRICTED
The call type is 27 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 27.
CC_CALL_TYPE_28x64KBS_UNRESTRICTED
The call type is 28 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 28.
CC_CALL_TYPE_29x64KBS_UNRESTRICTED
The call type is 29 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 29.
CC_CALL_TYPE_30x64KBS_UNRESTRICTED
The call type is 30 x 64 kbit/s unrestricted digital information. This call type corresponds to a Q.931 Information transfer capability of Unrestricted, and an Information
transfer rate of multi-rate with a base rate of 64 kbit/s and a multiplier of 30.
Flags
The following call flags are defined for Q.931 conforming CCS providers:
CC_ITC_WITH_TONES_AND_ANNOUNCEMENTS"
When set, this flag indicates that the unrestricted digital information includes tones
and announcements.
Rules
CC SETUP REQ

2011-10-28

203

Addendum for Q.931 Conformance

Parameters
cc call type
Specifies the type of call to be set up. For Q.931 conforming CCS providers, the call
type can be one of the call types listed under "Call Type and Flags" in this addendum.
cc call flags
Specifies the options flags associated with the call. For Q.931 conforming CCS
providers, the call flags can be any of the flags listed under "Call Type and Flags" in
this addendum.
cc cdpn length
Specifies the length of the called party number. For Q.931 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.931.
cc cdpn offset
Specifies the offset of the called party number from the beginning of the block.
Rules
Rules for call type:
1. A CCS provider need not support all of the call types listed.
Rules for call flags:
1. The CC ITC WITH TONES AND ANNOUNCEMENTS flag may only be set when the call
type is unrestricted digital information. When the call type is not unrestricted digital information, this flag should be ignored by the CCS provider.
Rules for called party number:
Rules for generating a SETUP message:
1. The mandatory (first) Bearer Capability information element in the SETUP message will be
derived from the call type and flags. The Bearer Capability information element will contain
the Information transfer capability, rate, base and multiplier indicated above.
When the call type is CC CALL TYPE 128KBS UNRESTRICTED, the Bearer
Capability information element will be coded with an Information transfer capability of unrestricted (or unrestricted with tones an announcements if the flag
CC ITC WITH TONES AND ANNOUNCEMENTS i set) and an Information transfer
rate of 2 x 64 kbit/s uni-rate call. For a multi-rate call, the call type should be coded as
CC CALL TYPE 2x64KBS UNRESTRICTED.
When the call type is CC CALL TYPE 384KBS UNRESTRICTED, the Bearer
Capability information element will be coded with an Information transfer capability of unrestricted (or unrestricted with tones an announcements if the flag
CC ITC WITH TONES AND ANNOUNCEMENTS i set) and an Information transfer
rate of 384 kbit/s uni-rate call. For a multi-rate call, the call type should be coded as
CC CALL TYPE 6x64KBS UNRESTRICTED.
When the call type is CC CALL TYPE 1536KBS UNRESTRICTED, the Bearer
Capability information element will be coded with an Information transfer capability of unrestricted (or unrestricted with tones an announcements if the flag
204

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.931 Conformance

CC ITC WITH TONES AND ANNOUNCEMENTS i set) and an Information transfer

rate of 1536 kbit/s uni-rate call. For a multi-rate call, the call type should be coded as
CC CALL TYPE 24x64KBS UNRESTRICTED.
When the call type is CC CALL TYPE 1920KBS UNRESTRICTED, the Bearer
Capability information element will be coded with an Information transfer capability of unrestricted (or unrestricted with tones an announcements if the flag
CC ITC WITH TONES AND ANNOUNCEMENTS i set) and an Information transfer
rate of 1920 kbit/s uni-rate call. For a multi-rate call, the call type should be coded as
CC CALL TYPE 29x64KBS UNRESTRICTED.
The mandatory Channel Identification information element in the SETUP message
will be derived from the address to which the stream is bound.
If the stream is bound to a channel group (the one or more interfaces), then a free channel
will be selected automatically by the CCS provider (if possible).
If the stream is bound to a channel, then the channel identifier of the bound channel will
be used.
Rules for state transitions:
1. If the optional information element contains a Sending Complete information element, then the
CCS provider will not accept any subsequent CC_INFORMATION_REQ primitives from the CCS
user, nor will the CCS provider issue any subsequent CC MORE INFO IND primitives to the
CCS user.
CC SETUP IND
Parameters
cc call type
Specifies the type of call to be set up. For Q.931 conforming CCS providers, the call
type can be one of the call types listed under "Call Type and Flags" in this addendum.
cc call flags
Specifies the options flags associated with the call. For Q.931 conforming CCS
providers, the call flags can be any of the flags listed under "Call Type and Flags" in
this addendum.
cc cdpn length
Specifies the length of the called party number. For Q.931 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.931.
cc cdpn offset
Specifies the offset of the called party number from the beginning of the block.
cc addr length
Specifies the length of the address which contains the channel identifier selected for the
call.
cc addr offset
Specifies the offset of the address from the beginning of the block.
2011-10-28

205

Addendum for Q.931 Conformance

Flags
Call flags can be any of the call flags supported by the CCS provider listed under CC_SETUP_REQ in
this addendum.
Rules
Rules for call type:
1. A CCS provider need not support all of the call types listed.
Rules for call flags:
1. The CC ITC WITH TONES AND ANNOUNCEMENTS flag may only be set when the call
type is unrestricted digital information. When the call type is not unrestricted digital information, this flag should be ignored by the CCS provider.
Rules for called party number:
Rules for obtaining parameters from a SETUP message:
1. The mandatory (first) Bearer Capability information element in the SETUP message will be
translated into the call type and flags. The call type and flags correspond to the Bearer
Capability information element will contain the Information transfer capability, rate, base and
multiplier indicated under "Call Type" and "Flags".
2. The mandatory Channel Identification information element in the SETUP message will be
provided in the address parameter.
Rules for state transitions:
1. If the optional information element contains a Sending Complete information element, then
the CCS provider will not accept any subsequent CC_MORE_INFO_REQ primitives from the CCS
user, nor will the CCS provider issue any subsequent CC_INFORMATION_IND primitives to the
CCS user.
CC SETUP RES
Parameters
Flags
Rules
CC SETUP CON
Parameters
Flags
Rules
CC CALL REATTEMPT IND

206

Version 1.1 Rel. 1.20110510

Flags
Q.931 conforming CCS providers do not support suspend flags. This field should be coded zero (0)
by the CCS user and ignored by the CCS provider.
Rules
Rules for issuing primitive:
1. Only the CCS user on the User side of the Q.931 interface can issue a CC_SUSPEND_REQ primitive.
If the CCS provider is in Network mode and it receives a CCS SUSPEND REQ, it should
respond with a CC_ERROR_ACK with error CCNOTSUPP.
CC SUSPEND IND
cc flags

Indicates the options associated with the suspend. See "Flags" below.

Flags
Q.931 conforming CCS providers do not support suspend flags. This field will be coded zero (0) by
the CCS provider and may be ignored by the CCS provider.
CC SUSPEND RES

210

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.931 Conformance

Parameters
Rules
CC SUSPEND CON
Parameters
Rules
CC SUSPEND REJECT REQ
Parameters
cc cause

Specifies the cause for the rejection. For Q.931 conforming CCS providers, the cause
values can be any of the values listed in "Cause Values" in this addendum with the
exception of CCS CAUS NONE.

Flags
Rules
CC SUSPEND REJECT IND
Parameters
cc cause

Specifies the cause for the rejection. For Q.931 conforming CCS providers, the cause
values can be any of the values listed in "Cause Values" in this addendum with the
exception of CCS CAUS NONE.

Flags
Rules
CC RESUME REQ
Parameters
cc flags

Indicates the options associated with the resume. See "Flags" below.

Flags
Q.931 conforming CCS providers do not support resume flags. This field should be coded zero (0)
by the CCS user and ignored by the CCS provider.
Rules
2011-10-28

211

Addendum for Q.931 Conformance

CC RESUME IND
Parameters
cc flags

Indicates the options associated with the resume. See "Flags" below.

Flags
Q.931 conforming CCS providers do not support resume flags. This field should be coded zero (0)
by the CCS user and ignored by the CCS provider.
Rules
CC RESUME RES
Parameters
Flags
Rules
CC RESUME CON
Parameters
Flags
Rules
CC RESUME REJECT REQ
Parameters
cc cause

Specifies the cause for the rejection. For Q.931 conforming CCS providers, the cause
values can be any of the values listed in "Cause Values" in this addendum with the
exception of CCS CAUS NONE.

Flags
Rules
CC RESUME REJECT IND
cc cause

212

Specifies the cause for the rejection. For Q.931 conforming CCS providers, the cause
values can be any of the values listed in "Cause Values" in this addendum with the
exception of CCS CAUS NONE.
Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.931 Conformance

Parameters
Flags
Rules
Call Termination Primitives
Cause Values
Cause values are used in the following primitives:
CC_REJECT_REQ, CC_REJECT_IND, CC_DISCONNECT_REQ, CC_DISCONNECT_IND, CC_RELEASE_REQ, and
CC_RELEASE_IND.
Parameters
cc cause

Indicates the case for the rejection, disconnection, or release of a call. For Q.931
conforming CCS providers, the cause values can be any of the cause values listed in
Q.850 listed under "Cause Value" below.

Cause Value
Cause values are essentially opaque and cause values will be transferred directly to the corresponding
Q.931 message. The following cause values are defined for Q.931 conforming CCS providers:
CC_CAUS_UNALLOCATED_NUMBER
The called party number does not correspond to number allocated to a subscriber or
terminal.
CC_CAUS_NO_ROUTE_TO_TRANSIT_NETWORK
(no description)
CC_CAUS_NO_ROUTE_TO_DESTINATION
(no description)
CC_CAUS_SEND_SPECIAL_INFO_TONE
(no description)
CC_CAUS_MISDIALLED_TRUNK_PREFIX
(no description)
CC_CAUS_PREEMPTION
(no description)
CC_CAUS_PREEMPTION_CCT_RESERVED
(no description)
CC_CAUS_NORMAL_CALL_CLEARING
(no description)
CC_CAUS_USER_BUSY
(no description)
2011-10-28

213

Addendum for Q.931 Conformance

CC_CAUS_NO_USER_RESPONDING
(no description)
CC_CAUS_NO_ANSWER
(no description)
CC_CAUS_SUBSCRIBER_ABSENT
(no description)
CC_CAUS_CALL_REJECTED
(no description)
CC_CAUS_NUMBER_CHANGED
(no description)
CC_CAUS_REDIRECT
(no description)
CC_CAUS_OUT_OF_ORDER
(no description)
CC_CAUS_ADDRESS_INCOMPLETE
(no description)
CC_CAUS_FACILITY_REJECTED
(no description)
CC_CAUS_NORMAL_UNSPECIFIED
(no description)
CC_CAUS_NO_CCT_AVAILABLE
(no description)
CC_CAUS_NETWORK_OUT_OF_ORDER
(no description)
CC_CAUS_TEMPORARY_FAILURE
(no description)
CC_CAUS_SWITCHING_EQUIP_CONGESTION
(no description)
CC_CAUS_ACCESS_INFO_DISCARDED
(no description)
CC_CAUS_REQUESTED_CCT_UNAVAILABLE
(no description)
CC_CAUS_PRECEDENCE_CALL_BLOCKED
(no description)
CC_CAUS_RESOURCE_UNAVAILABLE
(no description)
CC_CAUS_NOT_SUBSCRIBED
(no description)
214

Version 1.1 Rel. 1.20110510

Specifies the cause value for the rejection. For Q.931 conforming CCS providers, the
cause value will be one of the cause values listed under "Cause Values" in this Addendum.

Flags
Rules
CC CALL FAILURE IND
Parameters
cc reason

Specifies the reason for the failure indication. For Q.931 conforming CCS providers,
the reason will be one of the reasons listed under "Call Failure Reasons" below.

cc cause

Specifies the cause value for the error indication. For Q.931 conforming CCS providers,
the cause value will be one of the cause values listed under "Cause Values" in this
addendum.

Call Failure Reasons

ISUP_CALL_FAILURE_ERROR
Indicates that the data link failed and recovered during overlap sending or overlap
receiving.
ISUP_CALL_FAILURE_STATUS
Indicates that the CCS provider received a STATUS message from the peer with a
unrecoverable mismatch in state.
ISUP_CALL_FAILURE_RESTART
Indicates that the CCS provider received or issued a RESTART message for the channel.
Flags
Rules
CC DISCONNECT REQ
Parameters
cc cause

2011-10-28

Specifies the cause value for the disconnect. For Q.931 conforming CCS providers,
the cause value will be one of the cause values listed under "Cause Values" in this
addendum.
217

Addendum for Q.931 Conformance

Rules
CC DISCONNECT IND
Parameters
cc cause

Indicates the case values for the disconnect. For Q.931 conforming CCS providers, the
cause value wil be one of the cause values listed under "Cause Value" in this addendum.

Rules
CC RELEASE REQ
Parameters
cc cause

Specifies the cause value for the release. For Q.931 conforming CCS providers, the cause
value will be one of the cause values listed under "Cause Values" in this addendum.

Rules
Rules for cause:
1. If the request is not the first step in the clearing phase (i.e, the call is not in state
CC WREQ REL), then the cause value must be specified. Otherwise, the cause value should
be coded CC CAUS NONE by the CCS user and ignored by the CCS provider.
CC RELEASE IND
Parameters
cc cause

Specifies the cause value for the release. For Q.931 conforming CCS providers, the cause
value will be one of the cause values listed under "Cause Values" in this addendum.

Rules
Rules for cause:
1. If the request is not the first step in the clearing phase (i.e, the call is not in state
CC WIND REL), then the cause value will be indicated by the CCS provider. Otherwise, the
cause value will be coded CC CAUS NONE by the CCS provider and should be ignored by
the CCS user.
CC RELEASE RES
Parameters
Rules
CC RELEASE CON
218

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.931 Conformance

Parameters
Rules
Management Primitives
CC RESTART REQ
Parameters
cc flags
cc addr length
Specifies the length of the address which contains the interface identifier(s) and optional
channel identification for the interface(s) or channels to restart.
cc addr offset
Specifies the offset of the address from the beginning of the block.
Flags
Rules
CC RESTART CON
Parameters
cc flags
cc addr length
Specifies the length of the address which contains the interface identifier(s) and optional
channel identification for the interface(s) or channels to restart.
cc addr offset
Specifies the offset of the address from the beginning of the block.
Flags
Rules

Q.931 Header File Listing

#ifndef __SS7_ISDNI_H__
#define __SS7_ISDNI_H__
/*
* ISDN address
*/

2011-10-28

219

Addendum for Q.931 Conformance

typedef struct isdn_addr {

cc_ulong scope;
cc_ulong id;
cc_ulong ci;
} isdn_addr_t;
#define
#define
#define
#define
#define
#define

ISDN_SCOPE_CH
ISDN_SCOPE_FG
ISDN_SCOPE_TG
ISDN_SCOPE_EG
ISDN_SCOPE_XG
ISDN_SCOPE_DF

1
2
3
4
5
6

/* the scope of the identifier */

/* the identifier within the scope */
/* channel identifier within the scope */

/*
/*
/*
/*
/*
/*

channel scope */
facility group scope */
transmission group scope */
equipment group scope */
customer/provider group scope */
default scope */

enum {
U0_NULL,
U1_CALL_INITIATED,
U2_OVERLAP_SENDING,
U3_OUTGOING_CALL_PROCEEDING,
U4_CALL_DELIVERED,
U6_CALL_PRESENT,
U7_CALL_RECEIVED,
U8_CONNECT_REQUEST,
U9_INCOMING_CALL_PROCEEDING,
U10_ACTIVE,
U11_DISCONNECT_REQUEST,
U12_DISCONNECT_INDICATION,
U15_SUSPEND_REQUEST,
U17_RESUME_REQUEST,
U19_RELEASE_REQUEST,
U25_OVERLAP_RECEIVING,
N0_NULL,
N1_CALL_INITIATED,
N2_OVERLAP_SENDING,
N3_OUTGOING_CALL_PROCEEDING,
N4_CALL_DELIVERED,
N6_CALL_PRESENT,
N7_CALL_RECEIVED,
N8_CONNECT_REQUEST,
N9_INCOMING_CALL_PROCEEDING,
N10_ACTIVE,
N11_DISCONNECT_REQUEST,
N12_DISCONNECT_INDICATION,
N15_SUSPEND_REQUEST,
N17_RESUME_REQUEST,
N19_RELEASE_REQUEST,
N22_CALL_ABORT,
N25_OVERLAP_RECEIVING,
};
enum {
CMS_IDLE = 0,
};
#define ISDN_PI_INTERWORKING

0x0 /* FIXME */

220

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

* Q.850 Cause Values

*/
/*
Normal class
*/
#define CC_CAUS_UNALLOCATED_NUMBER
#define CC_CAUS_NO_ROUTE_TO_TRANSIT_NETWORK
#define CC_CAUS_NO_ROUTE_TO_DESTINATION
#define CC_CAUS_SEND_SPECIAL_INFO_TONE
#define CC_CAUS_MISDIALLED_TRUNK_PREFIX
#define CC_CAUS_CALL_ABANDONNED
#define CC_CAUS_PREEMPTION
#define CC_CAUS_PREEMPTION_CCT_RESERVED
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

CC_CAUS_NORMAL_CALL_CLEARING
CC_CAUS_USER_BUSY
CC_CAUS_NO_USER_RESPONDING
CC_CAUS_NO_ANSWER
CC_CAUS_SUBSCRIBER_ABSENT
CC_CAUS_CALL_REJECTED
CC_CAUS_NUMBER_CHANGED
CC_CAUS_REDIRECT
CC_CAUS_OUT_OF_ORDER
CC_CAUS_ADDRESS_INCOMPLETE

Addendum for Q.931 Conformance

1
2
3
4
5
6
8
9

/*
/*
/*
/*
/*
/*
/*
/*

16
17
18
19
20
21
22
23
27
28

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

#define CC_CAUS_FACILITY_REJECTED
#define CC_CAUS_NORMAL_UNSPECIFIED
/*
Resource Unavailable Class
*/
#define CC_CAUS_NO_CCT_AVAILABLE
#define CC_CAUS_NETWORK_OUT_OF_ORDER
#define CC_CAUS_TEMPORARY_FAILURE
#define CC_CAUS_SWITCHING_EQUIP_CONGESTION
#define CC_CAUS_ACCESS_INFO_DISCARDED
#define CC_CAUS_REQUESTED_CCT_UNAVAILABLE

29 /*
31 /*

34
38
41
42
43
44

/*
/*
/*
/*
/*
/*

#define CC_CAUS_PRECEDENCE_CALL_BLOCKED
#define CC_CAUS_RESOURCE_UNAVAILABLE
/*
Service or Option Unavaialble Class
*/
#define CC_CAUS_NOT_SUBSCRIBED
#define CC_CAUS_OGC_BARRED_WITHIN_CUG
#define CC_CAUS_ICC_BARRED WITHIN_CUG
#define CC_CAUS_BC_NOT_AUTHORIZED
#define CC_CAUS_BC_NOT_AVAILABLE

50
53
55
57
58

/*
/*
/*
/*
/*

Unallocated (unassigned) number */

No route to specified transit network */
No route to destination */
Send special information tone */
Misdialled trunk prefix */
Call abandonned */
Preemption */
Preemption - circuit reserved for
reuse */
Normal call clearing */
User busy */
No user responding */
No answer from user (user alerted) */
Subscriber absent */
Call rejected */
Number changed */
Redirect to new destination */
Desitination out of order */
Invalid number format (address
incomplete) */
Facility rejected */
Normal unspecified */

No circuit/channel available */
Network out of order */
Temporary failure */
Switching equipment congestion */
Access information discarded */
Requested circuit/channel not
available */
46 /* Precedence call blocked */
47 /* Resource unavailable, unspecified */

Requested facility not subscribed */

Outgoing calls barred within CUG */
Incoming calls barred within CUG */
Bearer capability not authorized */
Bearer capability not presently
available */
#define CC_CAUS_INCONSISTENCY
62 /* Inconsistency in designated outgoing
access information and subscriber
class */
#define CC_CAUS_SERVICE_OPTION_NOT_AVAILABLE 63 /* Service or option not available,
unspecified */
/*
Service or Option Not Implemented Class
*/

2011-10-28

221

Addendum for Q.931 Conformance

#define CC_CAUS_BC_NOT_IMPLEMENTED
#define CC_CAUS_FACILITY_NOT_IMPLEMENTED
#define CC_CAUS_RESTRICTED_BC_ONLY

65 /* Bearer capability not implemented */

69 /* Requested facility not implemented */
70 /* Only restricted digital information
bearer capability is available */
#define CC_CAUS_SERIVCE_OPTION_NOT_IMPLEMENTED 79
/* Service or option not
implemented, unspecified */
/*
Invalid Message (e.g., Parameter out of Range) Class
*/
#define CC_CAUS_UNEXPECTED_MESSAGE
81 /* Unexpected message */
#define CC_CAUS_USER_NOT_MEMBER_OF_CUG
87 /* User not member of CUG */
#define CC_CAUS_INCOMPATIBLE_DESTINATION
88 /* Incompatible destination */
#define CC_CAUS_NON_EXISTENT_CUG
90 /* Non-existent CUG */
#define CC_CAUS_INVALID_TRANSIT_NTWK_SELECTION 91
/* Invalid transit network
selection */
#define CC_CAUS_INVALID_MESSAGE
95 /* Invalid message, unspecified */
#define CC_CAUS_MISSING_MANDATORY_PARAMETER 96 /* Invalid message, missing mandatory
parameter */
/*
Protocol Error (e.g., Unknwon Message) Class
*/
#define CC_CAUS_MESSAGE_TYPE_NOT_IMPLEMENTED 97 /* Message typ non-existent or not
implemented. */
#define CC_CAUS_PARAMETER_NOT_IMPLEMENTED
99 /* Information element/Parameter
non-existent or not implemented */
#define CC_CAUS_INVALID_MANDATORY_PARAMETER 100 /* Invalid mandatory parameter */
#define CC_CAUS_RECOVERY_ON_TIMER_EXPIRY
102 /* Recovery on timer expiry */
#define CC_CAUS_PARAMETER_PASSED_ON
103 /* Parameter non-existent or not
implemented - passed on */
#define CC_CAUS_MESSAGE_DISCARDED
110 /* Message with unrecognized parameter
discarded */
#define CC_CAUS_PROTOCOL_ERROR
111 /* Protocol error, unspecified */
/*
Interworking Class
*/
#define CC_CAUS_INTERWORKING
127 /* Interworking, unspecified */
/*
* ANSI Standard Causes
*/
/*
Normal Class
*/
#define CC_CAUS_UNALLOCATED_DEST_NUMBER
23 /* Unallocated destination number */
#define CC_CAUS_UNKNOWN_BUSINESS_GROUP
24 /* Unknown business group */
#define CC_CAUS_EXCHANGE_ROUTING_ERROR
25 /* Exchange routing error */
#define CC_CAUS_MISROUTED_CALL_TO_PORTED_NUMBER 26
/* Misrouted call to a ported
number */
#define CC_CAUS_LNP_QOR_NUMBER_NOT_FOUND
27 /* Number portability Query on Release
(QoR) number not found. */
/*
Resource Unavailable Class
*/
#define CC_CAUS_RESOURCE_PREEMPTION
45 /* Preemption. */
#define CC_CAUS_PRECEDENCE_CALL_BLOCKED
46 /* Precedence call blocked. */
/*
Service or Option Not Available Class

222

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.931 Conformance

*/
#define CC_CAUS_CALL_TYPE_INCOMPATIBLE
#define CC_CAUS_GROUP_RESTRICTIONS

#endif

2011-10-28

51 /* Call type incompatible with service

request */
54 /* Call blocked due to group restrictions
*/

/* __SS7_ISDNI_H__ */

223

Call Control Interface (CCI)

Addendum for Q.764 Conformance

This addendum describes the formats and rules that are specific to ISUP Q.764. The addendum
must be used along with the generic CCI as defined in the main document when implementing a
CCS provider that will be configured with the Q.764 call processing layer.

Primitives and Rules for Q.764 Conformance

The following are the rules that apply to the CCI primitives for Q.764 compatibility.
Common Primitive Parameters
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.764 conforming CCS providers is as follows:
typedef struct isup_addr {
ulong scope;
ulong id;
ulong cic;
} isup_addr_t;

/* the scope of the identifier */

/* the identifier within the scope */
/* circuit identification code within the scope */

#define
#define
#define
#define
#define
#define
#define

1
2
3
4
5
6
7

ISUP_SCOPE_CT
ISUP_SCOPE_CG
ISUP_SCOPE_TG
ISUP_SCOPE_SR
ISUP_SCOPE_SP
ISUP_SCOPE_DF
ISUP_SCOPE_CIC

/*
/*
/*
/*
/*
/*
/*

circuit scope */
circuit group scope */
trunk group scope */
signalling relation scope */
signalling point scope */
default scope */
for unidentified cic addresses */

Address Fields
scope

Specifies or indicates the scope of the call control address. See "Scope" below.

Specifies or indicates the identifier within the scope.

cic

Specifies or indicates the Circuit Identification Code significant within the scope.

2011-10-28

225

Addendum for Q.764 Conformance

Scope
The scope of the address is one of the following:
ISUP_SCOPE_CT
Specifies or indicates that the scope of the call control address is a ISUP 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.
ISUP_SCOPE_CG
Specifies or indicates that the scope of the call control address is a ISUP 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).
ISUP_SCOPE_TG
Specifies or indicates that the scope of the call control address is a ISUP 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.
ISUP_SCOPE_SR
Specifies or indicates that the scope of the call control address is a ISUP 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.
ISUP_SCOPE_SP
Specifies or indicates that the scope of the call control address is a ISUP 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.
ISUP_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.
226

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

Rules
Rules for scope:
1. In primitives in which the address parameter occurs, the scope field setting indicates the scope
of the address parameter.
2. Only one call control address can be specified with a signle scope.
3. Not all scopes are necessarily supported by all primitives. See the particular primitive in this
addendum.
Rules for addresses:
1. 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).
2. If the scope of the address is ISUP_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.
3. If the scope of the address is ISUP_SCOPE_SP, then the circuit identification code field should
be coded zero (0) and will be ignored by the CCS user or provider.
4. 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.764 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.764 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.763.
cc opt offset
Specifies the offset of the optional parameters from the beginning of the block.
Rules
Rules for optional parameters:
1. 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 primitive with error [CCBADOPT].
2. 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
addendum.
2011-10-28

227

Addendum for Q.764 Conformance

3. Except for optional parameters interpreted by the CCS provider as specified later in this addendum, the optional parameters are treated as opaque and the optional parameter list only is
checked for syntax. Opaque parameters will be passed to the ISUP message without examination by the CCS provider.
4. To perform specific functions, additional optional parameters may be added to ISUP messages
by the CCS provider.
5. To perform specific functions, optional parameters may be modified by the CCS provider before
being added to ISUP messages.
Local Management Primitives
CC INFO ACK
Parameters
Flags
Rules
CC BIND REQ
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. 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). 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]).
228

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

CC_TOKEN_REQUEST
When set, this flag specifies to the CCS provider that the CCS user has
requested that a "token" be assigned to the stream (to be used in the call
response message), and the token value be returned to the CCS user via
the CC_BIND_ACK primitive. The token assigned by the CCS provider can
then be used by the CCS user in a subsequent CC_SETUP_RES primitive
to identify the stream on which the call is to be established.
CC_MANAGEMENT
When set, this flag specifies to the CCS provider that this stream is to be
used for circuit management indications for the specified addresses.
CC_TEST

When set, this flag specifies to the CCS provider that this stream is to be
used for continuity and test call indications for the specified addresses.

CC_MAINTENANCE
When set, this flag specifies to the CCS provider that this stream is to be
used for maintenance indications for the specified addresses.
Rules
Rules for address specification:
1. The address contained in the primitive as indicated by cc addr length and cc addr offset parameters. The address can be of any ISUP scope.
2. 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:
1. 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 ISUP_SCOPE_CT, only incoming calls on the bound circuit
will be delivered to the listening stream.
If the address bound is of scope ISUP_SCOPE_CG, only incoming calls on the bound circuit
group will be delivered to the listening stream.
If the address bound is of scope ISUP_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 ISUP_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 ISUP_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 ISUP_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.
2011-10-28

229

Addendum for Q.764 Conformance

2. 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:
1. For Q.764 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.
2. Only one of CC_DEFAULT_LISTENER, CC_MANAGEMENT, CC_TEST and CC_MAINTENANCE may be
set.
3. Streams bound with the CC_MANAGEMENT flag set will receive only circuit management indications and will not receive any calls.
4. 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.
5. 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
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 in this Addendum.
Rules
See CC_BIND_REQ in this Addendum.
CC OPTMGMT REQ
Parameters
Flags
Rules
Call Setup Primitives

230

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

CC SETUP REQ
Parameters
cc call type
Specifies the type of call to be set up. Q.764 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.764 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.764 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.764
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.764
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.764 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.764 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.764 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.764 transmission medium requirement of 1920
kbit/s Unrestricted Digital Information.
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 primitive is issued.

cc call flags
Specifies the options associated with the call. Q.764 conforming CCS providers must
support the following flags:
2011-10-28

231

Addendum for Q.764 Conformance

The following flags correspond to bits in the Nature of Connection Indicators parameter
of Q.763:
ISUP_NCI_ONE_SATELLITE_CCT
ISUP_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.
ISUP_NCI_CONT_CHECK_REQUIRED
ISUP_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.
ISUP_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.763:
ISUP_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.
ISUP_FCI_PASS_ALONG_E2E_METHOD_AVAILABLE
ISUP_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.
ISUP_FCI_INTERWORKING_ENCOUNTERED
When this flag is set, interworking has been encountered on the call.
Otherwise, no interworking has been encountered on the call.
ISUP_FCI_E2E_INFORMATION_AVAILABLE
When this flag is set, end-to-end information is now available. Otherwise,
no end-to-end information is available.
ISUP_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.
ISUP_FCI_ORIGINATING_ACCESS_ISDN
When this flag is set, the originating access is ISDN. Otherwise, the originating access is non-ISDN.
232

Version 1.1 Rel. 1.20110510

cc token value
Specifies the token of a stream upon which to accept the call setup.
Rules
Rules for call reference:
1. 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. Otherwise the CCS provider
will respond with a CC_ERROR_ACK primitive with error [CCBADCLR].
Rules for token value:
1. If the token is the token value of the stream upon which the corresponding CC_SETUP_IND
was received, or zero (0), then the call setup will be accepted on the stream upon which the
CC_SETUP_IND was received.
2. 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
Parameters
cc user ref

Indicates the CCS user call reference that was specified in the CC_SETUP_REQ. This call
reference is used by the CCS user to associated the CC_SETUP_CON with an outstanding
CC_SETUP_REQ primitive.

2011-10-28

235

Addendum for Q.764 Conformance

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:
1. The CCS user call reference will be the same as the call reference provided by the user in the
CC_SETUP_REQ primitive.
2. The CCS provider call reference will follow the rules of the CC_SETUP_IND in this Addendum.
Rules for addresses:
1. The call control address indicated in the CC_SETUP_CON is a ISUP_SCOPE_CT (circuit scoped) call
control address which identifies the circuit(s) upon which the outgoing call will be connected.
2. 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
Parameters
cc user ref

Indicates the CCS user call reference for the call. This reference identifies the corresponding CC_SETUP_REQ primitives to the CCS user for which the call reattempt need
be performed.

cc reason

Indicates the reason for the reattempt. The reason can be one of the following values:
ISUP_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).
ISUP_REATTEMPT_RESET
Indicates that the circuit was reset during the initial setup of the call (i.e,
before any backward message was received).
ISUP_REATTEMPT_BLOCKING
Indicates that the circuit was blocked during the initial setup of the call
(i.e, before any backward message was received).
ISUP_REATTEMPT_T24_TIMEOUT
Indicates that COT failure occurred on the circuit (due to T24 timeout).
ISUP_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).

236

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

ISUP_REATTEMPT_COT_FAILURE
Indicates that COT failed on the circuit (due to transmission of COT
message indicating failure).
ISUP_REATTEMPT_CIRCUIT_BUSY
Indicates that the specified circuit was busy.
Rules
Rules for call reference:
1. The CCS user call reference is a call reference associated with an outstanding CC_SETUP_REQ
primitive to which the CCS provider is responding.
Rules for reason:
1. The Q.764 conforming CCS provider will provide one of the reasons listed above.
2. The ISUP REATTEMPT DUAL SEIZURE reason will only be indicated if the CCS user represents a non-controlling exchange for the associated trunk group.
3. The ISUP REATTEMPT T24 TIMEOUT reason will only be indicated if the outgoing call
includes a continuity test and a positive CC_CONT_REPORT_REQ was not issued to the CCS
provider by a test stream within T24.
4. The ISUP REATTEMPT COT FAILURE reason will only be indicated if the outgoing call
includes a continuity test and a negative CC_CONT_REPORT_REQ was issued to the CCS provider
by a test stream within T24.
5. The ISUP REATTEMPT CIRCUIT BUSY reason will only be indicated if the stream issuing
the CC_SETUP_REQ primitive is bound to a circuit (ISUP_SCOPE_CT) and the circuit is busy with
another call.
CC SETUP COMPLETE REQ
Rules
For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to
Q.764, if a CCS provider conforming to Q.764 receives a CC_SETUP_COMPLETE_REQ for a call reference in the CCS ANSWERED state (CCS ICC ANSWERED), the CCS provider will ignore the
primitive.
CC SETUP COMPLETE IND
Rules
For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to
Q.764, if a CCS provider conforming to Q.764 issues a CC_SETUP_COMPLETE_IND for a call reference
in the CCS ANSWERED state, the CCS user may ignore the primitive.
Continuity Check Phase
CC CONT CHECK REQ

2011-10-28

237

Addendum for Q.764 Conformance

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:
1. 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 with an error of [CCNOADDR].
2. The address provided must be of scope ISUP_SCOPE_CT and must provide the identifier of the
circuit upon which the CCS user is requesting a continuity check.
3. The specified circuit identifier must be equipped else the CCS provider should response with
CC_ERROR_ACK and an error of [CCBADADDR].
CC CONT CHECK IND
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:
1.
Rules for addresses:
1. 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 with an error of [CCNOADDR].
2. The address provided must be of scope ISUP_SCOPE_CT and must provide the identifier of the
circuit upon which the CCS user is requesting a continuity check.
3. The specified circuit test address (circuit identifier) must be equipped else the CCS provider
should response with CC_ERROR_ACK and an error of [CCBADADDR].
CC CONT TEST REQ
This primitive is only supported when the Loop Back Acknowledgement is used as a national option
under Q.764. For compatibility with CCS providers not supporting the national option, if such
a CCS provider receives a CC_CONT_TEST_REQ while waiting for a CC_CONT_REPORT_IND, the CCS
provider should silently discard the primitive.
238

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

Parameters
cc call ref

Specifies the CCS provider call reference.

cc addr length
Indicates the length of the call control address (ISUP_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:
1. 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 with an error of [CCNOADDR].
2. The address provided must be the identifier of the circuit upon which the CCS user is requesting
a continuity check.
3. The specified circuit identifier must be equipped else the CCS provider should response with
CC_ERROR_ACK and an error of [CCBADADDR].
CC CONT TEST IND
This primitive is only supported when the Loop Back Acknowledgement is used as a national option
under Q.764. For compatibility with CCS providers not supporting the national option, such a
CCS provider will issue a CC_CONT_TEST_IND in response to a CC_CONT_CHECK_REQ following the
CC_OK_ACK.
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:
1. The CCS provider assigned call reference is used to associate an outstanding continuity test
indication (CC CONT CHECK IND or call setup indication CC_SETUP_IND including a continuity test (ISUP_NCI_CONT_CHECK_REQUIRED).
Rules for addresses:
1. 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 with an error of [CCNOADDR].
2. The address provided must be the identifier of the circuit upon which the CCS user is requesting
a continuity check.
2011-10-28

239

Addendum for Q.764 Conformance

3. The specified circuit identifier must be equipped else the CCS provider should response with
CC_ERROR_ACK and an error of [CCBADADDR].
CC CONT REPORT REQ
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.764 conforming CCS provider, the result parameter can be one of the following values:
ISUP_COT_SUCCESS
Indicates that the continuity check test was successful.
ISUP_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:
1. 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 with an error of [CCNOADDR].
2. The address provided must be the identifier of the circuit upon which the CCS user is requesting
a continuity check.
3. The specified circuit identifier must be equipped else the CCS provider should response with
CC_ERROR_ACK and an error of [CCBADADDR].
CC CONT REPORT IND
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.764 conforming CCS provider, the result parameter can be one of the following values:
ISUP_COT_SUCCESS
Indicates that the continuity check test was successful.
ISUP_COT_FAILURE
Indicates that the continuity check test failed.

240

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

Rules
Rules for call reference:
1.
Call Establishment Primitives
CC MORE INFO REQ
Rules
Rules for issuing primitive:
1. This primitive is not directly supported by Q.764 conforming CCS providers. For compatibility
with Q.931 conforming CCS providers, if the Q.764 conforming CCS provider receives a CC_
MORE_INFO_REQ in state CCS_WRES_SIND, it should invoke any interworking procedures and
silently discard the primitive.
CC MORE INFO IND
Rules
Rules for issuing primitive:
1. This primitive may optionally be issued by a Q.764 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
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.764 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.763.
cc subn offset
Specifies the offset of the subsequent number from the beginning of the block.
Rules
Rules for issuing primitive:
1. This primitive will only be issued before any CC_PROCEEDING_IND, CC_ALERTING_IND, CC_
PROGRESS_IND, or CC_IBI_IND has occurred on the stream while in the CCS_WCON_SREQ state. If
not, the CCS provider should respond with a CC_ERROR_ACK primitive with error [CCOUTSTATE].
2. This primitive must not be issued if the preceding CC_SETUP_REQ 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 with error [CCBADADDR].
2011-10-28

241

Indicates the progress event. The event can be any of the events listed in this addendum
under CC_PROGRESS_REQ.

cc flags

Indicates the options flags.

ISUP_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:
1. This primitive will only be issued by the CCS provider before any CC_IBI_IND has been issued
while in state CCS_WCON_SREQ.
Rules for progress event:
1. Q.764 conforming CCS providers must support the complete list of progress events listed above.
2. This primitive will not be issued by the CCS provider with event ISUP EVNT ALERTING or
event ISUP EVNT IBI: instead, a CC_ALERTING_IND or CC_IBI_IND event will be issued.
Rules for progress flags:
1. The flag ISUP EVNT PRESENTATION RESTRICTED cannot be set when the vent is
ISUP EVNT PROGRESS.
CC IBI REQ
Rules
CC IBI IND
Rules
Call Established Primitives
CC SUSPEND REQ
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.

246

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

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:
1. For Q.764 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
2. Indications of remote suspension of a call which is already remotely suspended will not be issued
by the CCS provider.
CC SUSPEND RES
Rules
Rules for issuing primitive:
For compatibility between CCS providers conforming to Q.931 and CCS providers conforming
to Q.764, if the CCS provider receives a CC_SUSPEND_RES in the CCS WRES SUSIND or CCS_
SUSPENDED states, the CCS provider should ignore the CC_SUSPEND_RES primitive and move directly
to the CCS_SUSPENDED state if it has not already done so.
CC SUSPEND REJECT REQ

2011-10-28

247

Addendum for Q.764 Conformance

Rules
Rules for issuing primitive:
For compatibility between CCS providers conforming to Q.931 and CCS providers conforming to
Q.764, if the CCS provider receives a CC_SUSPEND_REJECT_REQ in the CCS WRES SUSIND or
CCS_SUSPENDED states, the CCS provider should reply with a CC_ERROR_ACK primitive with error
CCNOTSUPP.
CC RESUME REQ
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
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
Rules
Rules for issuing primitive:
For compatibility between CCS providers conforming to Q.931 and CCS providers conforming
to Q.764, if the CCS provider receives a CC_RESUME_RES 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
Rules
Rules for issuing primitive:
248

Version 1.1 Rel. 1.20110510

Addendum for Q.764 Conformance

CC_CAUS_NOT_SUBSCRIBED
(no description)
CC_CAUS_OGC_BARRED_WITHIN_CUG
(no description)
CC_CAUS_ICC_BARRED WITHIN_CUG
(no description)
CC_CAUS_BC_NOT_AUTHORIZED
(no description)
CC_CAUS_BC_NOT_AVAILABLE
(no description)
CC_CAUS_INCONSISTENCY
(no description)
CC_CAUS_SERVICE_OPTION_NOT_AVAILABLE
(no description)
CC_CAUS_BC_NOT_IMPLEMENTED
(no description)
CC_CAUS_FACILITY_NOT_IMPLEMENTED
(no description)
CC_CAUS_RESTRICTED_BC_ONLY
(no description)
CC_CAUS_SERIVCE_OPTION_NOT_IMPLEMENTED
(no description)
CC_CAUS_USER_NOT_MEMBER_OF_CUG
(no description)
CC_CAUS_INCOMPATIBLE_DESTINATION
(no description)
CC_CAUS_NON_EXISTENT_CUG
(no description)
CC_CAUS_INVALID_TRANSIT_NTWK_SELECTION
(no description)
CC_CAUS_INVALID_MESSAGE
(no description)
CC_CAUS_MESSAGE_TYPE_NOT_IMPLEMENTED
(no description)
CC_CAUS_PARAMETER_NOT_IMPLEMENTED
(no description)
CC_CAUS_RECOVERY_ON_TIMER_EXPIRY
(no description)
252

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

CC_CAUS_PARAMETER_PASSED_ON
(no description)
CC_CAUS_MESSAGE_DISCARDED
(no description)
CC_CAUS_PROTOCOL_ERROR
(no description)
CC_CAUS_INTERWORKING
(no description)
CC_CAUS_UNALLOCATED_DEST_NUMBER
(no description)
CC_CAUS_UNKNOWN_BUSINESS_GROUP
(no description)
CC_CAUS_EXCHANGE_ROUTING_ERROR
(no description)
CC_CAUS_MISROUTED_CALL_TO_PORTED_NUMBER 26
(no description)
CC_CAUS_LNP_QOR_NUMBER_NOT_FOUND
(no description)
CC_CAUS_PREEMPTION
(no description)
CC_CAUS_PRECEDENCE_CALL_BLOCKED
(no description)
CC_CAUS_CALL_TYPE_INCOMPATIBLE
(no description)
CC_CAUS_GROUP_RESTRICTIONS
(no description)
Rules
CC RELEASE IND
Parameters
cc cause

Indicates the cause of the release. Cause can be one of the cause value listed in this
addendum under CC RELEASE REQ.

Rules
Management Primitives

2011-10-28

Addendum for Q.764 Conformance

ISUP_MAINTENANCE_ORIENTED
ISUP_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
Parameters
cc flags

Indicates the options flags.

ISUP_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.
ISUP_MAINTENANCE_ORIENTED
ISUP_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].

Indicates the options flags.

256

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

Indicates the options flags.

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
Parameters
cc flags

2011-10-28

259

Addendum for Q.764 Conformance

Indicates the options flags.

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

260

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

Parameters
cc flags

Indicates the options flags.

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

Q.764 Header File Listing

#ifndef __SS7_ISUPI_H__
#define __SS7_ISUPI_H__
/*
* ISUP addresss
*/
typedef struct isup_addr {
cc_ulong scope;
cc_ulong id;
cc_ulong cic;
} isup_addr_t;
#define
#define
#define
#define
#define
#define
#define

ISUP_SCOPE_CT
ISUP_SCOPE_CG
ISUP_SCOPE_TG
ISUP_SCOPE_SR
ISUP_SCOPE_SP
ISUP_SCOPE_DF
ISUP_SCOPE_CIC

1
2
3
4
5
6
7

/* the scope of the identifier */

/* the identifier within the scope */
/* circuit identification code within the scope */

/*
/*
/*
/*
/*
/*
/*

circuit scope */
circuit group scope */
trunk group scope */
signalling relation scope */
signalling point scope */
default scope */
for unidentified cic addresses */

/*
* Definitions for CCI for Q.764 Conforming CCS Providers.
*/
enum {
ISUP_INCOMING_INTERNATIONAL_EXCHANGE = 0x00000001UL,
ISUP_SUSPEND_NATIONALLY_PERFORMED = 0x00000002UL,
};
enum {
CMS_IDLE = 0,
CMS_WCON_BLREQ,
CMS_WRES_BLIND,

2011-10-28

261

Addendum for Q.764 Conformance

CMS_WACK_BLRES,
CMS_WCON_UBREQ,
CMS_WRES_UBIND,
CMS_WACK_UBRES,
CMS_WCON_RESREQ,
CMS_WRES_RESIND,
CMS_WACK_RESRES,
CMS_WCON_QRYREQ,
CMS_WRES_QRYIND,
CMS_WACK_QRYRES,
};
enum {
CKS_IDLE = 0,
CKS_WIND_CONT,
CKS_WRES_CONT,
CKS_WIND_CTEST,
CKS_WREQ_CTEST,
CKS_WIND_CCREP,
CKS_WREQ_CCREP,
CKS_WCON_RELREQ,
CKS_WRES_RELIND,
};
/*
* Circuit States:
*/
#define CTS_ICC
0x00000010
#define CTS_OGC
0x00000020
#define CTS_COT
0x00000040
#define CTS_LPA
0x00000080
#define CTS_COR
0x00000100
#define CTS_MASK 0x0000000f
#define CTS_DIRECTION(__val)
#define CTS_CONT_CHECK(__val)
#define CTS_MESSAGE(__val)
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

CTS_IDLE
CTS_WAIT_IAM
CTS_WAIT_CCR
CTS_WAIT_LPA
CTS_WAIT_SAM
CTS_WAIT_ACM
CTS_WAIT_ANM
CTS_ANSWERED
CTS_SUSPENDED
CTS_WAIT_RLC
CTS_SEND_RLC

#define
#define
#define
#define
#define
#define

CTS_ICC_WAIT_COT_CCR
CTS_OGC_WAIT_COT_CCR
CTS_ICC_WAIT_LPA_CCR
CTS_OGC_WAIT_LPA_CCR
CTS_ICC_WAIT_CCR
CTS_OGC_WAIT_CCR

262

(__val & (CTS_ICC|CTS_OGC))

(__val & (CTS_COT|CTS_LPA|CTS_COR))
(__val & CTS_MASK)

0x00000000
0x00000001
0x00000002
0x00000003
0x00000004
0x00000005
0x00000006
0x00000007
0x00000008
0x00000009
0x0000000a
(
(
(
(
(
(

CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC

|
|
|
|
|
|

CTS_COT | CTS_WAIT_CCR
CTS_COT | CTS_WAIT_CCR
CTS_LPA | CTS_WAIT_CCR
CTS_LPA | CTS_WAIT_CCR
CTS_WAIT_CCR )
CTS_WAIT_CCR )

)
)
)
)

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CTS_ICC_WAIT_COR_SAM
CTS_OGC_WAIT_COR_SAM
CTS_ICC_WAIT_COT_SAM
CTS_OGC_WAIT_COT_SAM
CTS_ICC_WAIT_LPA_SAM
CTS_OGC_WAIT_LPA_SAM
CTS_ICC_WAIT_SAM
CTS_OGC_WAIT_SAM
CTS_ICC_WAIT_COR_ACM
CTS_OGC_WAIT_COR_ACM
CTS_ICC_WAIT_COT_ACM
CTS_OGC_WAIT_COT_ACM
CTS_ICC_WAIT_LPA_ACM
CTS_OGC_WAIT_LPA_ACM
CTS_ICC_WAIT_ACM
CTS_OGC_WAIT_ACM
CTS_ICC_WAIT_ANM
CTS_OGC_WAIT_ANM
CTS_ICC_ANSWERED
CTS_OGC_ANSWERED
CTS_ICC_SUSPENDED
CTS_OGC_SUSPENDED
CTS_ICC_WAIT_RLC
CTS_OGC_WAIT_RLC
CTS_ICC_SEND_RLC
CTS_OGC_SEND_RLC

Addendum for Q.764 Conformance

(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(

/*
* Circuit, Group and MTP Flags
*/
#define CCTF_LOC_M_BLOCKED
#define CCTF_REM_M_BLOCKED
#define CCTF_LOC_H_BLOCKED
#define CCTF_REM_H_BLOCKED
#define CCTF_LOC_M_BLOCK_PENDING
#define CCTF_REM_M_BLOCK_PENDING
#define CCTF_LOC_H_BLOCK_PENDING
#define CCTF_REM_H_BLOCK_PENDING
#define CCTF_LOC_M_UNBLOCK_PENDING
#define CCTF_REM_M_UNBLOCK_PENDING
#define CCTF_LOC_H_UNBLOCK_PENDING
#define CCTF_REM_H_UNBLOCK_PENDING
#define CCTF_LOC_RESET_PENDING
#define CCTF_REM_RESET_PENDING
#define CCTF_LOC_QUERY_PENDING
#define CCTF_REM_QUERY_PENDING
#define CCTF_ORIG_SUSPENDED
#define CCTF_TERM_SUSPENDED
#define CCTF_UPT_PENDING
#define CCTF_LOC_S_BLOCKED
#define CCTF_LOC_G_BLOCK_PENDING
#define CCTF_REM_G_BLOCK_PENDING
#define CCTF_LOC_G_UNBLOCK_PENDING
#define CCTF_REM_G_UNBLOCK_PENDING
#define CCTF_COR_PENDING
#define CCTF_COT_PENDING

2011-10-28

CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC
CTS_ICC
CTS_OGC

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

)
)
)
)
)
)

0x00000001UL
0x00000002UL
0x00000004UL
0x00000008UL
0x00000010UL
0x00000020UL
0x00000040UL
0x00000080UL
0x00000100UL
0x00000200UL
0x00000400UL
0x00000800UL
0x00001000UL
0x00002000UL
0x00004000UL
0x00008000UL
0x00010000UL
0x00020000UL
0x00040000UL
0x00080000UL
0x00100000UL
0x00200000UL
0x00400000UL
0x00800000UL
0x01000000UL
0x02000000UL

263

Addendum for Q.764 Conformance

#define CCTF_LPA_PENDING
#define CCTM_OUT_OF_SERVICE

| \
| \
| \
\
\

)
#define CCTM_CONT_CHECK

( \
CCTF_COR_PENDING | \
CCTF_COT_PENDING | \
CCTF_LPA_PENDING | \
0 \
)

/*
Cause values for CC_CALL_REATTEMPT_IND
*/
/*
Cause values -- Q.764 conforming
*/
#define ISUP_REATTEMPT_DUAL_SIEZURE
#define ISUP_REATTEMPT_RESET
#define ISUP_REATTEMPT_BLOCKING
#define ISUP_REATTEMPT_T24_TIMEOUT
#define ISUP_REATTEMPT_UNEXPECTED
#define ISUP_REATTEMPT_COT_FAILURE
#define ISUP_REATTEMPT_CIRCUIT_BUSY

1UL
2UL
3UL
4UL
5UL
6UL
7UL

/*
Call types for CC_SETUP_REQ and CC_SETUP_IND
*/
/*
Call
*/
#define
#define
#define
#define
#define
#define
#define
#define
/*
Call
*/
/*
Call
*/
#define

264

types -- Q.764 Conforming

ISUP_CALL_TYPE_SPEECH
ISUP_CALL_TYPE_64KBS_UNRESTRICTED
ISUP_CALL_TYPE_3_1kHZ_AUDIO
ISUP_CALL_TYPE_64KBS_PREFERRED
ISUP_CALL_TYPE_2x64KBS_UNRESTRICTED
ISUP_CALL_TYPE_384KBS_UNRESTRICTED
ISUP_CALL_TYPE_1536KBS_UNRESTRICTED
ISUP_CALL_TYPE_1920KBS_UNRESTRICTED

0x00000000UL
0x00000002UL
0x00000003UL
0x00000006UL
0x00000007UL
0x00000008UL
0x00000009UL
0x0000000aUL

flags for CC_SETUP_REQ and CC_SETUP_IND

flags -- Q.764 Conforming

ISUP_NCI_ONE_SATELLITE_CCT

0x00000001UL

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

#define
#define
#define
#define
#define
#define
/*
Call
*/
/*
Call
*/
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
/*
Call
*/
/*
Call
*/
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

Addendum for Q.764 Conformance

ISUP_NCI_TWO_SATELLITE_CCT
ISUP_NCI_SATELLITE_MASK
ISUP_NCI_CONT_CHECK_REQUIRED
ISUP_NCI_CONT_CHECK_PREVIOUS
ISUP_NCI_CONT_CHECK_MASK
ISUP_NCI_OG_ECHO_CONTROL_DEVICE

0x00000002UL
0x00000003UL
0x00000004UL
0x00000008UL
0x0000000cUL
0x00000010UL

flags for CC_SETUP_REQ and CC_SETUP_IND

flags -- Q.764 Conforming

ISUP_FCI_INTERNATIONAL_CALL
ISUP_FCI_PASS_ALONG_E2E_METHOD_AVAIL
ISUP_FCI_SCCP_E2E_METHOD_AVAILABLE
ISUP_FCI_INTERWORKING_ENCOUNTERED
ISUP_FCI_E2E_INFORMATION_AVAILABLE
ISUP_FCI_ISDN_USER_PART_ALL_THE_WAY
ISUP_FCI_ISDN_USER_PART_NOT_REQUIRED
ISUP_FCI_ISDN_USER_PART_REQUIRED
ISUP_FCI_ORIGINATING_ACCESS_ISDN
ISUP_FCI_SCCP_CLNS_METHOD_AVAILABLE
ISUP_FCI_SCCP_CONS_METHOD_AVAILABLE

0x00000100UL
0x00000200UL
0x00000400UL
0x00000800UL
0x00001000UL
0x00002000UL
0x00004000UL
0x00008000UL
0x00010000UL
0x00020000UL
0x00040000UL

flags for CC_SETUP_REQ and CC_SETUP_IND

flags -- Q.764 Conforming

ISUP_CPC_MASK
ISUP_CPC_UNKNOWN
ISUP_CPC_OPERATOR_FRENCH
ISUP_CPC_OPERATOR_ENGLISH
ISUP_CPC_OPERATOR_GERMAN
ISUP_CPC_OPERATOR_RUSSIAN
ISUP_CPC_OPERATOR_SPANISH
ISUP_CPC_OPERATOR_LANGUAGE_6
ISUP_CPC_OPERATOR_LANGUAGE_7
ISUP_CPC_OPERATOR_LANGUAGE_8
ISUP_CPC_OPERATOR_CODE_9
ISUP_CPC_SUBSCRIBER_ORDINARY
ISUP_CPC_SUBSCRIBER_PRIORITY
ISUP_CPC_VOICE_BAND_DATA
ISUP_CPC_TEST_CALL
ISUP_CPC_SPARE
ISUP_CPC_PAYPHONE

0xff000000UL
0x00000000UL
0x01000000UL
0x02000000UL
0x03000000UL
0x04000000UL
0x05000000UL
0x06000000UL
0x07000000UL
0x08000000UL
0x09000000UL
0x0a000000UL
0x0b000000UL
0x0c000000UL
0x0d000000UL
0x0e000000UL
0x0f000000UL

/*
Flags for CC_CONT_REPORT_REQ and CC_CONT_REPORT_IND
*/
/*
Flags -- Q.764 Conforming
*/
#define ISUP_COT_FAILURE 0x00000000UL
#define ISUP_COT_SUCCESS 0x00000001UL

2011-10-28

265

Addendum for Q.764 Conformance

/*
Flags for CC_PROCEEDING, CC_ALERTING, CC_PROGRESS, CC_IBI
*/
/*
Flags -- Q.764 Conforming
*/
#define ISUP_BCI_NO_CHARGE
#define ISUP_BCI_CHARGE
#define ISUP_BCI_CHARGE_MASK
#define ISUP_BCI_SUBSCRIBER_FREE
#define ISUP_BCI_CONNECT_FREE
#define ISUP_BCI_CPS_MASK
#define ISUP_BCI_ORDINARY_SUBSCRIBER
#define ISUP_BCI_PAYPHONE
#define ISUP_BCI_CPI_MASK
#define ISUP_BCI_PASS_ALONG_E2E_METHOD_AVAIL
#define ISUP_BCI_SCCP_E2E_METHOD_AVAILABLE
#define ISUP_BCI_E2E_MASK
#define ISUP_BCI_INTERWORKING_ENCOUNTERED
#define ISUP_BCI_E2E_INFORMATION_AVAILABLE
#define ISUP_BCI_ISDN_USER_PART_ALL_THE_WAY
#define ISUP_BCI_HOLDING_REQUESTED
#define ISUP_BCI_TERMINATING_ACCESS_ISDN
#define ISUP_BCI_IC_ECHO_CONTROL_DEVICE
#define ISUP_BCI_SCCP_CLNS_METHOD_AVAILABLE
#define ISUP_BCI_SCCP_CONS_METHOD_AVAILABLE
#define ISUP_BCI_SCCP_METHOD_MASK
#define ISUP_OBCI_INBAND_INFORMATION_AVAILABLE
#define ISUP_OBCI_CALL_DIVERSION_MAY_OCCUR
#define ISUP_OBCI_ADDITIONAL_INFO_IN_SEG
#define ISUP_OBCI_MLPP_USER

0x00000001UL
0x00000002UL
0x00000003UL
0x00000004UL
0x00000008UL
0x0000000cUL
0x00000010UL
0x00000020UL
0x00000030UL
0x00000040UL
0x00000080UL
0x000000c0UL
0x00000100UL
0x00000200UL
0x00000400UL
0x00000800UL
0x00001000UL
0x00002000UL
0x00004000UL
0x00008000UL
0x0000c000UL
0x00010000UL
0x00020000UL
0x00040000UL
0x00080000UL

/*
Events for CC_PROGRESS_REQ and CC_PROGRESS_IND
*/
/*
Events -- Q.764 Conforming
*/
#define ISUP_EVNT_PRES_RESTRICT
#define ISUP_EVNT_ALERTING
#define ISUP_EVNT_PROGRESS
#define ISUP_EVNT_IBI
#define ISUP_EVNT_CFB
#define ISUP_EVNT_CFNA
#define ISUP_EVNT_CFU
#define ISUP_EVNT_MASK

0x80
0x01
0x02
0x03
0x04
0x05
0x06
0x7f

/*
/*
/*
/*
/*
/*

alerting */
progress */
in-band info or approp pattern avail */
call forwarded busy */
call forwarded no reply */
call forwarded unconditional */

/*
Cause values CC_CALL_FAILURE_IND -- Q.764 Conforming
*/
#define ISUP_CALL_FAILURE_COT_FAILURE
1UL
#define ISUP_CALL_FAILURE_RESET
2UL
#define ISUP_CALL_FAILURE_RECV_RLC
3UL
#define ISUP_CALL_FAILURE_BLOCKING
4UL
#define ISUP_CALL_FAILURE_T2_TIMEOUT
5UL
#define ISUP_CALL_FAILURE_T3_TIMEOUT
6UL

266

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

#define
#define
#define
#define
#define
#define
#define

ISUP_CALL_FAILURE_T6_TIMEOUT
ISUP_CALL_FAILURE_T7_TIMEOUT
ISUP_CALL_FAILURE_T8_TIMEOUT
ISUP_CALL_FAILURE_T9_TIMEOUT
ISUP_CALL_FAILURE_T35_TIMEOUT
ISUP_CALL_FAILURE_T38_TIMEOUT
ISUP_CALL_FAILURE_CIRCUIT_BUSY

Addendum for Q.764 Conformance

7UL
8UL
9UL
10UL
11UL
12UL
13UL

/*
* Q.850 Cause Values
*/
/*
Normal class
*/
#define CC_CAUS_UNALLOCATED_NUMBER
#define CC_CAUS_NO_ROUTE_TO_TRANSIT_NETWORK
#define CC_CAUS_NO_ROUTE_TO_DESTINATION
#define CC_CAUS_SEND_SPECIAL_INFO_TONE
#define CC_CAUS_MISDIALLED_TRUNK_PREFIX
#define CC_CAUS_PREEMPTION
#define CC_CAUS_PREEMPTION_CCT_RESERVED
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

1
2
3
4
5
8
9

/*
/*
/*
/*
/*
/*
/*

16
17
18
19
20
21
22
23
27
28

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

34
38
41
42
43
44

/*
/*
/*
/*
/*
/*

50
53
55
57
58

/*
/*
/*
/*
/*

2011-10-28

29 /*
31 /*

Unallocated (unassigned) number */

No route to specified transit network */
No route to destination */
Send special information tone */
Misdialled trunk prefix */
Preemption */
Preemption - circuit reserved for
reuse */
Normal call clearing */
User busy */
No user responding */
No answer from user (user alerted) */
Subscriber absent */
Call rejected */
Number changed */
Redirect to new destination */
Desitination out of order */
Invalid number format (address
incomplete) */
Facility rejected */
Normal unspecified */

Requested facility not subscribed */

Outgoing calls barred within CUG */
Incoming calls barred within CUG */
Bearer capability not authorized */
Bearer capability not presently
available */

267

Addendum for Q.764 Conformance

#define CC_CAUS_INCONSISTENCY

62 /* Inconsistency in designated outgoing

access information and subscriber
class */
#define CC_CAUS_SERVICE_OPTION_NOT_AVAILABLE 63 /* Service or option not available,
unspecified */
/*
Service or Option Not Implemented Class
*/
#define CC_CAUS_BC_NOT_IMPLEMENTED
65 /* Bearer capability not implemented */
#define CC_CAUS_FACILITY_NOT_IMPLEMENTED
69 /* Requested facility not implemented */
#define CC_CAUS_RESTRICTED_BC_ONLY
70 /* Only restricted digital information
bearer capability is available */
#define CC_CAUS_SERVICE_OPTION_NOT_IMPLEMENTED 79
/* Service or option not
implemented, unspecified */
/*
Invalid Message (e.g., Parameter out of Range) Class
*/
#define CC_CAUS_USER_NOT_MEMBER_OF_CUG
87 /* User not member of CUG */
#define CC_CAUS_INCOMPATIBLE_DESTINATION
88 /* Incompatible destination */
#define CC_CAUS_NON_EXISTENT_CUG
90 /* Non-existent CUG */
#define CC_CAUS_INVALID_TRANSIT_NTWK_SELECTION 91
/* Invalid transit network
selection */
#define CC_CAUS_INVALID_MESSAGE
95 /* Invalid message, unspecified */
/*
Protocol Error (e.g., Unknwon Message) Class
*/
#define CC_CAUS_MESSAGE_TYPE_NOT_IMPLEMENTED 97 /* Message typ non-existent or not
implemented. */
#define CC_CAUS_PARAMETER_NOT_IMPLEMENTED
99 /* Information element/Parameter
non-existent or not implemented */
#define CC_CAUS_RECOVERY_ON_TIMER_EXPIRY
102 /* Recovery on timer expiry */
#define CC_CAUS_PARAMETER_PASSED_ON
103 /* Parameter non-existent or not
implemented - passed on */
#define CC_CAUS_MESSAGE_DISCARDED
110 /* Message with unrecognized parameter
discarded */
#define CC_CAUS_PROTOCOL_ERROR
111 /* Protocol error, unspecified */
/*
Interworking Class
*/
#define CC_CAUS_INTERWORKING
127 /* Interworking, unspecified */
/*
* ANSI Standard Causes
*/
/*
Normal Class
*/
#define CC_CAUS_UNALLOCATED_DEST_NUMBER
23 /* Unallocated destination number */
#define CC_CAUS_UNKNOWN_BUSINESS_GROUP
24 /* Unknown business group */
#define CC_CAUS_EXCHANGE_ROUTING_ERROR
25 /* Exchange routing error */
#define CC_CAUS_MISROUTED_CALL_TO_PORTED_NUMBER 26
/* Misrouted call to a ported
number */
#define CC_CAUS_LNP_QOR_NUMBER_NOT_FOUND
27 /* Number portability Query on Release
(QoR) number not found. */
/*
Resource Unavailable Class
*/

268

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for Q.764 Conformance

#define CC_CAUS_RESOURCE_PREEMPTION
#define CC_CAUS_PRECEDENCE_CALL_BLOCKED
/*
Service or Option Not Available Class
*/
#define CC_CAUS_CALL_TYPE_INCOMPATIBLE

45 /* Preemption. */
46 /* Precedence call blocked.

51 /* Call type incompatible with service

request */
54 /* Call blocked due to group restrictions
*/

#define CC_CAUS_GROUP_RESTRICTIONS

/*
Management flags -- Q.764 Conforming
*/
#define ISUP_GROUP
0x00010000UL
#define ISUP_MAINTENANCE_ORIENTED
0x00000000UL
#define ISUP_HARDWARE_FAILURE_ORIENTED 0x00000001UL
/*
Management flags -- ANSI T1.113 Conforming
*/
#define ISUP_BLOCKING_WITHOUT_RELEASE
0x00000000UL
#define ISUP_BLOCKING_IMMEDIATE_RELEASE 0x00000001UL
#define ISUP_SOFTWARE_FAILURE_ORIENTED 0x00000002UL
#define ISUP_SRIS_MASK
#define ISUP_SRIS_NETWORK_INITIATED
#define ISUP_SRIS_USER_INITIATED

0x3
0x1
0x2

/*
Maintenance indications -- Q.764 Conforming
*/
#define ISUP_MAINT_T5_TIMEOUT
3UL
#define ISUP_MAINT_T13_TIMEOUT
4UL
#define ISUP_MAINT_T15_TIMEOUT
5UL
#define ISUP_MAINT_T17_TIMEOUT
6UL
#define ISUP_MAINT_T19_TIMEOUT
7UL
#define ISUP_MAINT_T21_TIMEOUT
8UL
#define ISUP_MAINT_T23_TIMEOUT
9UL
#define ISUP_MAINT_T25_TIMEOUT
10UL
#define ISUP_MAINT_T26_TIMEOUT
11UL
#define ISUP_MAINT_T27_TIMEOUT
12UL
#define ISUP_MAINT_T28_TIMEOUT
13UL
#define ISUP_MAINT_T36_TIMEOUT
14UL
#define ISUP_MAINT_UNEXPECTED_CGBA
15UL
#define ISUP_MAINT_UNEXPECTED_CGUA
16UL
#define ISUP_MAINT_UNEXPECTED_MESSAGE
17UL
#define ISUP_MAINT_UNEQUIPPED_CIC
18UL
#define ISUP_MAINT_SEGMENTATION_DISCARDED 19UL
#define ISUP_MAINT_USER_PART_UNEQUIPPED
20UL
#define ISUP_MAINT_USER_PART_UNAVAILABLE
21UL
#define ISUP_MAINT_USER_PART_AVAILABLE
22UL
#define ISUP_MAINT_USER_PART_MAN_MADE_BUSY 23UL
#define ISUP_MAINT_USER_PART_CONGESTED
24UL
#define ISUP_MAINT_USER_PART_UNCONGESTED
25UL
#define ISUP_MAINT_MISSING_ACK_IN_CGBA
26UL
#define ISUP_MAINT_MISSING_ACK_IN_CGUA
27UL
#define ISUP_MAINT_ABNORMAL_ACK_IN_CGBA
28UL

2011-10-28

/*
/*
/*
/*
/*
/*
/*

Q.752
Q.752
Q.752
Q.752
Q.752
Q.752
Q.752

12.5 on occrence */
12.16 1st and delta */
12.17 1st and delta */
12.1 1st and delta */
12.18 1st and delta */
12.19 1st and delta */
12.2 1st and delta */

/* Q.752 12.12 1st and delta */

/* Q.752 12.13 1st and delta */
/* Q.752 12.21 1st and delta */

/*
/*
/*
/*
/*
/*
/*
/*

Q.752
Q.752
Q.752
Q.752
Q.752
Q.752
Q.752
Q.752

10.1, 10.8 on occrence */

10.3, 10.9 on occrence */
10.2 on occrence */
/* XXX */
10.5, 10.11 on occrence */
10.6, 10.12 on occrence */
12.8 1st and delta */
12.9 1st and delta */
12.10 1st and delta */

269

Addendum for Q.764 Conformance

#define
#define
#define
#define
#define
#define
#endif

270

ISUP_MAINT_ABNORMAL_ACK_IN_CGUA
ISUP_MAINT_UNEXPECTED_BLA
ISUP_MAINT_UNEXPECTED_UBA
ISUP_MAINT_RELEASE_UNREC_INFO
ISUP_MAINT_RELEASE_FAILURE
ISUP_MAINT_MESSAGE_FORMAT_ERROR

29UL
30UL
31UL
32UL
33UL
34UL

/*
/*
/*
/*
/*
/*

Q.752
Q.752
Q.752
Q.752
Q.752
Q.752

12.11
12.14
12.15
12.22
12.23
12.20

1st
1st
1st
1st
1st
1st

and
and
and
and
and
and

delta
delta
delta
delta
delta
delta

*/
*/
*/
*/ /* XXX */
*/ /* XXX */
*/ /* XXX */

/* __SS7_ISUPI_H__ */

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for ETSI EN 300 356-1 V3.2.2 Conformance

This addendum describes the formats and rules that are specific to ETSI EN 300 356-1 V3.2.2. The
addendum must be used along with the generic CCI as defined in the main document, and the Q.764
conformance defined in [Addendum for Q.764 Conformance], page 225. when implementing a CCS
provider that will be configured with the EN 300 356-1 call processing layer.

Primitives and Rules for ETSI EN 300 356-1 V3.2.2 Conformance

The following are the additional rules that apply to the CCI primitives for ETSI EN 300 356-1
V3.2.2 compatibility.
Local Management Primitives
Call Setup Primitives
CC SETUP REQ
Parameters
Flags
Rules
CC SETUP IND
Parameters
cc call type
Specifies the call type to be set up. In addition to Q.764 values, for EN 300 356-1
V3.2.2 conforming CCS providers, the call type can also be one of the values listed
under "Call Type" below.
Call Type
The following call types are defined for EN 300 356-1 V3.2.2 conforming CCS providers in addition
to the Q.931 values shown in [Addendum for Q.931 Conformance], page 195.
CC_CALL_TYPE_3x64KBS_UNRESTRICTED
The call type is 3 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 3
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_4x64KBS_UNRESTRICTED
The call type is 4 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 4
x 64 kbit/s unrestricted digital information".
2011-10-28

271

Addendum for ETSI EN 300 356-1 V3.2.2 Conformance

CC_CALL_TYPE_5x64KBS_UNRESTRICTED
The call type is 5 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 5
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_6x64KBS_UNRESTRICTED
The call type is 6 x 64 kbit/s unrestricted digital information. This call type
corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of 384
kbit/s unrestricted digital information. This call type can be synonymous with
CC CALL TYPE 384KBS UNRESTRICTED.
CC_CALL_TYPE_7x64KBS_UNRESTRICTED
The call type is 7 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 7
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_8x64KBS_UNRESTRICTED
The call type is 8 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 8
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_9x64KBS_UNRESTRICTED
The call type is 9 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 9
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_10x64KBS_UNRESTRICTED
The call type is 10 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 10
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_11x64KBS_UNRESTRICTED
The call type is 11 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 11
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_12x64KBS_UNRESTRICTED
The call type is 12 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 12
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_13x64KBS_UNRESTRICTED
The call type is 13 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 13
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_14x64KBS_UNRESTRICTED
The call type is 14 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 14
x 64 kbit/s unrestricted digital information".
272

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Addendum for ETSI EN 300 356-1 V3.2.2 Conformance

CC_CALL_TYPE_15x64KBS_UNRESTRICTED
The call type is 15 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 15
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_16x64KBS_UNRESTRICTED
The call type is 16 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 16
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_17x64KBS_UNRESTRICTED
The call type is 17 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 17
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_18x64KBS_UNRESTRICTED
The call type is 18 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 28
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_19x64KBS_UNRESTRICTED
The call type is 19 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 19
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_20x64KBS_UNRESTRICTED
The call type is 20 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 20
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_21x64KBS_UNRESTRICTED
This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement
of "reserved for 21 x 64 kbit/s unrestricted digital information". The call type is 21 x
64 kbit/s unrestricted digital information.
CC_CALL_TYPE_22x64KBS_UNRESTRICTED
The call type is 22 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 22
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_23x64KBS_UNRESTRICTED
The call type is 23 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 23
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_24x64KBS_UNRESTRICTED
The call type is 24 x 64 kbit/s unrestricted digital information. This call type
corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "1536
kbit/s unrestricted digital information". This call type can be synonymous with
CC CALL TYPE 1536KBS UNRESTRICTED.
2011-10-28

273

Addendum for ETSI EN 300 356-1 V3.2.2 Conformance

CC_CALL_TYPE_25x64KBS_UNRESTRICTED
The call type is 25 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 25
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_26x64KBS_UNRESTRICTED
The call type is 26 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 26
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_27x64KBS_UNRESTRICTED
The call type is 27 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 27
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_28x64KBS_UNRESTRICTED
The call type is 28 x 64 kbit/s unrestricted digital information. This call type corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "reserved for 28
x 64 kbit/s unrestricted digital information".
CC_CALL_TYPE_29x64KBS_UNRESTRICTED
The call type is 29 x 64 kbit/s unrestricted digital information. This call type
corresponds to a EN 300 356-1 V3.2.2 transmission medium requirement of "1920
kbit/s unrestricted digital information". This call type can be synonymous with
CC CALL TYPE 1920KBS UNRESTRICTED.
Rules
Rules for call type:
1. Only multi-rate connection types for 384 kbit/s (6 x 64 kbit/s), 1536 kbit/s (24 x 64 kbit/s) and
1920 kbit/s (29 x 64 kbit/s) are supported. For EN 300 356-1 V3.2.2 compliant CCS providers.

ETSI EN 300 356-1 V3.2.2 Header File Listing

274

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Mapping of CCI Primitives to Q.931

Appendix A Mapping of CCI Primitives to Q.931

The mapping of CCI primitives to Q.931 primitives is shown in Table A.1. For the most part, this
mapping is a one to one mapping of service primitives, with the exception of Setup Response and
Setup Confirm.
CCI Primitive

Q.931 Primitive

CC_INFO_REQ
CC_INFO_ACK
CC_BIND_REQ
CC_BIND_ACK
CC_UNBIND_REQ
CC_ADDR_REQ
CC_ADDR_ACK
CC_OK_ACK
CC_ERROR_ACK
CC_SETUP_REQ
CC_SETUP_IND
CC_MORE_INFO_REQ
CC_MORE_INFO_IND
CC_INFORMATION_REQ
CC_INFORMATION_IND
CC_INFO_TIMEOUT_IND
CC_SETUP_RES
CC_SETUP_CON
CC_SETUP_COMPLETE_REQ
CC_SETUP_COMPLETE_IND
CC_PROCEEDING_REQ
CC_PROCEEDING_IND
CC_ALERTING_REQ
CC_ALERTING_IND
CC_PROGRESS_REQ
CC_PROGRESS_IND
CC_CONNECT_REQ
CC_CONNECT_IND
CC_SUSPEND_REQ
CC_SUSPEND_IND
CC_SUSPEND_RES
CC_SUSPEND_CON
CC_SUSPEND_REJECT_REQ
CC_SUSPEND_REJECT_IND
CC_RESUME_REQ
CC_RESUME_IND
CC_RESUME_RES
CC_RESUME_CON
CC_RESUME_REJECT_REQ
CC_RESUME_REJECT_IND
CC_CALL_REATTEMPT_IND
CC_CALL_FAILURE_IND
CC_REJECT_REQ
CC_REJECT_IND
CC_DISCONNECT_REQ
CC_DISCONNECT_IND
CC_RELEASE_REQ
CC_RELEASE_IND
CC_RELEASE_RES

Setup Request
Setup Indication
More Info Request
More Info Indication
Information Request
Information Indication
Timeout Indication
Proceeding, Alerting, Progress Request; Setup Response
Proceeding, Alerting, Progress Indication; Setup Confirm
Setup Complete Request
Setup Complete Indication
Proceeding Request
Proceeding Indication
Alerting Request
Alerting Indication
Progress Request
Progress Indication
Setup Response
Setup Confirm
Suspend Request, Notify Request
Suspend Indication, Notify Indication
Suspend Response
Suspend Confirm
Suspend Reject Request
Suspend Reject Indication
Resume Request, Notify Request
Resume Indication, Notify Indication
Resume Response
Resume Confirm
Resume Reject Request
Resume Reject Indication

Error Indication, Status Indication, Restart Indication

Reject Request, Release Complete Request
Reject Indication, Release Complete Indication
Disconnect Request
Disconnect Indication
Release Request
Release Indication
Release Complete Request

Table A.1: Mapping of CCI primitives to Q.931 Primitives

In Q.931 the Setup Response and Setup Confirm primitives and issued only once the voice channel
is connected. In OpenSS7 CCI, the CC_SETUP_RES and CC_SETUP_CON primitives are used to accept
2011-10-28

275

Appendix A: Mapping of CCI Primitives to Q.931

the addressing and assign a stream and correspond to the first backward message (i.e, Processing,
Alerting or Progress Request or Indication; and Setup Indication or Confirm).

276

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Mapping of CCI Primitives to Q.764

Appendix B Mapping of CCI Primitives to Q.764

The mapping of CCI primitives to Q.764 primitives is shown in Table B.1. For the most part this is a
one to one mapping of service primitives, with the exception of Setup Response and Setup Confirm.
CCI Primitive

Q.764 Primitive

CC_INFO_REQ
CC_INFO_ACK
CC_BIND_REQ
CC_BIND_ACK
CC_UNBIND_REQ
CC_ADDR_REQ
CC_ADDR_ACK
CC_OK_ACK
CC_ERROR_ACK
CC_SETUP_REQ
CC_SETUP_IND
CC_MORE_INFO_REQ
CC_MORE_INFO_IND
CC_INFORMATION_REQ
CC_INFORMATION_IND
CC_INFO_TIMEOUT_IND
CC_SETUP_RES
CC_SETUP_CON
CC_PROCEEDING_REQ
CC_PROCEEDING_IND
CC_ALERTING_REQ
CC_ALERTING_IND
CC_PROGRESS_REQ
CC_PROGRESS_IND
CC_CONNECT_REQ
CC_CONNECT_IND
CC_SUSPEND_REQ
CC_SUSPEND_IND
CC_RESUME_REQ
CC_RESUME_IND
CC_CALL_REATTEMPT_IND
CC_CALL_FAILURE_IND
CC_REJECT_REQ
CC_REJECT_IND
CC_RELEASE_REQ
CC_RELEASE_IND
CC_RELEASE_RES
CC_RELEASE_CON
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

Setup Request
Setup Indication

Information Request
Information Indication

Proceeding, Alerting, Progress Request; Setup Response

Proceeding, Alerting, Progress Indication; Setup Confirm
Proceeding Request
Proceeding Indication
Alerting Request
Alerting Indication
Progress Request
Progress Indication
Setup Response
Setup Confirm
Suspend Request
Suspend Indication
Resume Request
Resume Indication
Reattempt Indication
Failure Indication
Release Request
Release Indication
Release Request
Release Indication
Release Response
Release Confirm
Reset Request
Reset Indication
Reset Response
Reset Confirm
Blocking Request
Blocking Indication
Blocking Response
Blocking Confirm
Unblocking Request
Unblocking Indication
Unblocking Response

Table B.1: Mapping of CCI primitives to Q.764 Primitives

In Q.764 the Setup Response and Setup Confirm primitives and issued only once the voice channel
is connected. In OpenSS7 CCI, the CC_SETUP_RES and CC_SETUP_CON primitives are used to accept
2011-10-28

277

Appendix B: Mapping of CCI Primitives to Q.764

the addressing and assign a stream and correspond to the first backward message (i.e, Processing,
Alerting or Progress Request or Indication; and Setup Indication or Confirm).

278

Version 1.1 Rel. 1.20110510

#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

CC_INFO_REQ
CC_OPTMGMT_REQ
CC_BIND_REQ
CC_UNBIND_REQ
CC_ADDR_REQ
CC_SETUP_REQ
CC_MORE_INFO_REQ
CC_INFORMATION_REQ
CC_CONT_CHECK_REQ
CC_CONT_TEST_REQ
CC_CONT_REPORT_REQ
CC_SETUP_RES
CC_PROCEEDING_REQ
CC_ALERTING_REQ
CC_PROGRESS_REQ
CC_IBI_REQ
CC_DISCONNECT_REQ
CC_CONNECT_REQ
CC_SETUP_COMPLETE_REQ
CC_FORWXFER_REQ
CC_SUSPEND_REQ
CC_SUSPEND_RES
CC_SUSPEND_REJECT_REQ
CC_RESUME_REQ
CC_RESUME_RES
CC_RESUME_REJECT_REQ
CC_REJECT_REQ
CC_RELEASE_REQ
CC_RELEASE_RES
CC_NOTIFY_REQ
CC_RESTART_REQ
CC_RESET_REQ
CC_RESET_RES
CC_BLOCKING_REQ
CC_BLOCKING_RES
CC_UNBLOCKING_REQ
CC_UNBLOCKING_RES
CC_QUERY_REQ
CC_QUERY_RES
CC_STOP_REQ

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#define
#define
#define
#define

CC_OK_ACK
CC_ERROR_ACK
CC_INFO_ACK
CC_BIND_ACK

64
65
66
67

2011-10-28

/* ISDN only */
/* ISUP only */
/* ISUP only */
/* ISUP only */

/* (same as CC_DISCONNECT_REQ in ISDN) */

/* ISDN only */
/* ISUP only */
/* ISDN only */
/* ISDN only */
/* ISDN only */
/* ISDN only */
/* ISDN only */
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

ISUP
ISDN
ISDN
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP

only
only
only
only
only
only
only
only
only
only
only
only

*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/

283

Appendix E: CCI Header File Listing

#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define
#define

CC_OPTMGMT_ACK
CC_ADDR_ACK
CC_CALL_REATTEMPT_IND
CC_SETUP_IND
CC_MORE_INFO_IND
CC_INFORMATION_IND
CC_CONT_CHECK_IND
CC_CONT_TEST_IND
CC_CONT_REPORT_IND
CC_SETUP_CON
CC_PROCEEDING_IND
CC_ALERTING_IND
CC_PROGRESS_IND

68
69
70
71
72
73
74
75
76
77
78
79
80

#define CC_IBI_IND

81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

CC_DISCONNECT_IND
CC_CONNECT_IND
CC_SETUP_COMPLETE_IND
CC_FORWXFER_IND
CC_SUSPEND_IND
CC_SUSPEND_CON
CC_SUSPEND_REJECT_IND
CC_RESUME_IND
CC_RESUME_CON
CC_RESUME_REJECT_IND
CC_REJECT_IND
CC_CALL_FAILURE_IND
CC_RELEASE_IND
CC_RELEASE_CON
CC_NOTIFY_IND
CC_RESTART_CON
CC_STATUS_IND
CC_ERROR_IND
CC_DATALINK_FAILURE_IND
CC_INFO_TIMEOUT_IND
CC_RESET_IND
CC_RESET_CON
CC_BLOCKING_IND
CC_BLOCKING_CON
CC_UNBLOCKING_IND
CC_UNBLOCKING_CON
CC_QUERY_IND
CC_QUERY_CON
CC_STOP_IND
CC_MAINT_IND
CC_START_RESET_IND

/*
/*
/*
/*
/*
/*
/*

ISUP
recv
ISDN
recv
ISUP
ISUP
ISUP

only */
IAM */
only */
SAM */
only */
only */
only */

/* recv ACM w/ no indication if proceeding not sent before */

/* recv ACM w/ subscriber free indication */
/* recv ACM w/ no indication and ATP parameter and call
proceeding sent */
/* recv ACM or CPG w/ inband info (same as
CC_DISCONNECT_IND in ISDN) */

/* ISDN only */
/* ISUP only */
/* ISDN only */
/* ISDN only */
/*
/*
/*
/*

ISDN
ISDN
ISDN
ISUP

only
only
only
only

*/
*/
*/
(ERROR_IND?) */

/*
/*
/*
/*
/*

ISDN
ISDN
ISDN
ISDN
ISDN

only
only
only
only
only

*/
*/
*/
(CALL_FAILURE_IND?) */
*/

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP
ISUP

only
only
only
only
only
only
only
only
only
only
only

*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/

/*
* Interface state
*/
enum {
CCS_UNBND,
CCS_IDLE,
CCS_WIND_SETUP,
CCS_WREQ_SETUP,

284

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CCI Header File Listing

CCS_WREQ_MORE,
CCS_WIND_MORE,
CCS_WREQ_INFO,
CCS_WIND_INFO,
CCS_WACK_INFO,
CCS_WCON_SREQ,
CCS_WRES_SIND,
CCS_WREQ_CCREP,
CCS_WIND_CCREP,
CCS_WREQ_PROCEED,
CCS_WIND_PROCEED,
CCS_WACK_PROCEED,
CCS_WREQ_ALERTING,
CCS_WIND_ALERTING,
CCS_WACK_ALERTING,
CCS_WREQ_PROGRESS,
CCS_WIND_PROGRESS,
CCS_WACK_PROGRESS,
CCS_WREQ_IBI,
CCS_WIND_IBI,
CCS_WACK_IBI,
CCS_WREQ_CONNECT,
CCS_WIND_CONNECT,
CCS_WCON_CREQ,
CCS_WACK_FORWXFER,
CCS_WCON_SUSREQ,
CCS_CONNECTED,
CCS_SUSPENDED,
CCS_WIND_RELEASE,
CCS_WCON_RELREQ,
CCS_WRES_RELIND,
CCS_UNUSABLE,
};
typedef struct CC_ok_ack {
cc_ulong cc_primitive;
cc_ulong cc_correct_prim;
cc_ulong cc_state;
cc_ulong cc_call_ref;
} CC_ok_ack_t;

/*
/*
/*
/*

always CC_OK_ACK */
primitive being acknowledged */
current state */
call reference */

typedef struct CC_error_ack {

cc_ulong cc_primitive;
cc_ulong cc_error_primitive;
cc_ulong cc_error_type;
cc_ulong cc_unix_error;
cc_ulong cc_state;
cc_ulong cc_call_ref;
} CC_error_ack_t;

/*
/*
/*
/*
/*
/*

always CC_ERROR_ACK */
primitive in error */
CCI error code */
UNIX system error code */
current state */
call reference */

enum {
CCSYSERR = 0,
CCOUTSTATE,
CCBADADDR,
CCBADDIGS,
CCBADOPT,

2011-10-28

285

Appendix E: CCI Header File Listing

CCNOADDR,
CCADDRBUSY,
CCBADCLR,
CCBADTOK,
CCBADFLAG,
CCNOTSUPP,
CCBADPRIM,
CCACCESS,
};
typedef struct CC_info_req {
cc_ulong cc_primitive;
} CC_info_req_t;
typedef struct CC_info_ack {
cc_ulong cc_primitive;
/* FIXME ... more ...
} CC_info_ack_t;

/* always CC_INFO_REQ */

/* always CC_INFO_ACK */
*/

typedef struct CC_bind_req {

cc_ulong cc_primitive;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
cc_ulong cc_setup_ind;
cc_ulong cc_bind_flags;
} CC_bind_req_t;

/*
/*
/*
/*
/*

always CC_BIND_REQ */
length of address */
offset of address */
req # of setup inds to be queued */
bind options flags */

/*
Flags associated with CC_BIND_REQ
*/
#define CC_DEFAULT_LISTENER
#define CC_TOKEN_REQUEST
#define CC_MANAGEMENT
#define CC_TEST
#define CC_MAINTENANCE
#define CC_MONITOR

0x000000001UL
0x000000002UL
0x000000004UL
0x000000008UL
0x000000010UL
0x000000020UL

typedef struct CC_bind_ack {

cc_ulong cc_primitive;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
cc_ulong cc_setup_ind;
cc_ulong cc_token_value;
} CC_bind_ack_t;

/*
/*
/*
/*
/*

typedef struct CC_unbind_req {

cc_ulong cc_primitive;
} CC_unbind_req_t;

/* always CC_UNBIND_REQ */

typedef struct CC_addr_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
} CC_addr_req_t;

/* always CC_ADDR_REQ */
/* call reference */

typedef struct CC_addr_ack {

cc_ulong cc_primitive;

286

always CC_BIND_ACK */
length of address */
offset of address */
setup indications */
setup response token value */

/* always CC_ADDR_ACK */

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

cc_ulong
cc_ulong
cc_ulong
cc_ulong
cc_ulong
} CC_addr_ack_t;

cc_bind_length;
cc_bind_offset;
cc_call_ref;
cc_conn_length;
cc_conn_offset;

CCI Header File Listing

/*
/*
/*
/*
/*

length of bound address */

offset of bound address */
call reference */
length of connected address */
offset of connected address */

typedef struct CC_optmgmt_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
cc_ulong cc_opt_flags;
} CC_optmgmt_req_t;

/*
/*
/*
/*
/*

always CC_OPTMGMT_REQ */
call reference */
length of option values */
offset of option values */
option flags */

typedef struct CC_optmgmt_ack {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
cc_ulong cc_opt_flags;
} CC_optmgmt_ack_t;

/*
/*
/*
/*
/*

always CC_OPTMGMT_ACK */
call reference */
length of option values */
offset of option values */
option flags */

typedef struct CC_setup_req {

cc_ulong cc_primitive;
cc_ulong cc_user_ref;
cc_ulong cc_call_type;
cc_ulong cc_call_flags;
cc_ulong cc_cdpn_length;
cc_ulong cc_cdpn_offset;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_setup_req_t;

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

typedef struct CC_call_reattempt_ind {

cc_ulong cc_primitive;
cc_ulong cc_user_ref;
cc_ulong cc_reason;
} CC_call_reattempt_ind_t;

/* always CC_CALL_REATTEMPT_IND */
/* user call reference */
/* reason for reattempt */

typedef struct CC_setup_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_call_type;
cc_ulong cc_call_flags;
cc_ulong cc_cdpn_length;
cc_ulong cc_cdpn_offset;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_setup_ind_t;

/*
/*
/*
/*
/*
/*
/*
/*
/*
/*

typedef struct CC_setup_res {

2011-10-28

287

Appendix E: CCI Header File Listing

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_token_value;
} CC_setup_res_t;

/* always CC_SETUP_RES */
/* call reference */
/* call response token value */

typedef struct CC_setup_con {

cc_ulong cc_primitive;
cc_ulong cc_user_ref;
cc_ulong cc_call_ref;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_setup_con_t;

/*
/*
/*
/*
/*

typedef struct CC_cont_check_req {

cc_ulong cc_primitive;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_cont_check_req_t;

/* always CC_CONT_CHECK_REQ */
/* adress length */
/* adress offset */

typedef struct CC_cont_check_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_cont_check_ind_t;

/*
/*
/*
/*

typedef struct CC_cont_test_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_token_value;
} CC_cont_test_req_t;

/* always CC_CONT_TEST_REQ */
/* call reference */
/* token value */

typedef struct CC_cont_test_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_cont_test_ind_t;

/*
/*
/*
/*

always CC_CONT_TEST_IND */
call reference */
adress length */
adress offset */

typedef struct CC_cont_report_req {

cc_ulong cc_primitive;
cc_ulong cc_user_ref;
cc_ulong cc_call_ref;
cc_ulong cc_result;
} CC_cont_report_req_t;

/*
/*
/*
/*

always CC_CONT_REPORT_REQ */
user call reference */
call reference */
result of continuity check */

typedef struct CC_cont_report_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_result;
} CC_cont_report_ind_t;

/* always CC_CONT_REPORT_IND */
/* call reference */
/* result of continuity check */

typedef struct CC_more_info_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_opt_length;

288

always CC_SETUP_CON */
user call reference */
call reference */
connecting address length */
connecting address offset */

always CC_CONT_CHECK_IND */
call reference */
adress length */
adress offset */

/* always CC_MORE_INFO_REQ */
/* call reference */
/* optional parameter length */

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

cc_ulong cc_opt_offset;
} CC_more_info_req_t;

CCI Header File Listing

/* optional parameter offset */

typedef struct CC_more_info_ind {

cc_ulong cc_primitive;
cc_ulong cc_user_ref;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_more_info_ind_t;

/*
/*
/*
/*

always CC_MORE_INFO_IND */
user call reference */
optional parameter length */
optional parameter offset */

typedef struct CC_information_req {

cc_ulong cc_primitive;
cc_ulong cc_user_ref;
cc_ulong cc_subn_length;
cc_ulong cc_subn_offset;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_information_req_t;

/*
/*
/*
/*
/*
/*

always CC_INFORMATION_REQ */
call reference */
subsequent number length */
subsequent number offset */
optional parameter length */
optional parameter offset */

typedef struct CC_information_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_subn_length;
cc_ulong cc_subn_offset;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_information_ind_t;

/*
/*
/*
/*
/*
/*

always CC_INFORMATION_IND */
call reference */
subsequent number length */
subsequent number offset */
optional parameter length */
optional parameter offset */

typedef struct CC_info_timeout_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
} CC_info_timeout_ind_t;

/* always CC_INFO_TIMEOUT_IND */
/* call reference */

typedef struct CC_proceeding_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_flags;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_proceeding_req_t;

/*
/*
/*
/*
/*

always CC_PROCEEDING_REQ */
call reference */
proceeding flags */
optional parameter length */
optional parameter offset */

typedef struct CC_proceeding_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_flags;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_proceeding_ind_t;

/*
/*
/*
/*
/*

always CC_PROCEEDING_IND */
call reference */
proceeding flags */
optional parameter length */
optional parameter offset */

typedef struct CC_alerting_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_flags;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_alerting_req_t;

/*
/*
/*
/*
/*

always CC_ALERTING_REQ */
call reference */
alerting flags */
optional parameter length */
optional parameter offset */

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_flags;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_connect_req_t;

/*
/*
/*
/*
/*

always CC_CONNECT_REQ */
call reference */
connect flags */
optional parameter length */
optional parameter offset */

/*
/*
/*
/*

always CC_CONNECT_IND */
call reference */
connect flags */
optional parameter length */

typedef struct CC_connect_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_flags;
cc_ulong cc_opt_length;

290

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

cc_ulong cc_opt_offset;
} CC_connect_ind_t;

CCI Header File Listing

/* optional parameter offset */

typedef struct CC_setup_complete_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_resume_con_t;

/*
/*
/*
/*

always CC_RESUME_CON */
call reference */
optional parameter length */
optional parameter offset */

/*
/*
/*
/*

always CC_RESUME_REJECT_REQ */
call reference */
cause value */
optional parameter length */

typedef struct CC_resume_reject_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_cause;
cc_ulong cc_opt_length;

292

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

cc_ulong cc_opt_offset;
} CC_resume_reject_req_t;

CCI Header File Listing

/* optional parameter offset */

typedef struct CC_resume_reject_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_cause;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_resume_reject_ind_t;

/*
/*
/*
/*
/*

always CC_RESUME_REJECT_IND */
call reference */
cause value */
optional parameter length */
optional parameter offset */

typedef struct CC_reject_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_cause;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_reject_req_t;

/*
/*
/*
/*
/*

always CC_REJECT_REQ */
call reference */
cause value */
optional parameter length */
optional parameter offset */

typedef struct CC_reject_ind {

cc_ulong cc_primitive;
cc_ulong cc_user_ref;
cc_ulong cc_cause;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_reject_ind_t;

/*
/*
/*
/*
/*

always CC_REJECT_IND */
user call reference */
cause value */
optional parameter length */
optional parameter offset */

typedef struct CC_error_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
} CC_error_ind_t;

/* always CC_ERROR_IND */
/* call reference */

typedef struct CC_call_failure_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_reason;
cc_ulong cc_cause;
} CC_call_failure_ind_t;

/*
/*
/*
/*

always CC_CALL_FAILURE_IND */
call reference */
reason for failure */
cause to use in release */

typedef struct CC_disconnect_req {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_cause;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_disconnect_req_t;

/*
/*
/*
/*
/*

always CC_DISCONNECT_REQ */
call reference */
cause value */
optional parameter length */
optional parameter offset */

typedef struct CC_disconnect_ind {

cc_ulong cc_primitive;
cc_ulong cc_call_ref;
cc_ulong cc_cause;
cc_ulong cc_opt_length;
cc_ulong cc_opt_offset;
} CC_disconnect_ind_t;

/*
/*
/*
/*
/*

always CC_DISCONNECT_IND */
call reference */
cause value */
optional parameter length */
optional parameter offset */

/*
/*
/*
/*

always CC_BLOCKING_REQ */
blocking flags */
address length */
address offset */

typedef struct CC_blocking_ind {

cc_ulong cc_primitive;
cc_ulong cc_flags;

2011-10-28

/* always CC_BLOCKING_IND */
/* blocking flags */

295

cc_ulong cc_primitive;
cc_ulong cc_flags;

296

/* always CC_QUERY_IND */
/* query flags */

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_query_ind_t;

CCI Header File Listing

/* address length */
/* address offset */

typedef struct CC_query_res {

cc_ulong cc_primitive;
cc_ulong cc_flags;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_query_res_t;

/*
/*
/*
/*

always CC_QUERY_RES */
blocking flags */
address length */
address offset */

typedef struct CC_query_con {

cc_ulong cc_primitive;
cc_ulong cc_flags;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_query_con_t;

/*
/*
/*
/*

always CC_QUERY_CON */
query flags */
address length */
address offset */

typedef struct CC_maint_ind {

cc_ulong cc_primitive;
cc_ulong cc_reason;
cc_ulong cc_call_ref;
cc_ulong cc_addr_length;
cc_ulong cc_addr_offset;
} CC_maint_ind_t;

/*
/*
/*
/*
/*

always CC_MAINT_IND */
reason for indication */
call reference */
length of address */
length of address */

union CC_primitives {
cc_ulong cc_primitive;
CC_ok_ack_t ok_ack;
CC_error_ack_t error_ack;
CC_info_req_t info_req;
CC_info_ack_t info_ack;
CC_bind_req_t bind_req;
CC_bind_ack_t bind_ack;
CC_unbind_req_t unbind_req;
CC_addr_req_t addr_req;
CC_addr_ack_t addr_ack;
CC_optmgmt_req_t optmgmt_req;
CC_optmgmt_ack_t optmgmt_ack;
CC_setup_req_t setup_req;
CC_call_reattempt_ind_t call_reattempt_ind;
CC_setup_ind_t setup_ind;
CC_setup_res_t setup_res;
CC_setup_con_t setup_con;
CC_cont_check_req_t cont_check_req;
CC_cont_check_ind_t cont_check_ind;
CC_cont_test_req_t cont_test_req;
CC_cont_test_ind_t cont_test_ind;
CC_cont_report_req_t cont_report_req;
CC_cont_report_ind_t cont_report_ind;
CC_more_info_req_t more_info_req;
CC_more_info_ind_t more_info_ind;
CC_information_req_t information_req;
CC_information_ind_t information_ind;
CC_proceeding_req_t proceeding_req;
CC_proceeding_ind_t proceeding_ind;

2011-10-28

297

Appendix E: CCI Header File Listing

CC_alerting_req_t alerting_req;
CC_alerting_ind_t alerting_ind;
CC_progress_req_t progress_req;
CC_progress_ind_t progress_ind;
CC_ibi_req_t ibi_req;
CC_ibi_ind_t ibi_ind;
CC_connect_req_t connect_req;
CC_connect_ind_t connect_ind;
CC_setup_complete_req_t setup_complete_req;
CC_setup_complete_ind_t setup_complete_ind;
CC_forwxfer_req_t forwxfer_req;
CC_forwxfer_ind_t forwxfer_ind;
CC_suspend_req_t suspend_req;
CC_suspend_ind_t suspend_ind;
CC_suspend_res_t suspend_res;
CC_suspend_con_t suspend_con;
CC_suspend_reject_req_t suspend_reject_req;
CC_suspend_reject_ind_t suspend_reject_ind;
CC_resume_req_t resume_req;
CC_resume_ind_t resume_ind;
CC_resume_res_t resume_res;
CC_resume_con_t resume_con;
CC_resume_reject_req_t resume_reject_req;
CC_resume_reject_ind_t resume_reject_ind;
CC_reject_req_t reject_req;
CC_reject_ind_t reject_ind;
CC_error_ind_t error_ind;
CC_call_failure_ind_t call_failure_ind;
CC_disconnect_req_t disconnect_req;
CC_disconnect_ind_t disconnect_ind;
CC_release_req_t release_req;
CC_release_ind_t release_ind;
CC_release_res_t release_res;
CC_release_con_t release_con;
CC_restart_req_t restart_req;
CC_restart_con_t restart_con;
CC_status_ind_t status_ind;
CC_datalink_failure_ind_t datalink_failure_ind;
CC_reset_req_t reset_req;
CC_reset_ind_t reset_ind;
CC_reset_res_t reset_res;
CC_reset_con_t reset_con;
CC_blocking_req_t blocking_req;
CC_blocking_ind_t blocking_ind;
CC_blocking_res_t blocking_res;
CC_blocking_con_t blocking_con;
CC_unblocking_req_t unblocking_req;
CC_unblocking_ind_t unblocking_ind;
CC_unblocking_res_t unblocking_res;
CC_unblocking_con_t unblocking_con;
CC_query_req_t query_req;
CC_query_ind_t query_ind;
CC_query_res_t query_res;
CC_query_con_t query_con;
CC_maint_ind_t maint_ind;
};

298

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

#endif

2011-10-28

CCI Header File Listing

/* __SS7_CCI_H__ */

299

Call Control Interface (CCI)

Glossary

Glossary
Signalling Data Link Service Data Unit
A grouping of SDL user data whose boundaries are preserved from one end of the
signalling data link connection to the other.
Data transfer
The phase in connection and connectionless modes that supports the transfer of data
between to signalling data link users.
SDL provider
The signalling data link layer protocol that provides the services of the signalling data
link interface.
SDL user

The user-level application or user-level or kernel-level protocol that accesses the services
of the signalling data link layer.

Local management
The phase in connection and connectionless modes in which a SDL user initializes a
stream and attaches a PPA address to the stream. Primitives in this phase generate
local operations only.
PPA

The point at which a system attaches itself to a physical communications medium.

PPA identifier
An identifier of a particular physical medium over which communication transpires.

2011-10-28

301

Call Control Interface (CCI)

Acronyms

Acronyms
ITU-T
PPA
SDLI
SDL SDU
SDL

2011-10-28

International Telecommunications Union - Telecom Sector

Physical Point of Attachment
Signalling Data Link Interface
Signalling Data Link Service Data Unit
Signalling Data Link

303

Call Control Interface (CCI)

References

References
1. ITU-T Recommendation X.210, (Geneva, 1993), Information Technology Open Systems
Interconnection Basic reference model: Conventions for the definition of OSI services,
ISO/IEC 10731:1994.
2. ITU-T Recommendation X.217, (Geneva, 1995), Information Technology Open Systems
Interconnection Service definition for the Association Control Service Element, ISO/IEC
8649:1996.
3. ITU-T Recommendation X.227, (Geneva, 1995), Information Technology Open Systems
Interconnection Connection-oriented protocol for the Association Control Service Element:
Protocol Specification, ISO/IEC 8650-1.
4. ITU-T Recommendation X.237, (Geneva, 1995), Information Technology Open Systems Interconnection Connectionless protocol for the Association Control Service Element: Protocol
Specification, ISO/IEC 10035-1 : 1995.
5. ITU-T Recommendation X.216, (Geneva, 1994), Information Technology Open Systems
Interconnection Presentation service definition, ISO/IEC 8822:1994.
6. ITU-T Recommendation X.226, (Geneva, 1994), Information Technology Open Systems Interconnection Connection-oriented presentation protocol: Protocol specification, ISO/IEC
8823-1:1994.
7. ITU-T Recommendation X.236, (Geneva, 1995), Information Technology Open Systems Interconnection Connectionless presentation protocol: Protocol specification, ISO/IEC 95761:1995.
8. ITU-T Recommendation X.215, (Geneva, 1995), Information Technology Open Systems
Interconnection Session service definition, ISO/IEC 8326:1996.
9. ITU-T Recommendation X.225, (Geneva, 1995), Information Technology Open Systems Interconnection Connection-oriented session protocol: Protocol specification, ISO/IEC 83271:1996.
10. ITU-T Recommendation X.235, (Geneva, 1995), Information Technology Open Systems
Interconnection Connectionless session protocol: Protocol specification, ISO/IEC 95481:1995.
11. ITU-T Recommendation X.214, (Geneva, 1995), Information Technology Open Systems
Interconnection Transport service definition, ISO/IEC 8072:1996.
12. ITU-T Recommendation X.224
13. ITU-T Recommendation Q.700
14. ITU-T Recommendation Q.701
15. ITU-T Recommendation Q.702
16. ITU-T Recommendation Q.703
17. ITU-T Recommendation Q.704
18. Geoffrey Gerrien, CDI - Application Program Interface Guide, Gcom, Inc., March 1999.
19. ITU-T Recommendation Q.771, (Geneva, 1993), Signalling System No. 7 Functional description of transaction capabilities, (White Book).

2011-10-28

305

Call Control Interface (CCI)

Licenses

Licenses
All code presented in this manual is licensed under the [GNU Affero General Public License],
page 307. The text of this manual is licensed under the [GNU Free Documentation License], page 318,
with no invariant sections, no front-cover texts and no back-cover texts. Please note, however, that
it is just plain wrong to modify statements of, or attribute statements to, the Author or OpenSS7
Corporation.

GNU Affero General Public License

The GNU Affero General Public License.

Version 3, 19 November 2007
c 2007 Free Software Foundation, Inc. http://fsf.org/
Copyright
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Preamble
The GNU Affero General Public License is a free, copyleft license for software and other kinds of
works, specifically designed to ensure cooperation with the community in the case of network server
software.
The licenses for most software and other practical works are designed to take away your freedom
to share and change the works. By contrast, our General Public Licenses are intended to guarantee
your freedom to share and change all versions of a programto make sure it remains free software
for all its users.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses
are designed to make sure that you have the freedom to distribute copies of free software (and charge
for them if you wish), that you receive source code or can get it if you want it, that you can change
the software or use pieces of it in new free programs, and that you know you can do these things.
Developers that use our General Public Licenses protect your rights with two steps: (1) assert
copyright on the software, and (2) offer you this License which gives you legal permission to copy,
distribute and/or modify the software.
A secondary benefit of defending all users freedom is that improvements made in alternate versions
of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation.
However, in the case of software used on network servers, this result may fail to come about. The
GNU General Public License permits making a modified version and letting the public access it on
a server without ever releasing its source code to the public.
The GNU Affero General Public License is designed specifically to ensure that, in such cases, the
modified source code becomes available to the community. It requires the operator of a network
server to provide the source code of the modified version running there to the users of that server.
Therefore, public use of a modified version, on a publicly accessible server, gives the public access
to the source code of the modified version.
2011-10-28

Licenses

of the covered work conveyed by you (or copies made from those copies), or (b) primarily for
and in connection with specific products or compilations that contain the covered work, unless
you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting any implied license or other
defenses to infringement that may otherwise be available to you under applicable patent law.
12. No Surrender of Others Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License.
If you cannot convey a covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may not convey it at all.
For example, if you agree to terms that obligate you to collect a royalty for further conveying
from those to whom you convey the Program, the only way you could satisfy both those terms
and this License would be to refrain entirely from conveying the Program.
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified
version must prominently offer all users interacting with it remotely through a network (if
your version supports such interaction) an opportunity to receive the Corresponding Source
of your version by providing access to the Corresponding Source from a network server at no
charge, through some standard or customary means of facilitating copying of software. This
Corresponding Source shall include the Corresponding Source for any work covered by version
3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
Notwithstanding any other provision of this License, you have permission to link or combine
any covered work with a work licensed under version 3 of the GNU General Public License
into a single combined work, and to convey the resulting work. The terms of this License will
continue to apply to the part which is the covered work, but the work with which it is combined
will remain governed by version 3 of the GNU General Public License.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU Affero
General Public License from time to time. Such new versions will be similar in spirit to the
present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain
numbered version of the GNU Affero General Public License or any later version applies to it,
you have the option of following the terms and conditions either of that numbered version or of
any later version published by the Free Software Foundation. If the Program does not specify
a version number of the GNU Affero General Public License, you may choose any version ever
published by the Free Software Foundation.
If the Program specifies that a proxy can decide which future versions of the GNU Affero
General Public License can be used, that proxys public statement of acceptance of a version
permanently authorizes you to choose that version for the Program.
Later license versions may give you additional or different permissions. However, no additional
obligations are imposed on any author or copyright holder as a result of your choosing to follow
a later version.
2011-10-28

315

Licenses

texi/agpl3.texi

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED
BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM
AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH
YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN
IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local
legal effect according to their terms, reviewing courts shall apply local law that most closely
approximates an absolute waiver of all civil liability in connection with the Program, unless a
warranty or assumption of liability accompanies a copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS

316

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Licenses

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public,
the best way to achieve this is to make it free software which everyone can redistribute and change
under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each
source file to most effectively state the exclusion of warranty; and each file should have at least the
copyright line and a pointer to where the full notice is found.
one line to give the programs name and a brief idea of what it does.
Copyright (C) year name of author
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see http://www.gnu.org/licenses/.

Also add information on how to contact you by electronic and paper mail.
If your software can interact with users remotely through a network, you should also make sure that
it provides a way for users to get its source. For example, if your program is a web application, its
interface could display a Source link that leads users to an archive of the code. There are many
ways you could offer source, and different solutions will be better for different programs; see section
13 for the specific requirements.
You should also get your employer (if you work as a programmer) or school, if any, to sign a
copyright disclaimer for the program, if necessary. For more information on this, and how to
apply and follow the GNU AGPL, see http://www.gnu.org/licenses/.

2011-10-28

317

Licenses

texi/fdl13.texi

GNU Free Documentation License

texi/fdl13.texi

the Document does not specify a version number of this License, you may choose any version
ever published (not as a draft) by the Free Software Foundation. If the Document specifies
that a proxy can decide which future versions of this License can be used, that proxys public
statement of acceptance of a version permanently authorizes you to choose that version for the
Document.
11. RELICENSING
Massive Multiauthor Collaboration Site (or MMC Site) means any World Wide Web server
that publishes copyrightable works and also provides prominent facilities for anybody to edit
those works. A public wiki that anybody can edit is an example of such a server. A Massive
Multiauthor Collaboration (or MMC) contained in the site means any set of copyrightable
works thus published on the MMC site.
CC-BY-SA means the Creative Commons Attribution-Share Alike 3.0 license published by
Creative Commons Corporation, a not-for-profit corporation with a principal place of business
in San Francisco, California, as well as future copyleft versions of that license published by that
same organization.
Incorporate means to publish or republish a Document, in whole or in part, as part of another
Document.
An MMC is eligible for relicensing if it is licensed under this License, and if all works that
were first published under this License somewhere other than this MMC, and subsequently
incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections,
and (2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA
on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.

324

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

Licenses

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document
and put the following copyright and license notices just after the title page:
Copyright (C) year your name .
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled GNU
Free Documentation License.

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the with. . . Texts.
line with this:
with the Invariant Sections being list their titles , with
the Front-Cover Texts being list , and with the Back-Cover Texts
being list .

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge
those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these
examples in parallel under your choice of free software license, such as the GNU General Public
License, to permit their use in free software.

2011-10-28

325

Call Control Interface (CCI)

Index

Index
C
CC_ADDR_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CC_ADDR_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
CC_ADDR_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
CC_addr_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
cc_addr_length . . . . . 60, 63, 73, 77, 80, 83, 85, 89,
154, 155, 156, 158, 159, 161, 162, 164, 165,
167, 168, 170, 171, 173, 174, 176, 177, 179,
180, 181, 183, 187, 195, 198, 205, 219, 225,
228, 229, 230, 234, 236, 238, 239, 240, 254,
255, 256, 257, 258, 259, 260, 261
cc_addr_offset . . . . . 60, 63, 73, 77, 80, 83, 85, 89,
154, 155, 156, 158, 159, 161, 162, 164, 165,
167, 168, 170, 171, 173, 174, 176, 177, 179,
180, 181, 183, 187, 195, 198, 205, 219, 225,
228, 229, 230, 234, 236, 238, 239, 240, 254,
255, 256, 257, 258, 259, 260, 261
CC_ADDR_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CC_ADDR_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58, 59
CC_addr_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
CC_ALERTING_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 43
CC_ALERTING_IND . . . . . . . . . . . . . . . . . . . . . . . . 106, 209
CC_ALERTING_IND . . . . . . . . . . . . . . . . . . . 241, 244, 246
CC_alerting_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . 106
CC_ALERTING_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 42
CC_ALERTING_REQ . . . . . . . . . . . . . . . . . . . . . . . . 104, 209
CC_ALERTING_REQ . . . . . . . . . . . . . . . . . . . 242, 244, 245
CC_alerting_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . 104
CC_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
CC_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59, 61
CC_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
CC_BIND_ACK . . . . . . . . . . 64, 77, 78, 85, 87, 183, 185
CC_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
CC_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
CC_BIND_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
CC_bind_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
cc_bind_flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 61, 228
cc_bind_length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
cc_bind_offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
CC_BIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 60
CC_BIND_REQ . . . . . 61, 63, 64, 73, 78, 80, 85, 87, 89,
154, 155, 156, 162, 168, 174, 183, 185, 187
CC_BIND_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198, 228
CC_BIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
CC_bind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
CC_BLOCKING_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
CC_BLOCKING_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
CC_BLOCKING_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
CC_BLOCKING_CON . . . . . . . . . . . . . . . . . . . . . . . . 169, 175
CC_BLOCKING_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
CC_blocking_con_t . . . . . . . . . . . . . . . . . . . . . . . . . . 167
CC_BLOCKING_IND . . . . . . . . . . . . . . . . . . . . . . . . . 50, 164

2011-10-28

CC_BLOCKING_IND . . . . . . . . . . . . . . . . . . . 165, 171, 177

CC_BLOCKING_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
CC_blocking_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . 164
CC_BLOCKING_REQ . . . . . . . . . . . . . . . . . . . . 50, 162, 255
CC_blocking_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . 162
CC_BLOCKING_RES . . . . . . . . . . . . . . . . . . . . 50, 165, 256
CC_blocking_res_t . . . . . . . . . . . . . . . . . . . . . . . . . . 165
CC_CALL_FAILURE_IND . . 31, 45, 74, 75, 94, 97, 114
CC_CALL_FAILURE_IND . . . . . . . . . . . . . . . 143, 217, 249
CC_call_failure_ind_t . . . . . . . . . . . . . . . . . . . . . . 143
cc_call_flags . . . . . 72, 76, 200, 204, 205, 231, 234
CC_CALL_REATTEMPT_IND . . . . . . . . 24, 25, 36, 37, 41
CC_CALL_REATTEMPT_IND . . . . . . . . . . . 74, 75, 82, 143
CC_CALL_REATTEMPT_IND . . . . . . . . . . . . . . . . . 206, 236
CC_call_reattempt_ind_t . . . . . . . . . . . . . . . . . . . . . 82
cc_call_ref . . . . . 58, 59, 66, 69, 71, 76, 78, 80, 85,
87, 89, 90, 92, 93, 98, 100, 101, 103, 104, 106,
107, 109, 110, 112, 113, 115, 116, 118, 119,
121, 122, 124, 125, 127, 128, 130, 131, 133,
134, 136, 137, 139, 140, 143, 144, 146, 147,
149, 151, 153, 180, 183, 185, 187, 188, 190,
234, 235, 236, 238, 239, 240, 241, 242
cc_call_type . . 72, 76, 200, 204, 205, 231, 234, 271
CC_CALL_TYPE_10x64KBS_UNRESTRICTED . . 201, 272
CC_CALL_TYPE_11x64KBS_UNRESTRICTED . . 201, 272
CC_CALL_TYPE_128KBS_UNRESTRICTED . . . . . . . . . 200
CC_CALL_TYPE_12x64KBS_UNRESTRICTED . . 201, 272
CC_CALL_TYPE_13x64KBS_UNRESTRICTED . . 202, 272
CC_CALL_TYPE_14x64KBS_UNRESTRICTED . . 202, 272
CC_CALL_TYPE_1536KBS_UNRESTRICTED . . . 200, 231
CC_CALL_TYPE_15x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_16x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_17x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_18x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_1920KBS_UNRESTRICTED . . . 200, 231
CC_CALL_TYPE_19x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_20x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_21x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_22x64KBS_UNRESTRICTED . . 202, 273
CC_CALL_TYPE_23x64KBS_UNRESTRICTED . . 203, 273
CC_CALL_TYPE_24x64KBS_UNRESTRICTED . . 203, 273
CC_CALL_TYPE_25x64KBS_UNRESTRICTED . . 203, 274
CC_CALL_TYPE_26x64KBS_UNRESTRICTED . . 203, 274
CC_CALL_TYPE_27x64KBS_UNRESTRICTED . . 203, 274
CC_CALL_TYPE_28x64KBS_UNRESTRICTED . . 203, 274
CC_CALL_TYPE_29x64KBS_UNRESTRICTED . . 203, 274
CC_CALL_TYPE_2x64KBS_UNRESTRICTED . . . 200, 231
CC_CALL_TYPE_3_1kHZ_AUDIO . . . . . . . . . . . . 200, 231
CC_CALL_TYPE_30x64KBS_UNRESTRICTED . . . . . . . 203
CC_CALL_TYPE_384KBS_UNRESTRICTED . . . . 200, 231
CC_CALL_TYPE_3x64KBS_UNRESTRICTED . . . 201, 271
CC_CALL_TYPE_4x64KBS_UNRESTRICTED . . . 201, 271

327

Index

CC_CALL_TYPE_5x64KBS_UNRESTRICTED . . . 201, 272

CC_CALL_TYPE_64KBS_PREFERRED . . . . . . . . . . . . . . 231
CC_CALL_TYPE_64KBS_UNRESTRICTED. . . . . . 200, 231
CC_CALL_TYPE_6x64KBS_UNRESTRICTED . . . 201, 272
CC_CALL_TYPE_7x64KBS_UNRESTRICTED . . . 201, 272
CC_CALL_TYPE_8x64KBS_UNRESTRICTED . . . 201, 272
CC_CALL_TYPE_9x64KBS_UNRESTRICTED . . . 201, 272
CC_CALL_TYPE_SPEECH . . . . . . . . . . . . . . . . . . . 200, 231
CC_CAUS_ACCESS_INFO_DISCARDED . . . . . . . . 214, 251
CC_CAUS_ADDRESS_INCOMPLETE . . . . . . . . . . . 214, 251
CC_CAUS_BC_NOT_AUTHORIZED . . . . . . . . . . . . 215, 252
CC_CAUS_BC_NOT_AVAILABLE . . . . . . . . . . . . . . 215, 252
CC_CAUS_BC_NOT_IMPLEMENTED . . . . . . . . . . . 215, 252
CC_CAUS_CALL_REJECTED . . . . . . . . . . . . . . . . . 214, 251
CC_CAUS_CALL_TYPE_INCOMPATIBLE . . . . . . . 216, 253
CC_CAUS_EXCHANGE_ROUTING_ERROR . . . . . . . 216, 253
CC_CAUS_FACILITY_NOT_IMPLEMENTED . . . . 215, 252
CC_CAUS_FACILITY_REJECTED . . . . . . . . . . . . 214, 251
CC_CAUS_GROUP_RESTRICTIONS . . . . . . . . . . . 216, 253
CC_CAUS_ICC_BARRED WITHIN_CUG . . . . . . . . 215, 252
CC_CAUS_INCOMPATIBLE_DESTINATION . . . . 215, 252
CC_CAUS_INCONSISTENCY . . . . . . . . . . . . . . . . . 215, 252
CC_CAUS_INTERWORKING . . . . . . . . . . . . . . . . . . 216, 253
CC_CAUS_INVALID_MESSAGE . . . . . . . . . . . . . . . 215, 252
CC_CAUS_INVALID_TRANSIT_NTWK_SELECTION
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215, 252
CC_CAUS_LNP_QOR_NUMBER_NOT_FOUND . . . . 216, 253
CC_CAUS_MESSAGE_DISCARDED . . . . . . . . . . . . 216, 253
CC_CAUS_MESSAGE_TYPE_NOT_IMPLEMENTED . . . . 215,
252
CC_CAUS_MISDIALLED_TRUNK_PREFIX. . . . . . 213, 250
CC_CAUS_MISROUTED_CALL_TO_PORTED_NUMBER 26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216, 253
CC_CAUS_NETWORK_OUT_OF_ORDER . . . . . . . . . 214, 251
CC_CAUS_NO_ANSWER . . . . . . . . . . . . . . . . . . . . . . 214, 251
CC_CAUS_NO_CCT_AVAILABLE . . . . . . . . . . . . . . 214, 251
CC_CAUS_NO_ROUTE_TO_DESTINATION. . . . . . 213, 250
CC_CAUS_NO_ROUTE_TO_TRANSIT_NETWORK . . . . . 213,
250
CC_CAUS_NO_USER_RESPONDING . . . . . . . . . . . 214, 251
CC_CAUS_NON_EXISTENT_CUG . . . . . . . . . . . . . . 215, 252
CC_CAUS_NORMAL_CALL_CLEARING . . . . . . . . . 213, 250
CC_CAUS_NORMAL_UNSPECIFIED . . . . . . . . . . . 214, 251
CC_CAUS_NOT_SUBSCRIBED . . . . . . . . . . . . . . . . 214, 252
CC_CAUS_NUMBER_CHANGED . . . . . . . . . . . . . . . . 214, 251
CC_CAUS_OGC_BARRED_WITHIN_CUG . . . . . . . . 215, 252
CC_CAUS_OUT_OF_ORDER . . . . . . . . . . . . . . . . . . 214, 251
CC_CAUS_PARAMETER_NOT_IMPLEMENTED . . . 215, 252
CC_CAUS_PARAMETER_PASSED_ON . . . . . . . . . . 215, 253
CC_CAUS_PRECEDENCE_CALL_BLOCKED . . . . . 214, 216,
251, 253
CC_CAUS_PREEMPTION . . . . . . . . . . . 213, 216, 250, 253
CC_CAUS_PREEMPTION_CCT_RESERVED. . . . . . 213, 250
CC_CAUS_PROTOCOL_ERROR . . . . . . . . . . . . . . . . 216, 253
CC_CAUS_RECOVERY_ON_TIMER_EXPIRY . . . . 215, 252
CC_CAUS_REDIRECT . . . . . . . . . . . . . . . . . . . . . . . 214, 251

328

CC_CAUS_REQUESTED_CCT_UNAVAILABLE . . . 214, 251

CC_CAUS_RESOURCE_UNAVAILABLE . . . . . . . . . 214, 251
CC_CAUS_RESTRICTED_BC_ONLY . . . . . . . . . . . 215, 252
CC_CAUS_SEND_SPECIAL_INFO_TONE . . . . . . . 213, 250
CC_CAUS_SERIVCE_OPTION_NOT_IMPLEMENTED
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215, 252
CC_CAUS_SERVICE_OPTION_NOT_AVAILABLE . . . . 215,
252
CC_CAUS_SUBSCRIBER_ABSENT . . . . . . . . . . . . 214, 251
CC_CAUS_SWITCHING_EQUIP_CONGESTION . . 214, 251
CC_CAUS_TEMPORARY_FAILURE . . . . . . . . . . . . 214, 251
CC_CAUS_UNALLOCATED_DEST_NUMBER. . . . . . 216, 253
CC_CAUS_UNALLOCATED_NUMBER . . . . . . . . . . . 213, 250
CC_CAUS_UNKNOWN_BUSINESS_GROUP . . . . . . . 216, 253
CC_CAUS_USER_BUSY . . . . . . . . . . . . . . . . . . . . . . 213, 251
CC_CAUS_USER_NOT_MEMBER_OF_CUG . . . . . . . 215, 252
cc_cause . . . 128, 130, 137, 139, 140, 142, 143, 144,
146, 147, 149, 211, 212, 213, 216, 217, 218,
249, 250, 253
cc_cdpn_length . . . . . . . . 73, 76, 204, 205, 233, 234
cc_cdpn_offset . . . . . . . . 73, 76, 204, 205, 233, 234
CC_CHANNEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198, 199
CC_CHANNEL_GROUP . . . . . . . . . . . . . . . . . . . . . . . 198, 199
cc_conn_length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
cc_conn_offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
CC_CONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 43
CC_CONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
CC_CONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
CC_connect_ind_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
CC_CONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 42
CC_CONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
CC_connect_req_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
CC_CONT_CHECK_IND. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
CC_CONT_CHECK_IND . . . . . . . . . . . . . . . . . 85, 87, 88, 92
CC_CONT_CHECK_IND . . . 183, 185, 186, 190, 238, 239
CC_cont_check_ind_t . . . . . . . . . . . . . . . . . . . . 85, 183
CC_CONT_CHECK_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
CC_CONT_CHECK_REQ . . . . . . . . . . . . . 83, 181, 207, 237
CC_CONT_CHECK_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 239
CC_cont_check_req_t . . . . . . . . . . . . . . . . . . . . 83, 181
CC_CONT_REPORT_IND . . . . . . . . . . . . . . . . . . . . . . . 39, 41
CC_CONT_REPORT_IND . . . . . . . . . . . . . . . . . . . 42, 85, 88
CC_CONT_REPORT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 92
CC_CONT_REPORT_IND . . . . . . . . . . . . . . . . . . . . 183, 186
CC_CONT_REPORT_IND . . . . . . . . . . . . . . . . . . . . . . . . . 190
CC_CONT_REPORT_IND . . . . . . . . . . . . . . . . . . . . . . . . . 238
CC_CONT_REPORT_IND . . . . . . . . . . . . . . . . . . . . . . . . . 240
CC_cont_report_ind_t . . . . . . . . . . . . . . . . . . . 92, 190
CC_CONT_REPORT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 38
CC_CONT_REPORT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CC_CONT_REPORT_REQ . . . . . . 42, 74, 89, 90, 187, 188
CC_CONT_REPORT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 207
CC_CONT_REPORT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 237
CC_CONT_REPORT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 240
CC_cont_report_req_t . . . . . . . . . . . . . . . . . . . 90, 188
CC_CONT_TEST_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CC_CONT_TEST_IND . . . . . . . . . . . . . . . . . . . . . . . . . 39, 41
CC_CONT_TEST_IND . . . 84, 89, 90, 92, 182, 187, 188,
190, 239
CC_cont_test_ind_t . . . . . . . . . . . . . . . . . . . . . . 89, 187
CC_CONT_TEST_REQ . . . . . . . . 38, 40, 85, 87, 183, 185
CC_CONT_TEST_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
CC_CONT_TEST_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
CC_cont_test_req_t . . . . . . . . . . . . . . . . . . . . . . 87, 185
cc_correct_prim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
CC_DEFAULT_LISTENER . . . . . . . . . . . . . . . . . . . . . . . . . 50
CC_DEFAULT_LISTENER . . 61, 62, 198, 199, 228, 229,
230
CC_DISCONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . 26, 31
CC_DISCONNECT_IND. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
CC_DISCONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 114
CC_DISCONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 146
CC_DISCONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 213
CC_DISCONNECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 218
CC_disconnect_ind_t . . . . . . . . . . . . . . . . . . . . . . . . 146
CC_DISCONNECT_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CC_DISCONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . 26, 31
CC_DISCONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . 32, 36
CC_DISCONNECT_REQ . . . . . . . . . . . . . 63, 100, 144, 213
CC_DISCONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 217
CC_DISCONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 250
CC_disconnect_req_t . . . . . . . . . . . . . . . . . . . . . . . . 144
CC_ERROR_ACK . . . . 21, 58, 61, 64, 65, 67, 69, 73, 74,
79, 84, 88, 91, 94, 97, 102, 105, 108, 111, 114,
117, 120, 123, 125, 129, 132, 135, 138, 141,
145, 148, 152, 157, 160, 163, 166, 169, 172,
175, 178, 182, 186, 189, 193, 197, 210, 227,
235, 238, 239, 240, 241, 242, 248, 249, 250, 254
CC_error_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
cc_error_primitive . . . . . . . . . . . . . . . . . . . . . . . . . . 69
cc_error_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
cc_event . . . . . . . . . . . . . . . . . . . . . . 107, 109, 244, 246
cc_flags . . . 101, 103, 104, 106, 107, 109, 110, 112,
113, 115, 122, 124, 131, 133, 154, 155, 156,
158, 159, 161, 162, 164, 165, 167, 168, 170,
171, 173, 174, 176, 177, 179, 210, 211, 212,
219, 242, 245, 246, 247, 248, 254, 255, 256,
257, 258, 259, 260, 261
CC_FORWXFER_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
CC_forwxfer_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . 121
CC_forwxfer_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . 119
CC_IBI_IND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
CC_IBI_IND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
CC_IBI_IND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
CC_IBI_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112, 210
CC_IBI_IND . . . . . . . . . . . . . . . . . . . . 241, 244, 245, 246
CC_ibi_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
CC_IBI_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
CC_IBI_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
CC_IBI_REQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
CC_IBI_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110, 210
CC_IBI_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 242, 244, 245

2011-10-28

Index

CC_IBI_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
CC_ibi_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
CC_INFO_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CC_INFO_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
CC_INFO_ACK . . . . . . . . . . . . . . . . . . . . . . . . . 57, 198, 228
CC_info_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
CC_INFO_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18, 56
CC_INFO_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
CC_info_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
CC_INFO_TIMEOUT_IND . . . . . . . . . . . . . . . . . . . . . . 24, 36
CC_INFO_TIMEOUT_IND . . . . . . . . . . . 94, 100, 208, 242
CC_info_timeout_ind_t . . . . . . . . . . . . . . . . . . . . . . 100
CC_INFORMATION_IND . . . . . . . . . . . . . . . . . . . . . . . 24, 36
CC_INFORMATION_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 94
CC_INFORMATION_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 98
CC_INFORMATION_IND . . . . . . . . . . . . . . . . . . . . . . . . . 206
CC_INFORMATION_IND . . . . . . . . . . . . . . . . . . . . 208, 242
CC_information_ind_t . . . . . . . . . . . . . . . . . . . . . . . . 98
CC_INFORMATION_REQ . . . . . . . . . . . . . . . . . . . . . . . 24, 36
CC_INFORMATION_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 95
CC_INFORMATION_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 96
CC_INFORMATION_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 205
CC_INFORMATION_REQ . . . . . . . . . . . . . . . . . . . . 208, 241
CC_information_req_t . . . . . . . . . . . . . . . . . . . . . . . . 96
CC_ITC_WITH_TONES_AND_ANNOUNCEMENTS". . . . . 203
CC_MAINT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34, 61
CC_MAINT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
CC_MAINT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
CC_maint_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
CC_MAINTENANCE . . . . . . . . . . . . . . 61, 62, 77, 229, 230
CC_MANAGEMENT . . . . . . . . . . . . . . . 61, 62, 77, 229, 230
CC_MORE_INFO_IND . . . . . . . . . . . . . . . . . . . . . . . . . 24, 36
CC_MORE_INFO_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
CC_MORE_INFO_IND . . . . . . . . . . . . . . . . . . 205, 208, 241
CC_more_info_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . 95
CC_MORE_INFO_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 24, 36
CC_MORE_INFO_REQ . . . . . . . . . . . . . . 93, 206, 208, 241
CC_more_info_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . 93
CC_OK_ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
CC_OK_ACK . . . . 65, 67, 71, 78, 91, 97, 102, 104, 108,
111, 116, 117, 120, 125, 129, 132, 135, 138,
141, 145, 152, 160, 166, 172, 178, 189, 239
CC_ok_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
cc_opt_flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
cc_opt_length . . . . . 66, 73, 76, 93, 95, 96, 98, 101,
103, 104, 106, 107, 109, 110, 112, 113, 115,
116, 118, 119, 121, 122, 124, 125, 127, 128,
130, 131, 133, 134, 136, 137, 139, 140, 142,
143, 144, 146, 147, 149, 151, 153, 197, 227, 234
cc_opt_offset . . . . . 66, 73, 77, 93, 95, 96, 98, 101,
103, 104, 106, 107, 109, 110, 112, 113, 115,
116, 118, 119, 121, 122, 124, 125, 127, 128,
130, 131, 133, 134, 136, 137, 139, 140, 142,
143, 144, 146, 147, 149, 151, 153, 197, 227, 234
CC_optmgmt_ack_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
CC_OPTMGMT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

329

Index

CC_OPTMGMT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 66, 72
CC_OPTMGMT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 199, 230
CC_optmgmt_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
cc_primitive . . . . 56, 57, 58, 59, 60, 63, 65, 66, 69,
71, 72, 76, 78, 80, 82, 83, 85, 87, 89, 90, 92, 93,
95, 96, 98, 100, 101, 103, 104, 106, 107, 109,
110, 112, 113, 115, 116, 118, 119, 121, 122,
124, 125, 127, 128, 130, 131, 133, 134, 136,
137, 139, 140, 142, 143, 144, 146, 147, 149,
151, 153, 154, 155, 156, 158, 159, 161, 162,
164, 165, 167, 168, 170, 171, 173, 174, 176,
177, 179, 180, 181, 183, 185, 187, 188, 190
CC_PROCEEDING_IND . . . . . . . . . . . . . . . . . . . . . . . . 26, 43
CC_PROCEEDING_IND . . . . . . . . . . . . . . . . . . . . . . 103, 209
CC_PROCEEDING_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CC_PROCEEDING_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 244
CC_proceeding_ind_t . . . . . . . . . . . . . . . . . . . . . . . . 103
CC_PROCEEDING_REQ . . . . . . . . . . . . . . . . . . . . . . . . 26, 42
CC_PROCEEDING_REQ . . . . . . . . . . . . . . . . . . . . . . 101, 209
CC_PROCEEDING_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 242
CC_proceeding_req_t . . . . . . . . . . . . . . . . . . . . . . . . 101
CC_PROGRESS_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 43
CC_PROGRESS_IND . . . . . . . . . . . . . . . . . . . . . . . . 109, 209
CC_PROGRESS_IND . . . . . . . . . . . . . . . . . . . . . . . . 241, 244
CC_PROGRESS_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
CC_progress_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . 109
CC_PROGRESS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 26, 42
CC_PROGRESS_REQ . . . . . . . . . . . . . . . . . . . . . . . . 107, 209
CC_PROGRESS_REQ . . . . . . . . . . . . . . . . . . . 242, 244, 246
CC_progress_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . 107
CC_QUERY_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
CC_QUERY_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . 179, 260
CC_query_con_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
CC_QUERY_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
CC_QUERY_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . 176, 260
CC_query_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
CC_QUERY_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
CC_QUERY_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 174, 259
CC_query_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
CC_QUERY_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
CC_QUERY_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . 177, 260
CC_query_res_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
cc_reason . . . . . . . . . . . . . . . . . . 82, 143, 180, 217, 236
CC_REJECT_IND . . . . . . . . . . . . . . . . . . . . . . . . 30, 44, 142
CC_REJECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
CC_REJECT_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
CC_reject_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
CC_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
CC_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
CC_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
CC_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . 140, 208, 213
CC_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
CC_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 242, 249
CC_reject_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
CC_RELEASE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
CC_RELEASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 30, 44

330

CC_RELEASE_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
CC_RELEASE_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
CC_RELEASE_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
CC_RELEASE_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
CC_RELEASE_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
CC_RELEASE_CON . . . . . . . . . . . . . . . . . . . . . . . . . 153, 218
CC_release_con_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
CC_RELEASE_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 31
CC_RELEASE_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 46
CC_RELEASE_IND . . . . . 74, 75, 88, 97, 114, 123, 148,
149, 153, 163, 166, 169, 172, 175, 178, 186, 213
CC_RELEASE_IND . . . . . . . . . . . . . . . . . . . . . . . . . 218, 253
CC_release_ind_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
CC_RELEASE_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 31
CC_RELEASE_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
CC_RELEASE_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 35, 45
CC_RELEASE_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
CC_RELEASE_REQ . . . 76, 85, 100, 140, 147, 151, 183,
213
CC_RELEASE_REQ . . . . . . . . . . . . . . . . . . . . 218, 250, 253
CC_release_req_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
CC_RELEASE_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
CC_RELEASE_RES . . . . . . . . . . . . . . . . . . 32, 46, 151, 218
CC_release_res_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
CC_RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
CC_RESET . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 30, 44, 46
CC_RESET_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
CC_RESET_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
CC_RESET_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
CC_RESET_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . 161, 255
CC_reset_con_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
CC_RESET_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30, 44
CC_RESET_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
CC_RESET_IND. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48, 158
CC_RESET_IND . . . . . . . . . . . . . . . . . . 159, 163, 169, 175
CC_RESET_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
CC_reset_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
CC_RESET_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30, 44
CC_RESET_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
CC_RESET_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
CC_RESET_REQ . . . . . . . . . . . . . . . . . . . . . . . 154, 155, 156
CC_RESET_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
CC_reset_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
CC_RESET_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
CC_RESET_RES . . . . . . . . . . . . . . . . . . . . . . . . 48, 159, 254
CC_reset_res_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
CC_RESTART. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
CC_RESTART_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
CC_RESTART_CON . . . . . . . . . . . . . . . . . . . . . . . . . 155, 219
CC_restart_ind_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
CC_RESTART_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
CC_RESTART_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 154, 219
CC_RESTART_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
CC_restart_req_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
cc_result . . . . . . . . . . . . . . . . . . . 90, 92, 188, 190, 240
CC_RESUME_CON . . . . . . . . . . . . . . . . . . . . . . . 29, 136, 212

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

CC_resume_con_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
CC_RESUME_IND . . . . . . . . . . . . . . 29, 44, 133, 212, 248
CC_resume_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
CC_RESUME_REJECT_IND. . . . . . . . . . . . . . . 29, 139, 212
CC_resume_reject_ind_t . . . . . . . . . . . . . . . . . . . . . 139
CC_RESUME_REJECT_REQ . . . . . . . . . . 29, 137, 212, 248
CC_RESUME_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . . 249
CC_resume_reject_req_t . . . . . . . . . . . . . . . . . . . . . 137
CC_RESUME_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29, 30
CC_RESUME_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
CC_RESUME_REQ . . . . . . . . . . . . . . . . . . 44, 131, 211, 248
CC_resume_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
CC_RESUME_RES . . . . . . . . . . . . . . . . . . . . . . . 29, 134, 212
CC_RESUME_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
CC_resume_res_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
CC_SETUP_COMPLETE_IND. . . . . . . . . . . . . . . 27, 43, 114
CC_SETUP_COMPLETE_IND . . . . . . . . . . . . . . . . . 118, 207
CC_SETUP_COMPLETE_IND . . . . . . . . . . . . . . . . . . . . . . 237
CC_setup_complete_ind_t . . . . . . . . . . . . . . . . . . . 118
CC_SETUP_COMPLETE_REQ. . . . . . . . . . . . . . . 26, 42, 115
CC_SETUP_COMPLETE_REQ . . . . . . . . . . . . . . . . . 116, 207
CC_SETUP_COMPLETE_REQ . . . . . . . . . . . . . . . . . . . . . . 237
CC_setup_complete_req_t . . . . . . . . . . . . . . . . . . . 116
CC_SETUP_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 36
CC_SETUP_CON . . . 42, 74, 80, 82, 115, 128, 131, 134,
137, 147, 149, 151, 153
CC_SETUP_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
CC_SETUP_CON . . . . . . . . . . . . . . . . . . 231, 235, 236, 275
CC_SETUP_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
CC_SETUP_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
CC_SETUP_CON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
CC_setup_con_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
cc_setup_ind . . . . . . . . . . . . 60, 63, 64, 198, 228, 230
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 30, 36
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
CC_SETUP_IND . . . . 63, 76, 77, 78, 85, 87, 88, 93, 98,
100, 113, 128, 131, 134, 137, 140, 144, 147,
149, 151, 153, 183, 185, 186, 199
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
CC_SETUP_IND . . . . . . . . . . . . . . . . . . 234, 235, 236, 239
CC_SETUP_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
CC_setup_ind_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
CC_SETUP_REQ . . . . 38, 40, 42, 66, 72, 73, 74, 80, 81,
82, 90, 92, 95, 96, 142, 147, 149, 151, 153, 188,
190, 199
CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

2011-10-28

Index

CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
CC_SETUP_REQ . . . . . . . . 234, 235, 236, 237, 241, 242
CC_SETUP_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
CC_setup_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . 42, 61, 63, 76, 78
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . 208, 229, 234
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . 242, 275
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
CC_SETUP_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
CC_setup_res_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
cc_state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69, 71
cc_subn_length . . . . . . . . . . . . . . . . . . 96, 98, 241, 242
cc_subn_offset . . . . . . . . . . . . . . . . . . 96, 98, 241, 242
CC_SUSPEND_CON . . . . . . . . . . . . . . . . . . . . . . . . . . 28, 123
CC_SUSPEND_CON . . . . . . . . . . . . . . . . . . . . . . . . . 127, 211
CC_suspend_con_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
CC_SUSPEND_IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
CC_SUSPEND_IND . . . . . . . . . . . . . . . . . 44, 124, 210, 247
CC_suspend_ind_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
CC_SUSPEND_REJECT_IND . . . . . . . . . . . . . . . . . . 28, 123
CC_SUSPEND_REJECT_IND . . . . . . . . . . . . . . . . . 130, 211
CC_suspend_reject_ind_t . . . . . . . . . . . . . . . . . . . 130
CC_SUSPEND_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . . 27
CC_SUSPEND_REJECT_REQ . . . . . . . . . . . . 128, 211, 247
CC_SUSPEND_REJECT_REQ . . . . . . . . . . . . . . . . . . . . . . 248
CC_suspend_reject_req_t . . . . . . . . . . . . . . . . . . . 128
CC_SUSPEND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
CC_SUSPEND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
CC_SUSPEND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
CC_SUSPEND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 122
CC_SUSPEND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
CC_SUSPEND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
CC_suspend_req_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
CC_SUSPEND_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
CC_SUSPEND_RES . . . . . . . . . . . . . . . . . . . . . . . . . 125, 210
CC_SUSPEND_RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
CC_suspend_res_t. . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
CC_SUSRES_NETWORK_INITIATED . . . . . 246, 247, 248
CC_TEST. . . . . . 61, 62, 77, 85, 89, 183, 187, 229, 230
CC_TOKEN_REQ . . . . . . . . . . . . . . . . . . . . . . . . . 78, 87, 185
CC_TOKEN_REQUEST . . . . . . . . . . . . . . . . . . . . . . . . 61, 229
cc_token_value . . . . . . . . . . . . . . 63, 78, 87, 185, 235
CC_TRUNK_GROUP . . . . . . . . . . . . . . . . . . . . . . . . . 198, 199
CC_UNBIND_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 65
CC_unbind_req_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
CC_UNBLOCKING_CON . . . . . . . . . . . . . . . . . . 51, 173, 259
CC_unblocking_con_t . . . . . . . . . . . . . . . . . . . . . . . . 173
CC_UNBLOCKING_IND . . . . . . . . . . . . . . . . . . 51, 170, 258

331

Index

CC_unblocking_ind_t . . . . . . . . . . . . . . . . . . . . . . . . 170
CC_UNBLOCKING_REQ . . . . . . . . . . . . . . . . . . 51, 168, 257
CC_unblocking_req_t . . . . . . . . . . . . . . . . . . . . . . . . 168
CC_UNBLOCKING_RES . . . . . . . . . . . . . . . . . . 51, 171, 258
CC_unblocking_res_t . . . . . . . . . . . . . . . . . . . . . . . . 171
cc_unix_error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
cc_user_ref . . 72, 80, 82, 90, 95, 96, 142, 147, 149,
151, 153, 188, 231, 235, 236, 240
CC_WACK_AREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
CCACCESS . . 62, 67, 70, 75, 84, 88, 94, 97, 102, 105,
108, 111, 114, 117, 129, 132, 135, 138, 141,
145, 148, 157, 160, 163, 166, 169, 172, 175,
178, 182, 186
CCADDRBUSY . . . . . . . . . . . . . . . . . . . . 61, 62, 70, 75, 228
CCBADADDR . . . . 62, 70, 73, 75, 84, 97, 157, 160, 163,
169, 175, 182, 238, 239, 240, 241
CCBADCLR . . . . . 58, 67, 70, 75, 78, 79, 87, 88, 91, 94,
97, 102, 105, 108, 111, 114, 117, 129, 132, 135,
138, 141, 144, 145, 148, 185, 186, 189, 235
CCBADDIGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70, 75
CCBADFLAG . . . . . 62, 67, 70, 102, 105, 108, 111, 114,
256, 257, 258, 259
CCBADOPT . . . 67, 70, 75, 97, 102, 105, 108, 111, 114,
117, 129, 132, 135, 138, 141, 145, 148, 197, 227
CCBADPRIM . . . . . . 62, 67, 70, 75, 79, 91, 94, 97, 102,
105, 108, 111, 114, 117, 129, 132, 135, 138,
141, 145, 148, 189
CCBADTOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70, 79
CCFLAGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163, 169, 175
CCNOADDR . . . . . 62, 70, 73, 75, 84, 97, 157, 160, 163,
169, 175, 182, 238, 239, 240
CCNOTSUPP . . 70, 84, 88, 94, 117, 129, 132, 135, 138,
141, 145, 148, 157, 160, 163, 169, 175, 182,
186, 210, 242, 248, 249, 250, 254
CCOUTSTATE . . 62, 65, 67, 69, 75, 79, 84, 88, 91, 94,
97, 102, 105, 108, 111, 114, 117, 120, 123, 126,
129, 132, 135, 138, 141, 145, 148, 152, 157, 160,
163, 166, 169, 172, 175, 178, 182, 186, 189, 241
CCS_ALERTING_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CCS_CONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CCS_CONNECTED . . 115, 116, 118, 119, 121, 122, 124,
128, 130, 131, 133, 134, 136
CCS_DISCONNECT_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CCS_IBI_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CCS_IDLE . . . . . 34, 64, 65, 66, 67, 74, 77, 82, 83, 85,
90, 92, 141, 142, 143, 147, 148, 149, 150, 151,
153, 157, 158, 161, 163, 169, 175, 177, 179,
181, 183, 188, 190
CCS_PROCEED_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CCS_PROGRESS_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CCS_SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
CCS_SUSPENDED . . 122, 124, 125, 127, 128, 130, 131,
133, 134, 136, 137, 139, 247, 248
CCS_UNBND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
CCS_WACK_AREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
CCS_WACK_BREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61, 64

332

CCS_WACK_OPTREQ . . . . . . . . . . . . . . . . . . . . . . . . . . 66, 71
CCS_WACK_UREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 71
CCS_WAIT_COR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
CCS_WCON_CREQ . . . . . . . . . . . . . . . . . . . . . . . . . . . 89, 187
CCS_WCON_RELREQ . . . . . . . . . . . . . . 147, 148, 150, 153
CCS_WCON_SREQ . . 74, 80, 82, 92, 142, 143, 190, 241,
242, 244, 246
CCS_WCON_SUSREQ . . . . . . . . . . . . . . 127, 130, 136, 139
CCS_WCON_SUSREQ. . . . . . . . . . . . . . 127, 130, 136, 139
CCS_WIND_ALERTING . . . . . . . . . . . . 103, 106, 112, 146
CCS_WIND_CCREP . . . . . . . . . . . . . . . . . . . . . . . 77, 92, 190
CCS_WIND_CONNECT . . . . . . . . . . . . . . . . . . . . . . . 112, 146
CCS_WIND_CTEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
CCS_WIND_INFO . . . . . . . . . . . . . . . . . . . . . . . . 93, 98, 100
CCS_WIND_MORE . . . 74, 82, 95, 96, 97, 112, 143, 146
CCS_WIND_PROCEED . . . . . 82, 97, 101, 103, 106, 112,
143, 146
CCS_WIND_PROGRESS . . . . . . . . . . . . 106, 109, 112, 146
CCS_WREQ_ALERTING . . . . . . . . . . . . 104, 110, 113, 144
CCS_WREQ_CCREP . . . . . . . . . . . . . . . 74, 80, 82, 90, 188
CCS_WREQ_CONNECT . . . . . . . . . . . . . . . . . . 110, 113, 144
CCS_WREQ_CTEST . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 92
CCS_WREQ_INFO . . . . . . . . . . . 82, 95, 96, 100, 143, 146
CCS_WREQ_MORE . . . . 77, 81, 90, 93, 98, 99, 101, 103,
104, 106, 110, 113, 144, 188
CCS_WREQ_PROCEED . . . 78, 81, 90, 99, 104, 110, 113,
144, 188
CCS_WREQ_PROGRESS . . . . . . . 104, 107, 110, 113, 144
CCS_WRES_RELIND . . . . . . . . . . . . . . 148, 149, 150, 151
CCS_WRES_SIND . . . . . 77, 78, 140, 241, 244, 245, 249
CCSYSERR . . 58, 62, 65, 67, 69, 75, 79, 84, 88, 91, 94,
97, 102, 105, 108, 111, 114, 117, 120, 123, 126,
129, 132, 135, 138, 141, 145, 148, 152, 157,
160, 163, 166, 169, 172, 175, 178, 182, 186, 189
cic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195, 225

G
getmsg(2s). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

I
id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195,
isdn_addr_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISDN_SCOPE_CH . . . . . . . . . . . . . . . . . . . . . . . . . . . 13,
ISDN_SCOPE_DF . . . . . . . . . . . . . . . . . . . . . . . 12, 196,
ISDN_SCOPE_EG . . . . . . . . . . . . . . . . . . . . . . . 12, 196,
ISDN_SCOPE_FG . . . . . . . . . . . . . . . . . . . . . . . . 12, 13,
ISDN_SCOPE_TG . . . . . . . . . . . . . . . . . . . . . . . . . . . 13,
ISDN_SCOPE_XG . . . . . . . . . . . . . . . . . . . . . . . 12, 196,
isup_addr_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISUP_BCI_CHARGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISUP_BCI_CONNECT_FREE . . . . . . . . . . . . . . . . . . . . . .
ISUP_BCI_E2E_INFORMATION_AVAILABLE . . . . . . .
ISUP_BCI_HOLDING_REQUESTED . . . . . . . . . . . . . . . .
ISUP_BCI_IC_ECHO_CONTROL_DEVICE . . . . . . . . . .

225
195
196
197
197
196
196
197
225
243
243
243
243
243

Version 1.1 Rel. 1.20110510

Call Control Interface (CCI)

ISUP_BCI_INTERWORKING_ENCOUNTERED . . . . . . . . 243
ISUP_BCI_ISDN_USER_PART_ALL_THE_WAY . . . . . . 243
ISUP_BCI_NO_CHARGE . . . . . . . . . . . . . . . . . . . . . . . . . 243
ISUP_BCI_ORDINARY_SUBSCRIBER . . . . . . . . . . . . . . 243
ISUP_BCI_PASS_ALONG_E2E_METHOD_AVAILABLE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
ISUP_BCI_PAYPHONE . . . . . . . . . . . . . . . . . . . . . . . . . . 243
ISUP_BCI_SCCP_ALL_METHODS_AVAILABLE . . . . . . 244
ISUP_BCI_SCCP_CLNS_METHOD_AVAILABLE . . . . . . 244
ISUP_BCI_SCCP_CONS_METHOD_AVAILABLE . . . . . . 244
ISUP_BCI_SCCP_E2E_METHOD_AVAILABLE . . . . . . . 243
ISUP_BCI_SUBSCRIBER_FREE . . . . . . . . . . . . . . . . . . 243
ISUP_BCI_TERMINATING_ACCESS_ISDN . . . . . . . . . 243
ISUP_CALL_FAILURE_BLOCKING . . . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_CIRCUIT_BUSY . . . . . . . . . . . 250
ISUP_CALL_FAILURE_COT_FAILURE . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_ERROR . . . . . . . . . . . . . . . . . . . 217
ISUP_CALL_FAILURE_RECV_RLC . . . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_RESET . . . . . . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_RESTART . . . . . . . . . . . . . . . . . 217
ISUP_CALL_FAILURE_STATUS . . . . . . . . . . . . . . . . . . 217
ISUP_CALL_FAILURE_T2_TIMEOUT . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_T3_TIMEOUT . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_T35_TIMEOUT . . . . . . . . . . . . . 250
ISUP_CALL_FAILURE_T38_TIMEOUT . . . . . . . . . . . . . 250
ISUP_CALL_FAILURE_T6_TIMEOUT . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_T7_TIMEOUT . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_T8_TIMEOUT . . . . . . . . . . . . . . 249
ISUP_CALL_FAILURE_T9_TIMEOUT . . . . . . . . . . . . . . 250
ISUP_COT_FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
ISUP_COT_FAILURE. . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
ISUP_COT_SUCCESS . . . . . . . . . . . . . . . . . . . . . . . . 38, 240
ISUP_EVNT_ALERTING . . . . . . . . . . . . . . . . . . . . . . . . . 244
ISUP_EVNT_CALL_FORWARDED_ON_BUSY . . . . . . . . . 245
ISUP_EVNT_CALL_FORWARDED_ON_NO_ANSWER . . . 245
ISUP_EVNT_CALL_FORWARDED_UNCONDITIONAL . . 245
ISUP_EVNT_IBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
ISUP_EVNT_PRESENTATION_RESTRICTED . . . 245, 246
ISUP_EVNT_PROGRESS . . . . . . . . . . . . . . . . . . . . . . . . . 245
ISUP_FCI_E2E_INFORMATION_AVAILABLE . . . . . . . 232
ISUP_FCI_INTERNATIONAL_CALL . . . . . . . . . . . . . . . 232
ISUP_FCI_INTERWORKING_ENCOUNTERED . . . . . . . . 232
ISUP_FCI_ISDN_USER_PART_ALL_THE_WAY . . . . . . 232
ISUP_FCI_ORIGINATING_ACCESS_ISDN . . . . . . . . . 232
ISUP_FCI_PASS_ALONG_E2E_METHOD_AVAILABLE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232, 233
ISUP_FCI_SCCP_ALL_METHODS_AVAILABLE . . . . . . 233
ISUP_FCI_SCCP_CLNS_METHOD_AVAILABLE . . . . . . 233
ISUP_FCI_SCCP_CONS_METHOD_AVAILABLE . . . . . . 233
ISUP_FCI_SCCP_E2E_METHOD_AVAILABLE . . 232, 233
ISUP_GROUP . . 254, 255, 256, 257, 258, 259, 260, 261
ISUP_HARDWARE_FAILURE_ORIENTED . . . . . . 256, 257,
258, 259
ISUP_MAINTENANCE_ORIENTED . . . 256, 257, 258, 259
ISUP_NCI_CONT_CHECK_PREVIOUS . . . . . . . . . . 74, 232
ISUP_NCI_CONT_CHECK_PREVIOUS . . . . . . . . . . . . . . 233

2011-10-28

Index

ISUP_NCI_CONT_CHECK_PREVIOUS. . . . . . . . . . . . . . 233
ISUP_NCI_CONT_CHECK_REQUIRED . . . . . . . . . . . . . . . 38
ISUP_NCI_CONT_CHECK_REQUIRED . . . . . . . . . . . . . . . 39
ISUP_NCI_CONT_CHECK_REQUIRED . . . . . . . . . . . . . . . 40
ISUP_NCI_CONT_CHECK_REQUIRED . . . . . . . . . . . . . . . 41
ISUP_NCI_CONT_CHECK_REQUIRED . . . 42, 74, 80, 87,
185, 232
ISUP_NCI_CONT_CHECK_REQUIRED . . . . . . . . . . . . . . 233
ISUP_NCI_CONT_CHECK_REQUIRED . . . . . . . . . . . . . . 239
ISUP_NCI_CONT_CHECK_REQUIRED and. . . . . . . . . . 233
ISUP_NCI_OG_ECHO_CONTROL_DEVICE . . . . . . . . . . 232
ISUP_NCI_ONE_SATELLITE_CCT . . . . . . . . . . . . . . . . 232
ISUP_NCI_TWO_SATELLITE_CCT . . . . . . . . . . . . . . . . 232
ISUP_REATTEMPT_BLOCKING . . . . . . . . . . . . . . . . . . . 236
ISUP_REATTEMPT_CIRCUIT_BUSY . . . . . . . . . . . . . . . 237
ISUP_REATTEMPT_COT_FAILURE . . . . . . . . . . . . . . . . 237
ISUP_REATTEMPT_DUAL_SEIZURE . . . . . . . . . . . . . . . 236
ISUP_REATTEMPT_RESET . . . . . . . . . . . . . . . . . . . . . . . 236
ISUP_REATTEMPT_T24_TIMEOUT . . . . . . . . . . . . . . . . 236
ISUP_REATTEMPT_UNEXPECTED . . . . . . . . . . . . . . . . . 236
ISUP_SCOPE_CG . . . . . . . . . . . . . . . . . . . 14, 15, 226, 229
ISUP_SCOPE_CT . . . 15, 226, 229, 235, 236, 237, 238,
239
ISUP_SCOPE_DF . . . . . . . . . . . . . . . . . . 14, 226, 227, 229
ISUP_SCOPE_SP . . . . . . . . . . . . . . . . . . 14, 226, 227, 229
ISUP_SCOPE_SR . . . . . . . . . . . . . . . . . . . 14, 15, 226, 229
ISUP_SCOPE_TG . . . . . . . . . . . . . . . . . . . . . . . 14, 226, 229

L
license,
license,
license,
license,

AGPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GNU Affero General Public License . . .
GNU Free Documentation License . . . .

307
318
307
318

M
M_DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
M_ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
M_PCPROTO . . . . . . . . . . . . . . . . . . . 56, 57, 63, 68, 69, 71
M_PROTO . . 58, 59, 60, 65, 66, 72, 73, 76, 77, 78, 80,
82, 83, 85, 87, 89, 90, 92, 93, 94, 95, 96, 97, 98,
100, 101, 102, 103, 104, 105, 106, 107, 108,
109, 110, 111, 112, 113, 114, 115, 116, 118,
119, 121, 122, 124, 125, 127, 128, 130, 131,
133, 134, 136, 137, 139, 140, 142, 143, 144,
146, 147, 149, 151, 153, 154, 155, 156, 158,
159, 161, 162, 164, 165, 167, 168, 170, 171,
173, 174, 176, 177, 179, 180, 181, 183, 185,
187, 188, 190

P
putmsg(2s). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

333

Index

S
scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195, 225
STREAMS . . . . . . . . . . . . . . . . . . . . . . . 5, 9, 10, 11, 193
struct CC_addr_ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
struct CC_addr_req . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
struct CC_alerting_ind . . . . . . . . . . . . . . . . . . . . . 106
struct CC_alerting_req . . . . . . . . . . . . . . . . . . . . . 104
struct CC_bind_ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
struct CC_bind_req . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
struct CC_blocking_con . . . . . . . . . . . . . . . . . . . . . 167
struct CC_blocking_ind . . . . . . . . . . . . . . . . . . . . . 164
struct CC_blocking_req . . . . . . . . . . . . . . . . . . . . . 162
struct CC_blocking_res . . . . . . . . . . . . . . . . . . . . . 165
struct CC_call_failure_ind . . . . . . . . . . . . . . . . 143
struct CC_call_reattempt_ind . . . . . . . . . . . . . . . 82
struct CC_connect_ind . . . . . . . . . . . . . . . . . . . . . . 115
struct CC_connect_req . . . . . . . . . . . . . . . . . . . . . . 113
struct CC_cont_check_ind . . . . . . . . . . . . . . . 85, 183
struct CC_cont_check_req . . . . . . . . . . . . . . . 83, 181
struct CC_cont_report_ind . . . . . . . . . . . . . . 92, 190
struct CC_cont_report_req . . . . . . . . . . . . . . 90, 188
struct CC_cont_test_ind . . . . . . . . . . . . . . . . 89, 187
struct CC_cont_test_req . . . . . . . . . . . . . . . . 87, 185
struct CC_disconnect_ind . . . . . . . . . . . . . . . . . . . 146
struct CC_disconnect_req . . . . . . . . . . . . . . . . . . . 144
struct CC_error_ack . . . . . . . . . . . . . . . . . . . . . . . . . . 69
struct CC_forwxfer_ind . . . . . . . . . . . . . . . . . . . . . 121
struct CC_forwxfer_req . . . . . . . . . . . . . . . . . . . . . 119
struct CC_ibi_ind . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
struct CC_ibi_req . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
struct CC_info_ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
struct CC_info_req . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
struct CC_info_timeout_ind . . . . . . . . . . . . . . . . 100
struct CC_information_ind . . . . . . . . . . . . . . . . . . . 98
struct CC_information_req . . . . . . . . . . . . . . . . . . . 96
struct CC_maint_ind . . . . . . . . . . . . . . . . . . . . . . . . 180
struct CC_more_info_ind . . . . . . . . . . . . . . . . . . . . . 95
struct CC_more_info_req . . . . . . . . . . . . . . . . . . . . . 93
struct CC_ok_ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
struct CC_optmgmt_ack . . . . . . . . . . . . . . . . . . . . . . . 68
struct CC_optmgmt_req . . . . . . . . . . . . . . . . . . . . . . . 66
struct CC_proceeding_ind . . . . . . . . . . . . . . . . . . . 103
struct CC_proceeding_req . . . . . . . . . . . . . . . . . . . 101

334

struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct
struct

CC_progress_ind . . . . . . . . . . . . . . . . . . . . . 109
CC_progress_req . . . . . . . . . . . . . . . . . . . . . 107
CC_query_con . . . . . . . . . . . . . . . . . . . . . . . . 179
CC_query_ind . . . . . . . . . . . . . . . . . . . . . . . . 176
CC_query_req . . . . . . . . . . . . . . . . . . . . . . . . 174
CC_query_res . . . . . . . . . . . . . . . . . . . . . . . . 177
CC_reject_ind . . . . . . . . . . . . . . . . . . . . . . . 142
CC_reject_req . . . . . . . . . . . . . . . . . . . . . . . 140
CC_release_con . . . . . . . . . . . . . . . . . . . . . . 153
CC_release_ind . . . . . . . . . . . . . . . . . . . . . . 149
CC_release_req . . . . . . . . . . . . . . . . . . . . . . 147
CC_release_res . . . . . . . . . . . . . . . . . . . . . . 151
CC_reset_con . . . . . . . . . . . . . . . . . . . . . . . . 161
CC_reset_ind . . . . . . . . . . . . . . . . . . . . . . . . 158
CC_reset_req . . . . . . . . . . . . . . . . . . . . . . . . 156
CC_reset_res . . . . . . . . . . . . . . . . . . . . . . . . 159
CC_restart_ind . . . . . . . . . . . . . . . . . . . . . . 155
CC_restart_req . . . . . . . . . . . . . . . . . . . . . . 154
CC_resume_con . . . . . . . . . . . . . . . . . . . . . . . 136
CC_resume_ind . . . . . . . . . . . . . . . . . . . . . . . 133
CC_resume_reject_ind . . . . . . . . . . . . . . . 139
CC_resume_reject_req . . . . . . . . . . . . . . . 137
CC_resume_req . . . . . . . . . . . . . . . . . . . . . . . 131
CC_resume_res . . . . . . . . . . . . . . . . . . . . . . . 134
CC_setup_complete_ind . . . . . . . . . . . . . . 118
CC_setup_complete_req . . . . . . . . . . . . . . 116
CC_setup_con . . . . . . . . . . . . . . . . . . . . . . . . . . 80
CC_setup_ind . . . . . . . . . . . . . . . . . . . . . . . . . . 76
CC_setup_req . . . . . . . . . . . . . . . . . . . . . . . . . . 72
CC_setup_res . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CC_suspend_con . . . . . . . . . . . . . . . . . . . . . . 127
CC_suspend_ind . . . . . . . . . . . . . . . . . . . . . . 124
CC_suspend_reject_ind . . . . . . . . . . . . . . 130
CC_suspend_reject_req . . . . . . . . . . . . . . 128
CC_suspend_req . . . . . . . . . . . . . . . . . . . . . . 122
CC_suspend_res . . . . . . . . . . . . . . . . . . . . . . 125
CC_unbind_req . . . . . . . . . . . . . . . . . . . . . . . . 65
CC_unblocking_con . . . . . . . . . . . . . . . . . . . 173
CC_unblocking_ind . . . . . . . . . . . . . . . . . . . 170
CC_unblocking_req . . . . . . . . . . . . . . . . . . . 168
CC_unblocking_res . . . . . . . . . . . . . . . . . . . 171
isdn_addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
isup_addr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Version 1.1 Rel. 1.20110510

OCPP-2.0.1 Part2 Specification Edition2
No ratings yet
OCPP-2.0.1 Part2 Specification Edition2
481 pages
OpenScape Voice V7, Interface Manual - SOAP - XML Subscriber Interface Provisioning, Description, Issue 1 - Addfiles
No ratings yet
OpenScape Voice V7, Interface Manual - SOAP - XML Subscriber Interface Provisioning, Description, Issue 1 - Addfiles
974 pages
OpenScape Voice V7, Interface Manual - Volume 7, QSIG Interface, Description, Issue 1 - Addfiles
No ratings yet
OpenScape Voice V7, Interface Manual - Volume 7, QSIG Interface, Description, Issue 1 - Addfiles
138 pages
OpenScape Voice V7, Interface Manual, Volume 5, SIP Interface To Phones, Description, Issue 1 - Addfiles
No ratings yet
OpenScape Voice V7, Interface Manual, Volume 5, SIP Interface To Phones, Description, Issue 1 - Addfiles
205 pages
Junos Pppoe
No ratings yet
Junos Pppoe
846 pages
Avaya G450 CLI Command
No ratings yet
Avaya G450 CLI Command
1,382 pages
CXL Subsystem SVT Uvm User Guide
67% (3)
CXL Subsystem SVT Uvm User Guide
164 pages
OCPP-2.0.1 Edition3 Part1 Architecture Topology
No ratings yet
OCPP-2.0.1 Edition3 Part1 Architecture Topology
28 pages
550-08639 07.01 SBC Core 11.01.00R000 Billing Guide
No ratings yet
550-08639 07.01 SBC Core 11.01.00R000 Billing Guide
337 pages
Communication Server V1
No ratings yet
Communication Server V1
560 pages
OpenScape Voice v10 SOAP-XML Application Developers Manual
No ratings yet
OpenScape Voice v10 SOAP-XML Application Developers Manual
1,052 pages
OcNOS-SP Timing-Sync Guide
No ratings yet
OcNOS-SP Timing-Sync Guide
166 pages
OpenStage Provisioning Interface Developer's Guide
No ratings yet
OpenStage Provisioning Interface Developer's Guide
182 pages
Spring Cloud
100% (1)
Spring Cloud
572 pages
Ps VTM 17.4 Controlapi
No ratings yet
Ps VTM 17.4 Controlapi
746 pages
Osv V9 Csta
No ratings yet
Osv V9 Csta
310 pages
OpenScape Voice V10, SIP To Phones Interface Manual
No ratings yet
OpenScape Voice V10, SIP To Phones Interface Manual
218 pages
OpenScape Voice V9, SIP To SP Interface Manual
No ratings yet
OpenScape Voice V9, SIP To SP Interface Manual
155 pages
OCPP-2.0.1 Edition3 Part2 Specification
No ratings yet
OCPP-2.0.1 Edition3 Part2 Specification
492 pages
OCPP 2.0.1: Part 1 - Architecture & Topology
No ratings yet
OCPP 2.0.1: Part 1 - Architecture & Topology
27 pages
Base Functions Connectivity and Routing Voulme 1 IBM
No ratings yet
Base Functions Connectivity and Routing Voulme 1 IBM
514 pages
Cryptography
No ratings yet
Cryptography
496 pages
Spring Cloud
No ratings yet
Spring Cloud
661 pages
Mapi
100% (1)
Mapi
434 pages
SG 246351
No ratings yet
SG 246351
390 pages
553-3001-213 - 4 .00ip Peer Netw PDF
No ratings yet
553-3001-213 - 4 .00ip Peer Netw PDF
628 pages
Sipwise Community Edition Handbook
No ratings yet
Sipwise Community Edition Handbook
459 pages
XII CS Python MySQL Connectivity Notes
0% (1)
XII CS Python MySQL Connectivity Notes
6 pages
Gunnells W. - Rapid Python Programming GUI Creation, Django Web Server, Game Programming, and Stock Analysis - 2017
No ratings yet
Gunnells W. - Rapid Python Programming GUI Creation, Django Web Server, Game Programming, and Stock Analysis - 2017
189 pages
Mivoice Mx-One: Overview Guide
No ratings yet
Mivoice Mx-One: Overview Guide
58 pages
Cics 400 Administration and Operations Guide
No ratings yet
Cics 400 Administration and Operations Guide
343 pages
Iso 9506 2 2000 FR
No ratings yet
Iso 9506 2 2000 FR
19 pages
Application Development Guide EP-DSXX16
No ratings yet
Application Development Guide EP-DSXX16
522 pages
Contact Center, CS1000, M1 and Voice Processing Guide
100% (3)
Contact Center, CS1000, M1 and Voice Processing Guide
432 pages
TLE 6.2 SAP R3 and R4 Setup and User Guide
No ratings yet
TLE 6.2 SAP R3 and R4 Setup and User Guide
145 pages
TN iVantageAPI T0000960 RevC 12 11 18
No ratings yet
TN iVantageAPI T0000960 RevC 12 11 18
176 pages
Data Networking For Voice Over IP: Title Page
No ratings yet
Data Networking For Voice Over IP: Title Page
356 pages
OSCP 2.0 Specification
No ratings yet
OSCP 2.0 Specification
36 pages
Indic Input 3-User Guide
No ratings yet
Indic Input 3-User Guide
11 pages
Openscape Voice V8 Application Developers Manual: Programming Guide
No ratings yet
Openscape Voice V8 Application Developers Manual: Programming Guide
35 pages
4600 - Lan - Admin 063008
No ratings yet
4600 - Lan - Admin 063008
256 pages
Openss 7
No ratings yet
Openss 7
254 pages
Content Control Interfaces
No ratings yet
Content Control Interfaces
58 pages
OpenScape UC Application V7 OpenScape Desktop Client Enterprise Web Embedded Edition User Guide Issue 4
No ratings yet
OpenScape UC Application V7 OpenScape Desktop Client Enterprise Web Embedded Edition User Guide Issue 4
403 pages
Avaya 46xx Series Ip Phones
No ratings yet
Avaya 46xx Series Ip Phones
256 pages
OpenScape Voice V5, Interface Manual - Volume 7, QSIG Interface, Administrator Documentation, Issue 2 - Addfiles
No ratings yet
OpenScape Voice V5, Interface Manual - Volume 7, QSIG Interface, Administrator Documentation, Issue 2 - Addfiles
138 pages
OpenScape Voice V5, Application Developers Manual, Programming Guide, Issue 1 - Addfiles
No ratings yet
OpenScape Voice V5, Application Developers Manual, Programming Guide, Issue 1 - Addfiles
84 pages
Programmers Manual
No ratings yet
Programmers Manual
157 pages
Veraz ControlSwitch Product Description
No ratings yet
Veraz ControlSwitch Product Description
230 pages
OCPI 2.1.1-d2
No ratings yet
OCPI 2.1.1-d2
76 pages
3bl95517abaapczza 01 en PDF
No ratings yet
3bl95517abaapczza 01 en PDF
204 pages
Handbook Ce
No ratings yet
Handbook Ce
197 pages
Experiment 7 MSK Raspberry Oscilloscope
No ratings yet
Experiment 7 MSK Raspberry Oscilloscope
18 pages
Openss7 Linux Native SCTP Installation and Reference Manual: Brian Bidulock For The Openss7 Project
No ratings yet
Openss7 Linux Native SCTP Installation and Reference Manual: Brian Bidulock For The Openss7 Project
188 pages
Bridge Inisght
No ratings yet
Bridge Inisght
227 pages
Map Interface
No ratings yet
Map Interface
438 pages
Mod03 GL Features Training
No ratings yet
Mod03 GL Features Training
132 pages
Raghuveer Resume
No ratings yet
Raghuveer Resume
1 page
R Programming Language Notes
No ratings yet
R Programming Language Notes
8 pages
30+ Unique Artificial Intelligence Apps Ideas For Startups
No ratings yet
30+ Unique Artificial Intelligence Apps Ideas For Startups
10 pages
Ewsd v16
No ratings yet
Ewsd v16
52 pages
Lecture 2 - Introduction To Accounting Software
100% (3)
Lecture 2 - Introduction To Accounting Software
3 pages
Openss7 Ss7 Stack Installation and Reference Manual: Brian Bidulock For The Openss7 Project
No ratings yet
Openss7 Ss7 Stack Installation and Reference Manual: Brian Bidulock For The Openss7 Project
154 pages
Exchange Server 2010
No ratings yet
Exchange Server 2010
54 pages
Dibbler User
No ratings yet
Dibbler User
74 pages
Com - Hello.miheapp - Secretspace Logcat
No ratings yet
Com - Hello.miheapp - Secretspace Logcat
10 pages
Resume of Legiste905
No ratings yet
Resume of Legiste905
2 pages
Receivables Transaction Review and Control
No ratings yet
Receivables Transaction Review and Control
10 pages
Streamlining Laundry Services Using Innovative Website
No ratings yet
Streamlining Laundry Services Using Innovative Website
11 pages
Internal Klipfolio Pitch Deck
No ratings yet
Internal Klipfolio Pitch Deck
58 pages
Page Scope Mobile User Guide
No ratings yet
Page Scope Mobile User Guide
69 pages
Man020.01 System Management Under VAX-VMS
No ratings yet
Man020.01 System Management Under VAX-VMS
32 pages
Faster Python Programs Through Optimization PDF
No ratings yet
Faster Python Programs Through Optimization PDF
2 pages
WSPro UpgradeGuide SDPII USBCable
No ratings yet
WSPro UpgradeGuide SDPII USBCable
5 pages
Project Proposal
No ratings yet
Project Proposal
19 pages
Dharmesh Soni
No ratings yet
Dharmesh Soni
5 pages
Big Idea 1 Questions Vs 01
No ratings yet
Big Idea 1 Questions Vs 01
5 pages
26 07 2022 - TestPlan
No ratings yet
26 07 2022 - TestPlan
4 pages
A Study On Ariane 5 Failure and Reusability of Components
No ratings yet
A Study On Ariane 5 Failure and Reusability of Components
5 pages
Create New SKEY For Isometric Drawing in PDMS DRAFT - PDMSid
No ratings yet
Create New SKEY For Isometric Drawing in PDMS DRAFT - PDMSid
13 pages
Optitex 170290 Crack
No ratings yet
Optitex 170290 Crack
4 pages
Setup - ns3 Simulator
No ratings yet
Setup - ns3 Simulator
4 pages
How To Convert A HTML File To PDF (With Colors) - Ask Ubuntu
No ratings yet
How To Convert A HTML File To PDF (With Colors) - Ask Ubuntu
5 pages
Imcqrg
No ratings yet
Imcqrg
2 pages
Attendance Software Project: 1. Components of Existing System
No ratings yet
Attendance Software Project: 1. Components of Existing System
4 pages
PROGRAMMING PARADIGMS Categories of Programming Paradigms The
No ratings yet
PROGRAMMING PARADIGMS Categories of Programming Paradigms The
17 pages