S tandard ECMA-214
3rd Edition - December 2001
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Recall 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-214
3rd Edition - December 2001
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Recall Supplementary Service (QSIG-RE)
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
Ecma-214.doc
14-01-02 10,08
.
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 Recall 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-214 (published by ECMA in December 1994), the 2nd Edition incorporated changes in order to achieve complete alignment with International Standard ISO/IEC 15052:1997(E) published by ISO/IEC in May 1997. Compared to the 2nd Edition of Standard ECMA-214 (published by ECMA in June 1997), this 3rd Edition incorporates migration to ASN.1 version 1997.
Adopted as 3rd Edition of Standard ECMA-214 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 Served user, User A 4.2.2 Served User PINX
2 2 3 3 3
5
List of acronyms
3
6
Signalling protocol for the support of SS-RE 6 . 1 S S - RE d e s c r ip tio n 6 . 2 S S - RE 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 th e P r ima r y P I N X 6.2.3 Re q u ir e me n ts o n th e S e r v e d U s e r P I N X 6 . 3 S S - RE 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 - RE S ta te d e f in itio n s 6.4.1 States at the Served User PINX 6.4.2 S t a t e s a t t h e P r i ma r y P I N X 6 . 5 S S - RE s ig n a llin g p r o c e d u r e s 6.5.1 Actions at the Served User PINX 6.5.2 A c t i o n s a t t h e P r i ma r y P I N X 6 . 6 S S - RE I mp 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 . 7 S S - RE I mp a c t o f in te r w o r k in g w ith n o n - I S D N s 6 . 8 S S - R E P a r a me t e r v a l u e s ( T i me r s ) 6 . 9 P r o to c o l in te r a c tio n s b e tw e e n S S - RE 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.9.1 I n t e r a c t i o n w i t h 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.9.2 I n t e r a c t i o n w i t h C o n n e c t e d 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 O N P ) 6.9.3 I n t e r a c t i o n w i t h C a l l F o r w a r d in g U n c o n d i t i o n a l ( S S - C F U ) 6.9.4 I n t e r a c t i o n w i t h C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.9.5 I n t e r a c t i o n w i t h C a l l F o r w a r d in g N o R e p ly ( S S - C F N R ) 6.9.6 Interaction with Call Transfer (SS-CT) 6.9.7 I n t e r a c t i o n w i t h P a t h R e p l a c e me n t ( A N F - P R ) 6.9.8 I n t e r a c t i o n w i t h C a l l C o mp l e t i o n t o B u s y S u b s c r i b e r ( S S - C C B S ) 6.9.9 I n t e r a c t i o n w i t h C a l l C o mp l e t i o n o n N o R e p ly ( S S - C C N R )
3 3 3 3 3 3 4 4 5 5 5 5 5 5 6 6 6 6 7 7 7 7 7 7 7 8 8 8 8
- ii -
6.9.10 6.9.11 6.9.12 6.9.13 6.9.14 6.9.15
Interaction with Call Offer (SS-CO) Interaction with Do Not Disturb (SS-DND) I n t e r a c t i o n w i t h D o N o t D is t u r b O v e r r i d e ( S S - D N D O ) Interaction with Call Intrusion (SS-CI) I n te r a c tio n w ith A d v ic e o f Ch a r g e ( S S - A O C) Interactions with Call Interception delayed (ANF-CINT)
8 8 8 8 8 8
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
9
A n n e x B - Ex a m p le o f m e s s a g e s e q u e n c e s
15
A n n e x C - 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 g ua 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
17
A n n e x D - 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
21
1
Scope This Standard specifies the signalling protocol for the support of Recall supplementary service (SS-RE) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within Private Integrated Services Network (PISN). SS-RE is a supplementary service which provides for the re-direction of a transferred call back to the served user if the call is unanswered. SS-RE is only applicable after transfer by join, not after transfer by rerouteing. 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-213. The signalling protocol for SS-RE 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 SS-RE and other supplementary services and ANFs. However, the interaction with the Call Transfer supplementary service is specified as part of SS-RE signalling procedures as it is the essential aspect of the Recall supplementary service. NOTE Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. This Standard is applicable to PINXs which can be interconnected 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. Conformance to this Standard includes conforming to those clauses that specify protocol interactions between SS-RE and other supplementary services and ANFs for which signalling protocols at the Q reference point are supported in accordance with the stage 3 standards concerned.
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-164
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Name Identification Supplementary Services (International Standard ISO/IEC 13868)
- 2 -
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 - Inter-Exchange Signalling Protocol - Call Diversion Supplementary Services (International Standard ISO/IEC 13873)
ECMA-177
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Call Transfer Supplementary Service (International Standard ISO/IEC 13865)
ECMA-178
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Transfer Supplementary Services (International Standard ISO/IEC 13869)
ECMA-213
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Recall Supplementary Service (International Standard ISO/IEC 15051)
ECMA-221
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Interception Additional Network Feature (International Standard ISO/IEC 15054)
ETS 300 387
Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)
ITU-T Rec. I.112
Vocabulary of terms for ISDNs (1993)
ITU-T Rec. I.210
Principles of telecommunication services supported by an ISDN and the means to describe them (1993)
ITU-T Rec. Z.100 Specification and description language (1999)
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: − Application Protocol Data Unit
(ECMA-165)
− Basic Service
(ITU-T Rec. I.210)
− Call, Basic Call
(ECMA-165)
− End PINX
(ECMA-165)
− Gateway PINX
(ECMA-143)
− Integrated Services Digital Network
(ITU-T Rec. I.112)
− Interpretation APDU
(ECMA-165)
− Private Integrated Services Network (PISN)
(ECMA-133)
− Private Integrated services Network eXchange (PINX)
(ECMA-133)
− Primary Call
(ECMA-177)
− Primary PINX
(ECMA-178)
− Secondary Call
(ECMA-177)
− Secondary PINX
(ECMA-178)
− Signalling
(ITU-T Rec. I.112)
− Supplementary Service
(ITU-T Rec. I.210)
− Supplementary Service Control Entity
(ECMA-165)
- 3 -
4.2
− User
(ECMA-142)
− User B
(ECMA-177)
− User C
(ECMA-177)
Other definitions
4.2.1
Served user, User A The user of the Recall service located at the Served User PINX.
4.2.2
Served User PINX The End PINX which initiates the call transfer procedures on behalf of user A and which recalls user A in case the recall condition applies.
5
List of acronyms
6
APDU
Application Protocol Data Unit
ASN.1
Abstract Syntax Notation One
ISDN
Integrated Services Digital Network
NFE
Network Facility Extension
PICS
Protocol Implementation Conformance Statement
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
SDL
Specification and Description Language
SS-CT
Call Transfer supplementary service
SS-RE
Recall supplementary service
Signalling protocol for the support of SS-RE
6.1
SS-RE description When the served user has a call established with user B and transfers that call to user C SS-RE enables user B to be re-connected to the served user if user C is being alerted and does not reply within a specified time, or if the call is waiting at a busy user C and remains busy for a specified time.
6.2
SS-RE operational requirements
6.2.1
P r o v is io n /wit h d r a wa l SS-RE is provided or withdrawn after pre-arrangement with the service provider, or may be available generally to all users. SS-RE may be withdrawn on request of the user or for administrative reasons.
6.2.2
Requirements on the 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.3
Requirements on the Served User 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.
- 4 -
6.3 6.3.1
SS-RE coding requirements 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 D. Table 1 - Operations in Support of SS-RE
Recall-Operations-asn1-97 { iso (1) standard (0) pss1-recall (15052) recall-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) } PresentedNumberScreened, PartySubaddress FROM Addressing-Data-Elements-asn1-97 { iso (1) standard (0) pss1-generic-procedures (11582) addressing-data-elements-asn1-97 (20) }; Recall-Operations OPERATION ::= { recallAlerting | recallAnswered } recallAlerting
OPERATION ::= { -- Sent from the Served User PINX to the Primary PINX ARGUMENT ReAlertingArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 57}
recallAnswered
OPERATION ::= { -- Sent from the Served User PINX to the Primary PINX ARGUMENT ReAnswerArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 58}
ReAlertingArg ::= SEQUENCE { alertedNumber [1] PresentedNumberScreened OPTIONAL, alertedName [2] Name OPTIONAL, argumentExtension CHOICE { extension [6] IMPLICIT Extension{{REExtSet}}, multipleExtension [7] IMPLICIT SEQUENCE OF Extension{{REExtSet}} } OPTIONAL }
- 5 -
Table 1 - Operations in Support of SS-RE (concluded) ReAnswerArg ::= SEQUENCE { connectedNumber [1] PresentedNumberScreened, connectedSubaddress [2] PartySubaddress OPTIONAL, connectedName [3] Name OPTIONAL, argumentExtension CHOICE { extension [6] IMPLICIT Extension{{REExtSet}}, multipleExtension [7] IMPLICIT SEQUENCE OF Extension{{REExtSet}} } OPTIONAL } REExtSet EXTENSION ::= {…} END
-- of Recall-Operations-asn1-97
6.3.2 Information elements 6.3.2.1 Facility information element 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 and the Interpretation APDU shall contain value discardAnyUnrecognisedInvokePdu. 6.3.3
6.4
Messages The Facility information element shall be conveyed in the messages as specified in clause 10 of ECMA-165.
SS-RE State definitions
6.4.1
States at the Served User PINX The procedures for the Served User PINX are written in terms of the following conceptual states existing within the SS-RE Supplementary Service Control entity.
6.4.1.1
R E- I d le SS-RE is not operating at the Served User PINX.
6.4.1.2
R E- A wa it - A n s we r - F r o m - U s e r - A The recall to user A has been initiated by the Served User PINX.
6.4.2
S t a t e s a t t h e P r im a r y P I N X The procedures for the Primary PINX are written in terms of the following conceptual states existing within the SS-RE Supplementary Service Control entity in that PINX in association with a particular call:
6.4.2.1
6.5
R E- I d le - P SS-RE is not operating at the Primary PINX.
SS-RE signalling procedures An example message sequence is shown in annex B. NOTE The specification in this section is based on each of the End PINXs involved in SS-CT 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 are internal to the PINX implementation and therefore outside the scope of this Standard.
- 6 -
6.5.1 A c t io n s a t t h e S e r v e d U s e r P I N X 6.5.1.1 Normal procedures NOTE It is assumed that SS-CT has been invoked successfully before the procedures of SS-RE are started and user C has not answered the call. When recall to user A occurs, the Served User PINX shall enter state RE-Await-Answer-From-User-A and initiate clearing of the secondary call according to the procedures of ECMA-143 either immediately or when alerting of user A starts. In state RE-Await-Answer-From-User-A, the Served User PINX shall send a FACILITY message with a recallAlerting invoke APDU to the Primary PINX when alerting of user A commences and a recallAnswered invoke APDU when user A answers the call. The argument of the recallAlerting invoke APDU may contain the elements alertedNumber and/or alertedName if it is known that presentation restriction does not apply. The argument of recallAnswered invoke APDU may contain connectedSubaddress or connectedName. The Served User PINX shall enter state RE-Idle after the recallAnswered invoke APDU has been sent or when the call is cleared. 6.5.1.2
Ex c e p t io n a l p r o c e d u r e s If the recall to user A cannot be completed due to e.g. user A does not answer the call, additional implementation specific procedures may be provided by the Served User PINX.
6.5.2 A c t io n s a t t h e P r im a r y P I N X 6.5.2.1 Normal procedures NOTE It is assumed that SS-CT has been invoked successfully before the procedures of SS-RE are started. On receipt of a recallAlerting invoke APDU or a recallAnswered invoke APDU in a FACILITY message from the Served User PINX, the Primary PINX shall remain in state RE-Idle-P and convey appropriate alerting or answer notifications to user B. The received number information may be conveyed by the Primary PINX to the user subject to number presentation restriction. If element connectedName or alertedName is present, the received name information may be conveyed by the Primary PINX to the user subject to name presentation restriction. Any other information in the invoke APDU may be conveyed to the user. 6.5.2.2
6.6
Ex c e p t io n a l p r o c e d u r e s Not applicable.
SS-RE Impact of interworking with public ISDNs When user A is in the PISN, and user B is in the public ISDN, the Gateway PINX shall convey the notifications of recall to the public ISDN by mapping the recallAlerting invoke APDU and recallAnswered invoke APDU received from the Served User PINX to equivalent indications towards the public ISDN, if the public ISDN is capable of receiving it. When user A is in the public ISDN, and user B is in the PISN, the Gateway PINX shall convey any recall notifications received from the public ISDN to the Primary PINX by mapping them accordingly to the recallAlerting invoke APDU and recallAnswered invoke APDU. NOTE At the time of publication of this Standard, no equivalent service was specified for public ISDNs.
6.7
SS-RE Impact of interworking with non-ISDNs When user A is in the PISN, and user B is in the other network, the Gateway PINX shall convey the notifications of recall to the other network by mapping the recallAlerting invoke APDU and recallAnswered invoke APDU received from the Served User PINX to equivalent indications towards the other network, if the other network is capable of receiving it.
- 7 -
When user A is in the other network, and user B is in the PISN, the Gateway PINX shall convey any recall notifications received from the other network to the Primary PINX by mapping them accordingly to the recallAlerting invoke APDU and recallAnswered invoke APDU.
6.8
SS-RE Parameter values (Timers) Not applicable.
6.9
Protocol interactions between SS-RE 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 Simultaneous conveyance of APDUs for SS-RE 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.
6.9.1
Interaction with Calling Name Identification Presentation (SS-CNIP) No interaction.
6.9.2
Interaction with Connected Name Identification Presentation (SS-CONP) Provision of the connected name to the calling user following recall is specified in 6.5.2.1.
6.9.3
I n t e r a c t io n wit h 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.9.3.1
A c t io n s a t t h e S S - R E S e r v e d U s e r P I N X If SS-CFU is invoked, no divertingLegInformation1 or divertingLegInformation3 invoke APDU shall be sent to the Primary PINX. When sending a recallAlerting or recallAnswered invoke APDU, the information in the argument shall relate to the diverted-to user instead of to user A. On receipt of a callRerouteing invoke APDU during invocation of recall, the Served User PINX shall act as the Rerouteing PINX.
6.9.4
I n t e r a c t io n wit h 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. 6.9.3.1 shall apply with "CFU" replaced by "CFB".
6.9.5 6.9.5.1
I n t e r a c t i o n wit h 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 interaction shall apply if SS-CFNR is supported in accordance with ECMA-174. A c t io n s a t a S S - R E S e r v e d U s e r P I N X f o r j o in In state RE-Await-Answer-From-User-A, the SS-RE Served User PINX shall convey any received divertingLegInformation1 invoke APDU or divertingLegInformation3 invoke APDU to the Primary PINX. When the diverted-to user answers, the actions shall be as specified in 6.5.1.1 when user A answers. In state RE-Await-Answer-From-User-A, on receipt of a callRerouting invoke APDU, the SS-RE Served User 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.
6.9.5.2
A c t io n s a t a P r im a r y P I N X The actions at an Originating PINX in 6.5.1.1 and 6.5.1.2 of ECMA-174 shall apply also to the Primary PINX with the following exceptions: − The basic call protocol control state in which a divertingLegInformation1 invoke APDU can be received is "Active".
- 8 -
− On receipt of a recallAnswered invoke APDU, the Primary PINX shall enter state CFO-Idle. 6.9.6
I n t e r a c t io n wit h C a ll Tr a n s f e r ( S S - C T) Interactions are specified in clauses 6.1 to 6.8.
6.9.7
Interaction with Path Replacement (ANF-PR) No interaction.
6.9.8
Interaction with Call Completion to Busy Subscriber (SS-CCBS) No interaction.
6.9.9
I n t e r a c t i o n wit h C a l l C o m p l e t i o n o n N o R e p l y ( S S - C C N R ) No interaction.
6.9.10
Interaction with Call Offer (SS-CO) No interaction.
6.9.11
I n t e r a c t i o n wit h D o N o t D i s t u r b ( S S - D N D ) No interaction.
6.9.12
Interaction with Do Not Disturb Override (SS-DNDO) No interaction.
6.9.13
I n t e r a c t i o n wit h C a l l I n t r u s i o n ( S S - C I ) No interaction.
6.9.14
I n t e r a c t io n wit h A d v ic e o f C h a r g e ( S S - A O C ) No interaction.
6.9.15
Interactions with Call Interception delayed (ANF-CINT) The following interaction shall apply if ANF-CINT is supported in accordance with ECMA-221.
6.9.15.1
A c t io n s a t a S S - R E S e r v e d U s e r P I N X If recall fails or remains unanswered and if call interception is invoked, any cintLegInformation1, divertingLegInformation3, cintDisable or cintEnable invoke APDUs generated or received in accordance with ANF-CINT procedures shall be sent to the SS-RE Primary PINX.
6.9.15.2
A c t io n s a t a S S - R E P r im a r y P I N X The actions at an ANF-CINT Originating PINX specified in 6.6.3 of ECMA-221 shall apply also to the SS-RE Primary PINX. NOTE The basic call protocol control state in which a cintLegInformation1, divertingLegInformation3, cintEnable or cintDisable invoke APDU can be received is “active”.
- 9 -
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 Protocol Implementation Conformance Statement (PICS) proforma in clause A.3. 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: − by a 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 PICS proforma; − by the user (or potential user) of the implementation, as a basis for initially checking the possibility of interworking with another implementation (note that, while interworking can not 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 asses the claim for conformance of the implementation.
A.2
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 to conform 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 a restricted choice (Yes or No) or in the "Not Applicable" column (N/A).
- 10 -
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 or expected that a large quantity will be supplied, and a PICS can be considered complete without any 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
Exception 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 requirements. 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.
- 11 -
A.3
PICS proforma for ECMA-214
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 the requirement 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)
- 12 -
A.3.3
General
Item
Question/feature
Reference
Status
N/A
Support
A1
Support of SS-RE in Served User PINX
o.1
Yes [ ] No [ ]
A2
Support of SS-RE in Primary PINX
o.1
Yes [ ] No [ ]
A3
Support of SS-CT (transfer by join)
A1:m
A4
Support of SS-RE in Gateway PINX to public ISDNs
o
Yes [ ] No [ ]
A5
Support of SS-RE in Gateway PINX to non-ISDNs
o
Yes [ ] No [ ]
A.3.4
[]
m: Yes [ ]
Procedures for SS-RE
Item
Question/feature
Reference
Status
N/A
Support
B1
Support of ECMA-143 and ECMA-165 procedures at a Served User PINX
6.2.3
A1:m
[]
m: Yes [ ]
B2
Support of ECMA-143 and ECMA-165 procedures at a Primary PINX
6.2.2
A2:m
[]
m: Yes [ ]
B3
Signalling procedures at a Served User PINX
6.5.1
A1:m
[]
m: Yes [ ]
B4
Signalling procedures at a Primary PINX
6.5.2
A2:m
[]
m: Yes [ ]
B5
Behaviour as Gateway for interworking with public ISDNs
6.6
A4:m
[]
m: Yes [ ]
B6
Behaviour as Gateway for interworking with non-ISDNs
6.7
A5:m
[]
m: Yes [ ]
Reference
Status
N/A
Support
A.3.5 Item
Coding Question/feature
C1
Sending of recallAlerting invoke APDU in Served User PINX
6.3
A1:m
[]
m: Yes [ ]
C2
Receipt of recallAlerting invoke APDU in Primary User PINX
6.3
A2:m
[]
m: Yes [ ]
C3
Sending of recallAnswered invoke APDU in Served User PINX
6.3
A1:m
[]
m: Yes [ ]
C4
Receipt of recallAnswered invoke APDU in Primary PINX
6.3
A2:m
[]
m: Yes [ ]
- 13 -
A.3.6 Item
Interactions between SS-RE and SS-CFU Question/feature
D1
Support of SS-CFU (Rerouteing PINX)
D2
Actions at the SS-RE Served User PINX
Reference
Status
N/A
o
Support Yes [ ] No [ ]
6.9.3
c.1
[]
m: Yes [ ]
Reference
Status
N/A
Support
c.1: if A1 and D1 then mandatory, else N/A
A.3.7 Item
Interactions between SS-RE and SS-CFB Question/feature
E1
Support of SS-CFB (Rerouteing PINX)
E2
Actions at the SS-RE Served User PINX
o 6.9.4
Yes [ ] No [ ]
c.1
[]
m: Yes [ ]
Status
N/A
Support
c.1: if A1 and E1 then mandatory, else N/A
A.3.8 Item
Interactions between SS-RE and SS-CFNR Question/feature
Reference
F1
Support of SS-CFNR (Rerouteing PINX)
o
Yes [ ] No [ ]
F2
Support of SS-CFNR (Originating PINX)
o
Yes [ ] No [ ]
F3
Actions at the SS-RE Served User PINX
6.9.5.1
c.1
[]
m: Yes [ ]
F4
Actions at a Primary PINX
6.9.5.2
c.2
[]
m: Yes [ ]
Status
N/A
Support
c.1: if A1 and F1 then mandatory, else N/A c.2: if A2 and F2 then mandatory, else N/A
A.3.9
Interactions between SS-RE and ANF-CINT
Item
Question/feature
G1
Support of ANF-CINT (delayed)
G2
Interaction at a SS-RE Served User PINX
6.9.15.1
G1:m
[]
m: Yes [ ]
G3
Interaction at a SS-RE Primary PINX
6.9.15.2
c.1
[]
m: Yes [ ]
c.1: if G1 and (A3 or A4) then m else N/A
Reference
o
Yes [ ] No [ ]
- 14 -
- 15 -
Annex B ( in f o r ma tiv e )
Example of message sequences
This annex describes a typical message flow of SS-RE. The following conventions are used in the figure of this annex. 1. The following notation is used: M e s s a g e c o n ta in in g S S - R E in fo r m a tio n B a s ic c a ll m e s s a g e w ith o u t S S - R E in fo r m a tio n S y m b o lic p r im itiv e w ith o u t S S - R E in fo r m a tio n x x x .in v
In v o k e A P D U fo r o p e r a tio n x x x
2. The figure show messages exchanged via Protocol Control between PINXs involved in SS-RE. Only messages relevant to SS-RE 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-RE is not shown.
- 16 -
B.1
Message sequence for SS-RE Figure B.1.1 shows the successful invocation of SS-RE with alert and answer indications.
P rim a ry P IN X
U se r B
S e rv e d U se r P IN X
P rim a ry c a ll
a c tiv e b a s ic c a ll
S e c o n d a ry c a ll
b a s ic c a ll is a le rtin g o r w a itin g o n b u s y
r e c a ll to u s e r A o c c u r e d
D IS C O N N E C T R E L E A S E R E L E A S E
C O M P L E T E
U se r A u se r in d ic a tio n
a le rt in d ic a tio n F A C IL IT Y r e c a llA le r tin g .in v U se r A a n s w e r in d ic a tio n
u se r in d ic a tio n
S e c o n d a ry P IN X
F A C IL IT Y r e c a llA n s w e r e d .in v
9 4 -0 1 4 9 -A
F ig u r e B. 1 . 1 - S u c c e s s f u l in v o c a t io n o f S S - R E
- 17 -
Annex C ( 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 Recommendation Z.100 (1999). Each diagram represents the behaviour of an SS-RE 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 Procedures Control and Basic Call Control. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a QSIG message being sent, the output bears the name of the message and any remote operations APDU(s) or notification(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 is the result of a QSIG message being received, the input signal bears the name of the message and any remote operation APDU(s) or notification(s) contained in that message. In case of a message specified in ECMA-143, basic call actions associated with the receipt of that message are deemed to have occurred. The following abbreviations are used: inv
invoke APDU
- 18 -
C.1
SDL Representation of SS-RE at the Served User PINX Figure C.1 shows the behavior of an SS-RE Supplementary Service Control entity within the Served User PINX. Input signals from the right and output signals to the right represent primitives from and to the Coordination Function in respect of messages being received and sent or internal primitives. Input signals from the left represent primitives between the SS-RE Supplementary Service Control entity and the served user.
RE-Idle
Recall to user A occured
clear call to Secondary PINX
RE-Await-Answer -From-User-A
alerting indication from user A
send FACILITY with recallAlerting inv to Primary PINX
RE-Await-Answer -From-User-A
answer indication from user A
call cleared
send FACILITY with recallAnswerer inv to Primary PINX
RE-Idle
94-0150-A
Figure C.1 - SDL for Served User PINX
- 19 -
C.2
SDL Representation of SS-RE at the Primary PINX Figure C.2 shows the behavior of an SS-RE Supplementary Service Control entity within the Primary PINX. Input signals from the right represent primitives from the Coordination Function in respect of the messages being received. Outputs signals to the left represent primitives between the SS-RE Supplementary Service Control entity and the primary user. RE-Idle-P
FACILITY recallAlerting.inv APDU
notify user B
RE-Idle-P
FACILITY recallAnswered.inv APDU
notify user B
RE-Idle-P
94-0151-A
F ig u r e C . 2 - S D L f o r P r im a r y P I N X
- 20 -
- 21 -
Annex D ( 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-214, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the third edition the ASN.1 modules within ECMA-214 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 D . 1 - R e c a ll- 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 Recall-Operations { iso (1) standard (0) pss1-recall (15052) recall-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) } PSS1InformationElement FROM Generic-parameters-definition { iso (1) standard (0) pss1-generic-procedures (11582) pss1-generic-parameters (6)
} Name FROM Name-Operations { iso (1) standard (0) pss1-name (13868) name-operations (0) } PresentedNumberScreened, PartySubaddress FROM Addressing-Data-Elements { iso (1) standard (0) pss1-generic-procedures (11582) addressing-data-elements (9) }; RecallAlerting ::= OPERATION -- Sent from the Served User PINX to the Primary PINX ARGUMENT ReAlertingArg RecallAnswered ::= OPERATION -- Sent from the Served User PINX to the Primary PINX ARGUMENT ReAnswerArg ReAlertingArg ::= SEQUENCE { alertedNumber [1] PresentedNumberScreened OPTIONAL, alertedName [2] Name OPTIONAL, argumentExtension CHOICE { extension [6] IMPLICIT Extension, multipleExtension [7] IMPLICIT SEQUENCE OF Extension } OPTIONAL }
- 22 -
Ta b le D . 1 - R e c a ll- 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 ) ReAnswerArg ::= SEQUENCE { connectedNumber [1] PresentedNumberScreened, connectedSubaddress [2] PartySubaddress OPTIONAL, connectedName [3] Name OPTIONAL, argumentExtension CHOICE { extension [6] IMPLICIT Extension, multipleExtension [7] IMPLICIT SEQUENCE OF Extension } OPTIONAL } recallAlerting recallAnswered END
RecallAlerting RecallAnswered
-- of Recall-Operations
::= localValue 57 ::= localValue 58
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.