SIST ES 204 915-4-2 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 2 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 Generic Call Control Service Capability Feature (SCF) aspects of the interface. All aspects of the Generic Call Control SCF are defined here, these being:; • Sequence Diagrams.; • Class Diagrams.; • Interface specification plus detailed method descriptions.; • State Transition diagrams.; • Data Definitions.; • IDL Description of the interfaces.; • WSDL Description of the interfaces.; • Reference to the Java™ API description of the interfaces.; The process by which this task is accomplished is through the use of object modelling techniques described by the Unified Modelling Language (UML).

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

SIST ES 204 915-4-2 V1.1.1:2008 is an ETSI Standard for Open Service Access (OSA) Application Programming Interface (API), Part 4, Sub-part 2: Generic Call Control Service Capability Feature (SCF) (Parlay 6). It specifies the Generic Call Control SCF interface that lets application developers use network call-control functions through an open standardised interface, using UML-based sequence diagrams, class diagrams, state transition diagrams, data definitions, IDL, WSDL and Java API references. It is aimed at people implementing or assessing OSA call control support in service platforms and network applications.

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

SIST ES 204 915-4-2 V1.1.1:2008 specifies the Stage 3 interface for the Generic Call Control SCF in OSA. The document covers how an application can create, route, supervise, release and deassign calls, and how the network reports events back to the application through callbacks.

The scope also places the document in the wider OSA Phase 4 family, which incorporates 3GPP OSA Release 7 and is also known as Parlay 6.0. The Generic Call Control service is a basic call-control service with a third-party model: calls can be instantiated from the network and routed through it.

The document is organised into clauses for scope, references, definitions and abbreviations, sequence diagrams, class diagrams, interface classes, state transition diagrams, service properties and data definitions. It also includes annexes for interface descriptions and change information.

Annex	What it covers
Annex A	OMG IDL description of the Generic Call Control SCF
Annex B	W3C WSDL description of the Generic Call Control SCF
Annex C	Java API description of the Call Control SCFs
Annex D	Contents of 3GPP OSA Rel-7 Call Control
Annex E	Generic call control SCF for 3GPP2 cdma2000 networks
Annex F	Record of changes

The generic call control service is limited to two-party calls. It does not give explicit access to call legs and media channels; those are handled by the Multi-Party Call Control Service and related parts.

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

Service-side and application-side interfaces

Clause 6 defines two service-side interfaces, IpCallControlManager and IpCall, and two application-side callback interfaces, IpAppCallControlManager and IpAppCall. In practice, this means the service must provide a controlled way to create calls and notify applications, while the application must provide callback logic to receive reports, errors and state changes.

IpCallControlManager is the service manager interface. Clause 6.1 says it handles overload control, call creation and event notification control. As a minimum, the implementation shall provide either createCall() or the pair enableCallNotification() and disableCallNotification(), so a platform must support at least one of those entry paths.

IpCall is the call-control interface. Clause 6.3 says it is used to route calls, request call information, control charging, supervise a call, release it and deassign it. As a minimum, routeReq(), release() and deassignCall() shall be implemented, so a conforming service needs a basic call-routing path and cleanup path.

Call events, callbacks and session correlation

Clause 6.2 defines callback methods such as callEventNotify(), callAborted(), callNotificationInterrupted() and callNotificationContinued(). The callback model matters because call control is asynchronous: the application does not wait inside the request, but instead receives reports later.

The document also explains that repeated notification requests with the same criteria can be treated as additional callbacks. If one callback reference is unavailable, the service uses the most recent available one. In practice, this supports applications that run in multiple instances or need failover behaviour.

callEventNotify() carries the call reference, event information and assignment identifier. That lets the application correlate a network event with the criteria that enabled it, which is important for routing decisions, charging decisions and troubleshooting.

Routing, supervision and user interaction

Clause 6.3 includes routeReq(), setCallChargePlan(), setAdviceOfCharge(), getCallInfoReq(), getMoreDialledDigitsReq(), superviseCallReq() and continueProcessing(). These methods cover the main call-control tasks - routing the call, querying status, shaping charging behaviour and supervising call duration.

The sequence diagrams in Clause 4 show how these methods are used in practice. They cover examples such as alarm call, application initiated call, call barring, several number translation cases, prepaid control and prepaid with Advice of Charge (AoC). These examples matter because they show the order of messages and the points where the application must decide to continue, reroute, announce, release or deassign the call.

State behaviour and service properties

Clause 7 defines state transition diagrams for IpCallControlManager and IpCall. In practice, this tells an implementer when callbacks are possible, when a call is active, when notification is terminated, and how the object behaves after network release, application release or other call-end events.

Clause 8 defines service properties that describe the service capability profile, including supported triggering event types, dynamic event types, address plans, user interaction support and media type. It also defines SLA-style properties such as notification address ranges, notification types, monitor mode, numbers that may be changed and charging-plan permissions. For an operator or integrator, these properties determine which application behaviours the platform will accept.

Clause 8.2 gives the service-property values for the CAMEL Service Environment. That section is the practical profile to check when matching a CAMEL phase 4 implementation to this specification.

What terms does SIST ES 204 915-4-2 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 service layer feature defined by the API, such as Generic Call Control.
• Unified Modelling Language (UML) - the modelling notation used for the sequence diagrams, class diagrams and state diagrams in this document.
• Interface Definition Language (IDL) - the formal interface description used in Annex A to describe the API bindings.
• Web Services Description Language (WSDL) - the web-service interface description given in Annex B.
• Advice of Charge (AoC) - the charging information exchanged so that the end-user can be informed about call charges.
• Generic Call Control Service (GCCS) - the basic call-control service defined by the document.

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

The main users are application developers, service-platform developers and network gateway implementers working on OSA call-control functions. Quality managers and testers use it to check that a platform supports the required callback patterns, routing behaviour and service properties.

