SIST ES 202 915-5 V1.2.1:2005

• Abstract:

  Maintenance update of ES 202 915-5 V1.1.1 to produce ES 202 915-5 V1.2.1 Updated document will also be known as PARLAY 4.1. Only those parts requiring modification will be updated ( most parts require maintenance fixes )

• 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-5 V1.2.1 (2003-08) - Open Service Access (OSA); Application Programming Interface (API); Part 5: User Interaction SCF (Parlay 4)

SIST ES 202 915-5 V1.2.1:2005 is the Slovenian standard identical to ETSI ES 202 915-5 V1.2.1, titled Open Service Access (OSA); Application Programming Interface (API); Part 5: User Interaction SCF (Parlay 4). It specifies the User Interaction Service Capability Feature (SCF) for OSA APIs, so application developers can interact with end users through network services such as announcements, input collection, call-related prompts, notifications, and message recording.

What does SIST ES 202 915-5 V1.2.1:2005 specify?

SIST ES 202 915-5 V1.2.1:2005 specifies the User Interaction SCF part of the OSA API. The document is written for an open standardised interface between applications and network functionality, and it describes the service from the application side and the network side.

The standard is organized around the User Interaction feature in several forms of description:

• sequence diagrams
• class diagrams
• interface specifications and method descriptions
• state transition diagrams
• data definitions
• OMG IDL description
• W3C WSDL description
• reference to the Java API description

The foreword places this part within the multi-part ES 202 915 series. The part is also identified as part of the Parlay 4.1 set of specifications and as equivalent to 3GPP TS 29.198-5 V5.2.0 (Release 5).

Annex	What it covers
Annex A	OMG IDL description of User Interaction SCF
Annex B	W3C WSDL description of User Interaction SCF
Annex C	Java API description of User Interaction SCF
Annex D	Contents of 3GPP OSA R4 User Interaction
Annex E	Record of changes

What are the key requirements of SIST ES 202 915-5 V1.2.1:2005?

SIST ES 202 915-5 V1.2.1:2005 defines how applications create, use, and release User Interaction objects, how callbacks are handled, and how call-related and non-call-related user interaction is modeled. In practice, this is the part that tells a developer what objects exist, which methods they must support, and how the application learns about results, errors, and faults.

Interface structure and minimum support

Clause 4 defines three functional areas:

• User Interaction Manager for management functions
• Generic User Interaction for interaction with an end user
• Call User Interaction for interaction with an end user engaged in a call

Clause 4.1 says that if an implementation supports a method, it shall support the described functionality for at least one valid set of parameter values. If a service interface method is not supported, the implementation returns P_METHOD_NOT_SUPPORTED. If an application interface method is not supported, the call shall still be possible and no exception is returned. In practice, this tells implementers how to handle partial support without breaking the API model.

Callback handling and session binding

Clause 7.4 defines IpService with setCallback() and setCallbackWithSessionID(). These methods bind the service to an application callback interface, either generally or for a specific TpSessionID. In practice, this is how the service knows where to send responses, reports, and faults.

Generic User Interaction management

Clause 8.1 defines IpUIManager. It provides:

• createUI() for non-call interaction
• createUICall() for call-related interaction
• createNotification() and destroyNotification() for notification criteria
• changeNotification() and getNotification() for notification management
• enableNotifications() and disableNotifications() for network-provisioned notifications

The standard says that a Generic User Interaction SCF shall implement IpUIManager with at least one of these support patterns: createUI(), createUICall(), notification creation/destruction, or notification enabling/disabling. For a buyer or integrator, this means the service can be deployed in different capability levels, but at least one interaction path must be available.

Clause 8.1 also defines criteria handling. Overlapping notification criteria are refused with P_INVALID_CRITERIA, and network-provisioned notifications use the most recent callback reference if multiple callbacks are set. That matters when the same application manages several notification streams or changes callback endpoints.

User interaction requests and responses

Clause 8.3 defines IpUI for sending information to a user or collecting information from a user. sendInfoReq() plays an announcement or sends information, while sendInfoAndCollectReq() also gathers user input. Both use TpUIInfo, TpLanguage, variable information, and response control. release() ends the relationship between the application and the user interaction object.

Clause 8.4 defines IpAppUI, which receives responses such as sendInfoRes(), sendInfoErr(), sendInfoAndCollectRes(), sendInfoAndCollectErr(), and userInteractionFaultDetected(). In practice, this is the callback side that the application must implement to know whether the user heard the message, entered input, or encountered a fault.

