SIST ES 204 915-4-3 V1.1.1:2008

• Abstract:

  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 3 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 Multi-Party Call Control Service Capability Feature (SCF) aspects of the interface.; All aspects of the Multi-Party 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).

• Status: Published
• Publication Date: 02-Jul-2008
• ICS: 35.100.01 - Open systems interconnection in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 11-Jun-2008
• Due Date: 16-Aug-2008
• Completion Date: 03-Jul-2008
• Ref Project: ETSI ES 204 915-4-3 V1.1.1 (2008-05) - Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control; Sub-part 3: Multi-Party Call Control SCF (Parlay 6)

SIST ES 204 915-4-3 V1.1.1:2008 is an ETSI Standard for Open Service Access (OSA) Application Programming Interface (API), Part 4: Call Control, Sub-part 3: Multi-Party Call Control SCF (Parlay 6). It specifies the Stage 3 interface for the Multi-Party Call Control Service Capability Feature, so application developers and service/network implementers can create calls, manage call legs, control routing, request events, and receive callbacks through the OSA APIs.

What does SIST ES 204 915-4-3 V1.1.1:2008 specify?

SIST ES 204 915-4-3 V1.1.1:2008 specifies the Multi-Party Call Control SCF part of the OSA API. The document defines the interface between applications and the network service side, using UML-based sequence diagrams, class diagrams, state transition diagrams, data definitions, and machine-readable interface descriptions.

This standard is organized as a Stage 3 specification. Clause 4 gives service sequence diagrams, clause 5 gives class diagrams, clause 6 defines the interface classes and methods, clause 7 defines state transition behavior, clause 8 lists service properties, and clause 9 defines the data types used by the API.

Annex	What it covers
Annex A	OMG IDL description of Multi-Party Call Control SCF
Annex B	W3C WSDL description of Multi-Party Call Control SCF
Annex C	Java API description of the Multi-Party Call Control SCF
Annex D	Contents of 3GPP OSA Rel-7 Call Control
Annex E	cdma2000-specific description and exceptions
Annex F	Record of changes

What are the key requirements of SIST ES 204 915-4-3 V1.1.1:2008?

The main requirement is that the Multi-Party Call Control service supports leg management on top of Generic Call Control. In practice, that means one call can have more than one call leg, and the application can explicitly create, route, supervise, release, and deassign those legs.

Service-side manager behavior

Clause 6.1 defines IpMultiPartyCallControlManager as the service manager interface. It is used for call creation, overload control, and notification handling, and some methods are asynchronous so applications do not have to block while a transaction completes.

The minimum implementation requirement is important for interoperability. The service shall implement either createCall(), or the createNotification() and destroyNotification() pair, or the enableNotifications() and disableNotifications() pair. That tells an integrator which control model the service actually supports.

Clause 6.1 also defines notification overlap handling for createNotification(). If criteria overlap in a way that would let more than one application control the same call or session at the same time, the request is refused with P_INVALID_CRITERIA. In practice, this prevents two applications from competing for the same live call unless the network supports that as a special case.

Call control and call-leg control

Clause 6.3 defines IpMultiPartyCall, the call-level interface. It provides routing control, charging control, release, supervision, and explicit call-leg management through methods such as getCallLegs(), createCallLeg(), createAndRouteCallLegReq(), release(), deassignCall(), getInfoReq(), setChargePlan(), setAdviceOfCharge(), and superviseReq().

The minimum implementation requirement here matters for core call handling. The service shall implement release() and deassignCall(), plus either createCallLeg() or createAndRouteCallLegReq(). That tells a buyer or integrator whether the service can create legs separately or only as part of combined create-and-route behavior.

Clause 6.5 defines IpCallLeg, which is the logical object linking a call to an address. It supports routeReq(), eventReportReq(), release(), getInfoReq(), continueProcessing(), deassign(), and related operations such as media attachment, destination lookup, charging, supervision, and properties. In practice, this is the object an application uses when it needs fine control over one leg of a multi-party call.

Callback handling and application responses

Clause 6.2 defines IpAppMultiPartyCallControlManager, and clauses 6.4 and 6.6 define the callback interfaces IpAppMultiPartyCall and IpAppCallLeg. These interfaces carry notifications, results, and errors back to the application, which is why the application side must implement callback handling as well as request handling.

This is especially important for event-driven services. Methods such as reportNotification(), callEnded(), eventReportRes(), getInfoRes(), and superviseRes() are how the service reports results after the application has armed events or requested information.

State handling and interrupt processing

Clause 7 defines how calls and call legs move through their states. The document uses an activity timer for IpMultiPartyCall: when a call is created or received in interrupt mode, the timer starts, and if the application stops responding, the service calls callEnded() with P_TIMER_EXPIRY, or callAborted() if no callback is available.

This matters operationally because interrupt mode suspends call processing until the application acts. Clause 7 also says that when multiple network events occur close together, they are reported one by one in the order received, and the next pending event is not reported until call processing is resumed for the current one.

Clause 7 also makes the reporting order explicit for releasing calls. If the application requested extra call-leg information, the service sends the requested getInfoRes() and superviseRes() results before callLegEnded(). If the application deassigns a leg, the leg is released and destroyed with no further reports.

Service properties and supported environments

Clause 8 describes the service properties that describe capability and policy. These include supported event types, address plans, media type, whether user interaction is possible at call level or leg level, the maximum number of legs per call, whether parallel initial routing requests are allowed, and which call-leg properties are available.

This section matters because it tells an application what the service can actually do before it sends requests. Clause 8.2 also gives the property values for the CAMEL Service Environment, including the supported operation set, triggering and dynamic event types, address plan, user interaction limits, media type, and maximum call-leg counts.

What terms does SIST ES 204 915-4-3 V1.1.1:2008 define?

• Open Service Access (OSA) - An architecture that lets application developers use network functionality through standardized interfaces.
• Service Capability Feature (SCF) - A named OSA service capability; in this document, it is the Multi-Party Call Control service.
• Unified Modelling Language (UML) - The modeling language used here for sequence diagrams, class diagrams, and state transition diagrams.
• OMG Interface Definition Language (IDL) - The interface description format used in Annex A for the machine-readable API definition.
• W3C Web Services Description Language (WSDL) - The web service description format used in Annex B.
• IpMultiPartyCallControlManager - The service-side manager interface that creates calls and manages notifications and load control.
• IpCallLeg - The logical call-leg interface that controls routing, reporting, supervision, and release for one leg.

Who uses SIST ES 204 915-4-3 V1.1.1:2008?