It is also relevant to operators and integrators configuring event notifications, call supervision and charging-related behaviour. Annex E extends the interpretation to developers working in 3GPP2 cdma2000 network environments.

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

• ETSI ES 204 915-1 - provides the overview, common definitions, abbreviations and the references that apply to this part.
• ETSI ES 204 915-2 - supplies common data definitions for types that are not defined in this document.
• ETSI ES 204 915-4-1 - supplies common call control data definitions referenced by the Generic Call Control data model.
• ES 203 915 - is the base document cited as the starting point for the Phase 4 work.
• 3GPP TS 29.198-4-2 V7.0.0 (Release 7) - is the equivalent 3GPP release-7 specification named in the foreword.

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

The document contains worked service examples in Clause 4, including additional callbacks, alarm call, application initiated call, call barring, number translation variants and prepaid call control. These examples show the order of request, response and callback messages used in real call-control flows.

It also contains class diagrams, interface class descriptions and detailed method descriptions for the service and application sides. Clause 7 adds state transition diagrams so implementers can see how the call and manager objects move through active, released and terminated states.

Clause 8 contains service-property tables, including the CAMEL Service Environment profile. Clause 9 contains the data definitions that support the interface, and Annexes A to C give IDL, WSDL and Java API representations for implementation work.

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

Reference
DES/TISPAN-01032-4-02-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-2 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.8
2 References.8
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.8
4 Generic Call Control Service Sequence Diagrams.9
4.1 Additional Callbacks.9
4.2 Alarm Call.10
4.3 Application Initiated Call .12
4.4 Call Barring 1 .14
4.5 Number Translation 1.16
4.6 Number Translation 1 (with callbacks) .17
4.7 Number Translation 2.19
4.8 Number Translation 3.21
4.9 Number Translation 4.23
4.10 Number Translation 5.25
4.11 Prepaid.26
4.12 Pre-Paid with Advice of Charge (AoC).28
5 Class Diagrams.31
6 Generic Call Control Service Interface Classes .32
6.1 Interface Class IpCallControlManager.33
6.1.1 Method createCall().33
6.1.2 Method enableCallNotification().34
6.1.3 Method disableCallNotification().35
6.1.4 Method setCallLoadControl().35
6.1.5 Method changeCallNotification().36
6.1.6 Method getCriteria().36
6.2 Interface Class IpAppCallControlManager .37
6.2.1 Method callAborted().37
6.2.2 Method callEventNotify().37
6.2.3 Method callNotificationInterrupted().38
6.2.4 Method callNotificationContinued().38
6.2.5 Method callOverloadEncountered().39
6.2.6 Method callOverloadCeased().39
6.2.7 Method abortMultipleCalls().39
6.3 Interface Class IpCall .39
6.3.1 Method routeReq().40
6.3.2 Method release().41
6.3.3 Method deassignCall().41
6.3.4 Method getCallInfoReq().42
6.3.5 Method setCallChargePlan().42
6.3.6 Method setAdviceOfCharge().42
6.3.7 Method getMoreDialledDigitsReq().43
6.3.8 Method superviseCallReq().43
6.3.9 Method continueProcessing().43
6.4 Interface Class IpAppCall .44
6.4.1 Method routeRes().44
6.4.2 Method routeErr().45
6.4.3 Method getCallInfoRes().45
6.4.4 Method getCallInfoErr().45
6.4.5 Method superviseCallRes().46
ETSI
4 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
6.4.6 Method superviseCallErr().46
6.4.7 Method callFaultDetected().46
6.4.8 Method getMoreDialledDigitsRes().47
6.4.9 Method getMoreDialledDigitsErr().47
6.4.10 Method callEnded().47
7 Generic Call Control Service State Transition Diagrams.48
7.1 State Transition Diagrams for IpCallControlManager .48
7.1.1 Active State.48
7.1.2 Notification terminated State .48
7.2 State Transition Diagrams for IpCall.49
7.2.1 Network Released State .49
7.2.2 Finished State.49
7.2.3 Application Released State.49
7.2.4 No Parties State.50
7.2.5 Active State.50
7.2.6 1 Party in Call State .50
7.2.7 2 Parties in Call State.50
7.2.8 Routing to Destination(s) State.51
8 Generic Call Control Service Properties .51
8.1 List of Service Properties .51
8.2 Service Property values for the CAMEL Service Environment .52
9 Generic Call Control Data Definitions.53
9.1 Generic Call Control Event Notification Data Definitions.53
9.1.1 TpCallEventName.53
9.1.2 TpCallNotificationType.54
9.1.3 TpCallEventCriteria.54
9.1.4 TpCallEventInfo.54
9.2 Generic Call Control Data Definitions .54
9.2.1 IpCall.54
9.2.2 IpCallRef.54
9.2.3 IpAppCall.55
9.2.4 IpAppCallRef.55
9.2.5 TpCallIdentifier.55
9.2.6 IpAppCallControlManager.55
9.2.7 IpAppCallControlManagerRef.55
9.2.8 IpCallControlManager.55
9.2.9 IpCallControlManagerRef.55
9.2.10 TpCallAppInfo.55
9.2.11 TpCallAppInfoType.56
9.2.12 TpCallAppInfoSet.56
9.2.13 TpCallEndedReport.56
9.2.14 TpCallFault.56
9.2.15 TpCallInfoReport.57
9.2.16 TpCallReleaseCause.57
9.2.17 TpCallReport.57
9.2.18 TpCallAdditionalReportInfo.58
9.2.19 TpCallReportRequest.58
9.2.20 TpCallAdditionalReportCriteria.58
9.2.21 TpCallReportRequestSet.58
9.2.22 TpCallReportType.59
9.2.23 TpCallTreatment.59
9.2.24 TpCallEventCriteriaResultSet.59
9.2.25 TpCallEventCriteriaResult.59
Annex A (normative): OMG IDL Description of Generic Call Control SCF.60
Annex B (informative): W3C WSDL Description of Generic Call Control SCF .61
Annex C (informative): Java™ API Description of the Call Control SCFs.62
ETSI
5 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .63
Annex E (informative): Description of Call Control Sub-part 2: Generic call control SCF for
3GPP2 cdma2000 networks .64
E.1 General Exceptions.64
E.2 Specific Exceptions.64
E.2.1 Clause 1: Scope .64
E.2.2 Clause 2: References .64
E.2.3 Clause 3: Definitions and abbreviations.64
E.2.4 Clause 4: Generic Call Control Service Sequence Diagrams .64
E.2.5 Clause 5: Class Diagrams.64
E.2.6 Clause 6: Generic Call Control Service Interface Classes.64
E.2.7 Clause 7: Generic Call Control Service State Transition Diagrams .65
E.2.8 Clause 8: Generic Call Control Service Properties.65
E.2.9 Clause 9: Generic Call Control Data Definitions .65
E.2.10 Annex A (normative): OMG IDL Description of Generic Call Control SCF .65
E.2.11 Annex B (informative): W3C WSDL Description of Generic Call Control SCF.65
E.2.12 Annex C (informative): Java™ API Description of the Call Control SCFs.65
Annex F (informative): Record of changes .66
F.1 Interfaces.66
F.1.1 New.66
F.1.2 Deprecated.66
F.1.3 Removed.66
F.2 Methods.66
F.2.1 New.66
F.2.2 Deprecated.66
F.2.3 Modified.67
F.2.4 Removed.67
F.3 Data Definitions.67
F.3.1 New.67
F.3.2 Modified.67
F.3.3 Removed.67
F.4 Service Properties.67
F.4.1 New.67
F.4.2 Deprecated.67
F.4.3 Modified.68
F.4.4 Removed.68
F.5 Exceptions.68
F.5.1 New.68
F.5.2 Modified.68
F.5.3 Removed.68
F.6 Others.68
History .69

