SIST EN 300 368 V1.2.2:2005

• Abstract:

  To reflect changes in service description and in DSS1 protocol: 1) Remove requirement for one call to be placed on hold. TD16 to SPS1 Prague (03/98) refers and gives proposed changes; 2) Reflect changes in Q.82.7. Unnumbered TD to Prague refers. Supporting organizations: SGCS Ltd., GTP Ltd., KPN, BT.

• Status: Published
• Publication Date: 31-Mar-2005
• ICS: 33.080 - Integrated Services Digital Network (ISDN)
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Apr-2005
• Due Date: 01-Apr-2005
• Completion Date: 01-Apr-2005
• Ref Project: ETSI EN 300 368 V1.2.2 (1998-12) - Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT) supplementary service; Functional capabilities and information flows

SIST EN 300 368 V1.2.2:2005 is the Slovenian adoption of EN 300 368 V1.2.2 from ETSI. It specifies the stage 2 functional capabilities and information flows for the Integrated Services Digital Network (ISDN) Explicit Call Transfer (ECT) supplementary service. In practice, it shows how an ECT-capable network or terminal should model the transfer of two calls between user A, user B and user C.

What does SIST EN 300 368 V1.2.2:2005 specify?

SIST EN 300 368 V1.2.2:2005 specifies the stage two description of ECT for pan-European ISDN public telecommunications operators. It sets out the functional capabilities, the information flows, and the functional model needed to support transfer by join.

The document is organized into clauses on scope, normative references, definitions, abbreviations, service description, functional model derivation, information flows, SDL diagrams, Functional Entity Actions, and allocation of Functional Entities (FEs) to physical locations. Clauses 5 to 10 carry the main technical content.

The scope is focused on stage 2 behavior for public ISDN use. It keeps private-ISDN allocation rules and non-ISDN delivery requirements outside the stage 2 description, while still noting where private-network interworking can affect the functional model.

What are the key requirements of SIST EN 300 368 V1.2.2:2005?

The standard is built around a stage 2 service model, a set of information flows, and six FEs that describe how ECT is handled. For implementers, the important point is that the document is not just a service description - it maps the service into call-state checks, message content, and entity actions.

Service behavior and call conditions

Clause 5 limits this stage 2 description to transfer by join. The functional model also allows for interworking with transfer by rerouteing, which matters when private network behavior touches public-network users.

Clause 5 and Table 1 define the call-state combinations for invoking ECT. The primary call and secondary call have to be in one of the listed states, such as active, held, idle, or alerting, depending on whether the calls are incoming or outgoing. In practice, this tells a designer when transfer is allowed to begin.

Clause 5 also restricts the procedures to basic telecommunication services using a single 64 kbit/s connection. That matters because the document is not written for video telephony with two 64 kbit/s connections.

Information flows and what they carry

Clause 7 defines the main information flows used in the service. TRANSFER INVOKE starts or requests the transfer and carries the identities of the calls involving user B and user C. TRANSFER COMPLETE reports that the transfer has been effected, and it may carry the transferred number, transferred subaddress, and alerting indication depending on the case.

Clause 7 also defines TRANSFER ACTIVE, which is used only when an alerting transfer is answered later. This is the point where the network informs the other side that the call has become active after alerting.

TRANSFER INFORM tells the user that a call transfer has completed and identifies the other user involved. TERMINAL DETAILS carries transferred subaddress information when that information is relevant. In practice, these flows show what information may be passed to the user and when identity or subaddress data may appear.

Clause 7 includes LOOP TEST and LOOP TEST REJECT as optional loop-prevention related flows. When loop-prevention procedures are provided, these messages are used to test and reject a possible loop before the transfer proceeds.

Functional Entities and implementation checks

Clause 6 breaks the service into six Functional Entities: FE1 to FE6. FE1 receives the transfer request from the user and can do local checks before asking FE2 to execute the transfer. FE2 checks whether the transfer is valid for the two calls and whether conditions such as call state, supplementary service interactions, conference control, and closed user group restrictions allow it.

FE3 identifies the primary and secondary calls, joins the call paths between user B and user C, and clears the paths to user A. It also sends completion indications to the other exchanges and can trigger the optional loop-test procedure. That makes FE3 the point where the actual connection change happens.