Application developers use this standard to build call-control applications such as call barring, call forwarding on busy, hotline services, and information-collection services. They use the interface definitions to decide when to create a call, when to create a leg, and how to subscribe to events.

Network and service platform implementers use it to expose call-control capabilities through the OSA APIs, to implement callbacks, and to enforce service properties such as load control, monitor mode, and supported address plans. That is the group that turns the standard into a working gateway or service control layer.

Test, integration, and quality teams use the sequence diagrams, state models, and callback rules to validate call setup, redirection, release handling, and event reporting. Charging and statistics teams also use it because the call and call-leg interfaces support information collection and supervision.

What changed in SIST ES 204 915-4-3 V1.1.1:2008 from the previous edition?

SIST ES 204 915-4-3 V1.1.1:2008 is based on ES 203 915 and the new requirements for OSA Phase 4. The foreword also states that it is equivalent to 3GPP TS 29.198-4-3 V7.0.0 (Release 7).

Which standards are used with SIST ES 204 915-4-3 V1.1.1:2008?

Standard	What it contributes
ETSI ES 204 915-1	Overview, common terms, and the reference base for the series
ETSI ES 204 915-2	Common data definitions used by types referenced in this part
ETSI ES 204 915-4-1	Common call control data definitions used by clause 9
ETSI ES 204 915-4-2	Generic Call Control SCF, the related call-control part this document builds on
3GPP TS 29.198-4-3 V7.0.0	The Release 7 equivalent of this specification

What does the SIST ES 204 915-4-3 V1.1.1:2008 document contain?

The document contains worked UML sequence diagrams for application-initiated call setup, call barring, call forwarding on busy, call information collection, complex card service, hotline service, network-controlled notifications, and redirected events. These diagrams show the order of requests, responses, and callbacks used for design and integration.

It also contains class diagrams for the application-side and service-side packages, plus detailed method descriptions for the manager, call, and call-leg interfaces. That material is the main implementation reference for building the API.

Clause 7 adds state transition diagrams for the manager, the call object, and originating and terminating call legs. These diagrams are useful for testing whether the application handles interrupt mode, release behavior, and resume processing correctly.

Clause 8 provides service property tables, including the CAMEL Service Environment values. Clause 9 defines the data types used across the API, while Annex A, Annex B, and Annex C provide IDL, WSDL, and Java representations for implementation and binding work.

Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 3: Multi-Party Call Control SCF
(Parlay 6)
�
2 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)

