SIST ES 204 915-4-1 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 1 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 common definitions used by the Call Control Service Capability Features (SCF).

• 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-1 V1.1.1 (2008-05) - Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control; Sub-part 1: Call Control Common Definitions (Parlay 6)

SIST ES 204 915-4-1 V1.1.1:2008 is an ETSI Standard for Open Service Access (OSA) Application Programming Interface (API), Part 4: Call Control, Sub-part 1: Call Control Common Definitions (Parlay 6). It specifies the common definitions used by the Call Control Service Capability Features (SCF) in the OSA Stage 3 API, so application developers and network implementers can control calls and sessions through a standardised interface. The document is part of the Parlay 6.0 set of specifications and is equivalent to 3GPP TS 29.198-4-1 V7.0.0 (Release 7).

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

SIST ES 204 915-4-1 V1.1.1:2008 specifies the common definitions for the Call Control SCF within the OSA API. It is the first sub-part of Part 4 and focuses on the shared call-control model, the service interface pattern, and the data types used across the Call Control API family.

The document is organised into scope, references, definitions and abbreviations, Call Control SCF, Service Interface Specifications, Common Call Control Data Types, and six annexes.

Annex	What it covers
Annex A	Normative OMG IDL description of the common call control data types
Annex B	Informative W3C WSDL description of the common call control data types
Annex C	Informative Java API description of the Call Control SCFs
Annex D	Informative contents of 3GPP OSA Rel-7 Call Control
Annex E	Informative description for 3GPP2 cdma2000 networks
Annex F	Informative record of changes

Clause 2 points to ES 204 915-1 for the provisions that apply through reference. Clause 4 introduces the call control model and control concepts, clause 5 defines the interface specification style, and clause 6 defines the common call control data types.

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

SIST ES 204 915-4-1 V1.1.1:2008 defines how a call-control application sees a call, how service methods behave, and how common data is represented. In practice, this is the part that matters when designing an API implementation, mapping network events to callbacks, or deciding what data an application can send or receive.

Call control is modelled around calls, legs and addresses

Clause 4.1 defines a call object, a call leg object, an address and a terminal. A call is the relation between parties, while each call leg represents the logical link between the call and an address. For implementers, this means the API manages the whole call view and also the per-party legs that carry signalling and, where applicable, bearer or media connections.

Clause 4.1 also explains that legs can be attached or detached. Only attached legs can exchange media or bearer traffic, so the implementation must keep call state and leg state aligned with the network signalling.

The API supports single and multiple control points

Clause 4.4 describes Single point of Control (SPC) and Multiple Points of Control (MPC). With MPC, more than one application can influence the same call or session at the same time, and the document explains the cascaded chain principle for ordering event handling. In practice, this matters when several services are triggered for the same subscriber, because the operator must define how notifications and responses are sequenced.

Clause 4.4.3 notes that handling conflicts between multiple services is outside the scope of the present document, while clause 4.4.4 says network support for single or multiple control points is an implementation issue.

Methods have defined support and error behaviour

Clause 4.3 states that if an implementation supports a method, it shall support the functionality for at least one valid set of parameter values. If a service-interface method is not supported, the implementation shall return P_METHOD_NOT_SUPPORTED. If an application-interface method is not supported, the call shall still be possible and no exception shall be returned.

This matters for interoperability: an application can probe capability safely, and a service can signal unsupported functionality in a predictable way.

Service interfaces use a common callback pattern

Clause 5 defines the interface format in Unified Modelling Language (UML). The base interface is IpInterface, and all service interfaces inherit from IpService. The generic service interface provides setCallback() and setCallbackWithSessionID().

These methods tell the service where to send callbacks. The session-ID form is used for interactions tied to a specific session such as a call or call leg. If more than one callback reference is set, the most recent one is used, and if that fails the next most recent is used.

The document defines the main call-control data used by applications

Clause 6 defines the shared data types used by call-control methods. These include charging plans, error reports, information reports, load control, monitoring modes, supervision reports, treatments, service codes and media types. For a buyer or integrator, this section tells you what information the API can exchange with charging, supervision, monitoring and service logic.

Examples of the practical use are:

• selecting transparent or predefined charging
• reporting call end causes and timing
• describing supervision timeouts and warning tones
• declaring whether a call event is intercepted, only notified, or not monitored
• reporting audio, video or data media streams

Annexes provide machine-readable and platform-specific forms

Annex A gives the OMG IDL form of the data types, Annex B gives the W3C WSDL form, and Annex C gives Java API realisations for J2SE and J2EE. Annex E adapts the specification for 3GPP2 cdma2000 systems, with noted exceptions and references that are not applicable there.

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

• Open Service Access (OSA) - An architecture that lets application developers use network functionality through an open standardised interface.
• Service Capability Feature (SCF) - A call-control or other service-specific capability exposed through the API.
• Single point of Control (SPC) - A control model where only one application can influence a call or session at a time.
• Multiple Points of Control (MPC) - A control model where more than one application can influence the same call or session at the same time.
• Unified Modelling Language (UML) - The notation used to specify interface classes, methods, parameters and state models.
• Interface Definition Language (IDL) - The machine-oriented form given in Annex A for the common call-control data types.
• Web Services Description Language (WSDL) - The service description form given in Annex B for the common call-control data types.

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

SIST ES 204 915-4-1 V1.1.1:2008 is used by application developers, telecom platform vendors, and network engineers who implement OSA call-control services. It is also relevant to quality teams and buyers who need to check API compatibility, callback behaviour, and data-model support.

Typical users include:

• developers of Parlay/OSA client applications
• implementers of service interfaces and callback interfaces
• network operators provisioning triggers and priorities
• gateway and platform vendors supporting call control in UMTS IMS, IN, or cdma2000 environments
• teams producing Java, IDL or WSDL realisations

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

The document is identified as V1.1.1 and the foreword states that it is equivalent to 3GPP TS 29.198-4-1 V7.0.0 (Release 7). Annex F organises the change record for Parlay 6.0 into interfaces, methods, data definitions, service properties, exceptions and other items, each grouped as new, deprecated, modified or removed.

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

Standard	What it contributes
ETSI ES 204 915-1	Overview, shared terms and abbreviations, and the Java realisation rules referenced in Annex C
ETSI ES 204 915-2	Common data definitions used where a type is not defined in this part
ETSI ES 204 915-5	Source of TpUIInfo, which is referenced in call treatment information
ITU-T Recommendation Q.931	Bearer capability information and the facility information element
ITU-T Recommendation Q.932	Facility information element used in service-code handling
ITU-T Recommendation Q.763	Party category and teleservice information
TS 122 002 and TS 122 003	Bearer service and teleservice classifications
TS 124 002	Network access type classifications
TS 123 078 and TS 129 078	Annex E notes these are not applicable for cdma2000 systems

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