Call-related interaction

Clause 8.5 defines IpUICall, which extends IpUI and adds recordMessageReq(), deleteMessageReq(), and abortActionReq(). These methods are used for call legs or call-related user interaction, such as announcements to a party in a call. Clause 8.6 defines the matching callback interface IpAppUICall.

The state diagrams in clause 9 show that a UI object, a UICall object, or a notification manager can move through Active, Release Pending, and Finished states. The diagrams also show that call termination or user interaction faults can trigger userInteractionFaultDetected() and error reporting on outstanding requests. In practice, this gives implementers a clear lifecycle model for resource handling.

Service properties and data constraints

Clause 10 lists service properties such as P_INFO_TYPE, P_TRIGGERING_ADDRESSES, and P_SERVICE_CODE. These properties describe what the service supports and what Service Level Agreement restrictions can apply. Clause 11 then defines the data types used by the methods, including TpUIInfo, TpUICollectCriteria, TpUIMessageCriteria, TpUIEventCriteria, and TpUIReport. These definitions matter because they control how announcements are described, how input is collected, and how notifications are classified.

What terms does SIST ES 202 915-5 V1.2.1:2005 define?

User Interaction SCF is the service capability feature that lets applications interact with end users through the OSA API.

IpUIManager is the service manager interface for User Interaction; it creates user interaction objects and manages notifications.

IpUI is the non-call user interaction interface used to send information to, or collect information from, an end user.

IpUICall is the call-related user interaction interface used when the user is attached to a call or call leg.

IpAppUI is the application callback interface that receives responses, errors, and fault reports for IpUI.

TpUIInfo is the tagged choice that describes what information will be sent to the user, such as an ID, text, URL, or binary data.

TpUICollectCriteria is the structure that sets collection rules such as minimum and maximum length, end sequence, and timeouts.

AoC means Advice of Charge, the feature used in the prepaid examples to send charging information to the end user.

Who uses SIST ES 202 915-5 V1.2.1:2005?

SIST ES 202 915-5 V1.2.1:2005 is used by application developers, service platform developers, and integrators working with telecom network APIs. It is relevant when an application must play announcements, collect user input, record or delete messages, manage call-related interaction, or subscribe to network-provisioned notifications.

It also serves system architects and buyers who need to check whether a network service exposes the User Interaction functions they plan to use. The sequence diagrams show common application patterns such as alarm calls, call barring with PIN entry, prepaid supervision, and prepaid with Advice of Charge.

What changed in SIST ES 202 915-5 V1.2.1:2005 from the previous edition?

SIST ES 202 915-5 V1.2.1:2005 is a maintenance update of ES 202 915-5 V1.1.1. The changes recorded for the Parlay 4.1 version include:

• IpAppUIManager.reportEventNotification() replaces reportNotification()
• IpAppUIManager.reportNotification() is deprecated
• IpUIManager.getNotification() no longer has the P_INVALID_CRITERIA exception
• TpUIEventNotificationInfo is added
• TpUIInfoType adds P_UI_INFO_BIN_DATA
• TpUIInfo adds InfoBinData
• Annex B WSDL description is new
• Annex C Java API description is new

The document also states that it updates only the parts requiring modification and that most parts receive maintenance fixes.

Which standards are used with SIST ES 202 915-5 V1.2.1:2005?

Clause 2 names the standards that provide provisions for this part:

• ETSI ES 202 915-1 - overview, and the source of shared definitions and abbreviations
• ETSI ES 202 915-2 - common data definitions used by this and other parts
• ETSI ES 202 915-4-2 - Generic Call Control SCF, used for call-related data such as TpCallIdentifier
• ETSI ES 202 915-4-3 - Multi-Party Call Control SCF, used for multi-party call and call-leg data types

The foreword also places this part within the wider ES 202 915 series, alongside parts for call control, mobility, terminal capabilities, data session control, messaging, connectivity management, account management, charging, policy management, and presence and availability management. Those parts frame how User Interaction fits into the broader OSA API family.

What does the SIST ES 202 915-5 V1.2.1:2005 document contain?

The document contains the full interface model for User Interaction SCF, including UML-based class definitions, method descriptions, and state models. It also contains practical sequence diagrams for alarm delivery, call barring, network-controlled notifications, prepaid service, and prepaid with Advice of Charge.

