1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T I.254.1 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU INTEGRATED SERVICES DIGITAL NETWORK (ISDN) SERVICE CAPABILITIES MULTIPARTY SUPPLEMENTARY SERVICES: CONFERENCE CALLING (CONF) ITU-T Recommendation I.254.1 (Extract from the Blue Book) NOTES 1 ITU-T Re
2、commendation I.254.1 was published in Fascicle III.7 of the Blue Book. This file is an extract from the Blue Book. While the presentation and layout of the text might be slightly different from the Blue Book version, the contents of the file are identical to the Blue Book version and copyright condi
3、tions remain unchanged (see below). 2 In this Recommendation, the expression “Administration” is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. ITU 1988, 1993 All rights reserved. No part of this publication may be reproduced or utilized i
4、n any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the ITU. Fascicle III.7 - Rec. I.254.1 1 Recommendation I.254.1 Fascicle III.7 - Rec. I.254.1 MULTIPARTY SUPPLEMENTARY SERVICES CONFERENCE CALLING (CONF) (Melbourne, 1988) 1
5、 Conference Calling Service Description 1.1 Definition Conference Calling is an ISDN supplementary service which allows a user to communicate simultaneously with multiple parties, which may also communicate among themselves. This description deals primarily with the establishment and manipulation of
6、 the connections used to form a conference call and is therefore expected to be applicable to many types of conference calls (e.g. voice, data, video, multi-media). Although provision is made for specifying the conference type, it is recognized that the control of conferencing functions (especially
7、for those other than speech) is beyond the scope of this Recommendation. This Recommendation describes the operation of the “Add-on” Conference Calling service only. Other forms of Conference Calling (e.g. “Meet-me”) are not described. 1.2 Description 1.2.1 General description When Conference Callin
8、g is invoked, conference resources (e.g. a ”bridge”) are allocated to the served user, and any calls indicated by the service request are added to the conference. Once a conference is active, parties may be added, dropped, isolated (i.e. prevented from communicating with the conference), reattached,
9、 or split (i.e. removed from the conference but remain connected to the conference controller). The controller can place his connection to the conference on hold, retrieve the conference, end the conference, or disconnect himself from the conference. 1.2.2 Specific terminology 1.2.2.1 Served user, c
10、onference controller, conferees, parties During the invocation phase, the service is under the control of the “served user”, i.e. the one for whom the service was subscribed or, in those cases where subscription is not required, the one who invokes the service. Once the conference is in the active s
11、tate, the service is under the control of the “conference controller” who, in most cases, is the served user but could be a party other than the served user if transfer of control has occurred (an anticipated future extension to this service). Any party other than the conference controller is called
12、 a “conferee”. All participants in the conference call are considered “parties”. 1.2.2.2 Call ID, Party ID, Connection ID Call ID: the served users (controllers) reference to a call of which he is a party. Examples: 1) the conference call itself, 2) a call which is to be added to the conference, 3)
13、a call which is formed by splitting a party from the conference. Party ID: the served users (or controllers) reference to a particular party within the context of a call. Connection ID: the served users (or controllers) reference to a particular connection (to a particular party) within the context
14、of a call. Observe that multiple parties may be associated with a given call, e.g. a conference call. Moreover, there can be multiple connections associated with a single party, e.g. a simultaneous voice and video call. Note - This service description assumes that there exists only one connection to
15、 a given party. Procedures to allow for multiple connection (e.g. multi-media conference calls) to a given party are anticipated future extensions. 2 Fascicle III.7 - Rec. I.254.1 1.2.2.3 Conference states Conference Idle: the state prior to the reception of a “conference invocation request”, or aft
16、er a particular conference has ended. Conference Active: the state in which conference resources have been allocated to the specified conference and at least one party has a connection to the conference. That connection could be either active or held. Conference Floating: the state in which the conf
17、erence is active but without a controller. This state is possible when two or more conferees exist on an active conference and the controller successfully disconnects himself (see Figure 1/I.254.1, sheet 7). 1.2.3 Qualification on the applicability to telecommunication services This supplementary se
18、rvice is considered meaningful when applied to the Telephony teleservice and the speech and 3.1 kHz audio bearer services. Furthermore, it may also be meaningful when applied to other services. 1.3 Procedures 1.3.1 Provision/withdrawal The Conference Calling supplementary service may be subscribed t
19、o by prior arrangements with the service provider. The subscription parameters include the maximum (and, if different, the default) number of conferees allowed in a conference call. Note - The default will usually be three, but may be six (or some other number). If the served user has subscribed to
20、more than one size conference service and wishes to establish a conference of a size other than the default size, the served user must request the properly-sized conference before any parties are added to the conference. Withdrawal of the service is made by the service provider upon request by the s
21、ubscriber or for service provider reasons. 1.3.2 Normal procedures 1.3.2.1 Activation/deactivation/registration None identified. 1.3.2.2 Invocation and operation 1.3.2.2.1 Beginning the conference call (see Figure 1/I.254.1, Sheets 1 and 2) Invocation parameters: The Conference Calling service must
22、be invoked by the served user. The invocation request must include the “root” Call ID, i.e. the Call ID by which the served user (or controller) will refer to the conference call itself. This Call ID may be either a new Call ID or the Call ID of an existing call which is to be used to form the confe
23、rence. The invocation request may include the following additional information: Conference size: the intended maximum number of parties for the conference (if different from the default). Existing call/party information (Call IDs/Party IDs/disposition of related B-channel connections): in order to i
24、nitially include one or more parties from an existing call in the conference, the invocation request must include the Call ID, and optionally the Party ID and information as to how the B-channel associated with that call is to be handled. New party information (called party address, other “set-up” i
25、nformation): in order to initially include a party for which there is no existing call, the invocation request must include the desired partys address, and optionally other information contained in a normal call request. Note - Some information which is mandatory in a normal call request (e.g. “bear
26、er capability”) can be inferred (e.g. from the conference type) and hence may not be mandatory here. Connection request: either active or held. This request defines the served users initial connection to the conference. Possible values follow: Fascicle III.7 - Rec. I.254.1 3 Active state specified:
27、i) Specific B-channel: a specified preferred/exclusive B-channel shall be used to immediately establish a connection to the conference. ii) Any available B-channel may be used. Held state specified: i) Reserved B-channel: a B-channel is to be reserved for (later) connection to the conference. ii) No
28、 reserved B-channel: in this case no B-channel is allocated or reserved; the served user may have to free up a B-channel later when participation in the conference is desired. Conference type: in general, the bearer capability compatibility check during context arbitration can be used to infer the t
29、ype of conference required. It is assumed to be “speech”. Other conference types may require special bridging facilities and/or higher layer control. Conference bridge location: it should be possible to request the conference bridge to be at a specified location, e.g. close to some grouping of confe
30、rees. Procedures for remote location of conference bridge facilities are anticipated future extensions. Defaults for invocation parameters If any of the information described above is not included in the invocation request, the following defaults will occur: Conference size: the size defaults to the
31、 subscribed default conference size specified at subscription time (if the served user specified a default conference size at subscription time) or the subscribed maximum conference size (if a default conference size was not specified), or the default conference size specified by the service provide
32、r (if the served user did not subscribe to the service). Existing call/party information: i) Call IDs: if no Call ID other than the root Call ID is specified, no existing calls will be initially included in the conference. ii) Party IDs: if not specified, each party (other than the served user) of t
33、he indicated Call ID(s) will be initially included in the conference. iii) Disposition of related B-channel connections: if disposition information is not included, the related B-channel connections will be deallocated, unless the service provider chooses to use them for connection of the served use
34、r to the conference call (e.g. in a multi-media conference). New party information: i) Called party address: if not specified, no new parties will be initially included in the conference. ii) Other “set-up” information: for further study. Connection request: if no connection information is included,
35、 it is assumed that the served user wishes to be initially connected to the conference in the active state and any available B-channel may be used. i) If the served user indicates that he wishes to be connected to the conference in the active state but does not indicate “specific B-channel” or “any
36、available B-channel”, it is assumed that any available B-channel may be used. ii) If the served user indicates that he wishes his resulting connection to the conference to be in the held state, but does not indicate “reserved B-channel” nor “no reserved”, it is assumed that a B-channel is to be rese
37、rved for (later) connection to the conference. Conference type: if not specified, the service provider will attempt to derive the appropriate conference type from the bearer capabilities of the call(s) involved. If no calls are known by the service provider to be involved in the call, the default co
38、nference type shall be “speech”. Conference bridge location: if not specified, the service provider will attempt to place the conference bridge(s) in the most appropriate location, considering the call(s) known by the service provider to be involved at the time the request is made. 4 Fascicle III.7
39、- Rec. I.254.1 Procedures When a conference request is made, a conference call is set up. When the service provider receives the request to allocate resources for the conference call, it checks to see that the requested conference can be established. This procedure is termed “context arbitration”. C
40、ontext arbitration includes a bearer capability compatibility check, a supplementary services compatibility check, a check to see that the state of each connection to be added is acceptable, and a check for the availability of conference/network resources. Upon successful completion of the context a
41、rbitration, the resources needed are allocated. If the conference request is successful, all existing appropriate call(s) referenced in the conference request are added to the conference. Note - Adding parties from an existing call may not be successful in all cases due to remote bridging and rerout
42、ing limitations. Upon successful joining of the specified parties to the conference, any unused B-channels are deallocated and any single party calls are released. The service provider checks the conference request for additional information (optional parameters). For those optional parameters not i
43、ncluded in the conference request, the default values will be used. In addition, if the connection request parameter is not included and no additional parties are indicated (i.e. m = 0, n = 0) the service provider will prompt the served user for further actions. 1) Prompting procedures detected: if
44、the number of referenced existing calls (other than the root Call ID) in the conference request is zero and the controller connection request is not included, then the conference is put on hold from the served users point of view and the served user is prompted for further actions (i.e. the add-part
45、y procedure is automatically started). 2) No prompting procedures detected: if the number of referenced existing calls (other than the root Call ID) in the conference request is larger than zero, or if the controller connection request is specified, the referenced calls are automatically connected t
46、o the conference, which is now in an active state. The served users connection to the conference will also be active unless the controller has indicated that his connection to the conference should be held. The decision to put the conference on hold or not (from the served users point of view) is ba
47、sed on the information received in the Conference request, independent of the number of referenced existing calls. 1.3.2.2.2 Managing individual parties (see Figure 1/I.254.1, Sheets 2 and 3) When managing a party, the controller needs to specify the pair Call ID/Party ID. If no party(s) is specifie
48、d, the service provider will typically assume that the request applies to all parties associated with the indicated Call ID. (Exception: if Party ID is not specified in the drop party command, the last party added to conference is dropped.) In the active state of the conference, the conference contr
49、oller has the following options for managing parties in association with a conference: Add new party The conference controller can request that a new party be added to an existing conference call using procedures analogous to those used to start the conference call. Upon a request for the addition of a new party, the conference controller automatically puts the conference on hold. The service provider checks the Add Party request for additional information, i.e. whether or not the conference controller is to keep the conference on hold after the addition
