SIST ES 201 915-5 V1.4.1:2005

• Abstract:

  Maintenance update of ES 201 915-5 v.1.3.1. Updated document will also be known as Parlay 3.3. 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 201 915-5 V1.4.1 (2003-07) - Open Service Access (OSA); Application Programming Interface (API); Part 5: User Interaction SCF (Parlay 3)

SIST ES 201 915-5 V1.4.1:2005 is the Slovenian adoption of ETSI ES 201 915-5 for Open Service Access (OSA) Application Programming Interface (API), Part 5: User Interaction SCF (Parlay 3). It specifies how applications interact with end users through network services, including announcements, user input collection, call-related interaction, notifications, and message handling. It is written for developers, service providers, and integrators who implement OSA interfaces or build applications that use them.

What does SIST ES 201 915-5 V1.4.1:2005 specify?

SIST ES 201 915-5 V1.4.1:2005 specifies the User Interaction Service Capability Feature (SCF) part of the OSA API. The document defines the service in terms of sequence diagrams, class diagrams, interface specifications, state transition diagrams, data definitions, and the IDL description of the interfaces.

The scope also states that this is a maintenance update of ES 201 915-5 v1.3.1 and that the updated document is also known as Parlay 3.3. The structure of the document is shown by its clauses and annexes.

Annex	What it covers
Annex A	Normative OMG IDL description of the User Interaction SCF
Annex B	Informative contents of 3GPP OSA R4 User Interaction
Annex C	Informative record of changes

The main clauses run from Scope and References through Definitions, the Generic and Call User Interaction SCF, Sequence Diagrams, Class Diagrams, Service Interface Specifications, Interface Classes, State Transition Diagrams, Service Properties, Data Definitions, and Exception Classes.

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

Method support and fallback behavior

Clause 4.1 sets the basic implementation rule: if an implementation supports a method from this document, it shall support the defined functionality for at least one valid parameter set. This matters in practice because partial support is allowed, but the supported case must work as specified.

The same clause also separates service-side and application-side behavior. If a service interface method is not supported, the service shall return P_METHOD_NOT_SUPPORTED. If an application interface method is not supported, a call to that method shall still be possible and no exception shall be returned.

Callback registration and session handling

Clause 7.4 defines IpService, which provides setCallback() and setCallbackWithSessionID(). The first registers a callback interface for general use, while the second links the callback to a specific session such as a call or call leg.

This distinction matters when an application must keep events tied to the correct user interaction instance. The document also states that setCallback() shall not be used on interfaces that use SessionIDs, and setCallbackWithSessionID() shall not be used on interfaces that do not use SessionIDs.

User Interaction manager functions

Clause 8.1 defines IpUIManager as the service manager for Generic User Interaction. It is responsible for creating UI objects for non-call interaction, UICall objects for call-related interaction, and notification subscriptions through createNotification().

The document requires at least one of these support patterns in a Generic User Interaction SCF: createUI(), createUICall(), or both createNotification() and destroyNotification(). In practice, that means a service can support interactive prompts, call-bound interaction, or event notification, but must clearly implement the chosen entry points.

createNotification() uses event criteria based on addresses and service code. Overlapping criteria are refused with P_INVALID_CRITERIA, so implementations must manage notification subscriptions carefully to avoid duplicate or conflicting event definitions.

Core user interaction operations

Clause 8.3 defines IpUI, which is the main interface for sending information to the user or collecting information from the user. The minimum required methods are release() and at least one of sendInfoReq() or sendInfoAndCollectReq().

sendInfoReq() can deliver predefined content, text, or a URL-based payload, together with language and variable information. sendInfoAndCollectReq() adds collection criteria such as minimum and maximum length, end character, start timeout, and inter-character timeout. In practice, this is the part to use for announcements, menus, PIN collection, and similar interactive prompts.

Call-related interaction

Clause 8.5 defines IpUICall, which inherits from IpUI and adds recordMessageReq(), deleteMessageReq(), and abortActionReq(). This interface is for interaction with a user or call party attached to a call or call leg, and the document says it is used only together with another service that can connect a call leg to a user, currently Call Control.

This matters for services such as in-call announcements, recorded messages, and call-leg-specific interaction. The call-related methods let an application store a message for later playback, remove a stored message, or cancel an ongoing user interaction without otherwise affecting the call.

States, faults, and release behavior

Clauses 9.1 to 9.3 define Active, Release Pending, and Finished states for IpUIManager, IpUI, and IpUICall. They show when an object can accept requests, when it is waiting for outstanding work to complete, and when it is finished and only release remains possible.

The diagrams also show that faults and termination events trigger userInteractionFaultDetected() or userInteractionAborted() where appropriate. In practice, implementers need to free resources when the object is no longer needed and handle network or call termination as a normal part of the lifecycle.

Service properties and capability limits