SIST ES 204 915-4-1 V1.1.1:2008 contains the UML-based interface structure for call control, including the base interface, the generic service interface and the callback methods setCallback() and setCallbackWithSessionID(). It also contains the common data definitions for charging, monitoring, supervision, information reporting, error reporting, service codes, treatments and media types.

The document includes tables for sequences, tagged choices, numbered sets and enumerations, plus the cascaded chain model figure in clause 4.2. It also includes platform-specific realisations in IDL, WSDL and Java form through its annexes, which makes it useful for design, implementation, integration and conformance work.

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

Reference
DES/TISPAN-01032-4-01-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-1 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Call Control SCF.7
4.1 Call Model Description .8
4.2 Structure of Call Control SCF Documentation.8
4.3 General requirements on support of methods.9
4.4 Application Control of a Call or Session.9
4.4.1 Introduction.9
4.4.2 Concept of Multiple Points of Control.9
4.4.2.1 Cascaded Chain Model .9
4.4.3 Service Interactions.11
4.4.4 Multiple services - applicability of MPC for Parlay/OSA .11
5 The Service Interface Specifications.11
5.1 Interface Specification Format .11
5.1.1 Interface Class.11
5.1.2 Method descriptions.12
5.1.3 Parameter descriptions.12
5.1.4 State Model.12
5.2 Base Interface.12
5.2.1 Interface Class IpInterface .12
5.3 Service Interfaces.12
5.3.1 Overview.12
5.4 Generic Service Interface .13
5.4.1 Interface Class IpService .13
5.4.1.1 Method setCallback().13
5.4.1.2 Method setCallbackWithSessionID().13
6 Common Call Control Data Types.14
6.1 TpCallAlertingMechanism.14
6.2 TpCallBearerService.14
6.3 TpCallChargePlan.14
6.4 TpCallPartyToChargeAdditionalInfo.15
6.5 TpCallPartyToChargeType.15
6.6 TpCallChargeOrderCategory.15
6.7 TpCallEndedReport.15
6.8 TpCallError.15
6.9 TpCallAdditionalErrorInfo.16
6.10 TpCallErrorType.16
6.11 TpCallInfoReport.16
6.12 TpCallInfoType.17
6.13 TpCallLoadControlMechanism.17
6.14 TpCallLoadControlIntervalRate.17
6.15 TpCallLoadControlMechanismType.17
6.16 TpCallMonitorMode.17
6.17 TpCallNetworkAccessType.18
6.18 TpCallPartyCategory.18
6.19 TpCallServiceCode.18
6.20 TpCallServiceCodeSet.18
6.21 TpCallServiceCodeType.19
ETSI
4 Final draft ETSI ES 204 915-4-1 V1.1.1 (2008-02)
6.22 TpCallSuperviseReport.19
6.23 TpCallSuperviseTreatment.19
6.24 TpCallTeleService.20
6.25 TpCallTreatment.20
6.26 TpCallTreatmentType.20
6.27 TpCallAdditionalTreatmentInfo.21
6.28 TpMediaType.21
Annex A (normative): OMG IDL Description of Common Call Control Data Types.22
Annex B (informative): W3C WSDL Description of Common Call Control Data Types .23
Annex C (informative): Java API Description of the Call Control SCFs.24
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .25
Annex E (informative): Description of Call Control Sub-part 1: Call Control Common
Definitions for 3GPP2 cdma2000 networks.26
E.1 General Exceptions.26
E.2 Specific Exceptions.26
E.2.1 Clause 1: Scope .26
E.2.2 Clause 2: References .26
E.2.3 Clause 3: Definitions and abbreviations.26
E.2.4 Clause 4: Call Control SCF .26
E.2.5 Clause 5: The Service Interface Specifications .26
E.2.6 Clause 6: Common Call Control Data Types .26
E.2.7 Annex A (normative): OMG IDL Description of Common Call Control Data Types .27
E.2.8 Annex B (informative): W3C WSDL Description of Common Call Control Data Types .27
E.2.9 Annex C (informative): Java™ API Description of the Call Control SCFs.27
Annex F (informative): Record of changes .28
F.1 Interfaces.28
F.1.1 New.28
F.1.2 Deprecated.28
F.1.3 Removed.28
F.2 Methods.28
F.2.1 New.28
F.2.2 Deprecated.28
F.2.3 Modified.29
F.2.4 Removed.29
F.3 Data Definitions.29
F.3.1 New.29
F.3.2 Modified.29
F.3.3 Removed.29
F.4 Service Properties.29
F.4.1 New.29
F.4.2 Deprecated.29
F.4.3 Modified.30
F.4.4 Removed.30
F.5 Exceptions.30
F.5.1 New.30
F.5.2 Modified.30
F.5.3 Removed.30
F.6 Others.30
History .31

