ETSI ETS 300 261 ed.1 (1993-11)

Private Telecommunication Network (PTN); Inter-exchange signalling protocol; Call transfer supplementary service

DE/ECMA-00047

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

General Information

• Status: Published
• Publication Date: 28-Nov-1993
• Technical Committee: Ecma - Standardizing information and communications systems
• Current Stage: 12 - Completion
• Due Date: 19-Nov-1993
• Completion Date: 29-Nov-1993
• Mandate: T-75C.3
• Ref Project: SIST ETS 300 261 E1:2005 - Private Telecommunication Network (PTN); Inter-exchange signalling protocol; Call transfer supplementary service

Standards Content (Sample)

SLOVENSKI STANDARD
01-maj-2005
Zasebno telekomunikacijsko omrežje (PTN) – Medcentralni signalizacijski protokol
- Dopolnilna storitev: predaja klica
Private Telecommunication Network (PTN); Inter-exchange signalling protocol; Call
transfer supplementary service
Ta slovenski standard je istoveten z: ETS 300 261 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 261
TELECOMMUNICATION November 1993
STANDARD
Source: ETSI TC-ECMA Reference: DE/ECMA-00047
ICS: 33.080
PTN, ECMA-178, QSIG-CT
Key words:
Private Telecommunication Network (PTN);
Inter-exchange signalling protocol
Call transfer supplementary service
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 1993. All rights reserved.
New presentation - see History box

Page 2
ETS 300 261:1993
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 261:1993
Table of contents
Foreword 7
1Scope 9
2 Conformance 9
3 References 9
4 Definitions 10
4.1 External definitions 10
4.2 End PTNX 10
4.3 Primary PTNX 10
4.4 Redirection Number 10
4.5 Secondary PTNX 10
4.6 Transferring PTNX 11
5 List of acronyms 11
6 Signalling protocol for the support of SS-CT 11
6.1 SS-CT description 11
6.2 SS-CT operational requirements 11
6.2.1 Provision/Withdrawal 11
6.2.2 Requirements on a Transferring PTNX 11
6.2.3 Requirements on a Primary PTNX 11
6.2.4 Requirements on a Secondary PTNX 11
6.2.5 Requirements on a Transit PTNX 12
6.3 SS-CT coding requirements 12
6.3.1 Operations 12
6.3.2 Information elements 16
6.3.2.1 Facility information element 16
6.3.2.2 Information elements embedded in the Facility information
element 16
6.3.2.3 Other information elements 16
6.3.3 Messages 16
6.4 SS-CT state definitions 17
6.4.1 States at a Transferring PTNX 17
6.4.1.1 CT-Idle 17
6.4.1.2 CT-Await-Answer-From-UserC 17
6.4.1.3 CT-Await-Identify-Response 17
6.4.1.4 CT-Await-Initiate-Response 17
6.4.2 States at a Primary PTNX 17
6.4.2.1 CT-Idle 17
6.4.2.2 CT-Await-Setup-Response 17
6.4.2.3 CT-Await-Connect 17
6.4.3 States at a Secondary PTNX 17
6.4.3.1 CT-Idle 17
6.4.3.2 CT-Await-Setup 17
6.5 SS-CT signalling procedures for invocation and operation 17
6.5.1 Actions at a Transferring PTNX 18
6.5.1.1 Normal procedures for transfer by join 18
6.5.1.2 Exceptional procedures for transfer by join 19
6.5.1.3 Normal procedures for transfer by rerouting 19

Page 4
ETS 300 261:1993
6.5.1.4 Exceptional procedures for transfer by rerouting 19
6.5.2 Actions at a Primary PTNX 20
6.5.2.1 Normal procedures for transfer by join 20
6.5.2.2 Exceptional procedures for transfer by join 20
6.5.2.3 Normal procedures for transfer by rerouting 20
6.5.2.4 Exceptional procedures for transfer by rerouting 21
6.5.3 Actions at a Secondary PTNX 22
6.5.3.1 Normal procedures for transfer by join 22
6.5.3.2 Exceptional procedures for transfer by join 22
6.5.3.3 Normal procedures for transfer by rerouting 22
6.5.3.4 Exceptional procedures for transfer by rerouting 23
6.5.4 Actions at a Transit PTNX 24
6.5.5 Subsequent actions at a Primary and a Secondary PTNX 24
6.6 SS-CT impact of interworking with public ISDNs 24
6.6.1 Actions at a Gateway PTNX 24
6.6.1.1 Impact of interworking if User A is in the PTN 24
6.6.1.2 Impact of interworking if a PTN User is transferred by the
public ISDN 24
6.6.2 Actions at other types of PTNX 25
6.7 SS-CT impact of interworking with non-ISDNs 25
6.7.1 Actions at a Gateway PTNX 25
6.7.1.1 Transfer within the PTN 25
6.7.1.2 Transfer within the non-ISDN 25
6.7.1.3 Co-operation with a non-ISDN in providing transfer by rerouting 26
6.7.2 Actions at other types of PTNX 26
6.8 SS-CT Parameter Values (Timers) 26
6.8.1 Timer T1 26
6.8.2 Timer T2 26
6.8.3 Timer T3 27
6.8.4 Timer T4 27
Annex A (normative): Protocol Implementation Conformance Statement (PICS) proforma 28
A.1 Introduction 28
A.2 Instructions for completing the PICS proforma 28
A.2.1 General structure of the PICS proforma 28
A.2.2 Additional information 29
A.2.3 Exception information 29
A.3 PICS proforma for ETS 300 261 30
A.3.1 Implementation identification 30
A.3.2 Protocol summary 30
A.3.3 General 30
A.3.4 Procedures for SS-CT-Join 31
A.3.5 Additional procedures for SS-CT-Rerouting 32
A.3.6 Coding 33
A.3.7 Timers 33
Annex B (informative): Imported ASN.1 definitions relating to numbers 34
Annex C (informative): Examples of message sequences 37
C.1 Example message sequence for normal operations of call transfer by join, both calls active 38