Clause 10 defines service properties such as P_INFO_TYPE, P_TRIGGERING_ADDRESSES, and P_SERVICE_CODE. These describe what a User Interaction service supports and what a service-level agreement may restrict.

This is important for deployment and integration work because it tells an operator or buyer what kinds of content can be sent and which addresses or service codes may be used for triggering notifications.

What terms does SIST ES 201 915-5 V1.4.1:2005 define?

IpUIManager is the service manager interface that creates user interaction objects and manages notification criteria.

IpUI is the generic user interaction interface used to send information to a user or collect information from a user.

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

TpUICollectCriteria defines the collection rules for user input, including minimum length, maximum length, end sequence, and timeouts.

TpUIEventCriteria defines the address and service-code conditions for receiving a user interaction notification.

TpUIResponseRequest tells the service whether a response is required, whether the request is the last announcement in a row, or whether it is the final request.

TpUIReport is the report returned after a response is requested, such as information sent, information collected, timeout, or message stored.

TpUIFault identifies the cause of a user interaction fault, including the case where the related call has ended.

Who uses SIST ES 201 915-5 V1.4.1:2005?

SIST ES 201 915-5 V1.4.1:2005 is used by telecom application developers, network platform engineers, and gateway implementers who need a standard way to interact with end users over a network. It is also relevant to system integrators and QA teams that test user prompts, input collection, prepaid call control, call barring, and notification handling.

In practice, the standard fits services that need to play announcements, collect PINs or menu choices, react to call events, or send event-driven messages to subscribers.

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

This version is a maintenance update of ES 201 915-5 v1.3.1 and is also known as Parlay 3.3. The scope states that only the parts requiring modification were updated, and most parts received maintenance fixes.

Annex C records the named changes for this version. It states that reportEventNotification() replaces the deprecated reportNotification(), TpUIEventNotificationInfo was added, and TpUIInfo and TpUIInfoType were extended with InfoBinData and P_UI_INFO_BIN_DATA.

Which standards are used with SIST ES 201 915-5 V1.4.1:2005?

ETSI ES 201 915-1 provides the overview part of the OSA API and supplies the terms and abbreviations used by this part.

ETSI ES 201 915-2 provides common data definitions used where this document refers to shared types that are not defined here.

ETSI ES 201 915-4 provides the call-related identifier types used in this part, including TpCallIdentifier, TpMultiPartyCallIdentifier, and TpCallLegIdentifier.

The foreword also states that this document is equivalent to 3GPP TS 29.198-5 V4.6.0 (Release 4).

What does the SIST ES 201 915-5 V1.4.1:2005 document contain?

SIST ES 201 915-5 V1.4.1:2005 contains worked service examples in the form of sequence diagrams for Alarm Call, Call Barring, Prepaid, and Pre-Paid with Advice of Charge (AoC). It also includes class diagrams, interface specifications, state transition diagrams, service properties, detailed data definitions, and exception classes.

Table 1 and Table 2 map methods to the Generic User Interaction and Call User Interaction interfaces, while Figure 1 gives the package overview. Figures 2 to 4 show application views of the UI Manager, UI object, and UICall object states, which helps implementers understand when requests, callbacks, and releases occur.

Annex A provides the OMG IDL text for implementation use, and Annex C lists the changed, deprecated, added, and removed items for this version.

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

