SIST ETS 300 366 E1:2005

Private Telecommunication Network (PTN); Inter-exchange signalling protocol ; Call completion supplementary services

Stage 3 of completion of call to busy sub & on no reply sup services at Q. See DTR/ECMA-0002 (ECMA-TR/SVC) for service description. See ENV41005 for definition of stage 3. See ENV41004 for definition of Q reference point. To contain PICS proforma.

Zasebno telekomunikacijsko omrežje (PTN) – Medcentralni signalizacijski protokol - Dopolnilna storitev: dokončanje klica

General Information

• Status: Published
• Publication Date: 30-Apr-2005
• ICS: 33.040.35 - Telephone networks
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-May-2005
• Due Date: 01-May-2005
• Completion Date: 01-May-2005
• Mandate: T-75C.3
• Ref Project: ETSI ETS 300 366 ed.1 (1994-07) - Private Telecommunication Network (PTN); Inter-exchange signalling protocol ; Call completion supplementary services

Standards Content (Sample)

SLOVENSKI STANDARD
01-maj-2005
=DVHEQRWHOHNRPXQLNDFLMVNRRPUHåMH371±0HGFHQWUDOQLVLJQDOL]DFLMVNLSURWRNRO
'RSROQLOQDVWRULWHYGRNRQþDQMHNOLFD
Private Telecommunication Network (PTN); Inter-exchange signalling protocol ; Call
completion supplementary services
Ta slovenski standard je istoveten z: ETS 300 366 Edition 1
ICS:
33.040.35 Telefonska omrežja Telephone networks
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN ETS 300 366
TELECOMMUNICATION July 1994
STANDARD
Source: ETSI TC-ECMA Reference: DE/ECMA-00049
ICS: 33.080
PTN, ECMA-186, QSIG.CC
Key words:
Private Telecommunication Network (PTN);
Inter-exchange signalling protocol
Call completion supplementary services
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
No part may be reproduced except as authorized by written permission. The copyright and the
Copyright Notification:
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1994. All rights reserved.
New presentation - see History box

Page 2
ETS 300 366:1994
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to "ETSI Editing
and Committee Support Dept." at the address shown on the title page.

Page 3
ETS 300 366:1994
Table of contents
Foreword 7
1Scope 9
2 Conformance 9
3 References 10
4 Definitions 11
4.1 External definitions 11
4.2 CC Call 11
4.3 CC Request 11
4.4 Connection release 12
4.5 Connection retention 12
4.6 Path Reservation 12
4.7 Service retention 12
5 List of acronyms 12
6 Signalling protocol for the support of SS-CCBS and SS-CCNR 13
6.1 SS-CCBS/CCNR description 13
6.2 SS-CC operational requirements 13
6.2.1 Requirements on the Originating PTNX 13
6.2.2 Requirements on the Terminating PTNX 13
6.2.3 Requirements on a Transit PTNX 13
6.3 SS-CC coding requirements 14
6.3.1 Operations 14
6.3.2 Information elements 16
6.3.2.1 Facility information element 16
6.3.2.2 Other information elements 17
6.3.3 Messages 17
6.4 SS-CC State definitions 17
6.4.1 States at the Originating PTNX 17
6.4.1.1 CC-Idle 17
6.4.1.2 CC-Wait-Ack 17
6.4.1.3 CC-Invoked-A-RET 17
6.4.1.4 CC-Invoked-A-RLS 17
6.4.1.5 CC-Suspended-A 17
6.4.1.6 CC-Path-Setup 17
6.4.1.7 CC-Wait-User-A-Answer-N 17
6.4.1.8 CC-Wait-User-A-Answer-R 17
6.4.1.9 CC-Ringout 17
6.4.1.10 CC-Wait-User-A-Free 17
6.4.2 States at the Terminating PTNX 18
6.4.2.1 CC-Idle 18
6.4.2.2 CC-Invoked-B 18
6.4.2.3 CC-Await-Call-Completion 18
6.4.2.4 CC-Suspended-B 18
6.4.2.5 CC-Path-Complete 18
6.4.2.6 CC-Wait-User-B-Alert 18
6.5 SS-CC signalling procedures 18
6.5.1 Major options 18
Page 4
ETS 300 366:1994
6.5.1.1 Path reservation 18
6.5.1.2 Retention of signalling connection 19
6.5.1.3 Service retention 19
6.5.2 Actions at the Originating PTNX 19
6.5.2.1 Normal procedures 19
6.5.2.1.1 CCBS invocation 19
6.5.2.1.2 CCNR invocation 20
6.5.2.1.3 SS-CC invocation - detailed procedure 20
6.5.2.1.4 Indication that User B is not busy 21
6.5.2.1.5 CC Call without Path Reservation 22
6.5.2.1.6 CC Call with Path Reservation 22
6.5.2.1.7 User A busy, non-reservation method 23
6.5.2.1.8 User A busy before Path Reservation 23
6.5.2.1.9 User A busy after Path Reservation 23
6.5.2.1.10 CCBS/CCNR cancellation 24
6.5.2.2 Exceptional procedures 25
6.5.2.2.1 CCBS/CCNR invocation 25
6.5.2.2.2 Unexpected APDUs 25
6.5.2.2.3 Service duration timer expiry 25
6.5.2.2.4 SS-CC Recall timer expiry 25
6.5.2.2.5 Failure of Path Reservation 25
6.5.2.2.6 Failure of CC Call presentation 26
6.5.3 Actions at the Terminating PTNX 26
6.5.3.1 Normal procedures 26
6.5.3.1.1 CCBS invocation 26
6.5.3.1.2 CCNR invocation 26
6.5.3.1.3 SS-CC invocation - detailed procedure 27
6.5.3.1.4 Indication that User B is not busy 27
6.5.3.1.5 CC Call without Path Reservation 28
6.5.3.1.6 CC Call with Path Reservation 29
6.5.3.1.7 CCBS/CCNR suspension / resumption 29
6.5.3.1.8 CCBS/CCNR cancellation 30
6.5.3.2 Exceptional procedures 30
6.5.3.2.1 CCBS/CCNR invocation 30
6.5.3.2.2 Unexpected APDUs 31
6.5.3.2.3 User B busy again on Path Reservation attempt 31
6.5.3.2.4 User B busy again on CC Call presentation 31
6.5.3.2.5 Interruption of CC Call 31

