ETSI ES 204 915-4-4 V1.1.1 (2008-05)
Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control; Sub-part 4: Multi-Media Call Control SCF (Parlay 6)
Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control; Sub-part 4: Multi-Media Call Control SCF (Parlay 6)
DES/TISPAN-01032-4-04-OSA
Odprti dostop do storitve (OSA) - Aplikacijski programski vmesnik (API) - 4. del: Krmiljenje klica - 4. poddel: Lastnost storitvene zmožnosti (SCF) pri krmiljenju večpredstavnostnih klicev (Parlay 6)
General Information
Standards Content (Sample)
Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 4: Multi-Media Call Control SCF
(Parlay 6)
�
2 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
Reference
DES/TISPAN-01032-4-04-OSA
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, 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-4 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 MultiMedia Call Control Service Sequence Diagrams .9
4.1 Barring for media combined with call routing, alternative 1.9
4.2 Barring for media combined with call routing, alternative 2.10
4.3 Barring for media, simple.12
4.4 Call Volume charging supervision .13
5 Class Diagrams.15
6 MultiMedia Call Control Service Interface Classes.16
6.1 Interface Class IpMultiMediaCallControlManager.17
6.1.1 Method createMediaNotification().17
6.1.2 Method destroyMediaNotification().18
6.1.3 Method changeMediaNotification().18
6.1.4 Method getMediaNotification().19
6.2 Interface Class IpAppMultiMediaCallControlManager .19
6.2.1 Method reportMediaNotification().19
6.3 Interface Class IpMultiMediaCall .20
6.3.1 Method superviseVolumeReq().20
6.4 Interface Class IpAppMultiMediaCall .21
6.4.1 Method superviseVolumeRes().21
6.4.2 Method superviseVolumeErr().22
6.5 Interface Class IpMultiMediaCallLeg .22
6.5.1 Method mediaStreamAllow().22
6.5.2 Method mediaStreamMonitorReq().23
6.5.3 Method getMediaStreams().23
6.6 Interface Class IpAppMultiMediaCallLeg .23
6.6.1 Method mediaStreamMonitorRes().24
6.7 Interface Class IpMultiMediaStream.24
6.7.1 Method subtract().24
7 MultiMedia Call Control Service State Transition Diagrams .25
8 Multi-Media Call Control Data Definitions .25
8.1 Event Notification Data Definitions.25
8.1.1 TpMediaStreamRequestSet.25
8.1.2 TpMediaStreamRequest.25
8.1.3 TpMediaStreamDirection.25
8.1.4 TpMediaStreamDataTypeRequest.26
8.1.5 TpMediaStreamDataTypeRequestType.26
8.1.6 TpAudioCapabilitiesType.26
8.1.7 TpVideoCapabilitiesType.27
8.1.8 TpDataCapabilities .27
8.1.9 TpMediaStreamEventType.27
8.1.10 TpMediaStreamSet.27
8.1.11 TpMediaStream.27
8.1.12 TpMediaStreamDataType.27
8.2 Multi-Media Call Control Data Definitions .27
8.2.1 IpMultiMediaCall.27
ETSI
4 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
8.2.2 IpMultiMediaCallRef.28
8.2.3 IpAppMultiMediaCall.28
8.2.4 IpAppMultiMediaCallRef.28
8.2.5 IpMultiMediaCallLeg.28
8.2.6 IpMultiMediaCallLegRef.28
8.2.7 IpAppMultiMediaCallLeg.28
8.2.8 IpAppMultiMediaCallLegRef.28
8.2.9 TpAppMultiMediaCallLegRefSet.28
8.2.10 TpMultiMediaCallIdentifier.28
8.2.11 TpMultiMediaCallIdentifierSet.28
8.2.12 TpMultiMediaCallLegIdentifier.28
8.2.13 TpMultiMediaCallLegIdentifierSet .29
8.2.14 IpAppMultiMediaCallControlManager.29
8.2.15 IpAppMultiMediaCallControlManagerRef.29
8.2.16 TpAppMultiMediaCallBack.29
8.2.17 TpAppMultiMediaCallBackRefType.29
8.2.18 TpAppMultiMediaCallLegCallBack.29
8.2.19 TpCallSuperviseVolume.30
8.2.20 TpNotificationMediaRequest.30
8.2.21 TpMediaNotificationRequested.30
8.2.22 TpMediaNotificationsRequestedSet.30
Annex A (normative): OMG IDL Description of Multi-Media Call Control SCF.31
Annex B (informative): W3C WSDL Description of Multi-Media Call Control SCF .32
Annex C (informative): Java API Description of the Call Control SCFs.33
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .34
Annex E (informative): Description of Call Control Sub-part 4: Multimedia call control SCF
for 3GPP2 cdma2000 networks .35
E.1 General Exceptions.35
E.2 Specific Exceptions.35
E.2.1 Clause 1: Scope .35
E.2.2 Clause 2: References .35
E.2.3 Clause 3: Definitions and abbreviations.35
E.2.4 Clause 4: MultiMedia Call Control Service Sequence Diagrams.35
E.2.5 Clause 5: Class Diagrams.35
E.2.6 Clause 6: MultiMedia Call Control Service Interface Classes .35
E.2.7 Clause 7: MultiMedia Call Control Service State Transition Diagrams.36
E.2.8 Clause 8: Multi-Media Call Control Data Definitions.36
E.2.9 Annex A (normative): OMG IDL Description of Multi-Media Call Control SCF.36
E.2.10 Annex B (informative): W3C WSDL Description of Multi-Media Call Control SCF.36
E.2.11 Annex C (informative): Java™ API Description of the Call Control SCF .36
Annex F (informative): Record of changes .37
F.1 Interfaces.37
F.1.1 New.37
F.1.2 Deprecated.37
F.1.3 Removed.37
F.2 Methods.37
F.2.1 New.37
F.2.2 Deprecated.37
F.2.3 Modified.38
F.2.4 Removed.38
F.3 Data Definitions.38
F.3.1 New.38
F.3.2 Modified.38
ETSI
5 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
F.3.3 Removed.38
F.4 Service Properties.38
F.4.1 New.38
F.4.2 Deprecated.38
F.4.3 Modified.39
F.4.4 Removed.39
F.5 Exceptions.39
F.5.1 New.39
F.5.2 Modified.39
F.5.3 Removed.39
F.6 Others.39
History .40
ETSI
6 Final draft ETSI ES 204 915-4-4 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 4 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-4 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-4 V7.0.0 (Release 7).
ETSI
8 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
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 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-4 V1.1.1 (2008-02)
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 MultiMe 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 an 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.
ETSI
10 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
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.
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 r eat eM edi aNo ti 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 gnCal l( )
1 6: e ventRep ortRes( )
17: "forward event"
18: deassignCall( )
19: reportMediaNotification( )
20: "forward event"
21: mediaStreamAllow( )
22: deas si gnCal l( )
1: The application creates a new AppMultiMediaCallControlManager interface.
2: The application expresses interest in all calls from subscriber A for rerouting purposes.
ETSI
11 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
3: The application creates a new AppMultiMediaCallControlManager interface. This is to be used for the media
control only.
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.
ETSI
12 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
4.3 Barring for media, simple
This sequence illustrates how an application can block the establishment of video streams for a certain user.
: (Logical : : : :
View::IpAppLogic) IpAppMultiMediaCallControlManager IpMultiMediaCallControlMan. IpMultiMediaCall IpMultiMediaCallLeg
1: new()
2: createMediaNotification( )
3: reportMediaNotification( )
4: "forward event"
5: mediaStreamAllow( )
6: deassignCall( )
1: The application starts a new AppMultiMediaCallControlManager interface for reception of callbacks.
2: The application expresses interest in all calls from or to subscriber A that use video. The just created App
interface is given as the callback interface.
3: Subscriber A makes a call with the SIP INVITE with SDP media stream indicating video.
4: The message is forwarded to the application.
5: The application indicates that the setup of the media stream is not allowed by not including the media stream
in the allowed list. This has the effect of suppressing the video capabilities in the setup.
6: The application is no longer interested in the call.
New attempts to open video streams will again be indicated with a reportMediaNotification.
ETSI
13 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
4.4 Call Volume charging supervision
This sequence illustrates how an application may supervise a call based on the number of bytes that are exchanged.
Note that in the sequence diagram below, a single box represents both an IpAppCall and an IpAppCallLeg for space
reasons.
IpAppCallLeg : : : IpCallLeg : IpUICall IpUIManager :
: (Logical : : IpAppUICall :
IpAppMultiMediaCall IpMultiMediaCall IpUIManager
View::IpAppLogic) IpAppMultiMediaCallControlManager IpMultiMediaCallControlMan.
1: new()
2: setCallback( )
3: new()
4: createCall( )
5: createAndRouteCallLegReq( )
6: new( )
7: eventReportRes( )
8: "f orward event"
9: c reat eAndRouteCallLegReq( )
10: new( )
11: ev entReportRes( )
12: "forward ev ent"
13: superviseVolumeReq( )
14: superviseVolumeRes( )
15: "forward ev ent"
16: createUICall( )
17: sendInfoAndCollectReq( )
18: sendInf oAndCollectRes( )
19: "forward ev ent"
20: release( )
21: superviseVolumeReq( )
22: release( )
1: The application creates a new interface to receive callbacks on the call control manager.
2: The created interface is set as the callback interface for the call control manager.
3: The application creates a new interface to receive callback on the call.
4: The application requests the creation of a call.
5: The application initiates the call by routing to the origination. This will implicitly create a call leg. The
application requests a notification when the party answers.
7: When the A party answers the application is notified.
8: The message is forwarded to the logic.
9: The application also routes the call to the destination. This implicitly creates a call leg. The application
requests to be notified on answer of the B-party.
ETSI
14 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
11: When the B-party answers the application is notified.
12: The message is forwarded to the logic.
13: The application requests to supervise the call. In the request the application specifies a limit on the amount of
bytes that may be transferred. The application specifies that if the limit is reached the application should be
notified.
14: When the limit is reached a notification is send to the application.
15: The message is forwarded to the logic.
17: The application plays an announcement to the user, asking whether the user wants to end the call or continue
the call.
18: When the user answers whether the call should continue.
19: The message is forwarded to the logic.
20: The UIcall is released, since no further announcements are needed.
21: In case the user answers that the call should continue, the supervision is reset with a new maximum number of
allowed bytes. (note that this might have charging consequences, not shown).
22: If the user answered that the call should not continue, the call is released.
ETSI
15 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
5 Class Diagrams
<>
IpAppCallLeg
(f rom mpccs)
<>
<>
IpAppMultiPartyCallControlManager
IpAppMultiPartyCall
eventReportRes()
(f rom mpccs)
(from mpccs)
eventReportErr()
attachMediaRes()
reportNotification()
10.n 10.n
getInfoRes() attachMediaErr()
callAborted()
getInfoErr() detachMediaRes()
managerInterrupted()
superviseRes() detachMediaErr()
managerResumed()
superviseErr() getInfoRes()
callOverloadEncountered()
callEnded() getInfoErr()
callOverloadCeased()
createAndRouteCallLegErr() routeErr()
abortMultipleCalls()
superviseRes()
superviseErr()
callLegEnded()
<>
<>
<>
IpAppMultiMediaCall
IpAppMultiMediaCallControlManager
IpAppMultiMediaCallLeg
(f rom mmccs)
(from mmccs)
(f rom mmccs)
superviseVolumeRes()
reportMediaNotification()
mediaStreamMonitorRes()
superviseVolumeErr()
<>
<>
<>
<>
<>
IpMultiMediaCallControlManager
<> IpMultiMediaCallLeg
(from mmccs)
(f rom mmccs)
IpMultiMediaCall
1 0.n 1 0.n
(f rom mmccs)
createMediaNotification()
mediaStreamAllow()
destroyMediaNotification()
superviseVolumeReq() mediaStreamMonitorReq()
changeMediaNotification()
getMediaStreams()
getMediaNotification()
Figure 1: Application Interfaces
ETSI
16 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
<> <>
IpMultiPartyCallControlManager IpCallLeg
<>
(from mpccs) (from mpccs)
IpMultiPartyCall
(from mpccs)
rout eReq()
createCall()
eventReportReq()
createNotification()
getCallLegs()
rel ease()
destroyNotification()
createCallLeg()
getInfoReq()
changeNotification()
createAndRouteCallLegReq()
getCall()
setCallLoadControl()
release()
enableNotifications() attachMediaReq()
deassignCall()
disableNotifications() detachM edi aReq()
getInfoReq()
getNextNotification() getCurrentDestinationAddress()
setChargePlan()
continueProcessi ng()
setAdviceOfCharge()
setChargePla n()
superviseReq()
setA dviceOf Charg e()
supervi seReq()
deassi gn()
getProperties()
setP roperti es()
<>
<>
IpMul ti MediaCallControlManager
<> IpMultiMediaCallLeg <>
(from mmccs)
IpMultiMediaCall (from mmcc s) IpMultiMediaStream
1 0.n 10.n 1 0.n
(from mmccs) (from mmccs)
createMediaNotification()
mediaStreamAllow()
destroyMediaNotification()
supervi seVolumeReq() mediaStreamMonitorReq() subtract()
changeMediaNotification()
getMediaStreams()
getMediaNotification()
Figure 2: Service Interfaces
6 MultiMedia Call Control Service Interface Classes
The MultiMedia Call Control service enhances the functionality of the MultiParty Call Control Service with multi-
media capabilities.
The MultiMedia Call Control Service is represented by the IpMultiMediaCallControlManager, IpMultiMediaCall,
IpMultiMediaCallLeg and IpMultiMediaStream interfaces that interface to services provided by the network. Some
methods are asynchronous, in that they do not lock a thread into waiting whilst a transaction performs. In this way, the
client machine can handle many more calls, than one that uses synchronous message calls. To handle responses and
reports, the developer must implement IpAppMultiMediaCallControlManager, IpAppMultiMediaCall and
IpAppMultiMediaCallLeg to provide the callback mechanism.
To handle the multi-media aspects of a call the concept of media stream is introduced. A media stream is bi-directional
media stream and is associated with a call leg. These media streams are usually negotiated between the terminals in the
call. The multi-party Call Service gives the application control over the media streams associated with the legs in a
multi-media call in the following way:
• the application can be triggered on the establishment of a media stream that meets the application defined
characteristics;
• the application can monitor on the establishment (addition) or release (subtraction) of media streams of an
ongoing call;
• the application can allow or deny the establishment of media streams (provided the stream establishment was
monitored/notified in interrupt mode);
• the application can explicitly subtract already established media streams;
• the application can request the media streams associated with a specific leg.
ETSI
17 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
6.1 Interface Class IpMultiMediaCallControlManager
Inherits from: IpMultiPartyCallControlManager.
The Multi Media Call Control Manager is the factory interface for creating multimedia calls. The multi-media call
control manager interface provides the management functions to the multi-media call control service. The application
programmer can use this interface to create, destroy, change and get media stream related notifications.
This interface shall be implemented by a Multi Media Call Control SCF. As a minimum requirement the
createMediaNotification() and destroyMediaNotification() methods shall be implemented. The minimum required
methods from IpMultiPartyCallControlManager are also required.
<>
IpMultiMediaCallControlManager
createMediaNotification (appInterface: in IpAppMultiMediaCallControlManagerRef, notificationMediaRequest:
in TpNotificationMediaRequest): TpAssignmentID
destroyMediaNotification (assignmentID: in TpAssignmentID): void
changeMediaNotification (assignmentID: in TpAssignmentID, notificationMediaRequest: in
TpNotificationMediaRequest): void
getMediaNotification (): TpMediaNotificationRequestedSet
6.1.1 Method createMediaNotification()
This method is used to create media stream notifications so that events can be sent to the application.
This applies both to callsetup media (e.g. SIP initial INVITE or H.323 with faststart) and for media setup during the
call.
This is the first step an application has to do to get initial notifications of media streams happening in the network.
When such an event happens, the application will be informed by reportMediaNotification(). In case the application is
interested in other events during the context of a particular call session it has to use the mediaStreamMonitorReq()
method on the Multi-Media call leg object.
The createMediaNotification method is purely intended for applications to indicate their interest to be notified when
certain media stream events take place. It is possible to subscribe to a certain media stream event for a whole range of
addresses, e.g. the application can indicate it wishes to be informed when a call is made to any number starting with
800.
If some application already requested notifications with criteria that overlap the specified criteria, the request is refused
with P_INVALID_CRITERIA. The criteria are said to overlap if both originating and terminating ranges overlap and
the same number plan is used.
If the same application invokes this method multiple times with exactly the same criteria but with different callback
references, then these shall be treated as additional callback references. Each such notification request shall share the
same assignmentID. The gateway shall use the most recent callback interface provided by the application using this
method. In the event that a callback reference fails or is no longer available, the next most recent callback reference
available shall be used.
In case the createMediaNotification contains no callback, at the moment the application needs to be informed the
gateway will use as callback the one that has been registered by setCallback().
Returns assignmentID: Specifies the ID assigned by the multi-media call control manager interface for this newly-
created notification.
ETSI
18 Final draft ETSI ES 204 915-4-4 V1.1.1 (2008-02)
Parameters
appInterface: in IpAppMultiMediaCallControlManagerRef
Specifies a reference to the application interface, which is used for callbacks.
notificationMediaRequest: in TpNotificationMediaRequest
The mediaMonitorMode is a parameter of TpMediaStreamRequest and can be in interrupt or in notify mode. If in
interrupt mode the application has to specify which media streams are allowed by calling mediaStreamAllow on the
callLeg.
The notificationMediaRequest parameter specifies the event specific criteria used by the application to define the event
required. This is the media portion of the criteria. Only events that meet the notificationMediaRequest are reported.
Individual addresses or address ranges may be specified for the destination and/or origination.
Returns
TpAssignmentID
Raises
TpCommonExceptions, P_INVALID_CRITERIA, P_INVALID_INTERFACE_TYPE, P_INVALID_EVENT_TYPE
6.1.2 Method destroyMediaNotification()
This method is used by the application to disable Multi Media Channel notifications.
Parameters
assignmentID: in TpAssignmentID
Specifies the assignment ID given by the Multi Media call control manager interface when the previous
enableMediaNotification was called. If the assignment ID does not correspond to one of the valid assignment IDs, the
exception P_INVALID_ASSIGNMENTID will be raised.
Raises
TpCommonExceptions
6.1.3 Method changeMediaNotification()
This method is used by the application to change the event criteria introduced with createMediaNotification. Any stored
criteria associated with the specified assignmentID will be replaced with the specified criteria.
Parameters
assignmentID: in TpAssignmentID
Specifies the ID assigned by the multi-media call control manager interface for the media stream notification. If two
callbacks have been registered under this assign
...
ETSI Standard
Open Service Access (OSA);
Application Programming Interface (API);
Part 4: Call Control;
Sub-part 4: Multi-Media Call Control SCF
(Parlay 6)
�
2 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
Reference
DES/TISPAN-01032-4-04-OSA
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, 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-4 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 MultiMedia Call Control Service Sequence Diagrams .9
4.1 Barring for media combined with call routing, alternative 1.9
4.2 Barring for media combined with call routing, alternative 2.10
4.3 Barring for media, simple.12
4.4 Call Volume charging supervision .13
5 Class Diagrams.15
6 MultiMedia Call Control Service Interface Classes.16
6.1 Interface Class IpMultiMediaCallControlManager.17
6.1.1 Method createMediaNotification().17
6.1.2 Method destroyMediaNotification().18
6.1.3 Method changeMediaNotification().18
6.1.4 Method getMediaNotification().19
6.2 Interface Class IpAppMultiMediaCallControlManager .19
6.2.1 Method reportMediaNotification().19
6.3 Interface Class IpMultiMediaCall .20
6.3.1 Method superviseVolumeReq().20
6.4 Interface Class IpAppMultiMediaCall .21
6.4.1 Method superviseVolumeRes().21
6.4.2 Method superviseVolumeErr().22
6.5 Interface Class IpMultiMediaCallLeg .22
6.5.1 Method mediaStreamAllow().22
6.5.2 Method mediaStreamMonitorReq().23
6.5.3 Method getMediaStreams().23
6.6 Interface Class IpAppMultiMediaCallLeg .23
6.6.1 Method mediaStreamMonitorRes().24
6.7 Interface Class IpMultiMediaStream.24
6.7.1 Method subtract().24
7 MultiMedia Call Control Service State Transition Diagrams .25
8 Multi-Media Call Control Data Definitions .25
8.1 Event Notification Data Definitions.25
8.1.1 TpMediaStreamRequestSet.25
8.1.2 TpMediaStreamRequest.25
8.1.3 TpMediaStreamDirection.25
8.1.4 TpMediaStreamDataTypeRequest.26
8.1.5 TpMediaStreamDataTypeRequestType.26
8.1.6 TpAudioCapabilitiesType.26
8.1.7 TpVideoCapabilitiesType.27
8.1.8 TpDataCapabilities .27
8.1.9 TpMediaStreamEventType.27
8.1.10 TpMediaStreamSet.27
8.1.11 TpMediaStream.27
8.1.12 TpMediaStreamDataType.27
8.2 Multi-Media Call Control Data Definitions .27
8.2.1 IpMultiMediaCall.27
ETSI
4 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
8.2.2 IpMultiMediaCallRef.28
8.2.3 IpAppMultiMediaCall.28
8.2.4 IpAppMultiMediaCallRef.28
8.2.5 IpMultiMediaCallLeg.28
8.2.6 IpMultiMediaCallLegRef.28
8.2.7 IpAppMultiMediaCallLeg.28
8.2.8 IpAppMultiMediaCallLegRef.28
8.2.9 TpAppMultiMediaCallLegRefSet.28
8.2.10 TpMultiMediaCallIdentifier.28
8.2.11 TpMultiMediaCallIdentifierSet.28
8.2.12 TpMultiMediaCallLegIdentifier.28
8.2.13 TpMultiMediaCallLegIdentifierSet .29
8.2.14 IpAppMultiMediaCallControlManager.29
8.2.15 IpAppMultiMediaCallControlManagerRef.29
8.2.16 TpAppMultiMediaCallBack.29
8.2.17 TpAppMultiMediaCallBackRefType.29
8.2.18 TpAppMultiMediaCallLegCallBack.29
8.2.19 TpCallSuperviseVolume.30
8.2.20 TpNotificationMediaRequest.30
8.2.21 TpMediaNotificationRequested.30
8.2.22 TpMediaNotificationsRequestedSet.30
Annex A (normative): OMG IDL Description of Multi-Media Call Control SCF.31
Annex B (informative): W3C WSDL Description of Multi-Media Call Control SCF .32
Annex C (informative): Java API Description of the Call Control SCFs.33
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .34
Annex E (informative): Description of Call Control Sub-part 4: Multimedia call control SCF
for 3GPP2 cdma2000 networks .35
E.1 General Exceptions.35
E.2 Specific Exceptions.35
E.2.1 Clause 1: Scope .35
E.2.2 Clause 2: References .35
E.2.3 Clause 3: Definitions and abbreviations.35
E.2.4 Clause 4: MultiMedia Call Control Service Sequence Diagrams.35
E.2.5 Clause 5: Class Diagrams.35
E.2.6 Clause 6: MultiMedia Call Control Service Interface Classes .35
E.2.7 Clause 7: MultiMedia Call Control Service State Transition Diagrams.36
E.2.8 Clause 8: Multi-Media Call Control Data Definitions.36
E.2.9 Annex A (normative): OMG IDL Description of Multi-Media Call Control SCF.36
E.2.10 Annex B (informative): W3C WSDL Description of Multi-Media Call Control SCF.36
E.2.11 Annex C (informative): Java™ API Description of the Call Control SCF .36
Annex F (informative): Record of changes .37
F.1 Interfaces.37
F.1.1 New.37
F.1.2 Deprecated.37
F.1.3 Removed.37
F.2 Methods.37
F.2.1 New.37
F.2.2 Deprecated.37
F.2.3 Modified.38
F.2.4 Removed.38
F.3 Data Definitions.38
F.3.1 New.38
F.3.2 Modified.38
ETSI
5 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
F.3.3 Removed.38
F.4 Service Properties.38
F.4.1 New.38
F.4.2 Deprecated.38
F.4.3 Modified.39
F.4.4 Removed.39
F.5 Exceptions.39
F.5.1 New.39
F.5.2 Modified.39
F.5.3 Removed.39
F.6 Others.39
History .40
ETSI
6 ETSI ES 204 915-4-4 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 4 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-4 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-4 V7.0.0 (Release 7).
ETSI
8 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
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 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-4 V1.1.1 (2008-05)
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 MultiMe 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 an 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.
ETSI
10 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
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.
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 r eat eM edi aNo ti 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 gnCal l( )
1 6: e ventRep ortRes( )
17: "forward event"
18: deassignCall( )
19: reportMediaNotification( )
20: "forward event"
21: mediaStreamAllow( )
22: deas si gnCal l( )
1: The application creates a new AppMultiMediaCallControlManager interface.
2: The application expresses interest in all calls from subscriber A for rerouting purposes.
ETSI
11 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
3: The application creates a new AppMultiMediaCallControlManager interface. This is to be used for the media
control only.
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.
ETSI
12 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
4.3 Barring for media, simple
This sequence illustrates how an application can block the establishment of video streams for a certain user.
: (Logical : : : :
View::IpAppLogic) IpAppMultiMediaCallControlManager IpMultiMediaCallControlMan. IpMultiMediaCall IpMultiMediaCallLeg
1: new()
2: createMediaNotification( )
3: reportMediaNotification( )
4: "forward event"
5: mediaStreamAllow( )
6: deassignCall( )
1: The application starts a new AppMultiMediaCallControlManager interface for reception of callbacks.
2: The application expresses interest in all calls from or to subscriber A that use video. The just created App
interface is given as the callback interface.
3: Subscriber A makes a call with the SIP INVITE with SDP media stream indicating video.
4: The message is forwarded to the application.
5: The application indicates that the setup of the media stream is not allowed by not including the media stream
in the allowed list. This has the effect of suppressing the video capabilities in the setup.
6: The application is no longer interested in the call.
New attempts to open video streams will again be indicated with a reportMediaNotification.
ETSI
13 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
4.4 Call Volume charging supervision
This sequence illustrates how an application may supervise a call based on the number of bytes that are exchanged.
Note that in the sequence diagram below, a single box represents both an IpAppCall and an IpAppCallLeg for space
reasons.
IpAppCallLeg : : : IpCallLeg : IpUICall IpUIManager :
: (Logical : : IpAppUICall :
IpAppMultiMediaCall IpMultiMediaCall IpUIManager
View::IpAppLogic) IpAppMultiMediaCallControlManager IpMultiMediaCallControlMan.
1: new()
2: setCallback( )
3: new()
4: createCall( )
5: createAndRouteCallLegReq( )
6: new( )
7: eventReportRes( )
8: "f orward event"
9: c reat eAndRouteCallLegReq( )
10: new( )
11: ev entReportRes( )
12: "forward ev ent"
13: superviseVolumeReq( )
14: superviseVolumeRes( )
15: "forward ev ent"
16: createUICall( )
17: sendInfoAndCollectReq( )
18: sendInf oAndCollectRes( )
19: "forward ev ent"
20: release( )
21: superviseVolumeReq( )
22: release( )
1: The application creates a new interface to receive callbacks on the call control manager.
2: The created interface is set as the callback interface for the call control manager.
3: The application creates a new interface to receive callback on the call.
4: The application requests the creation of a call.
5: The application initiates the call by routing to the origination. This will implicitly create a call leg. The
application requests a notification when the party answers.
7: When the A party answers the application is notified.
8: The message is forwarded to the logic.
9: The application also routes the call to the destination. This implicitly creates a call leg. The application
requests to be notified on answer of the B-party.
ETSI
14 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
11: When the B-party answers the application is notified.
12: The message is forwarded to the logic.
13: The application requests to supervise the call. In the request the application specifies a limit on the amount of
bytes that may be transferred. The application specifies that if the limit is reached the application should be
notified.
14: When the limit is reached a notification is send to the application.
15: The message is forwarded to the logic.
17: The application plays an announcement to the user, asking whether the user wants to end the call or continue
the call.
18: When the user answers whether the call should continue.
19: The message is forwarded to the logic.
20: The UIcall is released, since no further announcements are needed.
21: In case the user answers that the call should continue, the supervision is reset with a new maximum number of
allowed bytes. (note that this might have charging consequences, not shown).
22: If the user answered that the call should not continue, the call is released.
ETSI
15 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
5 Class Diagrams
<>
IpAppCallLeg
(f rom mpccs)
<>
<>
IpAppMultiPartyCallControlManager
IpAppMultiPartyCall
eventReportRes()
(f rom mpccs)
(from mpccs)
eventReportErr()
attachMediaRes()
reportNotification()
10.n 10.n
getInfoRes() attachMediaErr()
callAborted()
getInfoErr() detachMediaRes()
managerInterrupted()
superviseRes() detachMediaErr()
managerResumed()
superviseErr() getInfoRes()
callOverloadEncountered()
callEnded() getInfoErr()
callOverloadCeased()
createAndRouteCallLegErr() routeErr()
abortMultipleCalls()
superviseRes()
superviseErr()
callLegEnded()
<>
<>
<>
IpAppMultiMediaCall
IpAppMultiMediaCallControlManager
IpAppMultiMediaCallLeg
(f rom mmccs)
(from mmccs)
(f rom mmccs)
superviseVolumeRes()
reportMediaNotification()
mediaStreamMonitorRes()
superviseVolumeErr()
<>
<>
<>
<>
<>
IpMultiMediaCallControlManager
<> IpMultiMediaCallLeg
(from mmccs)
(f rom mmccs)
IpMultiMediaCall
1 0.n 1 0.n
(f rom mmccs)
createMediaNotification()
mediaStreamAllow()
destroyMediaNotification()
superviseVolumeReq() mediaStreamMonitorReq()
changeMediaNotification()
getMediaStreams()
getMediaNotification()
Figure 1: Application Interfaces
ETSI
16 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
<> <>
IpMultiPartyCallControlManager IpCallLeg
<>
(from mpccs) (from mpccs)
IpMultiPartyCall
(from mpccs)
rout eReq()
createCall()
eventReportReq()
createNotification()
getCallLegs()
rel ease()
destroyNotification()
createCallLeg()
getInfoReq()
changeNotification()
createAndRouteCallLegReq()
getCall()
setCallLoadControl()
release()
enableNotifications() attachMediaReq()
deassignCall()
disableNotifications() detachM edi aReq()
getInfoReq()
getNextNotification() getCurrentDestinationAddress()
setChargePlan()
continueProcessi ng()
setAdviceOfCharge()
setChargePla n()
superviseReq()
setA dviceOf Charg e()
supervi seReq()
deassi gn()
getProperties()
setP roperti es()
<>
<>
IpMul ti MediaCallControlManager
<> IpMultiMediaCallLeg <>
(from mmccs)
IpMultiMediaCall (from mmcc s) IpMultiMediaStream
1 0.n 10.n 1 0.n
(from mmccs) (from mmccs)
createMediaNotification()
mediaStreamAllow()
destroyMediaNotification()
supervi seVolumeReq() mediaStreamMonitorReq() subtract()
changeMediaNotification()
getMediaStreams()
getMediaNotification()
Figure 2: Service Interfaces
6 MultiMedia Call Control Service Interface Classes
The MultiMedia Call Control service enhances the functionality of the MultiParty Call Control Service with multi-
media capabilities.
The MultiMedia Call Control Service is represented by the IpMultiMediaCallControlManager, IpMultiMediaCall,
IpMultiMediaCallLeg and IpMultiMediaStream interfaces that interface to services provided by the network. Some
methods are asynchronous, in that they do not lock a thread into waiting whilst a transaction performs. In this way, the
client machine can handle many more calls, than one that uses synchronous message calls. To handle responses and
reports, the developer must implement IpAppMultiMediaCallControlManager, IpAppMultiMediaCall and
IpAppMultiMediaCallLeg to provide the callback mechanism.
To handle the multi-media aspects of a call the concept of media stream is introduced. A media stream is bi-directional
media stream and is associated with a call leg. These media streams are usually negotiated between the terminals in the
call. The multi-party Call Service gives the application control over the media streams associated with the legs in a
multi-media call in the following way:
• the application can be triggered on the establishment of a media stream that meets the application defined
characteristics;
• the application can monitor on the establishment (addition) or release (subtraction) of media streams of an
ongoing call;
• the application can allow or deny the establishment of media streams (provided the stream establishment was
monitored/notified in interrupt mode);
• the application can explicitly subtract already established media streams;
• the application can request the media streams associated with a specific leg.
ETSI
17 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
6.1 Interface Class IpMultiMediaCallControlManager
Inherits from: IpMultiPartyCallControlManager.
The Multi Media Call Control Manager is the factory interface for creating multimedia calls. The multi-media call
control manager interface provides the management functions to the multi-media call control service. The application
programmer can use this interface to create, destroy, change and get media stream related notifications.
This interface shall be implemented by a Multi Media Call Control SCF. As a minimum requirement the
createMediaNotification() and destroyMediaNotification() methods shall be implemented. The minimum required
methods from IpMultiPartyCallControlManager are also required.
<>
IpMultiMediaCallControlManager
createMediaNotification (appInterface: in IpAppMultiMediaCallControlManagerRef, notificationMediaRequest:
in TpNotificationMediaRequest): TpAssignmentID
destroyMediaNotification (assignmentID: in TpAssignmentID): void
changeMediaNotification (assignmentID: in TpAssignmentID, notificationMediaRequest: in
TpNotificationMediaRequest): void
getMediaNotification (): TpMediaNotificationRequestedSet
6.1.1 Method createMediaNotification()
This method is used to create media stream notifications so that events can be sent to the application.
This applies both to callsetup media (e.g. SIP initial INVITE or H.323 with faststart) and for media setup during the
call.
This is the first step an application has to do to get initial notifications of media streams happening in the network.
When such an event happens, the application will be informed by reportMediaNotification(). In case the application is
interested in other events during the context of a particular call session it has to use the mediaStreamMonitorReq()
method on the Multi-Media call leg object.
The createMediaNotification method is purely intended for applications to indicate their interest to be notified when
certain media stream events take place. It is possible to subscribe to a certain media stream event for a whole range of
addresses, e.g. the application can indicate it wishes to be informed when a call is made to any number starting with
800.
If some application already requested notifications with criteria that overlap the specified criteria, the request is refused
with P_INVALID_CRITERIA. The criteria are said to overlap if both originating and terminating ranges overlap and
the same number plan is used.
If the same application invokes this method multiple times with exactly the same criteria but with different callback
references, then these shall be treated as additional callback references. Each such notification request shall share the
same assignmentID. The gateway shall use the most recent callback interface provided by the application using this
method. In the event that a callback reference fails or is no longer available, the next most recent callback reference
available shall be used.
In case the createMediaNotification contains no callback, at the moment the application needs to be informed the
gateway will use as callback the one that has been registered by setCallback().
Returns assignmentID: Specifies the ID assigned by the multi-media call control manager interface for this newly-
created notification.
ETSI
18 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
Parameters
appInterface: in IpAppMultiMediaCallControlManagerRef
Specifies a reference to the application interface, which is used for callbacks.
notificationMediaRequest: in TpNotificationMediaRequest
The mediaMonitorMode is a parameter of TpMediaStreamRequest and can be in interrupt or in notify mode. If in
interrupt mode the application has to specify which media streams are allowed by calling mediaStreamAllow on the
callLeg.
The notificationMediaRequest parameter specifies the event specific criteria used by the application to define the event
required. This is the media portion of the criteria. Only events that meet the notificationMediaRequest are reported.
Individual addresses or address ranges may be specified for the destination and/or origination.
Returns
TpAssignmentID
Raises
TpCommonExceptions, P_INVALID_CRITERIA, P_INVALID_INTERFACE_TYPE, P_INVALID_EVENT_TYPE
6.1.2 Method destroyMediaNotification()
This method is used by the application to disable Multi Media Channel notifications.
Parameters
assignmentID: in TpAssignmentID
Specifies the assignment ID given by the Multi Media call control manager interface when the previous
enableMediaNotification was called. If the assignment ID does not correspond to one of the valid assignment IDs, the
exception P_INVALID_ASSIGNMENTID will be raised.
Raises
TpCommonExceptions
6.1.3 Method changeMediaNotification()
This method is used by the application to change the event criteria introduced with createMediaNotification. Any stored
criteria associated with the specified assignmentID will be replaced with the specified criteria.
Parameters
assignmentID: in TpAssignmentID
Specifies the ID assigned by the multi-media call control manager interface for the media stream notification. If two
callbacks have been registered under this assignment ID both of them will be changed.
notificationMediaRequest: in TpNotificationMediaRequest
Specifies the new set of event specific criteria used by the application to define the event required. Only events that
meet these criteria are reported.
Raises
TpCommonExceptions, P_INVALID_
...
SLOVENSKI STANDARD
01-september-2008
2GSUWLGRVWRSGRVWRULWYH 26$ $SOLNDFLMVNLSURJUDPVNLYPHVQLN $3, GHO
.UPLOMHQMHNOLFDSRGGHO /DVWQRVWVWRULWYHQH]PRåQRVWL 6&) SULNUPLOMHQMX
YHþSUHGVWDYQRVWQLKNOLFHY 3DUOD\
Open Service Access (OSA) - Application Programming Interface (API) - Part 4: Call
Control - Sub-part 4: Multi-Media Call Control SCF (Parlay 6)
Ta slovenski standard je istoveten z: ES 204 915-4-4 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 4: Multi-Media Call Control SCF
(Parlay 6)
�
2 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
Reference
DES/TISPAN-01032-4-04-OSA
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, 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-4 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 MultiMedia Call Control Service Sequence Diagrams .9
4.1 Barring for media combined with call routing, alternative 1.9
4.2 Barring for media combined with call routing, alternative 2.10
4.3 Barring for media, simple.12
4.4 Call Volume charging supervision .13
5 Class Diagrams.15
6 MultiMedia Call Control Service Interface Classes.16
6.1 Interface Class IpMultiMediaCallControlManager.17
6.1.1 Method createMediaNotification().17
6.1.2 Method destroyMediaNotification().18
6.1.3 Method changeMediaNotification().18
6.1.4 Method getMediaNotification().19
6.2 Interface Class IpAppMultiMediaCallControlManager .19
6.2.1 Method reportMediaNotification().19
6.3 Interface Class IpMultiMediaCall .20
6.3.1 Method superviseVolumeReq().20
6.4 Interface Class IpAppMultiMediaCall .21
6.4.1 Method superviseVolumeRes().21
6.4.2 Method superviseVolumeErr().22
6.5 Interface Class IpMultiMediaCallLeg .22
6.5.1 Method mediaStreamAllow().22
6.5.2 Method mediaStreamMonitorReq().23
6.5.3 Method getMediaStreams().23
6.6 Interface Class IpAppMultiMediaCallLeg .23
6.6.1 Method mediaStreamMonitorRes().24
6.7 Interface Class IpMultiMediaStream.24
6.7.1 Method subtract().24
7 MultiMedia Call Control Service State Transition Diagrams .25
8 Multi-Media Call Control Data Definitions .25
8.1 Event Notification Data Definitions.25
8.1.1 TpMediaStreamRequestSet.25
8.1.2 TpMediaStreamRequest.25
8.1.3 TpMediaStreamDirection.25
8.1.4 TpMediaStreamDataTypeRequest.26
8.1.5 TpMediaStreamDataTypeRequestType.26
8.1.6 TpAudioCapabilitiesType.26
8.1.7 TpVideoCapabilitiesType.27
8.1.8 TpDataCapabilities .27
8.1.9 TpMediaStreamEventType.27
8.1.10 TpMediaStreamSet.27
8.1.11 TpMediaStream.27
8.1.12 TpMediaStreamDataType.27
8.2 Multi-Media Call Control Data Definitions .27
8.2.1 IpMultiMediaCall.27
ETSI
4 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
8.2.2 IpMultiMediaCallRef.28
8.2.3 IpAppMultiMediaCall.28
8.2.4 IpAppMultiMediaCallRef.28
8.2.5 IpMultiMediaCallLeg.28
8.2.6 IpMultiMediaCallLegRef.28
8.2.7 IpAppMultiMediaCallLeg.28
8.2.8 IpAppMultiMediaCallLegRef.28
8.2.9 TpAppMultiMediaCallLegRefSet.28
8.2.10 TpMultiMediaCallIdentifier.28
8.2.11 TpMultiMediaCallIdentifierSet.28
8.2.12 TpMultiMediaCallLegIdentifier.28
8.2.13 TpMultiMediaCallLegIdentifierSet .29
8.2.14 IpAppMultiMediaCallControlManager.29
8.2.15 IpAppMultiMediaCallControlManagerRef.29
8.2.16 TpAppMultiMediaCallBack.29
8.2.17 TpAppMultiMediaCallBackRefType.29
8.2.18 TpAppMultiMediaCallLegCallBack.29
8.2.19 TpCallSuperviseVolume.30
8.2.20 TpNotificationMediaRequest.30
8.2.21 TpMediaNotificationRequested.30
8.2.22 TpMediaNotificationsRequestedSet.30
Annex A (normative): OMG IDL Description of Multi-Media Call Control SCF.31
Annex B (informative): W3C WSDL Description of Multi-Media Call Control SCF .32
Annex C (informative): Java API Description of the Call Control SCFs.33
Annex D (informative): Contents of 3GPP OSA Rel-7 Call Control .34
Annex E (informative): Description of Call Control Sub-part 4: Multimedia call control SCF
for 3GPP2 cdma2000 networks .35
E.1 General Exceptions.35
E.2 Specific Exceptions.35
E.2.1 Clause 1: Scope .35
E.2.2 Clause 2: References .35
E.2.3 Clause 3: Definitions and abbreviations.35
E.2.4 Clause 4: MultiMedia Call Control Service Sequence Diagrams.35
E.2.5 Clause 5: Class Diagrams.35
E.2.6 Clause 6: MultiMedia Call Control Service Interface Classes .35
E.2.7 Clause 7: MultiMedia Call Control Service State Transition Diagrams.36
E.2.8 Clause 8: Multi-Media Call Control Data Definitions.36
E.2.9 Annex A (normative): OMG IDL Description of Multi-Media Call Control SCF.36
E.2.10 Annex B (informative): W3C WSDL Description of Multi-Media Call Control SCF.36
E.2.11 Annex C (informative): Java™ API Description of the Call Control SCF .36
Annex F (informative): Record of changes .37
F.1 Interfaces.37
F.1.1 New.37
F.1.2 Deprecated.37
F.1.3 Removed.37
F.2 Methods.37
F.2.1 New.37
F.2.2 Deprecated.37
F.2.3 Modified.38
F.2.4 Removed.38
F.3 Data Definitions.38
F.3.1 New.38
F.3.2 Modified.38
ETSI
5 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
F.3.3 Removed.38
F.4 Service Properties.38
F.4.1 New.38
F.4.2 Deprecated.38
F.4.3 Modified.39
F.4.4 Removed.39
F.5 Exceptions.39
F.5.1 New.39
F.5.2 Modified.39
F.5.3 Removed.39
F.6 Others.39
History .40
ETSI
6 ETSI ES 204 915-4-4 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 4 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-4 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-4 V7.0.0 (Release 7).
ETSI
8 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
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 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-4 V1.1.1 (2008-05)
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 MultiMe 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 an 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.
ETSI
10 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
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.
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 r eat eM edi aNo ti 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 gnCal l( )
1 6: e ventRep ortRes( )
17: "forward event"
18: deassignCall( )
19: reportMediaNotification( )
20: "forward event"
21: mediaStreamAllow( )
22: deas si gnCal l( )
1: The application creates a new AppMultiMediaCallControlManager interface.
2: The application expresses interest in all calls from subscriber A for rerouting purposes.
ETSI
11 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
3: The application creates a new AppMultiMediaCallControlManager interface. This is to be used for the media
control only.
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.
ETSI
12 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
4.3 Barring for media, simple
This sequence illustrates how an application can block the establishment of video streams for a certain user.
: (Logical : : : :
View::IpAppLogic) IpAppMultiMediaCallControlManager IpMultiMediaCallControlMan. IpMultiMediaCall IpMultiMediaCallLeg
1: new()
2: createMediaNotification( )
3: reportMediaNotification( )
4: "forward event"
5: mediaStreamAllow( )
6: deassignCall( )
1: The application starts a new AppMultiMediaCallControlManager interface for reception of callbacks.
2: The application expresses interest in all calls from or to subscriber A that use video. The just created App
interface is given as the callback interface.
3: Subscriber A makes a call with the SIP INVITE with SDP media stream indicating video.
4: The message is forwarded to the application.
5: The application indicates that the setup of the media stream is not allowed by not including the media stream
in the allowed list. This has the effect of suppressing the video capabilities in the setup.
6: The application is no longer interested in the call.
New attempts to open video streams will again be indicated with a reportMediaNotification.
ETSI
13 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
4.4 Call Volume charging supervision
This sequence illustrates how an application may supervise a call based on the number of bytes that are exchanged.
Note that in the sequence diagram below, a single box represents both an IpAppCall and an IpAppCallLeg for space
reasons.
IpAppCallLeg : : : IpCallLeg : IpUICall IpUIManager :
: (Logical : : IpAppUICall :
IpAppMultiMediaCall IpMultiMediaCall IpUIManager
View::IpAppLogic) IpAppMultiMediaCallControlManager IpMultiMediaCallControlMan.
1: new()
2: setCallback( )
3: new()
4: createCall( )
5: createAndRouteCallLegReq( )
6: new( )
7: eventReportRes( )
8: "f orward event"
9: c reat eAndRouteCallLegReq( )
10: new( )
11: ev entReportRes( )
12: "forward ev ent"
13: superviseVolumeReq( )
14: superviseVolumeRes( )
15: "forward ev ent"
16: createUICall( )
17: sendInfoAndCollectReq( )
18: sendInf oAndCollectRes( )
19: "forward ev ent"
20: release( )
21: superviseVolumeReq( )
22: release( )
1: The application creates a new interface to receive callbacks on the call control manager.
2: The created interface is set as the callback interface for the call control manager.
3: The application creates a new interface to receive callback on the call.
4: The application requests the creation of a call.
5: The application initiates the call by routing to the origination. This will implicitly create a call leg. The
application requests a notification when the party answers.
7: When the A party answers the application is notified.
8: The message is forwarded to the logic.
9: The application also routes the call to the destination. This implicitly creates a call leg. The application
requests to be notified on answer of the B-party.
ETSI
14 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
11: When the B-party answers the application is notified.
12: The message is forwarded to the logic.
13: The application requests to supervise the call. In the request the application specifies a limit on the amount of
bytes that may be transferred. The application specifies that if the limit is reached the application should be
notified.
14: When the limit is reached a notification is send to the application.
15: The message is forwarded to the logic.
17: The application plays an announcement to the user, asking whether the user wants to end the call or continue
the call.
18: When the user answers whether the call should continue.
19: The message is forwarded to the logic.
20: The UIcall is released, since no further announcements are needed.
21: In case the user answers that the call should continue, the supervision is reset with a new maximum number of
allowed bytes. (note that this might have charging consequences, not shown).
22: If the user answered that the call should not continue, the call is released.
ETSI
15 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
5 Class Diagrams
<>
IpAppCallLeg
(f rom mpccs)
<>
<>
IpAppMultiPartyCallControlManager
IpAppMultiPartyCall
eventReportRes()
(f rom mpccs)
(from mpccs)
eventReportErr()
attachMediaRes()
reportNotification()
10.n 10.n
getInfoRes() attachMediaErr()
callAborted()
getInfoErr() detachMediaRes()
managerInterrupted()
superviseRes() detachMediaErr()
managerResumed()
superviseErr() getInfoRes()
callOverloadEncountered()
callEnded() getInfoErr()
callOverloadCeased()
createAndRouteCallLegErr() routeErr()
abortMultipleCalls()
superviseRes()
superviseErr()
callLegEnded()
<>
<>
<>
IpAppMultiMediaCall
IpAppMultiMediaCallControlManager
IpAppMultiMediaCallLeg
(f rom mmccs)
(from mmccs)
(f rom mmccs)
superviseVolumeRes()
reportMediaNotification()
mediaStreamMonitorRes()
superviseVolumeErr()
<>
<>
<>
<>
<>
IpMultiMediaCallControlManager
<> IpMultiMediaCallLeg
(from mmccs)
(f rom mmccs)
IpMultiMediaCall
1 0.n 1 0.n
(f rom mmccs)
createMediaNotification()
mediaStreamAllow()
destroyMediaNotification()
superviseVolumeReq() mediaStreamMonitorReq()
changeMediaNotification()
getMediaStreams()
getMediaNotification()
Figure 1: Application Interfaces
ETSI
16 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
<> <>
IpMultiPartyCallControlManager IpCallLeg
<>
(from mpccs) (from mpccs)
IpMultiPartyCall
(from mpccs)
rout eReq()
createCall()
eventReportReq()
createNotification()
getCallLegs()
rel ease()
destroyNotification()
createCallLeg()
getInfoReq()
changeNotification()
createAndRouteCallLegReq()
getCall()
setCallLoadControl()
release()
enableNotifications() attachMediaReq()
deassignCall()
disableNotifications() detachM edi aReq()
getInfoReq()
getNextNotification() getCurrentDestinationAddress()
setChargePlan()
continueProcessi ng()
setAdviceOfCharge()
setChargePla n()
superviseReq()
setA dviceOf Charg e()
supervi seReq()
deassi gn()
getProperties()
setP roperti es()
<>
<>
IpMul ti MediaCallControlManager
<> IpMultiMediaCallLeg <>
(from mmccs)
IpMultiMediaCall (from mmcc s) IpMultiMediaStream
1 0.n 10.n 1 0.n
(from mmccs) (from mmccs)
createMediaNotification()
mediaStreamAllow()
destroyMediaNotification()
supervi seVolumeReq() mediaStreamMonitorReq() subtract()
changeMediaNotification()
getMediaStreams()
getMediaNotification()
Figure 2: Service Interfaces
6 MultiMedia Call Control Service Interface Classes
The MultiMedia Call Control service enhances the functionality of the MultiParty Call Control Service with multi-
media capabilities.
The MultiMedia Call Control Service is represented by the IpMultiMediaCallControlManager, IpMultiMediaCall,
IpMultiMediaCallLeg and IpMultiMediaStream interfaces that interface to services provided by the network. Some
methods are asynchronous, in that they do not lock a thread into waiting whilst a transaction performs. In this way, the
client machine can handle many more calls, than one that uses synchronous message calls. To handle responses and
reports, the developer must implement IpAppMultiMediaCallControlManager, IpAppMultiMediaCall and
IpAppMultiMediaCallLeg to provide the callback mechanism.
To handle the multi-media aspects of a call the concept of media stream is introduced. A media stream is bi-directional
media stream and is associated with a call leg. These media streams are usually negotiated between the terminals in the
call. The multi-party Call Service gives the application control over the media streams associated with the legs in a
multi-media call in the following way:
• the application can be triggered on the establishment of a media stream that meets the application defined
characteristics;
• the application can monitor on the establishment (addition) or release (subtraction) of media streams of an
ongoing call;
• the application can allow or deny the establishment of media streams (provided the stream establishment was
monitored/notified in interrupt mode);
• the application can explicitly subtract already established media streams;
• the application can request the media streams associated with a specific leg.
ETSI
17 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
6.1 Interface Class IpMultiMediaCallControlManager
Inherits from: IpMultiPartyCallControlManager.
The Multi Media Call Control Manager is the factory interface for creating multimedia calls. The multi-media call
control manager interface provides the management functions to the multi-media call control service. The application
programmer can use this interface to create, destroy, change and get media stream related notifications.
This interface shall be implemented by a Multi Media Call Control SCF. As a minimum requirement the
createMediaNotification() and destroyMediaNotification() methods shall be implemented. The minimum required
methods from IpMultiPartyCallControlManager are also required.
<>
IpMultiMediaCallControlManager
createMediaNotification (appInterface: in IpAppMultiMediaCallControlManagerRef, notificationMediaRequest:
in TpNotificationMediaRequest): TpAssignmentID
destroyMediaNotification (assignmentID: in TpAssignmentID): void
changeMediaNotification (assignmentID: in TpAssignmentID, notificationMediaRequest: in
TpNotificationMediaRequest): void
getMediaNotification (): TpMediaNotificationRequestedSet
6.1.1 Method createMediaNotification()
This method is used to create media stream notifications so that events can be sent to the application.
This applies both to callsetup media (e.g. SIP initial INVITE or H.323 with faststart) and for media setup during the
call.
This is the first step an application has to do to get initial notifications of media streams happening in the network.
When such an event happens, the application will be informed by reportMediaNotification(). In case the application is
interested in other events during the context of a particular call session it has to use the mediaStreamMonitorReq()
method on the Multi-Media call leg object.
The createMediaNotification method is purely intended for applications to indicate their interest to be notified when
certain media stream events take place. It is possible to subscribe to a certain media stream event for a whole range of
addresses, e.g. the application can indicate it wishes to be informed when a call is made to any number starting with
800.
If some application already requested notifications with criteria that overlap the specified criteria, the request is refused
with P_INVALID_CRITERIA. The criteria are said to overlap if both originating and terminating ranges overlap and
the same number plan is used.
If the same application invokes this method multiple times with exactly the same criteria but with different callback
references, then these shall be treated as additional callback references. Each such notification request shall share the
same assignmentID. The gateway shall use the most recent callback interface provided by the application using this
method. In the event that a callback reference fails or is no longer available, the next most recent callback reference
available shall be used.
In case the createMediaNotification contains no callback, at the moment the application needs to be informed the
gateway will use as callback the one that has been registered by setCallback().
Returns assignmentID: Specifies the ID assigned by the multi-media call control manager interface for this newly-
created notification.
ETSI
18 ETSI ES 204 915-4-4 V1.1.1 (2008-05)
Parameters
appInterface: in IpAppMultiMediaCallControlManagerRef
Specifies a reference to the application interface, which is used for callbacks.
notificationMediaRequest: in TpNotificationMediaRequest
The mediaMonitorMode is a parameter of TpMediaStreamRequest and can be in interrupt or in notify mode. If in
interrupt mode the application has to specify which media streams are allowed by calling mediaStreamAllow on the
callLeg.
The notificationMediaRequest parameter specifies the event specific criteria used by the application to define the event
required. This is the media portion of the criteria
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...