Information technology — Telecommunications and information exchange between systems — Private Integrated Services Network — Specification, functional model and information flows — Call transfer supplementary service

Is one of a series of standards defining services and signalling protocols applicable to Private Services Networks (PISN). The Series uses ISDN concepts as developed by ITU-T and conforms to the framework of Standards for Open Systems Interconnections as defined by ISO/IEC. Specifies the Call Transfer supplementary service.

Technologies de l'information — Télécommunications et échange d'information entre systèmes — Réseau privé à intégration de services — Spécification, modèle fonctionnel et flux d'informations — Service supplémentaire de transfert d'appel

General Information

Status
Withdrawn
Publication Date
08-Nov-1995
Withdrawal Date
08-Nov-1995
Current Stage
9599 - Withdrawal of International Standard
Completion Date
24-Mar-2003
Ref Project

Relations

Buy Standard

Standard
ISO/IEC 13865:1995 - Information technology -- Telecommunications and information exchange between systems -- Private Integrated Services Network -- Specification, functional model and information flows -- Call transfer supplementary service
English language
43 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL
lSO/IEC
STANDARD
13865
First edition
1995-11-15
Information technology -
Telecommunications and information
exchange between systems - Private
Integrated Services Network -
Specification, functional model and
information flows - Call transfer
supplementary service
Technologies de I’informa tion - T6l6communications et 6change
d’information entre systemes - R6seau priv6 2 in tggration de
services - Spkification, modgle fonctionnel et flux d’in forma tions -
Service suppkmen taire de trans fert d ‘appel
Reference number
lSO/IEC 13865:1995(E)

---------------------- Page: 1 ----------------------
ISO/IEC 13865: 1995 (E)
Contents
v
Foreword
vi
Introduction
1
1 Scope
2 Conformance 1
1
3 Normative references
2
4 Definitions
2
4.1 External definitions
4.2 Otherdefinitions 3
List of Acronyms 4
5
6 SS-CT stage I specification 5
6.1 Description 5
5
6.1.1 General description
Qualifications on applicability to telecommunications services 5
6.1 .2
6.2 Procedures
6.2.1 Provision/withdrawal
6.2.2 Normal procedures
6.2.2.1 Activationldeactivation/registration/interrogation
6.2.2.2 I nvocation and operation
6.2.3 Exceptional procedures
6.2.3.1 Activation/deactivation/registration/interrogation
6.2.3.2 Invocation and operation
6.3 Interactions with other supplementary services and ANFs
6.3.1 Calling Line Identification Presentation (SS-CLIP)
6.3.2 Connected Line identification Presentation (SS-COLP)
6.3.3 Calling/Connected Line Identification Restriction (SS-CLIR)
6.3.4 Calling Name Identification Presentation (SS-CNIP)
6.3.5 Connected Name Identification Presentation (SS-CONP)
6.3.6 Calling/connected Name Identification Restriction (SS-CNIR)
6.3.7 Completion of Calls to Busy Subscribers (SS-CCBS)
0 ISO/IEC 1995
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized in any form or by any means, electronic or mechanical,
including photocopying and microfilm, without permission in writing from the
publisher.
lSO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
ISO/IEC 13865: 1995 (E)
0 ISO/lEC
7
6.3.8 Completion of Calls on No Reply (SS-CCNR)
7
6.3.9 Call Forwarding Services
8
6.3.10 Path Replacement (ANF-PR)
8
6.4 Inter-working considerations
8
6.4.1 User B and/or User C in another network
8
UserA in another network
6.4.2
8
6.5 Overall SDL
10
7 SS-CT stage 2 specification for transfer by join
10
7.1 Functional model
10
7.1 .l Functional model description
11
7.1.2.1 Transfer invoke functional entity, FE1
11
7.1.2.2 Transfer execute functional entity, FE2
11
7.1.2.3 Transfer complete receive functional entity, FE3
Transfer notification receive functional entity FE4 11
7.1.2.4
7.1.3 Relationship of functional model to Basic Call functional model 11
13
7.2 Information flows
Definition of information flows 13
7.2.1
13
7.2.1 .l Transfer Invoke
13
7.2.1.2 Transfer Complete
14
7.2.1.3 Transfer Active
15
7.2.1.4 Transfer Notify
15
7.2.1.5 Terminal Details
16
Transfer Update
7.2.1.6
16
7.2.2 Relationship of information flows to basic call information flows
16
7.2.3 Examples of information flow sequences
Successful Call Transfer (both calls answered) 17
7.2.3.1
19
7.2.3.2 Successful Call Transfer (User C alerting)
20
Functional entity actions
7.3
20
7.3.1 Functional entity actions of FE1
20
7.3.2 Functional entity actions of FE2
20
7.3.3 Functional entity actions of FE3
21
7.3.4 Functional entity actions of FE4
21
7.4 Functional entity behaviour
21
7.4.1 Behaviourof FE1
23
7.4.2 Behaviourof FE2
25
7.4.3 Behaviourof FE3
26
7.4.4 Behaviourof FE4
27
7.5 Allocation of functional entities to physical locations
27
7.6 Interworking considerations

