Standard ECMA-191 2nd E dition - J une 1997
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Offer Supplementary Service
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h
.
Standard ECMA-191 2nd E dition - J une 1997
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Offer Supplementary Service (COSD)
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h IW Ecma-191.doc
14-07-98 16,25
.
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. It has been produced under ITSTC work item M-IT-05 2.2 and under ETSI work item DE/ECMA-00008. This particular Standard specifies the Call Offer (CO) supplementary service. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. There is currently no equivalent service specified by ITU-T or ETSI for public ISDNs. Compared to the 1st Edition of Standard ECMA-191 (published by ECMA in June 1993), this 2nd Edition incorporates changes in order to achieve complete alignment with International Standard ISO/IEC 14841:1996(E) published by ISO/IEC in September 1996.
Adopted as 2nd Edition of Standard ECMA-191 by the General Assembly of June 1997.
.
- i -
Table of contents 1 Scope
1
2 Conformance
1
3 References (normative)
1
4 Definitions
2
4.1 External definitions
2
4.2 Other definitions
2
4.2.1 Additional network feature
2
4.2.2 Automatic call offer invocation timer
2
4.2.3 Busy
3
4.2.4 Call, basic call
3
4.2.5 Consultation timer
3
4.2.6 Offered call
3
4.2.7 Path retention
3
5 Acronyms
3
6 SS-CO stage 1 specification
4
6.1 Description
4
6.1.1 General description
4
6.1.2 Qualifications on applicability to telecommunication services
4
6.2 Procedures
4
6.2.1 Provision/withdrawal
4
6.2.2 Normal procedures
4
6.2.3 Exceptional procedures
5
6.3 Interactions with other supplementary services and ANFs
5
6.3.1 Calling Line Identification Presentation (SS-CLIP)
5
6.3.2 Connected Line Identification Presentation (SS-COLP)
5
6.3.3 Calling/Connected Line Identification Restriction (SS-CLIR)
6
6.3.4 Calling Name Identification Presentation (SS-CNIP)
6
6.3.5 Connected Name Identification Presentation (SS-CONP)
6
6.3.6 Calling/Connected Name Identification Restriction (SS-CNIR)
6
6.3.7 Completion of Calls to Busy Subscriber (SS-CCBS)
6
6.3.8 Completion of Calls on No Reply (SS-CCNR)
6
6.3.9 Call Transfer (SS-CT)
6
6.3.10 Call Forwarding Unconditional (SS-CFU)
6
6.3.11 Call Forwarding Busy (SS-CFB)
6
6.3.12 Call Forwarding No Reply (SS-CFNR)
6
6.3.13 Call Deflection (SS-CD)
6
6.3.14 Path Replacement (ANF-PR)
7
6.3.15 Do Not Disturb (SS-DND)
7
- ii -
6.3.16 Do Not Disturb Override (SS-DNDO)
7
6.3.17 Call Intrusion (SS-CI)
7
6.4 Interworking considerations
7
6.5 Overall SDL
7
7 SS-CO stage 2 specification
12
7.1 Functional model
12
7.1.1 Functional model description
12
7.1.2 Description of functional entities
13
7.1.3 Relationship of functional model to basic call functional model
13
7.2 Information flows
14
7.2.1 Definition of information flows
14
7.2.2 Relationship of information flows to basic call information flows
15
7.2.3 Examples of information flow sequences
16
7.3 Functional entity actions
26
7.3.1 Functional entity actions of FE1
26
7.3.2 Functional entity actions of FE2
26
7.4 Functional entity behaviour
26
7.4.1 Behaviour of FE1
26
7.4.2 Behaviour of FE2
33
7.5 Allocation of functional entities to physical equipment
36
7.6 Interworking considerations
36
1
Scope This Standard specifies the Call Offer supplementary service (SS-CO), which is applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. Call Offer (SS-CO) is a supplementary service which, on request from the calling user (or on that user's behalf), enables a call to be offered to a busy called user and to wait for that called user to accept this call. Supplementary service specifications are produced in three stages, according to the method described in ETS 300 387. This Standard contains the stage 1 and stage 2 specifications of SS-CO. The stage 1 specification (clause 6) specifies the supplementary service as seen by users of PISNs. The stage 2 specification (clause 7) identifies the functional entities involved in the supplementary service and the information flows between them. NOTE 1 For this Standard, stage 2 does not consider the split of functionality between a functional terminal and the local PINX. Terminal functions and local PINX functions are included in the same functional entity.
2
Conformance In order to conform to this Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the supplementary service specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clause 6 (stage 1) and clause 7 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.
3
References (normative) The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-142
Private Integrated Services Network - Circuit-mode 64 kbit/s Bearer Services - Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
ECMA-148
Private Integrated Services Network - Specification, Functional Model and Information Flows Identification Supplementary Services (International Standard ISO/IEC 14136)
ECMA-163
Private Integrated Services Network - Specification, Functional Model and Information Flows Name Identification Supplementary Services (International Standard ISO/IEC 13864)
ECMA-173
Private Integrated Services Network - Specification, Functional Model and Information Flows Call Diversion Supplementary Services (International Standard ISO/IEC 13872)
ECMA-177
Private Integrated Services Network - Specification, Functional Model and Information Flows Call Transfer Supplementary Service (International Standard ISO/IEC 13865)
ECMA-185
Private Integrated Services Network - Specification, Functional Model and Information Flows Call Completion Supplementary Services (International Standard ISO/IEC 13866)
ECMA-193
Private Integrated Services Network - Specification, Functional Model and Information Flows Do Not Disturb and Do Not Disturb Override Supplementary Services (International Standard ISO/IEC 14842)
ISO/IEC 11579-1
Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Part 1: Reference configuration for PISN Exchanges (PINX)
ETS 300 387
Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)
- 2 -
4
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. I.221
Common specific characteristics of services (1993)
ITU-T Rec. Z.100
Specification and description language (1993)
Definitions For the purposes of this Standard, the following definitions apply.
4.1
External definitions This Standard uses the following terms defined in other documents: – Basic service
(ITU-T Rec. I.210)
– Connection
(ITU-T Rec. I.112)
– Network Determined User Busy
(ITU-T Rec. I.221)
– Private Integrated Services Network (PISN)
(ISO/IEC 11579-1)
– Private Integrated Services Network Exchange (PINX)
(ISO/IEC 11579-1)
– Service
(ITU-T Rec. I.112)
– Signalling
(ITU-T Rec. I.112)
– Supplementary Service
(ITU-T Rec. I.210)
– User
(ECMA-142)
– User Determined User Busy
(ITU-T Rec. I.221)
This Standard refers to the following basic call functional entity (FEs) defined in ECMA-142: – Call Control (CC) – Call Control Agent (CCA) This Standard refers to the following basic call inter-FE relationships defined in ECMA-142: – r1 – r2 – r3 This Standard refers to the following basic call information flows defined in ECMA-142: – Release request/indication – Release response/confirmation – Report request/indication – Setup request/indication – Setup response/confirmation.
4.2 4.2.1
Other definitions Additional network feature A capability, over and above that of a basic service, provided by a PISN, but not directly to a PISN user.
4.2.2
Automatic call offer invocation timer A timer governing the time after which SS-CO is automatically invoked after the calling user has been informed that a call has failed because of busy at the destination. The duration of the timer is an implementation option.
- 3 -
4.2.3
Busy A property of a user for whom either a Network Determined User Busy or User Determined User Busy condition exists.
4.2.4
Call, basic call An instance of the use of a basic service.
4.2.5
Consultation timer A timer governing the time in which the calling user is allowed to request invocation of SS-CO after being informed that a call has failed because of busy at the destination. The duration of the timer is an implementation option.
4.2.6
Offered call A call that is in a waiting condition as a result of invocation of SS-CO against a busy called user.
4.2.7
Path retention The retaining of the network connection between the Originating CC and the Destination CC so that a supplementary service (such as SS-CO) can be invoked without establishing a new connection.
5
Acronyms ANF
Additional Network Feature
CC
Call Control (functional entity)
CCA
Call Control Agent (functional entity)
CCBS
Call Completion to Busy Subscriber
CCNR
Call Completion on No Reply
CD
Call Deflection
CFB
Call Forwarding Busy
CFNR
Call Forwarding No Reply
CFU
Call Forwarding Unconditional
CLIP
Calling Line Identification Presentation
CLIR
Calling/Connected Line Identification Restriction
CNIP
Calling Name Identification Presentation
CNIR
Calling/Connected Name Identification Restriction
CO
Call Offer
COLP
Connected Line Identification Presentation
CONP
Connected Name Identification Presentation
CT
Call Transfer
DND
Do Not Disturb
DNDO
Do Not Disturb Override
FE
Functional Entity
ISDN
Integrated Services Digital Network
PR
Path Replacement
PINX
Private Integrated Services Network Exchange
PISN
Private Integrated Services Network
SDL
Specification and Description Language
- 4 -
6
SS
Supplementary Service
TE
Terminal Equipment
SS-CO stage 1 specification
6.1
Description
6.1.1
General description SS-CO is a supplementary service which, on request from the calling user (or on that user's behalf), enables a call to be offered to a busy called user and to wait for that called user to accept the call, after the necessary resources have become available. The busy called user is given an indication of the offered call. During the time that the call is offered, the called user may ignore the offered call or may attempt to make the necessary resources available (e.g. by releasing or placing on hold another call). When and if the necessary resources become available, the call shall be completed as a normal incoming call.
6.1.2
Qualifications on applicability to telecommunication services SS-CO is applicable to all basic services defined in ECMA-142.
6.2
Procedures
6.2.1
Provision/withdrawal SS-CO may be provided or withdrawn after pre-arrangement with the service provider (by means of service profile control), or may be available generally to all users. In a PISN that offers more than one way of invoking SS-CO (see 6.2.2.2), one or more of these ways shall be selected at provision time.
6.2.2 6.2.2.1
Normal procedures Activation/deactivation/registration/interrogation Not applicable.
6.2.2.2
Invocation and operation There are four different ways of invoking SS-CO. A PISN shall offer one or more of these ways. These ways are: 1. Network invocation (immediate): the PISN shall automatically invoke SS-CO whenever the calling user makes a call to a user that is busy, if required by the service profile of the calling user. 2. Consultation: the calling user, on being informed that a call has failed because of busy at the destination and that SS-CO may be possible, shall be able, within a defined time period (consultation timer) to request invocation of SS-CO. 3. Immediate invocation: the calling user shall be able to request invocation of SS-CO as part of the initial call set up. 4. Network invocation (delayed): the network, having informed the calling user that a call has failed because of busy at the destination, shall automatically invoke SS-CO unless the calling user initiates call clearing within a defined time period (automatic call offer invocation timer). NOTE 2 If method 1 is provided to a user, methods 2, 3 and 4 will not be available to that user. For consultation and network invocation (delayed), for those basic services for which ECMA-142 requires an in-band tone or announcement to indicate progress or otherwise of the call, the information provided by the network that the call has failed because of busy at the destination shall include an in-band tone or announcement. If the calling user is provided with both consultation and network invocation (delayed), the calling user shall be able to request SS-CO during the period of the automatic call offer invocation timer. If, at the time of expiry of the automatic call offer invocation timer, the calling user has not requested SS-CO and has not initiated call clearing, the network shall automatically invoke SS-CO.
- 5 -
On successful invocation of SS-CO, the called user shall receive an indication of the offered call, and the calling user shall be advised that SS-CO has been invoked. Additional information that would normally accompany an incoming call indication (see ECMA-142) may optionally be provided to the called user. During the waiting period, for those basic services for which ECMA-142 requires an in-band tone or announcement to indicate progress or otherwise of the call, an in-band tone or announcement shall be given to the calling user. If the PISN detects that the necessary resources have become available, it shall transfer an incoming call indication to the called user. NOTE 3 The waiting period for the offered call can be subject to time-out. At time-out, the offered call can be released. Any such procedure is outside the scope of this Standard. SS-CO shall be considered completed when any one of the following occurs: – the called user starts alerting; – the called user accepts the call; – the calling user releases the offered call; – the called user rejects the offered call. If the called user starts alerting, the calling user shall receive an appropriate indication. If the called user rejects the offered call, the call shall be released with an appropriate indication to the calling user. 6.2.3
Exceptional procedures
6.2.3.1
Activation/deactivation/registration/interrogation Not applicable.
6.2.3.2
Invocation and operation If the calling user requests invocation of SS-CO as part of the initial call request, and immediate invocation is not provided to the calling user, then the request shall be ignored and the call shall proceed as if the request had not been made. An SS-CO request may be rejected for other reasons, e.g. when the number of calls already offered to the called user is equal to the maximum allowed for this user or when the call fails due to network conditions (see clause 9.3 of ECMA-142). If the request has been initiated by means of immediate invocation, consultation or network invocation (delayed), the calling user shall be informed that the SS-CO request is rejected. If consultation applies to the call, the call shall be released either if the calling user does not request invocation within the defined time period (consultation timer) or if the calling user requests invocation within the defined time period (consultation timer) and this request is rejected. If SS-CO is requested and the called user is found to be not busy, the call shall be treated as a normal incoming call to the called user.
6.3
Interactions with other supplementary services and ANFs Interactions with other supplementary services and ANFs for which PISN standards were available at the time of publication of this Standard are specified below.
6.3.1
Calling Line Identification Presentation (SS-CLIP) The called user shall receive, as part of the offered call, the Calling Line Identification of the calling user, unless SS-CLIR applies and the called user has no override capability.
6.3.2
Connected Line Identification Presentation (SS-COLP) No interaction.
- 6 -
6.3.3
Calling/Connected Line Identification Restriction (SS-CLIR) When Calling Line Identification Restriction has been invoked, the Calling Line Identification shall not be presented to the called user (as part of the offered call), unless the called user has an override category.
6.3.4
Calling Name Identification Presentation (SS-CNIP) The called user shall receive, as part of the offered call, the Calling Name Identification of the calling user, unless SS-CNIR applies and the called user has no override capability.
6.3.5
Connected Name Identification Presentation (SS-CONP) No interaction.
6.3.6
Calling/Connected Name Identification Restriction (SS-CNIR) When Calling Name Identification Restriction has been invoked, the Calling Name Identification shall not be presented to the called user (as part of the offered call), unless the called user has an override category.
6.3.7
Completion of Calls to Busy Subscriber (SS-CCBS) While a call is being offered, the calling user may be able to invoke SS-CCBS. SS-CO invoked against the called user shall have priority over any SS-CCBS requests against that called user, when resources at the called user become available.
6.3.8
Completion of Calls on No Reply (SS-CCNR) No interaction.
6.3.9
Call Transfer (SS-CT) It shall be possible for a user, after having successfully invoked SS-CO against a busy called user, to invoke call transfer for transferring a third user to that called user. This shall operate in a similar manner to Call Transfer during the alerting state, except that the call shall continue as an offered call to the called user. The third user may be notified that the call is in a waiting condition against a busy called user. If the called user subsequently enters an alerting phase and a notification that the call is in a waiting condition against a busy called user has been given to the third user, the third user shall be notified that the waiting condition has ceased.
6.3.10
Call Forwarding Unconditional (SS-CFU) SS-CO, if invoked, shall operate on a busy user that has been forwarded to as a result of one or more invocations of SS-CFU, provided neither SS-CFNR nor Call Deflection from Alert has taken place.
6.3.11
Call Forwarding Busy (SS-CFB) If SS-CO invocation is requested by the calling user as part of the initial call set up or automatically by the network when a call is made to a user that is busy, and if the called user is busy and has SS-CFB active, SS-CFB shall be invoked. If the SS-CFB forwarded-to user is also busy, SS-CO shall operate on the forwarded-to user. If the call undergoes more than one diversion, at least one of which is SS-CFB, but none of which is either SS-CFNR or Call Deflection from Alert, SS-CO shall operate on the final diverted-to user if that user is busy. If the calling user is informed that a call has failed because of busy at the destination, and if SS-CO is subsequently invoked, SS-CO shall operate on the SS-CFB forwarding user or on the SS-CFB forwarded-to user. If the call has undergone more than one diversion, at least one of which is SS-CFB, but none of which is either SS-CFNR or Call Deflection from Alert, then SS-CO shall operate either on the first SS-CFB forwarding user or on the final diverted-to user. Choice between the two is an implementation option. An implementation may permit the calling user to make the choice.
6.3.12
Call Forwarding No Reply (SS-CFNR) SS-CO if invoked, shall not operate on a busy user arrived at as a result of one or more diversions, at least one of which is SS-CFNR. The procedures of SS-CFNR shall apply. SS-CFNR can apply when alerting a user after completion of SS-CO on that user.
6.3.13
Call Deflection (SS-CD) SS-CO, if invoked, shall operate on a busy user that has been diverted to as a result of one or more invocations of Call Deflection Immediate, provided neither SS-CFNR nor Call Deflection from Alert has taken place.
- 7 -
SS-CO, if invoked, shall not operate on a busy user arrived at as a result of one or more diversions, at least one of which is Call Deflection Alert. The procedures of SS-CD shall apply. Call Deflection from Alert can apply when alerting a user after completion of SS-CO on that user. 6.3.14
Path Replacement (ANF-PR) No interaction.
6.3.15
Do Not Disturb (SS-DND) If SS-CO has been invoked: – as part of the initial call setup (i.e. by SS-CO immediate invocation); – following consultation (i.e. by SS-CO Consultation); – or by SS-CO network invocation (delayed) and if, at the time of invocation, SS-DND is active at the destination and has not been successfully overriden then the invocation of SS-CO shall be rejected, and the procedures of SS-DND shall apply.
6.3.16
Do Not Disturb Override (SS-DNDO) If the called user has SS-DND active, and SS-DNDO is successfully invoked, then: – if CO network invocation (immediate), immediate invocation or network invocation (delayed) is applicable to the call, then the invocation of CO shall apply to the call after SS-DND has been overridden, – if CO consultation is applicable to the call, it shall apply after SS-DND has been overriden.
6.3.17
Call Intrusion (SS-CI) A SS-CO request made after a SS-CI request has been accepted by the PISN shall be rejected. NOTE 4 SS-CI service includes a similar service to SS-CO - wait on busy. This can be used instead of SS-CO. A SS-CI request made after a SS-CO request has been accepted by the PISN shall be allowed. If the request is rejected due to intrusion not allowed, the SS-CO state shall remain. If SS-CI is accepted by the PISN, the SS-CO request shall be cancelled. If both SS-CI immediate invocation and SS-CO immediate invocation are requested at call set up, the services shall be rejected, and the call shall proceed as if neither of the services had been requested. If the served user is provided with SS-CO network invocation (immediate) and the served user requests SS-CI immediate invocation, the network shall not invoke SS-CO. NOTE 5 If a call fails because of busy at the destination, either SS-CI or SS-CO can be applied.
6.4
Interworking considerations When interworking with another network which supports an equivalent feature, it may be possible to cooperate with the other network in order to provide SS-CO. If a call is made with invocation of SS-CO to a destination in a network that does not support SS-CO, then the invocation of SS-CO shall be rejected and the call shall proceed normally as if there was no SS-CO invocation.
6.5
Overall SDL Figure 1 contains the dynamic description of SS-CO using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1993). The SDL process represents the behaviour of the PISN in providing SS-CO to a calling user. Input signals from the left and output signals to the left represent primitives from and to the calling user. Input signals from the right represent either primitives from the called user, or inputs from the basic call process, or inputs from an internal process. Output signals to the right represent primitives to the called user.
- 8 -
Figure 1 (part 1) - SS-CO, overall SDL
- 9 -
Figure 1 (part 2) - SS-CO, overall SDL
- 10 -
Figure 1 (part 3) - SS-CO, overall SDL
- 11 -
Figure 1 (part 4) - SS-CO, overall SDL
- 12 -
7
SS-CO stage 2 specification The stage 2 specification provides two different methods for the operation of SS-CO within the network. With the path retention method, if a busy called user is encountered the network connection between the Originating CC and the Destination CC is not released in accordance with ECMA-142 but instead is retained awaiting a possible request for SS-CO. With the non-retention method, if a busy called user is encountered and the basic call SETUP request/indication was not accompanied by a request for SS-CO, the network connection is released in accordance with ECMA-142. Therefore, with the non-retention method, if SS-CO is requested after encountering a busy called user a new network connection has to be established. Either of the methods can be used to support any of the four methods of invoking SS-CO described in 6.2.2.2. – Immediate invocation and network invocation (immediate) can be supported by the non-retention method by accompanying the SETUP request/indication with a request for SS-CO. – Immediate invocation and network invocation (immediate) can be supported by the path retention method by accompanying the SETUP request/indication with a request for path retention and then, when the path is retained because the called user is busy, requesting SS-CO. – Consultation or network invocation (delayed) can be supported by the non-retention method by accompanying the SETUP request/indication with a request for SS-CO and then, when the connection is released because the called user is busy, consulting the calling user or applying a delay. SS-CO can then be requested if necessary by repeating the SETUP request/indication, this time accompanied by a request for SS-CO. – Consultation or network invocation (delayed) can be supported by the path retention method by accompanying the SETUP request/indication with a request for path retention and then, when the path is retained because the called user is busy, consulting the calling user or applying a delay. SS-CO can then be requested if necessary using the retained connection. If it is determined that SS-CO is not required, the connection is released. The stage 3 standard for SS-CO at the Q reference point shall support both options, shall permit a PINX supporting FE1 functionality (see 7.1) to support either path retention or non-retention or both, and shall require a PINX supporting FE2 functionality to support both path retention and non-retention.
7.1 7.1.1
Functional model Functional model description The functional model shall comprise the following functional entities: FE1
Calling user's control entity
FE2
Called user's control entity
The following functional relationships shall exist between these FEs: ra
between FE1 and FE2
Figure 2 shows these FEs and relationships.
ra FE1
FE2 Figure 2 - Functional model for SS-CO
The further division of FE1 into an FE that is collocated with the Originating CCA (and therefore allocatable to a functional TE) and an FE that is collocated with the Originating CC (and therefore allocatable to a PINX) is outside the scope of this Standard. The further division of FE2 into an FE that is allocatable to a functional TE and an FE that is collocated with the Destination CC (and therefore allocated to a PINX), is outside the scope of this Standard.
- 13 -
7.1.2 7.1.2.1
Description of functional entities Calling user's control entity, FE1 This functional entity: – at the time of the original call request:
receives and validates request from the calling user for immediate invocation of SS-CO;
determines if immediate invocation, network invocation (immediate), network invocation (delayed) or consultation is applicable to the call;
if SS-CO is applicable to the call, determines if the path retention method or the non-retention method is to be used and, as appropriate, sends a path retention request or immediate invocation request to FE2 at the time of the original basic call r2-SETUP request/indication, or retains the call setup information;
– if consultation applies to the call and the conditions for performing consultation are met:
informs the calling user that the called user is busy and SS-CO may be requested;
limits the length of the consultation by clearing the call if the calling user has not responded (by requesting SS-CO or clearing the call) within the consultation time;
receives request (during consultation) from the calling user for invocation of SS-CO, sends an appropriate SS-CO invocation request (depending on the method used) to FE2, and sends the result of the invocation request to the calling user;
– if network invocation (delayed) applies to the call and the conditions for performing this are met:
informs the calling user that the called user is busy and SS-CO will be invoked unless the calling user clears the call;
on expiry of the automatic call offer invocation timer or on earlier request from the calling user, sends an appropriate SS-CO invocation request (depending on the method used) to FE2, and sends the result of the invocation request to the calling user;
– if immediate invocation or network invocation (immediate) applies and the path retention method is used, on receipt of the information from FE2 that the called user is busy and SS-CO is allowed, sends a SS-CO invocation request to FE2. 7.1.2.2
Called user's control entity, FE2 This functional entity: – on an incoming call with CO request to the called user who is busy, checks if SS-CO is possible; if so, offers the call to the called user; if not, rejects the CO request; – on an incoming call without CO request but with path retention request to a called user who is busy, checks if SS-CO would be possible; if so, retains the path, offers FE1 the possibility of invoking SS-CO, and, if required, applies an in-band tone or announcement to the calling user; – having retained the path and offered FE1 the possibility of invoking SS-CO, and on receipt of an SS-CO request from FE1, checks if SS-CO is still possible and if so, offers the call to the called user; if not, rejects the request; – if the call is offered to the called user, applies an in-band tone or announcement to the calling user, if required; – if the called user becomes not busy while a call is being offered, presents the call to the called user.
7.1.3
Relationship of functional model to basic call functional model Functional entity FE1 is collocated with calling user's CCA/CC. Functional entity FE2 is collocated with called user's CC. An example of relationship between the FEs for SS-CO and FEs for the basic call is shown in figure 3.
- 14 -
CCA
r1
CC
r2
CC
r3
r2
CC
CCA
FE2
FE1 ra Calling user
Called user Figure 3 - Example relationship between models for SS-CO and basic call
7.2
Information flows
7.2.1
Definition of information flows In the tables listing the service elements in information flows, the column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow.
7.2.1.1
ra-CO-ACTIVATE ra-CO-ACTIVATE is an unconfirmed information flow across ra from FE1 to FE2 which is used to request path retention if the called user is busy and if SS-CO is possible, in order to give the calling user the opportunity to invoke SS-CO. There are no service elements in this information flow.
7.2.1.2
ra-CO-AVAILABLE ra-CO-AVAILABLE is an unconfirmed information flow across ra from FE2 to FE1 that is used to inform FE1 that the path has been retained and SS-CO is possible. There are no service elements in this information flow.
7.2.1.3
ra-CO-INVOKE-IMMEDIATE ra-CO-INVOKE-IMMEDIATE is a confirmed information flow across ra from FE1 to FE2 which is used to invoke immediately (as part of the call establishment between FE1 and FE2) SS-CO if the called user is busy and SS-CO is possible. The response indicates one of the following: – short term denial, e.g. because of maximum number of offered calls already reached at FE2; – long term denial, e.g. because of SS-CO not provided; – not applicable, e.g. because of called user not busy; – success. Table 1 lists the service elements within the ra-CO-INVOKE-IMMEDIATE information flow. Table 1 - Content of ra-CO-INVOKE-IMMEDIATE Element CO-INVOKE-IMMEDIATE-result
Request
Confirm
-
M (Note 6)
NOTE 6 This element takes one of the values: short-term-denial, long-term-denial, not-applicable, success.
- 15 -
7.2.1.4
ra-CO-INVOKE ra-CO-INVOKE is a confirmed information flow across ra from FE1 to FE2 which is used to invoke SS-CO in the case where path retention has been successfully invoked (by ra-CO-ACTIVATE). The response indicates one of the following: – short term denial, e.g. because of maximum number of offered calls already reached at FE2; – not applicable, e.g. because of called user not busy; – success. Table 2 lists the service elements within the ra-CO-INVOKE information flow. Table 2 - Content of ra-CO-INVOKE Element
Request
Confirm
-
M (Note 7)
CO-INVOKE-result
NOTE 7 This element takes one of the values: short-term-denial, not-applicable, success. 7.2.1.5
ra-CO-TERMINATED ra-CO-TERMINATED is an unconfirmed information flow from FE2 to FE1 which is used to inform FE1 that the called user has started alerting and that the call is no longer offered. There are no service elements in this information flow.
7.2.2
Relationship of information flows to basic call information flows When ra-CO-ACTIVATE or ra-CO-INVOKE-IMMEDIATE request/indication information flow is sent, it shall be in conjunction with r2-SETUP request/indication. ra-CO-INVOKE request/indication shall be sent independently of a basic call information flow. ra-CO-AVAILABLE request/indication shall be sent: – independently of any basic call information flow if no tone or announcement is to be given by FE2 to the calling user; – with r2-REPORT request/indication (specifying Report Type = "call rejection" and Call History = "In-band information") if a tone or announcement is to be given by FE2 to the calling user and no r2-REPORT request/indication has previously been sent; – independently of any basic call information flow if a tone or announcement is to be given by FE2 to the calling user and r2-REPORT request/indication has previously been sent. ra-CO-INVOKE-IMMEDIATE response/confirmation and ra-CO-INVOKE response/confirmation, in the case of successful invocation, shall be sent: – with r2-REPORT request/indication if FE2 requires the Originating CCA, the Originating CC and any Transit CCs to behave as if the called PISN user is not busy and has entered an alerting phase and a r2-REPORT specifying the correct Report Type and Call History has not already been sent. The r2-REPORT shall specify Report Type = "user being alerted". Furthermore, for the basic services for which ECMA-142 requires tones or announcements to be given to indicate progress or otherwise of the call, the r2-REPORT shall also specify Call History = "in-band information"; – otherwise, independently of any basic call information flow. ra-CO-INVOKE-IMMEDIATE response/confirmation, in the case of failure of invocation, shall be sent: – with r2-REPORT request/indication if this is sent at the same time (e.g. if called user enters an alerting phase);
- 16 -
– with r2-SETUP response/confirmation if this is sent at the same time (e.g. if called user answers the call immediately); – with r2-RELEASE response/confirmation if this is sent at the same time (e.g. if called user is busy but SS-CO not provided); – otherwise independently of any basic call information flow. ra-CO-INVOKE response/confirmation, in the case of failure of invocation, shall be sent: – with r2-REPORT request/indication if this is sent at the same time (e.g. if called user enters an alerting phase); – with r2-SETUP response/confirmation if this is sent at the same time (e.g. if called user answers the call immediately); – with r2-RELEASE response/confirmation if this is sent at the same time (e.g. if called user is busy but SS-CO not possible at the time of invocation); – otherwise independently of any basic information flow. ra-CO-TERMINATED request/indication shall be sent: – with r2-REPORT request/indication if no r2-REPORT req/ind with Report Type = "user being alerted" has previously been sent; – otherwise independently of any basic information flow. Table 3 summarizes the relationship of the SS-CO information flows with those of the basic call. Table 3 - Relationship of the SS-CO information flows with the basic call Information flow
Independent of basic call flow
With basic flow
Basic call flows
ra-CO-ACTIVATE
request
-
yes
r2-SETUP req/ind
ra-CO-AVAILABLE
request
yes
yes
r2-REPORT req/ind
request
-
yes
r2-SETUP req/ind
confirm
yes
yes
r2-REPORT req/ind, r2-RELEASE req/ind
ra-CO-INVOKEIMMEDIATE
r2-SETUP resp/conf
ra-CO-INVOKE
request
yes
-
confirm
yes
yes
r2-REPORT req/ind, r2-RELEASE req/ind r2-SETUP resp/conf
ra-CO-TERMINATED
7.2.3
request
yes
yes
r2-REPORT req/ind
Examples of information flow sequences A stage 3 standard for SS-CO shall provide signalling procedures in support of the information flow sequences specified below. In addition, signalling procedures should be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc..
- 17 -
In the figures, SS-CO information flows are represented by solid arrows and basic call information flows are represented by broken arrows. An ellipse embracing two information flows indicates that the two information flows occur simultaneously. Within a column representing an SS-CO functional entity, the numbers refer to functional entity actions listed in 7.3. The following abbreviations are used: req
request
ind
indication
resp
response
cfm
confirmation
NOTE 8 To simplify the diagrams, some basic call information flows (e.g. RELEASE resp/conf) and transit CCs. 7.2.3.1
Normal operation of SS-CO Figure 4 shows the information flow sequence for normal operation of SS-CO without path retention. SS-CO is requested in conjunction with the basic call SETUP request/indication as a result of one of the following: – immediate invocation; – network invocation (immediate); – consulting the calling user, after a previous SETUP request/indication encountered a busy user; – network invocation (delayed), after a previous SETUP request/indication encountered a busy user. Subsequent to invocation of SS-CO, FE2 detects that the necessary resources have become available, and the called user enters an alerting phase. Figure 5 shows the information flow sequence for normal operation of SS-CO with path retention and when no tone or announcement is provided by FE2 to the calling user at the time of path retention. The path is retained because the called user is busy and then SS-CO is requested either: – immediately (immediate invocation or network invocation (immediate)); or – as a result of consulting the calling user; or – after a delay (network invocation (delayed)). Subsequent to invocation of SS-CO, the called user accepts the offered call after the necessary resources have become available. Figures 4 and 5 show the information flow sequences for the case where r2-REPORT req/ind is not sent in conjunction with ra-CO-INVOKE-IMMEDIATE resp/conf or ra-CO-INVOKE resp/conf at the time of invocation of SS-CO.
- 18 -
Figure 4 - Information flow sequence - normal operation of SS-CO without path retention and with the called user being alerted after resources become available
- 19 -
Figure 5 - Information flow sequence - normal operation of SS-CO with path retention and with acceptance of the call by the called user
- 20 -
7.2.3.2
Failure operation of SS-CO Figure 6 shows the information flow sequence for failure operation of SS-CO without path retention due to FE2 local reason (e.g. because the called user is unable to accept a further offered call). Figure 7 shows the information flow sequence for failure operation of SS-CO with path retention due to FE2 local reason (e.g. because the called user is unable to accept a further offered call). Figure 8 shows the information flow sequence for failure to retain path for SS-CO (e.g. because called user busy but SS-CO is not possible). Figure 9 shows the information flow sequence for failure operation of SS-CO without path retention when the called user is not busy and accepts the call immediately. Figure 10 shows the information flow sequence for failure operation of SS-CO with path retention when the called user is not busy when receiving the SS-CO request.
- 21 -
Figure 6 - Information flow sequence - failure operation of SS-CO without path retention (for instance, because the called user is unable to accept a further offered call)
- 22 -
Figure 7 - Information flow sequence - failure operation of SS-CO with path retention (for instance, because the called user is unable to accept a further offered call)
- 23 -
Figure 8 - Information flow sequence - failure to retain path for SS-CO (for instance, because SS-CO is not possible)
- 24 -
Figure 9 - Information flow sequence - failure operation of SS-CO without path retention (called user is not busy and accepts the call immediately)
- 25 -
Figure 10 - Information flow sequence - failure operation of SS-CO with path retention (called user not busy when receiving the SS-CO request)
- 26 -
7.3
Functional entity actions The following FE actions shall occur at the points indicated in the figures of 7.2.3.
7.3.1
7.3.2
7.4
Functional entity actions of FE1 101
Send ra-CO-ACTIVATE req/ind to FE2 in order to request path retention if the called user is encountered busy and SS-CO is possible.
102
If consultation is provided, notify the calling user that the called user is busy and SS-CO possible and start the consultation timer unless network invocation (delayed) is also provided. If network invocation (delayed) is provided, start the automatic CO invocation timer with notification to that user that CO will happen. If network invocation (immediate) is provided or if immediate invocation has been requested, send ra-CO-INVOKE req/ind immediately.
103
Recognize CO request from the calling user or initiate network invocation, and send ra-CO-INVOKEIMMEDIATE req/ind to FE2.
104
Recognize CO request from the calling user and stop the consultation timer, or process the expiry of the automatic CO invocation timer. Send ra-CO-INVOKE req/ind to FE2.
105
Notify the calling user that the CO request has been accepted.
106
Notify the calling user that the call continues as a normal call.
107
If CO request has been initiated by means of immediate invocation or consultation, notify the calling user that it has been rejected.
Functional entity actions of FE2 201
Determine that the called user is busy and SS-CO is possible. Return ra-CO-AVAILABLE req/ind to FE1. If required, apply an in-band tone or announcement to inform the calling user that the called user is busy.
202
Determine whether the called user is busy and SS-CO is possible or not. Return ra-CO-INVOKEIMMEDIATE resp/conf to FE1 with the appropriate result. If accepted, offer the call to the called user, optionally instruct the collocated CC to act towards the Originating CC as if the called user is not busy and has entered an alerting phase, and, if required, apply an in-band tone or announcement to inform the calling user that the call is offered. If rejected, indicate the reason why.
203
Determine whether the called user is busy and SS-CO is possible or not. Return ra-CO-INVOKE resp/conf to FE1 with the appropriate result. If accepted, offer the call to the called user, optionally instruct the collocated CC to act towards the Originating CC as if the called user is not busy and has entered an alerting phase, and, if required, apply an in-band tone or announcement to inform the calling user that the call is offered. If rejected, indicate the reason why.
204
Determine that the necessary resources have been made available and then that the called user enters an alerting phase or an active phase. Send ra-CO-TERMINATED to FE1, if the called user enters an alerting phase.
205
Determine that path retention for SS-CO is not possible.
Functional entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1993).
7.4.1
Behaviour of FE1 Figure 11 shows the normal behaviour of FE1. Input signals from the left and output signals to the left represent primitives from and to the calling user. Input signals from the right and output signals to the right represent information flows from and to FE2 and input signals from the collocated CC or other internal process.
- 27 -
Figure 11 (part 1) - SS-CO, SDL for functional entity FE1
- 28 -
Figure 11 (part 2) - SS-CO, SDL for functional entity FE1
- 29 -
Figure 11 (part 3) - SS-CO, SDL for functional entity FE1
- 30 -
Figure 11 (part 4) - SS-CO, SDL for functional entity FE1
- 31 -
Figure 11 (part 5) - SS-CO, SDL for functional entity FE1
- 32 -
Figure 11 (part 6) - SS-CO, SDL for functional entity FE1
- 33 -
7.4.2
Behaviour of FE2 Figure 12 shows the normal behaviour of FE2. Input signals from the right and output signals to the right represent primitives from and to the called user and input signals from the collocated CC. Input signals from the left and output signals to the left represent information flows from and to FE1.
- 34 -
Figure 12 (part 1) - SS-CO, SDL for functional entity FE2
- 35 -
Figure 12 (part 2) - SS-CO, SDL for functional entity FE2
- 36 -
7.5
Allocation of functional entities to physical equipment The allocation of FEs to physical equipment shown in table 4 shall apply. In the table, "TE" represents a TE attached to a PISN. Table 4 - Scenarios for the allocation of FEs to physical equipment
Scenario 1
7.6
FE1
FE2
Originating TE/PINX
Terminating TE/PINX
Interworking considerations On an incoming call from another network which supports SS-CO, then FE1 shall be in the other network (see table 5, scenario 2). On an outgoing call to another network: 1. If the other network fully supports SS-CO, then FE2 shall be in the other network (see table 5, scenario 3). 2. If the other network does not support SS-CO, then FE2 shall be in the Gateway PINX (see table 5, scenario 4) and: a) shall supply response/confirmation to ra-CO-INVOKE-IMMEDIATE request/indication specifying CO-INVOKE-IMMEDIATE-result = "long-term-denial"; b) shall ignore a receipt of an ra-CO-ACTIVATE request/indication. 3. If the other network supports SS-CO only without path retention, then FE2 shall be in the Gateway PINX (see table 5, scenario 4) and: a) shall forward any ra-CO-INVOKE-IMMEDIATE request/indication; b) on receipt of ra-CO-ACTIVATE request/indication, shall send a request for call establishment without SS-CO to the other network. If the call fails due to a busy called user, FE2 may optionally retain all call setup information and send ra-CO-AVAILABLE request/indication to FE1. On receipt of ra-CO-INVOKE request/indication, FE2 shall send a request for call establishment with SS-CO to the other network. Depending on the result of the request for call establishment, FE2 shall send ra-CO-INVOKE response/confirmation specifying appropriate value for CO-INVOKE-result. The actions performed may depend on the requirements of the other network. Table 5 - Scenarios for the allocation of FEs to physical equipment for normal operation in the case of interworking with another network FE1
FE2
Scenario 2
Other network
Terminating TE/PINX
Scenario 3
Originating TE/PINX
Other network
Scenario 4
Originating TE/PINX
Gateway PINX
.
.
Printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:
+41 22 849.60.01 [email protected]
Files can be downloaded from our FTP site, ftp.ecma.ch, logging in as anonymous and giving your E-mail address as password. This Standard is available from library ECMA-ST as a compacted, self-expanding file in MSWord 6.0 format (file E191-DOC.EXE) and as an Acrobat PDF file (file E191-PDF.PDF). File E191-EXP.TXT gives a short presentation of the Standard. Our web site, http://www.ecma.ch, gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland This Standard ECMA-191 is available free of charge in printed form and as a file. See inside cover page for instructions