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

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

---------------------- Page: 1 ----------------------

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

---------------------- Page: 2 ----------------------

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

ETSI ES 202 915-4-4 V1.2.1 (2003-08)
ETSI Standard


Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 4: Multi-Media Call Control SCF
(Parlay 4)



�

---------------------- Page: 3 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 2 ETSI ES 202 915-4-4 V1.2.1 (2003-08)



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

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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:
editor@etsi.org
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

---------------------- Page: 4 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 3 ETSI ES 202 915-4-4 V1.2.1 (2003-08)
Contents
Intellectual Property Rights.5
Foreword.5
1 Scope.7
2 References.7
3 Definitions and abbreviations.7
3.1 Definitions.7
3.2 Abbreviations.7
4 MultiMedia Call Control Service Sequence Diagrams .8
4.1 Barring for media combined with call routing, alternative 1.8
4.2 Barring for media combined with call routing, alternative 2.9
4.3 Barring for media, simple.10
4.4 Call Volume charging supervision .11
5 Class Diagrams.13
6 MultiMedia Call Control Service Interface Classes.14
6.1 Interface Class IpMultiMediaCallControlManager.15
6.1.1 Method createMediaNotification().15
6.1.2 Method destroyMediaNotification().16
6.1.3 Method changeMediaNotification().16
6.1.4 Method getMediaNotification().17
6.2 Interface Class IpAppMultiMediaCallControlManager .17
6.2.1 Method reportMediaNotification().17
6.3 Interface Class IpMultiMediaCall .18
6.3.1 Method superviseVolumeReq().19
6.4 Interface Class IpAppMultiMediaCall .19
6.4.1 Method superviseVolumeRes().19
6.4.2 Method superviseVolumeErr().20
6.5 Interface Class IpMultiMediaCallLeg.20
6.5.1 Method mediaStreamAllow().20
6.5.2 Method mediaStreamMonitorReq().21
6.5.3 Method getMediaStreams().21
6.6 Interface Class IpAppMultiMediaCallLeg .21
6.6.1 Method mediaStreamMonitorRes().22
6.7 Interface Class IpMultiMediaStream.22
6.7.1 Method subtract().23
7 MultiMedia Call Control Service State Transition Diagrams .23
8 Multi-Media Call Control Data Definitions .23
8.1 Event Notification Data Definitions.23
8.1.1 TpMediaStreamRequestSet.23
8.1.2 TpMediaStreamRequest.24
8.1.3 TpMediaStreamDirection.24
8.1.4 TpMediaStreamDataTypeRequest.24
8.1.5 TpMediaStreamDataTypeRequestType.24
8.1.6 TpAudioCapabilitiesType.25
8.1.7 TpVideoCapabilitiesType.25
8.1.8 TpDataCapabilities.25
8.1.9 TpMediaStreamEventType.25
8.1.10 TpMediaStreamSet.25
8.1.11 TpMediaStream.26
8.1.12 TpMediaStreamDataType.26
8.2 Multi-Media Call Control Data Definitions .26
8.2.1 IpMultiMediaCall.26
ETSI

