SIST ETS 300 362 E1:2005

SLOVENSKI STANDARD
01-maj-2005
Zasebno telekomunikacijsko omrežje (PTN) – Medcentralni signalizacijski protokol
- Dopolnilna storitev: ponudba klica
Private Telecommunication Network (PTN); Inter-exchange signalling protocol; Call offer
supplementary service
Ta slovenski standard je istoveten z: ETS 300 362 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 362
TELECOMMUNICATION November 1994
STANDARD
Source:ETSI TC-ECMA Reference:DE/ECMA-00052
ICS: 33.080
CCS, CO, PTN, QSIG, stage 3, supplementary service, ECMA-192
Key words:
Private Telecommunication Network (PTN);
Inter-exchange signalling protocol
Call offer supplementary service
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
F-06921 Sophia Antipolis CEDEX - FRANCE
Postal address:
650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Office address:
c=fr, a=atlas, p=etsi, s=secretariat - secretariat@etsi.fr
X.400: Internet:
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
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 362: November 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 362: November 1994
Contents
Foreword.5
1 Scope .7
2 Conformance .7
3 References .7
4 Definitions .8
4.1 External definitions.8
4.2 Inter-PTNX link.8
4.3 Path retention.8
5 List of acronyms .9
6 Signalling protocol for the support of SS-CO.9
6.1 SS-CO description .9
6.2 SS-CO operational requirements .9
6.2.1 Requirements on the Originating PTNX .9
6.2.2 Requirements on the Terminating PTNX.9
6.2.3 Requirements on a Transit PTNX .9
6.3 SS-CO coding requirements .9
6.3.1 Operations.9
6.3.2 Notifications.12
6.3.3 Information elements.12
6.3.3.1 Facility information element .12
6.3.3.2 Notification indicator information element .12
6.3.3.3 Other information elements.13
6.3.4 Messages .13
6.4 SS-CO state definitions.13
6.4.1 States at the Originating PTNX.13
6.4.1.1 State CO-Idle .13
6.4.1.2 State CO-Wait-Ack .13
6.4.2 States at the Terminating PTNX .13
6.4.2.1 State CO-Idle .13
6.4.2.2 State CO-Dest-Invoked .13
6.5 SS-CO signalling procedures for activation, deactivation and registration.13
6.6 SS-CO signalling procedures for invocation and operation.13
6.6.1 Actions at the Originating PTNX.13
6.6.1.1 Normal procedures.14
6.6.1.2 Exceptional procedures.14
6.6.2 Actions at the Terminating PTNX.14
6.6.2.1 Normal procedures.15
6.6.2.2 Exceptional procedures.15
6.6.3 Actions at a Transit PTNX.16
6.7 SS-CO impact of interworking with public ISDNs.16
6.8 SS-CO impact of interworking with non-ISDNs.16
6.9 SS-CO parameter values (timers) .16
Annex A (normative): Signalling protocol for the support of Path Retention.17
A.1 Path Retention description.17