It defines the callback model, service properties, and the data structures used for user prompts, input collection, event notifications, message recording, and error reporting. Annex A gives the OMG IDL form, Annex B the WSDL form, and Annex C points to the Java API representation.

Annex D links the content to 3GPP OSA R4 User Interaction. Annex E lists the changed, deprecated, added, and removed interfaces, methods, data definitions, service properties, exceptions, and other items across releases.

SLOVENSKI STANDARD
01-januar-2005
Odprti dostop do storitve (OSA) – Vmesnik za aplikacijsko programiranje (API) – 5.
del: Medsebojno vplivanje uporabnikov SCF
Open Service Access (OSA); Application Programming Interface (API); Part 5: User
Interaction SCF (Parlay 4)
Ta slovenski standard je istoveten z: ES 202 915-5 Version 1.2.1
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 5: User Interaction SCF
(Parlay 4)
�
2 ETSI ES 202 915-5 V1.2.1 (2003-08)

Reference
RES/SPAN-120096-5
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-5 V1.2.1 (2003-08)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 Generic and Call User Interaction SCF.8
4.1 General requirements on support of methods.9
5 Sequence Diagrams.9
5.1 Alarm Call.9
5.2 Call Barring 1 .11
5.3 Network Controlled Notifications .12
5.4 Prepaid.13
5.5 Pre-Paid with Advice of Charge (AoC).15
6 Class Diagrams.18
7 The Service Interface Specifications.19
7.1 Interface Specification Format .19
7.1.1 Interface Class.19
7.1.2 Method descriptions.19
7.1.3 Parameter descriptions.19
7.1.4 State Model.19
7.2 Base Interface.19
7.2.1 Interface Class IpInterface .19
7.3 Service Interfaces.20
7.3.1 Overview.20
7.4 Generic Service Interface .20
7.4.1 Interface Class IpService .20
7.4.1.1 Method setCallback().20
7.4.1.2 Method setCallbackWithSessionID().20
8 Generic User Interaction Interface Classes .21
8.1 Interface Class IpUIManager .21
8.1.1 Method createUI().21
8.1.2 Method createUICall().22
8.1.3 Method createNotification().22
8.1.4 Method destroyNotification().23
8.1.5 Method changeNotification().23
8.1.6 Method getNotification().24
8.1.7 Method <> enableNotifications().24
8.1.8 Method <> disableNotifications().25
8.2 Interface Class IpAppUIManager.25
8.2.1 Method userInteractionAborted().25
8.2.2 Method <> reportNotification() .25
8.2.3 Method userInteractionNotificationInterrupted().26
8.2.4 Method userInteractionNotificationContinued().26
8.2.5 Method <> reportEventNotification().26
8.3 Interface Class IpUI.27
8.3.1 Method sendInfoReq().27
8.3.2 Method sendInfoAndCollectReq().28
8.3.3 Method release().29
8.4 Interface Class IpAppUI.29
ETSI
4 ETSI ES 202 915-5 V1.2.1 (2003-08)
8.4.1 Method sendInfoRes().30
8.4.2 Method sendInfoErr().30
8.4.3 Method sendInfoAndCollectRes().30
8.4.4 Method sendInfoAndCollectErr().31
8.4.5 Method userInteractionFaultDetected().31
8.5 Interface Class IpUICall.31
8.5.1 Method recordMessageReq().32
8.5.2 Method deleteMessageReq().32
8.5.3 Method abortActionReq().33
8.6 Interface Class IpAppUICall .33
8.6.1 Method recordMessageRes().33
8.6.2 Method recordMessageErr().34
8.6.3 Method deleteMessageRes().34
8.6.4 Method deleteMessageErr().34
8.6.5 Method abortActionRes().35
8.6.6 Method abortActionErr().35
9 State Transition Diagrams.36
9.1 State Transition Diagrams for IpUIManager.36
9.1.1 Active State.36
9.1.2 Notification Terminated State.36
9.2 State Transition Diagrams for IpUI.37
9.2.1 Active State.37
9.2.2 Release Pending State.37
9.2.3 Finished State.37
9.3 State Transition Diagrams for IpUICall .38
9.3.1 Active State.38
9.3.2 Release Pending State.38
9.3.3 Finished State.39
10 Service Properties.39
10.1 User Interaction Service Properties .39
11 Data Definitions.39
11.1 TpUIFault.39
11.2 IpUI.39
11.3 IpUIRef.40
11.4 IpAppUI.40
11.5 IpAppUIRef.40
11.6 IpAppUIManager.40
11.7 IpAppUIManagerRef.40
11.8 TpUICallIdentifier.40
11.9 TpUICollectCriteria.40
11.10 TpUIError.41
11.11 TpUIEventCriteria.42
11.12 TpUIEventCriteriaResultSet.42
11.13 TpUIEventCriteriaResult.42
11.14 TpUIEventInfo.42
11.15 TpUIEventInfoDataType.42
11.16 TpUIIdentifier.43
11.17 TpUIInfo.43
11.18 TpUIInfoType.43
11.19 TpUIMessageCriteria.43
11.20 TpUIReport.44
11.21 TpUIResponseRequest.44
11.22 TpUITargetObjectType.44
11.23 TpUITargetObject.45
11.24 TpUIVariableInfo.45
11.25 TpUIVariableInfoSet.45
11.26 TpUIVariablePartType.45
11.27 TpUIEventNotificationInfo.46
12 Exception Classes.46
ETSI
5 ETSI ES 202 915-5 V1.2.1 (2003-08)
Annex A (normative): OMG IDL Description of User Interaction SCF.47
Annex B (informative): W3C WSDL Description of User Interaction SCF .48
Annex C (informative): Java API Description of User Interaction SCF.49
Annex D (informative): Contents of 3GPP OSA R4 User Interaction.50
Annex E (informative): Record of changes .51
E.1 Interfaces.51
E.1.1 New.51
E.1.2 Deprecated.51
E.1.3 Removed.51
E.2 Methods.51
E.2.1 New.51
E.2.2 Deprecated.52
E.2.3 Modified.52
E.2.4 Removed.52
E.3 Data Definitions.52
E.3.1 New.52
E.3.2 Modified.52
E.3.3 Removed.53
E.4 Service Properties.53
E.4.1 New.53
E.4.2 Deprecated.53
E.4.3 Modified.53
E.4.4 Removed.53
E.5 Exceptions.54
E.5.1 New.54
E.5.2 Modified.54
E.5.3 Removed.54
E.6 Others.54
History .55