---------------------- Page: 3 ----------------------
0 ISO/IEC
ISO/IEC 13865: 1995 (E)
8 SS-CT stage 2 specification for transfer by rerouteing 28
28
8.1 Functional model
8.1 .I Functional model description 28
8.1.2 Description of functional entities 29
8.1.2.1 Transfer Invoke Functional Entity, FE1 29
8.1.2.2 Transfer Notification Receive Functional Entity, FE4 29
Transfer Co-ordinate Functional Entity, FE5
8.1.2.3 29
Transfer Associate Functional Entity, FE6
8.1.2.4 29
Transfer Execute Functional Entity, FE7
8.1.2.5 29
8.1.3 Relationship of Functional Model to Basic Call Functional Model 29
8.2 Information flows 30
8.2.1 Definition of information flows 30
8.2.1.1 Transfer Invoke 30
8.2.1.2 Transfer Identify 30
8.2.1.2.1 Meaning of Transfer Identify 30
8.2.1.2.2 Information content of Transfer Identify
30
8.2.1.3 Transfer Abandon
31
8.2.1.3.1 Meaning of Transfer Abandon
31
8.2.1.3.2
Information content of Transfer Abandon 31
8.2.1.4 Transfer Initiate 31
8.2.1.4.1 Meaning of Transfer Initiate
31
8.2.1.4.2 Information content of Transfer Initiate
31
Transfer Setup
8.2.1.5 32
8.2.1.5.1 Meaning of Transfer Setup 32
8.2.1.5.2 Information content of Transfer Setup 32
8.2.1.6 Transfer Notify 33
8.2.1.7 Terminal Details 33
8.2.2 Relationship of information flows to basic call information flows 33
8.2.3 Examples of information flow sequences 33
8.2.3.1 Successful Call Transfer (answered) 34
Successful Call Transfer (alerting) 35
8.2.3.2
8.2.3.3 Unsuccessful Call Transfer (setup fails) 36
8.3 Functional Entity actions 37
8.3.1 Functional Entity actions of FE1 37
37
8.3.2 Functional Entity actions of FE5
8.3.3 Functional Entity actions of FE6 37
8.3.4 Functional Entity actions of FE7 38
8.3.5 Functional Entity actions of FE4 38
Functional Entity behaviour 38
8.4
8.4.1 Behaviourof FE5 38
8.4.2 Behaviourof FE6 40
8.4.3 Behaviourof FE7 41
8.5 Allocation of Functional Entities to Physical Locations 42
Annex A 43
iv

---------------------- Page: 4 ----------------------
0 ISOAEC ISO/lEC 13865: 1995 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of IS0 or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with IS0 and IEC, also
take part in the work.
In the field of information technology, IS0 and IEC have established a joint technical committee,
ISOAEC JTC 1. Draft International Standards adopted by the joint technical committee are
circulated to the national bodies for voting. Publication as an International Standard requires
approval by at least 75% of the national bodies casting a vote.
International Standard ISOAEC 13865 was prepared by Joint Technical Committee ISOAEC JTC 1,
Information technology, Subcommittee SC6, Telecommunications and information exchange
between systems.
Annex A of this International Standard is for information only.