FE4, FE5 and FE6 handle the reporting side of the service. FE4 and FE5 pass on completion or active indications, store relevant network details, and may relay terminal-specific details if information transfer is allowed. FE6 informs the local user of the transfer or the later answer and handles any subaddress information.

Physical allocation scenarios

Clause 10 lists 12 scenarios for allocating the FEs to physical locations. The scenarios cover cases where the entities sit in A’s Terminal Equipment (TE), A’s Local Exchange (LE), A’s Private Telecommunication Network eXchange (PTNX), B’s LE, B’s PTNX, or B’s TE.

This matters for implementation planning because the same service can be realized in different network placements. Note 1 allows FE4 to be placed in the gateway of user A’s network, and Note 2 says FE2 and FE3 shall exist in adjacent basic call Call Control (CC) entities in that scenario.

What terms does SIST EN 300 368 V1.2.2:2005 define?

• Integrated Services Digital Network (ISDN) - The digital network context in which the ECT supplementary service is defined.
• Explicit Call Transfer (ECT) - A supplementary service that connects the other users of two calls together.
• Primary call - One of user A’s answered calls.
• Secondary call - The other call of user A, which may be answered or alerting.
• Transfer by join - The transfer method where the local exchange joins the two calls together.
• Transfer by rerouteing - The transfer method where a new connection replaces the two original calls.
• Functional Entity (FE) - A functional block used in the service model, such as FE1 through FE6.
• Functional Entity Action (FEA) - A numbered action that describes what each FE does in the service flow.
• Call Control Agent (CCA) - The call-control role referenced in the basic call model.
• Private Telecommunication Network eXchange (PTNX) - The private-network exchange used in the allocation scenarios.

Who uses SIST EN 300 368 V1.2.2:2005?

SIST EN 300 368 V1.2.2:2005 is used by ETSI-style telecom engineers, switch and protocol implementers, and network architects who need to build or analyze ECT behavior. It is also relevant to operators and integrators that need to place the functional entities across public networks, private networks, or gateways.

Quality and procurement teams can use it to check whether an ISDN product supports the stage 2 ECT behavior described here. In practice, it helps them compare products by call-state handling, message content, and entity placement.

What changed in SIST EN 300 368 V1.2.2:2005 from the previous edition?

This edition reflects changes in the service description and in the DSS1 protocol. The scope says the update removes the requirement for one call to be placed on hold and reflects changes in Q.82.7.

The document history shows publication steps from V1.1.1 to V1.2.1 and then V1.2.2. For readers, the important point is that this version is a later publication of the same ECT stage 2 model with the stated service and protocol updates.

Which standards are used with SIST EN 300 368 V1.2.2:2005?

• ITU-T Recommendation I.112 - Provides ISDN vocabulary and the base definitions used for terms such as ISDN and service.
• CCITT Recommendation I.130 - Gives the three-stage method used to describe telecommunication services and network capabilities.
• ITU-T Recommendation Q.65 - Provides the unified functional methodology used for the stage 2 characterization.
• ITU-T Recommendation Q.71 - Supplies the circuit mode switched bearer services model and the basic call context.
• CCITT Recommendation Z.100 - Provides the Specification and Description Language (SDL) used for the functional diagrams.
• EN 300 367 - Gives the stage 1 service description for ECT.
• EN 300 369-1 - Gives the stage 3 Digital Subscriber Signalling System No. one (DSS1) protocol specification for ECT.

What does the SIST EN 300 368 V1.2.2:2005 document contain?

The document contains a functional model, a basic-call relationship diagram, and a set of information-flow diagrams that show successful transfer and loop-test handling. It also includes SDL diagrams for FE1 to FE6 and the corresponding Functional Entity Actions that explain each step in plain procedural terms.

Tables 1 to 12 carry the key structured data. They cover invocation states, message contents for TRANSFER INVOKE, TRANSFER COMPLETE, TRANSFER ACTIVE, TERMINAL DETAILS, TRANSFER INFORM, LOOP TEST REJECT, and the allocation of FEs to physical locations.

