Details
-
Suggestion
-
Resolution: Unresolved
-
P1: Critical
-
None
-
None
-
None
Description
This page collects potential use cases/requirements for the Qt Telephony API. It does not mean that the first API release will support all these use cases.
Objectives
Enable application developers (Current and external/3rd party) to be able to invoke telephony functionality. Call origination, Call Termination, Recieve a call, hold call, perhaps also considering Conferencing.
The intention is to create one Telephony API that will interoperate with selected telephony service.
Support for Symbian^3, S60 5.0, Harmattan and MeeGo being the top priority platforms, desktop platforms may also be included but currently at a lower priority.
Telephony API must be agnostic toward the underlying technology/bearer. For example, support for VoIP, GSM, PSTN should all be possible.
Use Cases.
What are the expected use cases and target users:
| Use case | Priority Meego | Pritority SD | Release | Complexity | Stakeholders |
|---|---|---|---|---|---|
User can initiate native phone dialer with a given pre-filled phone number |
High | Low | 1st. Rel | Megoo Low, SD Medium | 3rd. party dev., internal dev. |
| Comments: | |||||
| – Meego: Close to highest priority from Meego, investigate from SD side. | |||||
| – SD: Important for SD as well. | |||||
Developer accesses call object directly from the app |
3rd. party dev., internal dev., operators | ||||
|
High | High | 1st. Rel | Megoo High, SD Medium | |
|
High | High | 1st. Rel | Megoo High, SD Medium | |
|
High | High | 1st. Rel | Megoo High, SD Low | |
|
High | High | 1st. Rel | Megoo High, SD Low | |
|
High | High | 1st. Rel | Megoo High, SD Low | |
|
Low | Low | ? | ||
| Comments: | |||||
| – Limited from 3rdparty perspective | |||||
| – There might be other clients in position to accept (Telepathy role Approver). | |||||
| – The API will not handle the call UI. You may use the API to implement the UI though. | |||||
| – SD: Assuming 'Caller ID' refers to originator uri or number, not contact id | |||||
| – SD: Can easily provide for security level on/off info, currently no need for detailed encryption level, we propose this item is excluded from the API | |||||
User can initiate calls (audio, video, text) |
3rd. party dev., internal dev., operators | ||||
|
High | High | 1st Rel. | Medium, | |
|
Medium | Low | High, | ||
|
High | Medium | 1st Rel. | Megoo High, SD Medium | |
| Comments: | |||||
| – Initiate calls to a group is not necessary in Release 1.3 | |||||
| – In cases where developers want to provide a real phone app that controls the calls (f.ex voip clients) initiate an emergency call is needed. | |||||
| – SD: We have a preferred service logic implemented which in some cases dictates the used call service. Should this API be allowed to bypass the user settings? | |||||
| – SD: We suggest that emergency call creation API takes emergency number as an optional parameter , this creates some additional logic (e.g. what if the number passed was not valid emergency number in that region) but is needed since some countries have dedicated numbers for e.g. fire department or police. | |||||
| – SD: We suggest that call creation API does not cover sending supplementary service (SS) or USSD requests | |||||
User can influence a call |
3rd. party dev., internal dev., operators | ||||
|
High | High | 1st Rel. | Low | |
|
2nd Rel. | High | |||
|
High | High | 1st Rel. | Low | |
|
2nd Rel. | High | |||
|
High | High | 1st Rel. | Low | |
|
2nd Rel. | High | |||
|
High | High | 1st Rel. | Low | |
|
2nd Rel. | High | |||
| Comments: | |||||
| – SD: How about multicall functionality, e.g. transfer, deflect, voip transfers, terminate all calls, manual handover initiation? | |||||
User wants to activate and deactivate different services (text video audio etc.) during a call |
3rd. party dev., internal dev., operators | ||||
|
Medium | Medum | Meego 2nd Rel. SD 3rd Rel. | Meego High, SD Medium | |
| Comments: | |||||
| – depends on the protocol, it needs capability management) | |||||
| – SD: Obviously not available for CS voice calls unless call release+creation is hidden from client, Symbian telephony has no control over CS video call content | |||||
| – SD: VoIP video calls not supported currently | |||||
Developer want to be able to send DTMF strings |
3rd. party dev., internal dev., operators | ||||
|
High | High | 1st Rel. | Meego Medium, SD Low | |
|
High | High | 1st Rel. | Meego Medium, SD Low | |
| Comment: | |||||
| – needed in initiate emergency calls | |||||
| – SD: Additional internal requirement: need to play single dtmf tones (local + remote) | |||||
| – SD: We assume that DTMF API implementation covers both sending to network and playing the tones locally. | |||||
While on a call the user conferences in another party and splitting again |
Low | Medium | Meego High, SD Medium | 3rd. party dev., internal dev., operators | |
| Comment: | |||||
| – API research (http://telepathy.freedesktop.org/spec/#Conference-related-interfaces) | |||||
| – SD: Protocol restrictions apply | |||||
User can Mute/Unmute and control audio volume of a call |
3rd. party dev., internal dev. | ||||
|
High | Medium | 1st Rel. | Meego Medium, SD Low | |
|
Low, High for 3rd party Dev | Medium | 1st Rel. | Meego Medium, SD Low | |
| Comment: | |||||
| – Mute controlled by application | |||||
| – Volume in principle controllable | |||||
| – Volume control might have unwanted implications in UIs where audio volume is controlled centrally | |||||
| – Volume control can be handled by other API's. Mute and unmute is very useful in a call UI and isn't realized as a system-wide control (except in hardware assessories). | |||||
User can select the audio/video/text stream target (headset, speaker etc...) |
Low | Low | Meego High (User cannot select headset from API, just by plugging in the headset), SD Medium | 3rd. party dev., internal dev. | |
| Comment: | |||||
| – Simple use cases desired for more advanced use cases done via other API. | |||||
| – SD: We suggest that the platform remains in control over the initial audio routing of the call i.e. this API would offer the routing only after call is in connected state. Also it might be adequate to provide such routing options as public/private instead of more explicit ones (e.g. earpiece, Bt headset). | |||||
Developer can retrieve Audio and Video stream. |
Medium | Low | High | 3rd. party dev., internal dev. | |
| Comment: | |||||
| – Audio differently handled for Voip and GSM. | |||||
| – focus on simple Audio calls, enabling/disabling video | |||||
| – SD: We have no access to CS call audio stream content on Symbian side. Should we drop this requirement altogether? | |||||
Retrieve and modify (remove calls) call history programmatically |
High | Medium | 2nd.- 3rd. Rel. | Medium | 3rd. party dev., internal dev., operators (e.g. with own storage model) |
| Comment: | |||||
| – Different ontology on different platforms. Caller id are interchangeable between modules (Contacts, Accounts, Messaging) | |||||
| – This (able modify call log entries) is one of the very basic requirements for all 3rd party UC applications. E.g. customers would like to see one common "enterprise call log" in UC applications meaning that it doesn't matter where you answers the call the log entry will be synced in all your devices in right format (so that it can be used from there). | |||||
| – SD: Needs capability checking | |||||
| – SD: Not really a telephony API. Should this be moved to some other domain? | |||||
As a developer I want to have integration point for my IP call / VoiP client (system plugin) |
High | High | Meego Medium, SD High | 3rd. party dev., internal dev., operators | |
| Comment: | |||||
| – for licensing issues a process separated architecture is needed, with service framework or other IPC. | |||||
| – SD: Too big and vague a requirement. We cannot commit to this as is. | |||||
| – SD: Medium to low effort to support existing CS and SIP VoIP services, major effort if a framework for adding new protocols is requested | |||||
Network management |
3rd. party dev., internal dev., operators | ||||
|
Medium | Medium | Medium | ||
|
Medium | Medium | Medium | ||
|
Medium | Medium | Medium | ||
|
High | High | 1st Rel. | Medium | |
| Comments: | |||||
| – SD: Tower selection may not be available | |||||
| – SD: Possibly generates lots of signaling (constant signal strength updates) | |||||
| – SD: Does not look like a protocol agnostic api. How about VoIP provider settings? WLAN info? | |||||
| – SD: Not really a telephony API. Why would a Call UI request this information unless it is a complete home screen solution? Should this be moved to some other domain? | |||||
Manage call barring/ call forwarding information |
Low | Low | Medium | 3rd. party dev., internal dev., operators | |
| Comment: | |||||
| – not limited to telephone number (possible for Voip/SIP as well) | |||||
| – somewhat lower priority as mostly used by internal settings apps | |||||
VoiceMail Management |
3rd. party dev., internal dev., operators | ||||
|
Low | Low | High | ||
|
High | High | 1st rel | Medium | |
| Comment: | |||||
| – Simple case: number to call. | |||||
| – Recording a voicemail for a contact | |||||
| – Message waiting indication and possibly how many msgs are waiting (abstract items with optional content), initiate play back. | |||||
| – SD: The above entries are a bit vague. Is the 'Retrieval' use case about setting and retrieving the voice mail box number? | |||||
| – SD: Not really a telephony API. Should this be moved to some other domain? | |||||
Call waiting, roaming Management |
3rd. party dev., internal dev., operators | ||||
|
Low | Low | High | ||
|
Low | Low | High | ||
| Comment: | |||||
| – Mostly Internal settings application | |||||
| – SD: What is roaming management? | |||||
| – SD: Possibly not really a telephony API. | |||||
Switching to Flight mode |
3rd. party dev., internal dev. | ||||
|
Low | Low | Medium | ||
|
High | High | 1st Rel. | Medium | |
| Comment: | |||||
| – Retrieval is high priority | |||||
| – SD: Not really a telephony API. | |||||
Retrieve call logs |
3rd. party dev., internal dev. | ||||
|
High | 1st Rel. | Medium | ||
|
High | 1st Rel. | Medium | ||
|
High | 1st Rel. | Medium | ||
| Comment: | |||||
| – SD: We in Contacts need an API to retrieve the call logs. Information retrieved should correspond to the currently available Symbian API for Logs engine |
References
- libcellular-qt
- oPhono (http://meego.gitorious.org/meego-cellular/ofono)
- libTelepathy-qt-4-0
- libTelepathy-qt-4-1
Attachments
There are no Sub-Tasks for this issue.