ETSI
6 Final draft ETSI ES 204 915-4-2 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 2 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
7 Final draft ETSI ES 204 915-4-2 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-2 V7.0.0 (Release 7).
ETSI
8 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
1 Scope
The present document is part 4, sub-part 2 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 Generic Call Control Service Capability Feature (SCF) aspects of the interface. All
aspects of the Generic Call Control SCF are defined here, these being:
• Sequence Diagrams.
• Class Diagrams.
• Interface specification plus detailed method descriptions.
• State Transition diagrams.
• Data Definitions.
• IDL Description of the interfaces.
• WSDL Description of the interfaces.
• Reference to the Java™ API description of the interfaces.
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 204 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 204 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 6)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 204 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 204 915-1 apply.
ETSI
9 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
4 Generic Call Control Service Sequence Diagrams
4.1 Additional Callbacks
The following sequence diagram shows how an application can register two call back interfaces for the same set of
events. If one of the call backs can not be used, e.g. because the application crashed, the other call back interface is used
instead.
first instance : (Logical : IpAppCallControlManager second instance : : IpAppCal lControlMan ager : IpCallControlManager
View::IpAppLogic) (Logic.
1: new()
2: enableCallNotification( )
3: new()
4: enableCallNotification( )
5: callEventNotify(  )
6: 'forward event'
7: "call Notify result: failure"
8: callEventNotify(  )
9: "forward event"
1: The first instance of the application is started on node 1. The application creates a new
IpAppCallControlManager to handle callbacks for this first instance of the logic.
2: The enableCallNotification is associated with an applicationID. The call control manager uses the
applicationID to decide whether this is the same application.
3: The second instance of the application is started on node 2. The application creates a new
IpAppCallControlManager to handle callbacks for this second instance of the logic.
4: The same enableCallNotification request is sent as for the first instance of the logic. Because both requests are
associated with the same application, the second request is not rejected, but the specified callback object is
stored as an additional callback.
5: When the trigger occurs one of the first instance of the application is notified. The gateway may have different
policies on how to handle additional callbacks, e.g. always first try the first registered or use some kind of
round robin scheme.
6: The event is forwarded to the first instance of the logic.
ETSI
10 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
7: When the first instance of the application is overloaded or unavailable this is communicated with an exception
to the call control manager.
8: Based on this exception the call control manager will notify another instance of the application (if available).
9: The event is forwarded to the second instance of the logic.
4.2 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.
: (Logical : IpAppCall : : : IpCall : : IpUICall
View::IpAppLogic) IpAppUICall IpCallControlManager IpAppUIManager
1: new()
2: createCall( )
3: new()
4: routeReq(    )
5: routeRes(  )
6: 'f orward ev ent'
7: createUICall()
8: new()
9: sendInf oReq(   )
10: sendInf oRes(  )
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) is 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".
ETSI
11 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
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.
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.
ETSI
12 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
4.3 Application Initiated Call
The following sequence diagram shows an application creating a call between party A and party B. This sequence could
be done after a customer has accessed a Web page and selected a name on the page of a person or organisation to talk
to.
: (Logical : IpAppCall : : IpCall
View::IpAppLo. IpCallControlManager
1: new()
2: createCall( )
3: new()
4: routeReq(    )
5: routeRes(  )
6: 'forward event'
7: routeReq(    )
8: routeRes(  )
9: 'forward event'
10: deassignCall( )
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) is met, it is created.
ETSI
13 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
4: This message is used to route the call to the A subscriber (origination). In the message the application request
response when the A party answers.
5: This message indicates that the A party answered the call.
6: This message forwards the previous message to the application logic.
7: This message is used to route the call to the B-party. Also in this case a response is requested for call answer
or failure.
8: This message indicates that the B-party answered the call. The call now has two parties and a speech
connection is automatically established between them.
9: This message is used to forward the previous message to the IpAppLogic.
10: Since the application is no longer interested in controlling the call, the application deassigns the call. The call
will continue in the network, but there will be no further communication between the call object and the
application.
ETSI
14 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
4.4 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 : IpAppCallControlManager : IpAppCall : : : IpCall : : IpUICall
View::IpAppLogic) 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: 'forw ard even t'
15: callEnded( )
16: "forward event"
17: d eass i gnC all ( )
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) is met, other messages (not shown) are used to create the call and associated call leg object.
3: This message is used to pass the new call event to the object implementing the 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.
ETSI
15 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
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.
ETSI
16 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
4.5 Number Translation 1
The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event
being received by the call control service.
: (Logical : IpAppCallControlManager : IpAppCall : : IpCall
View::IpAppLo. IpCallControlManager
1: new()
2: enableCallNotification( )
3: callEventNotify(  )
4: 'forward event'
5: new()
6: 'translate number'
7: routeReq(    )
8: routeRes(  )
9: 'forward event'
10: deassignCall( )
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 number translation 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 set in message 2, 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) is met, other messages (not
shown) are used to create the call and associated call leg object.
ETSI
17 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
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 message 3 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 message 3.
6: This message invokes the number translation function.
7: The returned translated number is used in message 7 to route the call towards the destination.
8: This message passes the result of the call being answered to its callback object.
9: This message is used to forward the previous message to the IpAppLogic.
10: The application is no longer interested in controlling the call and therefore deassigns the call. The call will
continue in the network, but there will be no further communication between the call object and the
application.
4.6 Number Translation 1 (with callbacks)
The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event
being received by the call control service.
For illustration, in this sequence the callback references are set explicitly. This is optional. All the callbacks references
can also be passed in other methods. From an efficiency point of view that is also the preferred method. The rest of the
sequences use that mechanism.
ETSI
18 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
: (Logical : IpAppCallControlManager : IpAppCall : : IpCall
View::IpAppLogic) IpCallControlManager
1: new()
2: setCallback( )
3: enableCallNotification( )
4: callEventNotify(  )
5: 'forward event'
6: new()
7: setCallbackWithSessionID( )
8: 'translate number'
9: routeReq(    )
10: routeRes(  )
11: 'forward event'
12: deassignCall( )
1: This message is used by the application to create an object implementing the IpAppCallControlManager
interface.
2: This message sets the reference of the IpAppCallControlManager object in the CallControlManager. The
CallControlManager reports the callEventNotify to referenced object only for enableCallNotifications that do
not have an explicit IpAppCallControlManager reference specified in the enableCallNotification.
ETSI
19 Final draft ETSI ES 204 915-4-2 V1.1.1 (2008-02)
3: This message is sent by the application to enable notifications on new call events. As this sequence diagram
depicts a number translation 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 set in message 3, 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) is met, other mess
...

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

