SIST ES 202 915-4-2 V1.2.1:2005

• Abstract:

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

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

SIST ES 202 915-4-2 V1.2.1:2005 is the Slovenian adoption of ETSI ES 202 915-4-2 V1.2.1 for Open Service Access (OSA) Application Programming Interface (API) Part 4, Call Control, Sub-part 2, Generic Call Control SCF (Parlay 4). It specifies the generic call control service interface that lets applications start, route, monitor, charge and release calls through an OSA network interface, using the service-side and application-side objects defined in the document.

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

SIST ES 202 915-4-2 V1.2.1:2005 specifies the Generic Call Control Service Capability Feature (SCF) for the OSA API. The document defines the call control behavior from the application view and the service view, including diagrams, interface classes, state models, data definitions and interface descriptions.

The scope describes it as a maintenance update of ES 202 915-4-2 V1.1.1, with the updated document also known as PARLAY 4.1. Only the parts needing modification are updated, with most changes being maintenance fixes.

The document is organized into these main parts:

• Scope, references, definitions and abbreviations
• Generic Call Control service sequence diagrams
• Class diagrams and interface classes
• State transition diagrams
• Service properties
• Data definitions
• Annexes for IDL, WSDL, Java API and change history

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-5 Call Control
Annex E	Record of changes

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

SIST ES 202 915-4-2 V1.2.1:2005 defines a call control service built around a two-party call model, service-side control objects, and application-side callback objects. In practice, the application must create or receive the right callback objects, request the right reports, and release or deassign the call when it is finished.

Service model and object roles

Clause 6 says the Generic Call Control Service (GCCS) is based on a third-party model where calls are instantiated from the network and routed through the network. It does not give explicit access to call legs or media channels; those are handled by the Multi-Party Call Control and Multi-Media Call Control services.

The service is represented by IpCallControlManager and IpCall, while the application provides IpAppCallControlManager and IpAppCall for callbacks. This matters because the developer has to implement both sides of the interaction: one side sends control requests, the other side receives event reports.

Minimum methods and callback handling

Clause 6.1 says IpCallControlManager must at least support either createCall() or the notification pair enableCallNotification() and disableCallNotification(). Clause 6.3 says IpCall must at least support routeReq(), release() and deassignCall().

The callback logic is central. createCall() expects an application callback reference so the service can report abnormal termination. enableCallNotification() can use an explicit callback reference or fall back to a previously set callback, and repeated notifications with the same criteria can be treated as additional callbacks. In practice, this lets one application instance fail over to another if needed.

Event notification, criteria and overload control

Clause 6.1.2 defines how applications subscribe to call-related events. The event criteria can cover originating or terminating numbers, address ranges and event types, and overlapping requests may be refused. This matters for shared services, because two applications cannot always subscribe to the same call space in the same way.

Clause 6.1.4 defines setCallLoadControl(), which applies or removes load control for a number range. The duration values include removal, infinite duration and network default duration. The application must also handle callOverloadEncountered() and callOverloadCeased(), which report when the network imposes or removes load control.

Routing, reporting, supervision and charging

Clause 6.3 makes routeReq() the main call-routing operation. The application can request response events such as answer, busy, no answer or routing failure, and it can pass address context and application-related information. For practical use, this is how an application starts or continues a call while still receiving network feedback.

Clause 6.3.4 and 6.4.3 cover getCallInfoReq() and getCallInfoRes(), which provide call timing and release-cause information for charging or call records. Clause 6.3.6 and 6.4.5 cover setAdviceOfCharge() and superviseCallReq(), which support advice-of-charge updates and timed supervision of the call. These functions matter when the application needs to control credit, duration or tariff changes during the call.

Call ending and cleanup

Clause 6.3.2 and 6.3.3 distinguish release() from deassignCall(). release() ends the call in the network and releases the call object, while deassignCall() removes the application’s control relationship but leaves the call in progress.

The document repeatedly expects the application to release or deassign the call when finished, unless a callFaultDetected() event has already been received. That is the cleanup rule that prevents stale call objects and makes the call lifecycle explicit.

State behavior and service properties

Clause 7 models the application view of the manager and call objects. The key states include Active, Notification terminated, No Parties, Routing to Destination(s), 1 Party in Call, 2 Parties in Call, Network Released, Application Released and Finished. This helps implementers map each method to a valid call state.

