ETSI EN 300 188-1 V1.2.4 (1998-06)

Integrated Services Digital Network (ISDN); Three-Party (3PTY) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification

REN/SPS-05145-J2-1

Digitalno omrežje z integriranimi storitvami (ISDN) - Dopolnilna storitev: konferenca treh (3PTY) - Protokol digitalne naročniške signalizacije št. 1 (DSS1) - 1. del: Specifikacija protokola

General Information

• Status: Published
• Publication Date: 28-Jun-1998
• Technical Committee: SPS 5 4 - Supplementary Services
• Current Stage: 12 - Completion
• Due Date: 03-Jul-1998
• Completion Date: 29-Jun-1998
• Ref Project: SIST EN 300 188-1 V1.2.4:2005 - Integrated Services Digital Network (ISDN); Three-Party (3PTY) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification

Standards Content (Sample)

SLOVENSKI STANDARD
01-april-2005
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'1'RSROQLOQDVWRULWHY
NRQIHUHQFDWUHK37<3URWRNROGLJLWDOQHQDURþQLãNHVLJQDOL]DFLMHãW'66
GHO6SHFLILNDFLMDSURWRNROD
Integrated Services Digital Network (ISDN); Three-Party (3PTY) supplementary service;
Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol
specification
Ta slovenski standard je istoveten z: EN 300 188-1 Version 1.2.4
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 300 188-1 V1.2.4 (1998-06)
European Standard (Telecommunications series)
Integrated Services Digital Network (ISDN);
Three Party (3PTY) supplementary service;
Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 1: Protocol specification