ETSI
5 Final draft ETSI ES 204 915-4-1 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 1 of a multi-part deliverable covering Open Service Access (OSA);
Application Programming Interface (API), as identified below. The API specification (ES 204 915) is structured in the
following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF";
Part 13: "Policy Management SCF";
Part 14: "Presence and Availability Management SCF";
Part 15: "Multi-Media Messaging SCF"
Part 16: "Service Broker SCF".
ETSI
6 Final draft ETSI ES 204 915-4-1 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-1 V7.0.0 (Release 7).
ETSI
7 Final draft ETSI ES 204 915-4-1 V1.1.1 (2008-02)
1 Scope
The present document is part 4, sub-part 1 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 common definitions used by the Call Control Service Capability Features (SCF).
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.
4 Call Control SCF
Four flavours of call control APIs are specified in ES 204 915, Parlay 6. Three of these have been included in 3GPP
Release 6. These are the Generic Call Control (GCC), the Multi-Party Call Control (MPCC) and the Multi-Media Call
Control (MMCC). The generic call control is the same API as was already present in the previous specification for
3GPP Release 99 (TS 129 198 V3). Multi-Party Call Control was introduced in the Release 4 specifications, and Multi-
Media Call Control was introduced in Release 5. All four have been included in ES 201 915, Parlay 3 and ES 202 915,
Parlay 4.
The joint work between 3GPP CN5, ETSI TISPAN and the Parlay Call Control Working group with collaboration from
JAIN has been focussed on the Multi-party and Multi-Media call control APIs. A number of improvements on call
control functionality have been made and are reflected in these APIs. For this it was necessary to break the inheritance
that previously existed between Generic and Multi-party call control.
The joint call control group has furthermore decided that the multi-party call control is to be considered as the future
base call control family and the technical work will not be continued on Generic Call control. Errors or technical flaws
will of course be corrected.
ETSI
8 Final draft ETSI ES 204 915-4-1 V1.1.1 (2008-02)
4.1 Call Model Description
The call model used for the Call Control SCFs has the following objects:
• A call object. A call is a relation between a number of parties. The call object relates to the entire call view
from the application. E.g. the entire call will be released when a release is called on the call. Note that different
applications can have different views on the same physical call, e.g. one application for the originating side
and another application for the terminating side. The applications will not be aware of each other, all
'communication' between the applications will be by means of network signalling. The API currently does not
specify any feature interaction mechanisms.
• A call leg object. The leg object represents a logical association between a call and an address. The
relationship includes at least the signalling relation with the party. The relation with the address is only made
when the leg is routed. Before that the leg object is IDLE and not yet associated with the address.
• An address. The address logically represents a party in the call.
• A terminal. A terminal is the end-point of the signalling and/or media for a party. This object type is currently
not addressed.
The call object is used to establish a relation between a number of parties by creating a leg for each party within the
call.
Associated with the signalling relationship represented by the call leg, there may also be a bearer connection (e.g. in the
traditional voice only networks) or a number (zero or more) of media channels (in multi-media networks).
A leg can be attached to the call or detached from the call. When the leg is attached, this means that media or bearer
channels related to the legs are connected to the media or bearer channels of the other legs that are attached to the same
call. I.e. only legs that are attached can 'speak' to each other. A leg can have a number of states, depending on the
signalling received from or sent to the party associated with the leg. Usually there is a limit to the number of legs that
are in being routed (i.e. the connection is being established) or connected to the call (i.e. the connection is established).
Also, there usually is a limit to the number of legs that can be simultaneously attached to the same call.
Some networks distinguish between controlling and passive legs. By definition the call will be released when the
controlling leg is released. All other legs are called passive legs. There can be at most one controlling leg per call.
However, there is currently no way the application can influence whether a Leg is controlling or not.
There are two ways for an application to get the control of a call. The application can request to be notified of calls that
meet certain criteria. When a call occurs in the network that meets these criteria, the application is notified and can
control the call. Some legs will already be associated with the call in this case. Another way is to create a new call from
the application.
4.2 Structure of Call Control SCF Documentation
Each of the Call Control SCFs is specified under the following headings:
• The Sequence diagrams give the reader a practical idea of how each of the SCF is implemented.
• The Class relationships clause shows how each of the interfaces applicable to the SCF, relate to one another.
• The Interface specification clause describes in detail each of the interfaces shown within the Class diagram
part.
• The State Transition Diagrams (STD) show transition between states in the SCF. The states and transitions are
well-defined; either methods specified in the Interface specification or events occurring in the underlying
networks cause state transitions.
• The Data definitions clause shows a detailed expansion of each of the data types associated with the methods
within the classes. Note that some data types are used in other methods and classes and are therefore defined
within the Common Data types part ES 204 915-2.
ETSI
9 Final draft ETSI ES 204 915-4-1 V1.1.1 (2008-02)
4.3 General requirements on support of methods
An implementation of one of the call control APIs which supports or implements a method described in one of the
sub-parts of ES 204 915-4, shall support or implement the functionality described for that method, for at least one valid
set of values for the parameters of that method.
Where a method is not supported by an implementation of a Service interface, the exception
P_METHOD_NOT_SUPPORTED shall be returned to any call of that method.
Where a method is not supported by an implementation of an Application interface, a call to that method shall be
possible, and no exception shall be returned.
4.4 Application Control of a Call or Session
4.4.1 Introduction
Services should be provision-able by multiple independent parties and therefore multiple applications may apply control
to the same instance of a call or a session. How this may be enabled is further described in the following.
However, first some reflections on what is meant with application control:
• Single application control may be classified as to allow at the same point in time during call or session
processing only one application to be capable to influence the call or session. This does not exclude more
applications on the same call, but they cannot operate at the same time. This is referred to as "Single point of
Control (SPC)" in IN terminology.
• Multiple application control may be classified as to allow at the same point in time during call or session
processing more than one application to be capable to influence the call or session. This is referred to as
"Multiple Points of Control (MPC)" in IN terminology.
MPC will demand some rules for event handling among multiple applications on a call like the cascaded chain
principle as applied in IN CS3 (ITU-T Recommendation Q.1238-2), where MPC has been introduced.
4.4.2 Concept of Multiple Points of Control
The term "multiple points of control" refers to the situation when multiple concurrently executing applications apply
control to one and the same instance of a call or session.
General Objective:
"If there ismore than one controlling application acting on the same call or session, then the event notification detection
point processing requested by any of the involved applications shall be performed in the same way as if notification
reporting had occurred in different call or session control instances, which are separated by a Network Node interface".
NOTE: The objective description above is taken from ITU-T Recommendation Q.1238-2, but slightly generalized
to become non-IN specific.
The MPC general objective signifies the cascaded chain principle, which is further explained below through an
informative cascaded chain model.
4.4.2.1 Cascaded Chain Model
When services running in different nodes apply control to a call or session, even if they are unaware of each other, they
provide a cascading of applications. They provide a natural ordering of applications. This ordering can be said to be
upstream or downstream. A downstream ordering is the ordering of applications as they are invoked downstream in the
network from the calling party (e.g. origin client, UAC) toward the called party (e.g. destination server, UAS). An
upstream ordering is the ordering of applications as they are invoked upstream in the network from the called party
toward the calling party.
ETSI
10 Final draft ETSI ES 204 915-4-1 V1.1.1 (2008-02)
Logically Most Upstream
Appl. Appl. Appl.
request
1 2 3
Downstream
Node
Calling party
Called party
(e.g.SIP Server)
(e.g. UAC)
(e.g. UAS)
Upstream
response
6 5 4
Appl. Appl. Appl.
Logically Most Downstream
Figure 1: Cascaded Chain Model
When applications that apply control to one instance of a call or session are invoked in some order, on the same node,
the applications can be thought of as cascaded.
When a "request" is received then the earlier the application is invoked, based on this event, the more logically
upstream it is considered to be in the chain of cascaded applications. When a response is received then the earlier the
applications is invoked, based on this event, the more logically downstream it is considered to be in the chain of
cascaded applications.
This means that the applications are treated as if they were triggered in different nodes (or hosts). This model is
conceptually simple and may provide a natural algorithm for resolving conflicts between the instructions of multiple
service applications at the same call or session event.
On reception of a call or session event in the network the actions are executed in order of priority in the following
manner:
1) Control is passed to the first application.
2) Some response is received from the first application.
3) Control is passed to the second application.
4) Some response is received from the second application and so on.
In this way a decision about whether to invoke a subsequent application can depend on the output from the previous
application.
If the first application terminates the request then the second application must not be invoked.
The most simple form of cascading is an order based in which the applications are triggered on a single event.
If for example three application "X1" "Y1" and "Z1" need to be triggered on eve
...

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