Clause 8 defines service properties that describe what the service supports, including triggering event types, dynamic event types, address plans, user interaction support, media type and service-level restrictions such as allowed notification modes and charge plans. For CAMEL Service Environment use, the document lists required property values and the supported operation set.

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

• Open Service Access (OSA) - An architecture that lets application developers use network functions through an open standardized interface.
• Application Programming Interface (API) - The interface set that applications use to interact with the call control service.
• Service Capability Feature (SCF) - A service function block in the OSA API; here it is the Generic Call Control service.
• IpCallControlManager - The service-side manager interface used to create calls, manage notifications and control load.
• IpAppCallControlManager - The application-side callback interface that receives call events and overload notifications.
• IpCall - The service-side call interface for routing, release, supervision, charging and call information.
• TpCallEventCriteria - The data structure that defines which call events an application wants to receive.
• TpCallReport - The data structure used to report call progress, answer, busy, disconnect and related events.

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

SIST ES 202 915-4-2 V1.2.1:2005 is used by telecom application developers, service platform vendors, gateway implementers and network integrators working with OSA call control. It is also relevant to operators and buyers who need call routing, notification, supervision, charging or user interaction in an open API model.

The document explicitly ties the Generic Call Control service to Intelligent Network services in switched telephony networks and to equivalent functions in packet-based networks. It also states that implementations may be specialized toward call control technologies such as H.323, ISUP, Q.931, Q.2931, UNI3.1 or Session Initiation Protocol (SIP).

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

SIST ES 202 915-4-2 V1.2.1:2005 is a maintenance update of ES 202 915-4-2 V1.1.1. The scope says the updated document is also known as PARLAY 4.1 and that only the parts requiring modification were updated, with most changes being maintenance fixes.

Annex E records the change history by interfaces, methods, data definitions, service properties, exceptions and other items. The only specific data definition change named in the document is TpCallEventCriteriaResult, which was modified to match the IDL.

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

Clause 2 points to the companion ETSI parts that provide shared definitions and common data:

• ETSI ES 202 915-1 - Overview, with the provisions, definitions and abbreviations used throughout the series
• ETSI ES 202 915-2 - Common Data Definitions
• ETSI ES 202 915-4-1 - Call Control Common Definitions

The foreword also states that the document is equivalent to 3GPP TS 29.198-4-2 V5.2.0 (Release 5). This helps readers align the ETSI OSA call control specification with the corresponding 3GPP OSA specification.

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

The document contains service sequence diagrams for typical call control scenarios such as callbacks, alarm call, application-initiated call, call barring, number translation and prepaid operation. These diagrams are useful when designing application flows and testing how the service and application exchange control and report messages.

It also contains class diagrams and detailed method descriptions for the service-side and application-side interfaces. That is where implementers find the call control operations, callback methods and the intended order of use.

Clause 7 contains state transition diagrams for IpCallControlManager and IpCall. These diagrams show when notifications are active, when calls are routed, when the call is released, and when the application is expected to deassign the call.

Clause 8 provides service property tables, including capability properties and the CAMEL Service Environment values. Clause 9 defines the event, report, fault and treatment data structures used by the API.

Annex A gives the OMG IDL form of the interface specification, Annex B gives the W3C WSDL form, and Annex C points to the Java API description. Annex D summarizes the 3GPP OSA Rel-5 Call Control content, and Annex E lists the change record for the version history.

SLOVENSKI STANDARD
01-januar-2005
2GSUWLGRVWRSGRVWRULWYH26$±9PHVQLN]DDSOLNDFLMVNRSURJUDPLUDQMH$3,±
GHO.UPLOMHQMHNOLFD±SRGGHO*HQHULþQRNUPLOMHQMHNOLFD6&)
Open Service Access (OSA); Application Programming Interface (API); Part 4: Call
Control; Sub-part 2: Generic Call Control SCF (Parlay 4)
Ta slovenski standard je istoveten z: ES 202 915-4-2 Version 1.2.1
ICS:
33.040.01 Telekomunikacijski sistemi Telecommunication systems
na splošno in general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 2: Generic Call Control SCF
(Parlay 4)
�
2 ETSI ES 202 915-4-2 V1.2.1 (2003-08)