Page 5
ETS 300 366:1994
6.5.4 Actions at the Transit PTNX 31
6.6 Impact of interworking with public ISDNs 31
6.6.1 Incoming Gateway PTNX procedures: SS-CCBS request from a public ISDN 32
6.6.2 Outgoing Gateway PTNX procedures: SS-CCBS request to a public ISDN 32
6.7 Impact of interworking with non-ISDNs 33
6.7.1 Incoming Gateway PTNX procedures 33
6.7.2 Outgoing Gateway PTNX procedures 33
6.8 Parameter values (timers) 34
6.8.1 Timers at the Originating PTNX 34
6.8.2 Timers at the Terminating PTNX 34
Annex A (normative): Protocol Implementation Conformance Statement (PICS) Proforma 35
A.1 Introduction 35
A.2 Instructions for completing the PICS proforma 35
A.2.1 General structure of the PICS proforma 35
A.2.2 Additional Information 36
A.2.3 Exception Information 36
A.3 PICS proforma for ECMA-186 36
A.3.1 Implementation Identification 36
A.3.2 Protocol Summary 37
A.3.3 General 37
A.3.4 Procedures at the Originating PTNX 38
A.3.5 Procedures at the Terminating PTNX 39
A.3.6 Procedures at a Gateway PTNX 40
A.3.7 Coding 41
A.3.8 Timers 42
Annex B (informative): Examples of message sequences 43
B.1 Successful CCBS 44
B.1.1 With path reservation and connection released 44
B.1.2 Without path reservation 45
B.2 Successful CCNR 45
B.3 User A busy 46
B.3.1 Path reservation case 46
B.3.2 Non-reservation case 47
B.4 User B busy again 48
B.4.1 At path reservation 48
B.4.2 At CC Call presentation - without path reservation, without service retention 49
B.4.3 At CC Call presentation - without path reservation, with service retention 50
Annex C (informative): Specification and Description Language (SDL), representation of procedures 51
C.1 Behaviour of the Originating PTNX 51
C.2 Behaviour of the Terminating PTNX 62
Annex D (informative): Imported Data types 69
History 70
Page 6
ETS 300 366:1994
Blank page
Page 7
ETS 300 366:1994
Foreword
This European Telecommunication Standard (ETS) has been produced by the European Computer Manufacturers
Association (ECMA) on behalf of its members and those of the European Telecommunications Standards Institute
(ETSI).
This ETS is one of a series of standards defining services and signalling protocols applicable to Private
Telecommunication Networks (PTNs). The series uses the Integrated Services Digital Network (ISDN) concepts as
developed by CCITT and is also within the framework of standards for open systems interconnection as defined by ISO.
This particular ETS specifies the signalling protocol for use at the Q reference point in support of the Call Completion
supplementary services.
The ETS is based upon the practical experience of ECMA member companies and the results of their active and
continuous participation in the work of ISO, CCITT, ETSI and other international and national standardisation bodies.
It represents a pragmatic and widely based consensus.
This ETS was produced by ECMA using the ECMA guidelines for the production of standards and using the ECMA
stylesheet. In order to avoid undue delays in the voting process for this ETS it has been agreed that this ETS will not be
converted to the ETSI stylesheet.

Page 8
ETS 300 366:1994
Blank page
Page 9
ETS 300 366:1994
1Scope
This European Telecommunication Standard (ETS) specifies the signalling protocol for the support of the Call
Completion supplementary services (SS-CCBS, SS-CCNR) at the Q reference point between Private
Telecommunication Network Exchanges (PTNXs) connected together within a Private Telecommunication
Network (PTN).
SS-CCBS enables a calling User A, encountering a busy destination User B, to have the call completed when
User B becomes not busy, without having to make a new call attempt.
SS-CCNR enables a calling User A, encountering a destination User B that, though alerted, does not answer, to
have the call completed when User B becomes not busy again after a period of activity, without having to make
a new call attempt.
The Q reference point is defined in Standard ISO/IEC 11579.
Service specifications are produced in three stages and according to the method specified in ENV 41005. This
Standard is the output from stage 3, the definition of signalling protocols, for SS-CCBS and SS-CCNR. This
Standard satisfies the requirements identified by the stage 1 and stage 2 specifications in ETS 300 365.
The signalling protocols for SS-CCBS and SS-CCNR operate partly on top of the signalling protocol for basic
circuit switched call control, as specified in ETS 300 172, and partly independently of a basic call. The
protocols use certain aspects of the generic procedures for the control of supplementary services specified in
ETS 300 239.
The impact on the protocol of interactions between the Call Completion services and other supplementary
services is outside the scope of this Standard.
This Standard is applicable to PTNXs which can interconnect to form a PTN.
2 Conformance
In order to conform to this Standard, a PTNX shall satisfy the requirements identified in the Protocol
Implementation Conformance Statement (PICS) proforma in Annex A.