Page 4
ETS 300 362: November 1994
A.2 Path Retention operational requirements . 17
A.2.1 Requirements on the Originating PTNX . 17
A.2.2 Requirements on the Terminating PTNX . 17
A.2.3 Requirements on a Transit PTNX . 17
A.3 Path Retention coding requirements . 18
A.3.1 Operations . 18
A.3.2 Information elements. 18
A.3.3 Messages . 18
A.4 Path Retention state definitions. 18
A.4.1 States at the Originating PTNX. 18
A.4.1.1 PRTO-Idle. 18
A.4.1.2 PRTO-Requested. 18
A.4.1.3 PRTO-Retained. 18
A.4.1.4 PRTO-Invoking. 18
A.4.2 States at the Terminating PTNX. 18
A.4.2.1 PRTT-Idle . 18
A.4.2.2 PRTT-Requested. 19
A.4.2.3 PRTT-Retained . 19
A.4.2.4 PRTT-Invoking . 19
A.5 Path Retention signalling procedures for invocation and operation. 19
A.5.1 Actions at the Originating PTNX . 19
A.5.2 Actions at the Terminating PTNX. 20
A.5.3 Actions at a Transit PTNX . 21
A.6 Path Retention impact of interworking with public ISDNs. 21
A.7 Path Retention impact of interworking with non-ISDNs. 21
A.8 Path Retention parameter values (timers) . 21
A.9 Specification and Description Language (SDL) - Representation of procedures
(informative) . 22
A.9.1 SDL representation of Path Retention at the Originating PTNX. 22
A.9.2 SDL representation of Path Retention at the Terminating PTNX. 24
Annex B (normative): Protocol Implementation Conformance Statement (PICS) Proforma. 27
B.1 Introduction. 27
B.2 Instructions for completing the PICS proforma . 27
B.2.1 General structure of the PICS proforma . 27
B.2.2 Additional information . 28
B.2.3 Exception information . 28
B.3 PICS proforma for ETS 300 362 . 28
B.3.1 Implementation identification. 28
B.3.2 Protocol summary. 29
B.3.3 General . 29
B.3.4 Procedures. 30
B.3.5 Coding . 30
B.3.6 Timers . 30
Annex C (informative): Examples of Message Sequences. 31
C.1 Example message sequence for normal operation of SS-CO without Path Retention. 32
C.2 Example message sequence for normal operation of SS-CO with Path Retention. 33
C.3 Example of unsuccessful invocation of SS-CO without Path Retention . 34
C.4 Example of unsuccessful invocation of Path Retention for SS-CO. 34
Annex D (informative): Specification and Description Language (SDL) representation of procedures. 35
D.1 SDL representation of SS-CO at the Originating PTNX. 36
D.2 SDL representation of SS-CO at the Terminating PTNX . 37
History . 38