Reference
DES/TISPAN-01032-4-02-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-2 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.8
2 References.8
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.8
4 Generic Call Control Service Sequence Diagrams.9
4.1 Additional Callbacks.9
4.2 Alarm Call.10
4.3 Application Initiated Call .12
4.4 Call Barring 1 .14
4.5 Number Translation 1.16
4.6 Number Translation 1 (with callbacks) .17
4.7 Number Translation 2.19
4.8 Number Translation 3.21
4.9 Number Translation 4.23
4.10 Number Translation 5.25
4.11 Prepaid.26
4.12 Pre-Paid with Advice of Charge (AoC).28
5 Class Diagrams.31
6 Generic Call Control Service Interface Classes .32
6.1 Interface Class IpCallControlManager.33
6.1.1 Method createCall().33
6.1.2 Method enableCallNotification().34
6.1.3 Method disableCallNotification().35
6.1.4 Method setCallLoadControl().35
6.1.5 Method changeCallNotification().36
6.1.6 Method getCriteria().36
6.2 Interface Class IpAppCallControlManager .37
6.2.1 Method callAborted().37
6.2.2 Method callEventNotify().37
6.2.3 Method callNotificationInterrupted().38
6.2.4 Method callNotificationContinued().38
6.2.5 Method callOverloadEncountered().39
6.2.6 Method callOverloadCeased().39
6.2.7 Method abortMultipleCalls().39
6.3 Interface Class IpCall .39
6.3.1 Method routeReq().40
6.3.2 Method release().41
6.3.3 Method deassignCall().41
6.3.4 Method getCallInfoReq().42
6.3.5 Method setCallChargePlan().42
6.3.6 Method setAdviceOfCharge().42
6.3.7 Method getMoreDialledDigitsReq().43
6.3.8 Method superviseCallReq().43
6.3.9 Method continueProcessing().43
6.4 Interface Class IpAppCall .44
6.4.1 Method routeRes().44
6.4.2 Method routeErr().45
6.4.3 Method getCallInfoRes().45
6.4.4 Method getCallInfoErr().45
6.4.5 Method superviseCallRes().46
ETSI
4 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
6.4.6 Method superviseCallErr().46
6.4.7 Method callFaultDetected().46
6.4.8 Method getMoreDialledDigitsRes().47
6.4.9 Method getMoreDialledDigitsErr().47
6.4.10 Method callEnded().47
7 Generic Call Control Service State Transition Diagrams.48
7.1 State Transition Diagrams for IpCallControlManager .48
7.1.1 Active State.48
7.1.2 Notification terminated State .48
7.2 State Transition Diagrams for IpCall.49
7.2.1 Network Released State .49
7.2.2 Finished State.49
7.2.3 Application Released State.49
7.2.4 No Parties State.50
7.2.5 Active State.50
7.2.6 1 Party in Call State .50
7.2.7 2 Parties in Call State.50
7.2.8 Routing to Destination(s) State.51
8 Generic Call Control Service Properties .51
8.1 List of Service Properties .51
8.2 Service Property values for the CAMEL Service Environment .52
9 Generic Call Control Data Definitions.53
9.1 Generic Call Control Event Notification Data Definitions.53
9.1.1 TpCallEventName.53
9.1.2 TpCallNotificationType.54
9.1.3 TpCallEventCriteria.54
9.1.4 TpCallEventInfo.54
9.2 Generic Call Control Data Definitions .54
9.2.1 IpCall.54
9.2.2 IpCallRef.54
9.2.3 IpAppCall.55
9.2.4 IpAppCallRef.55
9.2.5 TpCallIdentifier.55
9.2.6 IpAppCallControlManager.55
9.2.7 IpAppCallControlManagerRef.55
9.2.8 IpCallControlManager.55
9.2.9 IpCallControlManagerRef.55
9.2.10 TpCallAppInfo.55
9.2.11 TpCallAppInfoType.56
9.2.12 TpCallAppInfoSet.56
9.2.13 TpCallEndedReport.56
9.2.14 TpCallFault.56
9.2.15 TpCallInfoReport.57
9.2.16 TpCallReleaseCause.57
9.2.17 TpCallReport.57
9.2.18 TpCallAdditionalReportInfo.58
9.2.19 TpCallReportRequest.58
9.2.20 TpCallAdditionalReportCriteria.58
9.2.21 TpCallReportRequestSet.58
9.2.22 TpCallReportType.59
9.2.23 TpCallTreatment.59
9.2.24 TpCallEventCriteriaResultSet.59
9.2.25 TpCallEventCriteriaResult.59
Annex A (normative): OMG IDL Description of Generic Call Control SCF.60
Annex B (informative): W3C WSDL Description of Generic Call Control SCF .61
Annex C (informative): Java™ API Description of the Call Control SCFs.62
ETSI
5 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .63
Annex E (informative): Description of Call Control Sub-part 2: Generic call control SCF for
3GPP2 cdma2000 networks .64
E.1 General Exceptions.64
E.2 Specific Exceptions.64
E.2.1 Clause 1: Scope .64
E.2.2 Clause 2: References .64
E.2.3 Clause 3: Definitions and abbreviations.64
E.2.4 Clause 4: Generic Call Control Service Sequence Diagrams .64
E.2.5 Clause 5: Class Diagrams.64
E.2.6 Clause 6: Generic Call Control Service Interface Classes.64
E.2.7 Clause 7: Generic Call Control Service State Transition Diagrams .65
E.2.8 Clause 8: Generic Call Control Service Properties.65
E.2.9 Clause 9: Generic Call Control Data Definitions .65
E.2.10 Annex A (normative): OMG IDL Description of Generic Call Control SCF .65
E.2.11 Annex B (informative): W3C WSDL Description of Generic Call Control SCF.65
E.2.12 Annex C (informative): Java™ API Description of the Call Control SCFs.65
Annex F (informative): Record of changes .66
F.1 Interfaces.66
F.1.1 New.66
F.1.2 Deprecated.66
F.1.3 Removed.66
F.2 Methods.66
F.2.1 New.66
F.2.2 Deprecated.66
F.2.3 Modified.67
F.2.4 Removed.67
F.3 Data Definitions.67
F.3.1 New.67
F.3.2 Modified.67
F.3.3 Removed.67
F.4 Service Properties.67
F.4.1 New.67
F.4.2 Deprecated.67
F.4.3 Modified.68
F.4.4 Removed.68
F.5 Exceptions.68
F.5.1 New.68
F.5.2 Modified.68
F.5.3 Removed.68
F.6 Others.68
History .69

