Desktop Telephony Planning for Ubuntu

Architecture Overview

Where we concluded so far at UDS


Some ideas I have for discussion at UDS


Some original thoughts...




  • 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.
  • Simplify telephony application development
  • Fully integrate telephony as a natural part of user desktop experience
  • Simplify and provide consistent user experience for setup of telephony providers

Potential 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)
  • VoIP client auto-detection and auto-configuration of sipwitch services

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.

oFono Audio Issues

The oFono stack does not expose audio to user applications. It seems based on the premise that audio for GSM (or modem devices) would be "switched" into the headphone/mic jacks rather than transported or managed through sources and sinks. This of course makes it impossible to create "user applications" that can record calls. It also makes it impossible to transport audio to VoIP clients.

For the desktop user, it does not matter if the audio the user hears is generated by a VoIP client connecting rtp to alsa audio, or something doing so directly. The user hears audio from the remote caller in either case. To satisfy a local VoIP client, we can even inject dummy rtp silent packets. However, if the desktop user uses an external SIP phone device, we cannot offer oFono audio to them.

This issue needs to be investigated further to see if there are other options that can be made to work, including perhaps directly accessing audio device nodes associated with certain kinds of telephony devices.

Client auto-detection

How do we detect that SIP witch is available and auto-configure for it?

UDS Maverick

This is proposed issues for Maverick UDS

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