For implementation work, the most useful parts are the flow definitions and the FEA lists in clauses 7 to 10. They show what each entity sends, receives, stores, relays, or cancels, which is the practical basis for design, integration, and protocol mapping.

SLOVENSKI STANDARD
01-april-2005
Digitalno omrežje z integriranimi storitvami (ISDN) - Dopolnilna storitev:
nedvoumna predaja klica (ECT) - Funkcijske zmožnosti in informacijski tokovi
Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT) supplementary
service; Functional capabilities and information flows
Ta slovenski standard je istoveten z: EN 300 368 Version 1.2.2
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 300 368 V1.2.2 (1998-12)
European Standard (Telecommunications series)
Integrated Services Digital Network (ISDN);
Explicit Call Transfer (ECT) supplementary service;
Functional capabilities and information flows

2 EN 300 368 V1.2.2 (1998-12)
Reference
REN/SPS-01060 (3eo00ipc.PDF)
Keywords
ISDN, supplementary service, ECT, ISUP,
stage 2
ETSI
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: [phone]  Fax: [phone]
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
[e-mail]
Individual copies of this ETSI deliverable
can be downloaded from
http://www.etsi.org
If you find errors in the present document, send your
[e-mail]
comment to:
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 1998.
All rights reserved.
ETSI
3 EN 300 368 V1.2.2 (1998-12)
Contents
Intellectual Property Rights. 5
Foreword. 5
1 Scope . 6
2 Normative references. 6
3 Definitions. 7
4 Abbreviations.7
5 Description . 8
6 Derivation of the functional model. 8
6.1 Functional model description.8
6.2 Description of the FEs .8
6.3 Relationship with a basic service .9
7 Information flows. 9
7.1 Information flow diagrams.9
7.2 Definition of the individual information flows.12
7.2.1 Relationship rq.12
7.2.1A Contents of TRANSFER INVOKE.12
7.2.2 Relationship rr.12
7.2.2A Contents of TRANSFER INVOKE.12
7.2.3 Relationship rs1 .13
7.2.3.1 Contents of TRANSFER COMPLETE .13
7.2.3.2 Contents of TRANSFER ACTIVE.13
7.2.3.3 Contents of LOOP TEST .13
7.2.3.4 Contents of LOOP TEST REJECT .13
7.2.4 Relationship rs2 .13
7.2.4.1 Contents of TRANSFER COMPLETE .13
7.2.4.2 Contents of TRANSFER ACTIVE.14
7.2.4.3 Contents of TERMINAL DETAILS.14
7.2.4.4 Contents of LOOP TEST .14
7.2.4.5 Contents of LOOP TEST REJECT .14
7.2.5 Relationship rt.14
7.2.5.1 Contents of TRANSFER INFORM.14
7.2.5.2 Contents of TERMINAL DETAILS.15
7.2.6 Relationship ru .15
7.2.6A Contents of TERMINAL DETAILS.15
8 SDL diagrams for FEs. 16
8.1 FE1 .16
8.2 FE2 .18
8.3 FE3 .19
8.4 FE4 .23
8.5 FE5 .26
8.6 FE6 .29
9 Functional Entity Actions (FEAs) . 30
9.1 FEAs of FE1 .30
9.2 FEAs of FE2 .30
9.3 FEAs of FE3 .30
9.4 FEAs of FE4 .31
9.5 FEAs of FE5 .31
9.6 FEAs of FE6 .32
ETSI
4 EN 300 368 V1.2.2 (1998-12)
10 Allocation of FEs to physical locations . 32
History. 34
ETSI
5 EN 300 368 V1.2.2 (1998-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in
SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can
be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) which
are, or may be, or may become, essential to the present document.
Foreword
This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Signalling
Protocols and Switching (SPS).
In accordance with CCITT Recommendation I.130, the following three level structure is used to describe the
supplementary telecommunication services as provided by European public telecommunications operators under the
pan-European Integrated Services Digital Network (ISDN):
- Stage 1: is an overall service description, from the user's standpoint;
- Stage 2: identifies the functional capabilities and information flows needed to support the service described in
stage 1; and
- Stage 3: defines the signalling system protocols and switching functions needed to implement the service described
in stage 1.
The present document details the stage 2 aspects (functional capabilities and information flows) needed to support the
Explicit Call Transfer (ECT) supplementary service. The stage 1 and stage 3 aspects are detailed in EN 300 367 [6] and
EN 300 369-1 [7], respectively.
National transposition dates
Date of adoption of this EN: 11 December 1998
Date of latest announcement of this EN (doa): 31 March 1999
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 30 September 1999
Date of withdrawal of any conflicting National Standard (dow): 30 September 1999
ETSI
6 EN 300 368 V1.2.2 (1998-12)
1 Scope
The present document defines the stage two description of the Explicit Call Transfer (ECT) supplementary service for the
pan-European Integrated Services Digital Network (ISDN) as provided by European public telecommunications
operators. Stage two identifies the functional capabilities and the information flows needed to support the service
description as described in stage one. The stage two description also identifies user operations not directly associated
with a call (see CCITT Recommendation 1.130 [2]).
The present document is specified according to the methodology specified in CCITT Recommendation Q.65 [3].
The present document does not formally describe the relationship between this supplementary service and the basic call,
but where possible this information is included for guidance.
In addition the present document does not specify the requirements where the service is provided to the user via a private
ISDN. The present document does not specify the requirements for the allocation of defined Functional Entities (FEs)
within a private ISDN; it does, however, define which functional entities may be allocated to a private ISDN.
The present document does not specify the additional requirements where the service is provided to the user via a
telecommunications network that is not an ISDN.
The ECT supplementary service enables a user who has two calls, each of which can be an incoming or an outgoing call,
to connect the other users in the two calls.
The ECT supplementary service is applicable to all circuit-switched telecommunication services.
The present document is applicable to the stage three standards for the ISDN ECT supplementary service. The term "stage
three" is also defined in CCITT Recommendation 1.130 [2]. Where the text indicates the status of a requirement, i.e. as
strict command or prohibition, as authorization leaving freedom, as a capability or possibility, this shall be reflected in
the text of the relevant stage two and stage three standards.
Furthermore, conformance to the present document is met by conforming to the stage three standards with the field of
application appropriate to the equipment being implemented. Therefore, no method of testing is provided for the present
document.
2 Normative references
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, subsequent revisions do apply.
• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
number.
[1] ITU-T Recommendation I.112 (1993): "Vocabulary of terms for ISDNs".
[2] CCITT Recommendation I.130 (1988): "Method for the characterization of telecommunication
services supported by an ISDN and network capabilities of an ISDN".
[3] ITU-T Recommendation Q.65 (06/97): "The unified functional methodology for the characterization
of services and network capabilities".
[4] ITU-T Recommendation Q.71 (03/93): "ISDN Circuit mode switched bearer services".
[5] CCITT Recommendation Z.100 (1988): "Specification and Description Language (SDL)".
ETSI
7 EN 300 368 V1.2.2 (1998-12)
[6] EN 300 367: "Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT)
supplementary service; Service description".
[7] EN 300 369-1: Integrated Services Digital Network (ISDN); Explicit Call Transfer (ECT)
supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1:
Protocol specification".
3 Definitions
For the purposes of the present document, the following definitions apply:
Integrated Services Digital Network (ISDN): See ITU-T Recommendation I.112 [1], definition 308.
primary call: One of user A's (answered) calls.
secondary call: The other user A call (answered or alerting).
service; telecommunication service: See ITU-T Recommendation I.112 [1], definition 201.
transfer by join: The effecting of transfer by joining together the primary and secondary calls at user A's local exchange.
transfer by rerouteing: The effecting of transfer by establishing a new connection to replace the primary and secondary
calls.
user A: The served user, i.e. the user requesting the ECT supplementary service.
user B: The other user in user A's primary call.
user C: The other user in user A's secondary call.
4 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CC Call Control
CCA Call Control Agent
ECT Explicit Call Transfer
FE Functional Entity
FEA Functional Entity Action
ISDN Integrated Services Digital Network
LE Local Exchange
PTNX Private Telecommunication Network eXchange
SDL Specification and Description Language
TE Terminal Equipment
ETSI
8 EN 300 368 V1.2.2 (1998-12)
5 Description
This stage two supports only one variant of the ECT supplementary service, that of transfer by join. The functional model
supports interworking with transfer by rerouteing, which may occur within a private network but involving users of a
public network.
Table 1 shows the states for the invocation of the ECT supplementary service.
Table 1: States for invocation of ECT
Secondary call Primary call
Active, held Active, idle
Active, held Alerting, idle (note)
Active, idle Alerting, held (note)
Active, idle Active, idle
Active, idle Alerting, idle (note)
NOTE: Only applicable for an outgoing call.
The procedures are currently restricted to basic telecommunication services involving a single 64 kbit/s connection. The
present document is not applicable to a video telephony call involving two 64 kbit/s connections.
6 Derivation of the functional model
6.1 Functional model description
The functional model for the ECT supplementary service is shown in figure 1.
XVHU%
UV¸¶¶¶¹UV¸¶¶¶¹UW¸¶¶¶¹
¸¶¶¶¶¶½)(¼¶¶¶¶¶¶¶¶½)(¼¶¶¶¶¶¶¶¶½)(·
·º¶¾¶»º¶¶¶»º¶¾¶»
XVHU$··UX·
¸¶¶¶¹UT¸¶¶¶¹UU¸¶¶¿¹¸À¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
·)(¼¶¶¶¶¶¶½)(¼¶¶¶¶¶¶½)(···
º¶¶¶»º¶¶¶»º¶¶¾»·º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¹
··UX·
·¸¿¶¶¹¸¶¶¶¹¸¶¿¶¹
º¶¶¶¶¶½)(¼¶¶¶¶¶¶¶¶½)(¼¶¶¶¶¶¶¶¶½)(·
UVº¶¶¶»UVº¶¶¶»UWº¶¶¶»
XVHU&
Figure 1: Functional model for the ECT supplementary service
6.2 Description of the FEs
The FEs required by the ECT supplementary service in addition to those of basic call are as follows:
FE1: Transfer invoke entity;
FE2: Transfer validate entity;
FE3: Transfer execute entity;
FE4: Transfer screen entity;
FE5: Transfer complete receive entity;
FE6: Transfer inform receive entity.
ETSI
9 EN 300 368 V1.2.2 (1998-12)
6.3 Relationship with a basic service
The relationship with a basic service is as shown in figure 2.
NOTE: The basic call model is defined in CCITT Recommendation Q.71 [4], subclause 2.1, with the exception that
r1 represents an outgoing call relationship from a Call Control Agent (CCA) and r3 represents an incoming
call relationship to a CCA.
URU
¸¶¶¶¹U¸¶¶¶¹U¸¶¶¶¹U¸¶¶¶¹
·&&¼¶¶¶¶¶¶¶½&&¼¶¶¶¶¶¶¶¶½&&¼¶¶¶¶¶¶¶½&&$·
º¶¶¾»UVº¾¶¶¿¹UVº¾¶¶¿¹UWº¾¶¶¿¹
URUU·¸¶¶¶¶¶½)(¼¶¶¶¶¶¶¶¶½)(¼¶¶¶¶¶¶¶½)(·
¸¶¶¶¹U¸¶¶¶¹U¸¿¶¶¹·º¶¾¶»º¶¶¶»º¶¾¶»
·&&$¼¶¶¶¶¶¶½&&¼¶¶¶¶¶½&&···UX·
º¾¶¶¿¹UTº¾¶¶¿¹UUº¶¾¶¿¿¹¸À¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶»
·)(¼¶¶¶¶¶¶½)(¼¶¶¶¶¶¶½)(···
¸¿¶¶¾»¸¿¶¶¾»¸¶¿¶¾¾»·º¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¹
·&&$¼¶¶¶¶¶¶½&&¼¶¶¶¶¶½&&···UX·
º¶¶¶»Uº¶¶¶»Uº¾¶¶»·¸¿¶¶¹¸¶¶¶¹¸¶¿¶¹
RUUU·º¶¶¶¶¶½)(¼¶¶¶¶¶¶¶¶½)(¼¶¶¶¶¶¶¶½)(·
¸¶¶¿¹UV¸¿¶¶¾»UV¸¿¶¶¾»UW¸¿¶¶¾»
·&&¼¶¶¶¶¶¶¶½&&¼¶¶¶¶¶¶¶¶½&&¼¶¶¶¶¶¶¶½&&$·
º¶¶¶»Uº¶¶¶»Uº¶¶¶»Uº¶¶¶»
RUU
Figure 2: Relationship to basic call
7 Information flows
7.1 Information flow diagrams
The information flow diagrams assume the existence of a primary call and a secondary call and that both calls are
maintained until the completion of the transfer. Clearing of the primary and secondary calls with respect to the served user
is not shown as this uses basic call information flows only. Similarly any information flows concerned with holding and
retrieving the primary and secondary calls are outside the scope of the present document.
The TERMINAL DETAILS information flow may occur between both FE6s. Where there is no information to be sent at
all, the information flow is not present in either direction. The information flow is only shown in one direction in figure 3
for reasons of clarity.
The TRANSFER ACTIVE information flow will only occur in the case of an alerting transfer where the alerting user
subsequently answers. In such a case, a TERMINAL DETAILS information flow from user B's FE6 may also occur as a
result of receiving the second TRANSFER INFORM indication.
ETSI
10 EN 300 368 V1.2.2 (1998-12)
UX
¸¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¹
UV
·¸¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¹·
UX
¸¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶··¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶·¶¶¶¶¶¶¶¶¹·
¸¶¶¿¶¶¹UW¸¶¶¶¶¶¹UV¸¶¿¶¿¶¹¸¶¶¶¶¶¹UT¸¶¶¶¶¶¹UU¸¶¶¿¶¶¹UV¸¶¶¿¶¶¹UV¸¶¶¶¶¶¹UW¸¶¶¿¶¶¹
·)(¼¶¶¶¶½)(¼¶¶¶¶½)(··)(¼¶¶¶¶½)(¼¶¶¶¶½)(¼¶¶¶¶½)(¼¶¶¶¶½)(¼¶¶¶¶½)(·
º¾¶¶¶¾»º¾¶¶¶¾»º¾¶¶¶¾»º¾¶¶¶¾»º¾¶¶¶¾»º¾¶¶¶¾»º¾¶¶¶¾»º¾¶¶¶¾»º¾¶¶¶¾»
··················
········75$16)(5··········
········,192.(··········
······¼¶¶¶À¶¶¶¶¶¶¶¶¶¶!À¶¶¶½········
········UHTLQG··········
··········75$16)(5········
··········,192.(········
········¼¶¶¶À¶¶¶¶¶¶¶¶¶¶!À¶¶¶½······
··········UHTLQG········
··················
··················
··········75$16)(5QRWH······
··········,192.(········
········¼¶¶¶À¶¶¶¶¶¶¶¶¶¶À¶¶¶½······
········75$16)(5··UHVSFRQI········
········,192.(··········
······¼¶¶¶À¶¶¶¶¶¶¶¶¶¶À¶¶¶½········
········UHVSFRQI··········
··················
··················
··················
··············
··············
······75$16)(5&203/(7(········
····¼¶¶¶À¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶À¶¶¶½75$16)(5······
····75$16)(5··UHTLQG··&203/(7(······
····&203/(7(··¼¶¶¶À¶¶¶¶¶¶¶¶¶¶!À¶¶¶½····
··¼¶¶¶À¶¶¶¶¶¶¶¶¶¶À¶¶¶½··UHTLQG··75$16)(5····
··75$16)(5··UHTLQG······&203/(7(····
··,1)250······¼¶¶¶À¶¶¶¶¶¶¶¶¶¶!À¶¶¶½··
¼¶¶¶À¶¶¶¶¶¶¶¶¶¶À¶¶¶½······UHTLQG··75$16)(5··
··UHTLQG·(·········,1)250··
··········¼¶¶¶À¶¶¶¶¶¶¶¶¶¶!À¶¶¶½
···········(·UHTLQG··
··············
··············
NOTE: If the optional procedures for preventing loops are provided, the information flow shown in figure 4 occurs at this point, before proceeding with the rest of the information
flow shown in this figure.
Figure 3 (sheet 1 of 2): Successful call transfer
ETSI
11 EN 300 368 V1.2.2 (1998-12)
UX
¸¶¶¶¶¶¶¶¶¶¶¶¶
...