SIST ES 202 915-4-3 V1.2.2:2005

• Abstract:

  Logo and copyright text was missing on the cover sheet of version 1.2.1

• Status: Published
• Publication Date: 31-Dec-2004
• ICS: 33.040.01 - Telecommunication systems in general
• Technical Committee: SPN - Services and Protocols for Networks
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Jan-2005
• Due Date: 01-Jan-2005
• Completion Date: 01-Jan-2005
• Ref Project: ETSI ES 202 915-4-3 V1.2.2 (2003-08) - Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control; Sub-part 3: Multi-Party Call Control SCF (Parlay 4)

SIST ES 202 915-4-3 V1.2.2:2005 is the Slovenian adoption of ETSI ES 202 915-4-3 V1.2.2, part of the Open Service Access (OSA) Application Programming Interface (API) family. It specifies the Multi-Party Call Control Service Capability Feature (SCF) for Parlay 4, so application developers and service platform implementers can control multi-party calls, call legs, notifications, routing, charging and supervision through standardized interfaces.

What does SIST ES 202 915-4-3 V1.2.2:2005 specify?

SIST ES 202 915-4-3 V1.2.2:2005 specifies the Stage 3 API for the OSA Multi-Party Call Control SCF. It defines both the application-side and service-side interfaces, together with the call model and the event and state behavior needed to use them in practice.

The standard is organized around the main technical elements of the service:

• Clause 1 - Scope
• Clause 2 - References
• Clause 3 - Definitions and abbreviations
• Clause 4 - MultiParty Call Control Service Sequence Diagrams
• Clause 5 - Class Diagrams
• Clause 6 - MultiParty Call Control Service Interface Classes
• Clause 7 - MultiParty Call Control Service State Transition Diagrams
• Clause 8 - Multi-Party Call Control Service Properties
• Clause 9 - Multi-Party Call Control Data Definitions
• Annexes A-E - IDL, WSDL, Java API, 3GPP OSA Rel-5 content, and the record of changes

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 Call Control SCFs
Annex D	Contents of 3GPP OSA Rel-5 Call Control
Annex E	Record of changes

What are the key requirements of SIST ES 202 915-4-3 V1.2.2:2005?

SIST ES 202 915-4-3 V1.2.2:2005 defines how an application creates calls, creates and routes call legs, requests events, receives callbacks, and controls call release and supervision. In practice, this is the part of the standard that tells a platform vendor what functions to expose and tells an application developer when to call them and what responses to expect.

Call control is split between manager, call and call-leg interfaces

Clause 6 defines three core service-side interfaces: IpMultiPartyCallControlManager, IpMultiPartyCall and IpCallLeg. The manager creates calls and notifications, the call object handles call-wide functions, and the call-leg object handles leg-specific routing, events and reporting.

That split matters because a multi-party call is not controlled as one flat object. An implementation has to track the call as a whole and each party leg separately.

The service relies on callback interfaces on the application side

Clause 6 also defines the application-side callback interfaces: IpAppMultiPartyCallControlManager, IpAppMultiPartyCall and IpAppCallLeg. These receive notifications, event reports, results and errors asynchronously.

This matters in practice because the document is not describing a simple request-response API. The application has to implement callback handling so the network can report answers, releases, overloads, supervision results and other call events as they happen.

Some operations are mandatory building blocks for an implementation

Clause 6 states minimum implementation sets for the service interfaces. For IpMultiPartyCallControlManager, the service shall implement either createCall(), or createNotification() and destroyNotification(), or enableNotifications() and disableNotifications().

For IpMultiPartyCall, the service shall implement release() and deassignCall(), and either createCallLeg() or createAndRouteCallLegReq(). For IpCallLeg, the service shall implement routeReq(), eventReportReq(), release(), continueProcessing() and deassign().

For buyers and integrators, this is the quickest way to check implementation coverage. If a platform does not provide these functions, it does not fully support the service as described here.

Event handling is controlled by notification criteria and monitor modes

Clause 6.1.2 explains createNotification(), which subscribes the application to selected call events and address ranges. The request can be rejected if criteria overlap in a way that would let more than one application control the same call at the same time.

Clause 8 then defines service properties such as P_MONITOR_MODE, P_TRIGGERING_EVENT_TYPES, P_DYNAMIC_EVENT_TYPES and P_TRIGGERING_ADDRESSES. In practice, these properties determine which events can be armed, whether the application can use P_INTERRUPT and/or P_NOTIFY, and for which numbers notifications are allowed.

This matters because event control is central to the API. The application must know which events it is allowed to monitor and whether a reported event pauses call processing or just informs the application.

The standard defines state models for calls and call legs

Clause 7 gives state transition diagrams for IpMultiPartyCallControlManager, IpMultiPartyCall and IpCallLeg. The call object has IDLE, ACTIVE and RELEASED states, while call-leg behavior is split into originating and terminating models.