ETSI
6 ETSI ES 204 915-4-2 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 2 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
7 ETSI ES 204 915-4-2 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-2 V7.0.0 (Release 7).
ETSI
8 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 2 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 Generic Call Control Service Capability Feature (SCF) aspects of the interface. All
aspects of the Generic Call Control SCF are defined here, these being:
• Sequence Diagrams.
• Class Diagrams.
• Interface specification plus detailed method descriptions.
• State Transition diagrams.
• Data Definitions.
• IDL Description of the interfaces.
• WSDL Description of the interfaces.
• Reference to the Java™ API description of the interfaces.
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 204 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 204 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 6)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 204 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 204 915-1 apply.
ETSI
9 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4 Generic Call Control Service Sequence Diagrams
4.1 Additional Callbacks
The following sequence diagram shows how an application can register two call back interfaces for the same set of
events. If one of the call backs can not be used, e.g. because the application crashed, the other call back interface is used
instead.
first instance : (Logical : IpAppCallControlManager second instance : : IpAppCal lControlMan ager : IpCallControlManager
View::IpAppLogic) (Logic.
1: new()
2: enableCallNotification( )
3: new()
4: enableCallNotification( )
5: callEventNotify(  )
6: 'forward event'
7: "call Notify result: failure"
8: callEventNotify(  )
9: "forward event"
1: The first instance of the application is started on node 1. The application creates a new
IpAppCallControlManager to handle callbacks for this first instance of the logic.
2: The enableCallNotification is associated with an applicationID. The call control manager uses the
applicationID to decide whether this is the same application.
3: The second instance of the application is started on node 2. The application creates a new
IpAppCallControlManager to handle callbacks for this second instance of the logic.
4: The same enableCallNotification request is sent as for the first instance of the logic. Because both requests are
associated with the same application, the second request is not rejected, but the specified callback object is
stored as an additional callback.
5: When the trigger occurs one of the first instance of the application is notified. The gateway may have different
policies on how to handle additional callbacks, e.g. always first try the first registered or use some kind of
round robin scheme.
6: The event is forwarded to the first instance of the logic.
ETSI
10 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
7: When the first instance of the application is overloaded or unavailable this is communicated with an exception
to the call control manager.
8: Based on this exception the call control manager will notify another instance of the application (if available).
9: The event is forwarded to the second instance of the logic.
4.2 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.
: (Logical : IpAppCall : : : IpCall : : IpUICall
View::IpAppLogic) IpAppUICall IpCallControlManager IpAppUIManager
1: new()
2: createCall( )
3: new()
4: routeReq(    )
5: routeRes(  )
6: 'f orward ev ent'
7: createUICall()
8: new()
9: sendInf oReq(   )
10: sendInf oRes(  )
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) is 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".
ETSI
11 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
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.
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.
ETSI
12 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4.3 Application Initiated Call
The following sequence diagram shows an application creating a call between party A and party B. This sequence could
be done after a customer has accessed a Web page and selected a name on the page of a person or organisation to talk
to.
: (Logical : IpAppCall : : IpCall
View::IpAppLo. IpCallControlManager
1: new()
2: createCall( )
3: new()
4: routeReq(    )
5: routeRes(  )
6: 'forward event'
7: routeReq(    )
8: routeRes(  )
9: 'forward event'
10: deassignCall( )
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) is met, it is created.
ETSI
13 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4: This message is used to route the call to the A subscriber (origination). In the message the application request
response when the A party answers.
5: This message indicates that the A party answered the call.
6: This message forwards the previous message to the application logic.
7: This message is used to route the call to the B-party. Also in this case a response is requested for call answer
or failure.
8: This message indicates that the B-party answered the call. The call now has two parties and a speech
connection is automatically established between them.
9: This message is used to forward the previous message to the IpAppLogic.
10: Since the application is no longer interested in controlling the call, the application deassigns the call. The call
will continue in the network, but there will be no further communication between the call object and the
application.
ETSI
14 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4.4 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 : IpAppCallControlManager : IpAppCall : : : IpCall : : IpUICall
View::IpAppLogic) 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: 'forw ard even t'
15: callEnded( )
16: "forward event"
17: d eass i gnC all ( )
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) is met, other messages (not shown) are used to create the call and associated call leg object.
3: This message is used to pass the new call event to the object implementing the 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.
ETSI
15 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
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.
ETSI
16 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4.5 Number Translation 1
The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event
being received by the call control service.
: (Logical : IpAppCallControlManager : IpAppCall : : IpCall
View::IpAppLo. IpCallControlManager
1: new()
2: enableCallNotification( )
3: callEventNotify(  )
4: 'forward event'
5: new()
6: 'translate number'
7: routeReq(    )
8: routeRes(  )
9: 'forward event'
10: deassignCall( )
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 number translation 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 set in message 2, 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) is met, other messages (not
shown) are used to create the call and associated call leg object.
ETSI
17 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
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 message 3 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 message 3.
6: This message invokes the number translation function.
7: The returned translated number is used in message 7 to route the call towards the destination.
8: This message passes the result of the call being answered to its callback object.
9: This message is used to forward the previous message to the IpAppLogic.
10: The application is no longer interested in controlling the call and therefore deassigns the call. The call will
continue in the network, but there will be no further communication between the call object and the
application.
4.6 Number Translation 1 (with callbacks)
The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event
being received by the call control service.
For illustration, in this sequence the callback references are set explicitly. This is optional. All the callbacks references
can also be passed in other methods. From an efficiency point of view that is also the preferred method. The rest of the
sequences use that mechanism.
ETSI
18 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
: (Logical : IpAppCallControlManager : IpAppCall : : IpCall
View::IpAppLogic) IpCallControlManager
1: new()
2: setCallback( )
3: enableCallNotification( )
4: callEventNotify(  )
5: 'forward event'
6: new()
7: setCallbackWithSessionID( )
8: 'translate number'
9: routeReq(    )
10: routeRes(  )
11: 'forward event'
12: deassignCall( )
1: This message is used by the application to create an object implementing the IpAppCallControlManager
interface.
2: This message sets the reference of the IpAppCallControlManager object in the CallControlManager. The
CallControlManager reports the callEventNotify to referenced object only for enableCallNotifications that do
not have an explicit IpAppCallControlManager reference specified in the enableCallNotification.
ETSI
19 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
3: This message is sent by the application to enable notifications on new call events. As this sequence diagram
depicts a number translation 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 set in message 3, 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) is met, other messages (not
shown) are used to create the call and associated call leg object.
4: This message is used to pass the new call event to the object implementing the IpAppCallControlManager
interface.
5: This message is used to forward message 4 to the IpAppLogic.
6: This message is used by the applicatio
...

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