Page 5
ETS 300 261:1993
C.2 Example message sequence for call transfer by join, one call alerting 39
C.3 Example message sequence for normal operation of call transfer by rerouting 40
C.4 Example message sequence for normal operation of call transfer by rerouting, one call alerting 42
Annex D (informative): Specification and Description Language (SDL): Representation of procedures 44
D.1 SDL Representation of SS-CT at a Transferring PTNX 44
D.2 SDL Representation of SS-CT at a Primary PTNX 47
D.3 SDL Representation of SS-CT at a Secondary PTNX 51
History 53
Page 6
ETS 300 261:1993
Blank page
Page 7
ETS 300 261:1993
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) incorporating one or more interconnected nodes. The series uses the ISDN
concepts as developed by 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 Transfer
supplementary service (CT).
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 261:1993
Blank page
Page 9
ETS 300 261:1993
1Scope
This ETS specifies the signalling protocol for the support of the Call Transfer supplementary service (SS-CT)
at the Q reference point between Private Telecommunication Network Exchanges (PTNXs) connected together
within a Private Telecommunication Network (PTN).
SS-CT is a supplementary service which enables a User to transform two of that User's calls (at least one of
which must be answered) into a new call between the two other users of these two calls.
The Q reference point is defined in ENV 41004.
Service specifications are produced in three stages and according to the method specified in ENV 41005. 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 260.
The signalling protocol for SS-CT 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 Transfer 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 A.
3 References
ENV 41004 Reference configuration for connectivity relations of private telecommunication
network exchanges (1989).
ENV 41005 Method for the specification of basic and supplementary services of private
telecommunication networks (1989).
ENV 41007 Definition of terms in private telecommunication networks (1989).
ETS 300 171 Private Telecommunication Network (PTN); Specification, functional models and
information flows, Control aspects of circuit mode basic services (1992).
ETS 300 172 Private Telecommunication Network (PTN); Inter-exchange signalling protocol,
Circuit mode basic services (1992).
ETS 300 196 ISDN - Generic Functional Protocol for the Support of Supplementary Services -
DSS1 Protocol.
ETS 300 238 Private Telecommunication Network (PTN); Signalling between private
telecommunication exchanges, Protocol for the support of name identification
supplementary services (1993).
ETS 300 239 Private Telecommunication Network (PTN); Signalling between private
telecommunication exchanges, Generic functional protocol for the support of
supplementary services (1993).
ETS 300 260 Private Telecommunication Networks (PTN); Specification, functional models and
information flows, Call transfer supplementary service (1993).

Page 10
ETS 300 261:1993
CCITT Recommendation I.112 Vocabulary of terms for ISDNs (1988).
CCITT Recommendation I.210 Principles of telecommunication services supported by an ISDN and the
means to describe them (1988).
CCITT Recommendation Z.100 Specification and description language (1988).
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:
- Alerting (ETS 300 260);
- Answered (ETS 300 260);
- Application Protocol Data Unit (APDU) (ETS 300 239);
- Basic Service (CCITT Recommendation I.210);
- Gateway PTNX (ETS 300 172);
- Interpretation APDU (ETS 300 239);
- Network Facility Extension (NFE) (ETS 300 239);
- Originating PTNX (ETS 300 239);
- Primary Call (ETS 300 260);
- Private (ENV 41007);
- Private Telecommunication Network Exchange (PTNX) (ENV 41007);
- Public ISDN (ENV 41007);
- Secondary Call (ETS 300 260);
- Signalling (CCITT Recommendation I.112);
- Supplementary Service (CCITT Recommendation I.210);
- Supplementary Service Control Entity (ETS 300 239);
- Telecommunication Network (ENV 41007);
- Terminal (ENV 41007);
- Terminating PTNX (ETS 300 239);
- Transfer by join (ETS 300 260);
- Transfer by rerouting (ETS 300 260);
- Transit PTNX (ETS 300 239);
- User (ETS 300 171);
- User A (ETS 300 260);
- User B (ETS 300 260);
- User C (ETS 300 260).
4.2 End PTNX
Within the context of a call, a PTNX which is not acting as a Transit PTNX, i.e. an Originating PTNX, a
Terminating PTNX, or a Gateway PTNX.
4.3 Primary PTNX
The End PTNX which is on the end of the Primary Call nearest to User B.
4.4 Redirection Number
The number of a transferred User, as provided to the PTNX of the other transferred User.
4.5 Secondary PTNX
The End PTNX which is on the end of the Secondary Call nearest to User C.