Reference
RES/SPAN-120095-5
Keywords
API, OSA, IDL, 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 201 915-5 V1.4.1 (2003-07)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.6
2 References.6
3 Definitions and abbreviations.6
3.1 Definitions.6
3.2 Abbreviations.6
4 Generic and Call User Interaction SCF.6
4.1 General requirements on support of methods.8
5 Sequence Diagrams.8
5.1 Alarm Call.8
5.2 Call Barring 1 .10
5.3 Prepaid.11
5.4 Pre-Paid with Advice of Charge (AoC).13
6 Class Diagrams.16
7 The Service Interface Specifications.17
7.1 Interface Specification Format .17
7.1.1 Interface Class.17
7.1.2 Method descriptions.17
7.1.3 Parameter descriptions.17
7.1.4 State Model.17
7.2 Base Interface.17
7.2.1 Interface Class IpInterface .17
7.3 Service Interfaces.18
7.3.1 Overview.18
7.4 Generic Service Interface .18
7.4.1 Interface Class IpService .18
8 Generic User Interaction Interface Classes .19
8.1 Interface Class IpUIManager .19
8.2 Interface Class IpAppUIManager.22
8.3 Interface Class IpUI.25
8.4 Interface Class IpAppUI.27
8.5 Interface Class IpUICall.29
8.6 Interface Class IpAppUICall .31
9 State Transition Diagrams.34
9.1 State Transition Diagrams for IpUIManager.34
9.1.1 Active State.34
9.1.2 Notification Terminated State.35
9.2 State Transition Diagrams for IpUI.35
9.2.1 Active State.35
9.2.2 Release Pending State.35
9.2.3 Finished State.35
9.3 State Transition Diagrams for IpUICall .36
9.3.1 Active State.36
9.3.2 Release Pending State.36
9.3.3 Finished State.37
10 Service Properties.37
10.1 User Interaction Service Properties .37
11 Data Definitions.37
11.1 TpUIFault.37
ETSI
4 ETSI ES 201 915-5 V1.4.1 (2003-07)
11.2 IpUI.37
11.3 IpUIRef.38
11.4 IpAppUI.38
11.5 IpAppUIRef.38
11.6 IpAppUIManager.38
11.7 IpAppUIManagerRef.38
11.8 TpUICallIdentifier.38
11.9 TpUICollectCriteria.38
11.10 TpUIError.39
11.11 TpUIEventCriteria.39
11.12 TpUIEventCriteriaResultSet.40
11.13 TpUIEventCriteriaResult.40
11.14 TpUIEventInfo.40
11.15 TpUIEventInfoDataType.40
11.16 TpUIIdentifier.40
11.17 TpUIInfo.41
11.18 TpUIInfoType.41
11.19 TpUIMessageCriteria.41
11.20 TpUIReport.42
11.21 TpUIResponseRequest.42
11.22 TpUITargetObjectType.42
11.23 TpUITargetObject.42
11.24 TpUIVariableInfo.43
11.25 TpUIVariableInfoSet.43
11.26 TpUIVariablePartType.43
11.27 TpUIEventNotificationInfo.43
12 Exception Classes.44
Annex A (normative): OMG IDL Description of User Interaction SCF.45
Annex B (informative): Contents of 3GPP OSA R4 User Interaction.46
Annex C (informative): Record of changes .47
C.1 Interfaces.47
C.1.1 New.47
C.1.2 Deprecated.47
C.1.3 Removed.47
C.2 Methods.47
C.2.1 New.47
C.2.2 Deprecated.47
C.2.3 Modified.48
C.2.4 Removed.48
C.3 Data Definitions.48
C.3.1 New.48
C.3.2 Modified.48
C.3.3 Removed.48
C.4 Service Properties.48
C.4.1 New.48
C.4.2 Deprecated.49
C.4.3 Modified.49
C.4.4 Removed.49
C.5 Exceptions.49
C.5.1 New.49
C.5.2 Modified.49
C.5.3 Removed.49
C.6 Others.49
History .50
ETSI
5 ETSI ES 201 915-5 V1.4.1 (2003-07)

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 201 915) is structured in the following
parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "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".
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 3.3 set of specifications.
The present document is equivalent to 3GPP TS 29.198-5 V4.6.0 (Release 4).
ETSI
6 ETSI ES 201 915-5 V1.4.1 (2003-07)
1 Scope
The present document is part 5 of the Stage 3 specification for an Application Programming Interface (API) for Open
Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardised interface, i.e. the OSA APIs.
The present document specifies the 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
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 201 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 201 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 3)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 201 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations defined in ES 201 915-1 apply.
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.
ETSI
7 ETSI ES 201 915-5 V1.4.1 (2003-07)
The Generic User Interaction service capability feature is described in terms of the methods in the Generic User
Interaction interfaces.
Table 1 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
Table 2 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).
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 of this specification.
ETSI
8 ETSI ES 201 915-5 V1.4.1 (2003-07)
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
9 ETSI ES 201 915-5 V1.4.1 (2003-07)
: (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 ev ent'
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
10 ETSI ES 201 915-5 V1.4.1 (2003-07)
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.
ETSI
11 ETSI ES 201 915-5 V1.4.1 (2003-07)
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.
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 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
12 ETSI ES 201 915-5 V1.4.1 (2003-07)
:
Prepaid : (Logical : IpAppCall : IpAppUICall : IpCall : : IpUIManager : IpUICall
IpAppCallControlManager
View::IpAppLogic) IpCallControlManager
1: new()
2: enableCallNotification( )
3: callEventNotify(  )
4: "forward event"
5: new()
6: superviseCallReq(  )
7: routeReq(    )
8: superviseCallRes(  )
9: "forward event"
10: s uperviseC al lR eq(  )
11: s uperviseCallRes(  )
12: "forward event"
13: s uperviseC 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( )
1: This message is used by the application to create an object implementing the IpAppCallControlManager
interface.
ETSI
13 ETSI ES 201 915-5 V1.4.1 (2003-07)
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 terminates the call after the next supervision period.
22: The supervision period ends
23: The event is forwarded to the logic.
24: The application terminates the call. Since the user interaction is already explicitly terminated no
userInteractionFaultDetected is sent to the application.
5.4 Pre-Paid with Advice of Charge (AoC)
This sequence shows a Pre-paid application that uses the Advice of Charge feature. The application will send the
charging information before the actual call setup and when during the call the charging changes new information is sent
in order to update the end-user. Note that the Advice of Charge feature requires an application in the end-user terminal
to display the charges for the call, depending on the information received from the application.
ETSI
14 ETSI ES 201 915-5 V1.4.1 (2003-07)
Prepaid : (Logical : : IpAppCall : IpAppUICall : : IpCall : IpUIManager : IpUICall
Vi ew::IpAppLogic) IpAppCallControlManager IpCallControlManager
1: new()
2: enableCallNotification( )
3: callEventNotify(  )
4: "forward event"
5: new()
6: setAdviceOfCharge(  )
7: superviseCallReq(  )
8: routeReq(    )
9: superviseCallRes(  )
10: "forward event"
11: superviseCallReq(  )
12: supervis eCallRes(  )
13: "forward event"
14: setAdviceOfCharge(  )
15: superviseCallReq(  )
16: superviseCallRes(  )
17: "forward event"
18: new()
19: createUICall( )
20: new()
21: sendInfoReq(   )
22: sendInfoRes(  )
23: "forward event"
24: superviseCallReq(  )
25: superviseCallRes(  )
26: "forward event:
27: release( )
28: userInteractionFaultDetected( )

1: This message is used by the application to create an object implementing the IpAppCallControlManager
interface.
ETSI
15 ETSI ES 201 915-5 V1.4.1 (2003-07)
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 Call object is created
6: The Pre-Paid Application (PPA) sends the AoC information (e.g. the tariff switch time). (it shall be noted the
PPA contains ALL the tariff information and knows how to charge the user).
During this call sequence 2 tariff changes take place. The call starts with tariff 1, and at the tariff switch time
(e.g. 18:00 hours) switches to tariff 2. The application is not informed about this (but the end-user is!)
7: 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.
8: The application requests to route the call to the destination address.
9: At the end of each supervision period the application is informed and a new period is started.
10: The message is forwarded to the application.
11: The Pre-Paid Application (PPA) requests to supervise the call for another call duration.
12: At the end of each supervision period the application is informed and a new period is started.
13: The message is forwarded to the application.
14: Before the next tariff switch (e.g., 19:00 hours) the application sends a new AOC with the tariff switch time.
Again, at the tariff switch time, the network will send AoC information to the end-user.
15: 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.
16: When the user is almost out of credit the application is informed.
17: The message is forwarded to the application.
18: The application creates a new call back interface for the User interaction messages.
19: A new UI Call object that will handle playing of the announcement needs to be created
20: The Gateway creates a new UI call object that will handle playing of the announcement.
21: With this message the announcement is played to the parties in the call.
22: The user indicates that the call should continue.
23: The message is forwarded to the application.
24: The user does not terminate so the application terminates the call after the next supervision period.
25: The user is out of credit and the application is informed.
26: The message is forwarded to the application.
27: With this message the application requests to release the call.
ETSI
16 ETSI ES 201 915-5 V1.4.1 (2003-07)
28: Terminating the call which has still a UICall object associated will result in a userInteractionFaultDetected.
The UICall object is terminated in the gateway and no further communication is possible between the UICall
and the application.
6 Class Diagrams
The application generic user interaction service package consists of one IpAppUIManager interface, zero or more
IpAppUI interfaces and zero or more IpAppUICall interfaces.
The generic user interaction service package consists of one IpUIManager interface, zero or more IpUI interfaces and
zero or more IpUICall interfaces.
The class diagram in the following figure shows the interfaces that make up the application generic user interaction
service package and the generic user interaction service package. Communication between these packages is done via
the <> relationships.
The IpUICall implements call related user interaction and it inherits from the non call related IpUI interface. The same
holds for the corresponding application interfaces.
<>
IpInterface
<>
<> <>
IpAppUICall
IpAppUIManager IpAppUI
recordMessageRes()
userInteractionAborted() sendInfoRes()
recordMessageErr()
<> reportNotification() sendInfoErr()
deleteMessageRes()
userInteractionNotificationInterrupted() sendInfoAndCollectRes()
deleteMessageErr()
userInteractionNotificationContinued() sendInfoAndCollectErr()
abortActionRes()
<> reportEventNotification() userInteractionFaultDetected()
abortActionErr()
<>
<>
<>
<>
IpUIManager
<> <>
IpUI IpUICall
createUI()
createUICall()
sendInfoReq() recordMessageReq()
createNotification()
sendInfoAndCollectReq() deleteMessageReq()
destroyNotification()
release() abortActionReq()
changeNotification()
getNotification()
<>
IpService
setCallback()
setCallbackWithSessionID()
Figure 1: Generic User Interaction Package Overview
ETSI
17 ETSI ES 201 915-5 V1.4.1 (2003-07)
7 The Service Interface Specifications
7.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 o
...