Reference
DES/TISPAN-01032-4-03-OSA
Keywords
API, IDL, OSA, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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-3 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.7
Foreword.7
1 Scope.9
2 References.9
3 Definitions and abbreviations.9
3.1 Definitions.9
3.2 Abbreviations.9
4 MultiParty Call Control Service Sequence Diagrams .10
4.1 Application initiated call setup.10
4.2 Call Barring 2 .11
4.3 Call forwarding on Busy Service .13
4.4 Call Information Collect Service.14
4.5 Complex Card Service.17
4.6 Hotline Service.20
4.7 Network Controlled Notifications .23
4.8 Use of the Redirected event.24
5 Class Diagrams.24
6 MultiParty Call Control Service Interface Classes.26
6.1 Interface Class IpMultiPartyCallControlManager.26
6.1.1 Method createCall().27
6.1.2 Method createNotification().27
6.1.3 Method destroyNotification().29
6.1.4 Method changeNotification().29
6.1.5 Method setCallLoadControl().29
6.1.6 Method enableNotifications().30
6.1.7 Method disableNotifications().31
6.1.8 Method getNextNotification().31
6.2 Interface Class IpAppMultiPartyCallControlManager.32
6.2.1 Method reportNotification().32
6.2.2 Method callAborted().33
6.2.3 Method managerInterrupted().33
6.2.4 Method managerResumed().34
6.2.5 Method callOverloadEncountered().34
6.2.6 Method callOverloadCeased().34
6.2.7 Method abortMultipleCalls().34
6.3 Interface Class IpMultiPartyCall.34
6.3.1 Method getCallLegs().35
6.3.2 Method createCallLeg().35
6.3.3 Method createAndRouteCallLegReq().36
6.3.4 Method release().37
6.3.5 Method deassignCall().37
6.3.6 Method getInfoReq() .37
6.3.7 Method setChargePlan().38
6.3.8 Method setAdviceOfCharge().38
6.3.9 Method superviseReq().38
6.4 Interface Class IpAppMultiPartyCall .39
6.4.1 Method getInfoRes().39
6.4.2 Method getInfoErr().39
6.4.3 Method superviseRes().40
6.4.4 Method superviseErr().40
6.4.5 Method callEnded().40
6.4.6 Method createAndRouteCallLegErr().40
6.5 Interface Class IpCallLeg.41
ETSI
4 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
6.5.1 Method routeReq().42
6.5.2 Method eventReportReq().42
6.5.3 Method release().43
6.5.4 Method getInfoReq() .43
6.5.5 Method getCall().43
6.5.6 Method attachMediaReq().44
6.5.7 Method detachMediaReq().44
6.5.8 Method getCurrentDestinationAddress().44
6.5.9 Method continueProcessing().45
6.5.10 Method setChargePlan().45
6.5.11 Method setAdviceOfCharge().45
6.5.12 Method superviseReq().46
6.5.13 Method deassign().46
6.5.14 Method getProperties().46
6.5.15 Method setProperties().47
6.6 Interface Class IpAppCallLeg .48
6.6.1 Method eventReportRes().48
6.6.2 Method eventReportErr().49
6.6.3 Method attachMediaRes().49
6.6.4 Method attachMediaErr().49
6.6.5 Method detachMediaRes().49
6.6.6 Method detachMediaErr().49
6.6.7 Method getInfoRes().50
6.6.8 Method getInfoErr().50
6.6.9 Method routeErr().50
6.6.10 Method superviseRes().50
6.6.11 Method superviseErr().51
6.6.12 Method callLegEnded().51
7 MultiParty Call Control Service State Transition Diagrams.51
7.1 State Transition Diagrams for IpMultiPartyCallControlManager .51
7.1.1 Active State.52
7.1.2 Interrupted State.52
7.1.3 Overview of allowed methods .52
7.2 State Transition Diagrams for IpMultiPartyCall .52
7.2.1 IDLE State.53
7.2.2 ACTIVE State.53
7.2.3 RELEASED State.53
7.2.4 Overview of allowed methods .54
7.3 State Transition Diagrams for IpCallLeg .54
7.3.1 Originating Call Leg .55
7.3.1.1 Initiating State.55
7.3.1.2 Analysing State.57
7.3.1.3 Active State.58
7.3.1.4 Releasing State.60
7.3.1.5 Overview of allowed methods, Originating Call Leg STD.62
7.3.2 Terminating Call Leg.63
7.3.2.1 Idle (terminating) State .63
7.3.2.2 Active (terminating) State .64
7.3.2.3 Releasing (terminating) State.67
7.3.2.4 Overview of allowed methods and trigger events, Terminating Call Leg STD .69
8 Multi-Party Call Control Service Properties .69
8.1 List of Service Properties .69
8.2 Service Property values for the CAMEL Service Environment. .71
9 Multi-Party Call Control Data Definitions.72
9.1 Event Notification Data Definitions.72
9.2 Multi-Party Call Control Data Definitions .73
9.2.1 IpCallLeg.73
9.2.2 IpCallLegRef.73
9.2.3 IpAppCallLeg.73
9.2.4 IpAppCallLegRef.73
ETSI
5 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
9.2.5 IpMultiPartyCall.73
9.2.6 IpMultiPartyCallRef.73
9.2.7 IpAppMultiPartyCall.73
9.2.8 IpAppMultiPartyCallRef.73
9.2.9 IpMultiPartyCallControlManager.73
9.2.10 IpMultiPartyCallControlManagerRef.73
9.2.11 IpAppMultiPartyCallControlManager.73
9.2.12 IpAppMultiPartyCallControlManagerRef.73
9.2.13 TpAppCallLegRefSet.73
9.2.14 TpMultiPartyCallIdentifier.74
9.2.15 TpAppMultiPartyCallBack.74
9.2.16 TpAppMultiPartyCallBackRefType.74
9.2.17 TpAppCallLegCallBack.74
9.2.18 TpMultiPartyCallIdentifierSet .74
9.2.19 TpCallAppInfo.75
9.2.20 TpCallAppInfoType.75
9.2.21 TpCallAppInfoSet.75
9.2.22 TpCallEventRequest.75
9.2.23 TpCallEventRequestSet.76
9.2.24 TpCallEventType.76
9.2.25 TpAdditionalCallEventCriteria.78
9.2.26 TpCallEventInfo.78
9.2.27 TpCallAdditionalEventInfo.79
9.2.28 TpCallNotificationRequest.79
9.2.29 TpCallNotificationScope.79
9.2.30 TpCallNotificationInfo.79
9.2.31 TpCallNotificationReportScope.80
9.2.32 TpNotificationRequested.80
9.2.33 TpNotificationRequestedSet.80
9.2.34 TpReleaseCause.80
9.2.35 TpReleaseCauseSet.80
9.2.36 TpCallLegIdentifier.80
9.2.37 TpCallLegIdentifierSet.81
9.2.38 TpCallLegAttachMechanism.81
9.2.39 TpCallLegConnectionProperties.81
9.2.40 TpCallLegInfoReport.81
9.2.41 TpCallLegInfoType.82
9.2.42 TpCallLegSuperviseTreatment.82
9.2.43 TpCallHighProbabilityCompletion.82
9.2.44 TpNotificationRequestedSetEntry.82
9.2.45 TpCarrierSet.82
9.2.46 TpCarrier.82
9.2.47 TpCarrierID.83
9.2.48 TpCarrierSelectionField.83
9.2.49 TpCallLegPropertyName.83
9.2.50 TpCallLegPropertyNameList.83
9.2.51 TpCallLegPropertyValue.83
9.2.52 TpCallLegProperty.83
9.2.53 TpCallLegPropertyList.83
Annex A (normative): OMG IDL Description of Multi-Party Call Control SCF.84
Annex B (informative): W3C WSDL Description of Multi-Party Call Control SCF .85
Annex C (informative): Java API Description of the Call Control SCFs.86
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .87
Annex E (informative): Description of Call Control Sub-part 3: Multi-party call control SCF
for 3GPP2 cdma2000 networks .88
E.1 General Exceptions.88
ETSI
6 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
E.2 Specific Exceptions.88
E.2.1 Clause 1: Scope .88
E.2.2 Clause 2: References .88
E.2.3 Clause 3: Definitions and abbreviations.88
E.2.4 Clause 4: MultiParty Call Control Service Sequence Diagrams .88
E.2.5 Clause 5: Class Diagrams.88
E.2.6 Clause 6: MultiParty Call Control Service Interface Classes .88
E.2.7 Clause 7: MultiParty Call Control Service State Transition Diagrams .89
E.2.8 Clause 8: Multi-Party Call Control Service Properties.89
E.2.9 Clause 9: Multi-Party Call Control Data Definitions .89
E.2.10 Annex A (normative): OMG IDL Description of Multi-Party Call Control SCF.89
E.2.11 Annex B (informative): W3C WSDL Description of Multi-Party Call Control SCF.89
E.2.12 Annex C (informative): Java™ API Description of the Multi-Party Call Control SCF .89
Annex F (informative): Record of changes .90
F.1 Interfaces.90
F.1.1 New.90
F.1.2 Deprecated.90
F.1.3 Removed.90
F.2 Methods.90
F.2.1 New.90
F.2.2 Deprecated.90
F.2.3 Modified.91
F.2.4 Removed.91
F.3 Data Definitions.91
F.3.1 New.91
F.3.2 Modified.91
F.3.3 Removed.91
F.4 Service Properties.91
F.4.1 New.91
F.4.2 Deprecated.91
F.4.3 Modified.92
F.4.4 Removed.92
F.5 Exceptions.92
F.5.1 New.92
F.5.2 Modified.92
F.5.3 Removed.92
F.6 Others.92
History .93