2 EN 300 188-1 V1.2.4 (1998-06)
Reference
REN/SPS-05145-J2-1 (1qo90iqo.PDF)
Keywords
ISDN, 3PTY, DSS1, supplementary service
ETSI
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: [phone]  Fax: [phone]
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Internet
[e-mail]
http://www.etsi.fr
http://www.etsi.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1998.
All rights reserved.
ETSI
3 EN 300 188-1 V1.2.4 (1998-06)
Contents
Intellectual Property Rights. 5
Foreword. 5
1 Scope . 7
2 Normative references. 7
3 Definitions. 8
4 Abbreviations.9
5 Description . 9
6 Operational requirements . 10
6.1 Provision and withdrawal.10
6.2 Requirements on the originating network side.10
6.3 Requirements on the destination network side .10
7 Coding requirements. 10
7.1 Coding of the Facility information element components.10
7.2 Coding of the Notification indicator information element .11
8 State definitions. 11
9 Signalling procedures at the coincident S and T reference point . 12
9.1 Activation, deactivation and registration .12
9.2 Invocation and operation.12
9.2.1 Request for a three-way conversation .12
9.2.1.1 Normal operation.12
9.2.1.2 Exceptional procedures .13
9.2.2 Disconnection of one remote user, and retention of the other .13
9.2.2.1 Normal operation.13
9.2.2.2 Exceptional procedures .15
9.2.3 Disconnection of both remote users, and terminating the call.15
9.2.3.1 Normal operation.15
9.2.3.2 Exceptional procedures .15
9.2.4 Creation of a private communication with a remote user.16
9.2.4.1 Normal operation.16
9.2.4.2 Exceptional procedures .17
9.2.5 Remote user terminates the call.18
9.2.5.1 Normal operation.18
9.2.5.2 Exceptional procedures .19
ETSI
4 EN 300 188-1 V1.2.4 (1998-06)
10 Procedures for interworking with private ISDNs . 19
11 Interactions with other networks. 19
12 Interactions with other supplementary services. 19
13 Parameter values (timers). 19
14 Dynamic description (SDL diagrams). 19
Annex A (informative): Signalling flows . 31
A.1 Request for a three-way conversation. 31
A.2 Disconnection of one remote user, and retention of the other. 32
A.3 Disconnection of both remote users and terminating the call . 33
A.4 Creation of a private communication with a remote user. 34
A.5 Remote user terminates the call . 35
Annex B (informative): Changes with respect to the previous ETS 300 188-1. 36
History. 37
ETSI
5 EN 300 188-1 V1.2.4 (1998-06)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in
SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can
be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) which
are, or may be, or may become, essential to the present document.
Foreword
This European Standard (Telecommunications series) has been produced by ETSI Technical Committee Signalling
Protocols and Switching (SPS).
The present document is part 1 of a multi-part standard covering the Digital Subscriber Signalling System No. one (DSS1)
protocol specification for the Integrated Services Digital Network (ISDN) Three Party (3PTY) supplementary service, as
described below:
Part 1: "Protocol specification";
Part 2: "Protocol Implementation Conformance Statement (PICS) proforma specification";
Part 3: "Test Suite Structure and Test Purposes (TSS&TP) specification for the user";
Part 4: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT)
proforma specification for the user";
Part 5: "Test Suite Structure and Test Purposes (TSS&TP) specification for the network";
Part 6: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT)
proforma specification for the network".
In accordance with CCITT Recommendation I.130, the following three level structure is used to describe the
supplementary telecommunications services as provided by European public telecommunications operators under the pan-
European Integrated Services Digital Network (ISDN):
- Stage 1: is an overall service description, from the user's standpoint;
- Stage 2: identifies the functional capabilities and information flows needed to support the service described in
stage 1; and,
- Stage 3: defines the signalling system protocols and switching functions needed to implement the service described
in stage 1.
The present document details the stage 3 aspects (signalling system protocols and switching functions) needed to support
the Three Party (3PTY) supplementary service. The stage 1 and stage 2 aspects are detailed in ETS 300 186 and
ETS 300 187, respectively.
The present version updates the references to the basic call specifications and incorporates all previous amendments and
corrigenda.
ETSI
6 EN 300 188-1 V1.2.4 (1998-06)
National transposition dates
Date of adoption of this EN: 19 June 1998
Date of latest announcement of this EN (doa): 30 September 1998
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 1999
Date of withdrawal of any conflicting National Standard (dow): 31 March 1999
ETSI
7 EN 300 188-1 V1.2.4 (1998-06)
1 Scope
This first part of EN 300 188 specifies the stage three of the Three Party (3PTY) supplementary service for the pan-
European Integrated Services Digital Network (ISDN) as provided by European public telecommunications operators at
the T reference point or coincident S and T reference point (as defined in CCITT Recommendation I.411 [5]) by means of
the Digital Subscriber Signalling System No. one (DSS1) protocol. Stage three identifies the protocol procedures and
switching functions needed to support a telecommunications service (see CCITT Recommendation I.130 [3]).
In addition the present document specifies the protocol requirements at the T reference point where the service is
provided to the user via a private ISDN.
The present document does not specify the additional protocol requirements where the service is provided to the user via
a telecommunications network that is not an ISDN.
The 3PTY supplementary service enables a user to establish, participate in and control, a three-way conversation, i.e. a
simultaneous communication involving the served user and two remote users.
The 3PTY supplementary service is applicable to all circuit-switched telecommunication services carrying speech.
Further parts of the present document specify the method of testing required to identify conformance to the present
document.
The present document is applicable to equipment, supporting the 3PTY supplementary service, to be attached at either
side of a T reference point or coincident S and T reference point when used as an access to the public ISDN.
2 Normative references
References may be made to:
a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in which
case, subsequent revisions to the referenced document do not apply; or
b) all versions up to and including the identified version (identified by "up to and including" before the version
identity); or
c) all versions subsequent to and including the identified version (identified by "onwards" following the version
identity); or
d) publications without mention of a specific version, in which case the latest version applies.
A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
number.
[1] CCITT Recommendation E.164: "Numbering plan for the ISDN era".
[2] CCITT Recommendation I.112: "Vocabulary of terms for ISDNs".
[3] CCITT Recommendation I.130 (1988): "Method for the characterisation of telecommunication
services supported by an ISDN and network capabilities of an ISDN".
[4] CCITT Recommendation I.210: "Principles of telecommunication services supported by an ISDN
and the means to describe them".
[5] CCITT Recommendation I.411 (1988): "ISDN user-network interfaces - Reference configurations".
[6] CCITT Recommendation Q.9 (1988): "Vocabulary of switching and signalling terms".
[7] CCITT Recommendation X.208 (1988): "Specification of Abstract Syntax Notation One (ASN.1)".
[8] CCITT Recommendation X.209 (1988): "Specification of basic encoding rules for Abstract Syntax
Notation One (ASN.1)".
ETSI
8 EN 300 188-1 V1.2.4 (1998-06)
[9] CCITT Recommendation X.219 (1988): "Remote operations: Model, notation and service
definition".
[10] CCITT Recommendation Z.100 (1988): "Functional Specification and Description Language
(SDL)".
[11] EN 300 403-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System
No. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control; Part 1:
Protocol specification [ITU-T Recommendation Q.931 (1993), modified]".
[12] EN 300 403-2: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System
No. one (DSS1) protocol; Signalling network layer for circuit-mode basic call control; Part 2:
Specification and Description Language (SDL) diagrams".
[13] ETS 300 402-1: "Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System
No. one (DSS1) protocol; Data link layer; Part 1: General aspects".
[14] EN 300 195-1: "Integrated Services Digital Network (ISDN); Supplementary service interactions;
Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
[15] EN 300 196-1: "Integrated Services Digital Network (ISDN); Generic functional protocol for the
support of supplementary services; Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 1: Protocol specification".
3 Definitions
For the purposes of the present document, the following definitions apply:
active-held connection: A connection between two users where at the served user, the call state is Active, and the
auxiliary state is Call Held.
active-idle connection: A connection between two users where at the served user, the call state is Active, and the
auxiliary state is Idle.
call reference: See EN 300 196-1 [15], clause 3.
call state: A state as defined in EN 300 403-1 [11] subclause 2.1 for either the user side or the network side as
appropriate. A call state may exist for each call reference value (and for each additional responding Connection Endpoint
Identifier (CEI) in the incoming call state).
call: See CCITT Recommendation Q.9 [6], definition 2201.
connection endpoint identifier: The identifier that identifies the data link connection which is used to transfer the
signalling information (for the complete definition see EN 300 402-1 [13], subclause 3.4.1).
connection: See CCITT Recommendation Q.9 [6], definition 0011.
Integrated Services Digital Network (ISDN): See CCITT Recommendation I.112 [2], definition 308.
invoke component: See EN 300 196-1 [15], subclause 8.2.2.1. Where reference is made to "xxxx" invoke component, an
invoke component is meant with its operation value set to the value of the operation "xxxx".
ISDN number: A number conforming to the numbering plan and structure specified in CCITT Recommendation E.164 [1].
network: The DSS1 protocol entity at the network side of the user-network interface.
private communication: Communication between the served user and one remote user. This excludes communication
with the other remote user.
reject component: See EN 300 196-1 [15], subclause 8.2.2.4.
remote user: The two other users to the served user which are involved in the two calls that are joined together in a
three-way conversation. The remote users are distinguished as user B and user C.
ETSI
9 EN 300 188-1 V1.2.4 (1998-06)
return error component: See EN 300 196-1 [15], subclause 8.2.2.3. Where reference is made to "xxxx" return error
component, a return error component is meant which is related to an "xxxx" invoke component.
return result component: See EN 300 196-1 [15], subclause 8.2.2.2. Where reference is made to "xxxx" return result
component, a return result component is meant which is related to an "xxxx" invoke component.
served user: The user (DSS1 protocol entity) which invokes this supplementary service; this user is also referred to as
user A.
service; telecommunications service: See CCITT Recommendation I.112 [2], definition 201.
supplementary service: See CCITT Recommendation I.210 [4], § 2.4.
three-way bridge: The network equipment which performs connections between three users to allow three-way
conversation.
three-way conversation: Communication between all three users, i.e. the served user and both remote users.
user: The DSS1 protocol entity at the user side of the user-network interface.
4 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3PTY Three Party
ASN.1 Abstract Syntax Notation one
CEI Connection Endpoint Identifier
CR Call Reference
DSS1 Digital Subscriber Signalling System No. one
ISDN Integrated Services Digital Network
PSTN Public Switched Telephone Network
SDL Specification and Description Language
5 Description
The served user, which has only one Active-Idle connection, and at least one Active-Held connection can join the Active-
Idle connection with one of the Active-Held connections, to form a three-way conversation.
NOTE 1: Each call, to be involved in the 3PTY supplementary service, can have been originated by either the served
user, or by the appropriate remote user.
During the three-way conversation the served user can request that the network:
- explicitly disconnects one of the remote users, and the connection to that remote user;
- terminates the three-way conversation; or
- creates a private communication with one of the remote users.
Either of the remote users (user B or user C) can request that the network disconnects the connection.
Remote users are notified of these actions.
NOTE 2: During an interim period of time, some networks may not support the transfer of the notification to the
remote users.
NOTE 3: The protocol for implementation of the 3PTY supplementary service is restricted to implementations where
only one call within an Active-Idle connection exists for that CEI value. User implementations, e.g.
multifunctional terminals, that in a normal operation support more than one call with an Active-Idle
connection on the same CEI value, cannot make effective use of this protocol.
ETSI
10 EN 300 188-1 V1.2.4 (1998-06)
6 Operational requirements
6.1 Provision and withdrawal
The 3PTY supplementary service shall be provided by prior arrangement with the service provider.
The 3PTY supplementary service shall be withdrawn by the service provider upon request of the subscriber or for
service provider reasons.
6.2 Requirements on the originating network side
The requirements of EN 300 403-1 [11], subclause 5.1 shall apply.
6.3 Requirements on the destination network side
The requirements of EN 300 403-1 [11], subclause 5.2 shall apply.
7 Coding requirements
7.1 Coding of the Facility information element components
Table 1 shows the definition of the operations and types required for the 3PTY supplementary service using ASN.1 as
defined in CCITT Recommendations X.208 [7] and X.209 [8], and using the OPERATION macro as defined in CCITT
Recommendation X.219 [9], figure 4/X.219.
The formal definition of the component types to encode these operations and types is provided in EN 300 196-1 [15],
clause D.1.
The inclusion of components in Facility information elements is defined in EN 300 196-1 [15], subclause 11.2.2.1.
Table 1: Definition of operations for the 3PTY supplementary service
Three-Party-Operations {ccitt identified-organization etsi (0) 188 operations-and-types (1)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS        Begin3PTY, End3PTY;
IMPORTS        OPERATION
FROM Remote-Operation-Notation
{joint-iso-ccitt remote-operations (4) notation (0)}
notSubscribed, notAvailable, invalidCallState,
resourceUnavailable,
supplementaryServiceInteractionNotAllowed
FROM General-Errors
{ccitt identified-organization etsi (0) 196 general-errors (2)};
Begin3PTY   :: =  OPERATION
RESULT
ERRORS {notSubscribed, notAvailable, invalidCallState,
resourceUnavailable,
supplementaryServiceInteractionNotAllowed}
Table 1 (concluded): Definition of operations for the 3PTY supplementary service
-- The present document does not provide procedures for the generation of the error
"notAvailable"
ETSI
11 EN 300 188-1 V1.2.4 (1998-06)
End3PTY    :: =  OPERATION
RESULT
ERRORS {invalidCallState}
begin3PTY       Begin3PTY :: = 4
end3PTY        End3PTY  :: = 5
END
All components (invoke, return result, return error and reject) shall be included within a Facility information element. The
Facility information element shall be included in the message as specified in clause 9.
7.2 Coding of the Notification indicator information element
The notification description is contained in octet 3 of the Notification indicator information element and shall be coded as
shown in table 2.
NOTE: The following guidance is given for the interpretation of the notification descriptions at a remote user. A
notification description of "Remote hold" indicates a loss of communication path in the B-channel. When
three-way conversation exists, this may be due to termination of the three-way conversation, which will be
indicated by a subsequent notification description of "Conference disconnected", or due to operation of
some supplementary services, e.g. the call hold supplementary service. When the notification description of
"Conference disconnected" is received, a communication path exists in the B-channel, unless the
notification description is accompanied by, or immediately followed by, a notification description of
"Remote hold", which indicates a loss of communication path in the B-channel.
Table 2: Codepoints in the Notification indicator information element
Bits
8 7 6 5 4 3 2 1
1 1 0 0 0 0 1 0 Conference established (note 1)
1 1 0 0 0 0 1 1 Conference disconnected (note 2)
1 1 1 1 1 0 0 1 Remote hold
NOTE 1: The user takes part in a multiparty call.
NOTE 2: The user takes part in a normal two-party call.
8 State definitions
The call states as specified in EN 300 403-1 [11], subclause 2.1 shall apply.
The auxiliary states as specified in EN 300 196-1 [15], subclause 7.1.2 shall apply.
The following states are defined for the network:
- 3PTY Idle: an occurrence of the 3PTY supplementary service has not been requested;
- 3PTY Active: an occurrence of the 3PTY supplementary service exists;
- 3PTY Await Retrieve: a Retrieve function should be initiated by the user prior to ending of the 3PTY
supplementary service;
- 3PTY Await Hold And Retrieve: a Hold function and a Retrieve function should be initiated by the user prior to
ending of the 3PTY supplementary service;
- 3PTY Await Hold: a Hold function should be initiated by the user prior to ending of the 3PTY supplementary
service.
The following states are defined for the user:
ETSI
12 EN 300 188-1 V1.2.4 (1998-06)
- 3PTY Idle: an occurrence of the 3PTY supplementary service has not been requested;
- 3PTY Active: an occurrence of the 3PTY supplementary service exists;
- Begin3PTY Request: the 3PTY supplementary service has been requested by the served user;
- End3PTY Request: the served user wants to have a private conversation with one of the remote users.
9 Signalling procedures at the coincident S and
T reference point
9.1 Activation, deactivation and registration
Not applicable, i.e. no signalling procedures are required for the activation, deactivation and registration of the 3PTY
supplementary service.
9.2 Invocation and operation
9.2.1 Request for a three-way conversation
9.2.1.1 Normal operation
In order to request the 3PTY supplementary service, the served user requires two calls each related to the same CEI
value, one with each of the remote users. One call shall have an Active-Idle connection. The other call shall have an
Active-Held connection. The served user shall have no other calls with Active-Idle connections related to the same CEI
value. Other calls with Active-Held connections may exist.
To request the 3PTY supplementary service, the served user shall send to the network a Begin3PTY invoke component
according to the procedures of EN 300 196-1 [15], subclause 8.3.1.1, within a FACILITY message, and using the Call
Reference (CR) of the appropriate Active-Held connection.
NOTE: The other CR is implicitly identified by the constraint that it is the only Active-Idle connection.
On receiving this request, the network shall check whether:
- the 3PTY supplementary service is allowed to this user;
- the received request relates to an Active-Held connection;
- for the CEI value on which the request is received, a single Active-Idle connection exists;
- that a three-way bridge is available for use;
- no three-way bridge that is controlled by the served user is already included in the Active-Idle connection or in the
Active-Held connection; and
- the requirements of EN 300 195-1 [14] are met for the other supplementary service interactions.
If these requirements are met, the network shall:
a) allocate a three-way bridge;
b) attach the identified connections to this three-way bridge using the B-channel of the Active-Idle connection to
support user information transfer with the served user;
c) return to the served user a Begin3PTY return result component according to the procedures of EN 300 196-1 [15],
subclause 8.3.1.1, within a FACILITY message, and using the CR of the appropriate Active-Held connection; and
ETSI
13 EN 300 188-1 V1.2.4 (1998-06)
d) send a NOTIFY message to the remote users containing a Notification indicator information element with a
notification description of "Conference established".
When the served user receives a correctly encoded Begin3PTY return result component, within a FACILITY message, the
user shall accept the provided information and shall not respond to the network.
As a result of the procedures of this subclause, the call states and the auxiliary states of the two connections, at both the
network and the user, are unchanged.
9.2.1.2 Exceptional procedures
On receiving a Begin3PTY invoke component, within a FACILITY message, according to the procedures of
EN 300 196-1 [15], subclause 8.3.1.1, but three-way conversation is not allowed, the network shall return to the served
user a Begin3PTY return error component, according to the procedures of EN 300 196-1 [15], subclause 8.3.1.1, within a
FACILITY message, or in any other appropriate call control message, and using the CR of the connection on which the
message has been received, and take no action on any connections for that user.
The error included in the Begin3PTY return error component shall be one of the following:
- "notSubscribed", if the 3PTY service has not been subscribed;
- "invalidCallState", if the received request does not relate to an Active-Held connection, or no Active-Idle
connection exists for that CEI value, or more than one Active-Idle connection exists for that CEI value;
- "resourceUnavailable", if a three-way bridge is not available for use;
- "supplementaryServiceInteractionNotAllowed", if a three-way bridge already exists in one or both of the
identified connections, and the three-way bridge relates to the same served user, or if the provision of the service
is precluded by a procedure within EN 300 195-1 [14].
The served user, on receiving a Begin3PTY return error component, shall take no action, and remain in the state that
existed before the Begin3PTY invoke component was sent.
If the network receives a Begin3PTY invoke component in a message other than a FACILITY message then the network
shall return a Begin3PTY return error component according to the procedures of EN 300 196-1 [15], subclause 8.3.1.1.
The error included in the Begin3PTY return error component shall be "invalidCallState". The Begin3PTY return error
component shall be returned to the served user by the appropriate call control message or call hold and retrieve family of
messages as specified in EN 300 196-1 [15], clause 7, or a FACILITY message.
The served user, on receiving a reject component, shall take no action, and remain in the state that existed before the
Begin3PTY invoke component was sent.
The network, on receiving a reject component, shall take no action, and remain in the state that existed before the reject
component was received.
Once the network decides that the 3PTY supplementary service has been successfully invoked, up until the time that the
network decides that the three-way conversation is ended, the following procedures apply. If the network receives a
RETRIEVE message for the Active-Held connection, then the Retrieve function shall be rejected according to the
procedures of EN 300 196-1 [15] with cause #29 "Facility rejected".
9.2.2 Disconnection of one remote user, and retention of the other
9.2.2.1 Normal operation
The remote user to be disconnected is identified at the served user by the CR relating to either the Active-Held
connection, or to the Active-Idle connection. Depending on which applies, one of the two following procedures shall be
followed:
a) If the remote user to be disconnected is identified at the served user by a CR relating to the Active-Idle connection,
the served user shall send a DISCONNECT message with that CR, in accordance with the procedures of
EN 300 403-1 [11], subclause 5.3.
On receiving such a DISCONNECT message, the network shall:
ETSI
14 EN 300 188-1 V1.2.4 (1998-06)
i) clear the connection to the appropriate remote user;
NOTE 1: The receipt of clearing information at this remote user indicates the end of three-way conversation.
ii) continue clearing the identified CR to the served user in accordance with the procedures of EN 300 403-1 [11],
subclause 5.3. The network shall provide any appropriate reservation function as defined in
EN 300 196-1 [15], subclause 10.1, in association with this clearing;
iii) remove the three-way bridge from the Active-Held connection to the other remote user;
iv) release the three-way bridge; and,
v) send a NOTIFY message to the remaining remote user containing a Notification indicator information element
with a notification description of "Remote hold".
On receiving the RELEASE message, as provided by the procedures of EN 300 403-1 [11], subclause 5.3, the
served user shall:
i) continue to clear the CR on which clearing was initiated in accordance with the procedures of subclause 5.3 of
EN 300 403-1 [11]; and,
ii) use the CR relating to the Active-Held connection, perform the Retrieve function in accordance with the
procedures of EN 300 196-1 [15], subclause 7.4.
NOTE 2: The served user may need to allow for completion of clearing of the CR on which clearing was initiated
before performing the Retrieve function in order to ensure success of channel selection during the Retrieve
function.
On receiving a RETRIEVE message indicating a request for the Retrieve function, the network shall:
i) complete the Retrieve function (according to the procedures of subclause 7.4 of EN 300 196-1 [15]), using any
appropriate reservation (according to the procedures of subclause 10.1 of EN 300 196-1 [15]);
NOTE 3: A Notification indicator information element with a notification description of "Remote retrieval" is not
sent to the remote user under these circumstances.
ii) send a NOTIFY message to the remaining remote user containing a Notification indicator information element
with a notification description of "Conference disconnected".
As a result of the procedures of this item of this subclause, the call state of the remaining connection, at both the
network and the served user, is unchanged. The auxiliary state is Idle.
b) If the remote user to be disconnected is identified at the served user by a CR relating to the Active-Held
connection, the served user shall send a DISCONNECT message with that CR, in accordance with the procedures
of EN 300 403-1 [11], subclause 5.3.
On receiving such a DISCONNECT message, the network shall:
i) clear the connection to the appropriate remote user;
NOTE 4: The receipt of clearing information at this remote user indicates the end of three-way conversation.
ii) continue clearing the identified CR to the served user in accordance with the procedures of EN 300 403-1 [11],
subclause 5.3;
iii) remove the three-way bridge from the Active-Idle connection to the other remote user;
iv) release the three-way bridge; and,
v) send a NOTIFY message to the remaining remote user containing a Notification indicator information element
with a notification description of "Conference disconnected".
As a result of the procedures of this item of this subclause, the call state and the auxiliary state of the remaining
connection, at both the network and the served user, are unchanged.
ETSI
15 EN 300 188-1 V1.2.4 (1998-06)
9.2.2.2 Exceptional procedures
All exceptional conditions shall be treated according to the procedures of EN 300 403-1 [11], subclause 5.8.
9.2.3 Disconnection of both remote users, and terminating the call
9.2.3.1 Normal operation
The served user shall send a DISCONNECT message on both:
- the CR relating to the Active-Held connection. Subsequent procedures shall be according to subclause 9.2.2.1 item
b);
- the CR relating to the Active-Idle connection. Subsequent procedures shall be according to subclause 9.2.2.1 item
a) except that the served user shall not perform the Retrieve function.
The network shall create the notification towards the remaining remote user only on disconnection of the first remote user.
NOTE: Any notification description received at a remote user immediately prior to a clearing indication is
cancelled by that clearing indicator and can be ignored.
9.2.3.2 Exceptional procedures
All exceptional conditions shall be treated according to the procedures of EN 300 403-1 [11], subclause 5.8.
ETSI
16 EN 300 188-1 V1.2.4 (1998-06)
9.2.4 Creation of a private communication with a remote user
9.2.4.1 Normal operation
The remote user, for which a private communication is required, is identified at the served user by a CR relating to either
the Active-Held connection, or to the Active-Idle connection. Depending on which applies, one of the two following
procedures shall be followed:
a) If the remote user, for which a private communication is required, is identified at the served user by a CR relating
to the Active-Held connection, the served user shall send an End3PTY invoke component to the network in a
FACILITY message with that CR, in accordance with the procedures of EN 300 196-1 [15], subclause 8.3.1.1.
On receiving such an invoke component in a FACILITY message, the network shall:
i) remove the three-way bridge from both the Active-Idle connection and the Active-Held connection;
ii) release the three-way bridge;
iii) return to the served user an End3PTY return result component, within a FACILITY message, according to the
procedures of EN 300 196-1 [15], subclause 8.3.1.1, and using the CR of the Active-Held connection;
iv) send a NOTIFY message to the remote user with which private communication is required containing a
Notification indicator information element with a notification description of "Remote hold"; and,
v) send a NOTIFY message to the other remote user containing a Notification indicator information element with a
notification description of "Conference disconnected".
When the served user receives a correctly encoded End3PTY return result component, within a FACILITY
message, the user shall accept the provided information and shall:
i) use the CR relating to the Active-Idle connection, perform the Hold function in accordance with the procedures
of EN 300 196-1 [15], subclause 7.2;
ii) use the CR relating to the Active-Held connection, perform the Retrieve function in accordance with the
procedures of EN 300 196-1 [15], subclause 7.4.
NOTE 1: If the network processes the RETRIEVE message before the HOLD message (e.g. the user sends a
RETRIEVE message before the Hold function is completed, or due to internal message handling in the
network), the successful outcome of the Retrieve function will depend on the availability of a free
B-channel. In case a free B-channel is not available, the network cannot successfully complete the Retrieve
function. In order to ensure success of channel selection during the Retrieve function, unless the user knows
that a free B-channel is available, the user should wait for completion of the Hold function before
performing the Retrieve function.
The network shall complete the Hold and Retrieve functions (according to the procedures of subclauses 7.2 and
7.4 of EN 300 196-1 [15]), creating and using any appropriate reservation (according to the procedures of
subclause 10.1 of EN 300 196-1 [15]). On successful completion of the Hold function (i.e. the HOLD
ACKNOWLEDGE message is sent) the network shall send a NOTIFY message, to the remote user that is not to be
included in the private communication, containing a Notification indicator information element with a notification
description of "Remote hold". On successful completion of the Retrieve function (i.e. RETRIEVE
ACKNOWLEDGE message is sent) the network shall send a NOTIFY message, to the remote user for whom
private communication is desired, containing a Notification indicator information element with a notification
description of "Conference disconnected".
NOTE 2: A Notification indicator information element with a notification description of "Remote retrieval" is not
sent to the remote user under these circumstances.
As a result of the procedures of this item of this subclause, the call state of the connections, at both the network and
the served user, is unchanged. The auxiliary state of the connection of the private communication changes from Call
Held to Idle. The auxiliary state of the other connection changes from Idle to Call Held.
ETSI
17 EN 300 188-1 V1.2.4 (1998-06)
b) If the remote user, for which a private communication is required, is identified at the served user by the CR
relating to the Active-Idle connection, the served user shall send an End3PTY invoke component to the network in
a FACILITY message with that CR, in accordance with the procedures of EN 300 196-1 [15], subclause 8.3.1.1.
On receiving such an invoke component in a FACILITY message, the network shall:
i) remove the three-way bridge from both the Active-Idle connection and the Active-Held connection;
ii) release the three-way bridge;
iii) return to the served user an End3PTY return result component, within a FACILITY message, according to the
procedures of EN 300 196-1 [15], subclause 8.3.1.1, and using the CR of the Active-Idle connection;
iv) send a NOTIFY message to both remote users containing a Notification indicator information element with a
notification description of "Conference disconnected"; and,
v) send to the remote user for which private communication is not required, either in the same NOTIFY message
as (iv), or in a subsequent NOTIFY message, a Notification indicator information element with a notification
description of "Remote hold".
NOTE 3: If any intervening protocol between the network of the served user and the network of the remote user does
not support transmission of two notification descriptions in the same message, then this should be mapped
at that point to a message containing a single notification description of "Conference disconnected", and a
subsequent message containing a notification description of "Remote hold".
When the served user receives a correctly encoded End3PTY return result component, within a FACILITY
message, the user shall accept the provided information and take no further action.
As a result of the procedures of this item of this subclause, the call state and the auxiliary state of the connections,
at both the network and the served user, are unchanged.
9.2.4.2 Exceptional procedures
On receiving an End3PTY invoke component, within a FACILITY message, according to the procedures of
EN 300 196-1 [15], subclause 8.3.1.1, but no three-way conversation exists, the network shall return to the served user an
End3PTY return error component, according to the procedures of EN 300 196-1 [15], subclause 8.3.1.1, in any
appropriate message and using the CR on which the message has been received.
On receiving an End3PTY invoke component, within a message other than a FACILITY message, according to the
procedures of EN 300 1
...