---------------------- Page: 5 ----------------------
ISOAEC 13865: 1995 (E)
0 ISOAEC
Introduction
This International Standard is one of a series of standards defining services and signalling
protocols applicable to Private Integrated Services Networks (PISN). The series uses ISDN
concepts as developed by ITU-T and conforms to the framework of Standards for Open Systems
Interconnection as defined by ISOAEC.
This particular International Standard specifies the Call Transfer supplementary service.
VI

---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD 0 lSO/IEC ISO/IEC 13865: 1995(E)
Information technology - Telecommunication and
information exchange between systems - Private Integrated
Services Network - Specification, functional model and
information flows - Call transfer supplementary service
1 Scope
This International Standard specifies Supplementary Service Call Transfer (SS-CT), which is
applicable to various basic services supported by Private Integrated Services Networks (PISNs).
Basic services are specified in
ISOIIEC 11574.
SS-CT is a supplementary service which enables a user to transform two of that user’s calls (of
which one must be answered) into a new call between the other two users of the two calls.
Supplementary service specifications are produced in three stages, according to the method
described in CCITT Recommendation 1.130. This International Standard contains the stage 1 and
stage 2 specifications of SS-CT. The stage 1 specification (clause 6) specifies the supplementary
service as seen by users of PISNs. The stage 2 specification (clauses 7 and 8) identifies the
functional entities involved in the supplementary service and the information flows between them.
This International Standard contains two stage 2 specifications reflecting different ways of
operating the service within the network: transfer by join and transfer by rerouteing.
2 Conformance
In order to conform to this International Standard, a Stage 3 Standard shall specify signalling
protocolsand equipment behaviourthat are capable of being used in a PISN which supports the
supplementary services specified in this International Standard. This means that, to claim
conformance aStage 3 Standard is required to be adequate for the support of those aspects of
clause 6 (stage 1)and clauses 7 and 8 (stage 2) which are relevant to the interface or equipment
to which the Stage 3 Standard applies.
3 Normative references
The following standards contain provisions which, through reference in this text, constitute
provisions of this International Standard. At the time of publication, the editions indicated were
valid. All standards are subject to revision, and parties to agreements based on this International
Standard are encouraged to investigate the possibility of applying the most recent editions of the
1