Page 10
ETS 300 366:1994
3 References
ISO/IEC 11579: Information Technology - Telecommunications and Information Exchange between
Systems - Private Integrated Services Network - Reference Configurations for
PISN Exchanges (1994)
ETS 300 172: Private Telecommunication Network (PTN); Inter-exchange signalling protocol;
Circuit mode basic services (1994)
ETS 300 196-1: Integrated Services Digital Network (ISDN); Generic functional protocol for the
support of supplementary services; Digital Subscriber Signalling System No. one
(DSS1) protocol; Part 1: Protocol specification (1992)
ETS 300 239: Private Telecommunication Network (PTN) - Inter-exchange signalling protocol;
Generic functional protocol for the support of supplementary services (1992)
ETS 300 359-1: Integrated Services Digital Network (ISDN); Completion of Calls to Busy
Subscriber (CCBS) supplementary service; Digital Subscriber Signalling System
No. one (DSS1) protocol; Part 1: Protocol specification (1994)
ETS 300 365: Private Telecommunication Network (PTN); Specification, functional model and
information flows; Call completion supplementary services (1994)
ETS 300 171: Private Telecommunication Networks (PTN); Specification, functional model and
information flows; Control aspects of circuit mode basic services (1992)
ENV 41005: Method for the Specification of Basic and Supplementary Services of Private
Telecommunication Networks (1989)
ENV 41007-1: Definition of Terms in Private Telecommunication Networks (1989)
CCITT Rec. I.112: Vocabulary of terms for ISDNs (1988)
CCITT Rec. I.210: Principles of telecommunication services supported by an ISDN and the means to
describe them (1988)
CCITT Rec. Z.100: Specification and description language (SDL) (1988)

Page 11
ETS 300 366:1994
4 Definitions
For the purposes of this Standard the following definitions apply.
4.1 External definitions
This Standard uses the following terms defined in other documents:
− Application Protocol Data Unit (APDU) (ETS 300 239)
− Basic Service (CCITT Rec. I.210)
− Busy (ETS 300 365)
− Call, Basic Call (ETS 300 239)
− Call Independent (ETS 300 239)
− Call Independent Signalling Connection (ETS 300 239)
− Call Related (ETS 300 239)
− End PTNX (ETS 300 239)
− Gateway PTNX (Incoming / Outgoing) (ETS 300 239)
− Interpretation APDU (ETS 300 239)
− Network Facility Extension (NFE) (ETS 300 239)
− Originating PTNX (ETS 300 172)
− Private Telecommunication Network Exchange (ENV 41007-1)
− Public ISDN (ENV 41007-1)
− SS-CC Recall (ETS 300 365)
− Signalling (CCITT Rec. I.112)
− Supplementary Service (CCITT Rec. I.210)
− Supplementary Service Control Entity (ETS 300 239)
− Telecommunication Network (ENV 41007-1)
− Terminal, Terminal Equipment (ENV 41007-1)
− Terminating PTNX (ETS 300 172)
− Transit PTNX (ETS 300 172)
− User (ETS 300 171-1)
− User A (ETS 300 365)
− User B (ETS 300 365)
4.2 CC Call
The re-initiation, in the course of executing a CC Request, of the previously unsuccessful call from User A to
User B on behalf of User A, with or without Path Reservation.
4.3 CC Request
An instance of SS-CCBS or SS-CCNR.