ETSI
6 ETSI ES 202 915-5 V1.2.1 (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 5 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";
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".
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-5 V5.2.0 (Release 5).
ETSI
7 ETSI ES 202 915-5 V1.2.1 (2003-08)
1 Scope
The present document is part 4 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 User Interaction (UI) Service Capability Feature (SCF) aspects of the interface. All
aspects of the User Interaction 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-2: "Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control;
Sub-part 2: Generic Call Control SCF (Parlay 4)".
ETSI ES 202 915-4-3: "Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control;
Sub-part 3: Multi-Party Call Control SCF (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
8 ETSI ES 202 915-5 V1.2.1 (2003-08)
4 Generic and Call User Interaction SCF
The Generic User Interaction service capability feature is used by applications to interact with end users. It consists of
three interfaces:
1) User Interaction Manager, containing management functions for User Interaction related issues;
2) Generic User Interaction, containing methods to interact with an end-user.
3) Call User Interaction, containing methods to interact with an end-user engaged in a call.
The Generic User Interaction service capability feature is described in terms of the methods in the Generic User
Interaction interfaces.
The following table gives an overview of the Generic User Interaction methods and to which interfaces these methods
belong.
Table 1: Overview of Generic User Interaction interfaces and their methods
User Interaction Manager Generic User Interaction
createUI sendInfoReq
createUICall sendInfoRes
createNotification sendInfoErr
destroyUINotification sendInfoAndCollectReq
reportNotification sendInfoAndCollectRes
userInteractionAborted sendInfoAndCollectErr
userInteractionNotificationInterrupted release
userInteractionNotificationContinued UserInteractionFaultDetected
changeNotification
getNotification
enableNotifications
disableNotifications
The following table gives an overview of the Call User Interaction methods and to which interfaces these methods
belong.
Table 2: Overview of Call User Interaction interfaces and their methods
User Interaction Manager Call User Interaction
As defined for the Generic User Interaction SCF Inherits from Generic User Interaction and adds:
recordMessageReq
recordMessageRes
recordMessageErr
deleteMessageReq
deleteMessageRes
deleteMessageErr
abortActionReq
abortActionRes
abortActionErr
The IpUI Interface provides functions to send information to, or gather information from the user, i.e. this interface
allows applications to send SMS and USSD messages. An application can use this interface independently of other
SCFs. The IpUICall Interface provides functions to send information to, or gather information from the user (or call
party) attached to a call.
The following clauses describe each aspect of the Generic User Interaction Service Capability Feature (SCF).
ETSI
9 ETSI ES 202 915-5 V1.2.1 (2003-08)
The order is as follows:
• The Sequence diagrams give the reader a practical idea of how each of the SCFs is implemented.
• The Class relationships clause show 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. This clause also includes Call User interaction.
• The State Transition Diagrams (STD) show the 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 show 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 202 915-2.
4.1 General requirements on support of methods
An implementation of this API which supports or implements a method described in the present document, 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.
5 Sequence Diagrams
5.1 Alarm Call
The following sequence diagram shows a 'reminder message', in the form of an alarm, being delivered to a customer as
a result of a trigger from an application. Typically, the application would be set to trigger at a certain time, however, the
application could also trigger on events.
ETSI
10 ETSI ES 202 915-5 V1.2.1 (2003-08)
: (Logical : IpAppCall : : : IpCall : IpUIManager : IpUICall
View::IpAppLogic) IpAppUICall IpCallControlManager
1: new()
2: createCall( )
3: new()
4: routeReq(    )
5: routeRes(  )
6: 'forward event'
7: createUICall( )
8: new()
9: sendInf oReq(   )
10: sendInfoRes(  )
11: 'f orward event'
12: release( )
13: release( )
1: This message is used to create an object implementing the IpAppCall interface.
2: This message requests the object implementing the IpCallControlManager interface to create an object
implementing the IpCall interface.
3: Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load control values not
exceeded) are met it is created.
4: This message instructs the object implementing the IpCall interface to route the call to the customer destined to
receive the 'reminder message'
5: This message passes the result of the call being answered to its callback object.
6: This message is used to forward the previous message to the IpAppLogic.
7: The application requests a new UICall object that is associated with the call object.
8: Assuming all criteria are met, a new UICall object is created by the service.
9: This message instructs the object implementing the IpUICall interface to send the alarm to the customer's call.
10: When the announcement ends this is reported to the call back interface.
11: The event is forwarded to the application logic.
ETSI
11 ETSI ES 202 915-5 V1.2.1 (2003-08)
12: The application releases the UICall object, since no further announcements are required. Alternatively, the
application could have indicated P_FINAL_REQUEST in the sendInfoReq in which case the UICall object would have
been implicitly released after the announcement was played.
13: The application releases the call and all associated parties.
5.2 Call Barring 1
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 accepted and the call is routed to the original called party.
: (Logical : : IpAppCall : : : IpCall : : IpUICall
View::IpAppLogic) IpAppCallControlManager IpAppUICall IpCallControlManager IpUIManager
1: new()
2: enableCallNotification( )
3: callEventNotify(  )
4: 'forward event'
5: new()
6: createUICall( )
7: new()
8: sendInfoAndCollectReq(   )
9: sendInfoAndCollectRes(  )
10: 'forward event'
11: release( )
12: routeReq(    )
13: routeRes(  )
14: 'forward event'
15: callEnded( )
16: "forward event"
17: deas si gn Cal l( )
1: This message is used by the application to create an object implementing the IpAppCallControlManager 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 set, arrives, a
message (not shown) is directed to the object implementing the IpCallControlManager. Assuming that the criteria for
creating an object implementing the IpCall interface (e.g. load control values not exceeded) are 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 IpAppCallControlManager interface.
4: This message is used to forward the previous message to the IpAppLogic.
ETSI
12 ETSI ES 202 915-5 V1.2.1 (2003-08)
5: This message is used by the application to create an object implementing the IpAppCall interface. The reference to
this object is passed back to the object implementing the IpCallControlManager using the return parameter of the
callEventNotify.
6: This message is used to create a new UICall object. The reference to the call object is given when creating the
UICall.
7: Provided all the criteria are fulfilled, a new UICall object is created.
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: This message releases the UICall object.
12: Assuming the correct PIN is entered, the call is forward routed to the destination party.
13: This message passes the result of the call being answered to its callback object.
14: This message is used to forward the previous message to the IpAppLogic
15: When the call is terminated in the network, the application will receive a notification. This notification will always
be received when the call is terminated by the network in a normal way, the application does not have to request this
event explicitly.
16: The event is forwarded to the application.
17: The application must free the call related resources in the gateway by calling deassignCall.
5.3 Network Controlled Notifications
The following sequence diagram shows how an application can receive notifications that have not been created by the
application, but are provisioned from within the network.
AppLogic : IpAppUIManager : IpUIManager
1: new ()
2: enableNotifications( )
3: reportNotification(  )
4: 'forward event'
5: reportNotification(  )
6: 'forward event'
7: disableNotifications( )
ETSI
13 ETSI ES 202 915-5 V1.2.1 (2003-08)
1: The application is started. The application creates a new IpAppUIManager to handle callbacks.
2: The enableNotifications method is invoked on the IpUIManager interface to indicate that the application is ready to
receive notifications that are created in the network. For illustrative purposes we assume notifications of type "B" are
created in the network.
3: When a network created trigger occurs the application is notified on the callback interface.
4: The event is forwarded to the application.
5: When a network created trigger occurs the application is notified on the callback interface.
6: The event is forwarded to the application.
7: When the application does not want to receive notifications created in the network anymore, it invokes
disableNotifications on the IpMultiPartyCallConrolManager interface. From now on the gateway will not send any
notifications to the application that are created in the network.
5.4 Prepaid
This sequence shows a Pre-paid application. The subscriber is using a pre-paid card or credit card to pay for the call.
The application each time allows a certain timeslice for the call. After the timeslice, a new timeslice can be started or
the application can terminate the call. In the following sequence the end-user will received an announcement before his
final timeslice.
ETSI
14 ETSI ES 202 915-5 V1.2.1 (2003-08)
Prepaid : (Logical : IpAppCall : : IpAppUICall : IpCall : : IpUIManager : IpUICall
View::IpAppLogic) IpAppCallControlManager IpCallControlManager
1: new()
2: enableCallNotification( )
3: callEventNotify(  )
4: "forward event"
5: new()
6: superviseCallReq(  )
7: routeReq(    )
8: superviseCallRes(  )
9: "forward event"
10: s uper vis eC al lR eq(  )
11: s uperviseCallRes(  )
12: "forward event"
13: s uper vis eC al lR eq(  )
14: superviseCallRes(  )
15: "forward event"
16: createUICall( )
17: sendInfoReq(   )
18: sendInfoRes(  )
19: "forward event"
20: release( )
21: superviseCallReq(  )
22: superviseCallRes(  )
23: "forward event:
24: release( )
ETSI
15 ETSI ES 202 915-5 V1.2.1 (2003-08)
1: This message is used by the application to create an object implementing the IpAppCallControlManager interface.
2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts
a pre-paid service, it is likely that only new call events within a certain address range will be enabled. When a new call,
that matches the event criteria, arrives a message (not shown) is directed to the object implementing the
IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load
control values not exceeded) are met, other messages (not shown) are used to create the call and associated call leg
object.
3: The incoming call triggers the Pre-Paid Application (PPA).
4: The message is forwarded to the application.
5: A new object on the application side for the Generic Call object is created
6: The Pre-Paid Application (PPA) requests to supervise the call. The application will be informed after the period
indicated in the message. This period is related to the credits left on the account of the pre-paid subscriber.
7: Before continuation of the call, PPA sends all charging information, a possible tariff switch time and the call
duration supervision period, towards the GW which forwards it to the network.
8: At the end of each supervision period the application is informed and a new period is started.
9: The message is forwarded to the application.
10: The Pre-Paid Application (PPA) requests to supervise the call for another call duration.
11: At the end of each supervision period the application is informed and a new period is started.
12: The message is forwarded to the application.
13: The Pre-Paid Application (PPA) requests to supervise the call for another call duration. When the timer expires it
will indicate that the user is almost out of credit.
14: When the user is almost out of credit the application is informed.
15: The message is forwarded to the application.
16: The application decides to play an announcement to the parties in this call. A new UICall object is created and
associated with the call.
17: An announcement is played informing the user about the near-expiration of his credit limit.
18: When the announcement is completed the application is informed.
19: The message is forwarded to the application.
20: The application releases the UICall object.
21: The user does not terminate so the application terminat
...