Page 11
ETS 300 261:1993
4.6 Transferring PTNX
The End PTNX which initiates the call transfer procedures on behalf of User A.
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-CT Supplementary Service Call Transfer
TE Terminal Equipment
6 Signalling protocol for the support of SS-CT
6.1 SS-CT description
Call Transfer (CT) is a supplementary service which enables a user to transform two of that user's calls (at
least one of which must be answered) into a new call between the two other users in the two calls.
This supplementary service is applicable to basic services defined in ETS 300 171.
Call transfer can be achieved by using one of two methods; transfer by join and transfer by rerouting.
Support of transfer by join is mandatory. Support of transfer by rerouting is an option, which, if not
supported by all PTNXs involved in the operation of call transfer, allows fall back to using transfer by join.
NOTE 1
When an active call has been transferred to an alerting call, the supervision during the alerting phase and
the possible procedures to be followed in case the alerting call remains unanswered are outside the scope of
this ETS.
6.2 SS-CT operational requirements
6.2.1 Provision/Withdrawal
Provision and withdrawal shall be in accordance with 6.2.1 of ETS 300 260.
6.2.2 Requirements on a Transferring PTNX
The basic call procedures specified in ETS 300 172 shall be supported. 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 Primary PTNX
The basic call procedures specified in ETS 300 172 shall be supported.
Generic procedures for the call-related control of supplementary services, as specified in ETS 300 239 for
an End PTNX, shall apply.
6.2.4 Requirements on a Secondary PTNX
The basic call procedures specified in ETS 300 172 shall be supported.
Generic procedures for the call-related control of supplementary services, as specified in ETS 300 239 for
an End PTNX, shall apply.
Page 12
ETS 300 261:1993
6.2.5 Requirements on a Transit PTNX
The basic call procedures specified in ETS 300 172 shall be supported.
Generic procedures for the call-related control of supplementary services, as specified in ETS 300 239 for
a Transit PTNX, shall apply.
For SS-CT 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-CT coding requirements
6.3.1 Operations
The following operations, defined in Abstract Syntax Notation number 1 (ASN.1) in table 1 shall apply.
Table 1 - Operations in support of SS-CT
Call-Transfer-Operations
{ccitt(0) identified-organization(3) etsi(0)
qsig-call-transfer(261) call-transfer-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) }
Name FROM Name-Operations { ccitt(0) identified-organization (3)
etsi(0) qsig-name (238) name-operations (0) }
notAvailable, invalidCallState, supplementaryServiceInteractionNotAllowed,
FROM General-Errors {ccitt(0) identified-organization(3)
etsi (0) 196 general-errors (2)}
PresentedAddressScreened, PresentedNumberScreened, PartyNumber,
PartySubaddress FROM Addressing-Data-Elements { ccitt(0)
identified-organization(3) etsi(0) 196 addressing-data-elements (6)}
-- Note. The definitions of PresentedAddressScreened,
-- PresentedNumberScreened, PartyNumber, and PartySubaddress are
-- reproduced in annex B
QSIGInformationElement FROM Generic-parameters-definition {
ccitt(0) identified-organization(3) etsi(0) qsig-generic-procedures
(239) qsig-generic-parameters (6) };
ptn OBJECTIDENTIFIER ::= {iso(1) identified-organization(3) icd-ecma(0012)
private-isdn-signalling-domain(09)}
CallTransferIdentify ::= OPERATION
ARGUMENT DummyArg
RESULT CTIdentifyRes
ERRORS { notAvailable,
invalidCallState,
supplementaryServiceInteractionNotAllowed,
unspecified}
Page 13
ETS 300 261:1993
CallTransferAbandon ::= OPERATION
ARGUMENT DummyArg
CallTransferInitiate ::= OPERATION
ARGUMENT CTInitiateArg
RESULT DummyRes
ERRORS { notAvailable,
invalidCallState,
invalidReroutingNumber,
unrecognizedCallIdentity,
establishmentFailure,
supplementaryServiceInteractionNotAllowed,
unspecified }
CallTransferSetup ::= OPERATION
ARGUMENT CTSetupArg
RESULT DummyRes
ERRORS { notAvailable,
invalidCallState,
invalidReroutingNumber,
unrecognizedCallIdentity,
unspecified }
CallTransferActive ::= OPERATION
ARGUMENT CTActiveArg
CallTransferComplete ::= OPERATION
ARGUMENT CTCompleteArg
CallTransferUpdate ::= OPERATION
ARGUMENT CTUpdateArg
SubaddressTransfer ::= OPERATION
ARGUMENT SubaddressTransferArg
DummyArg ::= CHOICE {
NULL,
[1] IMPLICIT Extension,
[2] IMPLICIT SEQUENCE OF Extension
}
DummyRes ::= CHOICE {
NULL,
[1] IMPLICIT Extension,
[2] IMPLICIT SEQUENCE OF Extension
}
CTIdentifyRes ::= SEQUENCE {
callIdentity CallIdentity,
reroutingNumber PartyNumber,
resultExtension CHOICE {
[6] IMPLICIT Extension,
[7] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
}
Page 14
ETS 300 261:1993
CTInitiateArg ::= SEQUENCE {
callIdentity CallIdentity,
reroutingNumber PartyNumber,
argumentExtension CHOICE {
[6] IMPLICIT Extension,
[7] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
}
CTSetupArg ::= SEQUENCE {
callIdentity CallIdentity,
argumentExtension CHOICE {
[0] IMPLICIT Extension,
[1] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
}
CTActiveArg ::= SEQUENCE {
connectedAddress PresentedAddressScreened,
basicCallInfoElements QSIGInformationElement OPTIONAL,
-- ETS 300 172 information elements Party category and
-- Progress indicator are conveyed
connectedName Name OPTIONAL,
argumentExtension CHOICE {
[9] IMPLICIT Extension,
[10] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
}
CTCompleteArg ::= SEQUENCE {
endDesignation EndDesignation,
redirectionNumber PresentedNumberScreened,
basicCallInfoElements QSIGInformationElement OPTIONAL,
-- ETS 300 172 information elements Party category and
-- Progress indicator are conveyed
redirectionName Name OPTIONAL,
callStatus CallStatus DEFAULT answered,
argumentExtension CHOICE {
[9] IMPLICIT Extension,
[10] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
}
Page 15
ETS 300 261:1993
CTUpdateArg ::= SEQUENCE {
redirectionNumber PresentedNumberScreened,
redirectionName Name OPTIONAL,
basicCallInfoElements QSIGInformationElement OPTIONAL,
-- ETS 300 172 information elements Party category and
-- Progress indicator are conveyed
argumentExtension CHOICE {
[9] IMPLICIT Extension,
[10] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
}
SubaddressTransferArg ::= SEQUENCE {
redirectionSubaddress PartySubaddress,
argumentExtension CHOICE {
[0] IMPLICIT Extension,
[1] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
}
CallStatus ::= ENUMERATED {
answered(0),
alerting(1) }
CallIdentity ::= NumericString (SIZE (1.4))
EndDesignation ::= ENUMERATED {
primaryEnd(0),
secondaryEnd(1) }
Unspecified ERROR PARAMETER Extension
unspecified Unspecified ::= {ptn 1008}
callTransferIdentify CallTransferIdentify ::= {ptn ct-identify(7) }
callTransferAbandon CallTransferAbandon ::= {ptn ct-abandon(8) }
callTransferInitiative CallTransferInitiative ::= {ptn ct-initiate(9) }
callTransferSetup CallTransferSetup ::= {ptn ct-setup(10) }
callTransferActive CallTransferActive ::= {ptn ct-active(11) }
callTransferComplete CallTransferComplete ::= {ptn ct-complete(12) }
callTransferUpdate CallTransferUpdate ::= {ptn ct-update(13) }
subaddressTransfer SubaddressTransfer ::= {ptn subaddress-transfer(14) }
invalidReroutingNumber ERROR ::= {ptn 1004 }
-- used when establishment of the new connection fails because
-- the reroutingNumber is not a valid PTN address
unrecognizedCallIdentity ERROR ::= {ptn 1005 }
-- used when establishment of the new connection fails because it
-- could not be associated with a SS-CT entity at the Secondary PTNX
establishmentFailure ERROR ::= {ptn 1006 }
-- used when establishment of the new connection fails and
-- no other error applies
END -- of Call-Transfer-Operations

Page 16
ETS 300 261:1993
6.3.2 Information elements
6.3.2.1 Facility information element
APDUs of the operations defined in 6.3.1 shall be coded in the Facility information element in
accordance with ETS 300 239.
When conveying the invoke APDU of the operations defined in 6.3.1, the destinationEntity data
element of the NFE shall contain value endPTNX.
When conveying the invoke APDU of operations callTransferAbandon, callTransferComplete,
callTransferActive, callTransferUpdate or subaddressTransfer, the Interpretation APDU shall contain
value discardAnyUnrecognisedInvokePdu.
When conveying the invoke APDU of operation callTransferSetup, the Interpretation APDU shall
contain value clearCallIfAnyInvokePduNotRecognised.
When conveying the invoke APDU of operation callTransferIdentify or callTransferInitiate, the
Interpretation APDU shall be omitted.
6.3.2.2 Information elements embedded in the Facility information element
APDUs of the operations defined in 6.3.1 may contain information elements defined in and coded
according to ETS 300 172. These shall be embedded in data elements of type QSIGInformationElement
as specified in 11.3.3.4 of ETS 300 239.
In data element basicCallInfoElements, which is of type QSIGInformationElement, the embedded
contents shall be coded as Party category and/or Progress indicator information elements specified in
ETS 300 172.
6.3.2.3 Other information elements
The following information elements used during the establishment of the new connection (transfer by
rerouting) shall be coded as specified in ETS 300 172:
- Bearer capability;
- Called party number;
-Cause;
- Sending complete;
- Transit counter.
6.3.3 Messages
Except for cases where a basic call message is to be conveyed at the same time, the Facility information
element shall be conveyed in a FACILITY message as specified in ETS 300 239.
The following messages used during the establishment of the new connection and release of the old
connections (in case of transfer by rerouting) shall be as specified in ETS 300 172:
- CALL PROCEEDING;
- CONNECT;
- CONNECT ACKNOWLEDGE;
- DISCONNECT;
- PROGRESS;
- RELEASE;
- RELEASE COMPLETE;
- SETUP.
Page 17
ETS 300 261:1993
6.4 SS-CT state definitions
6.4.1 States at a Transferring PTNX
The procedures at the Transferring PTNX are written in terms of the following conceptual states existing
within the SS-CT control entity in that PTNX in association with a particular Call Transfer request from
User A.
6.4.1.1 CT-Idle
SS-CT is not operating.
6.4.1.2 CT-Await-Answer-From-UserC
A callTransferComplete invoke APDU with callStatus having value alerting has been sent to the
Primary PTNX. This state may be used during transfer by join.
6.4.1.3 CT-Await-Identify-Response
A callTransferIdentify invoke APDU has been sent to the Secondary PTNX. This state is used during
transfer by rerouting.
6.4.1.4 CT-Await-Initiate-Response
A callTransferInitiate invoke APDU has been sent to the Primary PTNX. This state is used during
transfer by rerouting.
6.4.2 States at a Primary PTNX
The procedures at the Primary PTNX are written in terms of the following conceptual states existing
within the SS-CT control entity in that PTNX in association with the primary call, i.e. a particular call of
User B.
6.4.2.1 CT-Idle
SS-CT is not operating.
6.4.2.2 CT-Await-Setup-Response
A callTransferSetup invoke APDU has been sent to the Secondary PTNX. This state is used during
transfer by rerouting.
6.4.2.3 CT-Await-Connect
The primary call has been transferred to an alerting secondary User, and the primary User has been
notified. A CONNECT message indicating answering by the secondary User is awaited.
6.4.3 States at a Secondary PTNX
The procedures at the Secondary PTNX are written in terms of the following conceptual states existing
within the SS-CT control entity in that PTNX in association with a particular call of User C.
6.4.3.1 CT-Idle
SS-CT is not operating.
6.4.3.2 CT-Await-Setup
A callTransferIdentify return result APDU has been sent to the Transferring PTNX. This state is used
during transfer by rerouting.
6.5 SS-CT signalling procedures for invocation and operation
References in this clause to protocol control states refer to basic call protocol control states defined in ETS
300 172.
Page 18
ETS 300 261:1993
NOTE 2
The specification in this section is based on each of the End PTNXs being a different PTNX, but this section
is also applicable to scenarios where two of the three PTNXs are the same. In those scenarios some of the
signalling procedures and message flows described in this section are internal to the PTNX implementation
and therefore outside the scope of this ETS.
Annex C contains some examples of message sequences.
6.5.1 Actions at a Transferring PTNX
Call Transfer procedures shall be initiated on a request from User A specifying the two calls in which
User A is involved to be acted upon. The Transferring PTNX shall check that one of the two calls is in
protocol control state Active and is therefore a valid primary call, and that the other call is in protocol
control state Active or Call Delivered and is therefore a secondary call.
If User C is a User in a non-ISDN, additional states are valid for the secondary call as specified in 6.7.2.
NOTE 3
Additional checks carried out by the Transferring PTNX, e.g. to satisfy the requirements of ETS 300 260,
are outside the scope of this ETS.
NOTE 4
The SDL representation of procedures at a Transferring PTNX is shown in D.1 of annex D.
After validation of the request for call transfer, the Transferring PTNX shall determine which variant of
call transfer is to be attempted: join or rerouting.
NOTE 5
This depends on the capabilities of the Transferring PTNX, the known network topology, and on the
known capabilities of the Primary and Secondary PTNXs in the current call contexts.
If call transfer by rerouting procedures are to be attempted 6.5.1.3 and 6.5.1.4 shall apply, otherwise call
transfer by join procedures specified in 6.5.1.1 and 6.5.1.2 shall apply.
On successful completion of call transfer (either by join or by rerouting), the Transferring PTNX shall
release User A from the two calls and, depending on the procedures at the access, indicate acceptance to
User A.
On failure of call transfer, e.g. because of an invalid request or because of failure of transfer by rerouting,
the Transferring PTNX shall either retain the two calls at User A and indicate rejection to User A or take
implementation dependent action if the calls have been released already from User A.
6.5.1.1 Normal procedures for transfer by join
The Transferring PTNX shall join the B-channels of the primary and secondary calls and send a
callTransferComplete invoke APDU in a FACILITY message to both the Primary and Secondary PTNX
using the call references of the primary and secondary call respectively. Within the argument,
endDesignation shall be included to give a distinctive designation to each end of the new call. If the
secondary call was not in protocol control state Active when transferred, the Transferring PTNX shall
include callStatus with value alerting in the argument of the invoke sent to the Primary PTNX. In
addition other information may be indicated if available: redirectionNumber and redirectionName to
identify the other User in the transferred call, and basicCallInfoElements carrying the category of the
redirected User and/or progress indications encountered during setup of the other call.
If the secondary call is not in protocol control state Active at the time of initiation of the transfer, the
Transferring PTNX shall enter state CT-Await-Answer-From-UserC in which it shall continue to
intercept the signalling connections associated with the former primary and secondary calls.

Page 19
ETS 300 261:1993
In state CT-Await-Answer-From-UserC the Transferring PTNX shall convey all received
callTransferUpdate and subaddressTransfer invoke APDUs from the Primary PTNX to the Secondary
PTNX and vice-versa. On receipt in state CT-Await-Answer-From-UserC of any ETS 300 172 message
from the Primary PTNX or Secondary PTNX, other than a CONNECT message received from the
Secondary PTNX, the Transferring PTNX shall act as a Transit PTNX.
If both the primary and secondary call are in protocol control state Active, the Transferring PTNX shall
associate the two connections after having sent the two callTransferComplete invoke APDUs, start to
act as a Transit PTNX for the resulting call from this point onwards, and enter state CT-Idle.
On receipt of a CONNECT message on the call reference of the secondary call while in state CT-Await-
Answer-From-UserC the Transferring PTNX shall send a FACILITY message with a callTransferActive
invoke APDU on the call reference of the primary call. Element basicCallInfoElements may be
included. Additionally, if the CONNECT message contained a Facility information element with a
connectedName invoke APDU, as defined in ETS 300 238, the Transferring PTNX may include the
information therein in element connectedName in the callTransferActive invoke APDU instead of
relaying the connectedName as a separate invoke APDU. The Transferring PTNX shall associate the
two connections, begin to act as a Transit PTNX for the resultant call, and enter state CT-idle.
6.5.1.2 Exceptional procedures for transfer by join
Not applicable.
6.5.1.3 Normal procedures for transfer by rerouting
In order to start transfer by rerouting, the Transferring PTNX shall send a callTransferIdentify invoke
APDU in a FACILITY message to the Secondary PTNX using the call reference of the secondary call,
start timer T1, and enter state CT-Await-Identify-Response.
On receipt in state CT-Await-Identify-Response of a FACILITY message with a callTransferIdentify
return result APDU on the call reference of the secondary call, the Transferring PTNX shall send a
callTransferInitiate invoke APDU in a FACILITY message to the Primary PTNX using the call
reference of the primary call, stop timer T1, and start timer T3. The callIdentity and reroutingNumber
information received within the result of the callTransferIdentify return result APDU shall be relayed
within the argument of the callTransferInitiate invoke APDU. State CT-Await-Initiate-Response shall
be entered.
On receipt in state CT-Await-Initiate-Response of a DISCONNECT message with a callTransferInitiate
return result APDU using the call reference of the primary call, the Transferring PTNX shall continue
call clearing of the primary call according to basic call procedures, initiate call clearing of the
secondary call according to basic call procedures if this has not been cleared yet, stop timer T3,
indicate successful completion of call transfer to User A, and enter State CT-Idle.
Upon receiving in state CT-Await-Identify-Response or CT-Await-Initiate-Response of an indication
from basic call control that the primary and/or secondary call has been cleared, the Transferring PTNX
shall initiate clearing of the other call if this has not been cleared yet, indicate successful completion of
call transfer to User A, and enter state CT-Idle.
6.5.1.4 Exceptional procedures for transfer by rerouting
On receipt in state CT-Await-Identify-Response of a FACILITY message with a callTransferIdentify
reject or return error APDU on the call reference of the secondary call, the Transferring PTNX shall
stop timer T1, abort the procedure for transfer by rerouting, and, depending on the error cause, call
transfer may be reinitiated using transfer by join procedures as specified in 6.5.1.1 and 6.5.1.2.
On expiry of timer T1, the Transferring PTNX shall send a callTransferAbandon invoke APDU on the
call reference of the secondary call, abort the procedure for transfer by rerouting, and reinitiate call
transfer using transfer by join procedures as specified in 6.5.1.1 and 6.5.1.2.

Page 20
ETS 300 261:1993
On receipt in state CT-Await-Initiate-Response of a FACILITY message using the call reference of the
primary call, and conveying a callTransferInitiate reject or return error APDU, the Transferring PTNX
shall send a callTransferAbandon invoke APDU in a FACILITY message using the call reference of the
secondary call if this has not been cleared yet, stop timer T3, abort the procedure for transfer by
rerouting, and, depending on the error cause, call transfer may be reinitiated using transfer by join
procedures as specified in 6.5.1.1 and 6.5.1.2.
On expiry of timer T3, the Transferring PTNX shall send a callTransferAbandon invoke APDU on the
call reference of the secondary call if this has not been cleared yet by the Secondary PTNX, and abort
the procedure for transfer by rerouting. If possible, call transfer shall be reinitiated using transfer by
join procedures as specified in 6.5.1.1 and 6.5.1.2, or else state CT-Idle shall be entered.
6.5.2 Actions at a Primary PTNX
A PTNX shall treat as valid an APDU indicating that it is the Primary PTNX for SS-CT only if the
protocol control state is Active.
NOTE 6
The SDL representation of procedures at a Primary PTNX is shown in D.2 of annex D.
6.5.2.1 Normal procedures for transfer by join
On receipt of a FACILITY message containing a callTransferComplete invoke APDU while meeting
the conditions listed in 6.5.2, the Primary PTNX shall proceed as follows. The presence of element
endDesignation with value 'primaryEnd' signifies that the PTNX shall operate as a Primary PTNX.
Optionally it may send a callTransferUpdate invoke APDU in a FACILITY message using the call
reference on which the callTransferComplete invoke was received. Within the argument, optional data
elements redirectionNumber, redirectionName, and basicCallInfoElements containing information
relating to User B may be conveyed. The Primary PTNX may record details of the transfer, notify User
B if this is able to receive a notification, and provide other details received in the invoke to User B as
appropriate. A number or name marked as restricted shall not be passed on to the transferred user. The
Primary PTNX may solicit a subaddress for sending to User C. The Primary PTNX shall remain in state
CT-Idle.
Additional procedures valid for state CT-Idle are specified in 6.5.5.
6.5.2.2 Exceptional procedures for transfer by join
Not applicable.
6.5.2.3 Normal procedures for transfer by rerouting
On receipt in state CT-Idle of a FACILITY message containing a callTransferInitiate invoke APDU
while in protocol control state Active, the Primary PTNX shall determine whether it can participate in
the transfer. If so, it shall attempt to establish a new connection by selecting an outgoing B-channel on
a route determined by the contents of reroutingNumber received within the argument of
callTransferInitiate. If a B-channel is available, a SETUP message shall be sent using a new call
reference in accordance with the procedures of ETS 300 172. The SETUP message shall contain the
following information elements:
- Bearer capability, containing the bearer capability information of the original call;
- Called party number, containing the number received in
reroutingNumber within the received argument;
- Facility;
- Sending complete;
- Transit counter, with value zero (optional);

Page 21
ETS 300 261:1993
The SETUP message shall contain a Facility information element conveying a callTransferSetup invoke
APDU, with callIdentity within the argument having the same value as callIdentity in the argument that
was received within the callTransferInitiate invoke. The SETUP message may also contain a
callTransferUpdate invoke APDU, with in the argument, optional elements redirectionNumber,
redirectionName and basicCallInfoElements. Optionally, timer T4 may be started.
State CT-Await-Setup-Response shall be entered.
The protocol procedures of ETS 300 172 shall apply during the establishment of the new connection.
NOTE 7
Initially protocol control will enter state Call Initiated. On receipt of a CALL PROCEEDING message,
state Outgoing Call Proceeding will be entered, on receipt of ALERTING, state Alerting will be entered
and on receipt of CONNECT, state Active will be entered.
On receipt in state CT-Await-Setup-Response of a CONNECT message (using the call reference of the
new connection) containing a callTransferSetup return result APDU, the Primary PTNX shall
disconnect the B-channel of the old connection and connect User B to the B-channel of the new
connection. Timer T4 shall be stopped if running. The Primary PTNX may record details of the transfer
and notify User B if this is able to receive a notification. The Primary PTNX may solicit a subaddress
for sending to User C. If the CONNECT message also contains a callTransferUpdate invoke APDU
with, in the argument, optional elements redirectionNumber, redirectionName and/or
basicCallInfoElements the information contained therein may be conveyed to User B. A number or
name marked as restricted shall not be passed on to the transferred User. A DISCONNECT message
containing a callTransferInitiate return result APDU shall be sent on the call reference of the old
connection to the Transferring PTNX. Completion of the release of the old connection shall be in
accordance with the protocol procedures of ETS 300 172. State CT-Idle shall be entered.
On receipt in state CT-Await-Setup-Response of an ALERTING message (using the call reference of
the new connection) containing a callTransferSetup return result APDU, the Primary PTNX shall
proceed according to the procedures specified in the paragraph above with the following modification.
Instead of CT-Idle, state CT-Await-Connect shall be entered.
On receipt in state CT-Await-Connect of a CONNECT message on the call reference of the re-routed
call, indicating call acceptance by User C, the Primary PTNX may notify User B, providing details as
appropriate, subject to presentation restrictions, and shall enter state CT-Idle.
Additional procedures valid for state CT-Idle are specified in 6.5.5.
6.5.2.4 Exceptional procedures for transfer by rerouting
If on receipt in state CT-Idle of a FACILITY message containing a callTransferInitiate invoke APDU,
the Primary PTNX is not able to participate, a callTransferInitiate return error APDU containing an
appropriate error shall be sent in a FACILITY message on the call reference on which the invoke was
received.
On expiry of timer T4, or on receipt in state CT-Await-Setup-Response of a call clearing message on
the call reference of the new connection, possibly containing a callTransferSetup return error APDU or
reject APDU, the Primary PTNX shall proceed with call clearing of the new connection in accordance
with the procedures of ETS 300 172, and send a FACILITY message on the call reference of the
primary call. A callTransferInitiate return error APDU shall be conveyed in the FACILITY message,
indicating either error value establishmentFailure, or if a callTransferSetup return error has been
received, the error value indicated therein.

Page 22
ETS 300 261:1993
On detection in state CT-Await-Setup-Response of call clearing by User B, or on receipt of a call
clearing message on the call reference of the Primary call, the Primary PTNX shall proceed with
clearing of the primary call in accordance with the procedures of ETS 300 172, and initiate call clearing
of the new connection using the procedures of ETS 300 172.
On detection in state CT-Await-Connect of call clearing of the re-routed connection, either by User B
or due to reception of a call clearing message using the call reference of the re-routed connection, the
Primary PTNX shall proceed with clearing of the re-routed connection in accordance with the
procedures of ETS 300 172.
In all of the above cases timer T4 shall be stopped if running and state CT-Idle shall be entered.
6.5.3 Actions at a Secondary PTNX
A PTNX shall treat as valid an APDU indicating that it is the Secondary PTNX for SS-CT only if the
protocol control state is Active or Call Received, or if specific conditions applicable to interworking
situations as defined in 6.7.1.1 are met.
NOTE 8
The SDL representation of procedures at a Secondary PTNX is shown in D.3 of annex D.
6.5.3.1 Normal procedures for transfer by join
On receipt in state CT-Idle of a FACILITY message containing a callTransferComplete invoke APDU
while meeting the conditions listed in 6.5.3, the Secondary PTNX shall proceed as follows. The
presence of element endDesignation with value 'secondaryEnd' signifies that the PTNX shall operate as
a Secondary PTNX. Optionally it may send a callTransferUpdate invoke APDU in a FACILITY
message to the Primary PTNX using the call reference on which the callTransferComplete invoke was
received. Within the argument, optional data elements redirectionNumber, redirectionName, and
basicCallInfoElements containing information relating to User C may be conveyed. The Secondary
PTNX may record details of the transfer and may notify User C if this is able to receive this
information. If the protocol control state of the secondary call is Active, the Secondary PTNX may
solicit a subaddress for sending to User B. The Secondary PTNX shall remain in state CT-Idle.
NOTE 9
On detection of answer by User C, a CONNECT message is sent to the Transferring PTNX in
accordance with the procedures of ETS 300 172, using the call reference of the secondary call.
Additional procedures valid for state CT-Idle are specified in 6.5.5.
6.5.3.2 Exceptional procedures for transfer by join
Not applicable.
6.5.3.3 Normal procedures for transfer by rerouting
On receipt in state CT-Idle of a FACILITY message containing a callTransferIdentify invoke APDU
under the conditions listed in 6.5.3, the Secondary PTNX shall determine whether it can proceed with
SS-CT by rerouting. If so, it shall send a callTransferIdentify return result APDU in a FACILITY
message using the call reference on which the invoke APDU was received, start timer T2, and enter
state CT-Await-Setup. Within the argument, callIdentity and reroutingNumber shall be included.
Element reroutingNumber shall contain a number which, when used as the contents of the information
element Called party number in a SETUP message, is sufficient to cause routing to the Secondary
PTNX. Element callIdentity shall be a number which, possibly in conjunction with reroutingNumber,
identifies the call on which SS-CT is being invoked. Element callIdentity need not have significance
outside the Secondary PTNX.
Page 23
ETS 300 261:1993
Having agreed the B-channel and sent back a CALL PROCEEDING message in response to an
incoming SETUP message, in accordance with the procedures of ETS 300 172, if the SETUP contains a
callTransferSetup invoke APDU, the Secondary PTNX shall proceed as follows. If the callIden
...