ETSI
7 Final draft ETSI ES 204 915-4-3 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 3 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
8 Final draft ETSI ES 204 915-4-3 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-3 V7.0.0 (Release 7).
ETSI
9 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
1 Scope
The present document is part 4, sub-part 3 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 Multi-Party Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Multi-Party 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
10 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
4 MultiParty Call Control Service Sequence Diagrams
4.1 Application initiated call setup
The following sequence diagram shows an application creating a call between party A and party B. Here, a call is
created first. Then party A's call leg is created before events are requested on it for answer and then routed to the call.
On answer from Party A, an announcement is played indicating that the call is being set up to party B. While the
announcement is being played, party B's call leg is created and then events are requested on it for answer. On answer
from Party B the announcement is cancelled and party B is routed to the call.
The service may as a variation be extended to include 3 parties (or more). After the two party call is established, the
application can create a new leg and request to route it to a new destination address in order to establish a 3 party call.
The event that causes this to happen could for example be the report of answer event from B-party or controlled by the
A-party by entering a service code (mid-call event).
The procedure for call setup to party C is exactly the same as for the set up of the connection to party B (sequence 13 to
17 in the sequence diagram).
: (Logical : AppPartyA : AppPartyB : : : : PartyA : PartyB : : : IpUICall
View::IpAppLogic) IpAppMultiPartyCall (IpAppMultiPartyCallLeg) (IpAppMultiPartyCallLeg) IpAppUICall IpMultiPartyCallControlManager IpMultiPartyCall IpCallLeg IpCallLeg IpUIManager
1: new()
2: createCall( )
3: new()
4: setCallback( )
5: createCallLeg( )
6: new()
7: ev entReportReq( )
8: routeReq(   )
9: eventReportRes ()
10: createUICall( )
11: sendInf oReq(   )
12: sendInfoRes(  )
13: createCallLeg( )
14: new()
15: ev entReportReq( )
16: routeReq(   )
17: ev entReportRes ()
18: abortActionReq( )
19: deassignCall( )
1: This message is used to create an object implementing the IpAppMultiPartyCall interface.
2: This message requests the object implementing the IpMultiPartyCallControlManager interface to create an
object implementing the IpMultiPartyCall interface.
3: Assuming that the criteria for creating an object implementing the IpMultiPartyCall interface (e.g. load control
values not exceeded) is met it is created.
ETSI
11 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
4: Once the object implementing the IpMultiPartyCall interface is created it is used to pass the reference of the
object implementing the IpAppMultiPartyCall interface as the callback reference to the object implementing
the IpMultiPartyCall interface. Note that the reference to the callback interface could already have been passed
in the createCall.
5: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for
customer A.
6: Assuming that the criteria for creating an object implementing the IpCallLeg interface is met, message 6 is
used to create it.
7: This message requests the call leg for customer A to inform the application when the call leg answers the call.
8: The call is then routed to the originating call leg.
9: Assuming the call is answered, the object implementing party A's IpCallLeg interface passes the result of the
call being answered back to its callback object. This message is then forwarded via another message (not
shown) to the object implementing the IpAppLogic interface.
10: A UICall object is created and associated with the just created call leg.
11: This message is used to inform party A that the call is being routed to party B.
12: An indication that the dialogue with party A has commenced is returned via message 13 and eventually
forwarded via another message (not shown) to the object implementing the IpAppLogic interface.
13: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for
customer B.
14: Assuming that the criteria for creating a second object implementing the IpCallLeg interface is met, it is
created.
15: This message requests the call leg for customer B to inform the application when the call leg answers the call.
16: The call is then routed to the call leg.
17: Assuming the call is answered, the object implementing party B's IpCallLeg interface passes the result of the
call being answered back to its callback object. This message is then forwarded via another message (not
shown) to the object implementing the IpAppLogic interface.
18: This message then instructs the object implementing the IpUICall interface to stop sending announcements to
party A.
19: The application deassigns the call. This will also deassign the associated user interaction.
4.2 Call Barring 2
The following sequence diagram shows a call barring service, initiated as a result of a prearranged event being received
by the call control service. Before the call is routed to the destination number, the calling party is asked for a PIN code.
The code is rejected and the call is cleared.
ETSI
12 Final draft ETSI ES 204 915-4-3 V1.1.1 (2008-02)
: (Logical : : : : IpMultiPartyCallControlManager : : : IpUICall
Vie w::IpAppL. IpAppMultiPartyCallControlManager IpAppMultiPartyCall IpAppUICall I pMultiP artyCa ll IpUIManager
1: new()
2: createNotif ication( )
3: reportNotif ication(  )
4: 'f orward event'
5: new( )
6: getCallLegs( )
7: createUICall( )
8: sendInfoAndCollectReq(   )
9: sendInfoAndCollectRes(  )
10: 'forward ev ent'
11: sendInfoReq(   )
12: sendInf oRes(  )
13: 'forward ev ent'
14: release( )
15: release( )
1: This message i
...

ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 3: Multi-Party Call Control SCF
(Parlay 6)
�
2 ETSI ES 204 915-4-3 V1.1.1 (2008-05)

Reference
DES/TISPAN-01032-4-03-OSA
Keywords
API, IDL, OSA, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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-3 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.7
Foreword.7
1 Scope.9
2 References.9
3 Definitions and abbreviations.9
3.1 Definitions.9
3.2 Abbreviations.9
4 MultiParty Call Control Service Sequence Diagrams .10
4.1 Application initiated call setup.10
4.2 Call Barring 2 .11
4.3 Call forwarding on Busy Service .13
4.4 Call Information Collect Service.14
4.5 Complex Card Service.17
4.6 Hotline Service.20
4.7 Network Controlled Notifications .23
4.8 Use of the Redirected event.24
5 Class Diagrams.24
6 MultiParty Call Control Service Interface Classes.26
6.1 Interface Class IpMultiPartyCallControlManager.26
6.1.1 Method createCall().27
6.1.2 Method createNotification().27
6.1.3 Method destroyNotification().29
6.1.4 Method changeNotification().29
6.1.5 Method setCallLoadControl().29
6.1.6 Method enableNotifications().30
6.1.7 Method disableNotifications().31
6.1.8 Method getNextNotification().31
6.2 Interface Class IpAppMultiPartyCallControlManager.32
6.2.1 Method reportNotification().32
6.2.2 Method callAborted().33
6.2.3 Method managerInterrupted().33
6.2.4 Method managerResumed().34
6.2.5 Method callOverloadEncountered().34
6.2.6 Method callOverloadCeased().34
6.2.7 Method abortMultipleCalls().34
6.3 Interface Class IpMultiPartyCall.34
6.3.1 Method getCallLegs().35
6.3.2 Method createCallLeg().35
6.3.3 Method createAndRouteCallLegReq().36
6.3.4 Method release().37
6.3.5 Method deassignCall().37
6.3.6 Method getInfoReq() .37
6.3.7 Method setChargePlan().38
6.3.8 Method setAdviceOfCharge().38
6.3.9 Method superviseReq().38
6.4 Interface Class IpAppMultiPartyCall .39
6.4.1 Method getInfoRes().39
6.4.2 Method getInfoErr().39
6.4.3 Method superviseRes().40
6.4.4 Method superviseErr().40
6.4.5 Method callEnded().40
6.4.6 Method createAndRouteCallLegErr().40
6.5 Interface Class IpCallLeg.41
ETSI
4 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
6.5.1 Method routeReq().42
6.5.2 Method eventReportReq().42
6.5.3 Method release().43
6.5.4 Method getInfoReq() .43
6.5.5 Method getCall().43
6.5.6 Method attachMediaReq().44
6.5.7 Method detachMediaReq().44
6.5.8 Method getCurrentDestinationAddress().44
6.5.9 Method continueProcessing().45
6.5.10 Method setChargePlan().45
6.5.11 Method setAdviceOfCharge().45
6.5.12 Method superviseReq().46
6.5.13 Method deassign().46
6.5.14 Method getProperties().46
6.5.15 Method setProperties().47
6.6 Interface Class IpAppCallLeg .48
6.6.1 Method eventReportRes().48
6.6.2 Method eventReportErr().49
6.6.3 Method attachMediaRes().49
6.6.4 Method attachMediaErr().49
6.6.5 Method detachMediaRes().49
6.6.6 Method detachMediaErr().49
6.6.7 Method getInfoRes().50
6.6.8 Method getInfoErr().50
6.6.9 Method routeErr().50
6.6.10 Method superviseRes().50
6.6.11 Method superviseErr().51
6.6.12 Method callLegEnded().51
7 MultiParty Call Control Service State Transition Diagrams.51
7.1 State Transition Diagrams for IpMultiPartyCallControlManager .51
7.1.1 Active State.52
7.1.2 Interrupted State.52
7.1.3 Overview of allowed methods .52
7.2 State Transition Diagrams for IpMultiPartyCall .52
7.2.1 IDLE State.53
7.2.2 ACTIVE State.53
7.2.3 RELEASED State.53
7.2.4 Overview of allowed methods .54
7.3 State Transition Diagrams for IpCallLeg .54
7.3.1 Originating Call Leg .55
7.3.1.1 Initiating State.55
7.3.1.2 Analysing State.57
7.3.1.3 Active State.58
7.3.1.4 Releasing State.60
7.3.1.5 Overview of allowed methods, Originating Call Leg STD.62
7.3.2 Terminating Call Leg.63
7.3.2.1 Idle (terminating) State .63
7.3.2.2 Active (terminating) State .64
7.3.2.3 Releasing (terminating) State.67
7.3.2.4 Overview of allowed methods and trigger events, Terminating Call Leg STD .69
8 Multi-Party Call Control Service Properties .69
8.1 List of Service Properties .69
8.2 Service Property values for the CAMEL Service Environment. .71
9 Multi-Party Call Control Data Definitions.72
9.1 Event Notification Data Definitions.72
9.2 Multi-Party Call Control Data Definitions .73
9.2.1 IpCallLeg.73
9.2.2 IpCallLegRef.73
9.2.3 IpAppCallLeg.73
9.2.4 IpAppCallLegRef.73
ETSI
5 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
9.2.5 IpMultiPartyCall.73
9.2.6 IpMultiPartyCallRef.73
9.2.7 IpAppMultiPartyCall.73
9.2.8 IpAppMultiPartyCallRef.73
9.2.9 IpMultiPartyCallControlManager.73
9.2.10 IpMultiPartyCallControlManagerRef.73
9.2.11 IpAppMultiPartyCallControlManager.73
9.2.12 IpAppMultiPartyCallControlManagerRef.73
9.2.13 TpAppCallLegRefSet.73
9.2.14 TpMultiPartyCallIdentifier.74
9.2.15 TpAppMultiPartyCallBack.74
9.2.16 TpAppMultiPartyCallBackRefType.74
9.2.17 TpAppCallLegCallBack.74
9.2.18 TpMultiPartyCallIdentifierSet .74
9.2.19 TpCallAppInfo.75
9.2.20 TpCallAppInfoType.75
9.2.21 TpCallAppInfoSet.75
9.2.22 TpCallEventRequest.75
9.2.23 TpCallEventRequestSet.76
9.2.24 TpCallEventType.76
9.2.25 TpAdditionalCallEventCriteria.78
9.2.26 TpCallEventInfo.78
9.2.27 TpCallAdditionalEventInfo.79
9.2.28 TpCallNotificationRequest.79
9.2.29 TpCallNotificationScope.79
9.2.30 TpCallNotificationInfo.79
9.2.31 TpCallNotificationReportScope.80
9.2.32 TpNotificationRequested.80
9.2.33 TpNotificationRequestedSet.80
9.2.34 TpReleaseCause.80
9.2.35 TpReleaseCauseSet.80
9.2.36 TpCallLegIdentifier.80
9.2.37 TpCallLegIdentifierSet.81
9.2.38 TpCallLegAttachMechanism.81
9.2.39 TpCallLegConnectionProperties.81
9.2.40 TpCallLegInfoReport.81
9.2.41 TpCallLegInfoType.82
9.2.42 TpCallLegSuperviseTreatment.82
9.2.43 TpCallHighProbabilityCompletion.82
9.2.44 TpNotificationRequestedSetEntry.82
9.2.45 TpCarrierSet.82
9.2.46 TpCarrier.82
9.2.47 TpCarrierID.83
9.2.48 TpCarrierSelectionField.83
9.2.49 TpCallLegPropertyName.83
9.2.50 TpCallLegPropertyNameList.83
9.2.51 TpCallLegPropertyValue.83
9.2.52 TpCallLegProperty.83
9.2.53 TpCallLegPropertyList.83
Annex A (normative): OMG IDL Description of Multi-Party Call Control SCF.84
Annex B (informative): W3C WSDL Description of Multi-Party Call Control SCF .85
Annex C (informative): Java API Description of the Call Control SCFs.86
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .87
Annex E (informative): Description of Call Control Sub-part 3: Multi-party call control SCF
for 3GPP2 cdma2000 networks .88
E.1 General Exceptions.88
ETSI
6 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
E.2 Specific Exceptions.88
E.2.1 Clause 1: Scope .88
E.2.2 Clause 2: References .88
E.2.3 Clause 3: Definitions and abbreviations.88
E.2.4 Clause 4: MultiParty Call Control Service Sequence Diagrams .88
E.2.5 Clause 5: Class Diagrams.88
E.2.6 Clause 6: MultiParty Call Control Service Interface Classes .88
E.2.7 Clause 7: MultiParty Call Control Service State Transition Diagrams .89
E.2.8 Clause 8: Multi-Party Call Control Service Properties.89
E.2.9 Clause 9: Multi-Party Call Control Data Definitions .89
E.2.10 Annex A (normative): OMG IDL Description of Multi-Party Call Control SCF.89
E.2.11 Annex B (informative): W3C WSDL Description of Multi-Party Call Control SCF.89
E.2.12 Annex C (informative): Java™ API Description of the Multi-Party Call Control SCF .89
Annex F (informative): Record of changes .90
F.1 Interfaces.90
F.1.1 New.90
F.1.2 Deprecated.90
F.1.3 Removed.90
F.2 Methods.90
F.2.1 New.90
F.2.2 Deprecated.90
F.2.3 Modified.91
F.2.4 Removed.91
F.3 Data Definitions.91
F.3.1 New.91
F.3.2 Modified.91
F.3.3 Removed.91
F.4 Service Properties.91
F.4.1 New.91
F.4.2 Deprecated.91
F.4.3 Modified.92
F.4.4 Removed.92
F.5 Exceptions.92
F.5.1 New.92
F.5.2 Modified.92
F.5.3 Removed.92
F.6 Others.92
History .93

ETSI
7 ETSI ES 204 915-4-3 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 3 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
8 ETSI ES 204 915-4-3 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-3 V7.0.0 (Release 7).
ETSI
9 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 3 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 Multi-Party Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Multi-Party 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
10 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
4 MultiParty Call Control Service Sequence Diagrams
4.1 Application initiated call setup
The following sequence diagram shows an application creating a call between party A and party B. Here, a call is
created first. Then party A's call leg is created before events are requested on it for answer and then routed to the call.
On answer from Party A, an announcement is played indicating that the call is being set up to party B. While the
announcement is being played, party B's call leg is created and then events are requested on it for answer. On answer
from Party B the announcement is cancelled and party B is routed to the call.
The service may as a variation be extended to include 3 parties (or more). After the two party call is established, the
application can create a new leg and request to route it to a new destination address in order to establish a 3 party call.
The event that causes this to happen could for example be the report of answer event from B-party or controlled by the
A-party by entering a service code (mid-call event).
The procedure for call setup to party C is exactly the same as for the set up of the connection to party B (sequence 13 to
17 in the sequence diagram).
: (Logical : AppPartyA : AppPartyB : : : : PartyA : PartyB : : : IpUICall
View::IpAppLogic) IpAppMultiPartyCall (IpAppMultiPartyCallLeg) (IpAppMultiPartyCallLeg) IpAppUICall IpMultiPartyCallControlManager IpMultiPartyCall IpCallLeg IpCallLeg IpUIManager
1: new()
2: createCall( )
3: new()
4: setCallback( )
5: createCallLeg( )
6: new()
7: ev entReportReq( )
8: routeReq(   )
9: eventReportRes ()
10: createUICall( )
11: sendInf oReq(   )
12: sendInfoRes(  )
13: createCallLeg( )
14: new()
15: ev entReportReq( )
16: routeReq(   )
17: ev entReportRes ()
18: abortActionReq( )
19: deassignCall( )
1: This message is used to create an object implementing the IpAppMultiPartyCall interface.
2: This message requests the object implementing the IpMultiPartyCallControlManager interface to create an
object implementing the IpMultiPartyCall interface.
3: Assuming that the criteria for creating an object implementing the IpMultiPartyCall interface (e.g. load control
values not exceeded) is met it is created.
ETSI
11 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
4: Once the object implementing the IpMultiPartyCall interface is created it is used to pass the reference of the
object implementing the IpAppMultiPartyCall interface as the callback reference to the object implementing
the IpMultiPartyCall interface. Note that the reference to the callback interface could already have been passed
in the createCall.
5: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for
customer A.
6: Assuming that the criteria for creating an object implementing the IpCallLeg interface is met, message 6 is
used to create it.
7: This message requests the call leg for customer A to inform the application when the call leg answers the call.
8: The call is then routed to the originating call leg.
9: Assuming the call is answered, the object implementing party A's IpCallLeg interface passes the result of the
call being answered back to its callback object. This message is then forwarded via another message (not
shown) to the object implementing the IpAppLogic interface.
10: A UICall object is created and associated with the just created call leg.
11: This message is used to inform party A that the call is being routed to party B.
12: An indication that the dialogue with party A has commenced is returned via message 13 and eventually
forwarded via another message (not shown) to the object implementing the IpAppLogic interface.
13: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for
customer B.
14: Assuming that the criteria for creating a second object implementing the IpCallLeg interface is met, it is
created.
15: This message requests the call leg for customer B to inform the application when the call leg answers the call.
16: The call is then routed to the call leg.
17: Assuming the call is answered, the object implementing party B's IpCallLeg interface passes the result of the
call being answered back to its callback object. This message is then forwarded via another message (not
shown) to the object implementing the IpAppLogic interface.
18: This message then instructs the object implementing the IpUICall interface to stop sending announcements to
party A.
19: The application deassigns the call. This will also deassign the associated user interaction.
4.2 Call Barring 2
The following sequence diagram shows a call barring service, initiated as a result of a prearranged event being received
by the call control service. Before the call is routed to the destination number, the calling party is asked for a PIN code.
The code is rejected and the call is cleared.
ETSI
12 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
: (Logical : : : : IpMultiPartyCallControlManager : : : IpUICall
Vie w::IpAppL. IpAppMultiPartyCallControlManager IpAppMultiPartyCall IpAppUICall I pMultiP artyCa ll IpUIManager
1: new()
2: createNotif ication( )
3: reportNotif ication(  )
4: 'f orward event'
5: new( )
6: getCallLegs( )
7: createUICall( )
8: sendInfoAndCollectReq(   )
9: sendInfoAndCollectRes(  )
10: 'forward ev ent'
11: sendInfoReq(   )
12: sendInf oRes(  )
13: 'forward ev ent'
14: release( )
15: release( )
1: This message is used by the application to create an object implementing the
IpAppMultiPartyCallControlManager interface.
2: This message is sent by the application to enable notifications on new call events. As this sequence diagra
...

SLOVENSKI STANDARD
01-september-2008
2GSUWLGRVWRSGRVWRULWYH26$$SOLNDFLMVNLSURJUDPVNLYPHVQLN$3,GHO
.UPLOMHQMHNOLFDSRGGHO/DVWQRVWLVWRULWYHQH]PRåQRVWL6&)SULNUPLOMHQMX
NOLFHYYHþXGHOHåHQFHY3DUOD\
Open Service Access (OSA) - Application Programming Interface (API) - Part 4: Call
Control - Sub-part 3: Multi-Party Call Control SCF (Parlay 6)
Ta slovenski standard je istoveten z: ES 204 915-4-3 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 3: Multi-Party Call Control SCF
(Parlay 6)
�
2 ETSI ES 204 915-4-3 V1.1.1 (2008-05)

