SIPDomainCalling

Differences between revisions 2 and 3
Revision 2 as of 2009-11-16 17:10:39
Size: 4457
Editor: 63
Comment:
Revision 3 as of 2009-11-20 15:28:46
Size: 4455
Editor: 63
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
 * '''Launchpad Entry''': UbuntuSpec:temporary-lucid-sip-domain-calling  * '''Launchpad Entry''': UbuntuSpec:desktop-lucid-sip-domain-calling

Summary

This feature enables an entirely free software alternative to Skype using standard IETF protocols along with support for direct peer-to-peer secure communications such as possible with ZRTP capable softphones and without need for a mitigating "service provider". Instead, DNS will be used for directly resolving SIP uri's and each user or organization will construct the network directly from the bottom-up running a sipwitch service daemon to answer and route calls for their users or on individual workstations, and do so while using existing standard compliant VoIP clients such as Empathy, Twinkle, SIP Communicator, local SIP devices, etc, as they prefer. SIP Witch will shortly be announced as having a key role in the FSF effort to promote replacing Skype with free software, and this spec is consistent with that plan.

Release Note

The initial release of SIP Witch Domain Telephony will allow you to create and deploy scalable secure VoIP solutions both for managing a local SIP based telephone system and to call remote users over the public Internet without the need of a service provider or central directory service. This offers the freedom to organize and communicate freely and securely, and also free as in cost, too!

Rationale

There is a need for an Internet scalable solution for VoIP that offers intercept-free communiation and which does not rely upon the control of a single provider or the use of non-standard's compliant clients.

User stories

User wants to run a simple phone system for several softphones they have at home, and dial them locally as extensions and have basic pbx features like call forwarding, multi-phone ring groups, etc.

User wants to call other users at remote locations. For this, we will use URI dialing, which means SIP witch will map email-like id's into local extensions.

Design

We will be making use of existing SIP compliant softphones, many of which have already been packaged for Ubuntu. SIP Witch simply coordinates these devices in a local dialing plan, and offers uri routing that is resolved through DNS for calling remote users.

Since SIP Witch only mitigates SIP and will soon offer media packet forward RTP for SIP devices behind a NAT, while still establishing direct peer-to-peer communication between endpoints, it has very little overhead and no issues with patent encumbered codecs. Because peer to peer media connections are used between endpoints, sipwitch can operate directly with, manage, and scale "Social Key Verification" systems such as ZRTP. Since all users can use direct URI dialing to contact users at other locations there is no need for a central "service provider" or directory.

The primary feature is being able to run a SIP Witch "service" on Ubuntu, and this is a packaging issue alone. Exposing this service to management, that is, making it possible for ordinary human beings to in some even basic manner configure a SIP Witch installation for this specific mission at minimum without hand editing config files, and the completion of packet forward integration in the daemon itself, is the only Ubuntu-specific feature proposed for Lucid.

Implementation

For Lucid:

  • Packaging of sipwitch daemon (nearly done)
  • Completion of packet forward feature for proper NAT support
  • Simple gui app (maybe done in quickly) to generate a configuration file
  • Ability to select gui config app from System->Administration

  • Basic documentation for this
  • Cache user sip hashes when user passwords change via pam stack and new /etc/sipwitch.db

For Lucid+1:

  • Introduction of mysql or sqlite plugin for keeping user extensions in a database
  • xmlrpc backend for managing configuration and db
  • new front-end app with systray for remote status monitoring of a sipwitch server

Effort

Lucid:

  • Packet forwarding may take a few days to complete and test
  • new digest cache a few days
  • gui app time unknown
  • Packaging should be about a day
  • Total effort ~1-2 weeks

UI Changes

  • New gui app for system-admin to create sipwitch configurations

Code Changes

Migration

Test/Demo Plan

Unresolved issues

Action Items

Specs/SIPDomainCalling (last edited 2009-11-30 20:38:15 by pool-72-75-154-242)