Telephony Framework API

1.0 References

• 3GPP TS 24.008 Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)
  
• 3GPP TS 22.030 Man-Machine Interface (MMI) of the User Equipment (UE) (Release 5)
  
• 3GPP TS 24.080 supplementary services specification (Release 5)
  
• 3GPP TS 23.038 Alphabets and language-specific information (Release 5)
  
• 3GPP TS 23.040 Technical realization of the Short Message Service (SMS) (Release 5)
  
• 3GPP TS 29.002 Mobile Application Part (MAP) specification (Release 5)
  
• 3GPP TS 31.102 Characteristics of the USIM application (Release 5)
  
• 3GPP TS 22.084 MultiParty (MPTY) Supplementary Services - Stage 1 (Release 5)
  
• 3GPP TS 23.014 Support of Dual Tone Multi Frequency (DTMF) signaling (Release 5)
  

2.0 Overview

• Call Services
• Supplementary Service
• Unstructured Supplementary Data
• Network Registration
• SIM
• SMS

2.1 Definitions, Acronyms, and Abbreviations

• TAPI: Telephony API library is responsible for carrying Application (user) requests to Telephony Server for various telephony services.
• Telephony Server: It is a process which receives the Application requests from multiple applications for various telephony services.
• OEM Adaptation Layer: This layer hides the underlying wireless stack and its interface part.. This allows the flexibility to port any underlying modem according to vendor requirement or business model. This abstracts the inter process communication used for single processor / dual processor model. This layer is vendor implementation specific.
• OEM Adaptation Layer Plug-in APIs: Telephony Server will call OEM Adaptation Layer Plug-in APIs to serve for application requests for various telephony related services. Also Indication/Response/Confirmation APIs are defined in this document which will be used by the OEM Adaptation layer in order to pass the responses/indications to Telephony Server. Telephony Server will generate events and publish it to application.

2.2 Execution Model

2.2.1 Telephony Logical Architecture

Figure 1. Telephony Logical Architecture

2.2.2 Call Flows

Figure 2. Call Flow Explains Request and Response Scenario

Figure 3. Call Flow Explains Indication and Response Fcenario

2.2.3 Roles of LiMo OEM Adaptation Layer Plugin

2.3 General Programming Considerations

1. OEM Adaptation layer Plug-in API calls should be non-blocking call. If it is a blocking call, then it will degrade the performance of Telephony Server.
   
   
2. As OEM Adaptation Layer is a plug-in, All OEM Adaptation Layer Plug-in Request (Req) APIs and Response (Rsp) APIs handling shall be implemented by Vendor.
   
   
3. OEM Adaptation layer has to call the appropriate Indications/Responses API(defined in Indications/Responses Section of this document) provided by the Telephony Server in order to pass responses/notification to the Application.
   
   
4. Return value of OEM Adaptation Layer plug-in Request API only implies whether request is sent successfully or not to the Oem Telephony provider. Return value success does not imply that the request functionality is fully executed. If return value indicates Failure, then no further processing of the request is done at OEM.
   
   
5. In case of failure("FALSE") return of any confirmation/indication API, OEM adaptation layer plug-in may perform further processing, if required.
   
   
6. All request Confirmations/Indications are sent asynchronously by calling the OEM Indication/confirmation APIs.
   
   
7. For a Request API, corresponding confirmation API to be called by OEM Adaptation layer is self-explanatory by naming convention
   
   
8. Request_id is generated by telephony server and it is unique identifying the request made by TS and used for mapping the responses provided by the OEM Adaptation layer. The same RequestId is expected to be provided by OEM adaptation layer along with the confirmation. Request id provided to the OEM Adaptation Layer shall be a valid positive value. In case OEM Adaptation layer receives any value less than 0, it can send TAPI_API_INVALID_REQUEST_ID error back to TS.
   
   
9. The memory allocated for the data in a particular layer should be deallocated by the same layer once the APIs are returned successfully.
   
   
10. OEM Adaptation layer plug-in shall throw an error TAPI_API_REQUEST_MAX_IN_PROGRESS for an API request as the maximum number of requests for the same service is already in progress at OEM Adaptation layer.
    
    
11. Asynchronous confirmation APIs(Cnf APIs) and indication APIs (Ind APIs) may return false, if there is communication loss between TAPI Client and Telephony server. This API return is just an indication to OEM Adaptation layer that asynchronous response failed at TS.
    
    APIs follows convention of ending with Req, Rsp, Cnf and Ind. Description is provided for the convention in the following Table:
    

3.0 Industry Standard

4.0 External API Documents

5.0 Plug-in Extension Point Interface

6.0 Other Interfaces

7.0 Other Notes

Generated on Mon Mar 31 01:01:00 2008 by  1.5.4