Reference
DES/TISPAN-01032-4-03-OSA
Keywords
API, IDL, OSA, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

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-3 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.7
Foreword.7
1 Scope.9
2 References.9
3 Definitions and abbreviations.9
3.1 Definitions.9
3.2 Abbreviations.9
4 MultiParty Call Control Service Sequence Diagrams .10
4.1 Application initiated call setup.10
4.2 Call Barring 2 .11
4.3 Call forwarding on Busy Service .13
4.4 Call Information Collect Service.14
4.5 Complex Card Service.17
4.6 Hotline Service.20
4.7 Network Controlled Notifications .23
4.8 Use of the Redirected event.24
5 Class Diagrams.24
6 MultiParty Call Control Service Interface Classes.26
6.1 Interface Class IpMultiPartyCallControlManager.26
6.1.1 Method createCall().27
6.1.2 Method createNotification().27
6.1.3 Method destroyNotification().29
6.1.4 Method changeNotification().29
6.1.5 Method setCallLoadControl().29
6.1.6 Method enableNotifications().30
6.1.7 Method disableNotifications().31
6.1.8 Method getNextNotification().31
6.2 Interface Class IpAppMultiPartyCallControlManager.32
6.2.1 Method reportNotification().32
6.2.2 Method callAborted().33
6.2.3 Method managerInterrupted().33
6.2.4 Method managerResumed().34
6.2.5 Method callOverloadEncountered().34
6.2.6 Method callOverloadCeased().34
6.2.7 Method abortMultipleCalls().34
6.3 Interface Class IpMultiPartyCall.34
6.3.1 Method getCallLegs().35
6.3.2 Method createCallLeg().35
6.3.3 Method createAndRouteCallLegReq().36
6.3.4 Method release().37
6.3.5 Method deassignCall().37
6.3.6 Method getInfoReq() .37
6.3.7 Method setChargePlan().38
6.3.8 Method setAdviceOfCharge().38
6.3.9 Method superviseReq().38
6.4 Interface Class IpAppMultiPartyCall .39
6.4.1 Method getInfoRes().39
6.4.2 Method getInfoErr().39
6.4.3 Method superviseRes().40
6.4.4 Method superviseErr().40
6.4.5 Method callEnded().40
6.4.6 Method createAndRouteCallLegErr().40
6.5 Interface Class IpCallLeg.41
ETSI
4 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
6.5.1 Method routeReq().42
6.5.2 Method eventReportReq().42
6.5.3 Method release().43
6.5.4 Method getInfoReq() .43
6.5.5 Method getCall().43
6.5.6 Method attachMediaReq().44
6.5.7 Method detachMediaReq().44
6.5.8 Method getCurrentDestinationAddress().44
6.5.9 Method continueProcessing().45
6.5.10 Method setChargePlan().45
6.5.11 Method setAdviceOfCharge().45
6.5.12 Method superviseReq().46
6.5.13 Method deassign().46
6.5.14 Method getProperties().46
6.5.15 Method setProperties().47
6.6 Interface Class IpAppCallLeg .48
6.6.1 Method eventReportRes().48
6.6.2 Method eventReportErr().49
6.6.3 Method attachMediaRes().49
6.6.4 Method attachMediaErr().49
6.6.5 Method detachMediaRes().49
6.6.6 Method detachMediaErr().49
6.6.7 Method getInfoRes().50
6.6.8 Method getInfoErr().50
6.6.9 Method routeErr().50
6.6.10 Method superviseRes().50
6.6.11 Method superviseErr().51
6.6.12 Method callLegEnded().51
7 MultiParty Call Control Service State Transition Diagrams.51
7.1 State Transition Diagrams for IpMultiPartyCallControlManager .51
7.1.1 Active State.52
7.1.2 Interrupted State.52
7.1.3 Overview of allowed methods .52
7.2 State Transition Diagrams for IpMultiPartyCall .52
7.2.1 IDLE State.53
7.2.2 ACTIVE State.53
7.2.3 RELEASED State.53
7.2.4 Overview of allowed methods .54
7.3 State Transition Diagrams for IpCallLeg .54
7.3.1 Originating Call Leg .55
7.3.1.1 Initiating State.55
7.3.1.2 Analysing State.57
7.3.1.3 Active State.58
7.3.1.4 Releasing State.60
7.3.1.5 Overview of allowed methods, Originating Call Leg STD.62
7.3.2 Terminating Call Leg.63
7.3.2.1 Idle (terminating) State .63
7.3.2.2 Active (terminating) State .64
7.3.2.3 Releasing (terminating) State.67
7.3.2.4 Overview of allowed methods and trigger events, Terminating Call Leg STD .69
8 Multi-Party Call Control Service Properties .69
8.1 List of Service Properties .69
8.2 Service Property values for the CAMEL Service Environment. .71
9 Multi-Party Call Control Data Definitions.72
9.1 Event Notification Data Definitions.72
9.2 Multi-Party Call Control Data Definitions .73
9.2.1 IpCallLeg.73
9.2.2 IpCallLegRef.73
9.2.3 IpAppCallLeg.73
9.2.4 IpAppCallLegRef.73
ETSI
5 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
9.2.5 IpMultiPartyCall.73
9.2.6 IpMultiPartyCallRef.73
9.2.7 IpAppMultiPartyCall.73
9.2.8 IpAppMultiPartyCallRef.73
9.2.9 IpMultiPartyCallControlManager.73
9.2.10 IpMultiPartyCallControlManagerRef.73
9.2.11 IpAppMultiPartyCallControlManager.73
9.2.12 IpAppMultiPartyCallControlManagerRef.73
9.2.13 TpAppCallLegRefSet.73
9.2.14 TpMultiPartyCallIdentifier.74
9.2.15 TpAppMultiPartyCallBack.74
9.2.16 TpAppMultiPartyCallBackRefType.74
9.2.17 TpAppCallLegCallBack.74
9.2.18 TpMultiPartyCallIdentifierSet .74
9.2.19 TpCallAppInfo.75
9.2.20 TpCallAppInfoType.75
9.2.21 TpCallAppInfoSet.75
9.2.22 TpCallEventRequest.75
9.2.23 TpCallEventRequestSet.76
9.2.24 TpCallEventType.76
9.2.25 TpAdditionalCallEventCriteria.78
9.2.26 TpCallEventInfo.78
9.2.27 TpCallAdditionalEventInfo.79
9.2.28 TpCallNotificationRequest.79
9.2.29 TpCallNotificationScope.79
9.2.30 TpCallNotificationInfo.79
9.2.31 TpCallNotificationReportScope.80
9.2.32 TpNotificationRequested.80
9.2.33 TpNotificationRequestedSet.80
9.2.34 TpReleaseCause.80
9.2.35 TpReleaseCauseSet.80
9.2.36 TpCallLegIdentifier.80
9.2.37 TpCallLegIdentifierSet.81
9.2.38 TpCallLegAttachMechanism.81
9.2.39 TpCallLegConnectionProperties.81
9.2.40 TpCallLegInfoReport.81
9.2.41 TpCallLegInfoType.82
9.2.42 TpCallLegSuperviseTreatment.82
9.2.43 TpCallHighProbabilityCompletion.82
9.2.44 TpNotificationRequestedSetEntry.82
9.2.45 TpCarrierSet.82
9.2.46 TpCarrier.82
9.2.47 TpCarrierID.83
9.2.48 TpCarrierSelectionField.83
9.2.49 TpCallLegPropertyName.83
9.2.50 TpCallLegPropertyNameList.83
9.2.51 TpCallLegPropertyValue.83
9.2.52 TpCallLegProperty.83
9.2.53 TpCallLegPropertyList.83
Annex A (normative): OMG IDL Description of Multi-Party Call Control SCF.84
Annex B (informative): W3C WSDL Description of Multi-Party Call Control SCF .85
Annex C (informative): Java API Description of the Call Control SCFs.86
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .87
Annex E (informative): Description of Call Control Sub-part 3: Multi-party call control SCF
for 3GPP2 cdma2000 networks .88
E.1 General Exceptions.88
ETSI
6 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
E.2 Specific Exceptions.88
E.2.1 Clause 1: Scope .88
E.2.2 Clause 2: References .88
E.2.3 Clause 3: Definitions and abbreviations.88
E.2.4 Clause 4: MultiParty Call Control Service Sequence Diagrams .88
E.2.5 Clause 5: Class Diagrams.88
E.2.6 Clause 6: MultiParty Call Control Service Interface Classes .88
E.2.7 Clause 7: MultiParty Call Control Service State Transition Diagrams .89
E.2.8 Clause 8: Multi-Party Call Control Service Properties.89
E.2.9 Clause 9: Multi-Party Call Control Data Definitions .89
E.2.10 Annex A (normative): OMG IDL Description of Multi-Party Call Control SCF.89
E.2.11 Annex B (informative): W3C WSDL Description of Multi-Party Call Control SCF.89
E.2.12 Annex C (informative): Java™ API Description of the Multi-Party Call Control SCF .89
Annex F (informative): Record of changes .90
F.1 Interfaces.90
F.1.1 New.90
F.1.2 Deprecated.90
F.1.3 Removed.90
F.2 Methods.90
F.2.1 New.90
F.2.2 Deprecated.90
F.2.3 Modified.91
F.2.4 Removed.91
F.3 Data Definitions.91
F.3.1 New.91
F.3.2 Modified.91
F.3.3 Removed.91
F.4 Service Properties.91
F.4.1 New.91
F.4.2 Deprecated.91
F.4.3 Modified.92
F.4.4 Removed.92
F.5 Exceptions.92
F.5.1 New.92
F.5.2 Modified.92
F.5.3 Removed.92
F.6 Others.92
History .93

