3GPP IMS and UMTS Specifications -- 29.198 OSA Series:
Open Service Access -- API Specifications
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Technical Report 3GPP TR 29.998 consists of a series of parts and subparts. An effort has been made to ensure that the part numbers used in the mapping TR correspond to the part numbers of the base OSA specification in 3GPP TS 29.198. For this reason, certain parts, for which no suitable mapping could be suggested, have not been delivered. At a later stage a mapping to a new protocol may become evident, in which case these missing parts will be developed.
If mapping for a certain Part is "Not Applicable" it can either indicate that a mapping does not exist (e.g. Part 2: Common Data), or the API is considered to be implemented directly on a physical entity, or via a proprietary mechanism.
|
|
|
|
|
|
| | |
3GPP TS 29.198
-01 |
CP |
|
OSA API - Part 1: Overview |
This TS is the first part of the 3GPP Specification defining the Application Programming Interface (API)
for Open Service Access (OSA), and provides an overview of the content and structure of the various parts
of this specification, and of the relation to other standards documents.
The OSA-specifications define an architecture that enables service application developers to make use
of network functionality through an open standardised interface, i.e. the OSA APIs.
The concepts and the functional architecture for the OSA are contained in
3GPP TS 23.198.
The requirements for OSA are contained in
3GPP TS 22.127.
This specification has been defined jointly between 3GPP TSG CT WG5, ETSI TISPAN and The Parlay Group,
in co-operation with a number of JAIN (TM) Community member companies.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TR 29.998
-01 |
CP |
|
API Mapping for OSA -
Part 1: General Issues on API Mapping |
This TR
is suggesting a mapping of the Application Programming Interface (API) for Open Service Access (OSA) onto CAMEL Application Part (CAP) operations and Mobile Application Part (MAP) operations, and provides an overview of the content and structure of the various parts of the present document.
The mapping of the OSA API to the CAP and relevant MAP operations is considered informative and not normative.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-02 |
CP |
|
OSA API - Part 2: Common Data Definitions |
This TS specifies the Common Data definitions of the OSA.
The Common Data definitions contain data-types that are common across the rest of the OSA API.
All aspects of the Common Data are defined here, these being:
| - |
Data definitions;
|
| - |
IDL (Interface Definition Language) description of the data types;
|
| - |
WSDL (Web Services Description Language) description of the data types;
|
| - |
Reference to the Java (TM) API description of the data types.
|
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-03 |
CP |
|
OSA API - Part 3: Framework |
The Framework API contains interfaces between the Application Server and the Framework, and between Network Service Capability Server (SCS) and the Framework (these interfaces are represented by the yellow circles in the figure below). The description of the Framework in the present document separates the interfaces into two distinct sets: Framework to Application interfaces and Framework to Service interfaces.
|
|
Some of the mechanisms are applied only once (e.g. establishment of service agreement), others are applied each time a user subscription is made to an application (e.g. enabling the call attempt event for a new user).
Basic mechanisms between Application and Framework:
|
| - |
Authentication: Once an off-line service agreement exists, the application can access the authentication interface. The authentication model of OSA is a peer-to-peer model, but authentication does not have to be mutual.
The application must be authenticated before it is allowed to use any other OSA interface. It is a policy decision for the application whether it must authenticate the framework or not. It is a policy decision for the framework whether it allows an application to authenticate it before it has completed its authentication of the application.
| |
| - |
Authorisation: Authorisation is distinguished from authentication in that authorisation is the action of determining what a previously authenticated application is allowed to do. Authentication shall precede authorisation. Once authenticated, an application is authorised to access certain SCFs.
| |
| - |
Discovery of Framework and network SCFs: After successful authentication, applications can obtain available Framework interfaces and use the discovery interface to obtain information on authorised network SCFs.
The Discovery interface can be used at any time after successful authentication.
| |
| - |
Establishment of service agreement: Before any application can interact with a network SCF, a service agreement shall be established. A service agreement may consist of an off-line (e.g. by physically exchanging documents) and an on-line part. The application has to sign the on-line part of the service agreement before it is allowed to access any network SCF.
| |
| - |
Access to network SCFs: The Framework shall provide access control functions to authorise the access to SCFs or service data for any API method from an application, with the specified security level, context, domain, etc.
| |
Basic mechanism between Framework and Service Capability Server (SCS):
|
| - |
Registering of network SCFs: SCFs offered by a SCS can be registered at the Framework. In this way the Framework can inform the Applications upon request about available SCFs (Discovery). For example, this mechanism is applied when installing or upgrading an SCS.
| |
All aspects of the Framework are defined in the present document, 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 (TM) 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).
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-04-1 |
CP |
|
OSA API - Part 4: Call Control -
Sub-part 1: Call Control Common Definitions |
Four flavours of Call Control (CC) APIs have been included in 3GPP Release 7. These are Generic Call Control (GCC), Multi-Party Call Control (MPCC), Multi-Media Call Control (MMCC) and Conference Call Control (CCC). The GCC is the same API as was already present in the Release 99 specification (TS 29.198 v3.3.0). Multi-Party Call Contorl was introduced in the Release 4 specifications, and Multi-Media Call Control is introduced in Release 5. Conference Call Control was introduced in Release 7.
The joint work between 3GPP CT5, ETSI TISPAN and the Parlay CC Working group with collaboration from JAIN has been focussed on the MPCC and MMCC APIs. A number of improvements on CC functionality have been made and are reflected in these APIs. For this it was necessary to break the inheritance that previously existed between GCC and MPCC.
The joint CC group has furthermore decided that the MPCC is to be considered as the future base CC family and the technical work will not be continued on GCC. Errors or technical flaws will of course be corrected.
This TS specifies the Common Definitions used by the Call Control Service Capability Features (SCF).
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-04-2 |
CP |
|
OSA API - Part 4: Call Control -
Sub-part 2: Generic Call Control SCF |
The Generic Call Control Service (GCCS) provides the basic call control service for the API. It is based around a third party model, which allows calls to be instantiated from the network and routed through the network.
The GCCS supports enough functionality to allow call routing and call management for today's Intelligent Network (IN) services in the case of a switched telephony network, or equivalent for packet based networks.
It is the intention of the GCCS that it could be readily specialised into call control specifications, for example, ITU-T Recommendations H.323, Q.763 ISUP, Q.931 and Q.2931, ATM Forum specification UNI3.1 and RFC 3261 Session Initiation Protocol, or any other call control technology.
For the generic call control service, only a subset of the call model defined in clause 4 is used; the API for generic call control does not give explicit access to the legs and the media channels. This is provided by the Multi-Party Call Control Service. Furthermore, the generic call is restricted to two party calls, i.e. only two legs are active at any given time. Active is defined here as 'being routed' or connected.
The GCCS is represented by the IpCallControlManager and IpCall 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 IpAppCallControlManager and IpAppCall to provide the callback mechanism.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-04-3 |
CP |
|
OSA API - Part 4: Call Control -
Sub-part 3: Multi-Party Call Control SCF |
The Multi-party Call Control service enhances the functionality of the Generic Call Control Service with leg management. It also allows for multi-party calls to be established, i.e. up to a service specific number of legs can be connected simultaneously to the same call.
The Multi-party Call Control Service is represented by the IpMultiPartyCallControlManager, IpMultiPartyCall, IpCallLeg 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 IpAppMultiPartyCallControlManager, IpAppMultiPartyCall and IpAppCallLeg to provide the callback mechanism.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-04-4 |
CP |
|
OSA API - Part 4: Call Control -
Sub-part 4: Multimedia Call Control SCF |
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 IpAppMultiMedia CallLeg 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 (substraction) 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.
|
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-04-5 |
CP |
|
OSA API - Part 4: Call Control -
Sub-part 5: Conference Call Control SCF |
The Conference call control Service enhances the multi-media call control service. The conference call control service gives the application the ability to manipulate subconferences within a conference. A subconference defines the grouping of legs within the overall conference call. Only parties in the same subconference have a bearer connection (or media channel connection) to each other (e.g. can speak to each other). The application can:
|
| - |
create new subconferences within the conference, either as an empty subconference or by splitting an existing subconference in two subconferences;
| |
| - |
move legs between subconferences;
| |
| - |
merge subconferences;
| |
| - |
get a list of all subconferences in the call;
|
The generic conference also gives the possibility to manipulate typical multi-media conference details, such as:
|
| - |
interworking with network signalled conference protocols (e.g. H.323);
| |
| - |
manipulation of the media in the MCU, e.g., broadcasting of video;
| |
| - |
handling of multi-media conference policies, e.g., how video should be handled, voice controlled switched or chair controlled.
|
Furthermore the conference call control service adds support for the reservation of resources needed for conferencing. The application can:
|
| - |
reserve resources for a predefined time period;
| |
| - |
free reserved resources;
| |
| - |
search for the availability of conference resources based on a number of criteria.
|
There are two ways to initiate a conference:
|
| - |
the conferences can be started on the pre-arranged time by the service, at the start time indicated in the reservation. The application is notified about this. The application can then add parties to the conference and/or parties can dial-in to the conference using the address provided during reservation;
| |
| - |
the conference can be created directly on request of the application using the createConference method in the IpConfCallControlManager interface.
|
Each Conference call control interface inherits from a Multi Media Call Control interface, which in turn inherits from Multi Party Call Control. It is possible to implement conference call control without any multi-media features, using only those inherited methods which come from Multi Party Call Control, in addition to the Conference call control methods. The minimum required method set for each Conference call control interface reflects this possibility, by not requiring the Multi Media Call Control methods.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TR 29.998
-04-4 |
CP |
|
OSA API - Mapping for OSA -
Part 4: Call Control Service Mapping;
Subpart 4: Multiparty Call Control ISC |
|
This TR investigates how the OSA Call Control Interface Class methods defined in
3GPP TS 29.198-4-1/4
can be mapped onto SIP methods.
The mapping of the OSA API to the SIP is considered informative, and not normative.
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 API specification is contained in the 3GPP TS 29.198 series of specifications.
The concepts and the functional architecture for the Open Service Access (OSA)
are described by
3GPP TS 23.198.
The requirements for OSA are defined in
3GPP TS 22.127.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-05 |
CP |
|
OSA API - Part 5: User Interaction SCF |
The Generic User Interaction service capability feature is used by applications to interact with end users. It consists of three interfaces:
|
| 1) |
User Interaction Manager, containing management functions for User Interaction related issues.
| |
| 2) |
Generic User Interaction, containing methods to interact with an end-user.
| |
| 3) |
Call User Interaction, containing methods to interact with an end-user engaged in a call.
|
The Generic User Interaction service capability feature is described in terms of the methods in the Generic User Interaction interfaces.
The Generic User Interaction Service interface (GUIS) is used by applications to interact with end users. The GUIS is represented by the IpUIManager, IpUI and IpUICall interfaces that interface to services provided by the network.
To handle responses and reports, the developer must implement IpAppUIManager and IpAppUI interfaces to provide the callback mechanism.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-06 |
CP |
|
OSA API - Part 6: Mobility SCF |
The User Location service (UL) provides a general geographic location service. UL has functionality to allow applications to obtain the geographical location and the status of fixed, mobile and IP based telephony users.
UL is supplemented by User Location Camel service (ULC) to provide information about network related information. There is also some specialised functionality to handle emergency calls in the User Location Emergency service (ULE).
The UL service provides the IpUserLocation and IpTriggeredUserLocation interfaces. Most 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 IpAppUserLocation and IpAppTriggeredUserLocation interfaces to provide the callback mechanism.
When periodic or triggered location reporting is used, errors may be reported either when the recurrent reporting is requested, as an error per user in reports or in the corresponding err-method when the error concerns all subscribers in an assignment.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Rapporteur: Tarek Nadour
Note: For R5 and R6, it was TR-29998-06 instead of TR-29998-06-1 |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Rapporteur: Tarek Nadour |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-07 |
CP |
|
OSA API - Part 7: Terminal Capabilities SCF |
|
The Terminal Capabilities SCF enables the application to retrieve the terminal capabilities of the specified terminal. Additionally it is possible for the application to request notifications when the capabilities of the terminal change in some way.
The Terminal Capabilities service provides SCF interfaces IpTerminalCapabilities and IpExtendedTerminalCapabilities. The application side interface for the reporting is called IpAppExtendedTerminalCapabilities.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-08 |
CP |
|
OSA API - Part 8: Data Session Control SCF |
The Data Session Control provides a means to control per data session basis the establishment of a new data session. This means especially in the GPRS context that the establishment of a PDP session is modelled not the attach/detach mode. Change of terminal location is assumed to be managed by the underlying network and is therefore not part of the model. The underlying assumption is that a terminal initiates a data session and the application can reject the request for data session establishment, can continue the establishment or can continue and change the destination as requested by the terminal.
The modelling is similar to the Generic Call Control but assumes a simpler underlying state model. An IpDataSessionControlManager object and an IpDataSession object are the interfaces used by the application, whereas the IpAppDataSessionControlManager and the IpAppDataSession interfaces are implemented by the application.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-10 |
CP |
|
OSA API - Part 10: Connectivity Manager SCF |
Connectivity Manager includes the APIs between the enterprise operator and the provider network for the two parties to establish QoS parameters for enterprise network packets travelling through the provider network.
The Connectivity Manager service provides tools for the enterprise operator to set up a Provisioned QoS service in the provider network. The QoS measures used in the enterprise network are outside the scope of the service. The API does not require any specific QoS method to be used in the enterprise network, nor in the provider network. However, in order for Provisioned QoS service to be applied to packets arriving from the enterprise network into the provider network, the packets have to be marked using DS Codepoint marking. Once the packets are so marked, they can enjoy the QoS service provisioned in the provider network.
APIs provide the enterprise network operator on-line access to provision quality of service measures that control the enterprise's own traffic passing through the provider network. Using APIs the operator can create Virtual Provisioned Pipes (VPrPs) in the provider network to carry the enterprise traffic and support it with pre-specified quality of service attributes. A VPrP can be thought of as a Virtual Leased Line (VLL) provisioned to deliver pre-specified QoS. The provider may offer to the enterprise operator a set of templates that are used by the operator to specify a VPrP. For instance, the provider may offer templates for video conferencing, audio conferencing, Gold Service, Silver Service, etc. Using these templates the operator can select and provision a VPrP that specifies the quality of service attributes for this VPrP.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-11 |
CP |
|
OSA API - Part 11: Account Management SCF |
The account manager interface IpAccountManager provides methods for managing accounts. Applications can use this interface to enable or disable charging-related event notifications and to manage account balances. Vouchers allow indirect references to amounts that can be applied to the account.
The account manager application interface IpAppAccountManager is implemented by the client application developer and is used to handle charging event notifications and query balance responses.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-12 |
CP |
|
OSA API - Part 12: Charging SCF |
The Charging SCF is used by applications to charge for the usage of the applications. The charged user can be the same user as that uses the application. It is also possible that another user will pay the charge.
In the interfaces of the Charging SCF a "Request Number" is used when invoking operations that operate on the user's account (directly or indirectly via reservations) in order to make retries possible after application, service, or communication errors. A retry of these operations can be done by invoking the same operation with the same Request Number.
In the callback to the application, the Request Number to be used for the next request operation is returned. This is the only Request Number besides the one in the last request operation that can be used. This mechanism ensures that an application retries an operation when it does not receive an answer.
The use of the Request Number ensures that there can only be one outstanding request per Charging Session. Only after an answer is received (result or error), the next request can be made. Note however that only asynchronous operations that could lead to over or under charging of the user require a request number.
Because responses from the Charging SCF can be delayed in the network the Charging SCF shall guarantee that Request Numbers are unique in a timespan where delayed responses can arrive. Suppose, for example, that the response from a retried request is received indicating the next request number to use is 1 000. During the period that the response to the original request (which also carries the next request number to use equal to 1 000) can arrive, this request number may not be used again.
The units (of different types) that are used in a TpVolumeSet are NOT consolidated by the charging SCF. The application must use the same units when making the reservation and when debiting the amount. For example, when after a reservation of 10 minutes a debit request for 5 seconds is done, an error will be returned.
Split Charging Functionality:
There are cases where a single instance of the merchant application may serve more than a one service user. Examples are multi-user games or conferences. Typically, the costs for the resources consumed by the single service instance will be split among all service users.
On the other hand, a merchant application may show advertisements within its application, and in turn the company that is advertised may subside a certain percentage of the application cost. A consumer connecting to the merchant application pays only part of the costs, while the remainder is paid by the advertised company.
To support this kind of application, multiple users can be specified when a charging session is created. The charging session interface itself is the same no matter if the split charging feature is used or not.
It is subject to service level agreements that are negotiated between the OSA client provider and the network operator how the charge is split between the users.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-13 |
CP |
|
OSA API - Part 13: Policy Management SCF |
This TS specifies the Policy Management Service Capability Feature (SCF) aspects of the interface.
The process by which this task is accomplished is through the use of object modelling techniques described
by the Unified Modelling Language (UML).
It is expected that more and more OSA services will use policies to express operational criteria.
It is also expected that network providers will host policy-enabled services that have been written by 3rd party application service providers. In order to manage policy information, control access to it and to request evaluation of policies a policy management service is needed.
Consistent with this, a policy management provisioning manager, IpPolicyManager, and a policy evaluation manager, IpPolicyEvalManager have been defined.
APIs have been defined to offer provisioning services. These include APIs to create, update or view policy information for any policy enabled service. Similarly APIs have been defined to facilitate interactions between clients (e.g. a 3rd party application) and the policies of any policy enabled service. These include APIs to subscribe to policy events, to request evaluation of policies and to request the generation of policy events. All APIs conform to an underlying policy information model that is a derived from the policy core information model defined by the IETF in RFC 3460.
Clients that perform administrative tasks of behalf of a policy enabled service, e.g. create, update or delete policy information must obtain access to IpPolicyManager via the Framework. Administrative tasks may then be performed through methods supported by IpPolicyManager. Similarly, clients that need to invoke evaluation of policies of a specific policy enabled service may do so by obtaining access to IpPolicyEvalManager via the Framework.
Consistent with the above the Policy Management Service supports two classes of service interfaces for policy provisioning and policy evaluation. These are the PM Provisioning SCF and the PM Policy Evaluation SCF respectively.
Examples of policy enabled services include: A load balancing service that uses policies to manage application loads on the network, a charging service that determines charging criteria based on policies, a call management service that uses policies to direct end-user calls to appropriate call agents, etc.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-14 |
CP |
|
OSA API - Part 14: Presence and Availability Management (PAM) SCF |
PAM consists of the following SCFs
|
| - |
PAM Provisioning Service
| |
| - |
PAM Access Service
| |
| - |
PAM Event Service
|
The PAM Provisioning service consists of the Identity Management, Agent Management, Agent Assignment, Agent Type Management, Identity Type Management and Capability Management interfaces.
The PAM Access service consists of the identity presence and availability interfaces.
The Event service consists of the Event Management interfaces.
An implementation of this API which supports or implements a method described in the present document, shall support or implement the functionality described for that method, for at least one valid set of values for the parameters of that method. Where a method is not supported by an implementation of a Service interface, the exception P_METHOD_NOT_SUPPORTED shall be returned to any call of that method.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-15 |
CP |
|
OSA API - Part 15: Multi-media Messaging (MM) SCF |
The MultiMedia Messaging SCF (MMM SCF) is used by applications to send, store and receive messages either from within the context of a mailbox paradigm, or outside of it. MMM SCF also supports voice mail and electronic mail as the messaging mechanisms. The messaging service interface can be used by both.
The MMM SCF is represented by the IpMultiMediaMessagingManager, IpMailbox and IpMultiMediaMessaging interfaces to services provided by the network.
To handle responses and reports, the developer must implement IpAppMultiMedia MessagingManager to provide the callback mechanism for the MultiMediaMessaging service manager.
The MMM SCF also supports messaging in the context of Instant Messaging (IM), SMS, MMS, GSM USSD etc., These contexts, IM in particular, may support communication in either the page mode or the session mode. The reader is encouraged to refer to "The Message Session Relay Protocol" work being done in the IETF for more details.
A messaging system that is conformant with the mailbox paradigm is assumed to have the following entities:
|
| - |
Mailboxes. This is the application's main entry point to the messaging system. The framework may or may not need to authenticate an application before it accesses a mailbox
| |
| - |
Folders. Folders may have sub-folders. The names of these sub-folders are appended to their parents' names with '/' as the delimiter. For instance, if there is a folder called INBOX and a sub-folder in INBOX called 'Personal' and a sub-folder in that folder called 'archive' then the fully qualified names, which are required for all operations, of the three folders are 'INBOX', 'INBOX/Personal', and 'INBOX/Personal/archive'. The names are case sensitive.
| |
| - |
Messages. Messages are stored in folders. Messages consist of a message header and message body.
Non-mailbox paradigm messaging is supported through the IpMultiMediaMessagingManager and IpMultiMediaMessaging interfaces.
|
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.198
-16 |
CP |
|
OSA API - Part 16: Service Broker SCF |
The Service Broker SCF enables the application to register its interest in particular traffic as part of service interactions. The Service Broker service provides a SCF interface that is called IpServiceBroker.
There is no need for an application interface, since IpServiceBroker only contains two synchronous methods registerServiceInteraction and unregisterServiceInteraction.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
|
|
