ARMTelephonyStack
|
Size: 2710
Comment:
|
Size: 5571
Comment: make consistent with other spec wiki pages for ARM-M
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from Specs/arm-maverick-telephony-stack | |
| Line 3: | Line 4: |
| * '''Launchpad Entry''': UbuntuSpec:arm-maverick-telephony-stack | * '''Launchpad Entry''': [[http://blueprints.launchpad.net/ubuntu-arm/+spec/arm-m-telephony-stack|arm-m-telephony-stack]] |
| Line 6: | Line 7: |
| * '''Packages affected''': sipwitch, ofono | * '''Packages affected''': sipwitch, ofono, telepathy |
| Line 10: | Line 11: |
| To create a unified approach to VoIP and telephony for the Ubuntu desktop, sipwitch is being proposed as desktop mediation service. This blueprint provides an overview of issues required to make this happen, and what changes within this broader goal we believe can be focused on within the Maverick timeframe. | To create a unified approach to VoIP and telephony for the Ubuntu desktop, sipwitch is being proposed as desktop mediation service. This blueprint provides an overview of issues required to make this happen, and what changes within this broader goal we believe can be focused on within the Maverick timeframe. The overall roadmap for this can be found at [[DavidSugar/telephony]] and likely will iterate over multiple releases. |
| Line 14: | Line 15: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. |
To better integrate and improve VoIP integration for the Ubuntu desktop, a new user preference panel offering tools to configure and use sipwitch as a VoIP and telephony mediation service is being offered. These initial tools and services are optional for Maverick but may become a standard part of the Ubuntu desktop experience in the future. |
| Line 20: | Line 19: |
| This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. | The goal, within Maverick, is to further complete work started in Lucid to use sipwitch to manage and route VoIP services and offer a standardized means to configure SIP clients and telephony services. The purpose is to create a unified, reliable, consistent, and much easier to configure desktop telephony experience regardless of the user's preferred front-end desktop telephony client. This is part of a larger goal to create a unified desktop telephony stack and user experience. |
| Line 59: | Line 58: |
| == BoF agenda and discussion == | == UDS Maverick Discussion == |
| Line 61: | Line 60: |
| Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. | === Problem Space === * Lots of communication methods and services * with different api's * different client experiences * ranging from VoIP to cellular, and all in between * Many kinds of applications * generic communication programs * specialized custom enterprise apps * ACD agents and relationship management * Need to integrate other system resources such as address books * Telephony application development often need to deal with audio processing and different network transport protocols long before the "application" |
| Line 63: | Line 73: |
| === Proposed Goals === * Unify disparate communication systems with different api's * Simplify telephony application programming * Single solution that works for cell phones to desktop === Questions === * Is desktop agnostic essential? * Can we use just a heavyweight client with an external API? * Does a heavywieight client effect agnostic and lightweight environments? * Can we use ofono as a top layer telephony application stack? * How much work is needed to make ofono usable this way in Ubuntu? * Can we reduce telephony application development to something like "quickly"? * How have others tried to solve this, and what can we learn? === Discussion Notes === * What are the differences and advantages of Ofono regarding Telepathy? * Telepathy has a more complete/complex API, aka ofono would restrict the feature set * oFono plugin for telepathy exists for nokia, but is currently closed source * call routing: might not work on phones; power consumption for VOIP isnt optimal * preferred way to route calls could be auto selected; where? client needs to take care because telepathy has no concept to do that; client could be != UI * priority should be to get use cases and devices work; then think about UI * integration with bearer management to make call routing decisions === Action Items === * bearer management service as part of the default * client that integrates with bearer management, address book (eds, akonadi), telepathy * sipwitch as proxy service? benefit: smart voip routing, smart NAT support, multi-device handling * 100k overhead * package ofono and friends * UI: DTMF dialer; bearer management problem; should we extend the empathy UI? * complicated question: how to do routing? where do do that? Telepathy contacts: sjoerd rob mcquen |
Launchpad Entry: arm-m-telephony-stack
Created: May 5, 2010
Contributors: David Sugar
Packages affected: sipwitch, ofono, telepathy
Summary
To create a unified approach to VoIP and telephony for the Ubuntu desktop, sipwitch is being proposed as desktop mediation service. This blueprint provides an overview of issues required to make this happen, and what changes within this broader goal we believe can be focused on within the Maverick timeframe. The overall roadmap for this can be found at DavidSugar/telephony and likely will iterate over multiple releases.
Release Note
To better integrate and improve VoIP integration for the Ubuntu desktop, a new user preference panel offering tools to configure and use sipwitch as a VoIP and telephony mediation service is being offered. These initial tools and services are optional for Maverick but may become a standard part of the Ubuntu desktop experience in the future.
Rationale
The goal, within Maverick, is to further complete work started in Lucid to use sipwitch to manage and route VoIP services and offer a standardized means to configure SIP clients and telephony services. The purpose is to create a unified, reliable, consistent, and much easier to configure desktop telephony experience regardless of the user's preferred front-end desktop telephony client. This is part of a larger goal to create a unified desktop telephony stack and user experience.
User stories
Assumptions
Design
You can have subsections that better describe specific parts of the issue.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
Should cover changes required to the UI, or specific UI that is required to implement this
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
- how users will be pointed to the new way of doing things, if necessary.
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
This need not be added or completed until the specification is nearing beta.
Unresolved issues
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
UDS Maverick Discussion
Problem Space
- Lots of communication methods and services
- with different api's
- different client experiences
- ranging from VoIP to cellular, and all in between
- Many kinds of applications
- generic communication programs
- specialized custom enterprise apps
- ACD agents and relationship management
- Need to integrate other system resources such as address books
- Telephony application development often need to deal with audio processing
- and different network transport protocols long before the "application"
Proposed Goals
- Unify disparate communication systems with different api's
- Simplify telephony application programming
- Single solution that works for cell phones to desktop
Questions
- Is desktop agnostic essential?
- Can we use just a heavyweight client with an external API?
- Does a heavywieight client effect agnostic and lightweight environments?
- Can we use ofono as a top layer telephony application stack?
- How much work is needed to make ofono usable this way in Ubuntu?
- Can we reduce telephony application development to something like "quickly"?
- How have others tried to solve this, and what can we learn?
Discussion Notes
- What are the differences and advantages of Ofono regarding Telepathy?
- Telepathy has a more complete/complex API, aka ofono would restrict the feature set
- oFono plugin for telepathy exists for nokia, but is currently closed source
- call routing: might not work on phones; power consumption for VOIP isnt optimal
- preferred way to route calls could be auto selected; where? client needs to take care
- because telepathy has no concept to do that; client could be != UI
- preferred way to route calls could be auto selected; where? client needs to take care
- priority should be to get use cases and devices work; then think about UI
- integration with bearer management to make call routing decisions
Action Items
- bearer management service as part of the default
- client that integrates with bearer management, address book (eds, akonadi), telepathy
- sipwitch as proxy service? benefit: smart voip routing, smart NAT support, multi-device handling
- 100k overhead
- package ofono and friends
- UI: DTMF dialer; bearer management problem; should we extend the empathy UI?
- complicated question: how to do routing? where do do that?
Telepathy contacts: sjoerd rob mcquen
Specs/M/ARMTelephonyStack (last edited 2010-06-07 14:34:31 by 178)