Page 12
ETS 300 366:1994
4.4 Connection release
The release of the call independent signalling connection as soon as SS-CC has been initiated and the
establishment of further call independent signalling connections for subsequent phases of the service.
4.5 Connection retention
The use of a single call independent signalling connection throughout the lifetime of a particular instance of
SS-CC.
4.6 Path Reservation
The reservation of resources prior to the SS-CC Recall, by means of a basic call set up from the Originating
to the Terminating PTNX, in order to have a bearer connection through the PTN available when User A
accepts the SS-CC Recall.
4.7 Service retention
The optional capability to continue with a CC Request after the CC Call failed due to User B being busy
again.
5 List of acronyms
APDU Application Protocol Data Unit
ASN.1 Abstract Syntax Notation no. 1
CC Call Completion
ISDN Integrated Services Digital Network
NFE Network Facility Extension
PICS Protocol Implementation Conformance Statement
PTN Private Telecommunication Network
PTNX Private Telecommunication Network Exchange
SDL Specification and Description Language
SS-CC Supplementary Service Call Completion (i.e. SS-CCBS or SS-CCNR)
SS-CCBS Supplementary Service Call Completion to Busy Subscriber
SS-CCNR Supplementary Service Call Completion on No Reply
TE Terminal Equipment
Page 13
ETS 300 366:1994
6 Signalling protocol for the support of SS-CCBS and SS-CCNR
6.1 SS-CCBS/CCNR description
Call Completion to Busy Subscriber (SS-CCBS) is a supplementary service which allows a calling User A,
on encountering a busy called User B, to request that the PTN monitors User B and indicates to User A when
User B becomes not busy. On response by User A to that indication the PTN will attempt to complete the call
to User B.
Call Completion on No Reply (SS-CCNR) is a supplementary service which allows a calling User A, when
the called User B does not respond to the call request, to request that the PTN monitors User B and indicates
to User A when User B becomes not busy after a subsequent period of activity at User B's TE. On response
by User A to that indication the PTN will attempt to complete the call to User B.
NOTE 1
Which activities at User B's TE would result in a 'B not busy' indication to User A is outside the scope of this
Standard.
These supplementary services are applicable to all circuit mode basic services defined in ETS 300 171.
6.2 SS-CC operational requirements
6.2.1 Requirements on the Originating PTNX
Call establishment procedures for the outgoing side of an inter-PTNX link and call release procedures, as
specified in ETS 300 172, shall apply.
Generic procedures for the call related control of supplementary services, as specified in ETS 300 239 for
an End PTNX, shall apply. Additionally generic procedures for the call independent control (connection
orientated) of supplementary services, as specified in ETS 300 239 for an Originating and a Terminating
PTNX, shall apply.
6.2.2 Requirements on the Terminating PTNX
Call establishment procedures for the incoming side of an inter-PTNX link and call release procedures, as
specified in ETS 300 172, shall apply.
Generic procedures for the call related control of supplementary services, as specified in ETS 300 239 for
an End PTNX, shall apply. Additionally generic procedures for the call independent control (connection
orientated) of supplementary services, as specified in ETS 300 239 for an Originating and a Terminating
PTNX, shall apply.
6.2.3 Requirements on a Transit PTNX
Basic call procedures for call establishment and call clearing at a Transit PTNX, as specified in ETS 300
172, shall apply.
NOTE 2
The use of basic call timer T310 at a Transit PTNX can cause premature clearing of a reserved path if the timer
value is too short. For this reason this Standard specifies the sending of CCITT progress description no. 8
"in-band information or appropriate pattern now available" by the Terminating PTNX, in order to stop timer
T310, even though in-band tones and announcements are not applicable in this situation.
Generic procedures for the call related control and call independent control (connection orientated) of
supplementary services, as specified in ETS 300 239 for a Transit PTNX, shall apply.

