telephony

Differences between revisions 2 and 3
Revision 2 as of 2010-04-16 13:17:06
Size: 1611
Editor: dyfet
Comment:
Revision 3 as of 2010-04-16 13:23:56
Size: 2392
Editor: dyfet
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
 * Unify all routing, NAT, and configuration issues in one place (sipwitch)  * Unify all routing, NAT, and configuration issues in one place with a low resource/lightweight service (sipwitch)
Line 16: Line 16:

== Work Items ==

 * oFono Management plugin for sipwitch

 * D-bus plugin for sipwitch

 * URI handler application

 * Address book integration

 * Indicator applet for telephony

 * Services setup GUI application

 * File format to hand off to providers

 * Notification management for incoming calls (osd notify)
Line 27: Line 45:
A second possibility would be to have address books and sip uri's notify the SIP client application to make a call. This means that each potential client application would have to be modified to perform such an action in this way. A second possibility would be to have address books and sip uri's notify the SIP client application to make a call. This means that each potential client application would have to be modified to perform such an action in this way.  Also, if the user has an external sip desktop phone, this would not be possible to activate.

The architecture proposed is really an executable that would run as a handler or in response to address book requests and which would then notify sipwitch (or a client). This means the behavior can be changed based on need or decided later. However, what is the correct default behavior should be discussed.

Desktop Telephony Planning for Ubuntu

Overview image

telephony.png

Purposes

  • Unify all routing, NAT, and configuration issues in one place with a low resource/lightweight service (sipwitch)
  • Unify user experience for all telephony services rather than using different things for VoIP, landlines, etc.
  • Fully integrate telephony as a natural part of user desktop experience
  • Simplify and provide consistent user experience for setup of telephony providers

Work Items

  • oFono Management plugin for sipwitch
  • D-bus plugin for sipwitch
  • URI handler application
  • Address book integration
  • Indicator applet for telephony
  • Services setup GUI application
  • File format to hand off to providers
  • Notification management for incoming calls (osd notify)

Discussion Items

This is a list of potential discussion items for UDS:

Desktop Integration and user experience

Desktop integration suggests that when one clicks on a phone number in an address book, or perhaps a sip: uri, it should be possible to automatically dial and establish a call with the remote user. This of course has several issues.

First, we can tell the server to create the call. It would then ring both the remote party and the local SIP client(s) for the user. This may however have an unnatural feel to users. What happens when the user picks up the call but the remote party has not yet? Or if the remote party picks up but the local user never does? One answer would be to have the invited local client auto-answer and automatically pickup such calls.

A second possibility would be to have address books and sip uri's notify the SIP client application to make a call. This means that each potential client application would have to be modified to perform such an action in this way. Also, if the user has an external sip desktop phone, this would not be possible to activate.

The architecture proposed is really an executable that would run as a handler or in response to address book requests and which would then notify sipwitch (or a client). This means the behavior can be changed based on need or decided later. However, what is the correct default behavior should be discussed.

=== To be added... ====

UDS Maverick

This is proposed issues for Maverick UDS

DavidSugar/telephony (last edited 2010-05-13 07:26:05 by dyfet)