Reference
DES/TISPAN-01032-4-01-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-1 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Call Control SCF.7
4.1 Call Model Description .8
4.2 Structure of Call Control SCF Documentation.8
4.3 General requirements on support of methods.9
4.4 Application Control of a Call or Session.9
4.4.1 Introduction.9
4.4.2 Concept of Multiple Points of Control.9
4.4.2.1 Cascaded Chain Model .9
4.4.3 Service Interactions.11
4.4.4 Multiple services - applicability of MPC for Parlay/OSA .11
5 The Service Interface Specifications.11
5.1 Interface Specification Format .11
5.1.1 Interface Class.11
5.1.2 Method descriptions.12
5.1.3 Parameter descriptions.12
5.1.4 State Model.12
5.2 Base Interface.12
5.2.1 Interface Class IpInterface .12
5.3 Service Interfaces.12
5.3.1 Overview.12
5.4 Generic Service Interface .13
5.4.1 Interface Class IpService .13
5.4.1.1 Method setCallback().13
5.4.1.2 Method setCallbackWithSessionID().13
6 Common Call Control Data Types.14
6.1 TpCallAlertingMechanism.14
6.2 TpCallBearerService.14
6.3 TpCallChargePlan.14
6.4 TpCallPartyToChargeAdditionalInfo.15
6.5 TpCallPartyToChargeType.15
6.6 TpCallChargeOrderCategory.15
6.7 TpCallEndedReport.15
6.8 TpCallError.15
6.9 TpCallAdditionalErrorInfo.16
6.10 TpCallErrorType.16
6.11 TpCallInfoReport.16
6.12 TpCallInfoType.17
6.13 TpCallLoadControlMechanism.17
6.14 TpCallLoadControlIntervalRate.17
6.15 TpCallLoadControlMechanismType.17
6.16 TpCallMonitorMode.17
6.17 TpCallNetworkAccessType.18
6.18 TpCallPartyCategory.18
6.19 TpCallServiceCode.18
6.20 TpCallServiceCodeSet.18
6.21 TpCallServiceCodeType.19
ETSI
4 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
6.22 TpCallSuperviseReport.19
6.23 TpCallSuperviseTreatment.19
6.24 TpCallTeleService.20
6.25 TpCallTreatment.20
6.26 TpCallTreatmentType.20
6.27 TpCallAdditionalTreatmentInfo.21
6.28 TpMediaType.21
Annex A (normative): OMG IDL Description of Common Call Control Data Types.22
Annex B (informative): W3C WSDL Description of Common Call Control Data Types .23
Annex C (informative): Java API Description of the Call Control SCFs.24
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .25
Annex E (informative): Description of Call Control Sub-part 1: Call Control Common
Definitions for 3GPP2 cdma2000 networks.26
E.1 General Exceptions.26
E.2 Specific Exceptions.26
E.2.1 Clause 1: Scope .26
E.2.2 Clause 2: References .26
E.2.3 Clause 3: Definitions and abbreviations.26
E.2.4 Clause 4: Call Control SCF .26
E.2.5 Clause 5: The Service Interface Specifications .26
E.2.6 Clause 6: Common Call Control Data Types .26
E.2.7 Annex A (normative): OMG IDL Description of Common Call Control Data Types .27
E.2.8 Annex B (informative): W3C WSDL Description of Common Call Control Data Types .27
E.2.9 Annex C (informative): Java™ API Description of the Call Control SCFs.27
Annex F (informative): Record of changes .28
F.1 Interfaces.28
F.1.1 New.28
F.1.2 Deprecated.28
F.1.3 Removed.28
F.2 Methods.28
F.2.1 New.28
F.2.2 Deprecated.28
F.2.3 Modified.29
F.2.4 Removed.29
F.3 Data Definitions.29
F.3.1 New.29
F.3.2 Modified.29
F.3.3 Removed.29
F.4 Service Properties.29
F.4.1 New.29
F.4.2 Deprecated.29
F.4.3 Modified.30
F.4.4 Removed.30
F.5 Exceptions.30
F.5.1 New.30
F.5.2 Modified.30
F.5.3 Removed.30
F.6 Others.30
History .31