This is important because methods are only valid in certain states. The diagrams show when processing is suspended, when the application must call continueProcessing(), and when events such as answer, redirect, release or service code are reported.

The service supports supervision, information retrieval and charging control

Clauses 6.3, 6.4, 6.5 and 6.6 include methods such as getInfoReq(), superviseReq(), setChargePlan() and setAdviceOfCharge(). The callback interfaces return the corresponding reports and errors.

For day-to-day use, this means the API is not limited to setting up and tearing down calls. It also supports collecting call-leg information, supervising call duration, and applying charging-related settings during the call.

Service properties define capability limits and policy constraints

Clause 8 lists properties such as P_MEDIA_TYPE, P_MAX_CALLLEGS_PER_CALL, P_UI_CALL_BASED, P_UI_CALLLEG_BASED and P_PARALLEL_INITIAL_ROUTING_REQUESTS. It also lists service level agreement style constraints like P_CHARGEPLAN_ALLOWED, P_NUMBERS_TO_BE_CHANGED and P_HIGH_PROBABILITY_OF_COMPLETION.

In practice, these properties tell an integrator what the service can do and what the application is allowed to do. They are the main place to check media support, call-leg limits, user interaction support and routing behavior.

What terms does SIST ES 202 915-4-3 V1.2.2:2005 define?

SIST ES 202 915-4-3 V1.2.2:2005 reuses the definitions and abbreviations from ES 202 915-1, but several terms are central to this part.

• Open Service Access (OSA) - the architecture that lets application developers use network functions through standardized interfaces.
• Application Programming Interface (API) - the interface layer through which applications invoke call control functions.
• Service Capability Feature (SCF) - the service building block provided by the network, here the Multi-Party Call Control SCF.
• Unified Modelling Language (UML) - the modelling method used for the sequence diagrams, class diagrams and state diagrams.
• IpMultiPartyCall - the call-level service object used to create, release, supervise and manage a multi-party call.
• IpCallLeg - the call-leg object that represents the signalling relationship between a call and one party.
• monitor mode - the event handling mode that decides whether an event is reported, interrupts processing, or is not monitored.

Who uses SIST ES 202 915-4-3 V1.2.2:2005?

SIST ES 202 915-4-3 V1.2.2:2005 is used by telecom application developers, platform vendors, network service designers and integration teams working on OSA/Parlay-based systems. It is also relevant to quality managers and buyers who need to verify that a call-control platform supports multi-party call setup, event notification, routing, release, supervision and charging control.

The sequence diagrams make it especially useful for teams implementing services such as call barring, call forwarding on busy, hotline behavior, information collection and user-interaction-driven call control. The service properties are useful for contract and capability checks before deployment.

What changed in SIST ES 202 915-4-3 V1.2.2:2005 from the previous edition?

SIST ES 202 915-4-3 V1.2.2:2005 is version 1.2.2 and the history places it after version 1.2.1. Annex E is the record of changes, organized by interfaces, methods, data definitions, service properties, exceptions and other items.

Which standards are used with SIST ES 202 915-4-3 V1.2.2:2005?

SIST ES 202 915-4-3 V1.2.2:2005 uses these companion documents from the same OSA series:

• ES 202 915-1 - provides the overview and the common terms and abbreviations used throughout the API family.
• ES 202 915-2 - provides the common data definitions reused by this part.
• ES 202 915-4-1 - provides the Call Control Common Definitions used by the multi-party call control part.

The foreword also states that this part is equivalent to 3GPP TS 29.198-4-3 V5.2.0 (Release 5), which helps teams align OSA and 3GPP references.

What does the SIST ES 202 915-4-3 V1.2.2:2005 document contain?

The document contains UML-based sequence diagrams for call setup, call barring, call forwarding on busy, information collection, complex card services, hotline service, network controlled notifications and redirected events. These examples show how the interfaces are used during real call flows.

It also contains class diagrams, detailed interface method descriptions, state transition diagrams for the manager, call and call-leg objects, service property tables and data definitions. These sections are used for implementation, integration testing and interoperability checks.

Annex A provides the IDL representation, Annex B provides the WSDL representation and Annex C points to the Java API mapping. Annex D ties the content to 3GPP OSA Rel-5, and Annex E records changes by category for readers tracking revisions.

SLOVENSKI STANDARD
01-januar-2005
2GSUWLGRVWRSGRVWRULWYH26$±9PHVQLN]DDSOLNDFLMVNRSURJUDPLUDQMH$3,±
GHO.UPLOMHQMHNOLFD±SRGGHO.UPLOMHQMHNOLFDYHþXGHOHåHQFHY6&)
Open Service Access (OSA); Application Programming Interface (API); Part 4: Call
Control; Sub-part 3: Multi-Party Call Control SCF (Parlay 4)
Ta slovenski standard je istoveten z: ES 202 915-4-3 Version 1.2.2
ICS:
33.040.01 Telekomunikacijski sistemi Telecommunication systems
na splošno 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 4)
�
2 ETSI ES 202 915-4-3 V1.2.2 (2003-08)