ETSI
7 ETSI ES 204 915-4-3 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 3 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
8 ETSI ES 204 915-4-3 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-3 V7.0.0 (Release 7).
ETSI
9 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 3 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 Multi-Party Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Multi-Party 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
10 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
4 MultiParty Call Control Service Sequence Diagrams
4.1 Application initiated call setup
The following sequence diagram shows an application creating a call between party A and party B. Here, a call is
created first. Then party A's call leg is created before events are requested on it for answer and then routed to the call.
On answer from Party A, an announcement is played indicating that the call is being set up to party B. While the
announcement is being played, party B's call leg is created and then events are requested on it for answer. On answer
from Party B the announcement is cancelled and party B is routed to the call.
The service may as a variation be extended to include 3 parties (or more). After the two party call is established, the
application can create a new leg and request to route it to a new destination address in order to establish a 3 party call.
The event that causes this to happen could for example be the report of answer event from B-party or controlled by the
A-party by entering a service code (mid-call event).
The procedure for call setup to party C is exactly the same as for the set up of the connection to party B (sequence 13 to
17 in the sequence diagram).
: (Logical : AppPartyA : AppPartyB : : : : PartyA : PartyB : : : IpUICall
View::IpAppLogic) IpAppMultiPartyCall (IpAppMultiPartyCallLeg) (IpAppMultiPartyCallLeg) IpAppUICall IpMultiPartyCallControlManager IpMultiPartyCall IpCallLeg IpCallLeg IpUIManager
1: new()
2: createCall( )
3: new()
4: setCallback( )
5: createCallLeg( )
6: new()
7: ev entReportReq( )
8: routeReq(   )
9: eventReportRes ()
10: createUICall( )
11: sendInf oReq(   )
12: sendInfoRes(  )
13: createCallLeg( )
14: new()
15: ev entReportReq( )
16: routeReq(   )
17: ev entReportRes ()
18: abortActionReq( )
19: deassignCall( )
1: This message is used to create an object implementing the IpAppMultiPartyCall interface.
2: This message requests the object implementing the IpMultiPartyCallControlManager interface to create an
object implementing the IpMultiPartyCall interface.
3: Assuming that the criteria for creating an object implementing the IpMultiPartyCall interface (e.g. load control
values not exceeded) is met it is created.
ETSI
11 ETSI ES 204 915-4-3 V1.1.1 (2008-05)
4: Once the object implementing the IpMultiPartyCall interface is created it is used to pass the reference of the
object implementing the IpAppMultiPartyCall interface as the callback reference to the object implementing
the IpMultiPartyCall interface. Note that the reference to the callback interface could already have been passed
in the createCall.
5: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for
customer A.
6: Assuming that the criteria for creating an object implementing the IpCallLeg interface is met, message 6 is
used to create it.
7: This message requests the call leg for customer A to inform the application when the call leg answers the call.
8: The call is then routed to the originating call leg.
9: Assuming the call is answered, the object implementing party A's IpCallLeg interface passes the result of the
call being answered back to its callback object. This message is then forwarded via another message (not
shown) to the object implementing the IpAppLogic interface.
10: A UICall object is created and associated with the just created call leg.
11: This message is used to inform party A that the call is being routed to party B.
12: An indication that the dialogue with party A has commenced is returned via message 13 and eventually
forwarded via another message (not shown) to the object implementing the IpAppLogic interface.
13: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for
customer B.
14: Assuming that the criteria for creating a second object implementing the IpCallLeg interface is met, it is
created.
15: This message requests the call leg for customer B to inform the application when the call leg answers the call.
16: The call is then routed to the call leg.
17: Assuming the call is answered, the object implementing party B's IpCallLeg interface passes the result of the
call being answered back to its callback object. This message is then forwarded via another message (not
shown) to the object implementing the IpAppLogic interface.
18: This message then instructs the object implementing the IpUICall interface to stop sending announcemen
...