Page 14
ETS 300 366:1994
6.3 SS-CC coding requirements
6.3.1 Operations
SS-CC-Operations { ccitt (0)  identified-organization (3)  etsi (0)
qsig-call-completion (366)  operations (0) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
OPERATION, ERROR FROM Remote-Operation-Notation
{ joint-iso-ccitt (2) remote-operations (4) notation (0) }
Extension FROM Manufacturer-specific-service-extension-definition
{ ccitt (0)  identified-organization (3)  etsi (0)
qsig-generic-procedures (239)  msi-definition (0) }
QSIGInformationElement FROM  Generic-Parameters-Definition
{ ccitt (0)  identified-organization (3)  etsi (0)
qsig-generic-procedures (239)  qsig-generic-parameters (6) }
PartyNumber, PartySubaddress, PresentedNumberUnscreened  FROM
Addressing-data-elements
{ ccitt (0)  identified-organization (3)  etsi (0)  196
addressing-data-elements (6) }
supplementaryServiceInteractionNotAllowed  FROM General-Errors
{ ccitt (0)  identified-organization (3)  etsi (0)  196
general-errors (2) };
ptnOBJECT IDENTIFIER ::=  { iso (1)  identified-organization (3)
icd-ecma (0012)  private-isdn-signalling-domain (9) }
CcbsRequest ::= OPERATION
ARGUMENT CcRequestArg
RESULT CcRequestRes
ERRORS { shortTermRejection, longTermRejection,
supplementaryServiceInteractionNotAllowed,
unspecified }
CcnrRequest ::= OPERATION
ARGUMENT CcRequestArg
RESULT CcRequestRes
ERRORS { shortTermRejection, longTermRejection,
supplementaryServiceInteractionNotAllowed,
unspecified }
CcCancel ::= OPERATION
ARGUMENT CcOptionalArg
CcExecPossible ::= OPERATION
ARGUMENT CcOptionalArg
CcPathReserve ::= OPERATION
ARGUMENT CcExtension
Page 15
ETS 300 366:1994
RESULT CcExtension
ERRORS    {remoteUserBusyAgain,
failureToMatch,
failedDueToInterworking,
unspecified  }
CcRingout ::= OPERATION
ARGUMENT CcExtension
ERRORS    {remoteUserBusyAgain,
failureToMatch,
unspecified  }
CcSuspend ::= OPERATION
ARGUMENT CcExtension
CcResume ::= OPERATION
ARGUMENT CcExtension
Unspecified ::= ERROR
PARAMETER CcExtension
CcRequestArg ::= SEQUENCE  {
numberA PresentedNumberUnscreened,
numberB PartyNumber,
service QSIGInformationElement,
-- permitted information elements are:
-- Bearer capability;
-- Low layer compatibility;
-- High layer compatibility.
subaddrA [10] PartySubaddress OPTIONAL,
subaddrB [11] PartySubaddress OPTIONAL,
can-retain-service [12]  IMPLICIT  BOOLEAN
DEFAULT FALSE,
retain-sig-connection [13]  IMPLICIT  BOOLEAN
OPTIONAL,
-- TRUE: sign. connection to be retained;
-- FALSE: sign. connection to be released;
-- omission: release or retain sign. conn.
extension CcExtension OPTIONAL  }
CcRequestRes ::= SEQUENCE {
no-path-reservation [0] IMPLICIT BOOLEAN
DEFAULT FALSE,
retain-service [1] IMPLICIT BOOLEAN
DEFAULT FALSE,
extension CcExtension  OPTIONAL  }
CcOptionalArg ::=
CHOICE   { fullArg [0] IMPLICIT SEQUENCE {
numberA PartyNumber,
numberB PartyNumber,
service QSIGInformationElement,
-- permitted information elements are:
-- Bearer capability;
Page 16
ETS 300 366:1994
-- Low layer compatibility;
-- High layer compatibility.
subaddrA [10] PartySubaddress OPTIONAL,
subaddrB [11] PartySubaddress OPTIONAL,
extension CcExtension OPTIONAL },
extArg CcExtension  }
CcExtension ::=
CHOICE   { none NULL,
single [14] IMPLICIT Extension,
multiple [15] IMPLICIT SEQUENCE OF Extension }
ccbsRequest CcbsRequest ::= { ptn  ccbs-request (40) }
ccnrRequest CcnrRequest ::= { ptn  ccnr-request (27) }
ccCancel CcCancel ::= { ptn  cc-cancel (28) }
ccExecPossible CcExecPossible ::= { ptn  cc-exec-possible (29) }
ccPathReserve CcPathReserve ::= { ptn  cc-path-reserve (30) }
ccRingout CcRingout ::= { ptn  cc-ringout (31) }
ccSuspend CcSuspend ::= { ptn  cc-suspend (32) }
ccResume CcResume ::= { ptn  cc-resume (33) }
shortTermRejection ERROR ::= { ptn 1010 }
longTermRejection ERROR ::= { ptn 1011 }
remoteUserBusyAgain ERROR ::= { ptn 1012 }
failureToMatch ERROR ::= { ptn 1013 }
failedDueToInterworking ERROR ::= { ptn 1014 }
unspecified Unspecified ::= { ptn 1008 }
END -- of SS-CC-Operations
6.3.2 Information elements
6.3.2.1 Facility information element
The operations defined in subclause 6.3.1 shall be coded in the Facility information element in
accordance with 11.3.3 of ETS 300 239.
The Facility information element shall always contain an NFE. When the Facility information element is
sent in a call related message and conveys an invoke APDU the destinationEntity element of the NFE
shall contain value endPTNX.
A Facility information element conveying a ccPathReserve invoke APDU shall also contain an
Interpretation APDU with value clearCallIfAnyInvokePduNotRecognised. In all other cases the
Interpretation APDU shall either be omitted or included with value rejectAnyUnrecognisedInvokePdu.
Within elements of type QSIGInformationElement information elements (e.g. Bearer capability) shall
be coded in accordance with ETS 300 172.

Page 17
ETS 300 366:1994
6.3.2.2 Other information elements
Any other information elements (e.g. Calling party number, Called party number) shall be coded in
accordance with the rules of ETS 300 172 and ETS 300 239.
6.3.3 Messages
The Facility information element shall be conveyed in the messages as specified in Clause 10 of ETS 300
239.
6.4 SS-CC State definitions
6.4.1 States at the Originating PTNX
The procedures for the Originating PTNX are written in terms of the following conceptual states existing
within the SS-CC Supplementary Service Control entity in that PTNX in association with a particular CC
Request.
6.4.1.1 CC-Idle
This state exists if SS-CC is not active.
6.4.1.2 CC-Wait-Ack
This state exists during SS-CC invocation.
6.4.1.3 CC-Invoked-A-RET
This state exists for an active CC Request while waiting for the indication that User B is not busy,
using the connection retention method.
6.4.1.4 CC-Invoked-A-RLS
This state exists for an active CC Request while waiting for the indication that User B is not busy, using
the connection release method.
6.4.1.5 CC-Suspended-A
This state exists when a CC Call without Path Reservation has been postponed because User A is busy.
6.4.1.6 CC-Path-Setup
This state exists during Path Reservation.
6.4.1.7 CC-Wait-User-A-Answer-N
This state exists while waiting for SS-CC Recall acceptance from User A if no path has been reserved.
6.4.1.8 CC-Wait-User-A-Answer-R
This state exists while waiting for SS-CC Recall acceptance from User A after a path has been reserved.
6.4.1.9 CC-Ringout
This state exists when User A has accepted the SS-CC Recall but completion of the call to User B is
still pending.
6.4.1.10 CC-Wait-User-A-Free
This state exists when Path Reservation is delayed because User A is busy.
6.4.2 States at the Terminating PTNX
The procedures for the Terminating PTNX are written in terms of the following conceptual states existing
within the SS-CC Supplementary Service Control entity in that PTNX in association with a particular CC
Request.
Page 18
ETS 300 366:1994
6.4.2.1 CC-Idle
This state exists if SS-CC is not active.
6.4.2.2 CC-Invoked-B
This state exists while User B is monitored as a result of a CC Request received.
6.4.2.3 CC-Await-Call-Completion
This state exists while waiting for the incoming CC Call after having indicated that User B is not busy.
6.4.2.4 CC-Suspended-B
This state exists when a CC Call has been postponed because User A is busy.
6.4.2.5 CC-Path-Complete
This state exists when a path has been successfully reserved and CC Call completion is pending.
6.4.2.6 CC-Wait-User-B-Alert
This state exists after a CC Call has been extended to User B, while waiting for acceptance (alerting or
connect).
6.5 SS-CC signalling procedures
The following procedures are a combination of call related and call independent signalling. The latter uses
the connection-oriented APDU transport mechanism specified in ETS 300 239, which provides call
independent signalling connections for supplementary service control.
All SS-CC control information is exchanged between Originating PTNX and Terminating PTNX.
Examples of message sequences are shown in Annex B.
6.5.1 Major options
The signalling protocol contains the following major options. These are negotiated between the
Originating and Terminating PTNXs at SS-CC invocation time, using specific elements in the argument
and result of operations ccbsRequest and ccnrRequest.
6.5.1.1 Path reservation
There are two methods of establishing the CC Call:
• path reservation method - a bearer connection between the Originating and Terminating PTNXs is
established before recalling User A, to avoid the possibility of encountering network congestion
after User A responds to SS-CC Recall;
• non-reservation method - a bearer connection between the Originating and Terminating PTNXs is
established after User A responds to SS-CC Recall and the service is cancelled if network
congestion is encountered.
As described in subclause 6.5.2, it is an option of the Originating PTNX which of these methods is
used. The procedures specified in subclause 6.5.3 mandate from a Terminating PTNX the support of
both methods. In interworking situations, an Outgoing Gateway PTNX can force the use of the
non-reservation method if the other network cannot support path reservation; see subclauses 6.6 and
6.7.
Page 19
ETS 300 366:1994
6.5.1.2 Retention of signalling connection
There are two ways in which SS-CC uses call independent signalling connections:
• connection retention method - the signalling connection is maintained until completion or
cancellation of SS-CC;
• connection release method - the signalling connection is cleared after each phase of call
independent signalling and a new signalling connection is established for each subsequent phase of
call independent signalling.
If the path reservation method is used, both methods above are possible. The procedures specified in
subclauses 6.5.2 and 6.5.3 leave the decision on the method to the Terminating PTNX, but permit the
Originating PTNX to ask for the use of the connection release method if possible, in order to avoid
occupying network resources for the duration of the service. Similarly, subclause 6.7 permits an
Incoming Gateway PTNX to ask for the use of the connection release method for compatibility with
other networks.
If the non-reservation method is used connection retention is required. Subclauses 6.6 and 6.7 provide a
means by which an Incoming Gateway PTNX or Outgoing Gateway PTNX can force the use of the
connection retention method for compatibility with public ISDNs and other networks that operate with a
retained connection.
6.5.1.3 Service retention
There are two possible behaviours when User B is found to be busy again after User A responds to
SS-CC Recall.
• service retention method - the CC Request remains in force at the Originating and Terminating
PTNXs and the Terminating PTNX commences the monitoring of User B again;
• service cancellation method - the CC Request is cancelled at the Originating and Terminating
PTNXs.
Either PTNX can force the use of the service cancellation method. The service retention method will be
used if both PTNXs agree.
6.5.2 Actions at the Originating PTNX
The SDL representation of procedures at the Originating PTNX is shown in Clause C.1 of Annex C.
6.5.2.1 Normal procedures
6.5.2.1.1 CCBS invocation
If User A requests SS-CCBS and the request is acceptable to the Originating PTNX, the Originating
PTNX shall send a ccbsRequest invoke APDU to the Terminating PTNX according to
subclause 6.5.2.1.3.
NOTE 3
SS-CCBS can be requested after a call attempt has encountered a busy condition at User B. The release of
the original call is beyond the scope of this Standard.
Upon receipt of a ccbsRequest return result APDU the Originating PTNX shall start the service
duration timer T2 with a value appropriate for SS-CCBS, enter state CC-Invoked-A-RET (connection
retention case) or CC-Invoked-A-RLS (connection release case), and wait for an indication that User
B has become not busy.
Page 20
ETS 300 366:1994
6.5.2.1.2 CCNR invocation
If User A requests SS-CCNR and the request is acceptable to the Originating PTNX, the Originating
PTNX shall send a ccnrRequest invoke APDU to the Terminating PTNX according to
subclause 6.5.2.1.3.
NOTE 4
SS-CCNR can be requested after a call to User B has remained unanswered. The release of the original
call is beyond the scope of this Standard.
Upon receipt of a ccnrRequest return result APDU the Originating PTNX shall start the service
duration timer T2 with a value appropriate for SS-CCNR, enter state CC-Invoked-A-RET
(connection retention case) or CC-Invoked-A-RLS (connection release case), and wait for an
indication that User B has become not busy after a subsequent period of activity.
6.5.2.1.3 SS-CC invocation - detailed procedure
The Facility information element containing the ccbsRequest or ccnrRequest invoke APDU shall be
sent in a SETUP message which establishes a call independent signalling connection between the two
end PTNXs, according to subclause 7.3 of ETS 300 239. The SETUP message shall contain User B's
number in information element Called party number, and optionally User A's number in information
element Calling party number.
The following information shall be included in the argument of the ccbsRequest or ccnrRequest
invoke APDU:
• basic call information from the original call:
− the number of User A, or an indication that it is not available or restricted, in element
numberA;
− optionally and if available, the subaddress of User A, in element subaddrA;
− the number of User B, in element numberB;
− if available, the subaddress of User B, in element subaddrB;
− the information elements Bearer capability, Low layer compatibility (if available) and High
layer compatibility (if available), embedded in element service;
• optionally element retain-sig-connection, according to the following rules:
− if the signalling connection has to be retained because the non-reservation method is going
to be used the element shall be included with value TRUE;
− if the Originating PTNX is going to use the path reservation method and prefers the
connection release option the element shall be included with value FALSE;
− if the Originating PTNX is going to use the path reservation method and has no preference
for the connection release option the element shall be omitted;
• optionally element can-retain-service with value TRUE if the Originating PTNX is able to use
the service retention method. Otherwise the element shall either be omitted or have the value
FALSE.
After sending the ccbsRequest/ccnrRequest invoke APDU the Originating PTNX shall start timer T1
and enter state CC-Wait-Ack.
Page 21
ETS 300 366:1994
Upon receipt of a ccbsRequest or ccnrRequest return result APDU the Originating PTNX shall stop
timer T1 and store the following information:
• If the result contains element retain-service with value TRUE and element can-retain-service was
sent with value TRUE in the argument of the corresponding invoke APDU, the Originating
PTNX shall record the fact that the service retention method is to be used; otherwise it shall
record the fact that the service cancellation method is to be used.
• If the result contains element no-path-reservation with value TRUE the Originating PTNX shall
record the fact that the non-reservation method is to be used. Otherwise it may select either the
path reservation method or the non-reservation method.
• If path reservation is to be used, all the information contained in the argument of the
ccbsRequest or ccnrRequest invoke APDU.
If the ccbsRequest/ccnrRequest return result APDU was received in a CONNECT message the
Originating PTNX shall continue according to the procedures specified for the connection retention
method. If the return result APDU was received in a RELEASE message and connection release is
permitted, the Originating PTNX shall complete the clearing of the signalling connection in
accordance with subclause 7.3 of ETS 300 239 and continue according to the procedures specified
for the connection release method.
6.5.2.1.4 Indication that User B is not busy
a)    Connection retention case:
If a ccExecPossible invoke APDU is received in a FACILITY message (i.e. on the retained call
independent signalling connection) while in state CC-Invoked-A-RET the Originating PTNX shall
proceed as described under c) below. Any basic call information, if present in the argument of the
ccExecPossible invoke APDU, shall be ignored.
b)   Connection release case:
On receipt of a ccExecPossible invoke APDU in a SETUP message for a call independent signalling
connection the Originating PTNX shall process the SETUP message according to subclause 7.3 of
ETS 300 239, attempt to associate the APDU with a CC Request that is in state CC-Invoked-A-RLS,
and if successful proceed as described under c) below.
The association shall be achieved by comparing all the basic call information received in the
argument of the ccExecPossible invoke APDU with the information stored at the Originating PTNX.
If less information is received than what is stored, a match shall be deemed to occur if all the
elements received match those stored and any missing element belongs to the following
group: subaddress of User A; subaddress of User B; High layer compatibility information element;
Low layer compatibility information element.
NOTE 5
Information can be missing as a result of the Terminating PTNX discarding part of the optional
information at SS-CC invocation time. This need not cause ambiguity provided the Terminating PTNX
rejects CC Requests which are duplicates with regard to the remaining information.
NOTE 6
The Originating PTNX with regard to SS-CC is the Terminating PTNX with regard to the call independent
signalling connection.
Page 22
ETS 300 366:1994
c)    For both cases:
In both cases a) and b) above the Originating PTNX shall proceed in accordance with
• 6.5.2.1.5, if User A is not busy and the non-reservation method is to be used; or
• 6.5.2.1.6, if User A is not busy and the path reservation method is to be used; or
• 6.5.2.1.7, if User A is busy and the non-reservation method is to be used; or
• 6.5.2.1.8, if User A is busy and the path reservation method is to be used.
6.5.2.1.5 CC Call without Path Reservation
If User A is not busy and the Originating PTNX chooses the non-reservation method for establishing
the CC Call, the Originating PTNX shall indicate the SS-CC Recall to User A, start the recall timer
T3 and enter state CC-Wait-User-A-Answer-N.
If the SS-CC Recall is accepted before timer T3 expires the Originating PTNX shall initiate the CC
Call in accordance with ETS 300 172 by sending a SETUP message towards the Terminating PTNX,
stop timer T3 and enter state CC-Ringout; the SETUP message shall contain a Facility information
element with a ccRingout invoke APDU.
If in state CC-Ringout an ALERTING or a CONNECT message is received the Originating PTNX
shall stop the service duration timer T2, delete the CC Request and return to state CC-Idle. If a call
independent signalling connection for SS-CC still exists it may be released according to
subclause 7.3 of ETS 300 239. The CC Call shall continue in accordance with ETS 300 172.
6.5.2.1.6 CC Call with Path Reservation
If User A is not busy and the Originating PTNX chooses the path-reservation method for establishing
the CC Call, the Originating PTNX shall:
• if the connection release method is used, return a RELEASE message with cause value #16
"normal call clearing" to release the signalling connection; optionally the RELEASE message
may also be sent in the connection retention case, if the service retention option does not apply
and no further call independent signalling is expected;
• initiate Path Reservation as a basic call request according to ETS 300 172, sending a SETUP
message towards the Terminating PTNX; the SETUP message shall contain a ccPathReserve
invoke APDU, as well as all the information stored from the original call;
• start timer T4; and
• enter state CC-Path-Setup.
Upon receipt of a ccPathReserve return result APDU while in state CC-Path-Setup the Originating
PTNX shall stop timer T4.
If User A is busy the Originating PTNX shall, if the capability exists, indicate to User A that User B
is not busy. Either immediately or if the busy condition persists the Originating PTNX shall continue
according to subclause 6.5.2.1.9.
NOTE 7
The means of determining whether the busy condition persists is implementation dependent.
If User A is not busy the Originating PTNX shall indicate the SS-CC Recall to User A, start the
recall timer T3 and enter state CC-Wait-User-A-Answer-R.