ETSI
5 ETSI ES 204 915-4-1 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 1 of a multi-part deliverable covering Open Service Access (OSA);
Application Programming Interface (API), as identified below. The API specification (ES 204 915) is structured in the
following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF";
Part 13: "Policy Management SCF";
Part 14: "Presence and Availability Management SCF";
Part 15: "Multi-Media Messaging SCF"
Part 16: "Service Broker SCF".
ETSI
6 ETSI ES 204 915-4-1 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-1 V7.0.0 (Release 7).
ETSI
7 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 1 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 common definitions used by the Call Control Service Capability Features (SCF).
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.
4 Call Control SCF
Four flavours of call control APIs are specified in ES 204 915, Parlay 6. Three of these have been included in 3GPP
Release 6. These are the Generic Call Control (GCC), the Multi-Party Call Control (MPCC) and the Multi-Media Call
Control (MMCC). The generic call control is the same API as was already present in the previous specification for
3GPP Release 99 (TS 129 198 V3). Multi-Party Call Control was introduced in the Release 4 specifications, and Multi-
Media Call Control was introduced in Release 5. All four have been included in ES 201 915, Parlay 3 and ES 202 915,
Parlay 4.
The joint work between 3GPP CN5, ETSI TISPAN and the Parlay Call Control Working group with collaboration from
JAIN has been focussed on the Multi-party and Multi-Media call control APIs. A number of improvements on call
control functionality have been made and are reflected in these APIs. For this it was necessary to break the inheritance
that previously existed between Generic and Multi-party call control.
The joint call control group has furthermore decided that the multi-party call control is to be considered as the future
base call control family and the technical work will not be continued on Generic Call control. Errors or technical flaws
will of course be corrected.
ETSI
8 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
4.1 Call Model Description
The call model used for the Call Control SCFs has the following objects:
• A call object. A call is a relation between a number of parties. The call object relates to the entire call view
from the application. E.g. the entire call will be released when a release is called on the call. Note that different
applications can have different views on the same physical call, e.g. one application for the originating side
and another application for the terminating side. The applications will not be aware of each other, all
'communication' between the applications will be by means of network signalling. The API currently does not
specify any feature interaction mechanisms.
• A call leg object. The leg object represents a logical association between a call and an address. The
relationship includes at least the signalling relation with the party. The relation with the address is only made
when the leg is routed. Before that the leg object is IDLE and not yet associated with the address.
• An address. The address logically represents a party in the call.
• A terminal. A terminal is the end-point of the signalling and/or media for a party. This object type is currently
not addressed.
The call object is used to establish a relation between a number of parties by creating a leg for each party within the
call.
Associated with the signalling relationship represented by the call leg, there may also be a bearer connection (e.g. in the
traditional voice only networks) or a number (zero or more) of media channels (in multi-media networks).
A leg can be attached to the call or detached from the call. When the leg is attached, this means that media or bearer
channels related to the legs are connected to the media or bearer channels of the other legs that are attached to the same
call. I.e. only legs that are attached can 'speak' to each other. A leg can have a number of states, depending on the
signalling received from or sent to the party associated with the leg. Usually there is a limit to the number of legs that
are in being routed (i.e. the connection is being established) or connected to the call (i.e. the connection is established).
Also, there usually is a limit to the number of legs that can be simultaneously attached to the same call.
Some networks distinguish between controlling and passive legs. By definition the call will be released when the
controlling leg is released. All other legs are called passive legs. There can be at most one controlling leg per call.
However, there is currently no way the application can influence whether a Leg is controlling or not.
There are two ways for an application to get the control of a call. The application can request to be notified of calls that
meet certain criteria. When a call occurs in the network that meets these criteria, the application is notified and can
control the call. Some legs will already be associated with the call in this case. Another way is to create a new call from
the application.
4.2 Structure of Call Control SCF Documentation
Each of the Call Control SCFs is specified under the following headings:
• The Sequence diagrams give the reader a practical idea of how each of the SCF is implemented.
• The Class relationships clause shows how each of the interfaces applicable to the SCF, relate to one another.
• The Interface specification clause describes in detail each of the interfaces shown within the Class diagram
part.
• The State Transition Diagrams (STD) show transition between states in the SCF. The states and transitions are
well-defined; either methods specified in the Interface specification or events occurring in the underlying
networks cause state transitions.
• The Data definitions clause shows a detailed expansion of each of the data types associated with the methods
within the classes. Note that some data types are used in other methods and classes and are therefore defined
within the Common Data types part ES 204 915-2.
ETSI
9 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
4.3 General requirements on support of methods
An implementation of one of the call control APIs which supports or implements a method described in one of the
sub-parts of ES 204 915-4, shall support or implement the functionality described for that method, for at least one valid
set of values for the parameters of that method.
Where a method is not supported by an implementation of a Service interface, the exception
P_METHOD_NOT_SUPPORTED shall be returned to any call of that method.
Where a method is not supported by an implementation of an Application interface, a call to that method shall be
possible, and no exception shall be returned.
4.4 Application Control of a Call or Session
4.4.1 Introduction
Services should be provision-able by multiple independent parties and therefore multiple applications may apply control
to the same instance of a call or a session. How this may be enabled is further described in the following.
However, first some reflections on what is meant with application control:
• Single application control may be classified as to allow at the same point in time during call or session
processing only one application to be capable to influence the call or session. This does not exclude more
applications on the same call, but they cannot operate at the same time. This is referred to as "Single point of
Control (SPC)" in IN terminology.
• Multiple application control may be classified as to allow at the same point in time during call or session
processing more than one application to be capable to influence the call or session. This is referred to as
"Multiple Points of Control (MPC)" in IN terminology.
MPC will demand some rules for event handling among multiple applications on a call like the cascaded chain
principle as applied in IN CS3 (ITU-T Recommendation Q.1238-2), where MPC has been introduced.
4.4.2 Concept of Multiple Points of Control
The term "multiple points of control" refers to the situation when multiple concurrently executing applications apply
control to one and the same instance of a call or session.
General Objective:
"If there ismore than one controlling application acting on the same call or session, then the event notification detection
point processing requested by any of the involved applications shall be performed in the same way as if notification
reporting had occurred in different call or session control instances, which are separated by a Network Node interface".
NOTE: The objective description above is taken from ITU-T Recommendation Q.1238-2, but slightly generalized
to become non-IN specific.
The MPC general objective signifies the cascaded chain principle, which is further explained below through an
informative cascaded chain model.
4.4.2.1 Cascaded Chain Model
When services running in different nodes apply control to a call or session, even if they are unaware of each other, they
provide a cascading of applications. They provide a natural ordering of applications. This ordering can be said to be
upstream or downstream. A downstream ordering is the ordering of applications as they are invoked downstream in the
network from the calling party (e.g. origin client, UAC) toward the called party (e.g. destination server, UAS). An
upstream ordering is the ordering of applications as they are invoked upstream in the network from the called party
toward the calling party.
ETSI
10 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
Logically Most Upstream
Appl. Appl. Appl.
request
1 2 3
Downstream
Node
Calling party
Called party
(e.g.SIP Server)
(e.g. UAC)
(e.g. UAS)
Upstream
response
6 5 4
Appl. Appl. Appl.
Logically Most Downstream
Figure 1: Cascaded Chain Model
When applications that apply control to one instance of a call or session are invoked in some order, on the same node,
the applications can be thought of as cascaded.
When a "request" is received then the earlier the application is invoked, based on this event, the more logically
upstream it is considered to be in the chain of cascaded applications. When a response is received then the earlier the
applications is invoked, based on this event, the more logically downstream it is considered to be in the chain of
cascaded applications.
This means that the applications are treated as if they were triggered in different nodes (or hosts). This model is
conceptually simple and may provide a natural algorithm for resolving conflicts between the instructions of multiple
service applications at the same call or session event.
On reception of a call or session event in the network the actions are executed in order of priority in the following
manner:
1) Control is passed to the first application.
2) Some response is received from the first application.
3) Control is passed to the second application.
4) Some response is received from the second application and so on.
In this way a decision about whether to invoke a subsequent application can depend on the output from the previous
application.
If the first application terminates the request then the second application must not be invoked.
The most simple form of cascading is an order based in which the applications are triggered on a single event.
If for example three application "X1" "Y1" and "Z1" need to be t
...

SLOVENSKI STANDARD
01-september-2008
Odprti dostop do storitve (OSA) - Aplikacijski programski vmesnik (API) - 4. del:
Krmiljenje klica - 1. poddel: Splošne definicije krmiljenja klica (Parlay 6)
Open Service Access (OSA) - Application Programming Interface (API) - Part 4: Call
Control - Sub-part 1: Call Control Common Definitions (Parlay 6)
Ta slovenski standard je istoveten z: ES 204 915-4-1 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 1: Call Control Common Definitions
(Parlay 6)
�
2 ETSI ES 204 915-4-1 V1.1.1 (2008-05)

