ETSI EN 300 185-1 V1.2.4 (1998-06)
Integrated Services Digital Network (ISDN); Conference call, add-on (CONF) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification
Integrated Services Digital Network (ISDN); Conference call, add-on (CONF) supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification
REN/SPS-05145-J1-1
Digitalno omrežje z integriranimi storitvami (ISDN) - Dopolnilna storitev: konferenčni klic, postopno vzpostavljanje (CONF) - Protokol digitalne naročniške signalizacije št. 1 (DSS1) - 1. del: Specifikacija protokola
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-april-2005
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL ,6'1 'RSROQLOQDVWRULWHY
NRQIHUHQþQLNOLFSRVWRSQRY]SRVWDYOMDQMH &21) 3URWRNROGLJLWDOQHQDURþQLãNH
VLJQDOL]DFLMHãW '66 GHO 6SHFLILNDFLMDSURWRNROD
Integrated Services Digital Network (ISDN); Conference call, add-on (CONF)
supplementary service; Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 1: Protocol specification
Ta slovenski standard je istoveten z: EN 300 185-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 185-1 V1.2.4 (1998-06)
European Standard (Telecommunications series)
Integrated Services Digital Network (ISDN);
Conference call, add-on (CONF) supplementary service;
Digital Subscriber Signalling System No. one (DSS1) protocol;
Part 1: Protocol specification
2 EN 300 185-1 V1.2.4 (1998-06)
Reference
REN/SPS-05145-J1-1 (1po90iqo.PDF)
Keywords
ISDN, CONF, DSS1, supplementary service
ETSI
Postal address
F-06921 Sophia Antipolis Cedex - FRANCE
Office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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
secretariat@etsi.fr
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 185-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 . 9
6.1 Provision and withdrawal.9
6.2 Requirements on the originating network side.9
6.3 Requirements on the destination network side .9
7 Coding requirements. 9
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 Beginning the conference from the Null call state.12
9.2.1.1 Normal operation.12
9.2.1.2 Exceptional procedures .12
9.2.2 Beginning the conference from the Active call state (N10, U10).13
9.2.2.1 Normal operation.13
9.2.2.2 Exceptional procedure.13
9.2.3 Adding a remote user.13
9.2.3.1 Normal operation.13
9.2.3.2 Exceptional procedures .14
9.2.4 Isolate a remote user.14
9.2.4.1 Normal operation.14
9.2.4.2 Exceptional procedures .15
9.2.5 Reattach a remote user.15
9.2.5.1 Normal operation.15
9.2.5.2 Exceptional procedures .15
9.2.6 Splitting a remote user.15
9.2.6.1 Normal operation.15
9.2.6.2 Exceptional procedures .16
9.2.7 Disconnect a remote user.16
9.2.7.1 Normal operation.16
9.2.7.2 Exceptional procedures .16
9.2.8 Disconnection by a remote user.17
9.2.8.1 Normal operation.17
9.2.8.2 Exceptional procedures .17
9.2.9 Terminate the conference.17
9.2.9.1 Normal operation.17
9.2.9.2 Exceptional procedures .17
ETSI
4 EN 300 185-1 V1.2.4 (1998-06)
10 Procedures for interworking with private ISDNs . 17
11 Interactions with other networks. 17
12 Interactions with other supplementary services. 18
13 Parameter values (timers). 18
14 Dynamic description (SDL diagrams). 18
Annex A (informative): Signalling flows . 35
Annex B (informative): Changes with respect to the previous ETS 300 185-1. 43
History. 44
ETSI
5 EN 300 185-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) Conference call, add-on (CONF)
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) to support the
Conference call, add-on (CONF) supplementary service. The stage 1 and stage 2 aspects are detailed in ETS 300 183 and
ETS 300 184, respectively.
The present version updates the references to the basic call specifications and incorporates all previous amendments and
corrigenda.
ETSI
6 EN 300 185-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 185-1 V1.2.4 (1998-06)
1 Scope
This first part of EN 300 185 specifies the stage three of the Conference call, add-on (CONF) 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 [1])
by means of the Digital Subscriber Signalling System No. one (DSS1). Stage 3 identifies the protocol procedures and
switching functions needed to support a telecommunications service (see CCITT Recommendation I.130 [2]).
In addition, the present document specifies the protocol requirements at the T reference point where the service is
provided to the user via an intermediate 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 CONF supplementary service provides a user with the ability to have a multi-connection call, i.e. a simultaneous
communication between more than two parties.
The CONF supplementary service is applicable to all 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 CONF 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 I.411 (1988): "ISDN user-network interfaces - Reference configurations".
[2] CCITT Recommendation I.130 (1988): "Method for the characterisation of telecommunication
services supported by an ISDN and network capabilities of an ISDN".
[3] 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".
[4] 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]".
[5] EN 300 195-1: "Integrated Services Digital Network (ISDN); Supplementary service interactions;
Digital Subscriber Signalling System No. one (DSS1) protocol; Part 1: Protocol specification".
[6] 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".
ETSI
8 EN 300 185-1 V1.2.4 (1998-06)
[7] CCITT Recommendation I.112: "Vocabulary of terms for ISDNs".
[8] CCITT Recommendation X.208 (1988): "Specification of Abstract Syntax Notation One (ASN.1)".
[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] ETS 300 184: "Integrated Services Digital Network (ISDN); Conference call, add-on (CONF)
supplementary service; Functional capabilities and information flows".
[12] CCITT Recommendation Q.71 (1988): "ISDN 64 kbit/s circuit mode switched bearer services".
[13] CCITT Recommendation I.210 (1988): "Principles of telecommunication services supported by an
ISDN and the means to describe them".
3 Definitions
For the purposes of the present document, the following definitions apply:
add: An action initiated by the served user that adds a new remote user to the conference.
auxiliary state: A state as defined in EN 300 196-1 [3], subclause 7.4. An auxiliary state may exist for a call reference in
parallel with the call state.
call state: A state as defined in EN 300 403-1 [4], subclause 2.1 for either the user or the network as appropriate. A call
state may exist for each call reference (and for each additional responding CEI in the incoming call states).
conference ID: An identifier that identifies an instance of the CONF supplementary service.
drop: An action initiated by the served user that disconnects a remote user from the conference.
Integrated Services Digital Network (ISDN): See CCITT Recommendation I.112 [7], § 2.3, definition 308.
invoke component: See EN 300 196-1 [3], subclause 8.2.2.1. Where reference is made to a "xxxx" invoke component, an
invoke component is meant with its operation value set to the value of operation "xxxx".
isolate: An action initiated by the served user that restricts communications with a participant of the conference.
network: The DSS1 protocol entity at the network side of the user-network interface.
party ID: An identifier that identifies a participant within an instance of the CONF supplementary service.
reattach: An action initiated by the served user that re-establishes the communication with a participant of the
conference.
remote user: The DSS1 protocol entity at the user side of the user-network interface which is involved in an instance of
the CONF supplementary service but which has no control of it.
return error component: See EN 300 196-1 [3], subclause 8.2.2.3. Where reference is made to a "xxxx" return error
component, a return error component is meant which is related to a "xxxx" invoke component.
return result component: See EN 300 196-1 [3], subclause 8.2.2.2. Where reference is made to a "xxxx" return result
component, a return result component is meant which is related to a "xxxx" invoke component.
served user: The DSS1 protocol entity at the user side of the user-network interface used to request and control the
CONF supplementary service.
service; telecommunications service: See CCITT Recommendation I.112 [7], § 2.2, definition 201.
split: An action initiated by the served user that creates a normal call between the served user and a remote user.
ETSI
9 EN 300 185-1 V1.2.4 (1998-06)
supplementary service: See CCITT Recommendation I.210 [13], § 2.4.
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:
ASN.1 Abstract Syntax Notation One
CONF Conference call, add-on
DSS1 Digital Subscriber Signalling System No. one
ISDN Integrated Services Digital Network
PSTN Public Switched Telephone Network
SDL Specification Description Language
5 Description
The CONF supplementary service can be invoked either from the Null call state (N0, U0) or, additionally, as a network
option from an existing call in the Active call state (N10, U10).
When the CONF supplementary service is invoked, conference resources (e.g. a "bridge") are allocated to the served
user. In the case of invocation from an active call, this call shall be automatically connected by the network to the
conference resources.
Once a conference is active, remote users may be added, dropped, isolated (i.e. prevented from communicating with the
conference), reattached or split (i.e. removed from the conference but remain connected to the conference controller).
Remote users are notified of these actions.
NOTE: During an interim period of time, some networks may not support the transfer of notifications.
6 Operational requirements
6.1 Provision and withdrawal
Not applicable.
6.2 Requirements on the originating network side
Not applicable.
6.3 Requirements on the destination network side
Not applicable.
7 Coding requirements
Table 1 shows the definition of the operations and errors required for the CONF supplementary service using ASN.1 as
specified in CCITT Recommendation X.208 [8] and using the OPERATION and ERROR macro as defined in
figure 4/X.219 of CCITT Recommendation X.219 [9].
The formal definition of the component types to encode these operations and errors is provided in EN 300 196-1 [3],
annex D, clause D.1.
ETSI
10 EN 300 185-1 V1.2.4 (1998-06)
The inclusion of components in Facility information elements is defined in EN 300 196-1 [3], subclause 11.2.2.1.
Table 1: Definition of operations and errors for the CONF supplementary service
Conference-Add-On-Operations {ccitt identified-organization etsi (0) 185 operations-and-types
(1)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS BeginCONF, AddCONF, SplitCONF, DropCONF,
IsolateCONF, ReattachCONF, PartyDISC,
IllConferenceId, IllPartyId,
NumberOfPartiesExceeded,
NotActive, NotAllowed, PartyId, ConferenceId, ConfSize;
IMPORTS OPERATION,
ERROR
FROM Remote-Operation-Notation
{joint-iso-ccitt remote-operations(4) notation(0)}
notSubscribed, notAvailable,
supplementaryServiceInteractionNotAllowed,
resourceUnavailable, invalidCallState
FROM General-Errors
{ccitt identified-organization etsi(0) 196 general-errors (2)};
BeginCONF ::= OPERATION
ARGUMENT ConfSize -- optional
RESULT SEQUENCE {
ConferenceId,
PartyId OPTIONAL }
ERRORS {notSubscribed, notAvailable,
resourceUnavailable,
invalidCallState,
NumberOfPartiesExceeded}
AddCONF ::= OPERATION
ARGUMENT ConferenceId
RESULT PartyId
ERRORS {IllConferenceId,
NumberOfPartiesExceeded,
NotAllowed,
supplementaryServiceInteractionNotAllowed,
invalidCallState}
SplitCONF ::= OPERATION
ARGUMENT SEQUENCE {
ConferenceId,
PartyId}
RESULT
ERRORS {IllConferenceId, IllPartyId}
DropCONF ::= OPERATION
ARGUMENT PartyId
RESULT
ERRORS {IllPartyId, NotActive}
IsolateCONF ::=OPERATION
ARGUMENT PartyId
RESULT
ERRORS {IllPartyId, NotActive}
ReattachCONF ::= OPERATION
ARGUMENT PartyId
RESULT
ERRORS {IllPartyId, NotActive}
ETSI
11 EN 300 185-1 V1.2.4 (1998-06)
Table 1 (concluded): Definition of operations and errors for the CONF supplementary service
PartyDISC ::= OPERATION
ARGUMENT PartyId
IllConferenceId ::=ERROR
IllPartyId ::=ERROR
NumberOfPartiesExceeded::=ERROR
NotActive ::=ERROR
NotAllowed ::=ERROR
PartyId ::= INTEGER (0.127)
ConferenceId ::= INTEGER (0.127)
ConfSize ::=INTEGER (0.127)
beginCONF BeginCONF ::= 40
addCONF AddCONF ::= 41
splitCONF SplitCONF ::= 42
dropCONF DropCONF ::= 43
isolateCONF IsolateCONF ::= 44
reattachCONF ReattachCONF ::= 45
partyDISC PartyDISC ::= 46
illConferenceId IllConferenceId ::= 28
illPartyId IllPartyId ::= 29
numberOfPartiesExceeded NumberOfPartiesExceeded ::= 30
notActive NotActive ::= 31
notAllowed NotAllowed ::= 32
END -- of Conference-Add-On-Operations
All components (invoke, return result, return error and reject) shall be included within a Facility information element.
This Facility information element may be included in any appropriate message as specified in EN 300 196-1 [3],
subclause 8.3.1.1, unless a more restricting specification is given in clause 9.
Table 2 contains the additional codepoints for the CONF supplementary service which shall be employed in octet 3 of the
Notification indicator information element (to be conveyed in the NOTIFY message).
Table 2: Additional 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 0 0 0 1 0 0 Other party added
1 1 0 0 0 1 0 1 Isolated
1 1 0 0 0 1 1 0 Reattached
1 1 0 0 0 1 1 1 Other party isolated
1 1 0 0 1 0 0 0 Other party reattached
1 1 0 0 1 0 0 1 Other party split
1 1 0 0 1 0 1 0 Other party disconnected
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 states associated with basic call control given in EN 300 403-1 [4] shall apply.
ETSI
12 EN 300 185-1 V1.2.4 (1998-06)
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 CONF
supplementary service.
9.2 Invocation and operation
9.2.1 Beginning the conference from the Null call state
9.2.1.1 Normal operation
To request a conference from the Null call state (U0), the served user shall send a SETUP message to the network
including a Facility information element and a Bearer capability information element. The Facility information element
shall contain a BeginCONF invoke component. This component may contain a ConfSize parameter indicating the
maximum number of remote users. If this parameter is not provided, then the network shall set the conference size to a
network dependent value. The Bearer capability information element shall indicate an appropriate bearer capability with
regard to the applicability of the CONF supplementary service. The Called party number and Called party subaddress
information element shall be omitted by the user. For the purpose of basic call processing the network shall regard the
SETUP message as containing all the information necessary to establish the connection to the conference bridge, i.e. the
SETUP ACKNOWLEDGE message shall not be used. Further, the normal basic call procedures apply according to
subclause 5.1 of EN 300 403-1 [4].
When the network responds with a CONNECT message it shall include a BeginCONF return result component in a
Facility information element. This component contains a ConferenceId parameter. The network shall allocate a
ConferenceId that is unique for all accesses assigned for the served user. The ConferenceId shall be used in some
operations to identify the conference explicitly.
When the user receives a correctly encoded BeginCONF return result component the user shall accept the provided
information, save the included ConferenceId and shall not respond to the network.
The procedures used to request a conference are completely independent from other calls.
9.2.1.2 Exceptional procedures
If the user is not subscribed to the CONF supplementary service, the network shall start the basic call clearing procedures
as defined in subclause 5.3 of EN 300 403-1 [4]. One of the messages sent by the network to the served user shall contain
a Facility information element with a BeginCONF return error component indicating "notSubscribed". Furthermore, this
message shall contain a Cause information element indicating cause #31 "Normal, unspecified" and a location of "public
network serving the local user".
If the network cannot accept the operation because the conference size as requested by the user exceeds the size supported
by the network, the network shall start the basic call clearing procedures as defined in subclause 5.3 of EN 300 403-1 [4].
One of the messages sent by the network to the served user shall contain a Facility information element with a
BeginCONF return error component indicating "numberOfPartiesExceeded". Furthermore, this message shall contain a
Cause information element indicating cause #31 "Normal, unspecified" and a location of "public network serving the local
user".
If the network cannot accept the operation because of lack of a conference bridge or other resources, the network shall
start the basic call clearing procedures as defined in subclause 5.3 of EN 300 403-1 [4]. One of the messages sent by the
network to the served user shall contain a Facility information element with a BeginCONF return error component
indicating "resourceUnavailable". Furthermore, this message shall contain a Cause information element indicating cause
#31 "Normal, unspecified" and a location of "public network serving the local user".
ETSI
13 EN 300 185-1 V1.2.4 (1998-06)
If the user indicates an in-appropriate bearer capability, the network shall start the basic call clearing procedures as
defined in subclause 5.3 of EN 300 403-1 [4]. One of the messages sent by the network to the served user shall contain a
Facility information element with a BeginCONF-Return-Error component indicating the error "notAvailable".
Furthermore, this message shall contain a Cause information element indicating cause #31 "Normal, unspecified" and a
location of "public network serving the local user".
9.2.2 Beginning the conference from the Active call state (N10, U10)
9.2.2.1 Normal operation
To accept a request for a conference from an active call is a network option.
To request a conference the served user shall send a FACILITY message to the network indicating the call reference of
the existing call and including a Facility information element. This Facility information element shall contain a
BeginCONF invoke component. This component may contain a ConfSize parameter indicating the maximum number of
remote users. If this parameter is not provided, then the network shall set the conference size to a network dependent
value. The served user shall only request a conference for a connection, identified by the call reference, with an
appropriate bearer capability. This connection can be either in the (Active, Idle) or (Active, Call Held) state.
The network shall send a BeginCONF return result component to the served user in a FACILITY message. This
component contains a ConferenceId and PartyId parameter. The ConferenceId shall be used in some operations to identify
the conference explicitly. The network shall allocate a ConferenceId that is unique for all accesses assigned for the served
user. The PartyId shall be used in subsequent operations to identify the remote user of the original call.
When the user receives a correctly encoded BeginCONF return result component the user shall accept the provided
information, save the included ConferenceId and PartyId parameter and shall not respond to the network.
The procedures to generate PartyId's are outside the scope of the present document. The requirements with respect to
PartyId's are that a PartyId used to identify a remote user shall not be used again until the remote user identified by this
PartyId has been dropped from the conference, i.e. a PartyId shall be unique within the context of a single conference.
The call state and auxiliary state of the network and the served user shall not be changed.
The network shall send a NOTIFY message to the remote user with a Notification indicator information element indicating
that this remote user has been added to the conference ("Conference established").
9.2.2.2 Exceptional procedure
If the user is not subscribed to the CONF supplementary service, the network shall send a BeginCONF return error
component indicating "notSubscribed" to the served user in a FACILITY message.
If the network cannot accept the operation because the conference size as requested by the user exceeds the size supported
by the network, the network shall send a BeginCONF return error component indicating "numberOfPartiesExceeded" to
the served user in a FACILITY message.
If the network cannot accept this operation because of lack of a conference bridge or other resources, the network shall
send a BeginCONF return error component indicating "resourceUnavailable" to the served user in a FACILITY message.
If the network receives a BeginCONF invoke component for a call reference value that is not in the Active call state
(N10) and not in the Null call state (N0), the network shall send a BeginCONF return result component indicating the
error "invalidCallState" to the served user in a FACILITY message.
If the user indicates an in-appropriate bearer capability, the network shall send a BeginCONF-Return-Error component
indicating "notAvailable" to the served user in a FACILITY message.
9.2.3 Adding a remote user
9.2.3.1 Normal operation
To add a new remote user, the connection to the conference bridge can be either in the (Active, Idle) state or in the
(Active, Call Held) state. The notation (Active, Call Held) is defined in EN 300 196-1 [3], subclause 7.5. The served
ETSI
14 EN 300 185-1 V1.2.4 (1998-06)
user shall only add a remote user for a connection with an appropriate bearer capability. The connection to the remote
user to be added shall be either in the (Active, Idle) state or (Active, Call Held) state.
The served user shall send a FACILITY message to the network indicating the call reference of the call to be added and
including an AddCONF invoke component. This component contains a ConferenceId parameter indicating the conference.
The network shall send a DISCONNECT message to the served user containing a Facility information element with an
AddCONF return result component and continue clearing according to subclause 5.3.3 of EN 300 403-1 [4]. This
component contains a PartyId. This PartyId shall be used in subsequent operations to identify the added remote user. The
first clearing message shall contain a Cause information element indicating cause #31 "Normal, unspecified" and a
location of "public network serving the local user".
When the user receives a correctly encoded AddCONF return result component, the user shall accept the provided
information, save the included PartyId and shall not respond to the network.
The procedures to generate PartyId's are outside the scope of the present document. The requirements with respect to
PartyId's are that a PartyId used to identify a remote user shall not be used again until the remote user identified by this
PartyId has been dropped from the conference, i.e. a PartyId shall be unique within the context of a single conference.
The call state and auxiliary state of the network and the served user for the call reference identifying the connection to the
conference bridge shall not be changed.
NOTE: If the connection to the conference bridge was in the (Active, Call Held) state, the served user can retrieve
the connection in order for communication to take place. This procedure is part of the call hold
supplementary service.
The network shall send a NOTIFY message to the added remote user with a Notification indicator information element
indicating that this remote user has been added to the conference ("Conference established").
The network shall send a NOTIFY message to all other remote users with a Notification indicator information element
indicating that a new remote user has been added to the conference ("Other party added").
9.2.3.2 Exceptional procedures
If the ConferenceId used is not associated with a conference known to the network, the network shall send an AddCONF
return error component indicating "illConferenceId" to the served user in a FACILITY message.
NOTE: This error can also occur as a result of routing constraints.
If the network cannot accept this operation because the maximum number of parties has been reached, the network shall
send an AddCONF return error component indicating "NumberOfPartiesExceeded" to the served user in a FACILITY
message.
If the network cannot accept this operation because addition of the call would result in violation of Closed User Group
rules, the network shall send an AddCONF return error component indicating
"supplementaryServiceInteractionNotAllowed" to the served user in a FACILITY message.
If the network receives a Facility information element containing an AddCONF invoke component for a call reference
value that is not in the Active call state (N10) and not in the Null call state (N0), the network shall send an AddCONF
return error component to the served user in a FACILITY message indicating the error "invalidCallState".
If the network cannot accept this operation for any other reason, the network shall send an AddCONF return error
component indicating "notAllowed" to the served user in a FACILITY message.
9.2.4 Isolate a remote user
9.2.4.1 Normal operation
To isolate a remote user, the served user shall send an IsolateCONF invoke component to the network in a FACILITY
message. The component includes a PartyId parameter identifying the remote user to be isolated.
To indicate a successful operation, the network shall send an IsolateCONF return result component to the served user in a
FACILITY message.
ETSI
15 EN 300 185-1 V1.2.4 (1998-06)
When the user receives a correctly encoded IsolateCONF return result component the user shall accept the provided
information and shall not respond to the network.
After execution of the IsolateCONF operation the remote user remains connected to the conference but communication is
not possible.
The network shall send a NOTIFY message to the isolated remote user with a Notification indicator information element
indicating "Isolated".
The network shall send a NOTIFY message to all other remote users with a Notification indicator information element
indicating that a remote user has been isolated ("Other party isolated").
9.2.4.2 Exceptional procedures
If the PartyId used is not associated with a remote user, the network shall send an IsolateCONF return error component
indicating "illPartyId" to the served user in a FACILITY message.
If the network cannot accept this operation because the conference has not successfully been established, the network shall
send an IsolateCONF return error component indicating "notActive" to the served user in a FACILITY message.
If the remote user indicated in the IsolateCONF invoke component is already isolated, then the network shall not treat this
as an error but shall return an IsolateCONF return result component to the served user in a FACILITY message.
9.2.5 Reattach a remote user
9.2.5.1 Normal operation
To reattach an isolated remote user, the served user shall send a ReattachCONF invoke component to the network in a
FACILITY message. The component includes a PartyId parameter identifying the remote user to be reattached.
To indicate a successful operation, the network shall connect the reattached remote user to the conference and send a
ReattachCONF return result component to the served user in a FACILITY message.
When the user receives a correctly encoded ReattachCONF return result component, the user shall accept the provided
information and shall not respond to the network.
The network shall send a NOTIFY message to the reattached remote user with a Notification indicator information
element indicating "Reattached".
The network shall send a NOTIFY message to all other parties with a Notification indicator information element
indicating that a remote user has been reattached ("Other party reattached").
9.2.5.2 Exceptional procedures
If the PartyId used is not associated with a remote user, the network shall send a ReattachCONF return error component
indicating "illPartyId" to the served user in a FACILITY message.
If the network cannot accept this operation because the conference has not successfully been established, the network shall
send a ReattachCONF return error component indicating "notActive" to the served user in a FACILITY message.
If the remote user indicated in the ReattachCONF invoke component is already reattached, then the network shall not treat
this as an error but return a ReattachCONF return result component to the served user in a FACILITY message.
9.2.6 Splitting a remote user
9.2.6.1 Normal operation
To split a remote user that may be isolated, the served user shall send a SETUP message to the network including a
Facility information element and a Bearer capability information element. The Facility information element shall contain a
SplitCONF invoke component. This component contains a ConferenceId parameter identifying the conference and a
PartyId parameter identifying the remote user to be split. The Bearer capability information element shall indicate an
ETSI
16 EN 300 185-1 V1.2.4 (1998-06)
appropriate bearer capability with regard to the applicability of the CONF supplementary service. The Called party
number and Called party subaddress information element shall be omitted by the user. Further, the normal basic call
procedures apply according to subclause 5.1 of EN 300 403-1 [4].
To indicate a successful operation, the network shall send a SplitCONF return result component to the served user in the
CONNECT message.
On sending the SplitCONF return result component, the network shall release the PartyId; the PartyId may be used to
identify future remote users.
When the served user receives a correctly encoded SplitCONF return result component, the user shall accept the provided
information, release the PartyId included in the invoke component and shall not respond to the network.
After execution of the SplitCONF operation the served user has a separate call with the indicated remote user. All other
remote users are still involved in the conference.
The network shall send a NOTIFY message to the split remote user with a Notification indicator information element
indicating "Conference disconnected".
The network shall send a NOTIFY message to all other remote users with a Notification indicator information element
indicating that a remote user has been split ("Other party split").
9.2.6.2 Exceptional procedures
If the ConferenceId used is not associated with a conference, the network shall start the basic call clearing procedures
according to subclause 5.3 of EN 300 403-1 [4]. One of the messages sent to the served user shall contain a SplitCONF
return error component indicating "illConferenceId". Furthermore, this message shall contain a Cause information element
indicating cause #31 "Normal, unspecified" and a location of "public network serving the local user".
If the PartyId used is not associated with a remote user, the network shall start the basic call clearing procedures
according to subclause 5.3 of EN 300 403-1 [4]. One of the messages sent to the served user shall contain a SplitCONF
return error component indicating "illPartyId". Furthermore, this message shall contain a Cause information element
indicating cause #31 "Normal, unspecified" and a location of "public network serving the local user".
9.2.7 Disconnect a remote user
9.2.7.1 Normal operation
To disconnect a remote user, the served user shall send a DropCONF invoke component to the network in a FACILITY
message. The component includes a PartyId parameter identifying the remote user to be disconnected.
To indicate that the identified remote user
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...