Page 5
ETS 300 362: November 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 ISDN concepts as developed by the ITU-T(formerly CCITT)
and is also within the framework of standards for open systems interconnection as defined by ISO.
This ETS specifies the signalling protocol for use at the Q reference point in support of the Call Offer supplementary
service.
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, ITU-T(formerly 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 approval process for this ETS it has been agreed that this ETS will not
be converted to the ETSI stylesheet.
Transposition dates
Date of latest announcement of this ETS (doa): 28 February 1995
Date of latest publication of new National Standard 31 August 1995
or endorsement of this ETS (dop/e):
Date of withdrawal of any conflicting National Standard (dow): 31 August 1995

Page 6
ETS 300 362: November 1994
Blank page
Page 7
ETS 300 362: November 1994
1 Scope
This European Telecommunication Standard (ETS) specifies the signalling protocol for the support of the Call
Offer supplementary service (SS-CO) at the Q reference point between Private Telecommunication Network
Exchanges (PTNXs) connected together within a Private Telecommunication Network (PTN).
SS-CO is a supplementary service which, on request from the calling user (or on that user's behalf), enables a
call to be offered to a busy called user and to wait for that called user to accept this call.
The Q reference point is defined in IS 11579.
Service specifications are produced in three stages and according to the method specified in ETS 300 387. This
ETS contains the stage 3 specification for the Q reference point and satisfies the requirements identified by the
stage 1 and stage 2 specifications in ETS 300 361.
The signalling protocol for SS-CO operates on top of the signalling protocol for basic circuit switched call
control, as specified in ETS 300 172, and uses 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 Offer supplementary service and other
supplementary services is outside the scope of this ETS.
This ETS is applicable to PTNXs which can interconnect to form a PTN.
2 Conformance
In order to conform to this ETS, a PTNX shall satisfy the requirements identified in the Protocol
Implementation Conformance Statement (PICS) proforma in annex B.
3 References
IS 11579 Information Technology - Telecommunications and Information Exchange Between Systems
- Private Integrated Services Network - Reference Configurations for PISN Exchanges
(1993).
ETS 300 171 Private Telecommunication Network (PTN); Specification, functional model and
information flows, control aspects of circuit mode basic services (1993).
ETS 300 172 Private Telecommunication Network (PTN); Inter-exchange signalling protocol, circuit
mode basic services (1993).
ETS 300 196 Integrated Services Digital Network (ISDN); Generic functional protocol for the support of
supplementary services Digital Subscriber Signalling System No. one (DSS1) protocol.
ETS 300 239 Private Telecommunication Network (PTN); Inter-exchange signalling protocol, generic
functional protocol for the support of supplementary services (1993).
ETS 300 361 Private Telecommunication Network (PTN); Specification, functional model and
information flows Call offer supplementary service (1994).
ETS 300 387 Private Telecommunications Network (PTN); Method for the specification of basic and
supplementary services (1994).
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 (1988).

Page 8
ETS 300 362: November 1994
4 Definitions
For the purpose of this ETS the following definitions apply.
4.1 External definitions
This ETS uses the following terms defined in other documents:
− Application Protocol Data Unit (APDU) (ETS 300 239);
− Basic Service (CCITT Recommendation I.210);
− Call, Basic Call (ETS 300 239);
− Coordination Function (ETS 300 239);
− Notification (ETS 300 239);
− Originating PTNX (ETS 300 172);
− Private (ENV 41007-1);
− Private Telecommunication Network Exchange (ENV 41007-1);
− Public ISDN (ENV 41007-1);
− Signalling (CCITT Recommendation I.112);
− Supplementary Service (CCITT Recommendation I.210);
− Supplementary Service Control Entity (ETS 300 239);
− Telecommunication Network (ENV 41007-1);
− Terminal (ENV 41007-1);
− Terminating PTNX. (ETS 300 172);
− Transit PTNX (ETS 300 172);
− User (ETS 300 171).
4.2 Inter-PTNX link
The totality of a signalling channel and a number of user information channels at the Q reference point.
4.3 Path retention
The retaining of the network connection between the Originating PTNX and the Terminating PTNX so that a
supplementary service (such as SS-CO) can be invoked without establishing a new connection.

Page 9
ETS 300 362: November 1994
5 List of acronyms
APDU Application Protocol Data Unit
ASN.1 Abstract Syntax Notation no. 1
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-CO Call Offer supplementary service
6 Signalling protocol for the support of SS-CO
6.1 SS-CO description
Call Offer (SS-CO) is a supplementary service which, on request from the calling user (or on that user's
behalf), enables a call to be offered to a busy called user and to wait for that called user to accept this call.
SS-CO is applicable to all circuit mode basic services defined in ETS 300 171.
6.2 SS-CO 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.
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.
6.2.3 Requirements on a Transit PTNX
Basic call procedures specified in ETS 300 172 for a Transit PTNX shall apply.
Generic procedures for the call-related control of supplementary services, as specified in ETS 300 239 for
a Transit PTNX, shall apply.
For SS-CO the requirements are limited to the passing on of Facility information elements for which the
destination, as indicated in the NFE, is not the Transit PTNX.
6.3 SS-CO coding requirements
6.3.1 Operations
The operations defined in Abstract Syntax Notation number 1 (ASN.1) in table 1 shall apply.

Page 10
ETS 300 362: November 1994
Table 1 - Operations in support of SS-CO
Call-Offer-Operations
{iso(1) identified-organization(3) icd-ecma(0012) standard(0)
qsig-call-offer(192) call-offer-operations (0) }
DEFINITIONS EXPLICIT TAGS::=
BEGIN
IMPORTS OPERATION, ERROR FROM Remote-Operation-Notation
{joint-iso-ccitt(2) remote-operations(4) notation(0)}
Extension FROM ECMA-manufacturer-specific-service-extension-definition
{iso(1) identified-organization(3) icd-ecma(0012) standard(0)
qsig-generic-procedures(165) msi-definition(0)}
notAvailable, supplementaryServiceInteractionNotAllowed FROM General-Errors
{ccitt(0) identified-organization(3) etsi (0) 196 general-errors (2)};
ptn OBJECT IDENTIFIER
::= { iso(1) identified-organization(3) icd-ecma(0012)
private-isdn-signalling-domain (9)}
PathRetain ::= OPERATION
ARGUMENT PathRetainArg
-- this operation may be used by other supplementary services
-- using other values of argument
ServiceAvailable ::= OPERATION
ARGUMENT ServiceAvailableArg
-- this operation may be used by other supplementary services
-- using other values of argument
CallOfferRequest ::= OPERATION
ARGUMENT DummyArg
RESULT DummyRes
ERRORS { notAvailable, notBusy, temporarilyUnavailable,
supplementaryServiceInteractionNotAllowed, unspecified}
PathRetainArg ::= CHOICE {serviceList ServiceList,
extendedServiceList SEQUENCE{
serviceList ServiceList,
extension Extension
}
}
Page 11
ETS 300 362: November 1994
ServiceAvailableArg ::= CHOICE {serviceList ServiceList,
extendedServiceList SEQUENCE{
serviceList ServiceList,
extension Extension
}
}
ServiceList ::= BIT STRING (SIZE(1.32)) {callOffer(0)}
-- bits other than callOffer(0) are reserved for
-- other supplementary services
DummyArg ::= CHOICE{
null NULL,
extension [1] IMPLICIT Extension,
sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension}
DummyRes ::= CHOICE{
null NULL,
extension [1] IMPLICIT Extension,
sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension}
callOfferRequest CallOfferRequest ::= {ptn co-request(34)}
pathRetain   PathRetain   ::= {ptn path-retain(41)}
serviceAvailable ServiceAvailable ::={ptn service-available(42)}
notBusy ERROR ::= {ptn 1009}
-- used when an SS-CO request is received in
-- a Terminating PTNX and the called user is not busy
temporarilyUnavailable ERROR ::={ptn 1000}
-- used when conditions for invocation of SS-CO
-- are momentarily not met
Unspecified ::= ERROR PARAMETER Extension
unspecified Unspecified ::= {ptn 1008}
END -- of Call-Offer-Operations

Page 12
ETS 300 362: November 1994
6.3.2 Notifications
The notification defined in Abstract Syntax Notation number 1(ASN.1) in table 2 shall apply.
Table 2 - Notification in support of SS-CO
Call-Offer-Notifications
{iso(1) identified-organization(3) icd-ecma(0012) standard(0)
qsig-call-offer(192) call-offer-notifications(1)}
DEFINITIONS ::=
BEGIN
IMPORTS NOTIFICATION FROM Notification-Data-Structure
{iso(1) identified-organization(3) icd-ecma(0012) standard(0)
qsig-generic-procedures(165) notification-data-structure(7)};
RemoteUserAlerting ::= NOTIFICATION
ARGUMENT NULL
remoteUserAlerting RemoteUserAlerting ::=
{iso(1) identified-organization(3) icd-ecma(0012)
private-isdn-signalling-domain(9) 2000}
END --of Call-Offer-Notifications
6.3.3 Information elements
6.3.3.1 Facility information element
The operations defined above shall be coded in the Facility information element in accordance with
ETS 300 239.
When conveying an APDU of operation callOfferRequest, the NFE shall be included.
When conveying the invoke APDU of operation callOfferRequest, the destinationEntity data element of
the NFE shall contain value endPTNX.
When conveying the invoke APDU of operation callOfferRequest, the Interpretation APDU shall be
omitted.
NOTE 1
Additional requirements for the conveyance of APDUs of operations pathRetain and serviceAvailable are
given in A.3.2 of annex A.
6.3.3.2 Notification indicator information element
The notification defined above shall be coded in the Notification indicator information element in
accordance with ETS 300 239.
Page 13
ETS 300 362: November 1994
6.3.3.3 Other information elements
Any other information elements (e.g. Cause, Progress indicator) shall be coded in accordance with the
rules of ETS 300 172.
6.3.4 Messages
The Facility information element and the Notification indicator information element shall be conveyed in
the messages as specified in clause 10 of ETS 300 239.
Messages used for call establishment and release shall be as specified in ETS 300 172.
6.4 SS-CO 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-CO Supplementary Service Control entity in that PTNX in association with a particular call.
6.4.1.1 State CO-Idle
SS-CO is not operating.
6.4.1.2 State CO-Wait-Ack
The Originating PTNX has requested SS-CO and is waiting for an acknowledgement from the
Terminating PTNX.
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-CO Supplementary Service Control entity in that PTNX in association with a particular call.
6.4.2.1 State CO-Idle
SS-CO is not operating.
6.4.2.2 State CO-Dest-Invoked
SS-CO has been invoked successfully.
6.5 SS-CO signalling procedures for activation, deactivation and registration
Not applicable.
6.6 SS-CO signalling procedures for invocation and operation
The following procedures are call associated.
SS-CO may be invoked in two ways depending on whether the network connection is retained when a call
encounters a busy called user. Retention of the network connection makes use of a generic path retention
mechanism, which is specified in annex A.
Annex C contains some examples of message sequences.
6.6.1 Actions at the Originating PTNX
For a given call, the Originating PTNX shall choose one of the following two methods for invocation of
SS-CO:
− invocation without path retention;

Page 14
ETS 300 362: November 1994
− invocation with path retention.
For invocation with path retention, the procedures specified below apply in conjunction with the
procedures specified in A.5.1 of annex A.
For each method, if the basic call clears in circumstances other than those covered below, SS-CO shall
terminate, any SS-CO timer shall be stopped, and state CO-Idle shall be entered (e.g. on calling user
release, call failure, etc.).
The SDL representation of procedures at the Originating PTNX is shown in D.1 of annex D.
6.6.1.1 Normal procedures
To invoke SS-CO the Originating PTNX shall send a callOfferRequest invoke APDU, start timer T1 and
enter state CO-Wait-Ack. For invocation without path retention, the APDU shall be sent in the SETUP
message that establishes the call. For invocation with path retention, the APDU shall be sent in a
FACILITY message using the call reference of a call for which the network connection has been
retained in accordance with A.5.1 of annex A (Path Retention state PRTO-Retained) and for which the
received serviceAvailable invoke APDU indicated that SS-CO is invokable.
In state CO-Wait-Ack, on receipt of a callOfferRequest return result APDU in a PROGRESS, a
FACILITY or an ALERTING message, the Originating PTNX shall stop timer T1 and shall enter state
CO-Idle.
NOTE 2
Successful invocation of SS-CO should be indicated to the calling user.
NOTE 3
The completion of SS-CO will be indicated by release of the call, receipt of an ALERTING or a CONNECT
message (handled in accordance with ETS 300 172) or receipt of a NOTIFY message containing notification
description value "remoteUserAlerting" (handled in accordance with ETS 300 239).
6.6.1.2 Exceptional procedures
In state CO-Wait-Ack, on receipt of:
− any message containing a callOfferRequest return error or reject APDU; or
− an ALERTING, CONNECT or DISCONNECT message without a callOfferRequest return result,
return error or reject APDU,
the Originating PTNX shall stop timer T1 and enter state CO-Idle, and the call shall continue in
accordance with ETS 300 172.
On expiry of timer T1 the Originating PTNX shall enter state CO-Idle and the call shall continue in
accordance with ETS 300 172.
NOTE 4
Failure of SS-CO should be indicated to the calling user.
6.6.2 Actions at the Terminating PTNX
The Terminating PTNX shall support the two methods of invocation.
For invocation with path retention, the procedures specified below apply in conjunction with the
procedures specified in A.5.2 of annex A.
For each method, if the basic call clears in circumstances other than those covered below, SS-CO shall
terminate and state CO-Idle shall be entered.

Page 15
ETS 300 362: November 1994
The SDL representation of procedures at the Terminating PTNX is shown in D.2 of annex D.
6.6.2.1 Normal procedures
If, while processing an incoming SETUP message in accordance with the procedures of ETS 300 172,
the called user is found to be busy, and if the SETUP message contained a callOfferRequest invoke
APDU, and if all conditions are met to allow SS-CO on the called user, the Terminating PTNX shall not
send a DISCONNECT message but shall instead send a callOfferRequest return result APDU. If, having
retained a network connection in accordance with A.5.2 of annex A and having indicated in the
serviceAvailable invoke APDU that SS-CO is invokable, a FACILITY message is received containing a
callOfferRequest invoke APDU, the Terminating PTNX shall check again whether the called user is
busy, and if so, and if SS-CO is still invokable, shall send a callOfferRequest return result APDU.
On sending a callOfferRequest return result APDU, the Terminating PTNX shall enter state CO-Dest-
Invoked.
NOTE 5
The Terminating PTNX should, by appropriate means, inform the called user that a call is waiting and allow
the user to accept the call or ignore the call.
On entering the state CO-Dest-Invoked, the Terminating PTNX shall either enter protocol control state
Call Received with the consequent sending of an ALERTING message, or shall remain in protocol
control state Incoming Call Proceeding while the call is being offered to the called user. If an
ALERTING message is not sent, the Terminating PTNX shall send a PROGRESS message containing a
Progress indicator information element containing Progress description no. 8 "in-band information or
appropriate pattern now available", if in-band tone or announcement is applied to the incoming B
channel or if Progress description no. 8 has not been sent earlier in the call.
NOTE 6
The Terminating PTNX can apply in-band tone or announcement to the incoming B-channel at this stage.
However, even if no in-band tone or announcement is applied, the Progress description no. 8 is still required
to be sent unless an ALERTING message is sent or Progress indicator no. 8 has been sent earlier in the call
as a means of ensuring that basic call timer T310 is stopped at other PTNXs. If an ALERTING message is
sent, it can contain a Progress indicator information element containing progress description no. 8 to
indicate the presence of in-band tone or announcement.
The return result APDU may be sent in the ALERTING or PROGRESS message. Otherwise it shall be
sent separately in a FACILITY message.
In state CO-Dest-Invoked, if the called user becomes free and alerting commences, the Terminating
PTNX shall send an ALERTING message if an ALERTING message has not been sent earlier or a
NOTIFY message containing notification description value "remoteUserAlerting" if an ALERTING
message has been sent earlier and shall enter state CO-Idle.
In state CO-Dest-Invoked, if the called user accepts the waiting call, the Terminating PTNX shall send a
CONNECT message and shall enter state CO-Idle.
In state CO-Dest-Invoked, if the called user rejects the waiting call, the Terminating PTNX shall send a
DISCONNECT message and shall enter state CO-Idle.
6.6.2.2 Exceptional procedures
On receipt of a SETUP or FACILITY message containing a callOfferRequest invoke APDU, if the
called user is not busy the call shall continue in accordance with ETS 300 172. The Terminating PTNX
shall return a callOfferRequest return error APDU containing error notBusy in the resulting ALERTING
or CONNECT message and shall remain in state CO-Idle.

Page 16
ETS 300 362: November 1994
NOTE 7
If supplementary service Call Waiting has been invoked on the called user, the ALERTING message can also
include a Notification indicator information element containing a notification description value "call is a
waiting call".
On receipt of a SETUP or FACILITY message containing a callOfferRequest invoke APDU, if the
called user is busy but invocation of SS-CO is not possible the call shall be released in accordance with
ETS 300 172 or, if continued retention of the path is required, shall continue in accordance with A.5.2.
The Terminating PTNX shall return a callOfferRequest return error APDU containing an error other
than notBusy in the resulting DISCONNECT or FACILITY message and shall remain in state CO-Idle.
6.6.3 Actions at a Transit PTNX
No special actions are required in support of SS-CO.
6.7 SS-CO impact of interworking with public ISDNs
On a call to a PTN from a public ISDN that does not support an equivalent service, SS-CO will not be
requested.
On a call from a PTN to a public ISDN that does not support an equivalent service, the Outgoing Gateway
PTNX shall behave as specified in sub-clause 6.6.2 for a Terminating PTNX at which conditions for
invocation of SS-CO are not met.
NOTE 8
At the time of publication of this ETS, no equivalent service was specified for public ISDNs.
6.8 SS-CO impact of interworking with non-ISDNs
When interworking with a non-ISDN which does not support an equivalent service, the procedures defined in
sub-clause 6.7 for interworking with a public ISDN that does not support an equivalent service shall apply.
When interworking with a non-ISDN which supports an equivalent service, the two networks may cooperate
in the operation of SS-CO. In this case, either the Originating PTNX functionality or the Terminating PTNX
functionality will be provided in the non-ISDN. The Incoming or Outgoing Gateway PTNX shall provide
conversion between the signalling protocol specified in this ETS and the signalling protocol of the other
network.
6.9 SS-CO parameter values (timers)
Timer T1
Timer T1 shall operate at the Originating PTNX during state CO-Wait-Ack. Its purpose is to protect against
an absence of response to SS-CO invocation.
Timer T1 shall have a value not less than 30 s.

Page 17
ETS 300 362: November 1994
Annex A (normative): Signalling protocol for the support of Path Retention
This annex is applicable to Originating PTNXs that support SS-CO with path retention and to Terminating PTNXs that
support SS-CO. A similar annex will appear in other Standards that make use of the generic mechanism for path
retention.
A.1 Path Retention description
Path retention is a generic mechanism which can be used by supplementary services during call establishment.
Path retention is invoked by the Originating PTNX either for one supplementary service or for several
supplementary services at the same time. Invocation for a particular supplementary service means that the
network connection is to be retained if the Terminating PTNX encounters conditions in which it is appropriate
to invoke that supplementary service. The Originating PTNX is informed of the reason for retaining the
connection so that it can decide (e.g. by consulting the calling user) whether to invoke the supplementary
service. Under some circumstances in which the network connection is retained, more than one of the
supplementary services for which path retention has been invoked may be applicable.
Successive retentions of the network connection by the Terminating PTNX following a single invocation of path
retention by the Originating PTNX are possible as a result of different conditions being encountered at the
Terminating PTNX. When an attempt is made to invoke a supplementary service for which the network
connection has been retained, a further condition can be encountered that can cause the network connection to
be retained again for the same supplementary service or a different supplementary service.
Path retention is specified in terms of a Path Retention entity existing within the Coordination Function at the
Originating PTNX and at the Terminating PTNX.
A.2 Path Retention operational requirements
A.2.1 Requirements on the Originating PTNX
Call establishment procedures for the outgoing side of an inter-PTNX link, 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.
A.2.2 Requirements on the Terminating PTNX
Call establishment procedures for the incoming side of an inter-PTNX link, 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.
A.2.3 Requirements on a Transit PTNX
Call establishment 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 a
Transit PTNX, shall apply.
Page 18
ETS 300 362: November 1994
A.3 Path Retention coding requirements
A.3.1 Operations
The operations pathRetain and serviceAvailable as defined in sub-clause 6.3.1 shall apply. Within the
ARGUMENT of operation pathRetain, the element of type ServiceList may contain bits other than those
named in sub-clause 6.3.1, in order to request path retention for other supplementary services. Within the
ARGUMENT of operation serviceAvailable, the element of type ServiceList may contain bits other than
those named in sub-clause 6.3.1, in order to indicate retention of the network connection for other
supplementary services.
A.3.2 Information elements
APDUs of the operations pathRetain and serviceAvailable shall be coded in the Facility information element
in accordance with ETS 300 239.
When conveying an APDU of operation pathRetain or serviceAvailable, the NFE shall be included. In the
case of an invoke APDU the destinationEntity data element of the NFE shall contain value endPTNX.
When conveying an invoke APDU of operation pathRetain or serviceAvailable, the Interpretation APDU
shall contain value discardAnyUnrecognisedInvokePdu.
A.3.3 Messages
The Facility information element shall be conveyed in the messages as specified in clause 10 of ETS 300 239.
The basic call messages shall be used for call establishment as specified in ETS 300 172.
A.4 Path Retention state definitions
A.4.1 States at the Originating PTNX
The procedures at the Originating PTNX are written in terms of the following conceptual states existing
within the Path Retention entity in that PTNX in association with a particular call.
A.4.1.1 PRTO-Idle
Path Retention is not operating.
A.4.1.2 PRTO-Requested
A pathRetain invoke APDU has been sent and the Originating PTNX is waiting for a serviceAvailable
invoke APDU from the Terminating PTNX.
A.4.1.3 PRTO-Retained
A serviceAvailable invoke APDU has been received and the network connection is retained.
A.4.1.4 PRTO-Invoking
Invocation of a supplementary service is being attempted using a retained network connection.
A.4.2 States at the Terminating PTNX
The procedures at the Terminating PTNX are written in terms of the following conceptual states existing
within the Path Retention entity in that PTNX in association with a particular incoming call.
A.4.2.1 PRTT-Idle
Path Retention is not operating.

Page 19
ETS 300 362: November 1994
A.4.2.2 PRTT-Requested
A pathRetain invoke APDU has been received and the Terminating PTNX is waiting until conditions for
retaining the network connection are encountered.
A.4.2.3 PRTT-Retained
A serviceAvailable invoke APDU has been sent and the network connection is retained.
A.4.2.4 PRTT-Invoking
Invocation of a supplementary service is being attempted using a retained network conne
...