Reference
RES/SPAN-120096-4-2
Keywords
API, IDL, OSA, UML
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to:
[e-mail]
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2003.
© The Parlay Group 2003.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
3 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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 .13
4.5 Number Translation 1.15
4.6 Number Translation 1 (with callbacks) .17
4.7 Number Translation 2.19
4.8 Number Translation 3.20
4.9 Number Translation 4.22
4.10 Number Translation 5.24
4.11 Prepaid.25
4.12 Pre-Paid with Advice of Charge (AoC).26
5 Class Diagrams.29
6 Generic Call Control Service Interface Classes .30
6.1 Interface Class IpCallControlManager.31
6.1.1 Method createCall().31
6.1.2 Method enableCallNotification().32
6.1.3 Method disableCallNotification().33
6.1.4 Method setCallLoadControl().33
6.1.5 Method changeCallNotification().34
6.1.6 Method getCriteria().34
6.2 Interface Class IpAppCallControlManager .34
6.2.1 Method callAborted().35
6.2.2 Method callEventNotify().35
6.2.3 Method callNotificationInterrupted().36
6.2.4 Method callNotificationContinued().36
6.2.5 Method callOverloadEncountered().36
6.2.6 Method callOverloadCeased().36
6.3 Interface Class IpCall .37
6.3.1 Method routeReq().37
6.3.2 Method release().38
6.3.3 Method deassignCall().39
6.3.4 Method getCallInfoReq().39
6.3.5 Method setCallChargePlan().39
6.3.6 Method setAdviceOfCharge().40
6.3.7 Method getMoreDialledDigitsReq().40
6.3.8 Method superviseCallReq().41
6.4 Interface Class IpAppCall .41
6.4.1 Method routeRes().42
6.4.2 Method routeErr().42
6.4.3 Method getCallInfoRes().42
6.4.4 Method getCallInfoErr().43
6.4.5 Method superviseCallRes().43
6.4.6 Method superviseCallErr().43
6.4.7 Method callFaultDetected().44
ETSI
4 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
6.4.8 Method getMoreDialledDigitsRes().44
6.4.9 Method getMoreDialledDigitsErr().44
6.4.10 Method callEnded().44
7 Generic Call Control Service State Transition Diagrams.45
7.1 State Transition Diagrams for IpCallControlManager .45
7.1.1 Active State.45
7.1.2 Notification terminated State .45
7.2 State Transition Diagrams for IpCall.46
7.2.1 Network Released State .46
7.2.2 Finished State.46
7.2.3 Application Released State.46
7.2.4 No Parties State.47
7.2.5 Active State.47
7.2.6 1 Party in Call State .47
7.2.7 2 Parties in Call State.47
7.2.8 Routing to Destination(s) State.48
8 Generic Call Control Service Properties .48
8.1 List of Service Properties .48
8.2 Service Property values for the CAMEL Service Environment .49
9 Generic Call Control Data Definitions.50
9.1 Generic Call Control Event Notification Data Definitions.50
9.1.1 TpCallEventName.50
9.1.2 TpCallNotificationType.51
9.1.3 TpCallEventCriteria.51
9.1.4 TpCallEventInfo.52
9.2 Generic Call Control Data Definitions .52
9.2.1 IpCall.52
9.2.2 IpCallRef.52
9.2.3 IpAppCall.52
9.2.4 IpAppCallRef.52
9.2.5 TpCallIdentifier.52
9.2.6 IpAppCallControlManager.52
9.2.7 IpAppCallControlManagerRef.52
9.2.8 IpCallControlManager.52
9.2.9 IpCallControlManagerRef.53
9.2.10 TpCallAppInfo.53
9.2.11 TpCallAppInfoType.53
9.2.12 TpCallAppInfoSet.53
9.2.13 TpCallEndedReport.53
9.2.14 TpCallFault.54
9.2.15 TpCallInfoReport.54
9.2.16 TpCallReleaseCause.54
9.2.17 TpCallReport.55
9.2.18 TpCallAdditionalReportInfo.55
9.2.19 TpCallReportRequest.55
9.2.20 TpCallAdditionalReportCriteria.56
9.2.21 TpCallReportRequestSet.56
9.2.22 TpCallReportType.56
9.2.23 TpCallTreatment.57
9.2.24 TpCallEventCriteriaResultSet.57
9.2.25 TpCallEventCriteriaResult.57
Annex A (normative): OMG IDL Description of Generic Call Control SCF.58
Annex B (informative): W3C WSDL Description of Generic Call Control SCF .59
Annex C (informative): Java API Description of the Call Control SCFs.60
Annex D (informative): Contents of 3GPP OSA Rel-5 Call Control .61
ETSI
5 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
Annex E (informative): Record of changes .62
E1 Interfaces.62
E.1.1 New.62
E.1.2 Deprecated.62
E.1.3 Removed.62
E.2 Methods.62
E.2.1 New.62
E.2.2 Deprecated.63
E.2.3 Modified.63
E.2.4 Removed.63
E.3 Data Definitions.63
E.3.1 New.63
E.3.2 Modified.63
E.3.3 Removed.64
E.4 Service Properties.64
E.4.1 New.64
E.4.2 Deprecated.64
E.4.3 Modified.64
E.4.4 Removed.64
E.5 Exceptions.65
E.5.1 New.65
E.5.2 Modified.65
E.5.3 Removed.65
E.6 Others.65
History .66