Page 23
ETS 300 366:1994
If the SS-CC Recall is accepted before timer T3 expires the Originating PTNX shall stop timer T3,
send a call related FACILITY message with a ccRingout invoke APDU to the Terminating PTNX
and enter state CC-Ringout.
If in state CC-Ringout an ALERTING or CONNECT message is received, the Originating PTNX
shall stop the service duration timer T2, delete the CC Request and return to state CC-Idle. If a call
independent signalling connection for SS-CC still exists it may be released according to
subclause 7.3 of ETS 300 239. The CC Call shall continue in accordance with ETS 300 172.
6.5.2.1.7 User A busy, non-reservation method
a)    Suspend procedure:
If User A is busy and the Originating PTNX chooses the non-reservation method, the Originating
PTNX shall send a ccSuspend invoke APDU to the Terminating PTNX in a FACILITY message on
the existing call independent signalling connection, start monitoring User A and enter state
CC-Suspended-A.
b)   Resume procedure:
If User A, for whom a CC Request in state CC-Suspended-A exists, becomes not busy the Originating
PTNX shall send a FACILITY message with a ccResume invoke APDU on the existing call
independent signalling connection and enter state CC-Invoked-A-RET, waiting for another indication
that User B is not busy.
6.5.2.1.8 User A busy before Path Reservation
If User A is busy and the Originating PTNX chooses the path reservation method, the Originating
PTNX shall release the call independent signalling connection according to subclause 7.3 of ETS 300
239, unless the connection retention method applies, start monitoring User A, and enter state
CC-Wait-User-A-Free. Cause #16 "normal call clearing" shall be used when releasing the signalling
connection.
The Originating PTNX may also send a ccSuspend invoke APDU to the Terminating PTNX on the
existing call independent signalling connection, either in the RELEASE message in case of
connection release or in a FACILITY message in case of connection retention.
If User A, for whom a CC Request in state CC-Wait-User-A-Free exists, becomes not busy the
Originating PTNX shall initiate a CC Call with Path Reservation according to subclause 6.5.2.1.6.
6.5.2.1.9 User A busy after Path Reservation
If User A is busy on completion of Path Reservation the Originating PTNX shall release the reserved
path by sending a DISCONNECT message to the Terminating PTNX, start monitoring User A and
enter state CC-Wait-User-A-Free. The DISCONNECT message shall contain a Facility information
element with a ccSuspend invoke APDU.
If User A, for whom a CC Request in state CC-Wait-User-A-Free exists, becomes not busy the
Originating PTNX shall initiate a CC Call with Path Reservation according to subclause 6.5.2.1.6.