Reference
RES/SPAN-120105
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, send your comment to:
[e-mail]
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 2003.
© The Parlay Group 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI 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 202 915-4-3 V1.2.2 (2003-08)
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().28
6.1.4 Method changeNotification().29
6.1.5 Method <> getNotification().29
6.1.6 Method setCallLoadControl().29
6.1.7 Method <> enableNotifications().30
6.1.8 Method <> disableNotifications().31
6.1.9 Method <> getNextNotification().31
6.2 Interface Class IpAppMultiPartyCallControlManager.31
6.2.1 Method reportNotification().32
6.2.2 Method callAborted().33
6.2.3 Method managerInterrupted().33
6.2.4 Method managerResumed().33
6.2.5 Method callOverloadEncountered().33
6.2.6 Method callOverloadCeased().33
6.3 Interface Class IpMultiPartyCall.34
6.3.1 Method getCallLegs().34
6.3.2 Method createCallLeg().35
6.3.3 Method createAndRouteCallLegReq().35
6.3.4 Method release().36
6.3.5 Method deassignCall().36
6.3.6 Method getInfoReq().37
6.3.7 Method setChargePlan().37
6.3.8 Method setAdviceOfCharge().38
6.3.9 Method superviseReq().38
6.4 Interface Class IpAppMultiPartyCall .38
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().41
6.5 Interface Class IpCallLeg.41
ETSI
4 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
6.5.1 Method routeReq().42
6.5.2 Method eventReportReq().43
6.5.3 Method release().43
6.5.4 Method getInfoReq().44
6.5.5 Method getCall().44
6.5.6 Method attachMediaReq().44
6.5.7 Method detachMediaReq().45
6.5.8 Method getCurrentDestinationAddress().45
6.5.9 Method continueProcessing().45
6.5.10 Method setChargePlan().46
6.5.11 Method setAdviceOfCharge().46
6.5.12 Method superviseReq().46
6.5.13 Method deassign().47
6.6 Interface Class IpAppCallLeg .47
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().50
6.6.7 Method getInfoRes().50
6.6.8 Method getInfoErr().50
6.6.9 Method routeErr().50
6.6.10 Method superviseRes().51
6.6.11 Method superviseErr().51
6.6.12 Method callLegEnded().51
7 MultiParty Call Control Service State Transition Diagrams.52
7.1 State Transition Diagrams for IpMultiPartyCallControlManager .52
7.1.1 Active State.52
7.1.2 Interrupted State.52
7.1.3 Overview of allowed methods .53
7.2 State Transition Diagrams for IpMultiPartyCall .53
7.2.1 IDLE State.54
7.2.2 ACTIVE State.54
7.2.3 RELEASED State.54
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.56
7.3.1.2 Analysing State.57
7.3.1.3 Active State.59
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 .70
8.1 List of Service Properties .70
8.2 Service Property values for the CAMEL Service Environment. .72
9 Multi-Party Call Control Data Definitions.73
9.1 Event Notification Data Definitions.73
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.74
9.2.5 IpMultiPartyCall.74
9.2.6 IpMultiPartyCallRef.74
ETSI
5 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
9.2.7 IpAppMultiPartyCall.74
9.2.8 IpAppMultiPartyCallRef.74
9.2.9 IpMultiPartyCallControlManager.74
9.2.10 IpMultiPartyCallControlManagerRef.74
9.2.11 IpAppMultiPartyCallControlManager.74
9.2.12 IpAppMultiPartyCallControlManagerRef.74
9.2.13 TpAppCallLegRefSet.74
9.2.14 TpMultiPartyCallIdentifier.74
9.2.15 TpAppMultiPartyCallBack.75
9.2.16 TpAppMultiPartyCallBackRefType.75
9.2.17 TpAppCallLegCallBack.75
9.2.18 TpMultiPartyCallIdentifierSet.75
9.2.19 TpCallAppInfo.76
9.2.20 TpCallAppInfoType.76
9.2.21 TpCallAppInfoSet.76
9.2.22 TpCallEventRequest.76
9.2.23 TpCallEventRequestSet.77
9.2.24 TpCallEventType.77
9.2.25 TpAdditionalCallEventCriteria.79
9.2.26 TpCallEventInfo.79
9.2.27 TpCallAdditionalEventInfo.80
9.2.28 TpCallNotificationRequest.80
9.2.29 TpCallNotificationScope.80
9.2.30 TpCallNotificationInfo.80
9.2.31 TpCallNotificationReportScope.81
9.2.32 TpNotificationRequested.81
9.2.33 TpNotificationRequestedSet.81
9.2.34 TpReleaseCause.81
9.2.35 TpReleaseCauseSet.81
9.2.36 TpCallLegIdentifier.81
9.2.37 TpCallLegIdentifierSet.82
9.2.38 TpCallLegAttachMechanism.82
9.2.39 TpCallLegConnectionProperties.82
9.2.40 TpCallLegInfoReport.82
9.2.41 TpCallLegInfoType.83
9.2.42 TpCallLegSuperviseTreatment.83
9.2.43 TpCallHighProbabilityCompletion.83
9.2.44 TpNotificationRequestedSetEntry.83
9.2.45 TpCarrierSet.83
9.2.46 TpCarrier.83
9.2.47 TpCarrierID.84
9.2.48 TpCarrierSelectionField.84
Annex A (normative): OMG IDL Description of Multi-Party Call Control SCF.85
Annex B (informative): W3C WSDL Description of Multi-Party Call Control SCF .86
Annex C (informative): Java API Description of the Call Control SCFs.87
Annex D (informative): Contents of 3GPP OSA Rel-5 Call Control .88
Annex E (informative): Record of changes .89
E.1 Interfaces.89
E.1.1 New.89
E.1.2 Deprecated.89
E.1.3 Removed.89
E.2 Methods.90
E.2.1 New.90
E.2.2 Deprecated.90
E.2.3 Modified.90
E.2.4 Removed.90
ETSI
6 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
E.3 Data Definitions.91
E.3.1 New.91
E.3.2 Modified.91
E.3.3 Removed.91
E.4 Service Properties.91
E.4.1 New.91
E.4.2 Deprecated.92
E.4.3 Modified.92
E.4.4 Removed.92
E.5 Exceptions.92
E.5.1 New.92
E.5.2 Modified.92
E.5.3 Removed.93
E.6 Others.93
History .94

