S tandard ECMA-177
3rd Edition - December 2001
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Transfer Supplementary Service
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]
.
S tandard ECMA-177
3rd Edition - December 2001
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Transfer Supplementary Service (CTSD)
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
Ecma-177.doc
14-01-02 09,33
.
Brief History
This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. This particular Standard specifies the Call Transfer supplementary service. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 1st Edition of Standard ECMA-177 (published by ECMA in June 1992), the 2nd Edition (published by ECMA in September 1997) incorporated changes in order to achieve complete alignment with International Standard ISO/IEC 13865:1995(E) published by ISO/IEC in November 1995.
Adopted as 3rd Edition of Standard ECMA-177 by the General Assembly of December 2001.
- i -
Table of contents 1
Scope
1
2
Conformance
1
3
References (normative)
1
4
Definitions 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 A d d itio n a l n e tw o r k f e a tu r e 4.2.2 A le r tin g 4.2.3 Answered 4.2.4 Call, basic call 4.2.5 P r i ma r y c a l l 4.2.6 S e c o n d a r y c a ll 4.2.7 Transfer by Join 4.2.8 T r a n s f e r b y r e r o u te in g 4.2.9 User A 4.2.10 User B 4.2.11 User C
2 2 2 2 2 3 3 3 3 3 3 3 3 3
5 6
Acronyms S S - C T s t a g e 1 s p e c if ic a t io n 6 . 1 D e s c r ip tio n 6.1.1 G e n e r a l d e s c r ip tio n 6.1.2 Q u a l i f i c a t i o n s o n a p p l i c a b i l i t y t o t e l e c o mmu n ic a t i o n s s e r v i c e s 6.2 Procedures 6.2.1 P r o v is io n /w ith d r a w a l 6.2.2 N o r ma l p r o c e d u r e s 6.2.3 E x c e p tio n a l p r o c e d u r e s 6 . 3 I n te r a c tio n s w ith o th e r s u p p le me n ta r y s e r v ic e s a n d A N F s 6.3.1 Calling Line Identification Presentation (SS-CLIP) 6.3.2 C o n n e c t e d L i n e I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO L P ) 6.3.3 Ca llin g /Co n n e c te d L in e I d e n tif ic a tio n Re s tr ic tio n ( S S - CL I R) 6.3.4 C a l l i n g N a me I d e n t i f i c a t i o n P r e s e n t a t i o n ( S S - C N I P ) 6.3.5 C o n n e c t e d N a me I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO N P ) 6.3.6 Ca llin g /c o n n e c te d N a me I d e n tif ic a tio n Re s tr ic tio n ( S S - CN I R) 6.3.7 C o mp l e t i o n o f C a l l s t o B u s y S u b s c r i b e r s ( S S - C C B S ) 6.3.8 C o mp l e t i o n o f C a l l s o n N o R e p ly ( S S - C C N R ) 6.3.9 Ca ll F o r w a r d in g S e r v ic e s 6.3.10 P a t h R e p l a c e me n t ( A N F - P R ) 6 . 4 I n te r w o r k in g c o n s id e r a tio n s
3 4 4 4 4 4 4 4 5 5 5 5 6 6 6 6 6 6 6 6 6
- ii -
6.4.1 U s e r B a n d /o r U s e r C in a n o th e r n e tw o r k 6.4.2 U s e r A in a n o th e r n e tw o r k 6.5 Overall SDL
6 6 7
7
SS-CT stage 2 specification for transfer by join 7 . 1 F u n c tio n a l mo d e l 7.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 7.1.2 Description of functional entities 7.1.3 Re la tio n s h ip o f f u n c tio n a l mo d e l to Ba s ic Ca ll f u n c tio n a l mo d e l 7 . 2 I n f o r ma t i o n f l o w s 7.2.1 D e f in itio n o f in f o r ma tio n f lo w s 7.2.2 Re la tio n s h ip o f in f o r ma tio n f lo w s to b a s ic c a ll in f o r ma tio n f lo w s 7.2.3 E x a mp le s o f in f o r ma tio n f lo w s e q u e n c e s 7.3 Functional Entity actions 7.3.1 Functional Entity actions of FE1 7.3.2 Functional Entity actions of FE2 7.3.3 Functional Entity actions of FE3 7.3.4 Functional Entity actions of FE4 7 . 4 F u n c t i o n a l E n t i t y b e h a v io u r 7.4.1 Be h a v io u r o f F E 1 7.4.2 Be h a v io u r o f F E 2 7.4.3 Be h a v io u r o f F E 3 7.4.4 Be h a v io u r o f F E 4 7 . 5 A l l o c a t i o n o f f u n c t i o n a l e n t i t i e s t o p h ys i c a l l o c a t i o n s 7 . 6 I n te r w o r k in g c o n s id e r a tio n s
8 8 8 8 9 10 10 12 12 15 15 15 15 15 15 16 17 19 20 21 21
8
SS-CT stage 2 specification for transfer by rerouteing 8 . 1 F u n c tio n a l mo d e l 8.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 8.1.2 Description of functional entities 8.1.3 Re la tio n s h ip o f f u n c tio n a l mo d e l to Ba s ic Ca ll f u n c tio n a l mo d e l 8 . 2 I n f o r ma t i o n f l o w s 8.2.1 D e f in itio n o f in f o r ma tio n f lo w s 8.2.2 Re la tio n s h ip o f in f o r ma tio n f lo w s to b a s ic c a ll in f o r ma tio n f lo w s 8.2.3 E x a mp le s o f in f o r ma tio n f lo w s e q u e n c e s 8.3 Functional Entity actions 8.3.1 Functional Entity actions of FE1 8.3.2 Functional Entity actions of FE5 8.3.3 Functional Entity actions of FE6 8.3.4 Functional Entity actions of FE7 8.3.5 Functional Entity actions of FE4 8 . 4 F u n c t i o n a l E n t i t y b e h a v io u r 8.4.1 Be h a v io u r o f F E 5 8.4.2 Be h a v io u r o f F E 6 8.4.3 Be h a v io u r o f F E 7 8 . 5 A l l o c a t i o n o f f u n c t i o n a l e n t i t i e s t o p h ys i c a l l o c a t i o n s
22 22 22 23 23 24 24 26 26 30 30 30 30 30 30 31 31 33 34 35
- iii -
Annex A - Bibliography
37
1
Scope This 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 ECMA-142. 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 ETS 300 387. This 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 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 Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the supplementary services specified in this Standard. This means that, to claim conformance a stage 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
References (normative) The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-133
Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)
ECMA-142
Private Integrated Services Network (PISN) - Circuit-mode 64 kbit/s Bearer Services Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
ECMA-148
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Identification Supplementary Services (International Standard ISO/IEC 14136)
ECMA-163
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Name Identification Supplementary Services (International Standard ISO/IEC 13864)
ETS 300 387
Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)
ITU-T Rec. I.112
Vocabulary of terms for ISDNs (1993)
ITU-T Rec. I.210
Principles of telecommunication services supported by an ISDN and the means to describe them (1993)
ITU-T Rec. Z.100 Specification and description language (1999)
- 2 -
4
Definitions For the purposes of this Standard, the following definitions apply.
4.1
External definitions This Standard uses the following terms defined in other documents: − Basic Service
(ITU-T Rec. I.210)
− Connection
(ITU-T Rec. I.112)
− Private Integrated Services Network (PISN)
(ECMA-133)
− Private Integrated services Network eXchange (PINX)
(ECMA-133)
− Service
(ITU-T Rec. I.112)
− Signalling
(ITU-T Rec. I.112)
− Supplementary Service
(ITU-T Rec. I.210)
− User
(ECMA-142)
This Standard refers to the following basic call functional entities (FEs) defined in ECMA-142: − Call Control (CC) − Call Control Agent (CCA) This Standard refers to the following basic call inter-FE relationships defined in ECMA-142: − r1 − r2 − r3 This Standard refers to the following basic call information flows defined in ECMA-142: − Channel_Acknowledge request/indication − Release request/indication − Release response/confirmation − Setup request/indication − Setup response/confirmation This Standard refers to the following basic call information flow elements defined in ECMA-142: − Call History (CH) − Connected Number (CN) − Connected Subaddress (CS) This Standard refers to the following Connected Line Identification Presentation information flow elements defined in ECMA-148: − Connected Number (CN) − Connected Subaddress (CS)
4.2
Other definitions
4.2.1
A d d it io n a l n e t wo r k f e a t u r e A capability, over and above that of a basic service, provided by a PISN, but not directly to a PISN user.
4.2.2
A le r t in g The state of the secondary call when the called user is being alerted but has not yet answered.
- 3 -
5
4.2.3
Answered The state of the primary or secondary call after the called user has answered.
4.2.4
C a ll, b a s ic c a ll An instance of the use of a basic service.
4.2.5
P r im a r y c a ll One of the calls involved in the transfer. In the case of a transfer 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.
4.2.6
Secondary call The other call involved in the transfer.
4.2.7
Tr a n s f e r b y J o in The effecting of transfer by joining together the connections of the primary and secondary calls at User A's PINX.
4.2.8
Transfer by rerouteing The effecting of transfer by establishing a new connection to 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 Transfer.
4.2.10
User B The other user in User A's primary call.
4.2.11
User C The other user in User A's secondary call.
Acronyms AI
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
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
PISN
Private Integrated Services Network
req
request
- 4 -
6
resp
response
RN
Rerouteing Number (information flow element)
SDL
Specification and Description Language
SS-CT
Supplementary Service Call Transfer
TDR
Terminal Detail Request
TE
Terminal Equipment
TIDR
Transfer Identity Result (information flow element)
TINR
Transfer Initiate Result (information flow element)
TIVR
Transfer Invoke Result (information flow element)
SS-CT stage 1 specification
6.1
Description
6.1.1
General description 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 SSCT, 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 Standard. This 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
6.2
Qualifications on applicability to telecommunications services SS-CT is applicable to all basic services defined in ECMA-142.
Procedures
6.2.1
P r o v is io n /wit h d r a wa l SS-CT shall be generally available to all PISN users with the ability to invoke it.
6.2.2 Normal procedures 6.2.2.1 A c t iv a t io n /d e a c t iv a t io n /r e g is t r a t io n /in t e r r o g a t io n Not applicable. 6.2.2.2
I n v o c a t io n a n d o p e r a t io n 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.
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.
- 5 -
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,1 kHz audio." NOTE 2 The provision of interworking functions between different bearer capabilities is outside the scope of this 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 Standard. 6.2.3 Ex c e p t io n a l p r o c e d u r e s 6.2.3.1 A c t iv a t io n /d e a c t iv a t io n /r e g is t r a t io n /in t e r r o g a t io n Not applicable. 6.2.3.2
I n v o c a t io n a n d o p e r a t io n 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.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 -
6.3.3
C a l l i n g /C o n n e c t e d L i n e I d e n t i f i c a t i o n R e s t r i c t i o n ( S S - C L I R ) 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.
6.3.6
C a l l i n g /c o n n e c t e d N a m e I d e n t i f i c a t i o n R e s t r i c t i o n ( S S - C N I R ) 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
C a ll F o r wa r d in g S e r v ic e s 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.
6.3.10
Path Replacement (ANF-PR) No interaction. NOTE Path Replacement may be invoked as a direct consequence of performing transfer if the transfer is achieved by joining as opposed to rerouteing.
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
U s e r B a n d /o r U s e r C in a n o t h e r n e t wo r k 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
U s e r A in a n o t h e r n e t wo r k 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 inband information.
- 7 -
6.5
Overall SDL Figure 1 contains the dynamic description of SS-CT using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.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.
Idle
A call transfer request is made with respect to the calls. One (in volving User B) should be answered. The other (involving User C) should be answered, alerting or have encountered interworking with a non-ISDN
Transfer request
Attempt to connect User B to User C
Th e result is a call between User B and User C. The call is an answered call, an alerting call, or a call which has encountered interworking with a non-ISDN
Transfer successful ?
NO
YES Transfer successful
Get cause
Clear redundent connections towards User A
transfer reject
Transfer notify to User B
Transfer notify to User C
Idle
Figure 1 - SS-CT, Overall SDL
- 8 -
7
SS-CT stage 2 specification for transfer by join
7.1
Functional model
7.1.1
Functional model description The functional model shall comprise the following Functional Entities: FE1
Transfer Invoke
FE2
Transfer Execute
FE3
Transfer Complete Receive
FE4
Transfer Notification 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 FE2
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
rv
between User B's FE3 and User C's FE3
Figure 2 shows these FEs and relationships. User A FE 1
rr
FE 2 rs
FE 3
rs rv
FE 3
rt
rt
User B
User C
FE 4
FE 4 ru
F ig u r e 2 - F u n c t io n a l M o d e l f o r S S - C T 7.1.2 D e s c r ip t io n o f f u n c t io n a l e n t it ie s 7.1.2.1 Tr a n s f e r in v o k e F u n c t io n a l En t it y , F E1 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
Tr a n s f e r e x e c u t e F u n c t io n a l En t it y , F E2 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.
- 9 -
7.1.2.3
T r a n s f e r c o m p l e t e r e c e iv e F u n c t i o n a l E n t i t y , F E 3 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 FE3s 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 FE4s 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 networks.
7.1.3
R e la t io n s h ip o f f u n c t io n a l m o d e l t o Ba s ic C a ll f u n c t io n a l m o d e l 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.
Use r A CCA
FE1
r1
CCA
rr
CC
FE2
r1 CC
r2
r2
CC rs
r2
FE3
CC
r3
CCA
CC rs
rv
rt
FE4
Use r B
r2
FE3
CC
r3
rt ru
FE4
CCA
Use r C
F i g u r e 3 - E x a m p l e r e l a t i o n s h i p b e t we e n m o d e l f o r S S - C T a n d B a s i c C a l l
- 10 -
7.2
Information flows
7.2.1
7.2.1.1
D e f in it io n o f in f o r m a t io n f lo ws 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 (O) in a request/indication information flow, and the column headed "Confirm" indicates which of these elements are mandatory (M) and which are optional (O) in a response/confirmation information flow. Tr a n s f e r I n v o k e 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. Ta b le 1 - C o n t e n t o f Tr a n s f e r I n v o k e Service element
Request
Confirm
Local Call Identities (LCI)
M
-
Transfer Invoke Result (TIVR)
-
M
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 transfer has been effected and that users B and C are now involved in the same call, without the involvement of User A. 7.2.1.2
Tr a n s f e r C o m p le t e This is an unconfirmed information flow across rs from FE2 to FE3 which indicates that a transfer has been effected. Table 2 lists the service elements within the Transfer Complete information flow. Table 2 - Content of Transfer Complete Service element
Request
Alerting Indication (AI)
O (NOTE)
Call History (CH)
O
Connected Name
O
Connected Number (CN)
O (NOTE)
End Designation (ED)
M
NOTE - CN and AI are mutually exclusive. AI may only be included in the case of an alerting transfer. CN may only be included in the case of an answered transfer. Service elements CN and CH are described in ECMA-142. Service element AI contains User C's number and restriction details if User C's number is known. Service element ED contains a designation for the new end PINXs in the resultant call. Different designations of "Primary" and "Secondary" are given to the two new end PINXs in order to allow them to be distinguished for the purpose of supporting services or features which may be invoked following Call Transfer. Service element Connected Name shall comprise the service elements of information flow INFORM3 of ECMA-163.
- 11 -
7.2.1.3
Tr a n s f e r A c t iv e This is an unconfirmed flow across rs from FE2 to FE3 which indicates that answer has taken place following an alerting transfer. Table 3 lists the service elements within the Transfer Active information flow. Ta b le 3 - C o n t e n t o f Tr a n s f e r A c t iv e Service element
Request
Connected Name
O
Connected Number (CN)
M
Connected Subaddress (CS)
O
Service elements CN and CS are described in ECMA-142. Service element Connected Name shall comprise the service elements of information flow of INFORM3 ECMA-163. 7.2.1.4
Tr a n s f e r N o t if y This is an unconfirmed flow across rt from FE3 to FE4 which informs users of the successful completion of a Call Transfer, and appropriate details of the other user. It can be repeated to provide further information about the transfer that has already been notified. Table 4 lists the service elements within the Transfer Notify information flow. Table 4 - Content of Transfer Notify Service element
Request
Alerting Indication (AI)
O (NOTE)
Call History (CH)
O
Connected Name
O
Connected Number (CN)
O (NOTE)
Connected Subaddress (CS)
O
Terminal Details Request (TDR)
O
NOTE - CN and AI are mutually exclusive. AI is included in the case of an alerting transfer. CN is included (if appropriate) in the case of an answered transfer. Service element CN is described in ECMA-148. Service element AI includes details of the other user involved in the transfer if known and not restricted, its contents being identical to those of service element CN described in ECMA-148. Service element CH is described in ECMA-142. Service element Connected Name shall comprise the elements of information flow INFORM4 of ECMA-163. Service element CS shall be as defined in ECMA-148 and shall be included only when available from information flow Transfer Active. Service element Terminal Details Request shall be included if FE4 is to be invited to send the Terminal Details information flow.
- 12 -
7.2.1.5
Terminal Details This is an unconfirmed information flow across ru from one FE4 to the other which allows the swapping of information between the users involved in the resultant call where such information is not necessarily stored by the network. Table 5 lists the service elements within the Terminal Details information flow. Table 5 - Content of Terminal Details Service element Connected Subaddress (CS)
Request O
Service element CS is described in ECMA-148. 7.2.1.6
Tr a n s f e r U p d a t e This is an unconfirmed flow across rv which allows User B's and User C's FE3s to inform each other of all details about the transferred users that are known to the network if User C's number is known. Table 6 lists the service elements within the Transfer Update information flow. Table 6 - Content of Transfer Update Service element
Request
Alerting Indication (AI)
O (NOTE)
Call History (CH)
O
Connected Name
O
Connected Number (CN)
O (NOTE)
NOTE - CN and AI are mutually exclusive. AI may only be included in the case of an alerting transfer. CN may only be included in the case of an answered transfer. Service elements CN and CH are described in ECMA-142. Service element AI contains User C's number and restriction details if User C's number is known. Service element Connected Name shall comprise the service elements of information flow INFORM3 of ECMA-163. 7.2.2
R e la t io n s h ip o f in f o r m a t io n f lo ws t o b a s ic c a ll in f o r m a t io n f lo ws None of the information flows of transfer by join are related to any basic call flows.
7.2.3
Ex a m p le s o f in f o r m a t io n f lo w s e q u e n c e s A stage 3 standard for SS-CT shall provide signalling procedures in support of the information flow sequences specified below. In addition, signalling procedures should be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc. In the figures, SS-CT information flows are represented by solid arrows and basic call information flows are represented by broken arrows. Within a column representing an SS-CT functional entity, the numbers refer to functional entity actions listed in 7.3. In the figures showing the information flow sequences the primitive and information flows are shortened as follows: 'request"
to
"req"
"indication"
to
" ind"
"response"
to
"resp"
"confirmation" to
"cfm"
- 13 -
7.2.3.1
Successful Call Transfer (both calls answered) Figure 4 shows the information flow sequence for normal operation of SS-CT when both calls have been answered. ru rv rs FE4
CCA
rt
User B
FE3
FE1
CC
CCA
101 102
rr
User A
Transfer Invoke req/ind
401
Transfer Notify
401
CC
req/ind
Te rm ina
req
/in d
FE4
User C CCA
201
Transfer Complete
301
req/ind
Tra nsf er Up dat e r eq /ind
302
rt
resp/cfm
req/ind
ina rm Te
401
CC
Transfer Notify req/ind
FE3
Transfer Invoke
Transfer Complete
301
rs
FE2
Tra
lD eta
ils
n
p r U sfe
Transfer Notify
e dat
req/ind
401
/ind req
302
Transfer Notify req/ind
401
ils eta l D d /in req
401
F i g u r e 4 - I n f o r m a t i o n F l o w S e q u e n c e - N or m a l O p e r a t i o n o f S S - C T ( U s e r C a n s w e r e d ) The Terminal Details flow is optional. If it occurs it may occur in either or both directions and is initiated on any receipt of a Transfer Notify containing element Terminal Details Request.
- 14 -
7.2.3.2
S u c c e s s f u l C a ll Tr a n s f e r ( U s e r C a le r t in g ) Figure 5 shows the information flow sequence for normal operation of SS-CT when User C is being alerted. ru rv rs FE4
CCA
rt
User B
FE3
FE1
CC
CCA
101 102
rr
User A
Transfer Invoke req/ind
FE2
CC
401
req/ind
fer U pd
401
req/ind
302
User C CCA
Transfer Complete req/ind
301 Transfer Notify
pdate fer U Trans ate
req/i n
req/ind
d req/in
Term in
Transfer Notify
FE4
resp/cfm
req/ind
req/in d
CC
rt
Transfer Invoke
Transfer Notify Trans
FE3
201
Transfer Complete
301
rs
al D etail s
302
Transfer Notify req/ind
d
401
401
401
Transfer Active Transfer Notify
401
303
202
Setup
Setup
resp/cfm
resp/cfm
req/ind
req/ind
Figure 5 - Information Flow Sequence - Normal Operation of SS-CT (User C being alerted) FE2 requests "transfer active" when the basic call Setup confirmation generated by User C answering is received by the basic call CC collocated with FE2. The Terminal Details flow is optional. If it occurs it is initiated upon receipt of transfer Notify containing element Terminal Details Request.
- 15 -
7.3
Functional Entity actions The following FE actions shall occur at the points indicated in the figures of 7.2.3.
7.3.1
F u n c t io n a l En t it y a c t io n s o f F E1 101 FE1 shall detect the user request for transfer. Local checks on the suitability of the transfer may be made and the request rejected on the basis of such checks. If the transfer is not barred locally, a Transfer Invoke request shall be sent to FE2. 102
7.3.2
On receipt of the Transfer Invoke confirmation, FE1 shall inform the user of the result, and in the case of successful completion, it may release the primary and secondary calls if they have not yet been released.
F u n c t io n a l En t it y a c t io n s o f F E2 201 On receipt of a Transfer Invoke indication from FE1, FE2 shall identify the primary and secondary calls and check the validity of the request from the network's point of view. The transfer shall be deemed invalid if the primary and secondary calls have incompatible bearer capabilities. If the transfer is found to be invalid, a Transfer Invoke response shall be sent to FE1 indicating rejection. If the transfer is deemed valid, a response indicating success shall be sent to FE1, the connections of the primary and secondary calls towards User B and User C shall be joined together and the connections of the primary and secondary calls towards User A shall be cleared. A Transfer Complete request shall be sent to each of the FE3s. If User C was not being alerted at the time of transfer, the two local CCs shall be merged to form a new Transit CC for the new call. 202
If User C was being alerted at the time of transfer, a Transfer Active request shall be sent to User B's FE3 on detection of answer by User C (indicated by the receipt of a basic call Setup confirmation by the basic call CC collocated with FE2). The two local CCs shall be merged to form a new Transit CC for the new call.
7.3.3
7.3.4
7.4
F u n c t io n a l En t it y a c t io n s o f F E3 301 On receipt of a Transfer Complete indication from FE2, a Transfer Notify request shall be sent to the associated FE4, a Transfer Update request shall be sent to the other FE3 and details relevant to the network concerning the new user in the call may be stored. The Transfer Notify shall contain element Terminal Details Request unless it is sent to a User C that has not answered. Any notifications appropriate due to other supplementary services may be sent to the new user in the call. 302
On receipt of a Transfer Update indication from the other FE3, a Transfer Notify request shall be sent to the associated FE4 and details relevant to the network concerning the other user in the call may be stored.
303
On receipt of a Transfer Active indication from FE2, relevant details may be stored and a second Transfer Notify request shall be sent to the associated FE4.
F u n c t io n a l En t it y a c t io n s o f F E4 401 On receipt of a Transfer Notify indication from the associated FE3 or a Terminal Details indication from the other FE4, relevant details may be stored. In the case of receipt of a Transfer Notify indication containing element Terminal Details Request, a Terminal Details request may be sent to the other FE4 if appropriate. In the case of an alerting transfer, the FE4 associated with User B can receive two of either indication.
Functional Entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100.
- 16 -
7.4.1
Be h a v io u r o f F E1 Figure 6 shows the normal behaviour of FE1. 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 information flows from and to FE2. Idle
Transfer request
YES
Do local checks preclude transfer ? NO Transfer invoke req/ind (to FE2)
Awaiting confirmation
Transfer invoke resp/cfm (from FE2)
Transfer successful ?
NO
YES release primary and secondary calls
Transfer successful
Get cause
transfer reject
Idle
Figure 6 - SS-CT, SDL for functional entity FE1
- 17 -
7.4.2
Be h a v io u r o f F E2 Figure 7 shows the normal behaviour of FE2. Input signals from the left and output signals to the left represent information flows from and to FE1. Input signals from the right and output signals to the right represent information flows from and to FE3 and basic call CCs collocated with FE2.
- 18 -
Idle Transfer Invoke req/ind (from FE1) Identify Primary and Secondary Calls
Transfer allowed ?
No
Yes Transfer Invoke resp/cfm (to FE1)
Transfer invoke resp/cfm reject (to FE1)
Join the two con nections together
Idle
Release unwanted parts of the original con nections Transfer complete req/ind (to FE3)
User B
Transfer complete req/ind (to FE3)
User C
Secon dary Call answered ?
Yes
No Wait answer from User C User C answered (from local CC) Transfer active req/ind (to FE3)
User B
Idle
Figure 7 - SS-CT, SDL for functional entity FE2
- 19 -
7.4.3
Be h a v io u r o f F E3 Figure 8 shows the normal behaviour of FE3. Input signals from the left and output signals to the left represent information flows from and to FE2 and the other FE3. Input signals from the right and output signals to the right represent information flows from and to FE4.
Idle
Transfer complete req/ind (from FE2) Transfer notify req/ind (to FE4)
No
Transfer update req/ind (from other FE3)
Local User
Transfer notify req/ind (to FE4)
Transfer update req/ind (to other FE3)
Store call details
Store call details
Idle
Local User
Other user being altered ? Yes wait transfer active Transfer active req/ind (from FE2)
Transfer update req/ind (from other FE3)
Store call details
Transfer notify req/ind (to FE4)
Transfer notify req/ind (to FE4)
Idle
Local User
Store call details wait transfer active
Figure 8 - SS-CT, SDL for functional entity FE3
Local User
- 20 -
7.4.4
Be h a v io u r o f F E4 Figure 9 shows the normal behaviour of FE4. Input signals from the left and output signals to the left represent primitives from and to User B or User C. Input signals from the right and output signals to the right represent information flows from and to FE3 and the other FE4. Idle
Transfer notify req/ind (from local FE3)
Terminal details req/ind (from other FE4)
Transfer notify
Details of other user
Terminal details to send ?
No
Yes Terminal details req/ind (to other FE4)
Idle
Figure 9 - SS-CT, SDL for Functional Entity FE4
- 21 -
7.5
Allocation of functional entities to physical locations The allocations of FEs to physical equipment shown in table 7 shall apply. In the table, "TE" represents a TE attached to a PISN. Where a terminal involved is stimulus with respect to SS-CT, any FE shown as residing in the TE shall reside instead in that TE's local PINX. Table 7 - FE location scenarios Scenarios
Functional Entities User A
1
User C
FE1
FE2
FE3
FE4
FE3
FE4
TE
PINX
PINX
TE
PINX
TE
2
User A in PISN, Users B, C in other network
TE
PINX
gateway PINX
other network
gateway PINX
other network
3
Users A, B in PISN, User C in other network
TE
PINX
PINX
TE
gateway PINX
other network
4
Users A, C in PISN, User B in other network
TE
PINX
gateway PINX
other network
PINX
TE
5
User A in other network, users B and C in PISN
other network
other network
other network
TE
other network
TE
6
Users A, B in other network, User C in PISN
other network
other network
other network
other network
other network
TE
7
Users A, C in other network, User B in PISN
other network
other network
other network
TE
other network
other network
All users in other network
other network
other network
other network
other network
other network
other network
8
7.6
Intra-PISN transfer
User B
Interworking considerations In the case where User B or User C is in another network, information pertaining to relationship rt is passed across the access to the other network by the gateway PINX if the other network is able to accept and convey all or part of such information. In the case where User A is in another network, any information pertaining to relationship rt received by the gateway PINX or by the user's PINX may be used by that PINX.
- 22 -
8
SS-CT stage 2 specification for transfer by rerouteing A stage 3 standard for SS-CT shall be capable of supporting the functional breakdown of the service specified in this clause.
8.1 8.1.1
Functional model Functional model description The functional model shall comprise the following Functional Entities: FE1
Transfer Invoke
FE4
Transfer Notification Receive
FE5
Transfer Co-ordinate
FE6
Transfer Associate
FE7
Transfer Execute
There shall be two instances of FE4, one associated with User B and one associated with User C. The following functional relationships shall exist between these FEs: rr
between FE1 and FE5
rt
between FE6 and User C's FE4 and between FE7 and User B's FE4
ru
between User B's FE4 and User C's FE4
rx
between FE5 and FE6
ry
between FE5 and FE7
rz
between FE6 and FE7
Figure 10 shows these FEs and relationships. User A FE1
rr
FE5 ry
FE7
rx rz
FE6
rt
rt
User B
User C
FE4
FE4 ru
F ig u r e 1 0 - F u n c t io n a l m o d e l o f S S - C T
- 23 -
8.1.2 D e s c r ip t io n o f f u n c t io n a l e n t it ie s 8.1.2.1 Tr a n s f e r I n v o k e F u n c t io n a l En t it y , F E1 Subclause 7.1.2.1 shall apply. 8.1.2.2
Transfer Notification Receive Functional Entity, FE4 Subclause 7.1.2.4 shall apply.
8.1.2.3
Tr a n s f e r C o - o r d in a t e F u n c t io n a l En t it y , F E5 This FE checks that details known concerning the primary and secondary calls do not preclude the interconnection of User B and User C, and co-ordinates the activities of FE6 and FE7 in executing the transfer.
8.1.2.4
Tr a n s f e r A s s o c ia t e F u n c t io n a l En t it y , F E6 This FE associates the new connection between User B and User C with the existing connection between User A and User C. On successful completion of the transfer, it releases the part of the existing connection between User A and User C which is no longer required and notifies to User C's FE4 the fact that the transfer has occurred.
8.1.2.5
Tr a n s f e r Ex e c u t e F u n c t io n a l En t it y , F E7 This FE initiates the establishment of the new connection between User B and User C. On successful completion of the transfer, it releases the part of the existing connection between User A and User B which is no longer required and notifies to User B's FE4 the fact that the transfer has occurred.
8.1.3
R e la t io n s h ip o f f u n c t io n a l m o d e l t o Ba s ic C a ll f u n c t io n a l m o d e l 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 Transfer but functional with respect to the basic call, in which case FE1 shall be collocated with User A's CCAs for the two calls. Functional Entity FE5 shall be collocated with User A's CCAs for the two calls. Functional Entity FE6 shall be collocated with User C's CC. Functional Entity FE7 shall be collocated with User B's CC. 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 Transfer 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 11. In this example, User A is the called user of the primary call and the calling user of the secondary call.
- 24 -
Use r A CCA
FE1
r1
CCA
rr
CC
FE5
r1 CC
r2
r2
CC ry
r2
FE7
CC
r3
CCA
CC rx
rz
rt
FE4
r2
FE6
CC
r3
rt ru
Use r B
FE4
CCA
Use r C
F i g u r e 1 1 - E x a m p l e R e l a t i o n s h i p b e t we e n M o d e l f o r S S - C T a n d B a s i c C a l l
8.2
Information flows
8.2.1
D e f in it io n o f in f o r m a t io n f lo ws The following information flows shall be supported.
8.2.1.1
Tr a n s f e r I n v o k e Subclause 7.2.1.1 shall apply.
8.2.1.2 Tr a n s f e r I d e n t if y 8 . 2 . 1 . 2 . 1 M e a n in g o f Tr a n s f e r I d e n t if y This confirmed information flow determines the ability of the FE6 to participate in the transfer and if so provides an identity for the secondary call which can be used in the setup process. 8.2.1.2.2
I n f o r m a t io n c o n t e n t o f Tr a n s f e r I d e n t if y Table 8 lists the service elements within the Transfer Identify information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a Transfer Identify request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a Transfer Identify response/confirmation information flow.
- 25 -
Table 8 - Content of Transfer Identify Service element
Request
Confirm
Call Identity (CID)
-
O (NOTE)
Rerouteing Number (RN)
-
O (NOTE)
Transfer Identity Result (TIDR)
-
M
NOTE - Mandatory if request accepted. Service element CID shall contain a call identity which has significance at FE6 and which is used by FE6 to associate the new connection, when it arrives at FE6, with the secondary call. Service element RN shall contain a number which will enable the new connection to be routed to FE6. Service element TIDR shall contain the result of the transfer identify request, and if it indicates rejection, then it shall identify the reason for rejection. Rejection may occur if rerouteing is not supported. An indication of acceptance means that the addressed FE6 is able to participate in the transfer and that it is awaiting completion. 8.2.1.3 Tr a n s f e r A b a n d o n 8 . 2 . 1 . 3 . 1 M e a n in g o f Tr a n s f e r A b a n d o n This unconfirmed information flow indicates that the transfer by rerouteing is to be aborted. 8.2.1.3.2
I n f o r m a t io n c o n t e n t o f Tr a n s f e r A b a n d o n None.
8.2.1.4 Tr a n s f e r I n it ia t e 8 . 2 . 1 . 4 . 1 M e a n in g o f Tr a n s f e r I n it ia t e This confirmed information flow determines the ability of the FE7 to participate in the transfer and, if so, to set up a call using the information which was provided to FE5 by FE6 in the Transfer Identify Response. 8.2.1.4.2
I n f o r m a t io n c o n t e n t o f Tr a n s f e r I n it ia t e Table 9 lists the service elements within the Transfer Initiate information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a Transfer Initiate request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a Transfer Initiate response/confirmation information flow. Table 9 - Content of Transfer Initiate Service element
Request
Confirm
Call Identity (CID)
M
-
Rerouteing Number (RN)
M
-
Transfer Initiate Result (TINR)
-
M
Service elements CID and RN are as described for the "Transfer Identify" information flow across relationship rx. Service element TINR shall contain the result of the transfer initiate request, and if it indicates rejection, then it shall identify the reason for rejection. Rejection may occur if rerouteing is not supported at FE7 or if the new connection cannot be established, e.g. because of congestion. 8.2.1.5 Tr a n s f e r S e t u p 8 . 2 . 1 . 5 . 1 M e a n in g o f Tr a n s f e r S e t u p This confirmed flow is associated with a "basic call" Setup Information flow for the transferred call using the Rerouteing Number (RN) supplied originally by FE6 as the Called Number. In addition it
- 26 -
contains the Call Identity (CID) of the secondary call, as originally supplied by FE6, which is used to associate the new call with the secondary call at FE6. If the transfer is an alerting transfer then the response is not associated with the corresponding basic call setup response but with the basic all (Alerting) report. 8.2.1.5.2
I n f o r m a t io n c o n t e n t o f Tr a n s f e r S e t u p Table 10 lists the service elements within the Transfer Setup information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a Transfer Setup request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a Transfer Setup response/confirmation information flow. Table 10 - Content of Transfer Setup Service element
Request
Confirm
Alerting Indication (AI)
-
O (NOTE)
Call History (CH)
O
O
Call Identity (CID)
M
-
Connected Name
O
O
Connected Number (CN)
O
O (NOTE)
NOTE - CN and AI are mutually exclusive. AI may only be included in the case of an alerting transfer. CN may only be included in the case of an answered transfer. Service element CID shall be defined as for the "Transfer Identify" information flow across relationship rx. Elements CN and CH shall be as defined in ECMA-142. Element AI shall contain User C's number and restriction details if User C's number is known. Element Connected Name shall comprise the elements of information flow INFORM3 of ECMA-163. 8.2.1.6
Tr a n s f e r N o t if y 7.2.1.4 shall apply.
8.2.1.7
Terminal Details 7.2.1.5 shall apply.
8.2.2
R e la t io n s h ip o f in f o r m a t io n f lo ws t o b a s ic c a ll in f o r m a t io n f lo ws None of the information flows of transfer by rerouteing are related to any basic call flows.
8.2.3
Ex a m p le s o f in f o r m a t io n f lo w s e q u e n c e s Below are examples of typical sequences of information flows. In addition to providing signalling procedures in support of these sequences, a stage 3 standard shall also cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc. In the figures, SS-CT information flows are represented by solid arrows and basic call information flows are represented by broken arrows. An ellipse embracing two information flows indicates that the two information flows occur simultaneously. Within a column representing an SS-CT functional entity, the numbers refer to functional entity actions listed in 8.3.
- 27 -
8.2.3.1
Successful Call Transfer (answered) Figure 12 shows the information flow sequence for normal operation of SS-CT when User C has answered.
ru rz ry FE4
CCA
rt
User B
FE7
FE1
CC
CCA
101
rr
rx
FE5
CC
User A
Transfer Invoke req/ind
FE6
CC
rt
FE4
User C CCA
501 Transfer Identify req/ind
701
502
Transfer Initiate
601
Transfer Identify resp/cfm
req/ind
Transfer Setup
602
req/ind
Transfer Notify Setup
req/ind
401
req/ind Transfer Setup
702 Transfer Notify
401
req/ind
resp/cfm Setup resp/cfm
Transfer Initiate
503
resp/cfm
Transfer Invoke
102
resp/cfm
Terminal Details
401
req/ind
F ig u r e 1 2 - I n f o r m a t io n F lo w S e q u e n c e - N o r m a l O p e r a t i o n o f S S - C T (User C answered) The Terminal Details flow is optional. If it occurs it may occur in either or both directions and is initiated on receipt of a Transfer Notify containing element Terminal Details Request.
- 28 -
8.2.3.2
S u c c e s s f u l C a ll Tr a n s f e r ( a le r t in g ) Figure 13 shows the information flow sequence for normal operation of SS-CT when User C is being alerted. ru rz ry FE4
CCA
rt
User B
FE7
FE1
CC
CCA
101
rr
rx
FE5
CC
User A
Transfer Invoke
FE6
CC
rt
FE4
User C CCA
501
req/ind
Transfer Identify req/ind
701
502
Transfer Initiate
601
Transfer Identify resp/cfm
req/ind
Transfer Setup
602
req/ind
Transfer Notify Setup
req/ind
401
req/ind Transfer Setup
702 401
resp/cfm
Report
Transfer Notify
req/ind
req/ind
Transfer Initiate
503
resp/cfm
Transfer Invoke
102
resp/cfm
Terminal Details
401
req/ind
Transfer Notify
401
703
Setup resp/cfm
req/ind
F ig u r e 1 3 - I n f o r m a t io n F lo w S e q u e n c e - N o r m a l O p e r a t i o n o f S S - C T (User C alerting) The Terminal Details flow is optional. If it occurs it is initiated on any receipt of Transfer Notify containing element Terminal Details.
- 29 -
8.2.3.3
U n s u c c e s s f u l C a ll Tr a n s f e r ( s e t u p f a ils ) Figure 14 shows the information flow sequence for unsuccessful operation of SS-CT when basic call does not reach User C's PINX owing to congestion. ru rz ry FE4
CCA
rt
User B
FE7
FE1
CC
CCA
101
rr
User A
Transfer Invoke req/ind
rx
FE5
CC
FE6
CC
rt
FE4
User C CCA
501 Transfer Identify req/ind
701
Transfer Initiate
502
601
Transfer Identify resp/cfm
req/ind
Transfer Setup req/ind
Note 1
Setup req/ind
Release
702
req/ind
Transfer Initiate (Reject) resp/cfm
503 Note 2 Transfer Abandon req/ind
603
NOTE 1 Basic call does not reach User C's PINX owing to congestion. NOTE 2 If transfer by rerouteing fails, transfer by join is invoked instead. F i g u r e 1 4 - I n f o r m a t i o n F l o w S e q u e n c e - U n s u c c es s f u l O p e r a t i o n o f S S - C T ( c a l l s e t u p f a i l s )
- 30 -
8.3
Functional Entity actions
8.3.1
F u n c t io n a l En t it y a c t io n s o f F E1 7.3.1 shall apply.
8.3.2
F u n c t io n a l En t it y a c t io n s o f F E5 501 On receipt of a Transfer Invoke indication from FE1, FE5 identifies the primary and secondary calls and checks the validity of the requests from the network's point of view. The transfer shall be deemed invalid if the primary and secondary calls have incompatible bearer capabilities. If the transfer is found to be invalid, a Transfer Invoke response is sent to FE1 indicating rejection. If the transfer is deemed valid, a transfer identify request is sent to FE6.
8.3.3
8.3.4
8.3.5
502
On receipt of the Transfer Identify confirmation from FE6, a Transfer Initiate request is sent to FE7 if FE6 is able to co-operate. If FE6 is unable to proceed then a fall-back to transfer by join occurs; this is effected by FE2 processing the original request received by FE5 from FE1.
503
On receipt of the Transfer Initiate confirmation from FE7, a Transfer Invoke response is sent to FE1 if FE7 indicates successful completion of the transfer. If FE7 has been unable to complete the transfer, a Transfer Abandon request is sent to FE6 and a fallback to transfer by join occurs; this is effected by FE2 processing the original request received by FE5 from FE1.
F u n c t io n a l En t it y a c t io n s o f F E6 601 On receipt of a Transfer Identify indication from FE5, FE6 determines whether or not it can participate in the transfer. If FE6 is not able to participate in the transfer, a response indicating rejection is returned to FE5. Otherwise FE6 allocates a locally significant call identity which is included together with a rerouteing number in the response to FE5 and the setup of the new connection is awaited. 602
On receipt of the Transfer Setup indication from FE7, the new connection is joined to the part of the secondary call toward User C, the part of the secondary call toward User A is released, a response to the Transfer Setup is returned to FE7, and a Transfer Notify request is sent to the FE4 associated with User C. The transfer Notify shall contain element Terminal Details Request unless it is sent to a User C that has not answered.
603
If Transfer Abandon is received form FE5 instead of the receipt of an acceptable Transfer Setup from FE7, resources such as the call identity are released and FE6 takes no further part in the transfer.
F u n c t io n a l En t it y a c t io n s o f F E7 701 On receipt of a Transfer Initiate indication from FE5, FE7 determines whether or not it can participate in the transfer. If FE7 is not able to participate in the transfer, a response indicating rejection is returned to FE5. Otherwise a Transfer Setup request is sent to FE6 associated with a basic call request. 702
On receipt of the Transfer Setup confirmation indicating success from FE6, the new connection is joined to the part of the primary call toward User B, a response indicating successful completion is sent to FE5, the part of the primary call toward User A is released, and a Transfer Notify request is sent to the FE4 associated with User B. The transfer Notify Request shall contain element Terminal Details Request. If instead the Transfer Setup is rejected by FE6 or the basic call associated with the Transfer Setup request fails, the Transfer Initiate indication is rejected and FE7 takes no further part in the transfer.
703
If User C was being alerted at the time of transfer, a basic call setup confirmation is awaited from the CC collocated with FE7. On receipt, a Transfer Notify request is passed to the FE4 associated with User B.
F u n c t io n a l En t it y a c t io n s o f F E4 7.3.4 shall apply.
- 31 -
8.4
Functional Entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100. The SDL for FE1 is as described by figure 6, except that references to FE2 are replaced by references to FE5. The SDL for FE4 is as described by figure 9, except that references to FE3 are replaced by references to FE6 and FE7.
8.4.1
Be h a v io u r o f F E5 Figure 15 shows the normal behaviour of FE5. Input signals from the left and output signals to the left represent information flows from and to FE1. Input signals from the right and output signals to the right represent information flows from and to FE6.
- 32 -
Idle
501
Transfer invoke indication (from FE1 )
Identify primary and secondary calls No Transfer allowed ? Yes Transfer identify request (to FE6) Wait for transfer identify response Transfer identify confirm (reject) (from FE6)
502
Transfer identify confirm (accept) (from FE6) Transfer initiate request (to FE7) Wait for transfer identify response
Fall back to transfer by join
503
Transfer initiate confirm (from FE7)
Transfer successful ?
Yes
No Transfer abandon request (to FE6) Transfer invoke response (to FE7)
Idle
F ig u r e 1 5 - S S - C T, S D L f o r F u n c t io n a l En t it y F E5
- 33 -
8.4.2
Be h a v io u r o f F E6 Figure 16 shows the normal behaviour of FE6. Input signals from the left and output signals to the left represent information flows from and to FE5. Input signals from the right and output signals to the right represent information flows from and to FE4.
Idle
601
Transfer identify indication (from FE5)
No able to participate ? Yes Transfer identify response (to FE5)
602
Await setup
Transfer identify response (to FE5)
Idle 603
Transfer setup request (from FE7) Connect old connection toward User C to the new connection and clear the part of the old connection to User A
Transfer abandon indication (from FE5)
Idle
Transfer setup response (to FE7) Transfer notify (to User C's FE4)
Idle
F ig u r e 1 6 - S S - C T, S D L f o r F u n c t io n a l En t it y F E6
- 34 -
8.4.3
Be h a v io u r o f F E7 Figure 17 shows the normal behaviour of FE7. Input signals from the left and output signals to the left represent information flows from and to FE4. Input signals from the right and output signals to the right represent information flows from and to FE5, FE6 and basic call CCs collocated with FE7.
701
Idle Transfer initiate indication (from FE5)
No
Transfer initiate response ( to FE5)
Able to participate? Yes Transfer setup reqest (to FE6)
Idle 702
Await setup response Transfer setup confirm accept (from FE6) Yes
Transfer initiate response reject (to FE5)
Failure case ? No Connect old connection toward User B to the new connection and clear the part of the old con nection to User A
Idle
Transfer initiate response (to FE5) Transfer notify (to User B's FE4)
Is path C being alerted?
No
Yes Wait for transfer active
703
Basic call setup confirm from CC colocated with FE7 Transfer notify request (to FE4)
Idle
F ig u r e 1 7 - S S - C T, S D L f o r F u n c t io n a l En t it y F E7
- 35 -
8.5
Allocation of functional entities to physical locations Table 11 illustrates the various scenarios possible, excluding the cases of stimulus terminals. Where a terminal involved is stimulus with respect to transfer, any FE shown as residing in the corresponding user's TE shall reside instead in that user's PINX. Table 11 - FE location scenarios Scenarios
Functional Entities User A
1
Intra-PISN transfer
User B
User C
FE1
FE5
FE7
FE4
FE6
FE4
TE
PINX
PINX
TE
PINX
TE
2
User A in PISN, users B, C in other network
TE
PINX
gateway PINX
other network
gateway PINX
other network
3
Users A, B in PISN, User C in other network
TE
PINX
PINX
TE
gateway PINX
other network
4
Users A, C in PISN, User B in other network
TE
PINX
gateway PINX
other network
PINX
TE
5
User A in other network, users B and C in PISN
other network
other network
other network
TE
other network
TE
6
Users A, B in other network, User C in PISN
other network
other network
other network
other network
other network
TE
7
Users A, C in other network, User B in PISN
other network
other network
other network
TE
other network
other network
All users in other network
other network
other network
other network
other network
other network
other network
8
- 36 -
- 37 -
Annex A ( in f o r ma tiv e )
Bibliography
ITU-T Rec. I.252.7
Integrated Services Digital Network (ISDN), Explicit Call Transfer supplementary service, service description
Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:
+41 22 849.60.01 [email protected]
Files of this Standard can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.