Reference
DES/TISPAN-01032-4-01-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-1 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Call Control SCF.7
4.1 Call Model Description .8
4.2 Structure of Call Control SCF Documentation.8
4.3 General requirements on support of methods.9
4.4 Application Control of a Call or Session.9
4.4.1 Introduction.9
4.4.2 Concept of Multiple Points of Control.9
4.4.2.1 Cascaded Chain Model .9
4.4.3 Service Interactions.11
4.4.4 Multiple services - applicability of MPC for Parlay/OSA .11
5 The Service Interface Specifications.11
5.1 Interface Specification Format .11
5.1.1 Interface Class.11
5.1.2 Method descriptions.12
5.1.3 Parameter descriptions.12
5.1.4 State Model.12
5.2 Base Interface.12
5.2.1 Interface Class IpInterface .12
5.3 Service Interfaces.12
5.3.1 Overview.12
5.4 Generic Service Interface .13
5.4.1 Interface Class IpService .13
5.4.1.1 Method setCallback().13
5.4.1.2 Method setCallbackWithSessionID().13
6 Common Call Control Data Types.14
6.1 TpCallAlertingMechanism.14
6.2 TpCallBearerService.14
6.3 TpCallChargePlan.14
6.4 TpCallPartyToChargeAdditionalInfo.15
6.5 TpCallPartyToChargeType.15
6.6 TpCallChargeOrderCategory.15
6.7 TpCallEndedReport.15
6.8 TpCallError.15
6.9 TpCallAdditionalErrorInfo.16
6.10 TpCallErrorType.16
6.11 TpCallInfoReport.16
6.12 TpCallInfoType.17
6.13 TpCallLoadControlMechanism.17
6.14 TpCallLoadControlIntervalRate.17
6.15 TpCallLoadControlMechanismType.17
6.16 TpCallMonitorMode.17
6.17 TpCallNetworkAccessType.18
6.18 TpCallPartyCategory.18
6.19 TpCallServiceCode.18
6.20 TpCallServiceCodeSet.18
6.21 TpCallServiceCodeType.19
ETSI
4 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
6.22 TpCallSuperviseReport.19
6.23 TpCallSuperviseTreatment.19
6.24 TpCallTeleService.20
6.25 TpCallTreatment.20
6.26 TpCallTreatmentType.20
6.27 TpCallAdditionalTreatmentInfo.21
6.28 TpMediaType.21
Annex A (normative): OMG IDL Description of Common Call Control Data Types.22
Annex B (informative): W3C WSDL Description of Common Call Control Data Types .23
Annex C (informative): Java API Description of the Call Control SCFs.24
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .25
Annex E (informative): Description of Call Control Sub-part 1: Call Control Common
Definitions for 3GPP2 cdma2000 networks.26
E.1 General Exceptions.26
E.2 Specific Exceptions.26
E.2.1 Clause 1: Scope .26
E.2.2 Clause 2: References .26
E.2.3 Clause 3: Definitions and abbreviations.26
E.2.4 Clause 4: Call Control SCF .26
E.2.5 Clause 5: The Service Interface Specifications .26
E.2.6 Clause 6: Common Call Control Data Types .26
E.2.7 Annex A (normative): OMG IDL Description of Common Call Control Data Types .27
E.2.8 Annex B (informative): W3C WSDL Description of Common Call Control Data Types .27
E.2.9 Annex C (informative): Java™ API Description of the Call Control SCFs.27
Annex F (informative): Record of changes .28
F.1 Interfaces.28
F.1.1 New.28
F.1.2 Deprecated.28
F.1.3 Removed.28
F.2 Methods.28
F.2.1 New.28
F.2.2 Deprecated.28
F.2.3 Modified.29
F.2.4 Removed.29
F.3 Data Definitions.29
F.3.1 New.29
F.3.2 Modified.29
F.3.3 Removed.29
F.4 Service Properties.29
F.4.1 New.29
F.4.2 Deprecated.29
F.4.3 Modified.30
F.4.4 Removed.30
F.5 Exceptions.30
F.5.1 New.30
F.5.2 Modified.30
F.5.3 Removed.30
F.6 Others.30
History .31