Reference
DES/TISPAN-01032-4-02-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-2 V1.1.1 (2008-05)
Contents
Intellectual Property Rights.6
Foreword.6
1 Scope.8
2 References.8
3 Definitions and abbreviations.8
3.1 Definitions.8
3.2 Abbreviations.8
4 Generic Call Control Service Sequence Diagrams.9
4.1 Additional Callbacks.9
4.2 Alarm Call.10
4.3 Application Initiated Call .12
4.4 Call Barring 1 .14
4.5 Number Translation 1.16
4.6 Number Translation 1 (with callbacks) .17
4.7 Number Translation 2.19
4.8 Number Translation 3.21
4.9 Number Translation 4.23
4.10 Number Translation 5.25
4.11 Prepaid.26
4.12 Pre-Paid with Advice of Charge (AoC).28
5 Class Diagrams.31
6 Generic Call Control Service Interface Classes .32
6.1 Interface Class IpCallControlManager.33
6.1.1 Method createCall().33
6.1.2 Method enableCallNotification().34
6.1.3 Method disableCallNotification().35
6.1.4 Method setCallLoadControl().35
6.1.5 Method changeCallNotification().36
6.1.6 Method getCriteria().36
6.2 Interface Class IpAppCallControlManager .37
6.2.1 Method callAborted().37
6.2.2 Method callEventNotify().37
6.2.3 Method callNotificationInterrupted().38
6.2.4 Method callNotificationContinued().38
6.2.5 Method callOverloadEncountered().39
6.2.6 Method callOverloadCeased().39
6.2.7 Method abortMultipleCalls().39
6.3 Interface Class IpCall .39
6.3.1 Method routeReq().40
6.3.2 Method release().41
6.3.3 Method deassignCall().41
6.3.4 Method getCallInfoReq().42
6.3.5 Method setCallChargePlan().42
6.3.6 Method setAdviceOfCharge().42
6.3.7 Method getMoreDialledDigitsReq().43
6.3.8 Method superviseCallReq().43
6.3.9 Method continueProcessing().43
6.4 Interface Class IpAppCall .44
6.4.1 Method routeRes().44
6.4.2 Method routeErr().45
6.4.3 Method getCallInfoRes().45
6.4.4 Method getCallInfoErr().45
6.4.5 Method superviseCallRes().46
ETSI
4 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
6.4.6 Method superviseCallErr().46
6.4.7 Method callFaultDetected().46
6.4.8 Method getMoreDialledDigitsRes().47
6.4.9 Method getMoreDialledDigitsErr().47
6.4.10 Method callEnded().47
7 Generic Call Control Service State Transition Diagrams.48
7.1 State Transition Diagrams for IpCallControlManager .48
7.1.1 Active State.48
7.1.2 Notification terminated State .48
7.2 State Transition Diagrams for IpCall.49
7.2.1 Network Released State .49
7.2.2 Finished State.49
7.2.3 Application Released State.49
7.2.4 No Parties State.50
7.2.5 Active State.50
7.2.6 1 Party in Call State .50
7.2.7 2 Parties in Call State.50
7.2.8 Routing to Destination(s) State.51
8 Generic Call Control Service Properties .51
8.1 List of Service Properties .51
8.2 Service Property values for the CAMEL Service Environment .52
9 Generic Call Control Data Definitions.53
9.1 Generic Call Control Event Notification Data Definitions.53
9.1.1 TpCallEventName.53
9.1.2 TpCallNotificationType.54
9.1.3 TpCallEventCriteria.54
9.1.4 TpCallEventInfo.54
9.2 Generic Call Control Data Definitions .54
9.2.1 IpCall.54
9.2.2 IpCallRef.54
9.2.3 IpAppCall.55
9.2.4 IpAppCallRef.55
9.2.5 TpCallIdentifier.55
9.2.6 IpAppCallControlManager.55
9.2.7 IpAppCallControlManagerRef.55
9.2.8 IpCallControlManager.55
9.2.9 IpCallControlManagerRef.55
9.2.10 TpCallAppInfo.55
9.2.11 TpCallAppInfoType.56
9.2.12 TpCallAppInfoSet.56
9.2.13 TpCallEndedReport.56
9.2.14 TpCallFault.56
9.2.15 TpCallInfoReport.57
9.2.16 TpCallReleaseCause.57
9.2.17 TpCallReport.57
9.2.18 TpCallAdditionalReportInfo.58
9.2.19 TpCallReportRequest.58
9.2.20 TpCallAdditionalReportCriteria.58
9.2.21 TpCallReportRequestSet.58
9.2.22 TpCallReportType.59
9.2.23 TpCallTreatment.59
9.2.24 TpCallEventCriteriaResultSet.59
9.2.25 TpCallEventCriteriaResult.59
Annex A (normative): OMG IDL Description of Generic Call Control SCF.60
Annex B (informative): W3C WSDL Description of Generic Call Control SCF .61
Annex C (informative): Java™ API Description of the Call Control SCFs.62
ETSI
5 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .63
Annex E (informative): Description of Call Control Sub-part 2: Generic call control SCF for
3GPP2 cdma2000 networks .64
E.1 General Exceptions.64
E.2 Specific Exceptions.64
E.2.1 Clause 1: Scope .64
E.2.2 Clause 2: References .64
E.2.3 Clause 3: Definitions and abbreviations.64
E.2.4 Clause 4: Generic Call Control Service Sequence Diagrams .64
E.2.5 Clause 5: Class Diagrams.64
E.2.6 Clause 6: Generic Call Control Service Interface Classes.64
E.2.7 Clause 7: Generic Call Control Service State Transition Diagrams .65
E.2.8 Clause 8: Generic Call Control Service Properties.65
E.2.9 Clause 9: Generic Call Control Data Definitions .65
E.2.10 Annex A (normative): OMG IDL Description of Generic Call Control SCF .65
E.2.11 Annex B (informative): W3C WSDL Description of Generic Call Control SCF.65
E.2.12 Annex C (informative): Java™ API Description of the Call Control SCFs.65
Annex F (informative): Record of changes .66
F.1 Interfaces.66
F.1.1 New.66
F.1.2 Deprecated.66
F.1.3 Removed.66
F.2 Methods.66
F.2.1 New.66
F.2.2 Deprecated.66
F.2.3 Modified.67
F.2.4 Removed.67
F.3 Data Definitions.67
F.3.1 New.67
F.3.2 Modified.67
F.3.3 Removed.67
F.4 Service Properties.67
F.4.1 New.67
F.4.2 Deprecated.67
F.4.3 Modified.68
F.4.4 Removed.68
F.5 Exceptions.68
F.5.1 New.68
F.5.2 Modified.68
F.5.3 Removed.68
F.6 Others.68
History .69