ETSI
6 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Standard (ES) has been produced by ETSI Technical Committee Services and Protocols for Advanced
Networks (SPAN).
The present document is part 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 202 915) is structured in the
following parts:
Part 1: "Overview";
Part 2: "Common Data Definitions";
Part 3: "Framework";
Part 4: "Call Control";
Sub-part 1: "Call Control Common Definitions";
Sub-part 2: "Generic Call Control SCF";
Sub-part 3: "Multi-Party Call Control SCF";
Sub-part 4: "Multi-Media Call Control SCF";
Sub-part 5: "Conference Call Control SCF";
Part 5: "User Interaction SCF";
Part 6: "Mobility SCF";
Part 7: "Terminal Capabilities SCF";
Part 8: "Data Session Control SCF";
Part 9: "Generic Messaging SCF";
Part 10: "Connectivity Manager SCF";
Part 11: "Account Management SCF";
Part 12: "Charging SCF";
Part 13: "Policy management SCF";
Part 14: "Presence and Availability Management SCF".
ETSI
7 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
The present document has been defined jointly between ETSI, The Parlay Group (http://www.parlay.org) and the 3GPP,
in co-operation with a number of JAIN™ Community (http://www.java.sun.com/products/jain) member companies.
The present document forms part of the Parlay 4.1 set of specifications.
The present document is equivalent to 3GPP TS 29.198-4-2 V5.2.0 (Release 5).
ETSI
8 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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 202 915-1 contain provisions which, through reference in this text, constitute
provisions of the present document.
ETSI ES 202 915-1: "Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview
(Parlay 4)".
ETSI ES 202 915-2: "Open Service Access (OSA); Application Programming Interface (API); Part 2: Common Data
Definitions (Parlay 4)".
ETSI ES 202 915-4-1: "Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control;
Sub-part 1: Call Control Common Definitions (Parlay 4)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ES 202 915-1 apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations defined in ES 202 915-1 apply.
ETSI
9 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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 : IpCallControlManag er
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 202 915-4-2 V1.2.1 (2003-08)
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'
5: This message passes the result of the call being answered to its callback object.
ETSI
11 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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 202 915-4-2 V1.2.1 (2003-08)
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.
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.
ETSI
13 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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.
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 IpCallContro lManage r 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 eas si gnC all ( )
ETSI
14 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
1: This message is used by the application to create an object implementing the IpAppCallControlManager interface.
2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts
a 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.
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
15 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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.
3: This message is used to pass the new call event to the object implementing the IpAppCallControlManager interface.
ETSI
16 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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.
ETSI
17 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
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.
: (Logical : IpAppCallControlManager : IpAppCall : : IpCall
View::IpAppLogic) IpCallControlManager
1: new()
2: enableCallNotification( )
3: setCallback( )
4: callEventNotify(  )
5: 'forward event'
6: new()
7: setCallbackWithSessionID( )
8: 'translate number'
9: routeReq(    )
10: rout eRes(  )
11: 'forward event'
12: 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
18 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
3: 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.
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 application to create an object implementing the IpAppCall interface.
7: This message is used to set the reference to the IpAppCall for this call.
8: This message invokes the number translation function.
9: The returned translated number is used in message 7 to route the call towards the destination.
10: This message passes the result of the call being answered to its callback object.
11: This message is used to forward the previous message to the IpAppLogic.
12: 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.
ETSI
19 ETSI ES 202 915-4-2 V1.2.1 (2003-08)
4.7 Number Translation 2
The following sequence diagram shows a number translation service, initiated as a result of a prearranged event being
received by
...