ETSI
5 ETSI ES 204 915-4-1 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 1 of a multi-part deliverable covering Open Service Access (OSA);
Application Programming Interface (API), as identified below. The API specification (ES 204 915) is structured in the
following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF";
Part 13: "Policy Management SCF";
Part 14: "Presence and Availability Management SCF";
Part 15: "Multi-Media Messaging SCF"
Part 16: "Service Broker SCF".
ETSI
6 ETSI ES 204 915-4-1 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-1 V7.0.0 (Release 7).
ETSI
7 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 1 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 common definitions used by the Call Control Service Capability Features (SCF).
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.
4 Call Control SCF
Four flavours of call control APIs are specified in ES 204 915, Parlay 6. Three of these have been included in 3GPP
Release 6. These are the Generic Call Control (GCC), the Multi-Party Call Control (MPCC) and the Multi-Media Call
Control (MMCC). The generic call control is the same API as was already present in the previous specification for
3GPP Release 99 (TS 129 198 V3). Multi-Party Call Control was introduced in the Release 4 specifications, and Multi-
Media Call Control was introduced in Release 5. All four have been included in ES 201 915, Parlay 3 and ES 202 915,
Parlay 4.
The joint work between 3GPP CN5, ETSI TISPAN and the Parlay Call Control Working group with collaboration from
JAIN has been focussed on the Multi-party and Multi-Media call control APIs. A number of improvements on call
control functionality have been made and are reflected in these APIs. For this it was necessary to break the inheritance
that previously existed between Generic and Multi-party call control.
The joint call control group has furthermore decided that the multi-party call control is to be considered as the future
base call control family and the technical work will not be continued on Generic Call control. Errors or technical flaws
will of course be corrected.
ETSI
8 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
4.1 Call Model Description
The call model used for the Call Control SCFs has the following objects:
• A call object. A call is a relation between a number of parties. The call object relates to the entire call view
from the application. E.g. the entire call will be released when a release is called on the call. Note that different
applications can have different views on the same physical call, e.g. one application for the originating side
and another application for the terminating side. The applications will not be aware of each other, all
'communication' between the applications will be by means of network signalling. The API currently does not
specify any feature interaction mechanisms.
• A call leg object. The leg object represents a logical association between a call and an address. The
relationship includes at least the signalling relation with the party. The relation with the address is only made
when the leg is routed. Before that the leg object is IDLE and not yet associated with the address.
• An address. The address logically represents a party in the call.
• A terminal. A terminal is the end-point of the signalling and/or media for a party. This object type is currently
not addressed.
The call object is used to establish a relation between a number of parties by creating a leg for each party within the
call.
Associated with the signalling relationship represented by the call leg, there may also be a bearer connection (e.g. in the
traditional voice only networks) or a number (zero or more) of media channels (in multi-media networks).
A leg can be attached to the call or detached from the call. When the leg is attached, this means that media or bearer
channels related to the legs are connected to the media or bearer channels of the other legs that are attached to the same
call. I.e. only legs that are attached can 'speak' to each other. A leg can have a number of states, depending on the
signalling received from or sent to the party associated with the leg. Usually there is a limit to the number of legs that
are in being routed (i.e. the connection is being established) or connected to the call (i.e. the connection is established).
Also, there usually is a limit to the number of legs that can be simultaneously attached to the same call.
Some networks distinguish between controlling and passive legs. By definition the call will be released when the
controlling leg is released. All other legs are called passive legs. There can be at most one controlling leg per call.
However, there is currently no way the application can influence whether a Leg is controlling or not.
There are two ways for an application to get the control of a call. The application can request to be notified of calls that
meet certain criteria. When a call occurs in the network that meets these criteria, the application is notified and can
control the call. Some legs will already be associated with the call in this case. Another way is to create a new call from
the application.
4.2 Structure of Call Control SCF Documentation
Each of the Call Control SCFs is specified under the following headings:
• The Sequence diagrams give the reader a practical idea of how each of the SCF is implemented.
• The Class relationships clause shows how each of the interfaces applicable to the SCF, relate to one another.
• The Interface specification clause describes in detail each of the interfaces shown within the Class diagram
part.
• The State Transition Diagrams (STD) show transition between states in the SCF. The states and transitions are
well-defined; either methods specified in the Interface specification or events occurring in the underlying
networks cause state transitions.
• The Data definitions clause shows a detailed expansion of each of the data types associated with the methods
within the classes. Note that some data types are used in other methods and classes and are therefore defined
within the Common Data types part ES 204 915-2.
ETSI
9 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
4.3 General requirements on support of methods
An implementation of one of the call control APIs which supports or implements a method described in one of the
sub-parts of ES 204 915-4, shall support or implement the functionality described for that method, for at least one valid
set of values for the parameters of that method.
Where a method is not supported by an implementation of a Service interface, the exception
P_METHOD_NOT_SUPPORTED shall be returned to any call of that method.
Where a method is not supported by an implementation of an Application interface, a call to that method shall be
possible, and no exception shall be returned.
4.4 Application Control of a Call or Session
4.4.1 Introduction
Services should be provision-able by multiple independent parties and therefore multiple applications may apply control
to the same instance of a call or a session. How this may be enabled is further described in the following.
However, first some reflections on what is meant with application control:
• Single application control may be classified as to allow at the same point in time during call or session
processing only one application to be capable to influence the call or session. This does not exclude more
applications on the same call, but they cannot operate at the same time. This is referred to as "Single point of
Control (SPC)" in IN terminology.
• Multiple application control may be classified as to allow at the same point in time during call or session
processing more than one application to be capable to influence the call or session. This is referred to as
"Multiple Points of Control (MPC)" in IN terminology.
MPC will demand some rules for event handling among multiple applications on a call like the cascaded chain
principle as applied in IN CS3 (ITU-T Recommendation Q.1238-2), where MPC has been introduced.
4.4.2 Concept of Multiple Points of Control
The term "multiple points of control" refers to the situation when multiple concurrently executing applications apply
control to one and the same instance of a call or session.
General Objective:
"If there ismore than one controlling application acting on the same call or session, then the event notification detection
point processing requested by any of the involved applications shall be performed in the same way as if notification
reporting had occurred in different call or session control instances, which are separated by a Network Node interface".
NOTE: The objective description above is taken from ITU-T Recommendation Q.1238-2, but slightly generalized
to become non-IN specific.
The MPC general objective signifies the cascaded chain principle, which is further explained below through an
informative cascaded chain model.
4.4.2.1 Cascaded Chain Model
When services running in different nodes apply control to a call or session, even if they are unaware of each other, they
provide a cascading of applications. They provide a natural ordering of applications. This ordering can be said to be
upstream or downstream. A downstream ordering is the ordering of applications as they are invoked downstream in the
network from the calling party (e.g. origin client, UAC) toward the called party (e.g. destination server, UAS). An
upstream ordering is the ordering of applications as they are invoked upstream in the network from the called party
toward the calling party.
ETSI
10 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
Logically Most Upstream
Appl. Appl. Appl.
request
1 2 3
Downstream
Node
Calling party
Called party
(e.g.SIP Server)
(e.g. UAC)
(e.g. UAS)
Upstream
response
6 5 4
Appl. Appl. Appl.
Logically Most Downstream
Figure 1: Cascaded Chain Model
When applications that apply control to one instance of a call or session are invoked in some order, on the same node,
the applications can be thought of as cascaded.
When a "request" is received then the earlier the application is invoked, based on this event, the more logically
upstream it is considered to be in the chain of cascaded applications. When a response is received then the earlier the
applications is invoked, based on this event, the more logically downstream it is considered to be in the chain of
cascaded applications.
This means that the applications are treated as if they were triggered in different nodes (or hosts). This model is
conceptually simple and may provide a natural algorithm for resolving conflicts between the instructions of multiple
service applications at the same call or session event.
On reception of a call or session event in the network the actions are executed in order of priority in the following
manner:
1) Control is passed to the first application.
2) Some response is received from the first application.
3) Control is passed to the second application.
4) Some response is received from the second application and so on.
In this way a decision about whether to invoke a subsequent application can depend on the output from the previous
application.
If the first application terminates the request then the second application must not be invoked.
The most simple form of cascading is an order based in which the applications are triggered on a single event.
If for example three application "X1" "Y1" and "Z1" need to be triggered on event "e"; then specifying an order say
X1-Y1-Z1 for event e means that first "X1" is contacted and its instructions taken, then the output of this is passed to
"Y1" and finally the output of "Y1" is passed to "Z1". (The letter represents the application and the number an instance
of the application running for a given user.)
How about future events that should invoke the same instances of "X" "Y" and "Z"? For these events there could be a
totally different order, specified say YXZ. It would however be administratively very complex if one has to specify an
order for all instances for all events. Thus a general basic principle may be useful like the cascaded chain for defining a
default ordering in the cases where this is not possible. The actual order depends on whether the event is coming from
the calling party (downstream) or the called party (upstream).
ETSI
11 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
If however a new application A1 should be triggered on "er" then it would be necessary to place this somewhere in the
order. However, a default general assumption can be that event reporting to already invoked applications should have
precedence over the invocation of new applications (see ITU-T Recommendation Q.1238-2).
Anyhow, as a network operator's option any MPC generalized rules specified may be replaced or enhanced by network
operator specific rules.
4.4.3 Service Interactions
A variety of different services, service enablers, and capabilities are being standardized. There are potential feature
interactions among these various services, service enablers, and capabilities.
Conflicts, incompatibilities, or modifications of one feature's characteristics due to interactions with another active
feature need to be resolved in case of multiple services.
In case there are multiple initial notification requests (filter criteria) assigned for one subscriber, a priority describe the
order in which the applications shall be contacted when the call or session encounters an event that matches the initial
filter criteria. Handling of service/application interaction issues to prevent undesired interactions when multi services
are to be supported is outside the scope of the present document. It is the basic assumption that the network operator is
responsible for the provisioning of triggers in the network as in this domain full awareness exists of all other services
and applications.
4.4.4 Multiple services - applicability of MPC for Parlay/OSA
As far as the OSA/Parlay API is concerned a user can choose his clients as he wishes, i.e. the user may subscribe to
more services over the network, each one being to a separate client application, not necessary placed in the same
physical entity.
From an OSA/Parlay gateway side it is a network implementation issue if multiple or single point of control
mechanisms are supported. Multi service support extends the number of applications that can register for notifications.
An example of multi service support network could be an OSA/Parlay Gateway in a UMTS IMS network or IN network
complying with the multiple points of control principle as defined for IN CS3.
Overlapping criteria have been defined for GCCS and MPCCS to prevent multiple points of control, leading to possible
interaction problems. Where Multi service support is provided, the overlap criteria rules as defined to secure single
point of control can be overruled.
5 The Service Interface Specifications
5.1 Interface Specification Format
This clause defines the interfaces, methods and parameters that form a part of the API specification. The Unified
Modelling Language (UML) is used to specify the interface classes. The general format of an interface specification is
described below.
5.1.1 Interface Class
This shows a UML interface class description of the methods supported by that interface, and the relevant parameters
and types. The Service and Framework interfaces for enterprise-based client applications are denoted by classes with
name Ip. The callback interfaces to the applications are denoted by classes with name IpApp. For the
interfaces between a Service and the Framework, the Service interfaces are typically denoted by classes with name
IpSvc, while the Framework interfaces are denoted by classes with name IpFw.
ETSI
12 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
5.1.2 Method descriptions
Each method (API method "call") is described. Both synchronous and asynchronous methods are used in the API.
Asynchronous methods are identified by a 'Req' suffix for a method request, and, if applicable, are served by
asynchronous methods identified by either a 'Res' or 'Err' suffix for method results and errors, respectively. To handle
responses and reports, the application or service developer must implement the relevant IpApp or IpSvc
interfaces to provide the callback mechanism.
5.1.3 Parameter descriptions
Each method parameter and its possible values are described. Parameters described as 'in' represent those that must have
a value when the method is called. Those described as 'out' are those that contain the return result of the method when
the method returns.
5.1.4 State Model
If relevant, a state model is shown to illustrate the states of the objects that implement the described interface.
5.2 Base Interface
5.2.1 Interface Class IpInterface
All application, framework and service interfaces inherit from the following interface. This API Base Interface does not
provide any additional methods.
<>
IpInterface
5.3 Service Interfaces
5.3.1 Overview
The Service Interfaces provide the interfaces into the capabilities of the underlying network - such as call control, user
interaction, messaging, mobility and connectivity management.
The interfaces that are implemented by the services are denoted as 'Service Interface'. The corresponding interfaces that
must be implemented by the application (e.g. for API callbacks) are denoted as 'Application Interface'.
ETSI
13 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
5.4 Generic Service Interface
5.4.1 Interface Class IpService
Inherits from: IpInterface;
All service interfaces inherit from the following interface.
<>
IpService
setCallback (appInterface: in IpInterfaceRef): void
setCallbackWithSessionID (appInterface: in IpInterfaceRef, sessionID: in TpSessionID): void