ETSI
7 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
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 Services and Protocols for Advanced
Networks (SPAN).
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 202 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".
ETSI
8 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
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 4.1 set of specifications.
The present document is equivalent to 3GPP TS 29.198-4-3 V5.2.0 (Release 5).
ETSI
9 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
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 202 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 202 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 4)".
ETSI ES 202 915-2: "Open Service Access (OSA); Application Programming Interface (API); Part 2: Common Data
Definitions (Parlay 4)".
ETSI ES 202 915-4-1: "Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control;
Sub-part 1: Call Control Common Definitions (Parlay 4)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations defined in ES 202 915-1 apply.
ETSI
10 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
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: ro uteR eq(   )
9: ev entReportRes ()
10: createUICall( )
11: sendInfoReq(   )
12: sendInf oRes(  )
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.
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.
ETSI
11 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
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 202 915-4-3 V1.2.2 (2003-08)
: (Logical : : : : IpMultiPartyCallControlManager : : : IpUICall
View::IpAppL. IpAppMultiPartyCallControlManager IpAppMultiPartyCall IpAppUICall I pMultiP artyCa ll IpUIManager
1: new()
2: createNotification( )
3: reportNotification(  )
4: 'forward event'
5: new()
6: getCallLegs( )
7: createUICall( )
8: sendInfoAndCollectReq(   )
9: sendInf oAndCollectRes(  )
10: 'forward ev ent'
11: sendInf oReq(   )
12: sendInfoRes(  )
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 diagram depicts
a call barring service, it is likely that all new call events destined for a particular address or address range prompted for
a password before the call is allowed to progress. When a new call, that matches the event criteria, arrives a message
(not shown) is directed to the object implementing the IpMultiPartyCallControlManager. Assuming that the criteria for
creating an object implementing the IpMultiPartyCall interface (e.g. load control values not exceeded) is met, other
messages (not shown) are used to create the call and associated call leg object.
3: This message is used to pass the new call event to the object implementing the
IpAppMultiPartyCallControlManager interface.
4: This message is used to forward message 3 to the IpAppLogic.
5: This message is used by the application to create an object implementing the IpAppMultiPartyCall interface. The
reference to this object is passed back to the object implementing the IpMultiPartyCallControlManager using the return
parameter of the callEventNotify.
6: The application requests a list of all the legs currently in the call.
7: This message is used to create a UICall object that is associated with the incoming leg of the call.
8: The call barring service dialogue is invoked.
9: The result of the dialogue, which in this case is the PIN code, is returned to its callback object.
10: This message is used to forward the previous message to the IpAppLogic
11: Assuming an incorrect PIN is entered, the calling party is informed using additional dialogue of the reason why the
call cannot be completed.
12: This message passes the indication that the additional dialogue has been sent.
ETSI
13 ETSI ES 202 915-4-3 V1.2.2 (2003-08)
13: This message is used to forward the previous message to the IpAppLogic.
14: No more UI is required, so the UICall obje
...