SIST ES 204 915-4-5 V1.1.1:2008
Open Service Access (OSA) - Application Programming Interface (API) - Part 4: Call Control - Sub-part 5: Conference Call Control SCF (Parlay 6)
Open Service Access (OSA) - Application Programming Interface (API) - Part 4: Call Control - Sub-part 5: Conference Call Control SCF (Parlay 6)
ETSI OSA APIs Phase 4. Based on ES 203 915 and the new requirements for OSA Phase 4, to produce ES 204 915 V1.1.1. ETSI OSA Phase 4 incorporates 3GPP OSA Release 7 and is also known as Parlay 6.0.The present document is part 4, sub-part 5 of the Stage 3 specification for an Application Programming Interface (API) for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality through an open standardised interface, i.e. the OSA APIs.
The present document specifies the Conference Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Conference Call Control SCF are defined here, these being:
• Sequence Diagrams.
• Class Diagrams.
• Interface specification plus detailed method descriptions.
• State Transition diagrams.
• Data Definitions.
• IDL Description of the interfaces.
• WSDL Description of the interfaces.
• Reference to the Java™ API description of the interfaces.
The process by which this task is accomplished is through the use of object modelling techniques described by the Unified Modelling Language (UML).
Odprti dostop do storitve (OSA) - Aplikacijski programski vmesnik (API) - 4. del: Krmiljenje klica - 5. poddel: Lastnost storitvene zmožnosti (SCF) pri krmiljenju konferenčnih klicev (Parlay 6)
General Information
Standards Content (Sample)
Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 5: Conference Call Control SCF
(Parlay 6)
�
2 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
Reference
DES/TISPAN-01032-4-05-OSA
Keywords
API, IDL, OSA, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - 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
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Conference Call Control Service Sequence Diagrams.8
4.1 Meet-me conference without subconferencing.8
4.2 Non-add hoc add-on with subconferencing.10
4.3 Non-addhoc add-on multimedia.12
4.4 Resource Reservation.14
5 Class Diagrams.14
6 Conference Call Control Service Interface Classes.16
6.1 Interface Class IpConfCallControlManager.17
6.1.1 Method createConference().17
6.1.2 Method checkResources().18
6.1.3 Method reserveResources().19
6.1.4 Method freeResources().20
6.2 Interface Class IpAppConfCallControlManager .20
6.2.1 Method conferenceCreated().20
6.3 Interface Class IpConfCall .21
6.3.1 Method getSubConferences().22
6.3.2 Method createSubConference().22
6.3.3 Method leaveMonitorReq().22
6.3.4 Method getConferenceAddress().23
6.4 Interface Class IpAppConfCall .23
6.4.1 Method partyJoined().23
6.4.2 Method leaveMonitorRes().24
6.5 Interface Class IpSubConfCall .24
6.5.1 Method splitSubConference().25
6.5.2 Method mergeSubConference().26
6.5.3 Method moveCallLeg().26
6.5.4 Method inspectVideo().26
6.5.5 Method inspectVideoCancel().27
6.5.6 Method appointSpeaker().27
6.5.7 Method chairSelection().27
6.5.8 Method changeConferencePolicy().27
6.6 Interface Class IpAppSubConfCall .28
6.6.1 Method chairSelection().28
6.6.2 Method floorRequest().28
7 Conference Call Control Service State Transition Diagrams.29
8 Conference Call Control Data Definitions .29
8.1 Event Notification Data Definitions.29
8.2 Conference Call Control Data Definitions .29
8.2.1 IpConfCall.29
8.2.2 IpConfCallRef.29
8.2.3 IpAppConfCall .29
8.2.4 IpAppConfCallRef.29
8.2.5 IpSubConfCall.30
8.2.6 IpSubConfCallRef.30
ETSI
4 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
8.2.7 IpAppSubConfCall.30
8.2.8 IpAppSubConfCallRef.30
8.2.9 TpSubConfCallIdentifierSet.30
8.2.10 TpConfCallIdentifier.30
8.2.11 TpSubConfCallIdentifier.30
8.2.12 IpAppConfCallControlManager.30
8.2.13 IpAppConfCallControlManagerRef .30
8.2.14 TpConfPolicyType.30
8.2.15 TpConfPolicy.31
8.2.16 TpMonoMediaConfPolicy.31
8.2.17 TpJoinEventInfo.31
8.2.18 TpConfSearchCriteria.31
8.2.19 TpConfSearchResult.32
8.2.20 TpMultiMediaConfPolicy.32
8.2.21 TpResourceReservation.32
8.2.22 TpVideoHandlingType.32
Annex A (normative): OMG IDL Description of Conference Call Control SCF.33
Annex B (informative): W3C WSDL Description of Conference Call Control SCF .34
Annex C (informative): Java™ API Description of the Call Control SCFs.35
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .36
Annex E (informative): Record of changes .37
E.1 Interfaces.37
E.1.1 New.37
E.1.2 Deprecated.37
E.1.3 Removed.37
E.2 Methods.37
E.2.1 New.37
E.2.2 Deprecated.37
E.2.3 Modified.38
E.2.4 Removed.38
E.3 Data Definitions.38
E.3.1 New.38
E.3.2 Modified.38
E.3.3 Removed.38
E.4 Service Properties.38
E.4.1 New.38
E.4.2 Deprecated.38
E.4.3 Modified.39
E.4.4 Removed.39
E.5 Exceptions.39
E.5.1 New.39
E.5.2 Modified.39
E.5.3 Removed.39
E.6 Others.39
History .40
ETSI
5 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
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 ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
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 ETSI 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 ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN), and is now submitted for the ETSI standards
Membership Approval Procedure.
The present document is part 4, sub-part 5 of a multi-part deliverable covering Open Service Access (OSA);
Application Programming Interface (API), as identified below. The API specification (ES 204 915) is structured in the
following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF";
Part 13: "Policy Management SCF";
Part 14: "Presence and Availability Management SCF";
Part 15: "Multi-Media Messaging SCF"
Part 16: "Service Broker SCF".
ETSI
6 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP,
in co-operation with a number of JAIN™ Community (http://www.java.sun.com/products/jain) member companies.
The present document forms part of the Parlay 6.0 set of specifications.
The present document is equivalent to 3GPP TS 29.198-4-5 V7.0.0 (Release 7).
ETSI
7 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
1 Scope
The present document is part 4, sub-part 5 of the Stage 3 specification for an Application Programming Interface (API)
for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardised interface, i.e. the OSA APIs.
The present document specifies the Conference Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Conference Call Control SCF are defined here, these being:
• Sequence Diagrams.
• Class Diagrams.
• Interface specification plus detailed method descriptions.
• State Transition diagrams.
• Data Definitions.
• IDL Description of the interfaces.
• WSDL Description of the interfaces.
• Reference to the Java™ API description of the interfaces.
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 204 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 204 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 6)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 204 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 204 915-1 apply.
ETSI
8 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
4 Conference Call Control Service Sequence
Diagrams
4.1 Meet-me conference without subconferencing
This sequence illustrates a pre-arranged meet-me conference for a specified time period. During this timeslot parties can
'call in to' the meet-me conference by dialling a special number.
For each participant joining the conference, the application can decide to accept the participant in to the conference.
The application can also be notified when parties are leaving the conference.
ETSI
9 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
: (Logical : : : : IpConfCall
View::IpAppLogic) IpAppConfCallControlManager IpAppConfCall IpConfCallControlManager
1: new()
2: reserveResources( )
3: conferenceCreated( )
4: "forward event"
5: new()
6: leaveMonitorReq( )
7: partyJoined( )
8: attachMediaReq( )
9: partyJoined( )
10: "forward event"
11: attachMediaReq( )
12: leaveMonitorRes( )
13: "forward event"
14: release( )
1: The application creates a new object to receive the callbacks from the conference call control manager.
2: The application reserves resources for some time in the future.
With this same method the application registers interest in the creation of the conference (e.g. when the first
party to joins the conference or at the specified start time, this is implementation dependant).
The reservation also includes the conference policy. One of the elements is whether joined parties must be
explicitly attached. If so, this is treated as an implicit joinMonitorReq.
3: The conference is created.
4: The message is forwarded to the application.
ETSI
10 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
5: The application creates an object to receive the call back messages from the conference call.
6: The application also requests to be notified when parties leave the conference.
7: The application is notified of the first party that joined the conference.
8: When the party is allowed to join the conference, the party is added.
Alternatively, the party could have been rejected with a releaseCallLeg.
9: A new party joins the conference and the application is notified.
10: The message is forwarded to the application.
11: This party also is allowed into the conference by attaching the leg.
12: A party leaves the conference.
13: The message is forwarded to the application.
14: The application decides to release the entire conference.
4.2 Non-add hoc add-on with subconferencing
This sequence illustrates a prearranged add-on conference. The end user that initiates the call, communicates with the
conference application via a web interface (not shown). By dragging and dropping names from the addressbook, the
end-user adds parties to the conference.
Also via the web-interface, the end-user can group parties in subconferences. Only parties in the same subconference
can talk to each other.
ETSI
11 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
: (Logical : : IpAppCallLeg : : IpConfCall first : : IpCallLeg second :
View::IpAppLogic) IpAppConfCall IpConfCallControlManager IpSubConfCall IpSubConfCall
1: new()
2: createConference( )
3: getSubConferences( )
4: new()
5: createAndRouteCallLegReq( )
6: new()
7: createAndRouteCallLegReq( )
8: createAndRouteCallLegReq( )
9: createAndRouteCallLegReq( )
10: eventReportRes( )
11: "forward event"
12: splitSubConference( )
13: moveCallLeg( )
14: release( )
1: The application creates a new interface to receive the callbacks from the conference call.
2: The application initiates the conference. There has been no prior resource reservation, so there is a chance that
no resources are available when parties are added to the conference.
The conferenceCall interface object is returned.
3: Together with the conference a subconference is implicitly created.
However, the subconference is not returned as a result of the createConference, therefore the application uses
this method to get the subconference.
4: The application creates a new IpAppCallLeg interface.
5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in
the following not all steps are shown.
6: The gateway creates a new IpCallLeg interface.
7: The application adds parties to the subconference.
8: The application adds parties to the subconference.
9: The application adds parties to the subconference.
10: When a party A answers the application is notified.
We assume that all parties answer. This happens in the same way as for party A and is not shown in the
following.
11: The message is forwarded to the application.
ETSI
12 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
12: The application decides to split the conference. Party C and D are indicated in the message.
The gateway will create a new subconference and move party C and D to the new subconference.
The configuration is A and B are in speech, C & D are in speech. There is no bearer connection between the
two subconferences.
13: The application moves one of the legs from the second subconference back to the first. The configuration now
is A, B and C are in speech configuration. D is alone in its own subconference.
14: The second subconference is released. Since party D was in this subconference, this callleg is also released.
This leaves one subconference with A, B and C.
4.3 Non-addhoc add-on multimedia
This sequence illustrates a prearranged add-on multi-media conference. The end user that initiates the call,
communicates with the conference application via a web interface (not shown). By dragging and dropping names from
the addressbook, the end-user adds parties to the conference.
Also via the web-interface, the end-user can do things that normally the chair would be able to do, e.g. determine who
has the floor (e.g. whose video is being broadcast to the other participants) or inspect the video of participants who do
not have the floor (e.g. to see how they react to the current speaker).
: (Logical : IpAppSubConfCall PartyA : PartyB : : : IpConfCall : IpSubConfCall PartyA : Pa rtyB :
View::IpAppLogic) IpAppCallLeg IpAppCallLeg IpConfCallControlM anager IpAppCallLeg IpAppCallLeg
1: new()
2: createCon ference( )
3: getSubConferences( )
4: new()
5: createAndRouteCallLegReq( )
6: new()
7: new()
8: createAndRouteCallLegReq( )
9: new()
10: createAndRouteCallLegReq( )
11: createAndRouteCallLegReq( )
12: eventReportRes( )
13: "forward event"
14: chairSelection( )
15: eventReportRes( )
16: appointSpeaker( )
17 : inspectVid eo( )
18 : inspectVid eo( )
19: inspectVideoCancel( )
20: floorRequest( )
21: "forward event"
22: appointSpeaker( )
1: The application creates a new object for receiving callbacks from the MMSubConference.
ETSI
13 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
2: When the user selects the appropriate option in the web interface, the application will create a conference
without resource reservation. The policy for video is set to 'chairperson switched.
3: The application requests the subconference that was implicitly created together with the conference.
4: The application creates a new IpAppCallLeg interface.
5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in
the following not all steps are shown.
6: The gateway creates a new IpCallLeg interface.
7: The application creates a new IpAppCallLeg interface.
8: The application adds parties to the conference and monitors on success.
9: The gateway creates a new IpCallLeg interface.
10: The application adds parties to the conference and monitors on success.
11: The application adds parties to the conference and monitors on success.
12: When a party A answers the application is notified.
We assume that all parties answer.
14: We assume that A was the initiating party.
The initiating end-user is assigned the chairpersonship.
This message is needed to synchronise the chairpersonship in the application with the MCU chairpersonship,
since the chair can also use H.323 messages to control the conference.
15: When a party B answers the application is notified. We assume the other parties answer as well and this is not
shown below in the sequence.
16: Chairperson (A) decides via WWW interface that party B is the speaker. This means that the video of B is
broadcast to the rest.
17: The chairperson selects the video of C in order to judge their reactions on B's proposal.
18: The chairperson selects the video of D in order to judge their reactions on B's proposal.
19: The chairperson goes back to receiving the broadcasted videostream (B).
20: User C requests the floor via the H.323 signals. The application is notified of this.
21: The message is forwarded to the application logic.
22: The chairperson (via the WWW interface) grants the request by appointing C as the speaker.
ETSI
14 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
4.4 Resource Reservation
This sequence illustrates how an application can check and reserve resources for a meet-me conference.
: (Logical : : : IpConfCall
View::IpAppLogic) IpAppConfCallControlManager IpConfCallControlManager
1: checkResources( )
2: new()
3: reserveResources( )
4: freeResources( )
5: reserveResources( )
6: conferenceCreated( )
7: "forward event"
1: The application checks if enough conference resources are available in a given time period.
2: The application creates an object to receive callback messages.
3: The application reserves resources for the time period. The callback object is in order to receive a notification
when the conference is started.
4: Because the time was wrong by accident, the application cancels the earlier reservation.
5: The application makes a new reservation.
6: At the specified time, or when the first party joins the conference the application is notified.
7: The event is forwarded to the application.
5 Class Diagrams
The conference call control service consists of two packages, one for the interfaces on the application side and one for
interfaces on the service side. The class diagrams in the following figures show the interfaces that make up the
conference call control application package and the conference call control service package.
This class diagram shows the interfaces that make up the application conference call control service package and the
relation to the interfaces in the conference call control service package.
ETSI
15 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
The diagram also shows the inheritance relation between the multi-party call application interfaces and the conference
call application interfaces; the conference interfaces are specialisations of the corresponding multi-party call interfaces.
Communication between the application and service packages is done via the <> relations; the interfaces can
communicate with callback methods in the corresponding application interfaces.
<>
IpAppMultiMediaCall <>
<< Interfac e> >
IpAppMultiMediaCallLeg
(from mmccs)
IpA ppM ul tiMe dia Call Co nt rolMan ag er
(from mmccs)
(from mmc cs)
superviseVolumeRes()
superviseVolumeErr() mediaStreamMonitorRes()
reportMediaNotification()
0.n
0.n
<> <>
<< Interfac e> >
IpAppConfCall IpAppSubConfCall
IpAppConfCallControlManager
10.n 1 0.n
(from cccs) (from cccs)
(from cccs)
partyJoined() chai rSele ction()
conferenceCreated()
leaveMonitorRes() floorRequest()
<>
<>
<>
<>
IpSubConfCall
<>
<< Interfac e> > <> (from cccs)
IpConfCallControlManager IpConfCall
(from cccs) (from cccs)
splitS ubCon ference()
10.n 10.n
merg eS ubCon ference()
createConference() getSubConferences() moveCal lLeg()
checkResources() createSubConference() inspe ctVi deo()
reserveResources() leaveMonitorReq() inspectVideoCancel()
freeResources() getConferenceAddress() ap po intSpeaker()
chairSelection()
chan ge Conferen ce Po li cy()
0.n <>
IpMu ltiMediaCallLeg
(from mmccs)
0.n
mediaStreamAllow()
mediaStreamMonitorReq()
getMediaStreams()
Figure 1: Application Interfaces
This class diagram shows the interfaces that make up the conference call control service package.
The diagram also shows the inheritance relation between the multi-party call interfaces and the conference call
interfaces; the conference interfaces are specialisations of the corresponding multi-party call interfaces.
Furthermore, the class diagram illustrates that the conference call control manager can instantiate or be associated with
zero or more conference calls. Each conference call can have one or more subconferences associated with it. Each
subconference contains zero or more call legs associated. Detached legs are not associated with any specific
subconference, instead they are associated with the conference call itself.
ETSI
16 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
<>
<>
IpMultiMediaCallControlManager
IpMultiMediaCall
(f rom mmccs )
(from mmccs)
createMediaNotification()
superviseVolumeReq()
destroyMediaNotification()
changeMediaNotification()
getMediaNotification()
<>
IpS ubCo nfCal l
<> << Inte rface>>
(from cccs)
IpConfCallControlManager IpConfCall
(f rom cccs) (from cccs)
splitSubConference()
10.n 1 0.n
mergeSubConference()
createConference() ge tSubConfe rences() moveCallLeg()
checkResources() c reat eSub Confe ren ce() inspectVideo()
reserveResources() leaveMonitorReq() inspectVideoCancel()
freeResources() ge tConf eren ce Address() appointSpeaker()
chairSelection()
changeConferencePolicy()
0.n
<>
IpMultiMediaCallLeg
0.n (from mmcc s)
mediaStreamAllow()
mediaStreamMonitorReq()
getMediaStreams()
Figure 2: Service Interfaces
6 Conference Call Control Service Interface Classes
The Conference Call Control Service enhances the multi-media call control service. The conference call control service
gives the application the ability to manipulate subconferences within a conference. A subconference defines the
grouping of legs within the overall conference call. Only parties in the same subconference have a bearer connection (or
media channel connection) to each other (e.g. can speak to each other). The application can:
• create new subconferences within the conference, either as an empty subconference or by splitting an existing
subconference in two subconferences;
• move legs between subconferences;
• merge subconferences;
• get a list of all subconferences in the call;
The generic conference also gives the possibility to manipulate typical multi-media conference details, such as:
• interworking with network signalled conference protocols (e.g. H.323);
• manipulation of the media in the MCU, e.g. broadcasting of video;
• handling of multi-media conference policies, e.g. how video should be handled, voice controlled switched or
chair controlled.
Furthermore the conference call control service adds support for the reservation of resources needed for conferencing.
The application can:
• reserve resources for a predefined time period;
• free reserved resources;
• search for the availability of conference resources based on a number of criteria.
ETSI
17 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
There are two ways to initiate a conference:
• the conferences can be started on the pre-arranged time by the service, at the start time indicated in the
reservation. The application is notified about this. The application can then add parties to the conference
and/or parties can dial-in to the conference using the address provided during reservation;
• the conference can be created directly on request of the application using the createConference method in the
IpConfCallControlManager interface.
Each Conference Call Control interface inherits from a Multi Media Call Control interface, which in turn inherits from
Multi Party Call Control. It is possible to implement conference call control without any multi-media features, using
only those inherited methods which come from Multi Party Call Control, in addition to the Conference Call Control
methods. The minimum required method set for each Conference Call Control interface reflects this possibility, by not
requiring the Multi Media Call Control methods.
6.1 Interface Class IpConfCallControlManager
Inherits from: IpMultiMediaCallControlManager.
The conference Call Control Manager is the factory interface for creating conferences. Additionally it takes care of
resource management.
This interface shall be implemented by a Conference Call Control SCF. As a minimum requirement, either the
createConference() method shall be implemented, or the reserveResources() and freeResources() methods shall be
implemented. The minimum required methods from IpMultiPartyCallControlManager are also required.
<>
IpConfCallControlManager
createConference (appConferenceCall: in IpAppConfCallRef, numberOfSubConferences: in TpInt32,
conferencePolicy: in TpConfPolicy, numberOfParticipants: in TpInt32, duration: in TpDuration):
TpConfCallIdentifier
checkResources (searchCriteria: in TpConfSearchCriteria): TpConfSearchResult
reserveResources (appInterface: in IpAppConfCallControlManagerRef, startTime: in TpDateAndTime,
numberOfParticipants: in TpInt32, duration: in TpDuration, conferencePolicy: in TpConfPolicy):
TpResourceReservation
freeResources (resourceReservation: in TpResourceReservation): void
6.1.1 Method createConference()
This method is used to create a new conference. If the specified resources are not available for the indicated duration the
creation is rejected with P_RESOURCES_UNAVAILABLE.
Returns conference: Specifies the interface reference and sessionID of the created conference.
Parameters
appConferenceCall: in IpAppConfCallRef
Specifies the callback interface for the conference created.
ETSI
18 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
numberOfSubConferences: in TpInt32
Specifies the number of subconferences that the user wants to create automatically. The references to the interfaces of
the subconferences can later be requested with getSubConferences.
The number of subconferences should be at least 1.
conferencePolicy: in TpConfPolicy
Specifies the policy to be applied for the conference, e.g. are parties allowed to join (call into) the conference?
Note that if parties are allowed to join the conference, the application can expect partyJoined() messages on the
IpAppConfCall interface.
numberOfParticipants: in TpInt32
Specifies the number of participants in the conference. The actual number of participants may exceed this, but these
resources are not guaranteed, i.e. anything exceeding this will be best effort only and the conference service may drop
or reject participants in order to fulfil other committed resource requests. By specifying 0, the application can request a
best effort conference.
duration: in TpDuration
Specifies the duration for which the conference resources are reserved. The duration of the conference may exceed this,
but after the duration, the resources are no longer guaranteed, i.e. parties may be dropped or rejected by the service in
order to satisfy other committed resource requests. When the conference is released before the allocated duration, the
reserved resources are released and can be used to satisfy other resource requests. By specifying 0, the application
requests a best effort conference.
Returns
TpConfCallIdentifier
Raises
TpCommonExceptions
6.1.2 Method checkResources()
This method is used to check for the availability of conference resources.
The input is the search period (start and stop time and date) - mandatory.
Furthermore, a conference duration and number of participants can be specified - optional.
The search algorithm will search the specified period for availability of conference resources and tries to find an
optimal solution.
When a match is found the actual number of available resources, the actual start and the actual duration for which these
are available is returned. These values can exceed the requested values.
When no match is found a best effort is returned, still the actual start time, duration, number of resources are returned,
but these values now indicate the best that the conference bridge can offer, e.g. one or more of these values will not
reach the requested values.
Returns result: Specifies the result of the search. It indicates if a match was found. If no exact match was found the best
attempt is returned.
Parameters
searchCriteria: in TpConfSearchCriteria
Specifies the boundary conditions of the search. E.g. the time period that should be searched, the number of
participants.
ETSI
19 Final draft ETSI ES 204 915-4-5 V1.1.1 (2008-02)
Returns
TpConfSearchResult
Raises
TpCommonExceptions
6.1.3 Method reserveResources()
This method is used to reserve conference resources for a given time period. Conferences can be created without first
reserving resources, but in that case no guarantees can be made.
Returns resourceReservation: Specifies a structured data type which contains two fields.
ResourceID: The address with which the conference can be addressed, both in the methods of the interface and in the
network, i.e. if joinAllowed is TRUE, parties can use this address to join the conference.
If no match is found the ResourceID contains an empty address.
ReservationID: Specifies the reservation made. It should be unique in a particular resource.
Parameters
appInterface: in IpAppConfCallControlManagerRef
Specifies the callback interface to be used when the conference is created in the network. The application will receive
the conferenceCreated message when a conference is created in the network.
startTime: in TpDateAndTime
Specifies the time at which the conference resources should be reserved, i.e. the start time of the conference.
numberOfParticipants: in TpInt32
Specifies the number of participants in the conference. The actual number of participants may exceed this, but these
resources are not guaranteed, i.e. anything exceeding this will be best effort only and the conference service may drop
or reject participants in order to fulfil other committed resource requests.
duration: in TpDuration
S
...
ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 5: Conference Call Control SCF
(Parlay 6)
�
2 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
Reference
DES/TISPAN-01032-4-05-OSA
Keywords
API, IDL, OSA, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - 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
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Conference Call Control Service Sequence Diagrams.8
4.1 Meet-me conference without subconferencing.8
4.2 Non-add hoc add-on with subconferencing.10
4.3 Non-addhoc add-on multimedia.12
4.4 Resource Reservation.14
5 Class Diagrams.14
6 Conference Call Control Service Interface Classes.16
6.1 Interface Class IpConfCallControlManager.17
6.1.1 Method createConference().17
6.1.2 Method checkResources().18
6.1.3 Method reserveResources().19
6.1.4 Method freeResources().20
6.2 Interface Class IpAppConfCallControlManager .20
6.2.1 Method conferenceCreated().20
6.3 Interface Class IpConfCall .21
6.3.1 Method getSubConferences().22
6.3.2 Method createSubConference().22
6.3.3 Method leaveMonitorReq().22
6.3.4 Method getConferenceAddress().23
6.4 Interface Class IpAppConfCall .23
6.4.1 Method partyJoined().23
6.4.2 Method leaveMonitorRes().24
6.5 Interface Class IpSubConfCall .24
6.5.1 Method splitSubConference().25
6.5.2 Method mergeSubConference().26
6.5.3 Method moveCallLeg().26
6.5.4 Method inspectVideo().26
6.5.5 Method inspectVideoCancel().27
6.5.6 Method appointSpeaker().27
6.5.7 Method chairSelection().27
6.5.8 Method changeConferencePolicy().27
6.6 Interface Class IpAppSubConfCall .28
6.6.1 Method chairSelection().28
6.6.2 Method floorRequest().28
7 Conference Call Control Service State Transition Diagrams.29
8 Conference Call Control Data Definitions .29
8.1 Event Notification Data Definitions.29
8.2 Conference Call Control Data Definitions .29
8.2.1 IpConfCall.29
8.2.2 IpConfCallRef.29
8.2.3 IpAppConfCall .29
8.2.4 IpAppConfCallRef.29
8.2.5 IpSubConfCall.30
8.2.6 IpSubConfCallRef.30
ETSI
4 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
8.2.7 IpAppSubConfCall.30
8.2.8 IpAppSubConfCallRef.30
8.2.9 TpSubConfCallIdentifierSet.30
8.2.10 TpConfCallIdentifier.30
8.2.11 TpSubConfCallIdentifier.30
8.2.12 IpAppConfCallControlManager.30
8.2.13 IpAppConfCallControlManagerRef .30
8.2.14 TpConfPolicyType.30
8.2.15 TpConfPolicy.31
8.2.16 TpMonoMediaConfPolicy.31
8.2.17 TpJoinEventInfo.31
8.2.18 TpConfSearchCriteria.31
8.2.19 TpConfSearchResult.32
8.2.20 TpMultiMediaConfPolicy.32
8.2.21 TpResourceReservation.32
8.2.22 TpVideoHandlingType.32
Annex A (normative): OMG IDL Description of Conference Call Control SCF.33
Annex B (informative): W3C WSDL Description of Conference Call Control SCF .34
Annex C (informative): Java™ API Description of the Call Control SCFs.35
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .36
Annex E (informative): Record of changes .37
E.1 Interfaces.37
E.1.1 New.37
E.1.2 Deprecated.37
E.1.3 Removed.37
E.2 Methods.37
E.2.1 New.37
E.2.2 Deprecated.37
E.2.3 Modified.38
E.2.4 Removed.38
E.3 Data Definitions.38
E.3.1 New.38
E.3.2 Modified.38
E.3.3 Removed.38
E.4 Service Properties.38
E.4.1 New.38
E.4.2 Deprecated.38
E.4.3 Modified.39
E.4.4 Removed.39
E.5 Exceptions.39
E.5.1 New.39
E.5.2 Modified.39
E.5.3 Removed.39
E.6 Others.39
History .40
ETSI
5 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
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 ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
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 ETSI 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 ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
The present document is part 4, sub-part 5 of a multi-part deliverable covering Open Service Access (OSA);
Application Programming Interface (API), as identified below. The API specification (ES 204 915) is structured in the
following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF";
Part 13: "Policy Management SCF";
Part 14: "Presence and Availability Management SCF";
Part 15: "Multi-Media Messaging SCF"
Part 16: "Service Broker SCF".
ETSI
6 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP,
in co-operation with a number of JAIN™ Community (http://www.java.sun.com/products/jain) member companies.
The present document forms part of the Parlay 6.0 set of specifications.
The present document is equivalent to 3GPP TS 29.198-4-5 V7.0.0 (Release 7).
ETSI
7 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 5 of the Stage 3 specification for an Application Programming Interface (API)
for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardised interface, i.e. the OSA APIs.
The present document specifies the Conference Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Conference Call Control SCF are defined here, these being:
• Sequence Diagrams.
• Class Diagrams.
• Interface specification plus detailed method descriptions.
• State Transition diagrams.
• Data Definitions.
• IDL Description of the interfaces.
• WSDL Description of the interfaces.
• Reference to the Java™ API description of the interfaces.
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 204 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 204 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 6)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 204 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 204 915-1 apply.
ETSI
8 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
4 Conference Call Control Service Sequence
Diagrams
4.1 Meet-me conference without subconferencing
This sequence illustrates a pre-arranged meet-me conference for a specified time period. During this timeslot parties can
'call in to' the meet-me conference by dialling a special number.
For each participant joining the conference, the application can decide to accept the participant in to the conference.
The application can also be notified when parties are leaving the conference.
ETSI
9 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
: (Logical : : : : IpConfCall
View::IpAppLogic) IpAppConfCallControlManager IpAppConfCall IpConfCallControlManager
1: new()
2: reserveResources( )
3: conferenceCreated( )
4: "forward event"
5: new()
6: leaveMonitorReq( )
7: partyJoined( )
8: attachMediaReq( )
9: partyJoined( )
10: "forward event"
11: attachMediaReq( )
12: leaveMonitorRes( )
13: "forward event"
14: release( )
1: The application creates a new object to receive the callbacks from the conference call control manager.
2: The application reserves resources for some time in the future.
With this same method the application registers interest in the creation of the conference (e.g. when the first
party to joins the conference or at the specified start time, this is implementation dependant).
The reservation also includes the conference policy. One of the elements is whether joined parties must be
explicitly attached. If so, this is treated as an implicit joinMonitorReq.
3: The conference is created.
4: The message is forwarded to the application.
ETSI
10 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
5: The application creates an object to receive the call back messages from the conference call.
6: The application also requests to be notified when parties leave the conference.
7: The application is notified of the first party that joined the conference.
8: When the party is allowed to join the conference, the party is added.
Alternatively, the party could have been rejected with a releaseCallLeg.
9: A new party joins the conference and the application is notified.
10: The message is forwarded to the application.
11: This party also is allowed into the conference by attaching the leg.
12: A party leaves the conference.
13: The message is forwarded to the application.
14: The application decides to release the entire conference.
4.2 Non-add hoc add-on with subconferencing
This sequence illustrates a prearranged add-on conference. The end user that initiates the call, communicates with the
conference application via a web interface (not shown). By dragging and dropping names from the addressbook, the
end-user adds parties to the conference.
Also via the web-interface, the end-user can group parties in subconferences. Only parties in the same subconference
can talk to each other.
ETSI
11 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
: (Logical : : IpAppCallLeg : : IpConfCall first : : IpCallLeg second :
View::IpAppLogic) IpAppConfCall IpConfCallControlManager IpSubConfCall IpSubConfCall
1: new()
2: createConference( )
3: getSubConferences( )
4: new()
5: createAndRouteCallLegReq( )
6: new()
7: createAndRouteCallLegReq( )
8: createAndRouteCallLegReq( )
9: createAndRouteCallLegReq( )
10: eventReportRes( )
11: "forward event"
12: splitSubConference( )
13: moveCallLeg( )
14: release( )
1: The application creates a new interface to receive the callbacks from the conference call.
2: The application initiates the conference. There has been no prior resource reservation, so there is a chance that
no resources are available when parties are added to the conference.
The conferenceCall interface object is returned.
3: Together with the conference a subconference is implicitly created.
However, the subconference is not returned as a result of the createConference, therefore the application uses
this method to get the subconference.
4: The application creates a new IpAppCallLeg interface.
5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in
the following not all steps are shown.
6: The gateway creates a new IpCallLeg interface.
7: The application adds parties to the subconference.
8: The application adds parties to the subconference.
9: The application adds parties to the subconference.
10: When a party A answers the application is notified.
We assume that all parties answer. This happens in the same way as for party A and is not shown in the
following.
11: The message is forwarded to the application.
ETSI
12 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
12: The application decides to split the conference. Party C and D are indicated in the message.
The gateway will create a new subconference and move party C and D to the new subconference.
The configuration is A and B are in speech, C & D are in speech. There is no bearer connection between the
two subconferences.
13: The application moves one of the legs from the second subconference back to the first. The configuration now
is A, B and C are in speech configuration. D is alone in its own subconference.
14: The second subconference is released. Since party D was in this subconference, this callleg is also released.
This leaves one subconference with A, B and C.
4.3 Non-addhoc add-on multimedia
This sequence illustrates a prearranged add-on multi-media conference. The end user that initiates the call,
communicates with the conference application via a web interface (not shown). By dragging and dropping names from
the addressbook, the end-user adds parties to the conference.
Also via the web-interface, the end-user can do things that normally the chair would be able to do, e.g. determine who
has the floor (e.g. whose video is being broadcast to the other participants) or inspect the video of participants who do
not have the floor (e.g. to see how they react to the current speaker).
: (Logical : IpAppSubConfCall PartyA : PartyB : : : IpConfCall : IpSubConfCall PartyA : Pa rtyB :
View::IpAppLogic) IpAppCallLeg IpAppCallLeg IpConfCallControlM anager IpAppCallLeg IpAppCallLeg
1: new()
2: createCon ference( )
3: getSubConferences( )
4: new()
5: createAndRouteCallLegReq( )
6: new()
7: new()
8: createAndRouteCallLegReq( )
9: new()
10: createAndRouteCallLegReq( )
11: createAndRouteCallLegReq( )
12: eventReportRes( )
13: "forward event"
14: chairSelection( )
15: eventReportRes( )
16: appointSpeaker( )
17 : inspectVid eo( )
18 : inspectVid eo( )
19: inspectVideoCancel( )
20: floorRequest( )
21: "forward event"
22: appointSpeaker( )
1: The application creates a new object for receiving callbacks from the MMSubConference.
ETSI
13 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
2: When the user selects the appropriate option in the web interface, the application will create a conference
without resource reservation. The policy for video is set to 'chairperson switched.
3: The application requests the subconference that was implicitly created together with the conference.
4: The application creates a new IpAppCallLeg interface.
5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in
the following not all steps are shown.
6: The gateway creates a new IpCallLeg interface.
7: The application creates a new IpAppCallLeg interface.
8: The application adds parties to the conference and monitors on success.
9: The gateway creates a new IpCallLeg interface.
10: The application adds parties to the conference and monitors on success.
11: The application adds parties to the conference and monitors on success.
12: When a party A answers the application is notified.
We assume that all parties answer.
14: We assume that A was the initiating party.
The initiating end-user is assigned the chairpersonship.
This message is needed to synchronise the chairpersonship in the application with the MCU chairpersonship,
since the chair can also use H.323 messages to control the conference.
15: When a party B answers the application is notified. We assume the other parties answer as well and this is not
shown below in the sequence.
16: Chairperson (A) decides via WWW interface that party B is the speaker. This means that the video of B is
broadcast to the rest.
17: The chairperson selects the video of C in order to judge their reactions on B's proposal.
18: The chairperson selects the video of D in order to judge their reactions on B's proposal.
19: The chairperson goes back to receiving the broadcasted videostream (B).
20: User C requests the floor via the H.323 signals. The application is notified of this.
21: The message is forwarded to the application logic.
22: The chairperson (via the WWW interface) grants the request by appointing C as the speaker.
ETSI
14 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
4.4 Resource Reservation
This sequence illustrates how an application can check and reserve resources for a meet-me conference.
: (Logical : : : IpConfCall
View::IpAppLogic) IpAppConfCallControlManager IpConfCallControlManager
1: checkResources( )
2: new()
3: reserveResources( )
4: freeResources( )
5: reserveResources( )
6: conferenceCreated( )
7: "forward event"
1: The application checks if enough conference resources are available in a given time period.
2: The application creates an object to receive callback messages.
3: The application reserves resources for the time period. The callback object is in order to receive a notification
when the conference is started.
4: Because the time was wrong by accident, the application cancels the earlier reservation.
5: The application makes a new reservation.
6: At the specified time, or when the first party joins the conference the application is notified.
7: The event is forwarded to the application.
5 Class Diagrams
The conference call control service consists of two packages, one for the interfaces on the application side and one for
interfaces on the service side. The class diagrams in the following figures show the interfaces that make up the
conference call control application package and the conference call control service package.
This class diagram shows the interfaces that make up the application conference call control service package and the
relation to the interfaces in the conference call control service package.
ETSI
15 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
The diagram also shows the inheritance relation between the multi-party call application interfaces and the conference
call application interfaces; the conference interfaces are specialisations of the corresponding multi-party call interfaces.
Communication between the application and service packages is done via the <> relations; the interfaces can
communicate with callback methods in the corresponding application interfaces.
<>
IpAppMultiMediaCall <>
<< Interfac e> >
IpAppMultiMediaCallLeg
(from mmccs)
IpA ppM ul tiMe dia Call Co nt rolMan ag er
(from mmccs)
(from mmc cs)
superviseVolumeRes()
superviseVolumeErr() mediaStreamMonitorRes()
reportMediaNotification()
0.n
0.n
<> <>
<< Interfac e> >
IpAppConfCall IpAppSubConfCall
IpAppConfCallControlManager
10.n 1 0.n
(from cccs) (from cccs)
(from cccs)
partyJoined() chai rSele ction()
conferenceCreated()
leaveMonitorRes() floorRequest()
<>
<>
<>
<>
IpSubConfCall
<>
<< Interfac e> > <> (from cccs)
IpConfCallControlManager IpConfCall
(from cccs) (from cccs)
splitS ubCon ference()
10.n 10.n
merg eS ubCon ference()
createConference() getSubConferences() moveCal lLeg()
checkResources() createSubConference() inspe ctVi deo()
reserveResources() leaveMonitorReq() inspectVideoCancel()
freeResources() getConferenceAddress() ap po intSpeaker()
chairSelection()
chan ge Conferen ce Po li cy()
0.n <>
IpMu ltiMediaCallLeg
(from mmccs)
0.n
mediaStreamAllow()
mediaStreamMonitorReq()
getMediaStreams()
Figure 1: Application Interfaces
This class diagram shows the interfaces that make up the conference call control service package.
The diagram also shows the inheritance relation between the multi-party call interfaces and the conference call
interfaces; the conference interfaces are specialisations of the corresponding multi-party call interfaces.
Furthermore, the class diagram illustrates that the conference call control manager can instantiate or be associated with
zero or more conference calls. Each conference call can have one or more subconferences associated with it. Each
subconference contains zero or more call legs associated. Detached legs are not associated with any specific
subconference, instead they are associated with the conference call itself.
ETSI
16 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
<>
<>
IpMultiMediaCallControlManager
IpMultiMediaCall
(f rom mmccs )
(from mmccs)
createMediaNotification()
superviseVolumeReq()
destroyMediaNotification()
changeMediaNotification()
getMediaNotification()
<>
IpS ubCo nfCal l
<> << Inte rface>>
(from cccs)
IpConfCallControlManager IpConfCall
(f rom cccs) (from cccs)
splitSubConference()
10.n 1 0.n
mergeSubConference()
createConference() ge tSubConfe rences() moveCallLeg()
checkResources() c reat eSub Confe ren ce() inspectVideo()
reserveResources() leaveMonitorReq() inspectVideoCancel()
freeResources() ge tConf eren ce Address() appointSpeaker()
chairSelection()
changeConferencePolicy()
0.n
<>
IpMultiMediaCallLeg
0.n (from mmcc s)
mediaStreamAllow()
mediaStreamMonitorReq()
getMediaStreams()
Figure 2: Service Interfaces
6 Conference Call Control Service Interface Classes
The Conference Call Control Service enhances the multi-media call control service. The conference call control service
gives the application the ability to manipulate subconferences within a conference. A subconference defines the
grouping of legs within the overall conference call. Only parties in the same subconference have a bearer connection (or
media channel connection) to each other (e.g. can speak to each other). The application can:
• create new subconferences within the conference, either as an empty subconference or by splitting an existing
subconference in two subconferences;
• move legs between subconferences;
• merge subconferences;
• get a list of all subconferences in the call;
The generic conference also gives the possibility to manipulate typical multi-media conference details, such as:
• interworking with network signalled conference protocols (e.g. H.323);
• manipulation of the media in the MCU, e.g. broadcasting of video;
• handling of multi-media conference policies, e.g. how video should be handled, voice controlled switched or
chair controlled.
Furthermore the conference call control service adds support for the reservation of resources needed for conferencing.
The application can:
• reserve resources for a predefined time period;
• free reserved resources;
• search for the availability of conference resources based on a number of criteria.
ETSI
17 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
There are two ways to initiate a conference:
• the conferences can be started on the pre-arranged time by the service, at the start time indicated in the
reservation. The application is notified about this. The application can then add parties to the conference
and/or parties can dial-in to the conference using the address provided during reservation;
• the conference can be created directly on request of the application using the createConference method in the
IpConfCallControlManager interface.
Each Conference Call Control interface inherits from a Multi Media Call Control interface, which in turn inherits from
Multi Party Call Control. It is possible to implement conference call control without any multi-media features, using
only those inherited methods which come from Multi Party Call Control, in addition to the Conference Call Control
methods. The minimum required method set for each Conference Call Control interface reflects this possibility, by not
requiring the Multi Media Call Control methods.
6.1 Interface Class IpConfCallControlManager
Inherits from: IpMultiMediaCallControlManager.
The conference Call Control Manager is the factory interface for creating conferences. Additionally it takes care of
resource management.
This interface shall be implemented by a Conference Call Control SCF. As a minimum requirement, either the
createConference() method shall be implemented, or the reserveResources() and freeResources() methods shall be
implemented. The minimum required methods from IpMultiPartyCallControlManager are also required.
<>
IpConfCallControlManager
createConference (appConferenceCall: in IpAppConfCallRef, numberOfSubConferences: in TpInt32,
conferencePolicy: in TpConfPolicy, numberOfParticipants: in TpInt32, duration: in TpDuration):
TpConfCallIdentifier
checkResources (searchCriteria: in TpConfSearchCriteria): TpConfSearchResult
reserveResources (appInterface: in IpAppConfCallControlManagerRef, startTime: in TpDateAndTime,
numberOfParticipants: in TpInt32, duration: in TpDuration, conferencePolicy: in TpConfPolicy):
TpResourceReservation
freeResources (resourceReservation: in TpResourceReservation): void
6.1.1 Method createConference()
This method is used to create a new conference. If the specified resources are not available for the indicated duration the
creation is rejected with P_RESOURCES_UNAVAILABLE.
Returns conference: Specifies the interface reference and sessionID of the created conference.
Parameters
appConferenceCall: in IpAppConfCallRef
Specifies the callback interface for the conference created.
ETSI
18 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
numberOfSubConferences: in TpInt32
Specifies the number of subconferences that the user wants to create automatically. The references to the interfaces of
the subconferences can later be requested with getSubConferences.
The number of subconferences should be at least 1.
conferencePolicy: in TpConfPolicy
Specifies the policy to be applied for the conference, e.g. are parties allowed to join (call into) the conference?
Note that if parties are allowed to join the conference, the application can expect partyJoined() messages on the
IpAppConfCall interface.
numberOfParticipants: in TpInt32
Specifies the number of participants in the conference. The actual number of participants may exceed this, but these
resources are not guaranteed, i.e. anything exceeding this will be best effort only and the conference service may drop
or reject participants in order to fulfil other committed resource requests. By specifying 0, the application can request a
best effort conference.
duration: in TpDuration
Specifies the duration for which the conference resources are reserved. The duration of the conference may exceed this,
but after the duration, the resources are no longer guaranteed, i.e. parties may be dropped or rejected by the service in
order to satisfy other committed resource requests. When the conference is released before the allocated duration, the
reserved resources are released and can be used to satisfy other resource requests. By specifying 0, the application
requests a best effort conference.
Returns
TpConfCallIdentifier
Raises
TpCommonExceptions
6.1.2 Method checkResources()
This method is used to check for the availability of conference resources.
The input is the search period (start and stop time and date) - mandatory.
Furthermore, a conference duration and number of participants can be specified - optional.
The search algorithm will search the specified period for availability of conference resources and tries to find an
optimal solution.
When a match is found the actual number of available resources, the actual start and the actual duration for which these
are available is returned. These values can exceed the requested values.
When no match is found a best effort is returned, still the actual start time, duration, number of resources are returned,
but these values now indicate the best that the conference bridge can offer, e.g. one or more of these values will not
reach the requested values.
Returns result: Specifies the result of the search. It indicates if a match was found. If no exact match was found the best
attempt is returned.
Parameters
searchCriteria: in TpConfSearchCriteria
Specifies the boundary conditions of the search. E.g. the time period that should be searched, the number of
participants.
ETSI
19 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
Returns
TpConfSearchResult
Raises
TpCommonExceptions
6.1.3 Method reserveResources()
This method is used to reserve conference resources for a given time period. Conferences can be created without first
reserving resources, but in that case no guarantees can be made.
Returns resourceReservation: Specifies a structured data type which contains two fields.
ResourceID: The address with which the conference can be addressed, both in the methods of the interface and in the
network, i.e. if joinAllowed is TRUE, parties can use this address to join the conference.
If no match is found the ResourceID contains an empty address.
ReservationID: Specifies the reservation made. It should be unique in a particular resource.
Parameters
appInterface: in IpAppConfCallControlManagerRef
Specifies the callback interface to be used when the conference is created in the network. The application will receive
the conferenceCreated message when a conference is created in the network.
startTime: in TpDateAndTime
Specifies the time at which the conference resources should be reserved, i.e. the start time of the conference.
numberOfParticipants: in TpInt32
Specifies the number of participants in the conference. The actual number of participants may exceed this, but these
resources are not guaranteed, i.e. anything exceeding this will be best effort only and the conference service may drop
or reject participants in order to fulfil other committed resource requests.
duration: in TpDuration
Specifies the duration for which the conference resources are reserved. The duration of the conference may exceed this,
but after the duration, the resources are no longer guaranteed, i.e. parties may be dropped or rejected by the service in
order to satisfy other committed resource requests. When the
...
SLOVENSKI STANDARD
01-september-2008
2GSUWLGRVWRSGRVWRULWYH 26$ $SOLNDFLMVNLSURJUDPVNLYPHVQLN $3, GHO
.UPLOMHQMHNOLFDSRGGHO /DVWQRVWVWRULWYHQH]PRåQRVWL 6&) SULNUPLOMHQMX
NRQIHUHQþQLKNOLFHY 3DUOD\
Open Service Access (OSA) - Application Programming Interface (API) - Part 4: Call
Control - Sub-part 5: Conference Call Control SCF (Parlay 6)
Ta slovenski standard je istoveten z: ES 204 915-4-5 Version 1.1.1
ICS:
35.100.01 Medsebojno povezovanje Open systems
odprtih sistemov na splošno interconnection in general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 5: Conference Call Control SCF
(Parlay 6)
�
2 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
Reference
DES/TISPAN-01032-4-05-OSA
Keywords
API, IDL, OSA, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - 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
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2008.
© The Parlay Group 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Conference Call Control Service Sequence Diagrams.8
4.1 Meet-me conference without subconferencing.8
4.2 Non-add hoc add-on with subconferencing.10
4.3 Non-addhoc add-on multimedia.12
4.4 Resource Reservation.14
5 Class Diagrams.14
6 Conference Call Control Service Interface Classes.16
6.1 Interface Class IpConfCallControlManager.17
6.1.1 Method createConference().17
6.1.2 Method checkResources().18
6.1.3 Method reserveResources().19
6.1.4 Method freeResources().20
6.2 Interface Class IpAppConfCallControlManager .20
6.2.1 Method conferenceCreated().20
6.3 Interface Class IpConfCall .21
6.3.1 Method getSubConferences().22
6.3.2 Method createSubConference().22
6.3.3 Method leaveMonitorReq().22
6.3.4 Method getConferenceAddress().23
6.4 Interface Class IpAppConfCall .23
6.4.1 Method partyJoined().23
6.4.2 Method leaveMonitorRes().24
6.5 Interface Class IpSubConfCall .24
6.5.1 Method splitSubConference().25
6.5.2 Method mergeSubConference().26
6.5.3 Method moveCallLeg().26
6.5.4 Method inspectVideo().26
6.5.5 Method inspectVideoCancel().27
6.5.6 Method appointSpeaker().27
6.5.7 Method chairSelection().27
6.5.8 Method changeConferencePolicy().27
6.6 Interface Class IpAppSubConfCall .28
6.6.1 Method chairSelection().28
6.6.2 Method floorRequest().28
7 Conference Call Control Service State Transition Diagrams.29
8 Conference Call Control Data Definitions .29
8.1 Event Notification Data Definitions.29
8.2 Conference Call Control Data Definitions .29
8.2.1 IpConfCall.29
8.2.2 IpConfCallRef.29
8.2.3 IpAppConfCall .29
8.2.4 IpAppConfCallRef.29
8.2.5 IpSubConfCall.30
8.2.6 IpSubConfCallRef.30
ETSI
4 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
8.2.7 IpAppSubConfCall.30
8.2.8 IpAppSubConfCallRef.30
8.2.9 TpSubConfCallIdentifierSet.30
8.2.10 TpConfCallIdentifier.30
8.2.11 TpSubConfCallIdentifier.30
8.2.12 IpAppConfCallControlManager.30
8.2.13 IpAppConfCallControlManagerRef .30
8.2.14 TpConfPolicyType.30
8.2.15 TpConfPolicy.31
8.2.16 TpMonoMediaConfPolicy.31
8.2.17 TpJoinEventInfo.31
8.2.18 TpConfSearchCriteria.31
8.2.19 TpConfSearchResult.32
8.2.20 TpMultiMediaConfPolicy.32
8.2.21 TpResourceReservation.32
8.2.22 TpVideoHandlingType.32
Annex A (normative): OMG IDL Description of Conference Call Control SCF.33
Annex B (informative): W3C WSDL Description of Conference Call Control SCF .34
Annex C (informative): Java™ API Description of the Call Control SCFs.35
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .36
Annex E (informative): Record of changes .37
E.1 Interfaces.37
E.1.1 New.37
E.1.2 Deprecated.37
E.1.3 Removed.37
E.2 Methods.37
E.2.1 New.37
E.2.2 Deprecated.37
E.2.3 Modified.38
E.2.4 Removed.38
E.3 Data Definitions.38
E.3.1 New.38
E.3.2 Modified.38
E.3.3 Removed.38
E.4 Service Properties.38
E.4.1 New.38
E.4.2 Deprecated.38
E.4.3 Modified.39
E.4.4 Removed.39
E.5 Exceptions.39
E.5.1 New.39
E.5.2 Modified.39
E.5.3 Removed.39
E.6 Others.39
History .40
ETSI
5 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
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 ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
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 ETSI 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 ETSI Standard (ES) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
The present document is part 4, sub-part 5 of a multi-part deliverable covering Open Service Access (OSA);
Application Programming Interface (API), as identified below. The API specification (ES 204 915) is structured in the
following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF";
Part 13: "Policy Management SCF";
Part 14: "Presence and Availability Management SCF";
Part 15: "Multi-Media Messaging SCF"
Part 16: "Service Broker SCF".
ETSI
6 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP,
in co-operation with a number of JAIN™ Community (http://www.java.sun.com/products/jain) member companies.
The present document forms part of the Parlay 6.0 set of specifications.
The present document is equivalent to 3GPP TS 29.198-4-5 V7.0.0 (Release 7).
ETSI
7 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 5 of the Stage 3 specification for an Application Programming Interface (API)
for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardised interface, i.e. the OSA APIs.
The present document specifies the Conference Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Conference Call Control SCF are defined here, these being:
• Sequence Diagrams.
• Class Diagrams.
• Interface specification plus detailed method descriptions.
• State Transition diagrams.
• Data Definitions.
• IDL Description of the interfaces.
• WSDL Description of the interfaces.
• Reference to the Java™ API description of the interfaces.
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 204 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 204 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 6)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 204 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 204 915-1 apply.
ETSI
8 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
4 Conference Call Control Service Sequence
Diagrams
4.1 Meet-me conference without subconferencing
This sequence illustrates a pre-arranged meet-me conference for a specified time period. During this timeslot parties can
'call in to' the meet-me conference by dialling a special number.
For each participant joining the conference, the application can decide to accept the participant in to the conference.
The application can also be notified when parties are leaving the conference.
ETSI
9 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
: (Logical : : : : IpConfCall
View::IpAppLogic) IpAppConfCallControlManager IpAppConfCall IpConfCallControlManager
1: new()
2: reserveResources( )
3: conferenceCreated( )
4: "forward event"
5: new()
6: leaveMonitorReq( )
7: partyJoined( )
8: attachMediaReq( )
9: partyJoined( )
10: "forward event"
11: attachMediaReq( )
12: leaveMonitorRes( )
13: "forward event"
14: release( )
1: The application creates a new object to receive the callbacks from the conference call control manager.
2: The application reserves resources for some time in the future.
With this same method the application registers interest in the creation of the conference (e.g. when the first
party to joins the conference or at the specified start time, this is implementation dependant).
The reservation also includes the conference policy. One of the elements is whether joined parties must be
explicitly attached. If so, this is treated as an implicit joinMonitorReq.
3: The conference is created.
4: The message is forwarded to the application.
ETSI
10 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
5: The application creates an object to receive the call back messages from the conference call.
6: The application also requests to be notified when parties leave the conference.
7: The application is notified of the first party that joined the conference.
8: When the party is allowed to join the conference, the party is added.
Alternatively, the party could have been rejected with a releaseCallLeg.
9: A new party joins the conference and the application is notified.
10: The message is forwarded to the application.
11: This party also is allowed into the conference by attaching the leg.
12: A party leaves the conference.
13: The message is forwarded to the application.
14: The application decides to release the entire conference.
4.2 Non-add hoc add-on with subconferencing
This sequence illustrates a prearranged add-on conference. The end user that initiates the call, communicates with the
conference application via a web interface (not shown). By dragging and dropping names from the addressbook, the
end-user adds parties to the conference.
Also via the web-interface, the end-user can group parties in subconferences. Only parties in the same subconference
can talk to each other.
ETSI
11 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
: (Logical : : IpAppCallLeg : : IpConfCall first : : IpCallLeg second :
View::IpAppLogic) IpAppConfCall IpConfCallControlManager IpSubConfCall IpSubConfCall
1: new()
2: createConference( )
3: getSubConferences( )
4: new()
5: createAndRouteCallLegReq( )
6: new()
7: createAndRouteCallLegReq( )
8: createAndRouteCallLegReq( )
9: createAndRouteCallLegReq( )
10: eventReportRes( )
11: "forward event"
12: splitSubConference( )
13: moveCallLeg( )
14: release( )
1: The application creates a new interface to receive the callbacks from the conference call.
2: The application initiates the conference. There has been no prior resource reservation, so there is a chance that
no resources are available when parties are added to the conference.
The conferenceCall interface object is returned.
3: Together with the conference a subconference is implicitly created.
However, the subconference is not returned as a result of the createConference, therefore the application uses
this method to get the subconference.
4: The application creates a new IpAppCallLeg interface.
5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in
the following not all steps are shown.
6: The gateway creates a new IpCallLeg interface.
7: The application adds parties to the subconference.
8: The application adds parties to the subconference.
9: The application adds parties to the subconference.
10: When a party A answers the application is notified.
We assume that all parties answer. This happens in the same way as for party A and is not shown in the
following.
11: The message is forwarded to the application.
ETSI
12 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
12: The application decides to split the conference. Party C and D are indicated in the message.
The gateway will create a new subconference and move party C and D to the new subconference.
The configuration is A and B are in speech, C & D are in speech. There is no bearer connection between the
two subconferences.
13: The application moves one of the legs from the second subconference back to the first. The configuration now
is A, B and C are in speech configuration. D is alone in its own subconference.
14: The second subconference is released. Since party D was in this subconference, this callleg is also released.
This leaves one subconference with A, B and C.
4.3 Non-addhoc add-on multimedia
This sequence illustrates a prearranged add-on multi-media conference. The end user that initiates the call,
communicates with the conference application via a web interface (not shown). By dragging and dropping names from
the addressbook, the end-user adds parties to the conference.
Also via the web-interface, the end-user can do things that normally the chair would be able to do, e.g. determine who
has the floor (e.g. whose video is being broadcast to the other participants) or inspect the video of participants who do
not have the floor (e.g. to see how they react to the current speaker).
: (Logical : IpAppSubConfCall PartyA : PartyB : : : IpConfCall : IpSubConfCall PartyA : Pa rtyB :
View::IpAppLogic) IpAppCallLeg IpAppCallLeg IpConfCallControlM anager IpAppCallLeg IpAppCallLeg
1: new()
2: createCon ference( )
3: getSubConferences( )
4: new()
5: createAndRouteCallLegReq( )
6: new()
7: new()
8: createAndRouteCallLegReq( )
9: new()
10: createAndRouteCallLegReq( )
11: createAndRouteCallLegReq( )
12: eventReportRes( )
13: "forward event"
14: chairSelection( )
15: eventReportRes( )
16: appointSpeaker( )
17 : inspectVid eo( )
18 : inspectVid eo( )
19: inspectVideoCancel( )
20: floorRequest( )
21: "forward event"
22: appointSpeaker( )
1: The application creates a new object for receiving callbacks from the MMSubConference.
ETSI
13 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
2: When the user selects the appropriate option in the web interface, the application will create a conference
without resource reservation. The policy for video is set to 'chairperson switched.
3: The application requests the subconference that was implicitly created together with the conference.
4: The application creates a new IpAppCallLeg interface.
5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in
the following not all steps are shown.
6: The gateway creates a new IpCallLeg interface.
7: The application creates a new IpAppCallLeg interface.
8: The application adds parties to the conference and monitors on success.
9: The gateway creates a new IpCallLeg interface.
10: The application adds parties to the conference and monitors on success.
11: The application adds parties to the conference and monitors on success.
12: When a party A answers the application is notified.
We assume that all parties answer.
14: We assume that A was the initiating party.
The initiating end-user is assigned the chairpersonship.
This message is needed to synchronise the chairpersonship in the application with the MCU chairpersonship,
since the chair can also use H.323 messages to control the conference.
15: When a party B answers the application is notified. We assume the other parties answer as well and this is not
shown below in the sequence.
16: Chairperson (A) decides via WWW interface that party B is the speaker. This means that the video of B is
broadcast to the rest.
17: The chairperson selects the video of C in order to judge their reactions on B's proposal.
18: The chairperson selects the video of D in order to judge their reactions on B's proposal.
19: The chairperson goes back to receiving the broadcasted videostream (B).
20: User C requests the floor via the H.323 signals. The application is notified of this.
21: The message is forwarded to the application logic.
22: The chairperson (via the WWW interface) grants the request by appointing C as the speaker.
ETSI
14 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
4.4 Resource Reservation
This sequence illustrates how an application can check and reserve resources for a meet-me conference.
: (Logical : : : IpConfCall
View::IpAppLogic) IpAppConfCallControlManager IpConfCallControlManager
1: checkResources( )
2: new()
3: reserveResources( )
4: freeResources( )
5: reserveResources( )
6: conferenceCreated( )
7: "forward event"
1: The application checks if enough conference resources are available in a given time period.
2: The application creates an object to receive callback messages.
3: The application reserves resources for the time period. The callback object is in order to receive a notification
when the conference is started.
4: Because the time was wrong by accident, the application cancels the earlier reservation.
5: The application makes a new reservation.
6: At the specified time, or when the first party joins the conference the application is notified.
7: The event is forwarded to the application.
5 Class Diagrams
The conference call control service consists of two packages, one for the interfaces on the application side and one for
interfaces on the service side. The class diagrams in the following figures show the interfaces that make up the
conference call control application package and the conference call control service package.
This class diagram shows the interfaces that make up the application conference call control service package and the
relation to the interfaces in the conference call control service package.
ETSI
15 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
The diagram also shows the inheritance relation between the multi-party call application interfaces and the conference
call application interfaces; the conference interfaces are specialisations of the corresponding multi-party call interfaces.
Communication between the application and service packages is done via the <> relations; the interfaces can
communicate with callback methods in the corresponding application interfaces.
<>
IpAppMultiMediaCall <>
<< Interfac e> >
IpAppMultiMediaCallLeg
(from mmccs)
IpA ppM ul tiMe dia Call Co nt rolMan ag er
(from mmccs)
(from mmc cs)
superviseVolumeRes()
superviseVolumeErr() mediaStreamMonitorRes()
reportMediaNotification()
0.n
0.n
<> <>
<< Interfac e> >
IpAppConfCall IpAppSubConfCall
IpAppConfCallControlManager
10.n 1 0.n
(from cccs) (from cccs)
(from cccs)
partyJoined() chai rSele ction()
conferenceCreated()
leaveMonitorRes() floorRequest()
<>
<>
<>
<>
IpSubConfCall
<>
<< Interfac e> > <> (from cccs)
IpConfCallControlManager IpConfCall
(from cccs) (from cccs)
splitS ubCon ference()
10.n 10.n
merg eS ubCon ference()
createConference() getSubConferences() moveCal lLeg()
checkResources() createSubConference() inspe ctVi deo()
reserveResources() leaveMonitorReq() inspectVideoCancel()
freeResources() getConferenceAddress() ap po intSpeaker()
chairSelection()
chan ge Conferen ce Po li cy()
0.n <>
IpMu ltiMediaCallLeg
(from mmccs)
0.n
mediaStreamAllow()
mediaStreamMonitorReq()
getMediaStreams()
Figure 1: Application Interfaces
This class diagram shows the interfaces that make up the conference call control service package.
The diagram also shows the inheritance relation between the multi-party call interfaces and the conference call
interfaces; the conference interfaces are specialisations of the corresponding multi-party call interfaces.
Furthermore, the class diagram illustrates that the conference call control manager can instantiate or be associated with
zero or more conference calls. Each conference call can have one or more subconferences associated with it. Each
subconference contains zero or more call legs associated. Detached legs are not associated with any specific
subconference, instead they are associated with the conference call itself.
ETSI
16 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
<>
<>
IpMultiMediaCallControlManager
IpMultiMediaCall
(f rom mmccs )
(from mmccs)
createMediaNotification()
superviseVolumeReq()
destroyMediaNotification()
changeMediaNotification()
getMediaNotification()
<>
IpS ubCo nfCal l
<> << Inte rface>>
(from cccs)
IpConfCallControlManager IpConfCall
(f rom cccs) (from cccs)
splitSubConference()
10.n 1 0.n
mergeSubConference()
createConference() ge tSubConfe rences() moveCallLeg()
checkResources() c reat eSub Confe ren ce() inspectVideo()
reserveResources() leaveMonitorReq() inspectVideoCancel()
freeResources() ge tConf eren ce Address() appointSpeaker()
chairSelection()
changeConferencePolicy()
0.n
<>
IpMultiMediaCallLeg
0.n (from mmcc s)
mediaStreamAllow()
mediaStreamMonitorReq()
getMediaStreams()
Figure 2: Service Interfaces
6 Conference Call Control Service Interface Classes
The Conference Call Control Service enhances the multi-media call control service. The conference call control service
gives the application the ability to manipulate subconferences within a conference. A subconference defines the
grouping of legs within the overall conference call. Only parties in the same subconference have a bearer connection (or
media channel connection) to each other (e.g. can speak to each other). The application can:
• create new subconferences within the conference, either as an empty subconference or by splitting an existing
subconference in two subconferences;
• move legs between subconferences;
• merge subconferences;
• get a list of all subconferences in the call;
The generic conference also gives the possibility to manipulate typical multi-media conference details, such as:
• interworking with network signalled conference protocols (e.g. H.323);
• manipulation of the media in the MCU, e.g. broadcasting of video;
• handling of multi-media conference policies, e.g. how video should be handled, voice controlled switched or
chair controlled.
Furthermore the conference call control service adds support for the reservation of resources needed for conferencing.
The application can:
• reserve resources for a predefined time period;
• free reserved resources;
• search for the availability of conference resources based on a number of criteria.
ETSI
17 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
There are two ways to initiate a conference:
• the conferences can be started on the pre-arranged time by the service, at the start time indicated in the
reservation. The application is notified about this. The application can then add parties to the conference
and/or parties can dial-in to the conference using the address provided during reservation;
• the conference can be created directly on request of the application using the createConference method in the
IpConfCallControlManager interface.
Each Conference Call Control interface inherits from a Multi Media Call Control interface, which in turn inherits from
Multi Party Call Control. It is possible to implement conference call control without any multi-media features, using
only those inherited methods which come from Multi Party Call Control, in addition to the Conference Call Control
methods. The minimum required method set for each Conference Call Control interface reflects this possibility, by not
requiring the Multi Media Call Control methods.
6.1 Interface Class IpConfCallControlManager
Inherits from: IpMultiMediaCallControlManager.
The conference Call Control Manager is the factory interface for creating conferences. Additionally it takes care of
resource management.
This interface shall be implemented by a Conference Call Control SCF. As a minimum requirement, either the
createConference() method shall be implemented, or the reserveResources() and freeResources() methods shall be
implemented. The minimum required methods from IpMultiPartyCallControlManager are also required.
<>
IpConfCallControlManager
createConference (appConferenceCall: in IpAppConfCallRef, numberOfSubConferences: in TpInt32,
conferencePolicy: in TpConfPolicy, numberOfParticipants: in TpInt32, duration: in TpDuration):
TpConfCallIdentifier
checkResources (searchCriteria: in TpConfSearchCriteria): TpConfSearchResult
reserveResources (appInterface: in IpAppConfCallControlManagerRef, startTime: in TpDateAndTime,
numberOfParticipants: in TpInt32, duration: in TpDuration, conferencePolicy: in TpConfPolicy):
TpResourceReservation
freeResources (resourceReservation: in TpResourceReservation): void
6.1.1 Method createConference()
This method is used to create a new conference. If the specified resources are not available for the indicated duration the
creation is rejected with P_RESOURCES_UNAVAILABLE.
Returns conference: Specifies the interface reference and sessionID of the created conference.
Parameters
appConferenceCall: in IpAppConfCallRef
Specifies the callback interface for the conference created.
ETSI
18 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
numberOfSubConferences: in TpInt32
Specifies the number of subconferences that the user wants to create automatically. The references to the interfaces of
the subconferences can later be requested with getSubConferences.
The number of subconferences should be at least 1.
conferencePolicy: in TpConfPolicy
Specifies the policy to be applied for the conference, e.g. are parties allowed to join (call into) the conference?
Note that if parties are allowed to join the conference, the application can expect partyJoined() messages on the
IpAppConfCall interface.
numberOfParticipants: in TpInt32
Specifies the number of participants in the conference. The actual number of participants may exceed this, but these
resources are not guaranteed, i.e. anything exceeding this will be best effort only and the conference service may drop
or reject participants in order to fulfil other committed resource requests. By specifying 0, the application can request a
best effort conference.
duration: in TpDuration
Specifies the duration for which the conference resources are reserved. The duration of the conference may exceed this,
but after the duration, the resources are no longer guaranteed, i.e. parties may be dropped or rejected by the service in
order to satisfy other committed resource requests. When the conference is released before the allocated duration, the
reserved resources are released and can be used to satisfy other resource requests. By specifying 0, the application
requests a best effort conference.
Returns
TpConfCallIdentifier
Raises
TpCommonExceptions
6.1.2 Method checkResources()
This method is used to check for the availability of conference resources.
The input is the search period (start and stop time and date) - mandatory.
Furthermore, a conference duration and number of participants can be specified - optional.
The search algorithm will search the specified period for availability of conference resources and tries to find an
optimal solution.
When a match is found the actual number of available resources, the actual start and the actual duration for which these
are available is returned. These values can exceed the requested values.
When no match is found a best effort is returned, still the actual start time, duration, number of resources are returned,
but these values now indicate the best that the conference bridge can offer, e.g. one or more of these values will not
reach the requested values.
Returns result: Specifies the result of the search. It indicates if a match was found. If no exact match was found the best
attempt is returned.
Parameters
searchCriteria: in TpConfSearchCriteria
Specifies the boundary conditions of the search. E.g. the time period that should be searched, the number of
participants.
ETSI
19 ETSI ES 204 915-4-5 V1.1.1 (2008-05)
Returns
TpConfSearchResult
Raises
TpCommonExceptions
6.1.3 Method reserveResources()
This method is used to reserve conference resources for a given time period. Conferences can be created without first
reserving resources, but in that case no guarantees
...
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...