5.4.1.1 Method setCallback()
This method specifies the reference address of the callback interface that a service uses to invoke methods on the
application. It is not allowed to invoke this method on an interface that uses SessionIDs. Multiple invocations of this
method on an interface shall result in multiple callback references being specified. The SCS shall use the most recent
callback interface provided by the application using this method. In the event that a callback reference fails or is no
longer available, the next most recent callback reference available shall be used.
Parameters
appInterface: in IpInterfaceRef

Specifies a reference to the application interface, which is used for callbacks.
Raises
TpCommonExceptions, P_INVALID_INTERFACE_TYPE

5.4.1.2 Method setCallbackWithSessionID()
This method specifies the reference address of the application's callback interface that a service uses for interactions
associated with a specific session ID: e.g. a specific call, or call leg. It is not allowed to invoke this method on an
interface that does not use SessionIDs. Multiple invocations of this method on an interface shall result in multiple
callback references being specified. The SCS shall use the most recent callback interface provided by the application
using this method. In the event that a callback reference fails or is no longer available, the next most recent callback
reference available shall be used.
Parameters
appInterface: in IpInterfaceRef

Specifies a reference to the application interface, which is used for callbacks.
sessionID: in TpSessionID
Specifies the session for which the service can invoke the application's callback interface.
Raises
TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_INTERFACE_TYPE

ETSI
14 ETSI ES 204 915-4-1 V1.1.1 (2008-05)
6 Common Call Control Data Types
The following data types referenced in this clause are defined in ES 204 915-5:
TpUIInfo
All other data types referenced in the present document but not defined in this clause are common data definitions
which may be found in ES 204 915-2.
6.1 TpCallAlertingMechanism
This data type is identical to a TpInt32, and defines the mechanism that will be used to alert a call party. The values of
this data type are operator specific.
6.2 TpCallBearerService
This data type defines the type of call application-related specific information (ITU-T Recommendation Q.931:
Information Transfer Capability, and TS 122 002).
Name Value Description
P_CALL_BEARER_SERVICE_UNKNOWN 0 Bearer capability information unknown at
this time
P_CALL_BEARER_SERVICE_SPEECH 1 Speech
P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTED 2 Unrestricted digital information
P_CALL_BEARER_SERVICE_DIGITALRESTRICTED 3 Restricted digital information
P_CALL_BEARER_SERVICE_AUDIO 4 3,1 kHz audio
P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTEDTONES 5 Unrestricted digital information with
tones/announcements
P_CALL_BEARER_SERVICE_VIDEO 6 Video

6.3 TpCallChargePlan
Defines the Sequence of Data Elements that specify the charge plan for the call.
Sequence Element Name Sequence Element Type Description
ChargeOrderType TpCallChargeOrderCategory Charge order
TransparentCharge TpOctetSet Operator specific charge plan specification,
e.g. charging table name / charging table
entry. The associated charge plan data will be
sent transparently to the charging records.
Only applicable when transparent charging is
selected.
ChargePlan TpInt32 Pre-defined charge plan. Example of the
charge plan set from which the application can
choose could be: (0 = normal user, 1 = silver
card user, 2 = gold card user).
Only applicable when predefined charge plan
is selected.
AdditionalInfo TpOctetSet Descriptive string which is sent to the billing
system without prior evaluation. Could be
included in the ticket.
PartyToCharge TpCallPartyToChargeType Identifies the entity or party to be charged for
the call or call leg.
PartyToChargeAdditionalInf
...