Page 24
ETS 300 366:1994
6.5.2.1.10 CCBS/CCNR cancellation
a)    Cancellation initiated by the Originating PTNX:
In order to cancel a CC Request, the Originating PTNX shall send a ccCancel invoke APDU to the
Terminating PTNX, release any call independent signalling connection by sending a RELEASE
message with cause #16 "normal call clearing", release any CC Call by sending a DISCONNECT
message with cause #16 "normal call clearing", delete all data stored for that CC Request, stop any
timer running, and return to state CC-Idle. Unless cancellation was initiated by user request or the
Originating PTNX automatically re-invokes SS-CC, User A shall, if the capability exists, be
informed of failure of the service.
If a call independent signalling connection exists the ccCancel invoke APDU shall be sent with
argument extArg in the RELEASE message that initiates clearing of the connection.
If no call independent signalling connection exists but a path has been reserved (i.e. after a
ccPathReserve return result APDU was received) the ccCancel invoke APDU shall be sent with
argument extArg in the DISCONNECT message that initiates clearing of the reserved path.
In all other cases the ccCancel invoke APDU shall be sent in a SETUP message establishing a new
signalling connection according to subclause 7.3 of ETS 300 239. The invoke APDU shall include
argument fullArg with the same basic call information as previously sent in the ccbsRequest or
ccnrRequest invoke APDU, in order to identify the CC Request to be cancelled. When subsequently
receiving a RELEASE message, the signalling connection shall be cleared in accordance with ETS
300 239.
b)   Cancellation initiated by the Terminating PTNX:
On receipt of a ccCancel invoke APDU from the Terminating PTNX in the RELEASE message for
an existing call independent signalling connection the Originating PTNX shall delete all data stored
for the associated CC Request, stop any timer still running, clear the CC Call - if already initiated - in
accordance with ETS 300 172, inform User A of the cancellation, if the capability exists, and return
to state CC-Idle. Any basic call information, if present in the argument of the ccCancel invoke
APDU, shall be ignored.
On receipt of a ccCancel invoke APDU in the SETUP message for a new call independent signalling
connection the Originating PTNX shall attempt to associat
...