ETSI
6 ETSI ES 204 915-4-2 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 2 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
7 ETSI ES 204 915-4-2 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-2 V7.0.0 (Release 7).
ETSI
8 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
1 Scope
The present document is part 4, sub-part 2 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 Generic Call Control Service Capability Feature (SCF) aspects of the interface. All
aspects of the Generic Call Control SCF are defined here, these being:
• Sequence Diagrams.
• Class Diagrams.
• Interface specification plus detailed method descriptions.
• State Transition diagrams.
• Data Definitions.
• IDL Description of the interfaces.
• WSDL Description of the interfaces.
• Reference to the Java™ API description of the interfaces.
The process by which this task is accomplished is through the use of object modelling techniques described by the
Unified Modelling Language (UML).
2 References
The references listed in clause 2 of ES 204 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 204 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 6)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 204 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ES 204 915-1 apply.
ETSI
9 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4 Generic Call Control Service Sequence Diagrams
4.1 Additional Callbacks
The following sequence diagram shows how an application can register two call back interfaces for the same set of
events. If one of the call backs can not be used, e.g. because the application crashed, the other call back interface is used
instead.
first instance : (Logical : IpAppCallControlManager second instance : : IpAppCal lControlMan ager : IpCallControlManager
View::IpAppLogic) (Logic.
1: new()
2: enableCallNotification( )
3: new()
4: enableCallNotification( )
5: callEventNotify(  )
6: 'forward event'
7: "call Notify result: failure"
8: callEventNotify(  )
9: "forward event"
1: The first instance of the application is started on node 1. The application creates a new
IpAppCallControlManager to handle callbacks for this first instance of the logic.
2: The enableCallNotification is associated with an applicationID. The call control manager uses the
applicationID to decide whether this is the same application.
3: The second instance of the application is started on node 2. The application creates a new
IpAppCallControlManager to handle callbacks for this second instance of the logic.
4: The same enableCallNotification request is sent as for the first instance of the logic. Because both requests are
associated with the same application, the second request is not rejected, but the specified callback object is
stored as an additional callback.
5: When the trigger occurs one of the first instance of the application is notified. The gateway may have different
policies on how to handle additional callbacks, e.g. always first try the first registered or use some kind of
round robin scheme.
6: The event is forwarded to the first instance of the logic.
ETSI
10 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
7: When the first instance of the application is overloaded or unavailable this is communicated with an exception
to the call control manager.
8: Based on this exception the call control manager will notify another instance of the application (if available).
9: The event is forwarded to the second instance of the logic.
4.2 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.
: (Logical : IpAppCall : : : IpCall : : IpUICall
View::IpAppLogic) IpAppUICall IpCallControlManager IpAppUIManager
1: new()
2: createCall( )
3: new()
4: routeReq(    )
5: routeRes(  )
6: 'f orward ev ent'
7: createUICall()
8: new()
9: sendInf oReq(   )
10: sendInf oRes(  )
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) is 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".
ETSI
11 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
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.
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.
ETSI
12 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4.3 Application Initiated Call
The following sequence diagram shows an application creating a call between party A and party B. This sequence could
be done after a customer has accessed a Web page and selected a name on the page of a person or organisation to talk
to.
: (Logical : IpAppCall : : IpCall
View::IpAppLo. IpCallControlManager
1: new()
2: createCall( )
3: new()
4: routeReq(    )
5: routeRes(  )
6: 'forward event'
7: routeReq(    )
8: routeRes(  )
9: 'forward event'
10: deassignCall( )
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) is met, it is created.
ETSI
13 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4: This message is used to route the call to the A subscriber (origination). In the message the application request
response when the A party answers.
5: This message indicates that the A party answered the call.
6: This message forwards the previous message to the application logic.
7: This message is used to route the call to the B-party. Also in this case a response is requested for call answer
or failure.
8: This message indicates that the B-party answered the call. The call now has two parties and a speech
connection is automatically established between them.
9: This message is used to forward the previous message to the IpAppLogic.
10: Since the application is no longer interested in controlling the call, the application deassigns the call. The call
will continue in the network, but there will be no further communication between the call object and the
application.
ETSI
14 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4.4 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 : IpAppCallControlManager : IpAppCall : : : IpCall : : IpUICall
View::IpAppLogic) 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: 'forw ard even t'
15: callEnded( )
16: "forward event"
17: d eass i gnC all ( )
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) is met, other messages (not shown) are used to create the call and associated call leg object.
3: This message is used to pass the new call event to the object implementing the 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.
ETSI
15 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
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.
ETSI
16 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
4.5 Number Translation 1
The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event
being received by the call control service.
: (Logical : IpAppCallControlManager : IpAppCall : : IpCall
View::IpAppLo. IpCallControlManager
1: new()
2: enableCallNotification( )
3: callEventNotify(  )
4: 'forward event'
5: new()
6: 'translate number'
7: routeReq(    )
8: routeRes(  )
9: 'forward event'
10: deassignCall( )
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 number translation 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 set in message 2, 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) is met, other messages (not
shown) are used to create the call and associated call leg object.
ETSI
17 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
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 message 3 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 message 3.
6: This message invokes the number translation function.
7: The returned translated number is used in message 7 to route the call towards the destination.
8: This message passes the result of the call being answered to its callback object.
9: This message is used to forward the previous message to the IpAppLogic.
10: The application is no longer interested in controlling the call and therefore deassigns the call. The call will
continue in the network, but there will be no further communication between the call object and the
application.
4.6 Number Translation 1 (with callbacks)
The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event
being received by the call control service.
For illustration, in this sequence the callback references are set explicitly. This is optional. All the callbacks references
can also be passed in other methods. From an efficiency point of view that is also the preferred method. The rest of the
sequences use that mechanism.
ETSI
18 ETSI ES 204 915-4-2 V1.1.1 (2008-05)
: (Logical : IpAppCallControlManager : IpAppCall : : IpCall
View::IpAppLogic) IpCallControlManager
1: new()
2: setCallback( )
3: enableCallNotification( )
4: callEventNotify(  )
5: 'forward event'
6: new()
...