S tandard ECMA-194
4th Edition - December 2001
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Do Not Disturb and Do Not Disturb Override Supplementary Services
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]
.
S tandard ECMA-194
4th Edition - December 2001
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Do Not Disturb and Do Not Disturb Override Supplementary Services (QSIG-DND(O))
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
Ecma-194.doc
14-01-02 09,39
.
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 Do Not Disturb (DND) and Do Not Disturb Override (DNDO) supplementary services. 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 and 2nd Editions of Standard ECMA-194 (published by ECMA in June 1993 and December 1994 respectively), the 3rd Edition incorporated changes in order to achieve complete alignment with International Standard ISO/IEC 14844:1996(E) published by ISO/IEC in September 1996. Compared to the 3rd Edition of Standard ECMA-194 (published by ECMA in June 1997), this 4th Edition incorporates migration to ASN.1 version 1997.
Adopted as 4th Edition of Standard ECMA-194 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 Activating PINX 4.2.2 Deactivating PINX 4.2.3 Inter-PINX link 4.2.4 I n te r r o g a tin g P I N X 4.2.5 Path retention 4.2.6 Served User PINX
2 2 3 3 3 3 3 3 3
5 6
Acronyms Signalling protocol for the support of SS-DND and SS-DNDO 6.1 SS-DND and SS-DNDO description 6 . 2 S S - D N D a n d S S - D N D O o p e r a t i o n a l r e q u i r e me n t s 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 e r min a tin g P I N X 6.2.3 Re q u ir e me n ts o n a n O r ig in a tin g P I N X 6.2.4 Re q u ir e me n ts o n a n A c tiv a tin g P I N X 6.2.5 Re q u ir e me n ts o n a D e a c tiv a tin g P I N X 6.2.6 Re q u ir e me n ts o n a n I n te r r o g a tin g P I N X 6.2.7 R e q u i r e me n t s o n a S S - D N D S e r v e d U s e r P I N X 6.2.8 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 - D N D a n d S S - D N D O c o d in g r e q u i r e me n t s 6.3.1 Operations 6.3.2 Notifications 6.3.3 I n f o r ma t i o n e l e me n t s 6.3.4 Messages 6.4 SS-DND and SS-DNDO state definitions 6.4.1 S t a t e a t t h e T e r mi n a t i n g P I N X 6.4.2 States at the Originating PINX 6.4.3 States at the Activating PINX 6.4.4 States at the Deactivating PINX 6.4.5 States at the Interrogating PINX 6.4.6 State at the SS-DND Served User PINX 6.5 SS-DND signalling procedures 6.5.1 A c t i o n s a t t h e T e r mi n a t i n g P I N X
3 3 3 4 4 4 4 4 4 5 5 5 6 6 11 11 11 12 12 12 12 12 12 12 13 13
- ii -
6.5.2 Actions at the Originating PINX 13 6.5.3 Actions at the Activating PINX 13 6.5.4 Actions at the Deactivating PINX 14 6.5.5 A c tio n s a t th e I n te r r o g a tin g P I N X 15 6.5.6 Actions at the Served User PINX 15 6.5.7 Actions at a Transit PINX 16 6.6 SS-DNDO signalling procedures 16 6.6.1 A c t i o n s a t t h e T e r mi n a t i n g P I N X 16 6.6.2 Actions at the Originating PINX 17 6.6.3 Actions at a Transit PINX 17 6 . 7 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 18 6.7.1 SS-DND 18 6.7.2 SS-DNDO 18 6 . 8 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 18 6.8.1 SS-DND 18 6.8.2 SS-DNDO 18 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 - D N D 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 18 6.9.1 I n t e r a c t i o n b e t w e e n S S - D N D a n d C a l l i n g N ame 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 CNIP) 19 6.9.2 I n te r a c tio n b e tw e e n S S - D N D a n d C o n n e c te d N a me I d e n tif ic a tio n P r e s e n ta tio n (SS-CONP) 19 6.9.3 I n t e r a c t i o n b e t w e e n S S - D N D a n d C a l l C o mp l et 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 ) 1 9 6.9.4 I n t e r a c t i o n b e t w e e n S S - D N D a n d C a l l C o mp l e t i o n o n N o R e p l y ( S S - C C N R ) 19 6.9.5 Interaction between SS-DND and Call Transfer (SS-CT) 19 6.9.6 I n t e r a c t i o n b e t w e e n S S - D N D a n d C a l l F or w a r d i n g U n c o n d i t i o n a l ( S S - C F U ) 19 6.9.7 Interaction between SS-DND and Call Forwarding Busy (SS-CFB) 19 6.9.8 Interaction between SS-DND and Call Forwarding No Reply (SS-CFNR) 19 6.9.9 I n t e r a c t i o n b e t w e e n S S - D N D a n d P a t h R e p l a c e me n t ( A N F - P R ) 19 6.9.10 Interaction between SS-DND and Call Offer (SS-CO) 19 6.9.11 Interaction between SS-DND and Do Not Disturb Override (SS-DNDO) 19 6.9.12 Interaction between SS-DND and Call Intrusion (SS-CI) 20 6.10 P r o to c o l in te r a c tio n s b e tw e e n S S - D N D O 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 ANFs 20 6.10.1 I n t e r a c t i o n b e t w e e n S S - D N D O a n d 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 (SS-CNIP) 20 6.10.2 I n te r a c tio n b e tw e e n S S - D N D O a n d C o n n e c te d N a me I d e n tif ic a tio n P r e s e n ta tio n (SS-CONP) 20 6.10.3 I n t e r a c t i o n b e t w e e n S S - D N D O a n d 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 CCBS) 20 6.10.4 I n t e r a c t i o n b e t w e e n S S - D N D O a n d C a l l C o mp l e t i o n o n N o R e p l y ( S S - C C N R ) 20 6.10.5 Interaction between SS-DNDO and Call Transfer (SS-CT) 20 6.10.6 Interaction between SS-DNDO and Call Forwarding Unconditional (SS-CFU) 20 6.10.7 Interaction between SS-DNDO and Call Forwarding Busy (SS-CFB) 21 6.10.8 Interaction between SS-DNDO and Call Forwarding No Reply (SS-CFNR) 21 6.10.9 I n t e r a c t i o n b e t w e e n S S - D N D O a n d P a t h R e p l a c e me n t ( A N F - P R ) 21 6.10.10 Interaction between SS-DNDO and Call Offer (SS-CO) 21 6.10.11 Interaction between SS-DNDO and Do Not Disturb (SS-DND) 21
- iii -
6.10.12 Interaction between SS-DNDO and Call Intrusion (SS-CI) 6.11 S S - D N D a n d S S - D N D O p a r a me t e r v a l u e s ( t i me r s ) 6.11.1 T i me r T 1 6.11.2 T i me r T 2 6.11.3 T i me r T 3 6.11.4 T i me r T 4
21 21 21 21 21 22
Annex A - Signalling protocol for the support of Path Retention
23
Annex B - Protocol Implementation Conformance Statement (PICS) proforma
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
45
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
51
Annex E - Imported ASN.1 definitions relating to numbers
59
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
61
1
Scope This Standard specifies the signalling protocol for the support of the Do Not Disturb and Do Not Disturb Override supplementary services (SS-DND and SS-DNDO) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). SS-DND is a supplementary service which enables a served user to cause the PISN to reject any calls, or just those associated with a specified basic service, addressed to the served user's PISN number. The calling user is given an indication. Incoming calls are rejected as long as the service is active. The served user's outgoing service is unaffected. SS-DNDO is a supplementary service which enables a served user to override SS-DND at a called number; that is, to allow the call to proceed as if the called user had not activated SS-DND. 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-193. The signalling protocols for SS-DND(O) operate on top of the signalling protocol for basic circuit switched call control, as specified in ECMA-143, and use 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-DND and other supplementary services and ANFs and between SS-DNDO and other supplementary services and ANFs. 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 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 B.
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-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)
- 2 -
ECMA-174
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Diversion Supplementary Services (International Standard ISO/IEC 13873)
ECMA-186
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Completion Supplementary Services (International Standard ISO/IEC 13870)
ECMA-192
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Offer Supplementary Service (International Standard ISO/IEC 14843)
ECMA-193
Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Do Not Disturb and Do Not Disturb Override Supplementary Services (International Standard ISO/IEC 14842)
ECMA-203
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Intrusion Supplementary Service (International Standard ISO/IEC 14846)
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: − Application Protocol Data Unit (APDU)
(ECMA-165)
− Basic Service
(ITU-T Rec. I.210)
− Call, Basic Call
(ECMA-165)
− Coordination Function
(ECMA-165)
− End PINX
(ECMA-165)
− Gateway PINX
(ECMA-143)
− Interpretation APDU
(ECMA-165)
− Network Facility Extension (NFE)
(ECMA-165)
− Originating PINX
(ECMA-165)
− Private Integrated Services Network (PISN)
(ECMA-133)
− Private Integrated services Network eXchange (PINX)
(ECMA-133)
− Rerouteing PINX
(ECMA-174)
− Served user
(ECMA-193)
− Signalling
(ITU-T Rec. I.112)
− Supplementary Service
(ITU-T Rec. I.210)
− Supplementary Services Control Entity
(ECMA-165)
− Terminating PINX
(ECMA-165)
− Transit PINX
(ECMA-165)
− User
(ECMA-142)
- 3 -
4.2
Other definitions
4.2.1
A c t iv a t in g P I N X The PINX serving the activating user.
4.2.2
D e a c t iv a t in g P I N X The PINX serving the deactivating user.
4.2.3
I n t e r - P I N X lin k The totality of a signalling channel and a number of information channels at the Q reference point.
4.2.4
I n t e r r o g a t in g P I N X The PINX serving the interrogating user.
4.2.5
P a t h r e t e n t io n The retaining of the network connection between the Originating PINX and the Terminating PINX so that a supplementary service (such as SS-DNDO) can be invoked without establishing a new connection.
4.2.6
Served User PINX The PINX serving the served user.
5
6 6.1
Acronyms ANF
Additional Network Feature
APDU
Application Protocol Data Unit
ASN.1
Abstract Syntax Notation no. 1
DNDOCL
DNDO Capability Level
DNDPL
DND Protection Level
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-DND
Supplementary Service Do Not Disturb
SS-DNDO
Supplementary Service Do Not Disturb Override
TE
Terminal Equipment
Signalling protocol for the support of SS-DND and SS-DNDO SS-DND and SS-DNDO description SS-DND is a supplementary service which enables a served user to cause the PISN to reject any calls, or just those associated with a specified basic service, addressed to the served user's PISN number. The calling user is given an appropriate indication. Incoming calls are rejected as long as the service is active. The served user's outgoing service is unaffected. SS-DNDO is a supplementary service which enables a calling user to override SS-DND at a called user, allowing the call to proceed as if the called user had not activated SS-DND. Both SS-DND and SS-DNDO are applicable to all circuit mode basic services defined in ECMA-142.
- 4 -
6.2
SS-DND and SS-DNDO operational requirements
6.2.1 P r o v is io n /wit h d r a wa l 6.2.1.1 P r o v i s i o n / wi t h d r a wa l o f S S - D N D SS-DND is provided or withdrawn after pre-arrangement with the service provider. SS-DND is provided on a per PISN number basis and per basic service basis. For each PISN number, the supplementary service can be subscribed to for every basic service subscribed to by that PISN number, or for only some of the basic services subscribed to by that PISN number. SS-DND subscription parameters may apply separately to each basic service to which SS-DND is subscribed, or for all the basic services to which SS-DND is subscribed. If SS-DNDO is implemented then the subscription parameter "DND protection level" (DNDPL) shall be provided. The DNDPL has a value in the range 0 to 3 where 0 means no protection against DNDO and 3 means total protection against DNDO. The values 0 and 3 shall be offered. The values 1 and 2 may, as an implementation option, be offered. The effect of the subscription parameter DNDPL shall be as described in subclause 6.3.15 of ECMA-193. The subscription parameter "Served user notification of SS-DND" may be provided. If it is not provided, as an implementation option, the network may or may not notify the served user of DND invocation. 6.2.1.2
P r o v i s i o n / wi t h d r a wa l o f S S - D N D O SS-DNDO is provided or withdrawn after pre-arrangement with the service provider. SS-DNDO is provided on a per PISN number basis and per basic service basis. For each PISN number, the supplementary service can be subscribed to for every basic service subscribed to by that PISN number, or for only some of the basic services subscribed to by that PISN number. SS-DNDO subscription parameters may apply separately to each basic service to which SS-DNDO is subscribed, or for all the basic services to which SS-DNDO is subscribed. The subscription parameter "DNDO capability level" (DNDOCL) shall be provided. The DNDOCL has a value in the range 1 (lowest capability) to 3 (highest capability). At least one of the DNDOCL levels shall be offered. The effect of the subscription parameter DNDOCL shall be as described in subclause 6.3.15 of ECMA-193.
6.2.2
Requirements on a Terminating PINX Call establishment procedures for the incoming side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. In addition, the generic procedures for notification, as specified in ECMA-165 for an End PINX, shall apply.
6.2.3
Requirements on an Originating PINX Call establishment procedures for the outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. In addition, the generic procedures for notification, as specified in ECMA-165 for an End PINX, shall apply.
6.2.4
Requirements on an Activating PINX Generic procedures for the call-independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply.
6.2.5
Requirements on a Deactivating PINX Generic procedures for the call-independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply.
- 5 -
6.2.6
Requirements on an Interrogating PINX Generic procedures for the call-independent control (connection oriented) of supplementary services, as specified in ECMA-165 for an Originating PINX, shall apply.
6.2.7
Requirements on a SS-DND Served User PINX Generic procedures for the call-independent control (connection oriented) of supplementary services, as specified in ECMA-165 for a Terminating PINX, shall apply.
6.2.8
Requirements on a Transit PINX The basic call procedures for call establishment and call clearing at a Transit PINX, as specified in ECMA-143, shall apply. Generic procedures for the call-related control and call-independent control (connection oriented) of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply. In addition, the generic procedures for notification, as specified in ECMA-165 for a Transit PINX, shall apply.
- 6 -
6.3
SS-DND and SS-DNDO 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-DND(O)
Do-Not-Disturb-Operations-asn1-97 {iso(1) standard(0) pss1-do-not-disturb(14844) do-not-disturb-operations-asn1-97 (2) } 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)} basicServiceNotProvided, invalidServedUserNr, notAvailable, userNotSubscribed, supplementaryServiceInteractionNotAllowed FROM General-Error-List {ccitt recommendation q 950 general-error-list (1)} PartyNumber FROM Addressing-Data-Elements-asn1-97 {iso(1) standard(0) pss1-generic-procedures(11582) addressing-data-elements-asn1-97 (20)} BasicService FROM Call-Diversion-Operations-asn1-97 {iso(1) standard(0) pss1-call-diversion(13873) call-diversion-operations-asn1-97 (1) } ;
Do-Not-Disturb-Operations OPERATION ::= {doNotDisturbActivateQ | doNotDisturbDeactivateQ | doNotDisturbInterrogateQ | doNotDisturbOverrideQ | doNotDisturbOvrExecuteQ | pathRetain | serviceAvailable} doNotDisturbActivateQ
OPERATION ::= { ARGUMENT DNDActivateArg RESULT DNDActivateRes ERRORS { userNotSubscribed | notAvailable | invalidServedUserNr | basicServiceNotProvided | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | unspecified} CODE local: 35}
- 7 -
Table 1 - Operations in support of SS-DND(O) (continued) doNotDisturbDeactivateQ
OPERATION ::= { ARGUMENT RESULT ERRORS
CODE doNotDisturbInterrogateQ
doNotDisturbOverrideQ
pathRetain
OPERATION ::= { ARGUMENT RESULT ERRORS
DNDDeactivateArg DummyRes { userNotSubscribed | notAvailable | invalidServedUserNr | notActivated | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | unspecified} local: 36}
CODE
DNDInterrogateArg DNDInterrogateRes { userNotSubscribed | notAvailable | invalidServedUserNr | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | unspecified} local: 37}
OPERATION ::= { ARGUMENT RETURN RESULT ALWAYS RESPONDS CODE
DNDOverrideArg FALSE FALSE local: 38}
OPERATION ::= { ARGUMENT
PathRetainArg
-- this operation may be used by other -- Supplementary Services using other -- values of the argument
RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 41} serviceAvailable
OPERATION ::= { ARGUMENT ServiceAvailableArg -- this operation may be used by other -- Supplementary Services using other -- values of the argument RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 42}
- 8 -
Table 1 - Operations in support of SS-DND(O) (continued) doNotDisturbOvrExecuteQ
OPERATION ::= { ARGUMENT RESULT ERRORS
CODE DummyArg
DummyRes
DummyArg DummyRes { notAvailable | temporarilyUnavailable | supplementaryServiceInteractionNotAllowed | unspecified} local: 39}
::= CHOICE { null extension sequenceOfExtn }
NULL, [1] IMPLICIT Extension{{DNDExtSet}}, [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}}
::= CHOICE { null extension sequenceOfExtn }
NULL, [1] IMPLICIT Extension{{DNDExtSet}}, [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}}
DNDActivateArg
::= SEQUENCE { basicService BasicService, servedUserNr PartyNumber, argumentExtension CHOICE{ extension [1] IMPLICIT Extension{{DNDExtSet}}, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}} } OPTIONAL }
DNDActivateRes
::= SEQUENCE { status SET OF SEQUENCE{ basicService BasicService, dndProtectionLevel DNDProtectionLevel OPTIONAL } OPTIONAL, resultExtension CHOICE{ extension [1] IMPLICIT Extension{{DNDExtSet}}, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}} } OPTIONAL }
DNDDeactivateArg
::= SEQUENCE { basicService BasicService, servedUserNr PartyNumber, argumentExtension CHOICE{ extension [1] IMPLICIT Extension{{DNDExtSet}}, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}} } OPTIONAL }
- 9 -
Table 1 - Operations in support of SS-DND(O) (continued) DNDInterrogateArg
::= SEQUENCE { servedUserNr PartyNumber, argumentExtension CHOICE{ extension [1] IMPLICIT Extension{{DNDExtSet}}, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}} } OPTIONAL }
DNDInterrogateRes
::= SEQUENCE { status SET OF SEQUENCE { basicService BasicService, dndProtectionLevel DNDProtectionLevel OPTIONAL } OPTIONAL, resultExtension CHOICE{ extension [1] IMPLICIT Extension{{DNDExtSet}}, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}} } OPTIONAL }
DNDOverrideArg
::= SEQUENCE { dndoCapabilityLevel DNDOCapabilityLevel, argumentExtension CHOICE{ extension [1] IMPLICIT Extension{{DNDExtSet}}, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension{{DNDExtSet}} } OPTIONAL }
PathRetainArg
::= CHOICE { serviceList extendedServiceList serviceList extension
ServiceList, SEQUENCE { ServiceList, Extension{{DNDExtSet}} }
} ServiceAvailableArg
::= CHOICE { serviceList extendedServiceList serviceList extension
ServiceList, SEQUENCE { ServiceList, Extension{{DNDExtSet}} }
}
- 10 -
Table 1 - Operations in support of SS-DND(O) (concluded) DNDProtectionLevel
::= ENUMERATED { lowProtection(0), mediumProtection(1), highProtection(2), fullProtection(3) }
DNDOCapabilityLevel
::= ENUMERATED { overrideLowProt(1), overrideMediumProt(2), overrideHighProt(3) }
ServiceList
::= BIT STRING { dndo-low(1), dndo-medium(2), dndo-high(3) } (SIZE (1..32)) -- bits other than dndo-low, dndo-medium, or dndo-high, are reserved -- for other Supplementary Services
temporarilyUnavailable notActivated
ERROR ::= { CODE ERROR ::= { CODE
unspecified
ERROR ::= { PARAMETER Extension{{DNDExtSet}} CODE local: 1008}
local: 1000} local: 43}
DNDExtSet EXTENSION ::= {…} END
-- of Do-Not-Disturb-Operations-asn1-97
- 11 -
6.3.2
N o t if ic a t io n s The notification defined in Abstract Syntax Notation number 1 (ASN.1) in table 2 shall apply. Table 2 - Notification in support of SS-DND
Do-Not-Disturb-Notifications-asn1-97 {iso(1) standard(0) pss1-do-not-disturb(14844) do-not-disturb-notifications-asn1-97 (3) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS
NOTIFICATION FROM Notification-class-asn1-97 { iso(1) standard(0) pss1-generic-procedures (11582) notification-class-asn1-97(21) } ;
doNotDisturb
NOTIFICATION ::= { ARGUMENT CODE
NULL local: 2002 }
Do-Not-Disturb-Notifications NOTIFICATION ::= { doNotDisturb } END
-- of Do-Not-Disturb-Notifications-asn1-97
6.3.3 Information elements 6.3.3.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 APDUs of operations defined in subclause 6.3.1, the destinationEntity data element of the NFE shall contain value endPINX. When conveying the invoke APDU of operation doNotDisturbOverrideQ, the Interpretation APDU shall contain value discardAnyUnrecognisedInvokePdu. When conveying the invoke APDUs of operations doNotDisturbOvrExecuteQ, doNotDisturbActivateQ, doNotDisturbDeactivateQ or doNotDisturbInterrogateQ, the Interpretation APDU shall be omitted. NOTE Additional requirements for the conveyance of APDUs of operations pathRetain and serviceAvailable are given in A.3.2 of annex A. 6.3.3.2
N o t i f i c a t i o n i n d ic a t o r i n f o r m a t i o n e l e m e n t The notification defined in subclause 6.3.2 shall be coded in the Notification indicator information element in accordance with ECMA-165.
6.3.3.3
Other information elements Any other information elements (e.g. Progress indicator) shall be coded in accordance with the rules of ECMA-143 and ECMA-165.
6.3.4
Messages The Facility information element and the Notification indicator information element shall be conveyed in the messages as specified in clause 10 of ECMA-165. Messages used for call establishment and release shall be as specified in ECMA-143.
- 12 -
6.4
SS-DND and SS-DNDO state definitions
6.4.1
6.4.1.1 6.4.2
State at the Terminating PINX The procedures for the Terminating PINX are written in terms of the following conceptual state existing within the SS-DND Supplementary Service Control entity in that PINX in association with a particular incoming call for the served user. D N D - t I d le SS-DND or SS-DNDO operation is not in progress. S t a t e s a t t h e O r ig in a t in g P I N X The procedures for the Originating PINX are written in terms of the following conceptual states existing within the SS-DNDO Supplementary Service Control entity in that PINX in association with a particular call of the calling user.
6.4.2.1
DNDO-oIdle SS-DNDO is not operating.
6.4.2.2
D N D O - o A wa i t E x e c R e s u l t A doNotDisturbOvrExecuteQ invoke APDU has been sent.
6.4.3
S t a t e s a t t h e A c t iv a t in g P I N X The procedures for the Activating PINX for remote activation of SS-DND are written in terms of the following conceptual states existing within the SS-DND Supplementary Service Control entity in that PINX in association with a particular activation request from the activating user.
6.4.3.1
DND-aIdle Activation not in progress.
6.4.3.2
DND-aWait A doNotDisturbActivateQ invoke APDU has been sent. The Activating PINX is waiting for the response.
6.4.4
S t a t e s a t t h e D e a c t iv a t in g P I N X The procedures for the Deactivating PINX for remote deactivation of SS-DND are written in terms of the following conceptual states existing within the SS-DND Supplementary Service Control entity in that PINX in association with a particular deactivation request from the deactivating user.
6.4.4.1
DND-dIdle Deactivation not in progress.
6.4.4.2
DND-dWait A doNotDisturbDeactivateQ invoke APDU has been sent. The Deactivating PINX is waiting for the response.
6.4.5
S t a t e s a t t h e I n t e r r o g a t in g P I N X The procedures for the Interrogating PINX for remote interrogation of SS-DND are written in terms of the following conceptual states existing within the SS-DND Supplementary Service Control entity in that PINX in association with a particular interrogation request from the interrogating user.
6.4.5.1
DND-iIdle Interrogation not in progress.
6.4.5.2
DND-iWait A doNotDisturbInterrogateQ invoke APDU has been sent. The Interrogating PINX is waiting for the response.
6.4.6
State at the SS-DND Served User PINX The procedures at the Served User PINX for remote activation, deactivation and interrogation of SSDND are written in terms of the following conceptual state existing within the SS-DND Supplementary
- 13 -
Service Control entity in that PINX in association with a particular call-independent signalling connection for the served user. 6.4.6.1
6.5
DND-sIdle Ready for receipt of a doNotDisturbInterrogateQ APDU.
doNotDisturbActivateQ,
doNotDisturbDeactivateQ
or
SS-DND signalling procedures References in this clause to protocol control states refer to basic call protocol control states defined in ECMA-143. Annex C contains some examples of message sequences.
6.5.1 6.5.1.1
Actions at the Terminating PINX The SDL representation of procedures at the Terminating PINX is shown in D.1 of annex D. Normal procedures 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, and having determined by a local procedure that SS-DND is to be invoked, the Terminating PINX shall proceed as follows. NOTE 1 If the SETUP message also contains a doNotDisturbOverrideQ invoke APDU or a pathRetain invoke APDU containing a retention request for SS-DNDO, there is interaction with SS-DNDO, and the procedures defined in subclause 6.6.1 apply instead of the procedures defined in this clause. NOTE 2 The Terminating PINX should inform the served user of invocation of SS-DND. If an optional in-band tone or announcement is to be applied, the Terminating PINX shall connect an in-band tone or announcement to the incoming B-channel and transmit a PROGRESS message containing a Progress indicator information element with progress description 8 "in-band information or appropriate pattern now available", a Cause information element containing cause number 21 "Call rejected", and a Notification indicator information element containing a NotificationDataStructure with value doNotDisturb. The SS-DND entity shall remain in state DND-tIdle. If no in-band tone or announcement is to be given, a DISCONNECT message shall be sent to clear the connection. The DISCONNECT message shall contain cause number 21 "Call rejected" in the Cause information element and a Notification indicator information element containing a NotificationDataStructure with value doNotDisturb. The SS-DND entity shall remain in state DND-tIdle. NOTE It is recommended that an in-band tone or announcement be provided by the Terminating PINX only if it conveys call rejection information which is not conveyable by the signalling protocol.
6.5.1.2
Ex c e p t io n a l p r o c e d u r e s Not applicable.
6.5.2 A c t io n s a t t h e O r ig in a t in g P I N X 6.5.2.1 Normal procedures None. NOTE In cases where an outgoing call encounters a do not disturb condition at the Terminating PINX, notification of do not disturb may be received from the Terminating PINX. Such a notification will be handled in accordance with subclause 7.4 of ECMA-165. 6.5.2.2 6.5.3
Ex c e p t io n a l p r o c e d u r e s Not applicable. A c t io n s a t t h e A c t iv a t in g P I N X The SDL representation of procedures at the Activating PINX is shown in D.3 of annex D.
- 14 -
6.5.3.1
Normal procedures On determining that activation of SS-DND for a served user at the Served User PINX is required, the Activating PINX shall send a doNotDisturbActivateQ invoke APDU to the Served User PINX using the call reference of a call-independent signalling connection. The call-independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in subclause 7.3 of ECMA-165. The Activating PINX shall enter the DND-aWait state and start timer T1. On receipt of the doNotDisturbActivateQ return result APDU, the Activating PINX shall stop timer T1 and revert to the DND-aIdle state. NOTE The Activating PINX should indicate acceptance to the activating user. The Activating PINX is responsible for clearing the call-independent signalling connection towards the Served User PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate.
6.5.3.2
Ex c e p t io n a l p r o c e d u r e s On receipt of the doNotDisturbActivateQ return error or reject APDU from the Served User PINX, the Activating PINX shall stop timer T1 and revert to the DND-aIdle state. If timer T1 expires (i.e. the doNotDisturbActivateQ invoke APDU is not answered by the Served User PINX), the Activating PINX shall enter the DND-aIdle state. NOTE The Activating PINX should indicate rejection to the activating user. The Activating PINX is responsible for clearing the call-independent signalling connection towards the Served User PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T1. Alternatively, the signalling connection may be retained for other applications, if appropriate.
6.5.4 6.5.4.1
A c t io n s a t t h e D e a c t iv a t in g P I N X The SDL representation of procedures at the Deactivating PINX is shown in D.4 of annex D. Normal procedures On determining that deactivation of SS-DND for a served user at the Served User PINX is required, the Deactivating PINX shall send a doNotDisturbDeactivateQ invoke APDU to the Served User PINX using the call reference of a call-independent signalling connection. The call-independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in subclause 7.3 of ECMA-165. The Deactivating PINX shall enter the DND-dWait state and start timer T2. On receipt of the doNotDisturbDeactivateQ return result APDU, the Deactivating PINX shall stop timer T2 and revert to the DND-dIdle state. NOTE The Deactivating PINX should indicate acceptance to the deactivating user. The Deactivating PINX is responsible for clearing the call-independent signalling connection towards the Served User PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate.
6.5.4.2
Ex c e p t io n a l p r o c e d u r e s On receipt of the doNotDisturbDeactivateQ return error or reject APDU from the Served User PINX, the Deactivating PINX shall stop timer T2 and revert to the DND-dIdle state. If timer T2 expires (i.e. the doNotDisturbDeactivateQ invoke APDU is not answered by the Served User PINX), the Deactivating PINX shall enter the DND-dIdle state. NOTE The Deactivating PINX should indicate rejection to the deactivating user. The Deactivating PINX is responsible for clearing the call-independent signalling connection towards the Served User PINX. This may occur on receipt of a return error or reject APDU or on expiry of
- 15 -
timer T2. Alternatively, the signalling connection may be retained for other applications, if appropriate. 6.5.5
A c t io n s a t t h e I n t e r r o g a t in g P I N X The SDL representation of procedures at the Interrogating PINX is shown in D.5 of annex D.
6.5.5.1
Normal procedures On determining that interrogation of SS-DND for a served user at the Served User PINX is required, the Interrogating PINX shall send a doNotDisturbInterrogateQ invoke APDU to the Served User PINX using the call reference of a call-independent signalling connection. The call-independent signalling connection shall be established (or used, if an appropriate connection is already available) in accordance with the procedures specified in subclause 7.3 of ECMA-165. The Interrogating PINX shall enter the DND-iWait state and start timer T3. On receipt of the doNotDisturbInterrogateQ return result APDU, the Interrogating PINX shall stop timer T3 and revert to the DND-iIdle state. NOTE The Interrogating PINX should indicate acceptance to the interrogating user. The Interrogating PINX is responsible for clearing the call-independent signalling connection towards the Served User PINX. This may occur on receipt of a return result APDU. Alternatively, the signalling connection may be retained for other applications, if appropriate.
6.5.5.2
Ex c e p t io n a l p r o c e d u r e s On receipt of the doNotDisturbInterrogateQ return error or reject APDU from the Served User PINX, the Interrogating PINX shall stop timer T3 and revert to the DND-iIdle state. If timer T3 expires (i.e. the doNotDisturbInterrogateQ invoke APDU is not answered by the Served User PINX), the Interrogating PINX shall enter DND-iIdle state. NOTE The Interrogating PINX should indicate rejection to the interrogating user. The Interrogating PINX is responsible for clearing the call-independent signalling connection towards the Served User PINX. This may occur on receipt of a return error or reject APDU or on expiry of timer T3. Alternatively, the signalling connection may be retained for other applications, if appropriate.
6.5.6
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 The SDL representation of procedures at the Served User PINX is shown in D.6 of annex D.
6.5.6.1 Normal procedures 6 . 5 . 6 . 1 . 1 R e m o t e a c t iv a t io n On receipt of a doNotDisturbActivateQ invoke APDU using the call reference of a call-independent signalling connection (as specified in subclause 7.3 of ECMA-165), the Served User PINX shall check the received basic service (element basicService) for the served user (element servedUserNr) and verify that remote activation is possible. If the activation request is acceptable, the Served User PINX shall activate SS-DND with the protection level subscribed to, and answer the doNotDisturbActivateQ invoke APDU with a return result APDU. 6.5.6.1.2
R e m o t e d e a c t iv a t io n On receipt of a doNotDisturbDeactivate invoke APDU using the call reference of a callindependent signalling connection (as specified in subclause 7.3 of ECMA-165), the Served User PINX shall check the consistency of the received basic service (element basicService) for the served user (element servedUserNr), and verify that SS-DND is activated and that remote deactivation is possible. If the deactivation request is valid, the Served User PINX shall deactivate SS-DND and answer the doNotDisturbDeactivate invoke APDU with a return result APDU.
- 16 -
6.5.6.1.3
R e m o t e in t e r r o g a t io n On receipt of a doNotDisturbInterrogateQ invoke APDU using the call reference of a callindependent signalling connection (as specified in subclause 7.3 of ECMA-165), the Served User PINX shall check the interrogation request and answer the doNotDisturbInterrogateQ invoke APDU with a return result APDU if the interrogation request is valid.
6.5.6.2 Ex c e p t io n a l p r o c e d u r e s 6.5.6.2.1 Remote activation of SS-DND If the activation request cannot be accepted, the Served User PINX shall send back a return error APDU with an appropriate error value. 6.5.6.2.2
Remote deactivation of SS-DND If the deactivation request is not valid, the Served User PINX shall answer the doNotDisturbDeactivateQ invoke APDU with a return error APDU containing an appropriate error value, e.g. "notActivated", if SS-DND is not activated for the relevant PISN number and basic service.
6.5.6.2.3
R e m o t e in t e r r o g a t io n o f S S - D N D If the interrogation request is not valid, the Served User PINX shall answer the doNotDisturbInterrogateQ invoke APDU with a return error APDU containing an appropriate error value.
6.5.7
6.6
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-DND.
SS-DNDO signalling procedures SS-DNDO may be invoked in two ways depending on whether the network connection is retained or not when a call encounters SS-DND activated for a called user. Retention of the network connection makes use of a generic path retention mechanism, which is specified in annex A. References in this clause to protocol control states refer to basic call protocol control states defined in ECMA-143. Annex C contains some examples of message sequences.
6.6.1
Actions at the Terminating PINX The Terminating PINX shall support the two methods of invocation. For invocation with path retention, the procedures specified below apply in conjunction with the procedures specified in A.5.2 of annex A. The SDL representation of procedures at the Terminating PINX is shown in D.1 of annex D.
6.6.1.1
Normal procedures 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, the Terminating PINX shall proceed as follows. If the SETUP message contains a doNotDisturbOverrideQ invoke APDU and if, apart from the possibility of DNDO, all the conditions for the call failing due to SS-DND active are met, the Terminating PINX shall compare the received DNDOCL with the served user's DNDPL. If the DNDPL is smaller than the DNDOCL, SS-DNDO shall be invoked and the call proceeds normally as a basic call without invocation of SS-DND. However, if the DNDPL is greater than or equal to the received DNDOCL, then DNDO is not allowed and SS-DND shall be invoked. In this case the call shall be processed further as if the doNotDisturbOverrideQ invoke APDU had not been included in the SETUP message, and the procedures defined in subclause 6.5.1 for invocation of SS-DND at a Terminating PINX shall apply. If the SETUP message contains a pathRetain invoke APDU with one of the bits dndo-high, dndomedium or dndo-low in element serviceList set to ONE and if, apart from the possibility of DNDO, all the conditions for the call failing due to SS-DND active are met, the Terminating PINX shall compare the received DNDOCL with the served user's DNDPL. If the DNDPL is smaller than the DNDOCL, then SS-DNDO is invokable, and the procedures for path retention in A.5.2 shall apply.
- 17 -
The bit set to ONE in element serviceList in the serviceAvailable invoke APDU shall be the bit that corresponds to the bit set to ONE in the pathRetain invoke APDU. If the DNDPL is greater than or equal to the DNDOCL, then the procedures defined in subclause 6.5.1 for invocation of SS-DND at a Terminating PINX shall apply. If subsequently, after having retained a network connection in accordance with A.5.2 of annex A, and having indicated SS-DNDO in the serviceAvailable APDU, in protocol control state Incoming Call Proceeding, a FACILITY message containing a doNotDisturbOvrExecuteQ invoke APDU is received, the Terminating PINX shall override SS-DND at the destination, permit the incoming call to proceed as for a normal basic call, send a doNotDisturbOvrExecuteQ return result APDU to the Originating PINX and remain in state DND-tIdle. The APDU shall be sent in a FACILITY message on the call reference of the retained network connection. 6.6.1.2
6.6.2
Ex c e p t io n a l p r o c e d u r e s If, on receipt of a doNotDisturbOvrExecuteQ invoke APDU, the Terminating PINX is not able to override SS-DND at the destination, it shall send a doNotDisturbOvrExecuteQ return error APDU to the Originating PINX in a FACILITY or a DISCONNECT message and remain in state DNDO-tIdle. A c t io n s a t t h e O r ig in a t in g P I N X For a given call, the Originating PINX shall choose one of the following two methods for invocation of SS-DNDO: − invocation without path retention; − invocation with path retention. For invocation with path retention, the procedures below apply in conjunction with the procedures specified in A.5.1 of annex A. The SDL representation of procedures at the Originating PINX is shown in D.2 of annex D.
6.6.2.1 Normal procedures 6 . 6 . 2 . 1 . 1 W it h o u t p a t h r e t e n t io n On determining for a new call that SS-DNDO is to be invoked when at the destination SS-DND active is encountered, the Originating PINX shall include a doNotDisturbOverrideQ invoke APDU in the SETUP message sent on the call reference of that call and remain in state DNDO-oIdle. 6.6.2.1.2
W it h p a t h r e t e n t io n For invocation of SS-DNDO with path retention, the Originating PINX shall send a doNotDisturbOvrExecuteQ invoke APDU in a FACILITY message using the call reference of a call for which the network connection has been retained in accordance with A.5.1 of annex A and for which the received serviceAvailable invoke APDU indicated that SS-DNDO is invokable, start timer T4, and enter state DND-oAwaitExecResult. On receipt in state DNDO-oAwaitExecResult of a FACILITY message containing a doNotDisturbOvrExecuteQ return result APDU on the call reference of the retained call, the Originating PINX shall stop timer T4 and enter state DNDO-oIdle.
6.6.2.2
Ex c e p t io n a l p r o c e d u r e s On expiry of timer T4, the Originating PINX shall abort the procedure for SS-DNDO, and enter state DNDO-oIdle. On receipt in state DNDO-oAwaitExecResult of a FACILITY or DISCONNECT message containing a doNotDisturbOvrExecuteQ return error APDU on the call reference of the retained call, the Originating PINX shall stop timer T4, and enter state DNDO-oIdle. On receipt in state DNDO-oAwaitExecResult of an ALERTING, CONNECT or DISCONNECT message without a doNotDisturbOvrExecuteQ return result, return error or reject APDU, the Originating PINX shall stop timer T4 and enter state DNDO-oIdle. The call shall continue in accordance with ECMA-143.
6.6.3
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-DNDO.
- 18 -
6.7
Impact of interworking with public ISDNs
6.7.1
SS-DND NOTE At the time of publication of this Standard, an equivalent service was not specified for public ISDNs.
6.7.1.1
I n c o m in g c a lls On a call to a PISN from a public ISDN, which encounters SS-DND in the PISN, the Incoming Gateway PINX may convey the received notification of SS-DND to the public ISDN if the signalling protocol permits, and may apply a tone or announcement.
6.7.1.2
O u t g o in g c a lls No impact.
6.7.2
SS-DNDO NOTE At the time of publication of this Standard, an equivalent service was not specified for public ISDNs.
6.7.2.1
I n c o m in g c a lls On a call to a PISN from a public ISDN that does not support an equivalent service, SS-DNDO may be invoked automatically by the Gateway PINX, depending on the requirements of the public ISDN.
6.7.2.2
O u t g o in g c a lls On a call from a PISN to a public ISDN that does not support an equivalent service, the Outgoing Gateway PINX shall behave as specified in subclause 6.6.1 for a Terminating PINX at which conditions for invocation of SS-DNDO are not met.
6.8 6.8.1
Impact of interworking with non-ISDNs SS-DND When interworking with a non-ISDN which does not support an equivalent service, the procedures defined in subclause 6.7.1 shall apply. When interworking with a non-ISDN which supports an equivalent service, the two networks may cooperate in the operation of SS-DND. In this case, either the Originating PINX functionality or the Terminating PINX functionality will be provided in the non-ISDN. The Incoming or Outgoing Gateway PINX shall provide conversion between the signalling protocol specified in this Standard and the signalling protocol of the other network.
6.8.2
SS-DNDO When interworking with a non-ISDN which does not support an equivalent service, the procedures defined in subclause 6.7.2 shall apply. When interworking with a non-ISDN which supports an equivalent service, the two networks may cooperate in the operation of SS-DNDO. In this case, either the Originating PINX functionality or the Terminating PINX functionality will be provided in the non-ISDN. The Incoming or Outgoing Gateway PINX shall provide conversion between the signalling protocol specified in this Standard and the signalling protocol of the other network.
6.9
Protocol interactions between SS-DND and other supplementary services and ANFs This clause specifies protocol interactions between SS-DND and 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 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. NOTE 2 Simultaneous conveyance of APDUs for SS-DND and another supplementary service or ANF in the same
- 19 -
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
I n t e r a c t i o n b e t w e e n S S - D N D a n d C a l l i n g N am e 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 ) No protocol interaction.
6.9.2
I n t e r a c t i o n b e t we e n (SS-CONP) No protocol interaction.
6.9.3
I n t e r a c t i o n b e t we e n S S - D N D a n d C a l l C o m p 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 ) The following protocol interaction shall apply if SS-CCBS is supported in accordance with ECMA-186.
6.9.3.1
SS-DND
and
Connected
Name
Identification
Presentation
Actions at the Terminating PINX If SS-CCBS is invoked on a destination with SS-DND active, then the SS-CCBS invocation shall fail using a ccbsRequest return error APDU with error value shortTermRejection. If at the time the PISN attempts to complete the call to the destination following CCBS recall, SSDND is active at the destination, then SS-CCBS shall fail with the appropriate indication to the calling user. The Terminating PINX shall return a DISCONNECT message and a doNotDisturb notification shall be included.
6.9.3.2 6.9.4 6.9.4.1
A c t io n s a t t h e O r ig in a t in g P I N X No interactions. I n t e r a c t i o n b e t we e n S S - D N D a n d 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 ) The following protocol interaction shall apply if SS-CCNR is supported in accordance with ECMA-186. Actions at the Terminating PINX If SS-CCNR is invoked on a destination with SS-DND active, then the SS-CCNR invocation shall fail using a ccnrRequest return error APDU with error value shortTermRejection. If at the time the PISN attempts to complete the call to the destination following CCNR recall, SSDND is active at the destination, then SS-CCNR shall fail with the appropriate indication to the calling user. The Terminating PINX shall return a DISCONNECT message and a doNotDisturb notification shall be included.
6.9.4.2
A c t io n s a t t h e O r ig in a t in g P I N X No interactions.
6.9.5
I n t e r a c t i o n b e t we e n S S - D N D a n d C a l l T r a n s f e r ( S S - C T ) No protocol interaction.
6.9.6
I n t e r a c t i o n b e t we e n S S - D N D a n d C a l l F o r wa r d i n g U n c o n d i t i o n a l ( S S - C F U ) No protocol interaction.
6.9.7
I n t e r a c t i o n b e t we e n S S - D N D a n d C a l l F o r wa r d i n g B u s y ( S S - C F B ) No protocol interaction.
6.9.8
I n t e r a c t i o n b e t we e n S S - D N D a n d 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 ) No protocol interaction.
6.9.9
Interaction between SS-DND and Path Replacement (ANF-PR) No protocol interaction.
6.9.10
I n t e r a c t i o n b e t we e n S S - D N D a n d C a l l O f f e r ( S S - C O ) No protocol interaction.
6.9.11
Interaction between SS-DND and Do Not Disturb Override (SS-DNDO) Protocol interactions are specified in subclause 6.6.
- 20 -
6.9.12
6.10
I n t e r a c t i o n b e t we e n S S - D N D a n d C a l l I n t r u s i o n ( S S - C I ) No protocol interaction.
Protocol interactions between SS-DNDO and other supplementary services and ANFs This clause specifies protocol interactions between SS-DNDO and 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 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. NOTE 2 Simultaneous conveyance of APDUs for SS-DNDO 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.10.1
Interaction between (SS-CNIP) No protocol interaction.
6.10.2
I n t e r a c t i o n b e t we e n S S - D N D O a n d C o n n e c t e d N a m e I d e n t i f i c a t i o n P r e s e n t a t i o n (SS-CONP) No protocol interaction.
6.10.3
I n t e r a c t i o n b e t we e n S S - D N D O a n d C a l l C o m p 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 ) No protocol interaction.
6.10.4
I n t e r a c t i o n b e t we e n S S - D N D O a n d 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 protocol interaction.
6.10.5
I n t e r a c t i o n b e t we e n S S - D N D O a n d C a l l T r a n s f e r ( S S - C T ) No protocol interaction.
6.10.6
I n t e r a c t i o n b e t we e n S S - D N D O a n d C a l l F o r wa r d i n g U n c o n d i t i o n a l ( S S - C F U ) The following protocol interaction shall apply if SS-CFU is supported in accordance with ECMA-174.
6.10.6.1
SS-DNDO
and
Calling
Name
Identification
Presentation
A c t io n s a t t h e R e r o u t e in g P I N X When executing call forwarding, the Rerouteing PINX shall act as follows: − Include a doNotDisturbOverrideQ invoke APDU in the SETUP message to the Diverted-to PINX if either this was included in the SETUP message to the Diverting PINX, or SS-DNDO has been invoked successfully at the diverting user following path retention. − Include a pathRetain invoke APDU with bit dndo-low, dndo-medium or dndo-high set to ONE in the SETUP message to the Diverted-to PINX if and only if this was included in the SETUP message to the Diverting PINX and SS-DNDO has not been successfully invoked at the diverting user. NOTE This interaction takes into account the possible use of SS-CFU signalling in support of Call Deflection Immediate, which can be invoked following SS-DNDO.
6.10.6.2
A c t io n s a t t h e O r ig in a t in g P I N X In order to invoke SS-DNDO without path retention after a call has encountered a diverted-to user with DND active, the Originating PINX shall include a doNotDisturbOverrideQ invoke APDU in addition to the divertingLegInformation2 invoke APDU in the SETUP message of the new call to the diverted-to user.
- 21 -
6.10.7
I n t e r a c t i o n b e t we e n S S - D N D O a n d C a l l F o r wa r d i n g B u s y ( S S - C F B ) The following protocol interaction shall apply if SS-CFB is supported in accordance with ECMA-174.
6.10.7.1
A c t io n s a t t h e R e r o u t e in g P I N X When executing call forwarding, the Rerouteing PINX shall act as follows: − Include a doNotDisturbOverrideQ invoke APDU in the SETUP message to the Diverted-to PINX if either this was included in the SETUP message to the Diverting PINX, or SS-DNDO has been invoked successfully at the diverting user following path retention. − Include a pathRetain invoke APDU with bit dndo-low, dndo-medium or dndo-high set to ONE in the SETUP message to the Diverted-to PINX if and only if this was included in the SETUP message to the Diverting PINX and SS-DNDO was not successfully invoked at the diverting user.
6.10.7.2
A c t io n s a t t h e O r ig in a t in g P I N X In order to invoke SS-DNDO without path retention after a call has encountered a diverted-to user with DND active, the Originating PINX shall include a doNotDisturbOverrideQ invoke APDU in the SETUP message of the new call to the diverted-to user.
6.10.8
I n t e r a c t i o n b e t we e n S S - D N D O a n d 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 ) No protocol interaction.
6.10.9
Interaction between SS-DNDO and Path Replacement (ANF-PR) No protocol interaction.
6 . 1 0 . 1 0 I n t e r a c t i o n b e t we e n S S - D N D O a n d C a l l O f f e r ( S S - C O ) The following protocol interaction shall apply if SS-CO is supported in accordance with ECMA-192. 6.10.10.1 Actions at the Terminating PINX On receiving a SETUP message containing a callOfferRequest invoke APDU together with a doNotDisturbOverrideQ invoke APDU, the procedures of SS-DNDO shall apply and, if SS-DND is not active or is successfully overridden, the procedures of SS-CO shall apply. 6 . 1 0 . 1 1 I n t e r a c t i o n b e t we e n S S - D N D O a n d D o N o t D i s t u r b ( S S - D N D ) Protocol interaction are specified in subclause 6.6. 6 . 1 0 . 1 2 I n t e r a c t i o n b e t we e n S S - D N D O a n d C a l l I n t r u s i o n ( S S - C I ) The following protocol interaction shall apply if SS-CI is supported in accordance with ECMA-203. 6.10.12.1 Actions at the Terminating PINX On receiving a SETUP message containing a callIntrusionRequest invoke APDU together with a doNotDisturbOverrideQ invoke APDU, the procedures of SS-DNDO shall apply and, if DND is not active or is successfully overridden, the procedures of SS-CI shall apply.
6.11
SS-DND and SS-DNDO parameter values (timers) The following timers apply:
6.11.1
Timer T1 Timer T1 operates at the Activating PINX during state DND-aWait. Its purpose is to protect against the absence of a response to the doNotDisturbActivateQ invoke APDU. Timer T1 shall have a value not less than 15 s.
6.11.2
Timer T2 Timer T2 operates at the Deactivating PINX during state DND-dWait. Its purpose is to protect against the absence of a response to the doNotDisturbDeactivateQ invoke APDU. Timer T2 shall have a value not less than 15 s.
6.11.3
Timer T3 Timer T3 operates at the Interrogating PINX during state DND-iWait. Its purpose is to protect against the absence of a response to the doNotDisturbInterrogateQ invoke APDU.
- 22 -
Timer T3 shall have a value not less than 15 s. 6.11.4
Timer T4 Timer T4 operates at the Originating PINX during state DNDO-oAwaitExecResult. Its purpose is to protect against the absence of a response to the doNotDisturbOvrExecute invoke APDU. Timer T4 shall have a value not less than 15 s.
- 23 -
Annex A ( n o r ma tiv e )
Signalling protocol for the support of Path Retention
This annex is applicable to Originating PINXs that support SS-DNDO with path retention and to Terminating PINXs that support SS-DNDO. A similar annex will appear in other standards that make use of the generic mechanism for path retention.
A.1
Path Retention description Path retention is a generic mechanism which can be used by supplementary services during call establishment. Path retention is invoked by the Originating PINX either for one supplementary service or for several supplementary services at the same time. Invocation for a particular supplementary service means that the network connection is to be retained if the Terminating PINX encounters conditions in which it is appropriate to invoke that supplementary service. The Originating PINX is informed of the reason for retaining the connection so that it can decide (e.g. by consulting the calling user) whether to invoke the supplementary service. Under some circumstances in which the network connection is retained, more than one of the supplementary services for which path retention has been invoked may be applicable. Successive retentions of the network connection by the Terminating PINX following a single invocation of path retention by the Originating PINX are possible as a result of different conditions being encountered at the Terminating PINX. When an attempt is made to invoke a supplementary service for which the network connection has been retained, a further condition can be encountered that can cause the network connection to be retained again for the same supplementary service or a different supplementary service. Path retention is specified in terms of a Path Retention entity existing within the Coordination Function at the Originating PINX and at the Terminating PINX.
A.2
Path Retention operational requirements
A.2.1
Requirements on the Originating PINX Call establishment procedures for the outgoing side of an inter-PINX link, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.
A.2.2
Requirements on the Terminating PINX Call establishment procedures for the incoming side of an inter-PINX link, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.
A.2.3
Requirements on a Transit PINX Call establishment procedures, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.
A.3
Path Retention coding requirements
A.3.1
Operations The operations pathRetain and serviceAvailable as defined in subclause 6.3.1 shall apply. Within the ARGUMENT of operation pathRetain, the element of type ServiceList may contain bits other than those
- 24 -
named in subclause 6.3.1, in order to request path retention for other supplementary services. Within the ARGUMENT of operation serviceAvailable, the element of type ServiceList may contain bits other than those named in subclause 6.3.1, in order to indicate retention of the network connection for other supplementary services.
A.3.2
Information elements APDUs of the operations pathRetain and serviceAvailable shall be coded in the Facility information element in accordance with ECMA-165. When conveying an APDU of operation pathRetain or serviceAvailable, the NFE shall be included. In the case of an invoke APDU the destinationEntity data element of the NFE shall contain value endPINX. When conveying an invoke APDU of operation pathRetain or serviceAvailable, the Interpretation APDU shall contain value discardAnyUnrecognisedInvokePdu.
A.3.3
Messages The Facility information element shall be conveyed in the messages as specified in clause 10 of ECMA165. The basic call messages shall be used for call establishment as specified in ECMA-143.
A.4
Path Retention state definitions
A.4.1
States at the Originating PINX The procedures at the Originating PINX are written in terms of the following conceptual states existing within the Path Retention entity in that PINX in association with a particular call.
A . 4 . 1 . 1 P R TO - I d le Path retention is not operating. A . 4 . 1 . 2 P R TO - R e q u e s t e d A pathRetain invoke APDU has been sent and the Originating PINX is waiting for a serviceAvailable invoke APDU from the Terminating PINX. A . 4 . 1 . 3 P R TO - R e t a in e d A serviceAvailable invoke APDU has been received and the network connection is retained. A . 4 . 1 . 4 P R TO - I n v o k in g Invocation of a supplementary service is being attempted using a retained network connection.
A.4.2
States at the Terminating PINX The procedures at the Terminating PINX are written in terms of the following conceptual states existing within the Path Retention entity in that PINX in association with a particular incoming call.
A . 4 . 2 . 1 P R TT- I d le Path retention is not operating. A . 4 . 2 . 2 P R TT- R e q u e s t e d A pathRetain invoke APDU has been received and the Terminating PINX is waiting until conditions for retaining the network connection are encountered. A . 4 . 2 . 3 P R TT- R e t a in e d A serviceAvailable invoke APDU has been sent and the network connection is retained. A . 4 . 2 . 4 P R TT- I n v o k in g Invocation of a supplementary service is being attempted using a retained network connection.
A.5
Path Retention signalling procedures for invocation and operation
A.5.1
Actions at the Originating PINX The SDL representation of procedures at the Originating PINX is shown in A.9.1.
- 25 -
On sending a SETUP message for call establishment, if path retention is required for allowing the possibility of invoking one or more supplementary services on encountering certain conditions at the Terminating PINX, the Originating PINX shall include a pathRetain invoke APDU in the SETUP message and shall enter state PRTO-Requested. In the element of type ServiceList in the ARGUMENT, any bit corresponding to a supplementary service for which path retention is required shall be set to ONE and all other bits shall be set to ZERO. On receipt of a serviceAvailable invoke APDU in a PROGRESS or a FACILITY message in state PRTO-Requested, the Originating PINX shall enter state PRTO-Retained. In state PRTO-Requested, if the Originating PINX determines that retention of the network connection can no longer occur (e.g. on receipt of a CONNECT message), it shall enter state PRTO-Idle. During state PRTO-Retained, invocation of any of the supplementary services indicated in the serviceAvailable invoke APDU may be requested. If invocation is requested (by sending the appropriate APDU in a FACILITY message), the Terminating PINX shall enter state PRTO-Invoking. In state PRTO-Invoking, if the supplementary service concerned is successfully invoked, the Originating PINX shall either: i) if there is a possibility of the network connection being retained again prior to completion of call establishment (e.g. to allow for the possibility of invoking another supplementary service or for the possibility of invoking the same supplementary service again), enter state PRTO-Requested again; or ii) enter state PRTO-Idle. In state PRTO-Invoking, if the supplementary service concerned fails to be invoked successfully, the Originating PINX shall either: i) if the network connection is still retained to allow the possibility of invoking another supplementary service, enter state PRTO-Retained again; or ii) enter state PRTO-Idle. If, in any state other than PRTO-Idle, the call is released, state PRTO-Idle shall be entered.
A.5.2
Actions at the Terminating PINX The SDL representation of procedures at the Terminating PINX is shown in A.9.2. On receipt of a pathRetain invoke APDU in a SETUP message, the Terminating PINX shall enter state PRTT-Requested and record the list of supplementary services for which path retention has been requested, as indicated by the element of type ServiceList. If, during state PRTT-Requested, a condition is encountered in which it is appropriate to invoke one or more of the supplementary services for which path retention has been requested, the Terminating PINX shall retain the network connection, send a serviceAvailable invoke APDU to the Originating PINX, start timer PRT1 and enter state PRTT-Retained. In the element of type ServiceList in the ARGUMENT, any bit corresponding to a supplementary service that can be invoked at this stage and for which path retention has been requested shall be set to ONE and all other bits shall be set to ZERO. This procedure replaces the normal procedure appropriate to the condition that has been encountered. The serviceAvailable invoke APDU shall be sent either in a FACILITY message or, if a PROGRESS message is to be sent at the same time, in the PROGRESS message. A PROGRESS message containing a Progress indicator information element with Progress description no. 8 (in-band information or appropriate pattern now available) shall be sent if this Progress description has not already been sent for this call. NOTE It is necessary that this Progress description be sent, as a means of ensuring that basic call timer T310 is stopped at other PINXs. However, if this Progress description has already been sent in conjunction with an earlier serviceAvailable invoke APDU for this call, it need not be repeated. In state PRTT-Requested, if the Terminating PINX determines that retention of the network connection can no longer occur (e.g. on sending a CONNECT message), it shall enter state PRTT-Idle.
- 26 -
In state PRTT-Retained, on receipt of an invocation request from the Originating PINX for any of the supplementary services for which the network connection has been retained, the Terminating PINX shall stop timer PRT1 and enter state PRTT-Invoking. In state PRTT-Invoking, if the supplementary service concerned is successfully invoked, the Terminating PINX shall either: i) if there is a possibility of the network connection being retained again prior to completion of call establishment (e.g. to allow for the possibility of invoking another supplementary service or for the possibility of invoking the same supplementary service again), enter state PRTT-Requested again; or ii) enter state PRTT-Idle. In state PRTT-Invoking, if the supplementary service concerned fails to be invoked successfully, the Terminating PINX shall either: i) continue to retain the network connection, return to state PRTT-Retained and start timer PRT1 if there are other supplementary services for which the network connection has been retained and that are still able to be invoked; or ii) enter state PRTT-Idle and allow the call to proceed as specified for failure of the supplementary service concerned (e.g. initiate release of the call). In case i), any APDU sent to the Originating PINX to indicate failure of the requested supplementary service shall be sent in a FACILITY message. On expiry of timer PRT1, the Terminating PINX shall enter state PRTT-Idle and initiate call clearing in accordance with ECMA-143. If, in any state other than PRTT-Idle, the call is released, state PRTT-Idle shall be entered and timer PRT1, if running, shall be stopped.
A.5.3
Actions at a Transit PINX No special actions are required in support of path retention.
A.6
Path Retention impact of interworking with public ISDNs On a call from a public ISDN that does not support an equivalent mechanism, path retention shall not be requested by the Incoming Gateway PINX. On a call from a PISN to a public ISDN that does not support an equivalent mechanism, the Outgoing Gateway PINX shall, on encountering a condition in the public ISDN in which it is appropriate to invoke one or more of the supplementary services for which path retention has been requested, either: i) proceed as if path retention had not been requested; or ii) retain the network connection and allow invocation of the supplementary services concerned in accordance with A.5.2. NOTE 1 If invocation of a supplementary service is requested while the network connection is retained, the Outgoing Gateway PINX is responsible for establishing a new network connection through the public ISDN in order to request invocation of the supplementary service. Failure to establish a new network connection (e.g. because of network congestion) can cause the Outgoing Gateway PINX to reject the supplementary service and release the call. NOTE 2 At the time of publication of this Standard, no equivalent mechanism was specified for public ISDNs.
A.7
Path Retention impact of interworking with non-ISDNs When interworking with a non-ISDN that does not support an equivalent mechanism, the procedures defined in A.6 for interworking with a public ISDN that does not support an equivalent mechanism shall apply.
- 27 -
When interworking with a non-ISDN that does support an equivalent mechanism, the two networks may cooperate in the operation of path retention. In this case, either the Originating PINX functionality or the Terminating PINX functionality will be provided in the non-ISDN. The Incoming or Outgoing Gateway PINX shall provide conversion between the signalling protocol specified in this Standard and the signalling protocol of the other network.
A.8
Path Retention parameter values (timers) Timer PRT1 operates at the Terminating PINX during state PRTT-Retained. Its purpose is to protect against absence of a supplementary service invocation request as a response to the serviceAvailable invoke APDU. Timer PRT1 shall have a value not less than 60 s.
A.9
Specification and Description Language (SDL) - Representation of procedures (informative) The diagrams in this annex use the Specification and Description Language defined in ITU-T Rec. Z.100 (1999). Each diagram represents the behaviour of a Path Retention entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Path Retention entity as a part of the coordination function uses the services of Generic Functional Procedures Control and Basic Call Control and provides services to the various Supplementary Service Control entities. Where an output symbol represents a primitive to other parts of 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 operations APDU(s) contained in that message. In the 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 other parts of the coordination function, and that primitive is the result of a PSS1 message being received, the input symbol bears the name of the message and any remote operations APDU(s) contained in that message. In the 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 abbreviation is used: inv.
invoke APDU.
- 28 -
A.9.1
SDL representation of Path Retention at the Originating PINX Figure A.1 shows the behaviour of a Path Retention entity within the Originating PINX. In figure A.1 output signals to the right represent messages sent via protocol control, input signals from the right represent messages received via protocol control, and input signals from the left represent internal primitives.
!
"#$ % & # !
' ( !
)
F ig u r e A . 1 ( s h e e t 1 o f 2 ) - S D L r e p r e s e n t a t io n o f P a t h R e t e n t io n a t t h e O r ig in a t in g P I N X
- 29 -
!
!
F ig u r e A . 1 ( s h e e t 2 o f 2 ) - S D L r e p r e s e n t a t io n o f P a t h R e t e n t io n a t t h e O r ig in a t in g P I N X
- 30 -
A.9.2
SDL representation of Path Retention at the Terminating PINX Figure A.2 shows the behaviour of a Path Retention entity within the Terminating PINX. In figure A.2 output signals to the left represent messages sent via protocol control, input signals from the left represent messages received via protocol control, and input signals from the right represent internal primitives.
!
"#
#
#
$%&' () % !
*
* +
*
# , ! "#
*
-
Figure A.2 (sheet 1 of 2) - SDL representation of Path Retention at the Terminating PINX
- 31 -
!
"#
!
"#
Figure A.2 (sheet 2 of 2) - SDL representation of Path Retention at the Terminating PINX
- 32 -
- 33 -
Annex B ( n o r ma tiv e )
Protocol Implementation Conformance Statement (PICS) proforma
B.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: − 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 the 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 PICS's; − by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.
B.2 B.2.1
Instructions for completing the PICS proforma General structure of the PICS proforma The PICS proforma is a fixed format questionnaire divided into sub-clauses 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).
- 34 -
B.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.
B.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 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.
- 35 -
B.3 B.3.1
PICS proforma for ECMA-194 : SS-DND 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).
B.3.2
Protocol summary Protocol version
1.0
Addenda implemented (if applicable) Amendments implemented Have any exception items been required (see B.2.3)?
Date of statement
No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)
- 36 -
B.3.3 Item
General Question/feature
References
Status
N/A
Support
A1
Behaviour as Terminating PINX for SS-DND
o.1
Yes [ ]
No [ ]
A2
Behaviour as Activating PINX for remote activation of SS-DND
o.1
Yes [ ]
No [ ]
A3
Behaviour as Deactivating PINX for remote deactivation of SS-DND
o.1
Yes [ ]
No [ ]
A4
Behaviour as Interrogating PINX for remote interrogation of SS-DND
o.1
Yes [ ]
No [ ]
A5
Behaviour as Served User PINX for remote activation, deactivation, and interrogation of SS-DND
A1:o
Yes [ ]
No [ ]
A6
Behaviour as Incoming Gateway PINX for SS-DND
Yes [ ]
No [ ]
6.7.1 6.8.1
o
[]
- 37 -
B.3.4 Item
Procedures Question/feature
References
Status
N/A
Support
B1
Support of relevant ECMA-143 and ECMA-165 procedures at a Terminating PINX
6.2.2
A1:m
[]
m: Yes [ ]
B2
Support of relevant ECMA-143 and ECMA-165 procedures at an Activating PINX
6.2.4
A2:m
[]
m: Yes [ ]
B3
Support of relevant ECMA-143 and ECMA-165 procedures at a Deactivating PINX
6.2.5
A3:m
[]
m: Yes [ ]
B4
Support of relevant ECMA-143 and ECMA-165 procedures at an Interrogating PINX
6.2.6
A4:m
[]
m: Yes [ ]
B5
Support of relevant ECMA-143 and ECMA-165 procedures at a Served User PINX
6.2.7
A5:m
[]
m: Yes [ ]
B6
Signalling procedures at a Terminating PINX, invocation
6.5.1
A1:m
[]
m: Yes [ ]
B7
Signalling procedures at an Activating PINX
6.5.3
A2:m
[]
m: Yes [ ]
B8
Signalling procedures at a Deactivating PINX
6.5.4
A3:m
[]
m: Yes [ ]
B9
Signalling procedures at an Interrogating PINX
6.5.5
A4:m
[]
m: Yes [ ]
B10
Signalling procedures at a Served User PINX, activation
6.5.6.1.1 6.5.6.2.1
A5:o
[]
Yes [ ]
No [ ]
B11
Signalling procedures at a Served User PINX, deactivation
6.5.6.1.2 6.5.6.2.2
A5:o
[]
Yes [ ]
No [ ]
B12
Signalling procedures at a Served User PINX, interrogation
6.5.6.1.3 6.5.6.2.3
A5:o
[]
Yes [ ]
No [ ]
- 38 -
B.3.5
Coding
Item
Question/feature
References
Status
N/A
D1
Sending of Notification Description doNotDisturb in a Notification information element
6.3.2, 6.3.3.2 6.3.4
A1:m
[]
m: Yes [ ]
D2
Sending of doNotDisturbActivateQ invoke APDU and receipt of return result and return error APDUs
6.3.1, 6.3.3.1 6.3.4
A2:m
[]
m: Yes [ ]
D3
Sending of doNotDisturbDeactivateQ invoke APDU and receipt of return result and return error APDUs
6.3.1, 6.3.3.1 6.3.4
A3:m
[]
m: Yes [ ]
D4
Sending of doNotDisturbInterrogateQ invoke APDU and receipt of return result and return error APDUs
6.3.1, 6.3.3.1 6.3.4
A4:m
[]
m: Yes [ ]
D5
Receipt of doNotDisturbActivateQ invoke APDU and sending of return result and return error APDUs
6.3.1, 6.3.3.1 6.3.4
A5:m
[]
m: Yes [ ]
D6
Receipt of doNotDisturbDeactivateQ invoke APDU and sending of return result and return error APDUs
6.3.1, 6.3.3.1 6.3.4
A5:m
[]
m: Yes [ ]
D7
Receipt of doNotDisturbInterrogateQ invoke APDU and sending of return result and return error APDUs
6.3.1, 6.3.3.1 6.3.4
A5:m
[]
m: Yes [ ]
References
Status
N/A
B.3.6 Item
Support
Timers Question/feature
Support
E1
Support of timer T1
6.11.1
A2:m
[]
m: Yes [ ] Value [ ]
E2
Support of timer T2
6.11.2
A3:m
[]
m: Yes [ ] Value [ ]
E3
Support of timer T3
6.11.3
A4:m
[]
m: Yes [ ] Value [ ]
B.3.7
Interactions between SS-DND and Call Completion to Busy Subscriber (SSCCBS)
Item
Question/feature
J1
Support of SS-CCBS (Terminating PINX)
J2
Interaction at the Terminating PINX
c.1: if (A1 and J1) then mandatory, else N/A
Reference
Status
N/A
o 6.9.3.1
c.1
Support Yes [ ] No [ ]
[]
m: Yes [ ]
- 39 -
B.3.8
Interactions between SS-DND and Call Completion on No Reply (SS-CCNR)
Item
Question/feature
K1
Support of SS-CCNR (Terminating PINX)
K2
Interaction at the Terminating PINX
c.1: if (A1 and K1) then mandatory, else N/A
Reference
Status
N/A
o 6.9.4.1
c.1
Support Yes [ ] No [ ]
[]
m: Yes [ ]
- 40 -
B.4 B.4.1
PICS proforma for ECMA-194 : SS-DNDO 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).
B.4.2
Protocol summary Protocol version
1.0
Addenda implemented (if applicable) Amendments implemented Have any exception items been required (see B.2.3)?
Date of statement
No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)
- 41 -
B.4.3
General
Item
Question/feature
References
Status
N/A
Support
F1
Behaviour as Terminating PINX for SS-DNDO
o.1
Yes [ ]
No [ ]
F2
Behaviour as Originating PINX for SS-DNDO
o.1
Yes [ ]
No [ ]
F3
Behaviour as Incoming Gateway PINX for SS-DNDO
6.7.2 6.8.2
o
Yes [ ]
No [ ]
F4
Behaviour as Outgoing Gateway PINX for SS-DNDO
6.7.2 6.8.2
o
Yes [ ]
No [ ]
References
Status
N/A
B.4.4 Item
Procedures Question/feature
Support
G1
Support of relevant ECMA-143 and ECMA-165 procedures at a Terminating PINX
6.2.2
F1:m
[]
m: Yes [ ]
G2
Support of relevant ECMA-143 and ECMA-165 procedures at an Originating PINX
6.2.3
F2:m
[]
m: Yes [ ]
G3
Signalling procedures without path retention at a Terminating PINX
6.6.1
F1:m
[]
m: Yes [ ]
G4
Signalling procedures with path retention at a Terminating PINX
6.6.1 A.5.2
F1:m
[]
m: Yes [ ]
G5
Signalling procedures at an Originating PINX in support of DNDO without path retention
6.6.2.1.1
F2:o.2
[]
Yes [ ]
No [ ]
G6
Signalling procedures at an Originating PINX in support of DNDO with path retention
6.6.2.1.2 A.5.1 6.6.2.2
F2:o.2
[]
Yes [ ]
No [ ]
- 42 -
B.4.5
Coding
Item
Question/feature
References
Status
N/A
H1
Sending of doNotDisturbOverrideQ invoke APDU
6.3.1 6.3.3.1
G5:m
[]
m: Yes [ ]
H2
Receipt of doNotDisturbOverrideQ invoke APDU
6.3.1 6.3.3.1
F1:m
[]
m: Yes [ ]
H3
Sending of pathRetain invoke APDU
6.3.1 6.3.3.1
G6:m
[]
m: Yes [ ]
H4
Receipt of pathRetain invoke APDU
6.3.1 6.3.3.1
F1:m
[]
m: Yes [ ]
H5
Sending of serviceAvailable invoke APDU
6.3.1 6.3.3.1
F1:m
[]
m: Yes [ ]
H6
Receipt of serviceAvailable invoke APDU
6.3.1 6.3.3.1
G6:m
[]
m: Yes [ ]
H7
Sending of doNotDisturbOvrExecuteQ invoke APDU and receipt of return result and return error APDUs
6.3.1 6.3.3.1
G6:m
[]
m: Yes [ ]
H8
Receipt of doNotDisturbOvrExecuteQ invoke APDU and sending of return result and return error APDUs
6.3.1 6.3.3.1
F1:m
[]
m: Yes [ ]
References
Status
N/A
B.4.6 Item
Support
Timers Question/feature
Support
I1
Support of timer T4
6.11.4
G6:m
[]
m: Yes [ ] Value [ ]
I2
Support of timer PRT1
A.8
F1:m
[]
m: Yes [ ] Value [ ]
B.4.7 Item
Interactions between SS-DNDO and Call Forwarding Unconditional (SS-CFU) Question/feature
Reference
Status
N/A
Support
L1
Support of SS-CFU (Rerouteing PINX)
o
Yes [ ] No [ ]
L2
Support of SS-CFU (Originating PINX)
o
Yes [ ] No [ ]
L3
Interactions at Rerouteing PINX
6.10.6.1
L1:m
[]
m: Yes [ ]
L4
Interactions at Originating PINX
6.10.6.2
c.1
[]
m: Yes [ ]
c.1: if (F2 and L2) then mandatory, else N/A
- 43 -
B.4.8 Item
Interactions between SS-DNDO and Call Forwarding Busy (SS-CFB) Question/feature
Reference
Status
N/A
Support
M1
Support of SS-CFB (Originating PINX)
o
Yes [ ] No [ ]
M2
Support of SS-CFB (Rerouteing PINX)
o
Yes [ ] No [ ]
M3
Interactions at Rerouteing PINX
6.10.7.1
c.1
[]
m: Yes [ ]
M4
Interactions at Originating PINX
6.10.7.2
c.2
[]
m: Yes [ ]
Status
N/A
Support
c.1: if ((F1 or F2) and M2) then mandatory, else N/A c.2: if (F2 and M1) then mandatory, else N/A
B.4.9 Item
Interactions between SS-DNDO and Call Offer (SS-CO) Question/feature
N1
Support of SS-CO (Terminating PINX)
N2
Interactions at the Terminating PINX
Reference
o 6.10.10.1
c.1
Yes [ ] No [ ] []
m: Yes [ ]
N/A
Support
c.1: if (F1 and N1) then mandatory, else N/A
B.4.10 Interactions between SS-DNDO and Call Intrusion (SS-CI) Item
Question/feature
O1
Support of SS-CI (Terminating PINX)
O2
Interactions at the Terminating PINX
c.1: if (F1 and O1) then mandatory, else N/A
Reference
Status o
6.10.12.1
c.1
Yes [ ] No [ ] []
m: Yes [ ]
- 44 -
- 45 -
Annex C ( in f o r ma tiv e )
Examples of message sequences
This annex describes some typical message flows for SS-DND and SS-DNDO. The following conventions are used in the figures of this annex: 1
The following notation is used:
Basic call message containing SS-DND or SS-DNDO information. Basic call message without SS-DND or SS-DNDO information. Call independent signalling connection message containing SS-DND or SS-DNDO information. Call independent signalling connection message without SS-DND or SS-DNDO information.
.. .. ... .. .. ... .. ..
Symbolic primitive containing SS-DND or SS-DNDO information. Symbolic primitive without SS-DND or SS-DNDO information.
xxx.inv xxx.res xxx.err xxx.rej
Invoke APDU for operation xxx Return result APDU for operation xxx Return error APDU for operation xxx Reject APDU for operation xxx
2
The figures show messages exchanged via Protocol Control between PINXs involved in SS-DND and SSDNDO. Only messages relevant to SS-DND or SS-DNDO 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-DND or SS-DNDO is not shown in all cases.
4
Some interactions with users are included in the form of symbolic primitives. The actual protocol at the terminal interface is outside the scope of this Standard.
5
The following abbreviations are used: dndActivate dndDeactvte dndIntrgate dndOverride dndOvrExec pathRetain svcAvail
doNotDisturbActivateQ; doNotDisturbDeactivateQ; doNotDisturbInterrogateQ; doNotDisturbOverrideQ; doNotDisturbOvrExecuteQ; pathRetain; serviceAvailable.
- 46 -
Example message sequences for normal operation Figure C.1 shows an example of a normal operation of SS-DND when a tone or announcement is provided by the Terminating PINX. The calling user is notified of the encountered do not disturb condition. The served user is notified of the unsuccessful call attempt. calling
Originating
Transit
Terminating
called
user
PI N X
PI NX
PI N X
user
Setup request
SETUP SETUP
CA LL PR OCEEDING
donotdisturb ..... . .. . .. .. .. ... indication
PRO GRESS Progress description No. 8 cause call rejected Notif. Descr. doNotDisturb DISC ONNECT
Release indication
RELEASE
CALL PRO CEEDING
PRO GRESS Progress description No. 8 cause call rejected Notif. Descr. doNotDisturb
dndInvoked .. .. ... .. .. ... .. . . indication
DISC ONNECT
RELEASE RELEASE COM PLETE
RELEASE C OMPLETE
Figure C.1 - Message sequence for normal operation of SS-DND with tone or announcement to Originating PINX
- 47 -
Figure C.2 shows an example of a normal operation of SS-DND when no tone or announcement is provided by the Terminating PINX.
calling
Originating
Transit
Terminating
called
user
PI NX
PI NX
PI NX
user
SETUP SETUP CALL PRO CEEDING
CA LL PR OCEEDING
DISCO NNECT
DISCONNECT
donotdisturb ... . ... ... . ... .. .. indication
Cause call rejected otif. Descr. doNotDisturb
Cause call rejected otif. Descr. doNotDisturb
dndInvoked .. ... .. .. ..... .. .. indication
RELEASE
RELEASE
RELEASE COM PLETE RELEASE C OMPLETE
Figure C.2 - Message sequence for normal operation of SS-DND with no tone or announcement to Originating PINX Figure C.3 shows an example of a normal operation of SS-DNDO without using path retention. In this example override is allowed, the called user is not busy, and alerting commences. calling
Originating
Transit
Terminating
called
user
PI N X
PI N X
PI NX
user
Setup . ... ... . ... ... .. .. request dndOverride.inv
SETUP dndOverride.inv
SETUP dndOverride.inv
CALL PROCEEDING
CALL PROCEEDING Setup . . .. .. .. . .. . . .. ... indication Alerting
ALERTING
ALERTING
request
Alerting indica tion
F i g u r e C . 3 - M e s s a g e s e q u e n c e f o r n o r m a l o p e r a t i o n o f S S - D N D O wit h o u t u s i n g P a t h R e t e n t i o n , override successful
- 48 -
Figure C.4 shows an example of a normal operation of SS-DNDO using path retention, and override is successful. In this example the calling user is consulted whether to apply SS-DNDO, and he chooses to request this. calling
Originating
user
PI NX Setup
Transit
Terminating
called
PI NX
PI NX
user
SETUP
request
pathRetain.inv(dndo)
SET UP pathRetain.inv(dndo) CALL PRO CEEDING
CA LL PR OCEEDING
for user B PRO GR ESS
PRO GRESS
Report ... . ... ... . ... .... indication
Progr. Descr. No. 8 svcAvail.inv(dndo)
Progr. Descr. No. 8 svcAvail.inv(dndo)
dndo-invokable DNDO_INV .. ... ... . ... ... . .. request
FACILITY
FACILITY
dndOvrExec.inv
dndOvrExec.inv FACILITY
FACILITY
DNDO_INV ... . ... ... . ... .... confirmation
Setup
dndOvrExec.res
dndOvrExec.res
indication Alerting
ALERTING
ALERTING
Alerting
DND active
request
indication
Figure C.4 - Message sequence for normal operation of SS-DNDO using Path Retention, consultation, override is allowed Figure C.5 shows an example of a normal operation of SS-DNDO when override is not allowed. In this example the DNDOCL of the calling user is not sufficient to override the DNDPL of the called user. The call is further processed according to the procedures of SS-DND. calling user
Originating P I NX
Transit
Terminating P I NX
PI NX
called user
SETUP pathR etain.inv(dndo)
SET UP pathRetain.inv(dndo)
CALL PROCEEDING
DISCONNECT Progress description No. 8 Cause call rejected
CALL PR OCEEDING
DND active for the called user DNDPL > DNDOCL
DISCON NECT Progress description No. 8 Cause call rejected
Further processing is according to the procedures of SS-DND
Figure C.5 - Message sequence for normal operation of SS-DNDO with Path Retention, override is not allowed
- 49 -
Figure C.6 shows an example of remote activation of SS-DND. Served
Served user
Activating
Activating
user
PI NX
PI NX
user
dndActivate . . . . . .. . . . . . .. . . . . request
SETUP dndActivate.inv CALL PROCEEDING
CONNECT dndActivate . .. . . . .. .. . . . .. .. . confirm
dndActivate.res
dndActivate . .. .. . . . .. .. . . . .. . indication
RELEASE RELEASE COMPLETE
Figure C.6 - Remote activation of SS-DND Figure C.7 shows an example of remote deactivation of SS-DND. Served
Served user
Deactivating
Deactivating
user
PI NX
PI NX
user
SETUP
dndDeactvte . .. . .. . . . . .. . . . . . . request
dndDeactvte.inv CALL PROCEEDING
CONNECT dndDeactvte . . . . . .. . . . . . .. . . . . indication
dndDeactvte.res RELEASE
dndDeactvte . .. . . . .. .. . . . .. .. . confirm
RELEASE COMPLETE
Figure C.7 - Remote deactivation of SS-DND
- 50 -
Figure C.8 shows an example of remote interrogation of SS-DND. Served user
Interrogating
Interrogating
PI NX
PI NX
user
SETUP
dndIntrgate . ..... .. ....... .. . request
dndIntrgate.inv CALL PROCEEDING
CONNECT dndIntrgate.res RELEASE
dndIntrgate . .. . . . .. .. . . . .. .. . confirm
RELEASE COMPLETE
F ig u r e C . 8 - R e m o t e in t e r r o g a t io n o f S S - D N D
- 51 -
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 Recommendation Z.100 (1999). Each diagram represents the behaviour of an SS-DND 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 message being sent, the output symbol bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. In the 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 message being received, the input symbol bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. In the 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. res. err. rej.
invoke APDU return result APDU return error APDU reject APDU
dndActivate dndDeactvte dndIntrgate dndOverride dndOvrExec
doNotDisturbActivateQ doNotDisturbDeactivateQ doNotDisturbInterrogateQ doNotDisturbOverrideQ doNotDisturbOvrExecuteQ
DNDO-oWaitExec
DNDO-oAwaitExecResult
- 52 -
D.1
SDL representation of SS-DND and SS-DNDO at a Terminating PINX Figure D.1 shows the behaviour of an SS-DND Supplementary Service Control entity within the Terminating PINX. Input signals from the left and output signals to the left represent primitives from and to the coordination functions.
!" # $ %! & $'( % # & % & %" ) !
!$!
,) &
$& % ,)
) % " $& $)
- *
)!
* + % )'
% )'
% % " ' $)
' $
Figure D.1 - Terminating PINX behaviour
- 53 -
D.2
SDL representation of SS-DNDO at an Originating PINX Figure D.2 shows the behaviour of an SS-DNDO Supplementary Service Control entity within the Originating PINX. Input signals from the left and output signals to the left represent primitives from and to the user or an entity acting on behalf of the user. Input signals from the right and output signals to the right represent primitives from and to the coordination functions. Also protocol timer expiry is indicated by an input signal from the right.
!
& ' () % * +
'
%
"#
$ %
% &
F ig u r e D . 2 - O r ig in a t in g P I N X b e h a v io u r
% &
- 54 -
D.3
SDL representation of SS-DND at an Activating PINX Figure D.3 shows the behaviour of an SS-DND Supplementary Service Control entity within the Activating PINX. Input signals from the left and output signals to the left represent primitives from and to the user or an entity acting on behalf of the user. Input signals from the right and output signals to the right represent primitives from and to the coordination functions. Also protocol timer expiry is indicated by an input signal from the right.
F ig u r e D . 3 - A c t iv a t in g P I N X b e h a v io u r
- 55 -
D.4
SDL representation of SS-DND at a Deactivating PINX Figure D.4 shows the behaviour of an SS-DND Supplementary Service Control entity within the Deactivating PINX. Input signals from the left and output signals to the left represent primitives from and to the user or an entity acting on behalf of the user. Input signals from the right and output signals to the right represent primitives from and to the coordination functions. Also protocol timer expiry is indicated by an input signal from the right.
F ig u r e D . 4 - D e a c t iv a t in g P I N X b e h a v io u r
- 56 -
D.5
SDL representation of SS-DND at an Interrogating PINX Figure D.5 shows the behaviour of an SS-DND Supplementary Service Control entity within the Interrogating PINX. Input signals from the left and output signals to the left represent primitives from and to the user or an entity acting on behalf of the user. Input signals from the right and output signals to the right represent primitives from and to the coordination functions. Also protocol timer expiry is indicated by an input signal from the right.
F ig u r e D . 5 - I n t e r r o g a t in g P I N X b e h a v io u r
- 57 -
D.6
SDL representation of SS-DND at a Served User PINX Figure D.6 shows the behaviour of an SS-DND Supplementary Service Control entity within the Served User PINX. Input signals from the left and output signals to the left represent primitives from and to the coordination functions.
Figure D.6 - Served User PINX behaviour
- 58 -
- 59 -
Annex E ( in f o r ma tiv e )
Imported ASN.1 definitions relating to numbers
The content of this annex has been deleted to remove duplicate ASN.1 definitions defined elsewhere.
- 60 -
- 61 -
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 third edition of ECMA-194, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the fourth edition the ASN.1 modules within ECMA-194 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 - D o - N o t - D is t u r b - 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 Do-Not-Disturb-Operations {iso(1) standard(0) pss1-do-not-disturb(14844) do-not-disturb-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)} basicServiceNotProvided, invalidServedUserNumber, notAvailable, userNotSubscribed, supplementaryServiceInteractionNotAllowed FROM General-Error-List {ccitt recommendation q 950 general-error-list (1)} PartyNumber FROM Addressing-Data-Elements {iso(1) standard(0) pss1-generic-procedures(11582) addressing-data-elements(9)} BasicService FROM Call-Diversion-Operations {iso(1) standard(0) pss1-call-diversion(13873) call-diversion-operations(0) } ;
DoNotDisturbActivate
::= OPERATION ARGUMENT DNDActivateArg RESULT DNDActivateRes ERRORS { userNotSubscribed, notAvailable, invalidServedUserNumber, basicServiceNotProvided, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, unspecified}
- 62 -
Ta b le F . 1 - D o - N o t - D is t u r b - 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 ) DoNotDisturbDeactivate
::= OPERATION ARGUMENT DNDDeactivateArg RESULT DummyRes ERRORS { userNotSubscribed, notAvailable, invalidServedUserNumber, notActivated, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, unspecified}
DoNotDisturbInterrogate
::= OPERATION ARGUMENT DNDInterrogateArg RESULT DNDInterrogateRes ERRORS { userNotSubscribed, notAvailable, invalidServedUserNumber, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, unspecified}
DoNotDisturbOverride
::= OPERATION ARGUMENT DNDOverrideArg
PathRetain
::= OPERATION ARGUMENT PathRetainArg
-- this operation may be used by other -- Supplementary Services using other -- values of the argument
ServiceAvailable
::= OPERATION ARGUMENT ServiceAvailableArg -- this operation may be used by other -- Supplementary Services using other -- values of the argument
DoNotDisturbOvrExecute
::= OPERATION ARGUMENT DummyArg RESULT DummyRes ERRORS {
DummyArg
::= CHOICE { null extension sequenceOfExtn }
notAvailable, temporarilyUnavailable, supplementaryServiceInteractionNotAllowed, unspecified}
NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension
- 63 -
Ta b le F . 1 - D o - N o t - D is t u r b - 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 ) DummyRes
::= CHOICE { null extension sequenceOfExtn }
NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension
DNDActivateArg
::= SEQUENCE { basicService BasicService, servedUserNr PartyNumber, argumentExtension CHOICE{ extension [1] IMPLICIT Extension, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }
DNDActivateRes
::= SEQUENCE { status SET OF SEQUENCE{ basicService BasicService, dndProtectionLevel DNDProtectionLevel OPTIONAL } OPTIONAL, resultExtension CHOICE{ extension [1] IMPLICIT Extension, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }
DNDDeactivateArg
::= SEQUENCE { basicService BasicService, servedUserNr PartyNumber, argumentExtension CHOICE{ extension [1] IMPLICIT Extension, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }
DNDInterrogateArg
::= SEQUENCE { servedUserNr PartyNumber, argumentExtension CHOICE{ extension [1] IMPLICIT Extension, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }
- 64 -
Ta b le F . 1 - D o - N o t - D is t u r b - 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 ) DNDInterrogateRes
::= SEQUENCE { status SET OF SEQUENCE { basicService BasicService, dndProtectionLevel DNDProtectionLevel OPTIONAL } OPTIONAL, resultExtension CHOICE{ extension [1] IMPLICIT Extension, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }
DNDOverrideArg
::= SEQUENCE { dndoCapabilityLevel DNDOCapabilityLevel, argumentExtension CHOICE{ extension [1] IMPLICIT Extension, sequenceOfExtn [2] IMPLICIT SEQUENCE OF Extension } OPTIONAL }
PathRetainArg
::= CHOICE { serviceList extendedServiceList serviceList extension
ServiceList, SEQUENCE { ServiceList, Extension }
} ServiceAvailableArg
::= CHOICE { serviceList extendedServiceList serviceList extension
ServiceList, SEQUENCE { ServiceList, Extension }
} DNDProtectionLevel
::= ENUMERATED { lowProtection(0), mediumProtection(1), highProtection(2), fullProtection(3) }
DNDOCapabilityLevel
::= ENUMERATED { overrideLowProt(1), overrideMediumProt(2), overrideHighProt(3) }
- 65 -
Ta b le F . 1 - D o - N o t - D is t u r b - 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 ) ServiceList
::= BIT STRING { dndo-low(1), dndo-medium(2), dndo-high(3) } (SIZE (1..32)) -- bits other than dndo-low, dndo-medium, or dndo-high, are reserved -- for other Supplementary Services
temporarilyUnavailable notActivated
ERROR ::= localValue 1000 ERROR ::= localValue 43
Unspecified
::= ERROR PARAMETER Extension
unspecified
Unspecified ::= localValue 1008
doNotDisturbActivateQ doNotDisturbDeactivateQ doNotDisturbInterrogateQ doNotDisturbOverrideQ doNotDisturbOvrExecuteQ pathRetain serviceAvailable
DoNotDisturbActivate DoNotDisturbDeactivate DoNotDisturbInterrogate DoNotDisturbOverride DoNotDisturbOvrExecute PathRetain ServiceAvailable
END
-- of Do-Not-Disturb-Operations
::= localValue 35 ::= localValue 36 ::= localValue 37 ::= localValue 38 ::= localValue 39 ::= localValue 41 ::= localValue 42
Ta b le F . 2 - D o - N o t - D is t u r b - N o t if ic 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 Do-Not-Disturb-Notifications {iso(1) standard(0) pss1-do-not-disturb(14844) do-not-disturb-notifications(1) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS
NOTIFICATION FROM Notification-macro {iso(1) standard(0) pss1-generic-procedures(11582) notification-macro(10)};
DoNotDisturb
::= NOTIFICATION ARGUMENT NULL
doNotDisturb
DoNotDisturb ::= localValue 2002
END
-- of Do-Not-Disturb-Notifications
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.