---------------------- Page: 5 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 4 ETSI ES 202 915-4-4 V1.2.1 (2003-08)
8.2.2 IpMultiMediaCallRef.26
8.2.3 IpAppMultiMediaCall.26
8.2.4 IpAppMultiMediaCallRef.26
8.2.5 IpMultiMediaCallLeg.26
8.2.6 IpMultiMediaCallLegRef.26
8.2.7 IpAppMultiMediaCallLeg.26
8.2.8 IpAppMultiMediaCallLegRef.26
8.2.9 TpAppMultiMediaCallLegRefSet.26
8.2.10 TpMultiMediaCallIdentifier.27
8.2.11 TpMultiMediaCallIdentifierSet.27
8.2.12 TpMultiMediaCallLegIdentifier.27
8.2.13 TpMultiMediaCallLegIdentifierSet.27
8.2.14 IpAppMultiMediaCallControlManager.27
8.2.15 IpAppMultiMediaCallControlManagerRef.27
8.2.16 TpAppMultiMediaCallBack.27
8.2.17 TpAppMultiMediaCallBackRefType.28
8.2.18 TpAppMultiMediaCallLegCallBack.28
8.2.19 TpCallSuperviseVolume.28
8.2.20 TpNotificationMediaRequest.28
8.2.21 TpMediaNotificationRequested.29
8.2.22 TpMediaNotificationsRequestedSet.29
Annex A (normative): OMG IDL Description of Multi-Media Call Control SCF.30
Annex B (informative): W3C WSDL Description of Multi-Media Call Control SCF .31
Annex C (informative): Java API Description of the Call Control SCFs.32
Annex D (informative): Contents of 3GPP OSA Rel-5 Call Control .33
Annex E (informative): Record of changes .34
E.1 Interfaces.34
E.1.1 New.34
E.1.2 Deprecated.34
E.1.3 Removed.34
E.2 Methods.34
E.2.1 New.34
E.2.2 Deprecated.35
E.2.3 Modified.35
E.2.4 Removed.35
E.3 Data Definitions.35
E.3.1 New.35
E.3.2 Modified.35
E.3.3 Removed.36
E.4 Service Properties.36
E.4.1 New.36
E.4.2 Deprecated.36
E.4.3 Modified.36
E.4.4 Removed.36
E.5 Exceptions.37
E.5.1 New.37
E.5.2 Modified.37
E.5.3 Removed.37
E.6 Others.37
History .38

ETSI

---------------------- Page: 6 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 5 ETSI ES 202 915-4-4 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 4 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

---------------------- Page: 7 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 6 ETSI ES 202 915-4-4 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-4 V5.2.0 (Release 5).
ETSI

---------------------- Page: 8 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 7 ETSI ES 202 915-4-4 V1.2.1 (2003-08)
1 Scope
The present document is part 4, sub-part 4 of the Stage 3 specification for an Application Programming Interface (API)
for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use of network functionality
through an open standardised interface, i.e. the OSA APIs.
The present document specifies the Multi-Media Call Control Service Capability Feature (SCF) aspects of the interface.
All aspects of the Multi-Media 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

---------------------- Page: 9 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 8 ETSI ES 202 915-4-4 V1.2.1 (2003-08)
4 MultiMedia Call Control Service Sequence Diagrams
4.1 Barring for media combined with call routing, alternative 1
This sequence illustrates how one application can influence both the call routing and the media stream establishment of
one call.
In this sequence there is one application handling both the media barring and the routing of the call.
: (Logical : : : : :
View::IpAppLogic) IpAppMultiMediaCallControlManager IpAppMultiMediaCallLeg Ip Mul tiMe diaCallCo ntrolMan ager IpMultiMediaCall IpMultiMediaCallLeg
1: new()
2: createNotification( )
3: reportNotification(  )
4: "forward event"
5: new()
6: mediaStreamMonitorReq( )
7: mediaStreamMonitorRes(  )
8: "forward event"
9: mediaStreamAllow( )
10: createAndRouteCallLegReq(   )
11: mediaStreamMonitorRes(  )
12: "forward event"
13: mediaStreamAllow( )

1: The application creates a AppMultiMediaCallControlManager interface in order to handle callback methods.
2: The application expresses interest in all calls from subscriber A. Since createNotification is used and not
createMediaNotification all calls are reported regardless of the media used.
3: A makes a call with the SIP INVITE with SDP media stream indicating video. The application is notified.
4: The event is forwarded to the application.
5: The application creates a new AppMultiMediaCallLeg interface to receive callbacks.
6: The application sets a monitor on video media streams to be established (added) for the indicated leg.
7: Since the video media stream was included in the SIP invite, the media streams monitored will be returned in the
monitor result.
8: The event is forwarded to the application.
9: The application denies the video media stream, i.e., it is not included in the allowed media streams. This
corresponds to removing the media stream from the setup.
ETSI

