S tandard ECMA-178
3rd Edition - December 2001
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol 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-178
3rd Edition - December 2001
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Call Transfer Supplementary Service (QSIG-CT)
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
Ecma-178.doc
15-01-02 14,57
.
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 signalling protocol for use at the Q reference point in support of the Call Transfer supplementary service. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). 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-178 (published by ECMA in June 1992), the 2nd Edition incorporated changes in order to achieve complete alignment with International Standard ISO/IEC 13869:1995(E) published by ISO/IEC in November 1995. Compared to the 2nd Edition of Standard ECMA-178 (published by ECMA in September 1997), this 3rd Edition incorporates migration to ASN.1 version 1997.
Adopted as 3rd Edition of Standard ECMA-178 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 End PINX 4.2.2 P r i ma r y P I N X 4.2.3 Re d ir e c tio n n u mb e r 4.2.4 Secondary PINX 4.2.5 Transferring PINX
2 2 3 3 3 3 3 3
5 6
Acronyms Signalling protocol for the support of SS-CT 6 . 1 S S - CT d e s c r ip tio n 6 . 2 S S - CT o p e r a tio n a l r e q u ir e me n ts 6.2.1 P r o v is io n /W ith d r a w a l 6.2.2 Re q u ir e me n ts o n a T r a n s f e r r in g P I N X 6.2.3 Re q u ir e me n ts o n a P r ima r y P I N X 6.2.4 Re q u ir e me n ts o n a S e c o n d a r y P I N X 6.2.5 Re q u ir e me n ts o n a T r a n s it P I N X 6 . 3 S S - CT c o d in g r e q u ir e me n ts 6.3.1 Operations 6.3.2 I n f o r ma t i o n e l e me n t s 6.3.3 Messages 6 . 4 S S - CT s ta te d e f in itio n s 6.4.1 States at a Transferring PINX 6.4.2 S t a t e s a t a P r i ma r y P I N X 6.4.3 S ta te s a t a S e c o n d a r y P I N X 6 . 5 S S - CT s ig n a llin g p r o c e d u r e s 6.5.1 A c tio n s a t a T r a n s f e r r in g P I N X 6.5.2 A c t i o n s a t a P r i ma r y P I N X 6.5.3 A c tio n s a t a S e c o n d a r y P I N X 6.5.4 Actions at a Transit PINX 6.5.5 S u b s e q u e n t a c tio n s a t a P r ima r y a n d a S e c o n d a r y P I N X 6 . 6 S S - CT imp a c t o f in te r w o r k in g w ith p u b lic I S D N s 6.6.1 Actions at a Gateway PINX 6.6.2 A c tio n s a t o th e r typ e s o f P I N X 6 . 7 S S - CT imp a c t o f in te r w o r k in g w ith n o n - I S D N s
3 3 3 3 3 3 4 4 4 5 5 10 10 11 11 11 11 11 12 14 15 17 17 18 18 18 18
- ii -
6.7.1 Actions at a Gateway PINX 6.7.2 A c tio n s a t o th e r typ e s o f P I N X 6 . 8 P r o to c o l I n te r a c tio n s b e tw e e n S S - CT a n d 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.8.1 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.8.2 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.8.3 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.8.4 Co mp le tio n o f Ca lls o n N o Re p ly ( S S - CCN R) 6.8.5 Ca ll F o r w a r d in g U n c o n d itio n a l ( S S - CF U ) 6.8.6 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.8.7 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.8.8 Call Deflection (SS-CD) 6.8.9 P a t h R e p l a c e me n t ( A N F - P R ) 6 . 9 S S - C T P a r a me t e r v a l u e s ( T i me r s ) 6.9.1 T i me r T 1 6.9.2 T i me r T 2 6.9.3 T i me r T 3 6.9.4 T i me r T 4
18 19 19 20 20 20 20 20 20 20 21 22 23 23 23 23 23
A n n e x A - P r o t o c o l I m p l e m e n t a t i o n C o n fo r m a n c e S t a t e m e n t ( P I C S ) p r o f o r m a
25
Annex B - Imported ASN.1 definitions
33
A n n e x C - Ex a m p le s o f m e s s a g e s e q u e n c e s
35
A n n e x D - S p e c i f i c a t i o n a n d D e s c r i p t i o n L a n gu a g e ( S D L ) r e p r e s e n t a t i o n o f p r o c e d u r e s
43
Annex E - Bibliography
53
A n n e x F - A S N . 1 d e f in it io n s a c c o r d in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9
55
1
Scope This Standard specifies the signalling protocol for the support of the Call Transfer supplementary service (SS-CT) at the Q reference point between Private Integrated Network services eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). SS-CT is a supplementary service which enables a User to transform two of that User's calls (at least one of which must be answered) into a new call between the two other users in the two calls. The Q reference point is defined in ECMA-133. Service specifications are produced in three stages and according to the method specified in ETS 300 387. This Standard contains the stage 3 specification for the Q reference point and satisfies the requirements identified by the stage 1 and stage 2 specifications in ECMA-177. The signalling protocol for SS-CT operates on top of the signalling protocol for basic circuit switched call control, as specified in ECMA-143, and uses certain aspects of the generic procedures for the control of supplementary services specified in ECMA-165. This Standard also specifies additional signalling protocol requirements for the support of interactions at the Q reference point between Call Transfer and other supplementary services and ANFs. This Standard is applicable to PINXs which can interconnect to form a PISN.
2
Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma in annex A.
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-143
Private Integrated Services Network (PISN) - Circuit-mode Bearer Services - InterExchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)
ECMA-155
Private Integrated Services Networks - Addressing (International Standard ISO/IEC 11571)
ECMA-164
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Name Identification Supplementary Services (International Standard ISO/IEC 13868)
ECMA-165
Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)
ECMA-174
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Diversion Supplementary Services (International Standard ISO/IEC 13873)
ECMA-176
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Path Replacement Additional Network Feature (International Standard ISO/IEC 13874)
- 2 -
ECMA-177
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Call Transfer Supplementary Service (International Standard ISO/IEC 13865)
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. Q.950 Supplementary services protocols, structure and general principles (2000) ITU-T Rec. Z.100 Specification and description language (1999)
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: − Alerting
(ECMA-177)
− Answered
(ECMA-177)
− Application Protocol Data Unit (APDU)
(ECMA-165)
− Basic Service
(ITU-T Rec. I.210)
− Gateway PINX
(ECMA-143)
− Complete Number
(ECMA-155)
− Interpretation APDU
(ECMA-165)
− Network Facility Extension (NFE)
(ECMA-165)
− Originating PINX
(ECMA-165)
− Primary Call
(ECMA-177)
− Private Integrated Services Network (PISN)
(ECMA-133)
− Private Integrated services Network eXchange (PINX)
(ECMA-133)
− Secondary Call
(ECMA-177)
− Signalling
(ITU-T Rec. I.112)
− Supplementary Service
(ITU-T Rec. I.210)
− Supplementary Service Control Entity
(ECMA-165)
− Terminating PINX
(ECMA-165)
− Transfer by join
(ECMA-177)
− Transfer by rerouteing
(ECMA-177)
− Transit PINX
(ECMA-165)
− User
(ECMA-142)
− User A
(ECMA-177)
− User B
(ECMA-177)
− User C
(ECMA-177)
- 3 -
4.2
Other definitions
4.2.1
En d P I N X Within the context of a call, a PINX which is not acting as a Transit PINX, i.e. an Originating PINX, a Terminating PINX, or a Gateway PINX.
4.2.2
P r im a r y P I N X The End PINX which is on the end of the Primary Call nearest to User B.
4.2.3
Redirection number The number of a transferred User, as provided to the PINX of the other transferred User.
4.2.4
Secondary PINX The End PINX which is on the end of the Secondary Call nearest to User C.
4.2.5
Transferring PINX End PINX which initiates the call transfer procedures on behalf of User A.
5
Acronyms
6
APDU
Application Protocol Data Unit
ASN.1
Abstract Syntax Notation no. 1
ISDN
Integrated Services Digital Network
NFE
Network Facility Extension
PNP
Private Numbering Plan
PICS
Protocol Implementation Conformance Statement
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
SDL
Specification and Description Language
SS-CT
Supplementary Service Call Transfer
Signalling protocol for the support of SS-CT
6.1
SS-CT description Call Transfer (CT) is a supplementary service which enables a user to transform two of that user's calls (at least one of which must be answered) into a new call between the two other users in the two calls. This supplementary service is applicable to all basic services defined in ECMA-142. Call transfer can be achieved by using one of two methods; transfer by join and transfer by rerouteing. Support of transfer by join is mandatory. Support of transfer by rerouteing is an option, which, if not supported by all PINXs involved in the operation of call transfer, allows fall back to using transfer by join. NOTE When an active call has been transferred to an alerting call, the supervision during the alerting phase and the possible procedures to be followed in case the alerting call remains unanswered are outside the scope of this Standard.
6.2
SS-CT operational requirements
6.2.1
P r o v is io n /W it h d r a wa l Provision and withdrawal shall be in accordance with 6.2.1 of ECMA-177.
6.2.2
Requirements on a Transferring PINX The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the callrelated control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.
- 4 -
6.2.3
Requirements on a Primary PINX The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.
6.2.4
Requirements on a Secondary PINX The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.
6.2.5
Requirements on a Transit PINX The basic call procedures specified in ECMA-143 shall be supported. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply. For SS-CT the requirements are limited to the passing on of Facility information elements for which the destination, as indicated in the NFE, is not the Transit PINX.
- 5 -
6.3
SS-CT coding requirements
6.3.1
O p e r a t io n s The operations defined in Abstract Syntax Notation number 1 (ASN.1) in table 1 shall apply. The notation is in accordance with ITU-T Rec. X.680 and X.690. The ITU-T Rec. X.208 and X.209 superseded version is in annex F. Table 1 - Operations in support of SS-CT
Call-Transfer-Operations-asn1-97 {iso(1) standard(0) pss1-call-transfer(13869) call-transfer-operations-asn1-97 (1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t(2) remote-operations(4) informationObjects(5) version1(0)} EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 {iso(1) standard(0) pss1-generic-procedures (11582) msi-class-asn1-97(11)} Name FROM Name-Operations-asn1-97 {iso(1) standard(0) pss1-name (13868) name-operations-asn1-97 (1)} supplementaryServiceInteractionNotAllowed, notAvailable, invalidCallState FROM General-Error-List {ccitt (0) recommendation (0) q 950 general-error-list (1)} PresentedAddressScreened, PresentedNumberScreened, PartyNumber, PartySubaddress FROM Addressing-Data-Elements-asn1-97 {iso(1) standard(0) pss1-generic-procedures (11582) addressing-data-elements-asn1-97 (20)} PSS1InformationElement FROM PSS1-generic-parameters-definition-asn1-97 { iso(1) standard (0) pss1-generic-procedures (11582) pss1-generic-parameters-asn1-97 (17)}; -- TYPE DEFINITIONS FOR CT OPERATIONS FOLLOW Call-Transfer-Operations OPERATION ::= {callTransferIdentify | callTransferAbandon | callTransferInitiate | callTransferSetup | callTransferActive | callTransferComplete | callTransferUpdate | subaddressTransfer} callTransferIdentify
OPERATION ::= { ARGUMENT DummyArg RESULT CTIdentifyRes ERRORS { notAvailable | invalidCallState | unspecified | supplementaryServiceInteractionNotAllowed} CODE local: 7}
- 6 -
Table 1 - Operations in support of SS-CT (continued) callTransferAbandon
OPERATION ::= { ARGUMENT DummyArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 8}
callTransferInitiate
OPERATION ::= { ARGUMENT CTInitiateArg RESULT DummyRes ERRORS { notAvailable | invalidCallState | invalidRerouteingNumber | unrecognizedCallIdentity | establishmentFailure | unspecified | supplementaryServiceInteractionNotAllowed } CODE local: 9}
callTransferSetup
OPERATION ::= { ARGUMENT CTSetupArg RESULT DummyRes ERRORS{ notAvailable | invalidCallState | invalidRerouteingNumber | unrecognizedCallIdentity | unspecified | supplementaryServiceInteractionNotAllowed } CODE local: 10}
callTransferActive
OPERATION::= { ARGUMENT RETURN RESULT ALWAYS RESPONDS CODE
CTActiveArg FALSE FALSE local: 11}
OPERATION ::= { ARGUMENT RETURN RESULT ALWAYS RESPONDS CODE
CTCompleteArg FALSE FALSE local: 12}
callTransferComplete
- 7 -
Table 1 - Operations in support of SS-CT (continued) callTransferUpdate
OPERATION ::= { ARGUMENT CTUpdateArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 13}
subaddressTransfer
OPERATION ::= { ARGUMENT SubaddressTransferArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 14}
-- TYPE DEFINITIONS FOR CT DATA TYPES FOLLOW DummyArg ::= CHOICE { null NULL, single [1] IMPLICIT Extension{{CTExtSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } DummyRes ::= CHOICE { null NULL, single [1] IMPLICIT Extension{{CTExtSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } CTIdentifyRes ::= SEQUENCE { callIdentity CallIdentity, rerouteingNumber PartyNumber, resultExtension CHOICE { single [6] IMPLICIT Extension{{CTExtSet}}, multiple [7] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } OPTIONAL } CTInitiateArg ::= SEQUENCE { callIdentity CallIdentity, rerouteingNumber PartyNumber, argumentExtension CHOICE { single [6] IMPLICIT Extension{{CTExtSet}}, multiple [7] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } OPTIONAL }
- 8 -
Table 1 - Operations in support of SS-CT (continued) CTSetupArg ::= SEQUENCE { callIdentity CallIdentity, argumentExtension CHOICE { single [0] IMPLICIT Extension{{CTExtSet}}, multiple [1] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } OPTIONAL } CTActiveArg ::= SEQUENCE{ connectedAddress basicCallInfoElements
connectedName argumentExtension single multiple
PresentedAddressScreened, PSS1InformationElement OPTIONAL, -- ISO/IEC 11572 information element -- Progress indicator is conveyed Name OPTIONAL, CHOICE { [9] IMPLICIT Extension{{CTExtSet}}, [10] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } OPTIONAL
} CTCompleteArg ::= SEQUENCE { endDesignation redirectionNumber basicCallInfoElements
redirectionName callStatus argumentExtension single multiple
EndDesignation, PresentedNumberScreened, PSS1InformationElement OPTIONAL, -- ISO/IEC 11572 information element -- Progress indicator is conveyed Name OPTIONAL, CallStatus DEFAULT answered, CHOICE { [9] IMPLICIT Extension{{CTExtSet}}, [10] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } OPTIONAL
} CTUpdateArg ::= SEQUENCE { redirectionNumber redirectionName basicCallInfoElements
argumentExtension single multiple
PresentedNumberScreened, Name OPTIONAL, PSS1InformationElement OPTIONAL, -- ISO/IEC 11572 information element -- Progress indicator is conveyed CHOICE { [9] IMPLICIT Extension{{CTExtSet}}, [10] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} }OPTIONAL }
- 9 -
Table 1 - Operations in support of SS-CT (concluded) SubaddressTransferArg ::= SEQUENCE { redirectionSubaddress PartySubaddress, argumentExtension CHOICE { single [0] IMPLICIT Extension{{CTExtSet}}, multiple [1] IMPLICIT SEQUENCE OF Extension{{CTExtSet}} } OPTIONAL } CallStatus ::= ENUMERATED{ answered(0), alerting(1) } CallIdentity ::= NumericString (SIZE (1..4)) EndDesignation ::= ENUMERATED { primaryEnd(0), secondaryEnd(1) } CTExtSet EXTENSION ::= {…} unspecified
ERROR ::= { PARAMETER Extension {{CTExtSet}} CODE local: 1008 }
invalidRerouteingNumber
ERROR ::= {
CODE local: 1004} -- used when establishment of the new -- connection fails because -- the rerouteingNumber is not a valid -- PISN address
unrecognizedCallIdentity
ERROR ::= {
CODE local: 1005} -- used when establishment of the new -- connection fails because it could not be -- associated with a SS-CT entity -- at the Secondary PINX
establishmentFailure
ERROR ::= {
CODE local: 1006} -- used when establishment of the new -- connection fails and no other error applies -- of Call-Transfer-Operations
END -- of Call-Transfer-Operations-asn1-97
- 10 -
6.3.2 Information elements 6.3.2.1 Facility information element APDUs of the operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDU of the operations defined in 6.3.1, the destinationEntity data element of the NFE shall contain value endPINX. When conveying the invoke APDU of operations callTransferAbandon, callTransferComplete, callTransferActive, callTransferUpdate or subaddressTransfer, the Interpretation APDU shall contain value discardAnyUnrecognisedInvokePdu. When conveying the invoke APDU of operation callTransferSetup, the Interpretation APDU shall contain value clearCallIfAnyInvokePduNotRecognised. When conveying the invoke APDU of operation callTransferIdentify or callTransferInitiate, the Interpretation APDU shall be included with the value rejectUnrecognizedInvokePdu or omitted. 6.3.2.2
Information elements embedded in the Facility information element APDUs of the operations defined in 6.3.1 may contain information elements defined in and coded according to ECMA-143. These shall be embedded in data elements of type PSS1InformationElement as specified in Annex B of ECMA-165. In data element basicCallInfoElements, which is of type PSS1InformationElement, the embedded contents shall be coded as Progress indicator information elements specified in ECMA-143.
6.3.2.3
6.3.3
Other information elements The following information elements used during the establishment of the new connection (transfer by rerouteing) shall be coded as specified in ECMA-143: -
Bearer capability,
-
Called party number,
-
Cause,
-
Sending complete.
Messages Except for cases where a basic call message is to be conveyed at the same time, the Facility information element shall be conveyed in a FACILITY message as specified in ECMA-165. The following messages used during the establishment of the new connection and release of the old connections (in case of transfer by rerouteing) shall be as specified in ECMA-143 and, where applicable, augmented in ECMA-165: -
CALL PROCEEDING
-
CONNECT
-
CONNECT ACKNOWLEDGE
-
DISCONNECT
-
PROGRESS
-
RELEASE
-
RELEASE COMPLETE
-
SETUP
- 11 -
6.4
SS-CT state definitions
6.4.1
States at a Transferring PINX The procedures at the Transferring PINX are written in terms of the following conceptual states existing within the SS-CT control entity in that PINX in association with a particular Call Transfer request from User A.
6.4.1.1
C T- I d le SS-CT is not operating.
6.4.1.2
C T- A wa it - A n s we r - F r o m - U s e r - C A callTransferComplete invoke APDU with callStatus having value alerting has been sent to the Primary PINX. This state may be used during transfer by join.
6.4.1.3
C T- A wa it - I d e n t if y - R e s p o n s e A callTransferIdentify invoke APDU has been sent to the Secondary PINX. This state is used during transfer by rerouteing.
6.4.1.4
C T- A wa it - I n it ia t e - R e s p o n s e A callTransferInitiate invoke APDU has been sent to the Primary PINX. This state is used during transfer by rerouteing.
6.4.2
S t a t e s a t a P r im a r y P I N X The procedures at the Primary PINX are written in terms of the following conceptual states existing within the SS-CT control entity in that PINX in association with the primary call, i.e. a particular call of User B.
6.4.2.1
C T- I d le SS-CT is not operating.
6.4.2.2
C T- A wa it - S e t u p - R e s p o n s e A callTransferSetup invoke APDU has been sent to the Secondary PINX. This state is used during transfer by rerouteing.
6.4.2.3
C T- A wa it - C o n n e c t The Primary Call has been transferred to an alerting Secondary User, and the Primary User has been notified. A CONNECT message indicating answering by the Secondary User is awaited.
6.4.3
States at a Secondary PINX The procedures at the Secondary PINX are written in terms of the following conceptual states existing within the SS-CT control entity in that PINX in association with a particular call of User C.
6.4.3.1
C T- I d le SS-CT is not operating.
6.4.3.2
C T- A wa it - S e t u p A callTransferIdentify return result APDU has been sent to the Transferring PINX. This state is used during transfer by rerouteing.
6.5
SS-CT signalling procedures References in this clause to protocol control states refer to basic call protocol control states defined in ECMA-143. NOTE The specification in this section is based on each of the End PINXs being a different PINX, but this section is also applicable to scenarios where two of the three PINXs are the same. In those scenarios some of the signalling procedures and message flows described in this section are internal to the PINX implementation and therefore outside the scope of this Standard. Annex C contains some examples of message sequences.
- 12 -
6.5.1
Actions at a Transferring PINX Call Transfer procedures shall be initiated on a request from User A specifying the two calls in which User A is involved to be acted upon. The Transferring PINX shall check that one of the two calls is in protocol control state Active and is therefore a valid Primary Call, and that the other call is in protocol control state Active or Call Delivered and is therefore a valid Secondary Call. If User C is a User in a non-ISDN, additional states are valid for the Secondary Call as specified in 6.7.2. NOTE 1 Additional checks carried out by the Transferring PINX, e.g. to satisfy the requirements of ECMA-177, are outside the scope of this Standard. NOTE 2 The SDL representation of procedures at a Transferring PINX is shown in D.1 of annex D. After validation of the request for call transfer, the Transferring PINX shall determine which variant of call transfer is to be attempted: join or rerouteing. NOTE 3 This depends on the capabilities of the Transferring PINX, the known network topology, and on the known capabilities of the Primary and Secondary PINXs in the current call contexts. If call transfer by rerouteing procedures are to be attempted 6.5.1.3 and 6.5.1.4 shall apply, otherwise call transfer by join procedures specified in 6.5.1.1 and 6.5.1.2 shall apply. On successful completion of call transfer (either by join or by rerouteing), the Transferring PINX shall release User A from the two calls and, depending on the procedures at the access, indicate acceptance to User A. On failure of call transfer, e.g. because of an invalid request or because of failure of transfer by rerouteing, the Transferring PINX shall retain the two calls at User A and indicate rejection to User A or take implementation dependent action if the calls have been released already from User A.
6.5.1.1
Normal procedures for transfer by join The Transferring PINX shall join the B-channels of the Primary and Secondary Calls and send a callTransferComplete invoke APDU in a FACILITY message to both the Primary and Secondary PINX using the call references of the Primary and Secondary Call respectively. Within the argument, endDesignation shall be included to give a distinctive designation to each end of the new call. If the Secondary Call was not in protocol control state Active when transferred, the Transferring PINX shall include callStatus with value alerting in the argument of the invoke sent to the Primary PINX. In addition other information may be indicated if available: redirectionNumber and redirectionName to identify the other User in the transferred call, and basicCallInfoElements carrying the progress indications encountered during setup of the other call. If the Secondary Call is not in protocol control state Active at the time of initiation of the transfer, the Transferring PINX shall enter state CT-Await-Answer-From-User-C in which it shall continue to intercept the signalling connections associated with the former Primary and Secondary Calls. In state CT-Await-Answer-From-User-C, if the Transferring PINX receives a callTransferUpdate or subaddressTransfer invoke APDU from the Primary PINX, it shall send a callTransferUpdate or subaddressTransfer invoke APDU respectively to the Secondary PINX, and if the Transferring PINX receives a callTransferUpdate or subaddressTransfer invoke APDU from the Secondary PINX, it shall send a callTransferUpdate or subaddressTransfer invoke APDU respectively to the Primary PINX. In either case the information in the argument of the transmitted APDU shall be the same as that in the received APDU and the Transferring PINX shall remain in the same state. On receipt of a call clearing message from the Primary or Secondary PINX in state CT-AwaitAnswer-From-User-C, the Transferring PINX shall also clear the call towards the Secondary or Primary PINX respectively in accordance with ECMA-143. In state CT-Await-Answer-from-User-C, the Transferring PINX shall convey all Notification indicator information elements received in a NOTIFY message from the Primary PINX to the Secondary PINX and vice versa and remain in the same state.
- 13 -
If both the Primary and Secondary Calls are in protocol control state Active, the Transferring PINX shall associate the two connections after having sent the two callTransferComplete invoke APDUs, start to act as a Transit PINX for the resulting call from this point on, and enter state CT-Idle. On receipt of a CONNECT message on the call reference of the Secondary Call while in state CTAwait-Answer-From-User-C the Transferring PINX shall send a FACILITY message with a callTransferActive invoke APDU on the call reference of the Primary Call. Element basicCallInfoElements may be included. Additionally, if the CONNECT message contained a Facility information element with a connectedName invoke APDU, as defined in ECMA-164, the Transferring PINX may include the information therein in element connectedName in the callTransferActive invoke APDU instead of relaying the connectedName as a separate invoke APDU. The Transferring PINX shall associate the two connections, begin to act as a Transit PINX for the resultant call, and enter state CT-idle. 6.5.1.2
Ex c e p t io n a l p r o c e d u r e s f o r t r a n s f e r b y j o in Not applicable.
6.5.1.3
Normal procedures for transfer by rerouteing In order to start transfer by rerouteing, the Transferring PINX shall send a callTransferIdentify invoke APDU in a FACILITY message to the Secondary PINX using the call reference of the Secondary Call, start timer T1, and enter state CT-Await-Identify-Response. On receipt in state CT-Await-Identify-Response of a FACILITY message with a callTransferIdentify return result APDU on the call reference of the Secondary Call, the Transferring PINX shall send a callTransferInitiate invoke APDU in a FACILITY message to the Primary PINX using the call reference of the Primary Call, stop timer T1, and start timer T3. The callIdentity and rerouteingNumber information received within the result of the callTransferIdentify return result APDU shall be relayed within the argument of the callTransferInitiate invoke APDU. State CT-AwaitInitiate-Response shall be entered. On receipt in state CT-Await-Initiate-Response of a DISCONNECT message with a callTransferInitiate return result APDU using the call reference of the Primary Call, the Transferring PINX shall continue call clearing of the Primary Call according to basic call procedures, initiate call clearing of the Secondary Call according to basic call procedures if this has not been cleared yet, stop timer T3, indicate successful completion of call transfer to User A, and enter state CT-Idle. Upon receiving in state CT-Await-Identify-Response or CT-Await-Initiate-Response of an indication from basic call control that the Primary and/or Secondary Call has been cleared, the Transferring PINX shall initiate clearing of the other call if this has not been cleared yet, indicate successful completion of call transfer to User A, and enter state CT-Idle.
6.5.1.4
Exceptional procedures for transfer by rerouteing On receipt in state CT-Await-Identify-Response of a FACILITY message with a callTransferIdentify reject or return error APDU on the call reference of the Secondary Call, the Transferring PINX shall stop timer T1, abort the procedure for transfer by rerouteing, and, depending on the error cause, either reinitiate call transfer using transfer by join procedures as specified in 6.5.1.1 and 6.5.1.2 or enter state CT-Idle. On expiry of timer T1, the Transferring PINX shall send a callTransferAbandon invoke APDU on the call reference of the Secondary Call, abort the procedure for transfer by rerouteing, and reinitiate call transfer using transfer by join procedures as specified in 6.5.1.1 and 6.5.1.2. On receipt in state CT-Await-Initiate-Response of a FACILITY message using the call reference of the Primary Call, and conveying a callTransferInitiate reject or return error APDU, the Transferring PINX shall send a callTransferAbandon invoke APDU in a FACILITY message using the call reference of the Secondary Call if this has not been cleared yet, stop timer T3, abort the procedure for transfer by rerouteing, and, depending on the error cause, either reinitiate call transfer using transfer by join procedures as specified in 6.5.1.1 and 6.5.1.2 or enter state CT-Idle. On expiry of timer T3, the Transferring PINX shall send a callTransferAbandon invoke APDU on the call reference of the Secondary Call if this has not been cleared yet by the Secondary PINX, and abort the procedure for transfer by rerouteing. If the Secondary Call has not been cleared, call transfer shall
- 14 -
be reinitiated using transfer by join procedures as specified in 6.5.1.1 and 6.5.1.2, or else state CTIdle shall be entered. 6.5.2
A c t io n s a t a P r im a r y P I N X A PINX shall treat as valid an APDU indicating that it is the Primary PINX for SS-CT only if the protocol control state is Active. NOTE The SDL representation of procedures at a Primary PINX is shown in D.2 of annex D.
6.5.2.1
Normal procedures for transfer by join On receipt of a FACILITY message containing a callTransferComplete invoke APDU while meeting the conditions listed in 6.5.2, the Primary PINX shall proceed as follows. The presence of element endDesignation with value 'primaryEnd' signifies that the PINX shall operate as a Primary PINX. Optionally it may send a callTransferUpdate invoke APDU in a FACILITY message using the call reference on which the callTransferComplete invoke was received. Within the argument, optional data elements redirectionNumber, redirectionName, and basicCallInfoElements containing information relating to User B may be conveyed. The Primary PINX may record details of the transfer, notify User B if this is able to receive a notification, and provide other details received in the invoke to User B as appropriate. A number or name marked as restricted shall not be passed on to the transferred User. The Primary PINX may solicit a subaddress for sending to User C. The Primary PINX shall remain in state CT-Idle. Additional procedures valid for state CT-Idle are specified in 6.5.5.
6.5.2.2
Ex c e p t io n a l p r o c e d u r e s f o r t r a n s f e r b y j o in Not applicable.
6.5.2.3
Normal procedures for transfer by rerouteing On receipt in state CT-Idle of a FACILITY message containing a callTransferInitiate invoke APDU while in protocol control state Active, the Primary PINX shall determine whether it can participate in the transfer. If so, it shall attempt to establish a new connection by selecting an outgoing B-channel on a route determined by the contents of rerouteingNumber received within the argument of callTransferInitiate. If a B-channel is available, a SETUP message shall be sent using a new call reference in accordance with the procedures of ECMA-143. The SETUP message shall contain the following information elements: -
Bearer capability, containing the Bearer Capability information of the original call;
-
Called party number, containing the number received in rerouteingNumber within the received argument;
-
Facility;
-
Sending complete.
The SETUP message shall contain a Facility information element conveying a callTransferSetup invoke APDU, with callIdentity within the argument having the same value as callIdentity in the argument that was received within the callTransferInitiate invoke. The SETUP message may also contain a callTransferUpdate invoke APDU. Within the argument, optional elements redirectionNumber, redirectionName and basicCallInfoElements may be conveyed. Optionally, timer T4 may be started. State CT-Await-Setup-Response shall be entered. The protocol procedures of ECMA-143 shall apply during the establishment of the new connection. NOTE Initially protocol control will enter state Call Initiated. On receipt of a CALL PROCEEDING message, state Outgoing Call Proceeding will be entered, on receipt of ALERTING, state Alerting will be entered and on receipt of CONNECT, state Active will be entered. On receipt in state CT-Await-Setup-Response of a CONNECT message (using the call reference of the new connection) containing a callTransferSetup return result APDU, the Primary PINX shall
- 15 -
disconnect the B-channel of the old connection and connect User B to the B-channel of the new connection. Timer T4 shall be stopped if running. The Primary PINX may record details of the transfer and notify User B if this is able to receive a notification. If the CONNECT message also contains a callTransferUpdate invoke APDU with, in the argument, optional elements redirectionNumber, redirectionName and/or basicCallInfoElements the information contained therein may be conveyed to User B. A number or name marked as restricted shall not be passed on to the transferred User. The Primary PINX may solicit a subaddress for sending to User C. A DISCONNECT message containing a callTransferInitiate return result APDU shall be sent on the call reference of the old connection to the Transferring PINX. Completion of the release of the old connection shall be in accordance with the protocol procedures of ECMA-143. State CT-Idle shall be entered. On receipt in state CT-Await-Setup-Response of an ALERTING message (using the call reference of the new connection) containing a callTransferSetup return result APDU, the Primary PINX shall proceed according to the procedures specified in the paragraph above with the following modification. Instead of CT-Idle, state CT-Await-Connect shall be entered. On receipt in state CT-Await-Connect of a CONNECT message on the call reference of the rerouted call, indicating call acceptance by User C, the Primary PINX may notify User B, providing details as appropriate, subject to presentation restrictions, and shall enter state CT-Idle. Additional procedures valid for state CT-Idle are specified in 6.5.5. 6.5.2.4
Exceptional procedures for transfer by rerouteing If on receipt in state CT-Idle of a FACILITY message containing a callTransferInitiate invoke APDU, the Primary PINX is not able to participate, a callTransferInitiate return error APDU containing an appropriate error shall be sent in a FACILITY message on the call reference on which the invoke was received. On expiry of timer T4, or on receipt in state CT-Await-Setup-Response of a call clearing message on the call reference of the new connection, possibly containing a callTransferSetup return error APDU or reject APDU, the Primary PINX shall proceed with call clearing of the new connection in accordance with the procedures of ECMA-143, and send a FACILITY message on the call reference of the primary call. A callTransferInitiate return error APDU shall be conveyed in the FACILITY message, indicating either error value establishmentFailure, or if a callTransferSetup return error has been received, the error value indicated therein. On detection in state CT-Await-Setup-Response of call clearing by User B, or on receipt of a call clearing message on the call reference of the Primary call, the Primary PINX shall proceed with clearing of the primary call in accordance with the procedures of ECMA-143, and initiate call clearing of the new connection using the procedures of ECMA-143. On detection in state CT-Await-Connect of call clearing of the rerouted connection, either by User B or due to reception of a call clearing message using the call reference of the rerouted connection, the Primary PINX shall proceed with clearing of the rerouted connection in accordance with the procedures of ECMA-143. In all of the above cases timer T4 shall be stopped if running and state CT-Idle shall be entered.
6.5.3
A c t io n s a t a S e c o n d a r y P I N X A PINX shall treat as valid an APDU indicating that it is the Secondary PINX for SS-CT only if the protocol control state is Active or Call Received, or if specific conditions applicable to interworking situations as defined in 6.7.1.1 are met. NOTE The SDL representation of procedures at a Secondary PINX is shown in D.3 of annex D.
6.5.3.1
Normal procedures for transfer by join On receipt in state CT-Idle of a FACILITY message containing a callTransferComplete invoke APDU while meeting the conditions listed in 6.5.3, the Secondary PINX shall proceed as follows. The presence of element endDesignation with value 'secondaryEnd' signifies that the PINX shall operate as a Secondary PINX. Optionally it may send a callTransferUpdate invoke APDU in a FACILITY
- 16 -
message to the Primary PINX using the call reference on which the callTransferComplete invoke was received. Within the argument, optional data elements redirectionNumber, redirectionName, and basicCallInfoElements containing information relating to User C may be conveyed. The Secondary PINX may record details of the transfer and may notify User C if this is able to receive this information. If the Protocol Control state of the Secondary Call is Active, the Secondary PINX may solicit a subaddress for sending to User B. The secondary PINX shall remain in state CT-Idle. NOTE On detection of answer by User C, a CONNECT message is sent to the Transferring PINX in accordance with the procedures of ECMA-143, using the call reference of the Secondary Call. Additional procedures valid for state CT-Idle are specified in 6.5.5. 6.5.3.2
Ex c e p t io n a l p r o c e d u r e s f o r t r a n s f e r b y j o in Not applicable.
6.5.3.3
Normal procedures for transfer by rerouteing On receipt in state CT-Idle of a FACILITY message containing a callTransferIdentify invoke APDU under the conditions listed in 6.5.3, the Secondary PINX shall determine whether it can proceed with SS-CT by rerouteing. If so, it shall send a callTransferIdentify return result APDU in a FACILITY message using the call reference on which the invoke APDU was received, start timer T2, and enter state CT-Await-Setup. Within the argument, callIdentity and rerouteingNumber shall be included. Element rerouteingNumber shall contain a number which, when used as the contents of the information element Called party number in a SETUP message, is sufficient to cause routing to the Secondary PINX. NOTE The number provided should have significance throughout the PISN. If it is a number from a Private Numbering Plan (PNP), it should be a Complete Number. If it is an E.164 number then a subscriber number can be insufficient, and in some networks a national number can be insufficient. Element callIdentity shall be a number which, possibly in conjunction with rerouteingNumber, identifies the call on which SS-CT is being invoked. Element callIdentity need not have significance outside the Secondary PINX. Having agreed the B-channel and sent back a CALL PROCEEDING message in response to an incoming SETUP message, in accordance with the procedures of ECMA-143, if the SETUP contains a callTransferSetup invoke APDU, the Secondary PINX shall proceed as follows. If the callIdentity in the argument of callTransferSetup matches the call-identity of a call whose SS-CT control entity is in state CT-Await-Setup, the Secondary PINX shall stop timer T2, disconnect the B-channel of the part of the secondary connection to User A, initiate release of this connection by sending a DISCONNECT message in accordance with the procedures of ECMA-143, and associate the new connection (as requested by the SETUP message) with the part of the Secondary Call to User C. The Secondary PINX may record details of the transfer, may notify the transferred User, and may solicit a subaddress for sending to User B. The SETUP may also contain a callTransferUpdate invoke APDU, having optional elements redirectionNumber, redirectionName and basicCallInfoElements in the argument. The information contained therein may be conveyed to User C, subject to number and/or name presentation restrictions. Next, if the Secondary Call is in state Active, a callTransferSetup return result APDU shall be sent in a CONNECT message using the call reference of the new connection, but if the Secondary Call is not in protocol control state Active, the return result APDU shall be conveyed in an ALERTING message. The CONNECT or ALERTING message may also contain a callTransferUpdate invoke APDU, carrying optional elements redirectionNumber, redirectionName and basicCallInfoElement in the argument of the invoke. State CT-Idle shall be entered. NOTE On detection of answer by User C, a CONNECT message is sent to the Primary PINX in accordance with the procedures of ECMA-143, using the call reference of the newly routed connection. Additional procedures valid for state CT-Idle are specified in 6.5.5.
- 17 -
6.5.3.4
Exceptional procedures for transfer by rerouteing If the secondary PINX is unable to comply with the callTransferIdentify invoke APDU, it shall send back a FACILITY message containing a callTransferIdentify return error APDU with a suitable error. Reasons can include: -
invalid call state;
-
a temporary condition prevents participation as Secondary PINX in a call transfer by rerouteing procedure;
-
SS-CT by rerouteing is not implemented.
Any errors other than unrecognizedCallIdentity may be used. Failure to associate an incoming SETUP message containing a callTransferSetup invoke APDU with a SS-CT entity in state CT-Await-Setup shall result in the sending of a DISCONNECT message to initiate the clearing of the new connection. Depending on implementation, the DISCONNECT shall contain either: -
a suitable cause number in the Cause information element, e.g. 1 "unallocated (unassigned) number"; or
-
cause number 29 "facility rejected" in the Cause information element and a return error APDU containing error unrecognisedCallIdentity.
On receipt in state CT-Await-Setup of a callTransferAbandon invoke APDU in a FACILITY message using the call reference of the Secondary Call, the Secondary PINX shall stop timer T2, abort the procedure for transfer by rerouteing, and enter state CT-Idle. On detection in state CT-Await-Setup of call clearing of the Secondary Call either by User B or due to reception of a call clearing message using the call reference of the Secondary Call, the Secondary PINX shall proceed with clearing of the Secondary Call in accordance with the procedures of ECMA-143, stop timer T2 if running and enter state CT-Idle. On expiry of timer T2, the Secondary PINX shall abort the procedure for transfer by rerouteing and enter state CT-Idle. 6.5.4
A c t io n s a t a Tr a n s it P I N X No special actions are required in support of SS-CT.
6.5.5
Subsequent actions at a Primary and a Secondary PINX During state CT-Idle, a FACILITY message containing a callTransferUpdate invoke APDU may be received. Information therein may be conveyed to the local user, if this is able to receive that information, and subject to number and/or name presentation restrictions. This information shall override any information received previously in a callTransferComplete invoke APDU. If during state CT-Idle, a FACILITY message containing a subaddressTransfer invoke APDU is received, the PINX may relay the subaddress on to the local user. If during state CT-Idle, the local user's terminal supplies subaddress information for transmission to the other user, the PINX shall transmit the information in a subaddressTransfer invoke APDU in a FACILITY message. If during state CT-Idle a FACILITY message containing a callTransferActive invoke APDU is received, the information received may be conveyed to the local user, if this is able to receive that information, and subject to number and/or name presentation restrictions. The information received shall override any information received previously. As an implementation option a Primary or Secondary PINX can keep record of the fact that a transfer has occurred and ignore the above events if transfer has not occurred.
- 18 -
6.6
SS-CT impact of interworking with public ISDNs
6.6.1
A c t io n s a t a G a t e wa y P I N X Interworking aspects are different depending on the type of interworking situation, the two relevant types are:
6.6.1.1
-
User A is in the PISN and transfers one or two public ISDN users,
-
User A is in the public ISDN and one or two PISN Users are transferred. I m p a c t o f in t e r wo r k in g if U s e r A is in t h e P I S N When User A is in the PISN, and User B (User C) is in the public ISDN, call transfer is performed within the PISN, and the gateway PINX shall act as Primary (Secondary) PINX. If the signalling protocol at the access allows, the Gateway PINX shall indicate that transfer has occurred, together with relevant information e.g. whether active or alerting, and the number and/or subaddress of the transferred-to User in appropriate notifications or operations to the public ISDN. If subaddress information is subsequently received from the public ISDN it shall be forwarded to the other End PINX as data element connectedSubaddress in a subaddressTransfer invoke APDU within a FACILITY message.
6.6.1.2
Impact of interworking if a PISN User is transferred by the public ISDN When User A is in the public ISDN, call transfer is performed within the public ISDN. The Gateway PINX shall forward the information received in the call transfer indication, which consists of an indication "call transferred, active" or "call transferred, alerting" and optionally a redirection number, to the other End PINX in a callTransferComplete invoke APDU within a FACILITY message. Element endDesignation in the invoke APDU shall be coded primaryEnd, except when the call to which call transfer applies is an incoming call from the ISDN that has not yet reached the Active state, in which case element endDesignation shall be coded secondaryEnd. Inclusion of other data elements is dependent on information received from the public ISDN. On receipt of a FACILITY message from the other End PINX containing a subaddressTransfer invoke APDU with data element connectedSubaddress, the Gateway PINX shall forward a response with subaddress information to the public ISDN if a request for subaddress information is pending. When subaddress information is received from the public ISDN in a separate operation, this information shall be forwarded to the other End PINX as data element connectedSubaddress in a subaddressTransfer invoke APDU within a FACILITY message.
6.6.2
6.7
A c t io n s a t o t h e r t y p e s o f P I N X The procedures of 6.5 shall apply.
SS-CT impact of interworking with non-ISDNs
6.7.1 A c t io n s a t a G a t e wa y P I N X 6.7.1.1 Tr a n s f e r wit h in t h e P I S N When User A is in the PISN, and User B (User C) is in the non-ISDN, call transfer shall be performed within the PISN, and the gateway PINX shall act as Primary (Secondary) PINX. The gateway shall perform for call transfer a signalling mapping between the signalling system specified in this Standard and that of the non-ISDN. An Outgoing Gateway PINX interworking with a non-ISDN shall treat as valid an APDU indicating that it is the Secondary PINX for SS-CT also if the protocol control state is Incoming Call Proceeding or Overlap Receiving. NOTE The Outgoing Gateway PINX, which will perform Secondary PINX functions in the context of call transfer, has informed the PINX serving User A of this condition before invocation of call transfer by sending, in accordance with ECMA-143, a Progress indicator information element with CCITT progress description "interworking with a non-ISDN (no. 1)" in an appropriate message in the backwards direction while it handled the incoming call from the PINX serving User A.
- 19 -
When a Gateway PINX, which performs Secondary PINX functions in the context of call transfer by rerouteing, has associated an incoming SETUP message that contains a callTransferSetup invoke APDU with a call whose SS-CT control entity is in state CT-Await-Setup, it shall proceed according to the procedures defined for this situation in 6.5.3.3, with the modification that if the Secondary call is in protocol control state Incoming Call Proceeding or Overlap Receiving, the callTransferSetup result shall be conveyed in a PROGRESS message. 6.7.1.2
Tr a n s f e r wit h in t h e n o n - I S D N When User A is in the non-ISDN, call transfer is performed within that network. When the non-ISDN is able to provide indications of call transfer, the Gateway PINX shall forward indications received, representing events like "call transferred, active" or "call transferred, alerting", to the other End PINX in a callTransferComplete invoke APDU within a FACILITY message. Element endDesignation in the invoke APDU shall be coded primaryEnd, except when the call to which call transfer applies is an incoming call from the non-ISDN that has not yet reached the Active state, in which case element endDesignation shall be coded secondaryEnd. Inclusion of other data elements, such as redirection number, name, is dependent on information received from the nonISDN. On receipt of a FACILITY message from the other End PINX containing a subaddressTransfer invoke APDU with data element connectedSubaddress, the Gateway PINX shall forward the subaddress information to the non-ISDN if the signalling system allows. When subaddress information is received from the non-ISDN, this information shall be forwarded to the other End PINX as data element connectedSubaddress in a subaddressTransfer invoke APDU within a FACILITY message.
6.7.1.3
6.7.2
Cooperation with a non-ISDN in providing transfer by rerouteing When interworking with another network which supports transfer by rerouteing and if the PINX's also support transfer by rerouteing, the two networks may cooperate in the operation of transfer by rerouteing. A c t io n s a t o t h e r t y p e s o f P I N X The procedures of 6.5 shall apply. Additional protocol control states are valid for a Transferring PINX if User C is a User in a non-ISDN. Then call transfer procedures may also be started from states Outgoing Call Proceeding or Overlap Sending. From the perspective of the Transferring PINX, User C shall only qualify as a user in a nonISDN if a Progress indicator information element with CCITT progress description "interworking with a non-ISDN (no. 1)" has been received in an appropriate message from the Secondary PINX during Secondary Call setup. Additional procedures are valid for a Primary PINX if User C is a user in a non-ISDN and transfer by rerouteing procedures have been initiated: On receipt in state CT-Await-Setup-Response of a PROGRESS message (using the call reference of the new connection) containing a callTransferSetup return result APDU, the Primary PINX shall proceed as if the APDU had been received in an ALERTING message, and enter state CT-Await-Connect.
6.8
Protocol Interactions between SS-CT and other supplementary services and ANFs This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had been published at the time of publication of this Standard. For interactions with supplementary services and ANFs for which stage 3 standards are published subsequent to the publication of this Standard, see those other stage 3 standards. NOTE 1 Simultaneous conveyance of APDUs for SS-CC and another supplementary service or ANF in the same message, each in accordance with the requirements of its respective stage 3 standard, does not, on its own, constitute a protocol interaction. NOTE 2 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications.
- 20 -
6.8.1
Calling Name Identification Presentation (SS-CNIP) Protocol interactions are specified in 6.5.
6.8.2
Connected Name Identification Presentation (SS-CONP) Protocol interactions are specified in 6.5.
6.8.3
Completion of Calls to Busy Subscribers (SS-CCBS) No protocol interaction.
6.8.4
Completion of Calls on No Reply (SS-CCNR) No protocol interaction.
6.8.5
C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) The following interaction shall apply if SS-CFU is supported in accordance with ECMA-174.
6.8.5.1
Actions at a Transferring PINX for join In state CT-Await-Answer-From-User-C the Transferring PINX shall convey any received divertingLegInformation1 invoke APDU or divertingLegInformation3 invoke APDU from the Secondary PINX to the Primary PINX. In state CT-Await-Answer-From-User-C, on receipt of a callRerouting invoke APDU from the Secondary PINX, the Transferring PINX shall act as the Rerouteing PINX. Any divertingLegInformation1 invoke APDUs or divertingLegInformation3 invoke APDUs generated in accordance with Rerouteing PINX procedures shall be sent to the Primary PINX. When the Transferring PINX enters state CT-Await-Answer-From-User-C, if the transferring PINX had previously received one or more divertingLegInformation1 invoke APDUs (i.e., the PINX was in state CDO-Divert) from the direction of the Secondary PINX or from the Rerouteing PINX, the Transferring PINX shall send a divertingLegInformation1 invoke APDU to the Primary PINX together with the callTransferComplete invoke APDU. The divertingLegInformation1 invoke APDU shall be coded as follows: •
diversionReason (based on the diversion reason of the last divertingLegInformation1 invoke APDU received)
•
subscription option (based on the most restrictive subscription option received in any of the divertingLegInformation1 invoke APDUs)
•
nominatedNr (based on the nominated number of the last divertingLegInformation1 invoke APDU received).
If the Transferring PINX receives a divertingLegInformation3 invoke APDU in an ALERTING message and the Transferring PINX has not yet sent callTransferComplete invoke APDU to the Primary PINX, then the Transferring PINX shall first send a divertingLegInformation1 invoke APDU to the Primary PINX together with the callTransferComplete invoke APDU and then relay the divertingLegInformation3 invoke APDU in a FACILITY message. 6.8.6 6.8.6.1 6.8.7
C a ll F o r wa r d in g Bu s y ( S S - C F B) The following interaction shall apply if SS-CFB is supported in accordance with ECMA-174. Actions at a Transferring PINX for join Protocol interactions are specified in 6.8.5.1. C a l l F o r wa r d i n g N o R e p l y ( S S - C F N R ) The following protocol interactions shall apply if SS-CFNR is supported in accordance with ECMA-174.
- 21 -
NOTE If SS-CFNR is invoked for an unanswered, transferred call, either the Transferring PINX acts as Rerouteing PINX (call transfer by join and call forwarding by rerouteing) or the Primary PINX acts as Rerouteing PINX (call transfer by rerouteing and call forwarding by rerouteing) or the Secondary PINX acts as Rerouteing PINX (call forwarding by forward switching). 6.8.7.1
A c t i o n s a t a T r a n s f e r r i n g P I N X f or r e r o u t e i n g a n d S S - C F N R O r i g i n a t i n g P I N X On receipt of a callRerouting invoke APDU after initiating call transfer by rerouteing, the Transferring PINX shall send a callRerouting return error APDU containing error value supplementaryServicelnteractionNotAllowed to the SS-CFNR Served User PINX. The Transferring PINX shall not pass on a received divertingLeglnformationl invoke APDU and divertingLeglnforrnation3 invoke APDU after initiating call transfer by rerouteing.
6.8.7.2
Actions at a Transferring PINX for join or rerouteing and SS-CFNR Originating PINX The Transferring PINX shall not initiate signalling for SS-CT while performing call forwarding by rerouteing and prior to clearing either the call to the diverting user or the call to the diverted-to user.
6.8.7.3
Actions at a Secondary PINX for rerouteing and SS-CFNR Served User PINX On receipt of a callTransferldentify invoke APDU after initiating call forwarding by rerouteing, the SS-CFNR Served User PINX shall send a callTransferldentify return error APDU containing error value supplementaryServicelnteractionNotAllowed to the Transferring PINX. SS-CFNR shall not be initiated while the Secondary PINX is involved in transfer by rerouteing.
6.8.7.4
Actions at a Secondary PINX for rerouteing and SS-CFNR Served User and Rerouteing PINX On receipt of a callTransferldentify invoke APDU after initiating call forwarding by forward switching and before a divertingLeglnforrnation1 invoke APDU has been sent, the SS-CFNR Rerouteing PINX shall send a callTransferldentify return error APDU containing error value supplementaryServicelnteractionNotAllowed to the Transferring PINX.
6.8.7.5
A c t io n s a t a S e c o n d a r y P I N X f o r j o i n a n d S S - C F N R S e r v e d U s e r a n d R e r o u t e i n g PINX On receipt of a callTransferComplete, callTransferUpdate or subaddressTransfer invoke APDU after initiating call forwarding by forward switching, the SS - CFNR Rerouteing PINX shall not pass on the APDU to the Diverted-to PINX while the SS-CFNR rerouteing procedure is in progress. After receipt of an ALERTING or CONNECT message from the Diverted-to PINX and if the diverting user has not already answered the call, the information received in callTransferComplete, callTransferUpdate or subaddressTransfer invoke APDUs shall be passed on to the Diverted-to PINX.
6.8.7.6
Actions at a Transferring PINX for join Protocol interactions are specified in 6.8.5.1.
6.8.7.7
A c t io n s a t a P r im a r y P I N X f o r j o in The actions at an Originating PINX in 6.5.1.1 of ECMA-174 and 6.5.1.2 of ECMA-174 shall apply also to the Primary PINX with the following exceptions:
6.8.8
-
The basic call protocol control state in which a divertingLegInformation1 invoke APDU or a divertingLegInformation3 invoke APDU can be received is "Active".
-
On receipt of a callTransferActive invoke APDU, the Primary PINX shall enter state CT-Idle.
Call Deflection (SS-CD) The protocol interactions with Call Deflection Immediate shall be as specified in 6.8.5 for interaction with SS-CFU. The protocol interactions with Call Deflection from Alert shall be as specified in 6.8.7 for interaction with SS-CFNR.
- 22 -
6.8.9
Path Replacement (ANF-PR) The following interaction shall apply if ANF-PR is supported in accordance with ECMA-176.
6.8.9.1 A c t io n s a t a n A N F - P R R e q u e s t in g P I N X 6 . 8 . 9 . 1 . 1 I n v o c a t io n o f C a ll t r a n s f e r For the purpose of the requirements below, the following events shall be considered as invocation of SS-CT: -
receipt of callTransferComplete invoke APDU;
-
receipt of callTransferIdentify invoke APDU;
-
receipt of callTransferInitiate invoke APDU;
-
invocation of Call Transfer by the local user.
SS-CT shall be allowed to proceed normally if invoked while the PINX is acting as a Requesting PINX for ANF-PR. If SS-CT is invoked while in ANF-PR state PR-Req-initiating or PR-ReqRejecting, all signalling for SS-CT shall occur on the old path. If SS-CT is invoked while in ANF-PR state PR-Req-Completing, all subsequent signalling for SS-CT shall be sent on the new path and received SS-CT signals shall be accepted from either path. A pathReplaceSetup invoke APDU shall be responded to with a return error APDU containing error temporarilyUnavailable if, since sending the pathReplacePropose invoke APDU, SS-CT has been invoked. NOTE This will prevent switching over to the new path, so that all signalling for SS-CT can take place on the old path without risk of loss during switch over. 6.8.9.1.2
I n it ia t io n o f A N F - P R d u r in g C a ll Tr a n s f e r ANF- PR shall not be initiated while the PINX is acting as a Transferring PINX, a Primary PINX or a Secondary PINX during SS-CT.
6.8.9.2 A c t io n s a t a n A N F - P R C o o p e r a t in g P I N X 6 . 8 . 9 . 2 . 1 I n v o c a t io n o f C a ll Tr a n s f e r On receipt of a callTransferComplete, callTransferIdentify or callTransferlnitiate invoke APDU while acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment or PR-Coop-Retain, SS-CT shall be allowed to proceed normally using the old path for further signalling, except that if the old path is released as a result of successful ANF-PR, signalling shall continue using the new path. NOTE The Requesting PINX will normally abandon ANF-PR by sending back a pathReplaceSetup return error APDU because SS-CT has been invoked. Therefore switch over to a new path will not normally occur. While acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Establishment, an SS-CT invocation request from the local user shall be treated in one of the following ways: -
reject the request for SS-CT; or
-
wait until ANF-PR is complete before processing the request for SS-CT; or
-
abort ANF-PR and proceed with SS-CT.
To abort ANF-PR while in state PR-Coop-Establishment, the Cooperating PINX shall send a DISCONNECT message using the call reference of the new connection, thereby initiating the clearing procedures of ECMA-143 for the new connection, send a pathReplacePropose return error APDU with error value supplementaryServiceInteractionNotAllowed using the call reference of the old connection, and enter state PR-Coop-Idle.
- 23 -
While acting as an ANF-PR Cooperating PINX in ANF-PR state PR-Coop-Retain, an SS-CT invocation request from the local user shall be treated in one of the following ways: • reject the request for SS-CT; or • wait until ANF-PR is complete before processing the request for SS-CT. 6.8.9.2.2
6.9
I n it ia t io n o f A N F - P R d u r in g C a ll Tr a n s f e r On receipt of a pathReplacePropose invoke APDU while acting as a Transferring PINX, a Primary PINX or a Secondary PINX during SS-CT, a pathReplacePropose return error APDU shall be sent. The error shall be temporarilyUnavailable.
SS-CT Parameter values (Timers) The following timers apply only to transfer by rerouteing.
6.9.1
Timer T1 Timer T1 shall operate at the Transferring PINX during state CT-Await-Identify-Response. Its purpose is to protect against the absence of a response to the callTransferIdentify invoke APDU. Timer T1 shall have a value not less than 10 seconds.
6.9.2
Timer T2 Timer T2 shall operate at the Secondary PINX during state CT-Await-Setup. Its purpose is to protect against failure of completion of the call transfer operation, i.e. failure to receive a callTransferSetup or callTransferAbandon invoke APDU. Timer T2 shall have a value not less than 50 seconds.
6.9.3
Timer T3 Timer T3 shall operate at the Transferring PINX during state CT-Await-Initiate-Response. Its purpose is to protect against the absence of a response to the callTransferInitiate invoke APDU. Timer T3 shall have a value not less than 50 seconds.
6.9.4
Timer T4 Timer T4 may optionally operate at the Primary PINX during state CT-Await-Setup-Response. Its purpose is to protect against failure to establish the new connection. NOTE Alternatively an implementation can rely on basic call timers for this protection. Timer T4 shall have a value not less than 40 seconds.
- 24 -
- 25 -
Annex A ( n o r ma tiv e )
Protocol Implementation Conformance Statement (PICS) proforma
A.1
Introduction The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use:
A.2
-
by the protocol implementor, as a check list to reduce the risk of failure to conform to the standard through oversight;
-
by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard's PICS proforma;
-
by the user or potential user of an implementation, as a basis for initially checking the possibility of interworking with another implementation. While interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICSs;
-
by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.
Instructions for completing the PICS proforma
A.2.1
General structure of the PICS proforma The PICS proforma is a fixed format questionnaire divided into subclauses each containing a group of individual items. Each item is identified by an item number, the name of the item (question to be answered), and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: m
mandatory (the capability is required for conformance to the protocol);
o
optional (the capability is not required for conformance to the protocol, but if the capability is implemented it is required for conformance to the protocol specifications);
o.<n>
optional, but support of at least one of the group of options labelled by the same numeral <n> is required;
x
prohibited;
c.<cond>
conditional requirement, depending on support for the item or items listed in condition <cond>;
<item>:m
simple conditional requirement, the capability being mandatory if item number <item> is supported, otherwise not applicable;
<item>:o
simple conditional requirement, the capability being optional if item number <item> is supported, otherwise not applicable;
Answers to the questionnaire items are to be provided either in the "Support" column, by simply marking an answer to indicate restricted choice (Yes) or (No), or in the "Not Applicable" column (N/A).
- 26 -
A.2.2
Additional information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS. It is not intended that a large quantity will be supplied, and a PICS can be considered complete without such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional information may be entered next to any answer in the questionnaire, and may be included in items of Exception information.
A.2.3
Exceptional information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer will be found in the support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this standard. A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.
- 27 -
A.3
PICS proforma for ECMA-178
A.3.1
Implementation identification Supplier Contact point for queries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification, e.g. name(s) and version(s) for machines and/or operating systems; system name(s)
Only the first three items are required for all implementations; other information may be completed as appropriate in meeting requirements for full identification. The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model).
A.3.2
Protocol summary Protocol version
1.0
Addenda implemented (if applicable) Amendments implemented Have any exception items been required (see A.2.3)?
Date of statement
No [ ]
Yes [ ]
(The answer Yes means that the implementation does not conform to this Standard)
- 28 -
A.3.3
General Item
A.3.4
Question/feature
References
Status
N/A
Support
A1
Support of SS-CT by join
m
Yes [ ]
A2
Support of SS-CT by rerouteing
o
Yes [ ] No [ ]
Procedures for SS-CT-Join Item
Question/feature
Reference
Status
N/A
Support
B1
Support of relevant ECMA-143 and ECMA-165 procedures
6.2
m
Yes [ ]
B2
Signalling procedures at a Transferring PINX
6.5.1.1, 6.5.1.2
m
Yes [ ]
B3
Signalling procedures at a Transferring PINX for interworking with a non-ISDN
6.7.2
m
Yes [ ]
B4
Signalling procedures at a Primary PINX
6.5.2.1, 6.5.2.2, 6.5.5
m
Yes [ ]
B5
Signalling procedures at a Secondary PINX 6.5.3.1, 6.5.3.2, 6.5.5
m
Yes [ ]
B6
Behaviour as Gateway PINX to a public ISDN to support transfer of users in the ISDN by a user in the PISN
6.6.1.1
o
Yes [ ] No [ ]
B7
Behaviour as Gateway PINX to a public ISDN to support transfer of users in the PISN by a user in the ISDN
6.6.1.2
o
Yes [ ] No [ ]
B8
Behaviour as Gateway PINX to a nonISDN to support transfer of users in the other network by a user in the PISN
6.7.1.1
o
Yes [ ] No [ ]
B9
Behaviour as Gateway PINX to a nonISDN to support transfer of users in the PISN by a user in the other network
6.7.1.2
o
Yes [ ] No [ ]
- 29 -
A.3.5
Additional procedures for SS-CT-Rerouteing Item
Name of Item
Reference
Status
N/A
Support
C1
Signalling procedures at a Transferring PINX
6.5.1.3, 6.5.1.4
A2:m
[]
m: Yes [ ]
C2
Signalling procedures at a Primary PINX
6.5.2.3, 6.5.2.4, 6.5.5
A2:m
[]
m: Yes [ ]
C3
Signalling procedures at a Secondary PINX 6.5.3.3, 6.5.3.4, 6.5.5
A2:m
[]
m: Yes [ ]
C4
Behaviour as Gateway PINX to a public ISDN to support transfer of users in the ISDN by a user in the PISN (using transfer by rerouteing in the PISN)
6.6.1.1
o
Yes [ ] No [ ]
C5
Behaviour as Gateway PINX to a nonISDN to support transfer of users in the other network by a user in the PISN (using transfer by rerouteing procedures)
6.7.1.1
o
Yes [ ] No [ ]
C6
Behaviour as Gateway PINX to a nonISDN to support transfer of users in the PISN by a user in the other network (using transfer by rerouteing procedures)
6.7.1.3
o
Yes [ ] No [ ]
- 30 -
A.3.6
Coding Item
Name of Item
Reference
Status
N/A
Support
D1
Sending of callTransferComplete invoke APDU
6.3
m
Yes [ ]
D2
Sending of callTransferActive invoke APDU
6.3
m
Yes [ ]
D3
Receipt of callTransferComplete invoke APDU
6.3
m
Yes [ ]
D4
Receipt of callTransferActive invoke APDU
6.3
m
Yes [ ]
D5
Sending of callTransferUpdate invoke APDU
6.3
o
Yes [ ] No [ ]
D6
Receipt of callTransferUpdate invoke APDU
6.3
m
Yes [ ]
D7
Sending of subaddressTransfer invoke APDU
6.3
o
Yes [ ] No [ ]
D8
Receipt of subaddressTransfer invoke APDU
6.3
m
Yes [ ]
D9
Sending of callTransferIdentify invoke APDU and receipt of return result and return error APDUs
6.3
A2:m
[]
m: Yes [ ]
D10
Sending of callTransferInitiate invoke APDU and receipt of return result and return error APDUs
6.3
A2:m
[]
m: Yes [ ]
D11
Sending of callTransferSetup invoke APDU and receipt of return result and return error APDUs
6.3
A2:m
[]
m: Yes [ ]
D12
Receipt of callTransferIdentify invoke APDU and sending of return result and return error APDUs
6.3
A2:m
[]
m: Yes [ ]
D13
Receipt of callTransferInitiate invoke APDU and sending of return result and return error APDUs
6.3
A2:m
[]
m: Yes [ ]
D14
Receipt of callTransferSetup invoke ADPU and sending of return result and return error APDUs
6.3
A2:m
[]
m: Yes [ ]
D15
Sending of callTransferAbandon invoke APDU
6.3
A2:m
[]
m: Yes [ ]
D16
Receipt of callTransferAbandon invoke APDU
6.3
A2:m
[]
m: Yes [ ]
- 31 -
A.3.7
Interactions between SS-CT and SS-CFNR/SS-CD Item
Question/feature
Reference
Status
N/A
Support
E1
Support of SS-CFNR or SS-CDA
o
Yes [ ] No [ ]
E2
Support of SS-CFNR or SS-CDA at an Originating PINX
o
Yes [ ] No [ ]
E3
Support of SS-CFNR or SS-CDA at an SS-CFNR/SS-CDA Served User PINX
o
Yes [ ] No [ ]
E4
Support of SS-CFNR or SS-CDA by forward switching at an SS-CFNR/SS-CDA Served User PINX
E3:o
[]
o: Yes [ ] No [ ]
E5
Actions at a Transferring PINX for rerouteing and SS-CFNR/SS-CDA Originating PINX
6.8.7.1
c.1
[]
m: Yes [ ]
E6
Actions at a Transferring PINX for join or rerouteing and SS-CFNR/SS-CDA Originating PINX
6.8.7.2
E2:m
[]
m: Yes [ ]
E7
Actions at a Secondary PINX for rerouteing and SS-CFNR/SS-CDA Served User PINX
6.8.7.3
c.2
[]
m: Yes [ ]
E8
Actions at a Secondary PINX for rerouteing and SS-CFNR/SS-CDA Served User / Rerouteing PINX
6.8.7.4
c.3
[]
m: Yes [ ]
E9
Actions at a Secondary PINX for join and SS-CFNR/SS-CDA Served User / Rerouteing PINX
6.8.7.5
E4:m
[]
m: Yes [ ]
E10
Actions at a Transferring PINX for join
6.8.7.6
E1:m
[]
m: Yes [ ]
E11
Actions at a Primary PINX for join
6.8.7.7
E1:m
[]
m: Yes [ ]
Status
N/A
Support
c.1: if A2 and E2 then mandatory, else N/A c.2: if A2 and E3 then mandatory, else N/A c.3: if A2 and E4 then mandatory, else N/A
A.3.8
Interactions between SS-CT and ANF-PR Item
Question/feature
Reference
F1
Support of ANF-PR at a Requesting PINX
o
Yes [ ] No [ ]
F2
Support of ANF-PR at a Cooperating PINX
o
Yes [ ] No [ ]
F3
Interactions between SS-CT and ANFPR at an ANF-PR Requesting PINX
6.8.9.1
F1:m
[]
m: Yes [ ]
F4
Interactions between SS-CT and ANFPR at an ANF-PR Cooperating PINX
6.8.9.2
F2:m
[]
m: Yes [ ]
- 32 -
A.3.9
Timers Item
Name of Item
Reference
Status
N/A
Support
G1
Support of timer T1
6.8.1
A2:m
[]
m: Yes [ ]
G2
Support of timer T2
6.8.2
A2:m
[]
m: Yes [ ]
G3
Support of timer T3
6.8.3
A2:m
[]
m: Yes [ ]
G4
Support of timer T4
6.8.4
A2:o
[]
o: Yes [ ] No [ ]
Status
N/A
Support
A.3.10 Interactions between SS-CT and SS-CFU/SS-CDI Item
Question/feature
H1
Support of SS-CFU or SS-CDI
H2
Actions at a Transferring PINX for join
Reference
o 6.8.5.1
Yes [ ] No [ ]
H1:m
[]
m: Yes [ ]
Status
N/A
Support
A.3.11 Interactions between SS-CT and SS-CFB Item
Question/feature
I1
Support of SS-CFB
I2
Actions at a Transferring PINX for join
Reference
o 6.8.6.1
I1:m
Yes [ ] No [ ] []
m: Yes [ ]
- 33 -
Annex B ( in f o r ma tiv e )
Imported ASN.1 definitions
The content of this annex has been deleted to remove duplicate ASN.1 definitions defined elsewhere.
- 34 -
- 35 -
Annex C ( in f o r ma tiv e )
Examples of message sequences
This annex describes some typical message flows for SS-CT. The following conventions are used in the figures of this annex: 1
The following notation is used: Protocol message Service primitive to / from user
xxx.inv
Invoke APDU for operation xxx
xxx.rr
Return result APDU for operation xxx
xxx.re
Return error APDU for operation xxx
2
The figures show messages exchanged via Protocol Control between PINXs involved in SS-CT. Only messages relevant to SS-CT are shown.
3
Only the relevant information content (i.e. remote operation APDUs) is listed below each message name. The Facility information elements containing remote operation APDUs are not explicitly shown. Information with no impact on SS-CT is not shown.
4
The following abbreviations are used: ctIdentify
callTransferIdentify
ctInitiate
callTransferInitiate
ctSetup
callTransferSetup
ctAbandon
callTransferAbandon
ctActive
callTransferActive
ctComplete
callTransferComplete
ctUpdate
callTransferUpdate
subAdrTfr
subaddressTransfer
ctInvoke
Call Transfer Invoke
ctNotify
Call Transfer Notify
- 36 -
C.1
Example message sequence for normal operations of call transfer by join, both calls active Figure C.1 shows an example of a normal operation of transfer by join when both calls are in state Active.
User B
Primary PINX
Primary Call
Transferring PINX
Active Basic Call User A
ctNotify indication
Secondary Call
Secondary PINX
User C
Active Basic Call ctInvoke request FACILITY ctComplete.inv
FACILITY ctComplete.inv
ctNotify indication
Transit PINX
Joined Call
Joined Call
Active Basic Call FACIL ITY ctUpd ate.in v
subAdrTfr request
ctNotify indication subAdrTfr indication
LITY FACI v ate.in ctUpd
FACILIT Y subAdrT fr.inv Y LIT CI e.inv A F at pd ctU Y v LIT CI fr.in A T F r d bA su
LITY FACI inv drTfr. subA FA ctU CILI T pd a te Y . inv F su ACIL bA drT ITY fr . i nv
subAdrTfr request
ctNotify indication
subAdrTfr indication
Active Basic Call
Figure C.1 - Message sequence for normal operation of SS-CT by join, both calls are Active
- 37 -
C.2
Example message sequence for call transfer by join, one call alerting Figure C.2 shows an example of a normal operation of transfer by join when one call is active and the other is alerting.
User B
Primary PINX
Primary Call
Transferring PINX
Active Basic Call User A
ctNotify indication
Secondary PINX
Alerting Basic Call
FACILITY ctComplete.inv
FACILITY ctComplete.inv
ctNotify indication
FACI LITY subA drTfr .inv
LITY FACI v ate.in ctUpd
ITY CIL .inv A F te pda ct U
FA ctU CILIT pd ate Y .inv
ctNotify indication
FA sub CILIT Y Ad rTf r.in v
CONNECT
ctNotify indication
User C
ctInvoke request
FACIL ITY ctUpd ate.in v
subAdrTfr request
Secondary Call
FACILITY ctActive.inv
Joined Call
ctNotify indication subAdrTfr indication Setup response
CONNECT ACKNOWLEDGE
Transit PINX
Joined Call
Active Basic Call
Figure C.2 - Message sequence for normal operation of SS-CT by join, one call is Active and the other is Alerting
- 38 -
C.3
Example message rerouteing
sequence
for
normal
operation
of
call
transfer
by
Figure C.3 shows an example of a normal operation of transfer by rerouteing when the two calls involved in the call transfer operation are both in the Active state.
User B
Primary PINX
Primary Call
Transferring PINX
Secondary Call
Active Basic Call User A
Secondary PINX
User C
Active Basic Call
ctInvoke request FACILITY ctIdentify.inv
FACILITY ctInitiate.inv
New connection
FACILITY ctIdentify.rr
Transit New connection PINX
Basic Call being set up SETUP ctSetup.inv ctUpdate.inv
SETUP ctSetup.inv ctUpdate.inv
CALL PROCEEDING CALL PROCEEDING
Figure C.3 (sheet 1 of 2) - Message sequence for Call Transfer by rerouteing, both calls are Active
- 39 -
Primary PINX
User B
New connection
Transit New connection Secondary PINX PINX CONNECT ctSetup.rr ctUpdate.inv
CONNECT ctSetup.rr ctUpdate.inv
ctNotify indication
CONNECT ACKNOWLEDGE
primary Call
User C
ctNotify indication
CONNECT ACKNOWLEDGE
Transferring PINX
Secondary Call
Active Basic Call
Active Basic Call DISCONNECT RELEASE
DISCONNECT ctInitiate res.
RELEASE COMPLETE
RELEASE
RELEASE COMPLETE
User A
ctInvoke confirm New connection
Transit PINX
New connection
Basic Call subAdrTfr request
subAdrTfr indication
LITY FACI inv drTfr. subA
FAC ILIT sub Y Adr Tfr. inv Y ILIT FAC fr.inv AdrT sub
FAC ILIT sub Y Adr Tfr. inv
subAdrTfr request
subAdrTfr indication
Active Basic Call
Figure C.3 (sheet 2 of 2) - Message sequence for Call Transfer by rerouteing, both calls are Active
- 40 -
C.4
Example message sequence for normal operation of call transfer by rerouteing, one call alerting Figure C.4 shows an example of a normal operation of transfer by rerouteing when one call is in the Active state and the other is alerting.
User B
Primary PINX
Primary Call
Transferring PINX
Secondary Call
Active Basic Call User A
Secondary PINX
User C
Alerting Basic Call
ctInvoke request FACILITY ctIdentify.inv
FACILITY ctInitiate.inv
New connection
FACILITY ctIdentify.rr
Transit PINX
New connection
Basic Call being set up
SETUP ctSetup.inv ctUpdate.inv
SETUP ctSetup.inv ctUpdate.inv
CALL PROCEEDING CALL PROCEEDING
Figure C.4 (sheet 1 of 2) - Message sequence for Call Transfer by rerouteing, one call Active and one Alerting
- 41 -
Primary PINX
User B
New connection
Secondary Transit New connection PINX PINX ALERTING ctSetup.rr ctUpdate.inv
ALERTING ctSetup.rr ctUpdate.inv
ctNotify indication
Primary Call
Transferring PINX
User C
ctNotify indication
Secondary Call
Active Basic Call
Alerting Basic Call DISCONNECT RELEASE
DISCONNECT ctInitiate.rr
RELEASE COMPLETE
RELEASE
RELEASE COMPLETE
User A
ctInvoke confirm New connection
New connection
Alerting Basic Call
Active Basic Call subAdrTfr request
Transit PINX
FACILIT Y subAdrT fr.inv
FACI LITY subA drTfr. inv
CONNECT ctUpdate.inv
CONNECT ctUpdate.inv
subAdrTfr indication Setup response
CONNECT ACKNOWLEDGE
ctNotify indication
CONNECT ACKNOWLEDGE Active Basic Call
Figure C.4 (sheet 2 of 2) - Message Sequence for Call Transfer by rerouteing, one call is Active, one Alerting
- 42 -
- 43 -
Annex D ( in f o r ma tiv e )
Specification and Description Language (SDL) representation of procedures
The diagrams in this annex use the Specification and Description Language defined in ITU-T Rec. Z.100. Each diagram represents the behaviour of a SS-CT Supplementary Service Control entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Supplementary Service Control entity uses, via the Coordination Function, the services of Generic Functional Transport Control and Basic Call Control. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a PSS1 message being sent, the output symbol bears the name of the message and any remote operation APDU(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the sending of that message are deemed to occur. Where an input symbol represents a primitive from the Coordination Function, and that primitive results from a PSS1 message being received, the input symbol bears the name of the message and any remote operation APDU(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the receiving of that message are deemed to occur. The following abbreviations are used: err.
return error APDU
ind.
indication
inv.
invoke APDU
opt.
optional
rcvd
received
rej.
reject APDU
res.
return result APDU
ctIdentify
callTransferIdentify
ctInitiate
callTransferInitiate
ctSetup
callTransferSetup
ctAbandon
callTransferAbandon
ctActive
callTransferActive
ctComplete
callTransferComplete
ctUpdate
callTransferUpdate
subAdrTfr
subaddressTransfer
- 44 -
D.1
SDL Representation of SS-CT at a Transferring PINX Figure D.1 shows the behaviour of a SS-CT Supplementary Service Control entity within a Transferring PINX. Input signals from the right and output signals to the right represent primitives to and from the Coordination Functions in respect of the messages being sent and received. Input signals from the left and output signals to the left represent stimuli between the SS-CT Supplementary Service Control entity and the SS-CT user. CT-Idle Call transfer invoke from User A
B CONNECT received from direction of Secondary PINX
Identify calls
No
CT-Await-AnswerFrom-User-C
A
Transfer allowed?
Send FACILITY ctActive inv. in direction of Primary PINX
Yes Rerouteing ?
Call cleared from either end
Yes
No Call transfer invoke rej. to User A
Call transfer invoke res. to User A
Send FACILITY ctIdentify inv. on Secondary Call
Disconnect Primary and Secondary Call parts to User A, join Users B &C parts
Start T1
Send FACILITY ctComplete inv. on Primary Call Send FACILITY ctComplete inv. on Secondary Call
No
CT-Idle
Alerting ind. in ctComplete inv. sent on Secondary Call ?
Yes
CT-Await-AnswerFrom-User-C
CT-AwaitIdentify-Response
Figure D.1 (sheet 1 of 4) - Transferring PINX SDL
CT-Idle
- 45 -
B
FACILITY received with ctUpdate inv. or subAdrTfr inv. on Primary or Secondary Call
NOTIFY received on Primary or Secondary Call
send FACILITY conveying the invoke APDU on the other call
Send NOTIFY on the other call
CT-Await-AnswerFrom-User-C
Figure D.1 (sheet 2 of 4) - Transferring PINX SDL
- 46 -
CT-AwaitIdentify-Response
FACILITY received ctIdentify res. on Secondary Call
Stop T1
FACILITY send ctIdentify rej. or ctIdentify err. on Secondary Call
T1 Expiry
Primary or Secondary Call cleared
Send FACILITY or ctAbandon inv. on Secondary Call
Stop T1
Stop T1
Yes Do join? No
Send FACILITY ctIinitiate inv. on Primary Call
Clear other call
Start T3
Indicate call transfer invoke reject to User A
CT-Await-InitiateResponse
CT-Idle
Indicate call transfer invoke result to User A
A
Figure D.1 (sheet 3 of 4) - Transferring PINX SDL
CT-Idle
- 47 -
CT-AwaitInitiate-Response
Primary or Secondary call cleared
DISCONNECT received ctInitiate res. on Primary Call
FACILITY received ctIinitiate rej. or ctInitiate err. on Primary Call
Stop T3
Stop T3
Stop T3
Clear other call
Clear Secondary Call if not yet cleared
Send FACILITY ctAbandon inv. on Secondary Call (if not cleared)
T3 Expiry
Yes Do join? No
Indicate call transfer invoke result to User A
Indicate call transfer invoke reject to User A
CT-Idle
Figure D.1 (sheet 4 of 4) - Transferring PINX SDL
A
- 48 -
D.2
SDL Representation of SS-CT at a Primary PINX Figure D.2 shows the behaviour of a SS-CT Supplementary Service Control entity within a Primary PINX. Input signals from the left and output signals to the left represent primitives to and from the Coordination Function in respect of messages sent and received. Input signals from the right and output signals to the right represent stimuli between the SS-CT Supplementary Service Control entity and the transferred User. CT-Idle
FACILITY received ctComplete inv.
FACILITY received ctUpdate inv.
FACILITY received subAdrTfr inv.
Notify User B
Notify User B
Notify subaddress to User B Send FACILITY subAdrTfr inv.
Send FACILITY ctUpdate inv.
FACILITY received ctInitiate inv.
Participate?
Subaddress from User B
FACILITY received ctActive inv.
No
Yes send SETUP ctSetup inv. + ctUpdate inv. on new connection
Send FACILITY ctInitia te err
Notify User B
Start T4 (optional)
CT-Await-SetupResponse
CT-Idle
F ig u r e D . 2 ( s h e e t 1 o f 2 ) - P r im a r y P I N X S D L
- 49 -
CT-Await-SetupResponse ALERTING rcvd ctSetup res and opt. ctUpdate inv. on new connection
CONNECT rcvd ctSetup res. and opt. ctUpdate inv. on new connection Stop T4 Disconnect old and connect new connection send DISCONNECT ctInitiate res on old connection
New connection failed
T4 Expiry
Stop T4
Stop T4
Proceed with clearing of new connection
Send FACILITY ctInitiate err.
Clear new connection
Notify User B
User C in active state?
Primary Call cleared
Yes
No CT-AwaitConnect CONNECT rcvd with ctSetup res. and optionally ctUpdate inv.
CT-Idle
Call cleared
Notify User B
CT-Idle
F ig u r e D . 2 ( s h e e t 2 o f 2 ) - P r im a r y P I N X S D L
CT-Idle
- 50 -
D.3
SDL Representation of SS-CT at a Secondary PINX Figure D.3 shows the behaviour of a SS-CT Supplementary Service Control entity within a Secondary PINX. Input signals from the left and output signals to the left represent primitives to and from the Coordination Functions in respect of messages sent and received. Input signals from the right and output signals to the right represent stimuli between the SS-CT Supplementary Service Control entity and the transferred User.
CT-Idle
FACILITY received ctIdentify inv.
Participate?
FACILITY received ctUpdate inv.
FACILITY received ctComplete inv.
FA CIL ITY received subAdrTfr inv.
Notify User C
Notify User C
Notify suba ddress to User C
Subaddress received from Use r C
No
Yes Send FACILITY ctIdentify res.
Send FACILITY ctIdentify err.
Send FACILITY ctUpdate inv.
Send FACILITY subAdrTfr inv.
Start T2
CT-Await-Setup
CT-Idle
Figure D.3 (sheet 1 of 2) - Secondary PINX SDL
- 51 -
CT-Await-Setup
ctSetup inv. contains matching call identity and rerouting number
SETUP received ctSetup inv. and optionally ctUpdate inv. on new connection
FACILITY received ctAbandon inv. secondary call
T2 Expiry
Secondary Call cleared
Disconnect old connection, connect with new
Initiate clearing of old connection
Abort call transfer
Stop T2
Stop T2
Notify User C
User C in active state?
No
Yes Send CONNECT ctSetup res. with opt. ctUpdate inv.
Send ALERTING ctSetup res. with opt. ctUpdate inv.
CT-Idle
Figure D.3 (sheet 2 of 2) - Secondary PINX SDL
Abort call transfer
- 52 -
- 53 -
Annex E ( in f o r ma tiv e )
Bibliography
ITU-T Rec. Q.952.7 Stage 3 description for Explicit Call Transfer supplementary service using DSS1
- 54 -
- 55 -
Annex F ( n o r ma tiv e )
ASN.1 definitions according to ITU-T Recs. X.208 / X.209
This annex lists all ASN.1 modules as they were defined in the second edition of ECMA-178, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the third edition the ASN.1 modules within ECMA-178 comply with ITU-T Recommendations X.680 / X.690. Please note that regardless of which version of these modules is used as a base of a QSIG implementation, the line encoding remains unchanged. Changes in future editions to modules based on X.680 / X.690 ASN.1 are not reflected in the modules in this annex. Ta b le F . 1 - C a ll- Tr a n s f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Call-Transfer-Operations {iso(1) standard(0) pss1-call-transfer(13869) call-transfer-operations (0)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS OPERATION, ERROR FROM Remote-Operation-Notation {joint-iso-ccitt(2) remote-operations(4) notation(0)} Extension FROM Manufacturer-specific-service-extension-definition {iso(1) standard(0) pss1-generic-procedures (11582) msi-definition(0)} Name FROM Name-Operations {iso(1) standard(0) pss1-name (13868) name-operations (0)} supplementaryServiceInteractionNotAllowed, notAvailable, invalidCallState FROM General-Error-List {ccitt (0) recommendation (0) q 950 general-error-list (1)} PresentedAddressScreened, PresentedNumberScreened, PartyNumber, PartySubaddress FROM Addressing-Data-Elements {iso(1) standard (0) pss1-generic-procedures (11582) addressing-dataelements (9)} PSS1InformationElement FROM PSS1-generic-parameters-definition { iso(1) standard (0) pss1-generic-procedures (11582) pss1-generic-parameters (6)};
- 56 -
Ta b le F . 1 - C a ll- Tr a n s f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) -- TYPE DEFINITIONS FOR CT OPERATIONS FOLLOW CallTransferIdentify ::=
OPERATION ARGUMENT DummyArg RESULT CTIdentifyRes ERRORS{ notAvailable, invalidCallState, unspecified, supplementaryServiceInteractionNotAllowed }
CallTransferAbandon ::= OPERATION ARGUMENT DummyArg CallTransferInitiate ::=
OPERATION ARGUMENT CTInitiateArg RESULT DummyRes ERRORS{ notAvailable, invalidCallState, invalidRerouteingNumber, unrecognizedCallIdentity, establishmentFailure, unspecified, supplementaryServiceInteractionNotAllowed }
CallTransferSetup ::=
OPERATION ARGUMENT CTSetupArg RESULT DummyRes ERRORS{ notAvailable, invalidCallState, invalidRerouteingNumber, unrecognizedCallIdentity, unspecified, supplementaryServiceInteractionNotAllowed }
- 57 -
Ta b le F . 1 - C a ll- Tr a n s f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) CallTransferActive ::=
OPERATION ARGUMENT CTActiveArg
CallTransferComplete ::= OPERATION ARGUMENT CTCompleteArg CallTransferUpdate ::=
SubaddressTransfer ::=
OPERATION ARGUMENT CTUpdateArg OPERATION ARGUMENT SubaddressTransferArg
-- TYPE DEFINITIONS FOR CT DATA TYPES FOLLOW DummyArg ::= CHOICE { NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension } DummyRes ::= CHOICE { NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension } CTIdentifyRes ::= SEQUENCE { callIdentity rerouteingNumber resultExtension
CallIdentity, PartyNumber, CHOICE { [6] IMPLICIT Extension, [7] IMPLICIT SEQUENCE OF Extension } OPTIONAL
} CTInitiateArg ::= SEQUENCE { callIdentity rerouteingNumber argumentExtension
}
CallIdentity, PartyNumber, CHOICE { [6] IMPLICIT Extension, [7] IMPLICIT SEQUENCE OF Extension } OPTIONAL
- 58 -
Ta b le F . 1 - C a ll- Tr a n s f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) CTSetupArg ::= SEQUENCE { callIdentity argumentExtension
CallIdentity, CHOICE { [0] IMPLICIT Extension, [1] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
} CTActiveArg ::= SEQUENCE{ connectedAddress basicCallInfoElements
connectedName argumentExtension
PresentedAddressScreened, PSS1InformationElement OPTIONAL, -- ISO/IEC 11572 information elements Party -- category and Progress indicator are conveyed Name OPTIONAL, CHOICE { [9] IMPLICIT Extension, [10] IMPLICIT SEQUENCE OF Extension } OPTIONAL
} CTCompleteArg ::= SEQUENCE { endDesignation redirectionNumber basicCallInfoElements
redirectionName callStatus argumentExtension
EndDesignation, PresentedNumberScreened, PSS1InformationElement OPTIONAL, -- ISO/IEC 11572 information elements Party -- category and Progress indicator are conveyed Name OPTIONAL, CallStatus DEFAULT answered, CHOICE { [9] IMPLICIT Extension, [10] IMPLICIT SEQUENCE OF Extension } OPTIONAL
} CTUpdateArg ::= SEQUENCE { redirectionNumber redirectionName basicCallInfoElements
argumentExtension
}
PresentedNumberScreened, Name OPTIONAL, PSS1InformationElement OPTIONAL, -- ISO/IEC 11572 information elements Party -- category and Progress indicator are conveyed CHOICE { [9] IMPLICIT Extension, [10] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
- 59 -
Ta b le F . 1 - C a ll- Tr a n s f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) SubaddressTransferArg ::= SEQUENCE { redirectionSubaddress PartySubaddress, argumentExtension CHOICE { [0] IMPLICIT Extension, [1 ] IMPLICIT SEQUENCE OF Extension } OPTIONAL } CallStatus ::= ENUMERATED{ answered(0), alerting(1) } CallIdentity ::= NumericString (SIZE (1..4)) EndDesignation ::= ENUMERATED { primaryEnd(0), secondaryEnd(1) } -- TYPE DEFINITIONS FOR CT ERRORS FOLLOW Unspecified ::=
ERROR PARAMETER Extension
-- VALUE DEFINITIONS FOR OPERATIONS AND ERRORS FOLLOW unspecified
Unspecified
::= 1008
callTransferIdentify callTransferAbandon callTransferInitiate callTransferSetup callTransferActive callTransferComplete callTransferUpdate subaddressTransfer
CallTransferIdentify CallTransferAbandon CallTransferInitiate CallTransferSetup CallTransferActive CallTransferComplete CallTransferUpdate SubaddressTransfer
invalidRerouteingNumber
ERROR
::= 7 ::= 8 ::= 9 ::= 10 ::= 11 ::= 12 ::= 13 ::= 14
::= 1004 -- used when establishment of the new -- connection fails because -- the rerouteingNumber is not a valid -- PISN address
- 60 -
Ta b le F . 1 - C a ll- Tr a n s f e r - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n c lu d e d ) unrecognizedCallIdentity
ERROR
::= 1005 -- used when establishment of the new -- connection fails because it could not be -- associated with a SS-CT entity -- at the Secondary PINX
establishmentFailure
ERROR
::= 1006 -- used when establishment of the new -- connection fails and no other error applies -- of Call-Transfer-Operations
END
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.