---------------------- Page: 7 ----------------------
ISOAEC 13865: 1995 (E) 0 ISOAEC
standards indicated below. Members of IEC and IS0 maintain registers of currently valid
International Standards.
ISOAEC 11574: 1994, Information technology - Telecommunications and information exchange
between systems - Private Integrated Services Network- Circuit-mode 64 kbit/s bearer services -
Service description, functional capabilities and information flows.
ISOAEC 11579-l :1994, Information technology - Telecommunications and information exchange
between systems - Private Integrated Services Network - Part I: Reference configuration for PISN
exchanges (PINX).
I SO/I EC 13864: 1995, lnforma tion technology - Telecommunications and information exchange
Private Integrated Sewices Network - Specification, functional model and
between systems -
information flows - Name identification supplementary services.
ISOA EC 14136: 1995, Information technology - Telecommunications and information exchange
between systems - Private Integrated Services Network - Specification, functional model and
information flows -Identification supplementary services.
CCITT Rec. 1.112 (1980), Vocabulary of terms for ISDNs (Blue Book) .
CCITT Rec. I .130 (1988)) Method for the characterization of Telecommunications services
supported by an ISDN and network capabilities of an ISDN
(Blue Book) .
CCIlT Rec.
1.210 (1988), Principles of telecommunication services supported by an ISDNand the
means to describe them (Blue Book).
CCIlT Rec. Z.100 (1988), Specification and description language (Blue Book).
4 Definitions
For the purposes of this International Standard, the following definitions apply.
4.1 External definitions
This International Standard uses the following terms defined in other documents:
- Basic Service (CCllT Rec. 1.210)
- Connection
(CCllT Rec. 1.112)
- Private Integrated Services Network (PISN) (ISO/I EC 11579-l )
- (ISOA EC 11579-l )
Private Integrated Services Network Exchange (PINX)
- Service
(CCllT Rec.l.112)
- Signalling (CCITT Rec. 1.112)
- Supplementary Service (CCITT Rec. 1.210)
- User ISOAEC 11574 )
(
2

---------------------- Page: 8 ----------------------
0 ISO/lEC ISO/IEC 13865: 1995 (E)
This International Standard refers to the following basic call functional entities (FEs) defined in
ISO/IEC 11574:
Call Control (CC)
Call Control Agent (CCA)
This International Standard refers to the following basic call inter-FE relationships defined in
ISO/IEC 11574 :
- rl
- r2
- r3
This International Standard refers to the following basic call information flows defined in ISCMEC
11574 :
- Channel Acknowledge request/indication
-
- Release request/indication
- Release response/confirmation
Setup request/indication
Setup response/confirmation
This International Standard refers to the following basic call information flow elements defined in
ISO/IEC 11574:
- Call History (CH)
- Connected Number (CN)
- Connected Subaddress (CS)
- Destination Category (DC)
This International Standard refers to the following Connected Line Identification Presentation
information flow elements defined in ISO/IEC 14136
- Connected Number (CN)
- Connected Subaddress (CS)
4.2 Other definitions
4.2.1 additional network feature: A capability, over and above that of a basic service,
provided by a PISN, but not directly to a PISN user.
4.2.2 alerting: The state of the secondary call when the called user is being alerted but has not
yet answered.
4.2.3 answered: Thestateoftheprimaryorsecondaycallafterthecalled userhasanswered.
4.2.4 call, basic call: An instance of the use of a basic service.
4.2.5 primary call: One ofthecallsinvolved in the transfer. In the case of atransfer involving
an unanswered call, the primary call is the answered call. In the case where both calls are already
answered, the primary call is chosen arbitrarily by the network.
3

---------------------- Page: 9 ----------------------
0 ISO/IEC
ISO/IEC 13865: 1995 (E)
4.2.6 secondary call: The othercall involved in the transfer.
The effecting of transfer by joining together the connections of the
4.2.7 transfer by Join:
primary and seconday calls at UserA’s PINX.
The effecting of transferbyestablishing a new connection to
4.2.8 transfer by rerouteing:
replace all or part of the connections of the primary and secondary calls.
4 2.9 User A: The served user, i.e. the user requesting Call Tmnsfer.
4.2.10 User B: Theotheruserin UserA’sprimaycall.
4.2.11 User C: Theotheruserin UserA’ssecondaycall.
List of Acronyms
5
Al Alerting Indication
cc Call Control (functional entity)
CCA Call Control Agent (functional entity
cfm confirmation
CH Call History (information flow element)
CID Call Identity (information flow element)
CN Connected Number (information flow element)
cs Connected Subaddress (information flow element)
CUG Closed User Group
DC Destination Category (information flow element)
ED End Designation (information flow element)
FE Functional Entity
ind indication
ISDN Integrated Services Digital Network
LCI Local Call Identities
PINX Private Integrated Services Network Exchange
request
req
response
resp
RN Rerouteing Number (information flow element)
SDL Specification and Description Language
SS-CT Supplementay Service Call Transfer
TDR Terminal Detail Request
TE Terminal Equipment
TIDR Transfer Identity Result (information flow element)
TINR Transfer Initiate Result (information flow element)
4

---------------------- Page: 10 ----------------------
0 ISO/IEC ISO/IEC 13865: 1995 (E)
TIVR Transfer Invoke Result (information flow element)
6 SS-CT stage 1 specification
Description
6.1
General description
6.1 .l
SS-CT is a supplementary service which enables a served user (User A) to transform two of that
users calls into a new call between the other two users of the two calls (User B and User C). Each
call can either be an incoming call to User A or an outgoing call from User A. After successful
invocation of SS-CT, User B and User C will no longer be able to communicate with User A.
One of the calls may be an outgoing call that has not been answered by the other user (User C).
After successful invocation of SS-CT User A will no longer be able to communicate with User B.
User B and User C will be in a position to communicate with each other as soon as User C has
answered.
NOTE - The establishment of either call as part of a request for transfer is outside the scope of
this International Standard. This International Standard assumes that both calls have already been
established when the request for call transfer is made. This does not preclude an implementation
whereby a single user request causes the establishment of a call and its subsequent transfer.
6.1.2 Qualifications on applicability to telecommunications services
SS-CT is applicable to all basic services defined in ISO/IEC 11574.
6.2 Procedures
6.2.1 Provision/withdrawal
SS-CT shall be generally available to all PISN users with the ability to invoke it.
Normal procedures
6.2.2
Activation/deactivation/registration/interrogation
6.2.2.1
Not applicable.
6.2.2.2 Invocation and operation
A Call Transfer request from a user (User A) shall be accepted only if it identifies two of that user’s
calls where:
- both calls (to/from User B and to/from User C) have been answered; or
- one call (to/from User B) has been answered and the other is an outgoing call which is
alerting User C; or
- one call (to/from User B) has been answered and the other is an unanswered
outgoing call to User C in a non-ISDN.
5

---------------------- Page: 11 ----------------------
0 ISO/IEC
ISO/IEC 13865: 1995 (E)
It shall not be necessary for User A to place either call on hold prior to invocation, although either
or both calls may be held.
The network shall ensure that the transfer attempt does not allow an illegal connection to be
made, for example one which would infringe CUG restrictions between User B and User C, or one
which would result in a connection with a mixture of incompatible bearer capabilities.
NOTE 1 - It is User A’s responsibility to ensure that the two calls are otherwise compatible.
Bearer capabilities shall be considered compatible if they are the same. Bearer capabilities shall
also be considered compatible if the only attribute that differs is Information Transfer Capability
and if one call has the value “Speech” and the other call is interworking with a non-ISDN and has
the value ” 3,l &Hz audio.”
NOTE 2 - The provision of interworking functions between different bearer capabilities is outside
the scope of this International Standard.
The result of successful Call Transfer shall be a new call between users B and C, at which point the
original connections to User A shall be released. Both users B and C shall be informed of the
transfer and the name and number of the other user (if available and not subject to restriction), and
whether the other user is still being alerted.
The network shall permit subaddresses to be exchanged between
User B and User C after
transfer.
If User C is being alerted at the time of completion of transfer, it shall continue to be alerted, and
on answer shall be connected to User B.
NOTE 3 - If the call resulting from the invocation of Call Transfer before answer fails to progress to
the answered state within a certain time other actions can be taken e.g., User A can be recalled
and on answer be connected to User B. The definition of procedures to support recall is outside the
scope of this International Standard.
6.2.3 Exceptional procedures
Activation/deactivation/registration/interrogation
6.2.3.1
Not applicable.
6.2.3.2 Invocation and operation
Call Transfer shall be rejected under the following circumstances:
- if invalid call identities are specified;
- if neither of the calls is answered;
if only one call is answered and the other is not an outgoing call which is either
alerting a distant user or interworking with a non- ISDN;
if the two calls have incompatible bearer capabilities;
- if interconnection of User B and User C is not permitted.
If transfer is rejected, User A shall be informed of the reason and the existing calls shall be
unaffected.
6

---------------------- Page: 12 ----------------------
ISO/IEC 13865: 1995 (E)
0 ISO/lEC
6.3 Interactions with other supplementary services and
ANFs
Interactions with other supplementary services and ANFs for which PISN standards were available
at the time of publication of this Standard are specified below.,
6.3.1 Calling Line Identification Presentation (SS-CLIP)
No interaction.
6.3.2 Connected Line Identification Presentation (SS-COLP)
No interaction.
6.3.3 Calling/Connected Line Identification Restriction (SS-CLIR)
User B’s and C’s restriction requirements from the original call shall be used to restrict the
presentation of that user’s number to the other user in a transferred call.
6.3.4 Calling Name Identification Presentation (SS-CNIP)
No interaction.
6.3.5 Connected Name Identification Presentation (SS-CONP)
No interaction.
Calling/connected Name Identification Restriction (SS-CNIR)
6.3.6
User B’s and C’s restriction requirements from the original call shall be used to restrict the
presentation of that user’s name to the other user in a transferred call.
6.3.7 Completion of Calls to Busy Subscribers (SS-CCBS)
No interaction.
6.3.8 Completion of Calls on No Reply (SS-CCNR)
No interaction.
6.3.9 Call Forwarding Services
If Call Transfer occurs while User C is being alerted, the resulting call can subsequently undergo
Call Forwarding on No Reply.
Call Transfer shall not affect the way in which chains of forwarding are controlled. Thus any hop
counter value maintained in order to determine whether a forwarding may occur shall have the
same value after transfer as it had prior to the transfer. The fact that a transfer has taken place shall
not affect the way in which the counter value is subsequently modified due to forwarding.

---------------------- Page: 13 ----------------------
ISO/IEC 13865: 1995 (E) 0 ISO/lEC
Path Replacement (ANF-PR)
6.3.10
No interaction.
NOTE - Path Replacement may be invoked as a direct consequence of performing transfer if the
is achi eved by joining as opposed to rerouteing.
transfer
6.4 Interworking considerations
Call Transfer may take place when one or both of the calls involves interworking with a public ISDN
or a public or private non-ISDN.
6.4.1 User B and/or User C in another network
Since the execution of the Call Transfer service need only involve the interconnection within the
PISN of one end of each of two established connections, the nature of the network (ISDN or non-
ISDN) containing User B or User C makes no difference to the operation of the service as seen by
User A.
The PISN shall pass on any notifications associated with the transfer to the other network if the
other network is capable of receiving this information, the possibilities being the notifications that
transfer has taken place, whether the transfer has taken place prior to answer, the name and
number (if appropriate) of the other User And the other user’s subaddress and compatibility
information.
In the case where User B and User C are in the same network, the PISN may be able to
cooperate
with that network in order to effect Call Transfer in that network.
6.4.2 User A in another network
The PISN shall accept transfer notifications from another network and pass them on to the PISN
user. Transfer notifications include notifications that transfer has taken place, whether the transfer
has taken place prior to answer, the name and number of the other user and the other user’s
subaddress and compatibility information. Where this information is not provided, a PISN user will
have to rely on in-band information.
6.5 Overall S DL
Figure 1 contains the dynamic description of SS-CT using the Specification and Description
Language (SDL) defined in CCITT Rec. 2.100 . The SDL process represents the behaviour of the
network in providing SS-CT. The relationship of this process to the basic call process is indicated
in the annotations.
Input signals from the left and output signals to the left represent primitives from and to User A.
Input signals from the right and output signals to the right represent primitives from and to users B
and C.

---------------------- Page: 14 ----------------------
0 ISOAEC ISOAEC 13865: 1995 (E)
A call transfer request is made
with respect to the calls. One
(i7volving User B) should be
answered. The other (involving
-
User C) should be answered, alerting
connect User B
or have encountered interworking
with a non-ISDN
!
NO
The result is a call between User B-
and User C. The call is an answered
--
- YES
call, an alerting call, or a call which
has encountered interworking with a
Transfer
I
non-l SDN
successful
Get cause
.
I
\
Clear redundent
connections
towards User A
r \
Figure 1 - SS-CT, Overall SDL

---------------------- Page: 15 ----------------------
ISO/IEC 13865:1995 (E)
0 ISOAEC
7
SS-CT stage 2 specification for transfer by join
71 . Functional model
7.1 .I Functional model description
The functional model shall comprise the following Functional Entities:
FE1 Transfer Invoke
FEZ Transfer Execute
FE3 Transfer Complete Receive
FE4 Transfer Not if ication Receive
There shall be two instances of FE3 and FE4, one of each associated with User B and User C.
The following functional relationships shall exist between these FEs:
rr between FE1 and FEZ
rs between FE2 and FE3
rt between FE3 and the FE4 associated with the same user
ru between User B’s FE4 and User C’s FE4
Iv between User B’s FE3 and User C’s FE3
Figure 2 shows these FEs and relationships.
User A
rr
User C
Figure 2 - Functional Model for SS-CT
10

---------------------- Page: 16 ----------------------
ISOAEC 13865: 1995 (E)
0 lSO/lEC
Transfer invoke functional entity, FE1
7.1.2.1
This FE acts on behalf of User A. It is responsible for recognising User A’s decision to effect Call
Transfer, and for identifying the two calls.
7.1.2.2 Transfer execute functional entity, FE2
This FE checks that details known concerning the primary and secondary calls do not preclude
the interconnection of User B and User C and creates the new connection between User B and
User C by joining together the two existing connections.
7.1.2.3 Transfer complete receive functional entity, FE3
This FE acts on behalf of User B or User C, and notifies the respective FE that a transfer has
occurred, along with the details of the new call. Two FE% exist, one for User B and one for User
C. This FE also passes to the other FE3 details about the associated user.
7.1.2.4 Transfer notification receive functional entity FE4
This FE receives on behalf of User B or User C the indication that a transfer has occurred, and the
details of the new call. Two FE& exist, one for User B and one for user C. This FE also passes to
the other FE4 details relevant to the transfer which are not provided by the
7.1.3 Relationship of functional model to Basic Call functional model
Functional Entity FE1 shall be collocated with User A’s CCAs for the two calls, except where User
A’s terminal is stimulus with respect to SS-CT but functional with respect to the basic call, in which
case FE1 shall be collocated with User A’s CCs for the two calls.
Functional Entity FE2 shall be collocated with User A’s CCs for the two calls.
A functional Entity FE3 shall be collocated with each of User B’s and User C’s CCs.
A functional Entity FE4 shall be collocated with each of User B’s and User C’s CCAs, except where
either or both of User B’s and User C’s terminals are stimulus with respect to SS-CT but functional
with respect to the basic call, in which case the FE4 in question shall be collocated with the user’s
cc .
An example of a relationship between the FEs for SS-CT and FEs for the basic call is shown in
Figure 3.
In this example, User A is the called user for the primary call, and the calling user of the secondary
call.
11

---------------------- Page: 17 ----------------------
0 ISO/IEC
ISOAEC 13865: 1995 (E)
User A
r
cc cc
rs rs
r2
r2
/u/
/
rv
\
r3
rt
r-t
n- “\
User C
User B
Example relationship between model for SS-CT and Basic Call
Figure 3 -
12

---------------------- Page: 18 ----------------------
ISOAEC 13865: 1995 (E)
0 ISO/lEC
7.2 Information flows
7.2.1 Definition of information flows
In the tables listing the elements in information flows, the column headed “Request” indicates
which of these elements are mandatory (M) and which are optional (0) in a request/indication
information flow, and the column headed “Confirm” indicates which of these elements are
mandatory (M) and which are optional (0) in a response/confirmation information flow.
7.2.1 .I Transfer Invoke
This is a confirmed information flow across rr from FE1 to FE2 which initiates a transfer. The
request contains the identities of the calls involving users B and C.
Table 1 lists the service elements within the Transfer Invoke information flow.
Table 1 - Content of Transfer Invoke
Service element Request Confirm
M
Local Call Identities (LCI)
M
Transfer Invoke Result (TIVR)
Service element LCI shall contains the identities of the two calls to be transferred.
Service element TIVR contains the result of the transfer invoke request and, if it indicates
rejection, identifies the reason for rejection An indication of rejection means that the primary and
secondary calls have not been affected by the invocation request. An indication of acceptance
means that the transf
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.