---------------------- Page: 10 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 9 ETSI ES 202 915-4-4 V1.2.1 (2003-08)
10: The application requests to reroute the call to a different destination (or the same one.)
11: Later in the call the A party tries to establish a lower bandwidth video media stream. This is again reported with
MediaStreamMonitorRes.
12: The event is forwarded.
13: This time the application allows the establishment of the media stream by including the media stream in the allowed
list.
4.2 Barring for media combined with call routing, alternative 2
This sequence illustrates how one application can influence both the call routing and the media establishment of one
call.
Media establishment and call establishment are regarded separately by the application.
From the gateway point of view it can actually be regarded as two separately triggered applications, one for media
control and one for routing. This is also the way that it is shown here, for clarity.
However, an implementation of the application could combine the media logic and call logic in one object.
callLogic : (Logical callAppLogic : : IpAppMultiMediaCall PartyA : PartyB : mediaLogic : mediaAppLogic : : : PartyA : PartyB :
View::IpAppLogic) IpAppMultiMediaCallControlManager IpMultiMedi. IpAppCallLeg (Logic. IpAppMultiMediaCallControlManager IpMultiMediaCallControlManager IpMultiMediaCall IpMultiMediaCallLeg IpAppCallLeg
1: new()
2: createNotification( )
3: new()
4: c reat eM edi aNoti fic atio n( )
5: reportNotification(  )
6: "forward event"
7: new()
8: new()
9: reportMediaNotification(   )
10: "forward event"
11: new()
12: createAndRouteCallLegReq(   )
13: new()
14: mediaStreamAllow( )
15: deas si gn Cal l( )
16: eventReport Res( )
17: "forward event"
18: deassignCall( )
19: reportMediaNotification(   )
20: "forward event"
21: mediaStreamAllow( )
22: deas si gn Cal l( )

1: The application creates a new AppMultiMediaCallControlManager interface.
2: The application expresses interest in all calls from subscriber A for rerouting purposes.
3: The application creates a new AppMultiMediaCallControlManager interface. This is to be used for the media
control only.
ETSI

---------------------- Page: 11 ----------------------

SIST ES 202 915-4-4 V1.2.1:2005
 10 ETSI ES 202 915-4-4 V1.2.1 (2003-08)
4: Separately the application expresses interest is some media streams for calls from and to A. The request indicates
interrupt mode.
5: Subscriber A makes a call with the SIP INVITE with SDP media stream indicating video. Since the media
establishment is combined with the SIP INVITE message, both applications are triggered (not necessarily in the order
shown). Here the call application is notified about the call setup.
6: The event is forwarded to the call control application.
7: The call control application creates a new AppMultiMediaCall interface.
8: The call control application creates a new AppMultiMediaCallLeg interface.
9: The media application is notified about the call setup. All media streams from the setup will be indicated.
10: The event is forwarded to the media application.
11: The call control application creates a new AppMultiMediaCallLeg interface.
12: The call application decides to reroute the call to another address. Included in the request are monitors on answer
and call end. However, since the media was also triggered in mode interrupt the call will not proceed until the media
streams are confirmed or rejected.
14: The application allows the audio media stream, but refuses the high bandwidth video, by excluding it from the
allowed list. Since both call processing and media handling is now acknowledged, the call routing can continue (with a
changed SDP parameter reflecting the manipulated media).
15: The Media application is no longer interested in the call.
16: When the B subscriber answers the call application is notified.
17: The event is forwarded to the call application.
19: When later in the call A tries to establish a lower bandwidth video stream the media application is triggered.
20: The triggering is forwarded to the media application.
21: The application now allows the establishment of the media stream by including the media stream in the
mediaStreamAllow list.
22: The media application is no longer interested in the call.
4.3 Barring for media, simple
This sequence illustrates how an application can block the establishment of video streams for a certain user.
: (Logical :
...