|Line 8:||Line 8:|
== Summary ==
== Summary ==
This feature for to for service provider. running a service to for or , and standard compliant such as Empathy, , SIP , , as .
== Owner ==
== Owner ==
Revision as of 12:41, 5 November 2009
- 1 Features/SIP Witch Domain Telephony
- 1.1 Summary
- 1.2 Owner
- 1.3 Current status
- 1.4 Detailed Description
- 1.5 Benefit to Fedora
- 1.6 Scope
- 1.7 How To Test
- 1.8 User Experience
- 1.9 Dependencies
- 1.10 Contingency Plan
- 1.11 Documentation
- 1.12 Release Notes
- 1.13 Comments and Discussion
Features/SIP Witch Domain Telephony
This feature offers an entirely free software alternative to Skype using standard IETF protocols and offers support for direct peer to peer secure communication with ZRTP capable softphones without any 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 using existing standard compliant VoIP clients such as Empathy, Twinkle, SIP Communicator, etc, as they prefer.
- Name: David Sugar
- email: firstname.lastname@example.org
- Targeted release: Fedora13
- Last updated: 2009-10-10
- Percentage of completion: 10%
This is described as a feature because the goal is ultimately to setup, deploy, and manage sipwitch (or general VoIP) services in a manner consistent with other core Fedora services. Long term goals to further this can include integrating phone service management with user account creation, use of auto-activating SIP user agents for SIP uri's (as a selectable preferred GNOME application much like email and web browser), address book integration to VoIP, and many other areas that touch widely upon Fedora and the overall desktop user experience. A much less ambitious starting point is proposed in this limited feature spec for the F13 release timeframe. From the F13 perspective and timeframe, this is principally an infrastructure feature to put things in place for later enabling the full user experience.
This feature essentially requires a user to setup and deploy a GNU sipwitch server and connect it to manage one or more local SIP user agents, devices, or existing services. This can be be done directly on individual workstations, on a public facing server acting as a SIP agent for an entire domain and organization, or some combination of both. SIP Witch also will mitigate NAT issues on behalf of local SIP clients using the service to call remote users, thereby simplifying the deployment of such services. The goal is to be able to setup and deploy sipwitch and softphones to use it with much the same simplicity that one does for Skype, as well as to offer more extensive features when using sipwitch as a local SIP phone system for SIP devices.
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. This offers the ability to use verifiable high-grade end-to-end media encryption to easily establish and maintain "secure" VoIP calls with remote users, something not possible with solutions like Asterisk which do not offer media peering at connection and require central decryption. This means trustworthy intercept-free calling can become possible for larger organizations in a very simple way.
Part of the focus in F13 is on completing sipwitch NAT and then enabling a simple means for users to minimally configure and use the service. This goal will be served by a simple system "admin" application (in GNOME menus under system->administration) which will offer a form with basic questions such as the "calling domain", information about publicly appearing address for NAT, and the basic dialing plan for local SIP user agents or devices. It will include a simple tool to transform a local user account into a SIP user. A patch may also be added to the Twinkle SIP softphone to add a local SIP service such as sipwitch as a wizard "profile".
Benefit to Fedora
Further enabling Fedora users to more easily communicate and collaborate realtime in voice and video worldwide in both freedom and as desired privately, and without the need of mitigating service providers. Enabling any organization and enterprise to deploy secure scalable realtime VoIP networks using Fedora whether for public or private use. Finally, as a back-end infrastructure, this feature is very naturally complimentary to Empathy as a means for users to communicate by empowering the community to create it's own messaging and communication infrastructure directly rather than depending on specific back-end providers like Google, MSN, Yahoo, etc.
What is already done:
- sipwitch packaged for fedora
- plugable architecture
- server interfaces for statistics and running state
- xml based configuration files
- swig interfaces to server for perl and python.
What is minimally required:
- sipwitch packet forward (0.6 release planned)
- something basic to easily create a configuration file
- documentation explaining how to use above
What is desired (maybe F14):
- mysql or sqlite plugin to read local extension info from a database
- call detail collection saved into said database
- A more complete front-end which utilizes said database
- A python tray application that can get server stats via xmlrpc
- Documentation for setting up a site
How To Test
install sipwitch service
$ yum install sipwitch*
start the daemon (as root)
# /etc/init.d/sipwitch start
Configure test SIP client such as Twinkle...to be added....
test local calling
Dial extension number of test client. You should receive busy.
Dial an unknown extension number like 999. You should receive not found.
test domain configuration
Some instructions on domain setup...
Dial your email address as a uri. If reverse config is correct, you should get your call appearing as a new inbound call on the second line in Twinkle.
If the sipwitch daemon crashes, all active calls still remain active. Since packet filtering is used to form proxy forward, even calls behind NAT will continue.
There is also a user experience associated with an admin application.
Revert to current package, at minimum we should have sipwitch 0.6 by fedora13 which will have media proxy for NAT. It can also be bumped to Fedora14 ;).
- There is a basic howto at http://www.gnutelephony.org/index.php/Howto_Deploy_SIP_Witch_On_Ubuntu
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!