< Features
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.
SIP Witch Domain Telephony
Summary
GNU SIP Witch will be used to operate SIP in a manner analogous to what sendmail does for SMTP to allow anyone to connect to both local SIP user agents and devices managed as local extensions, and remote users through SIP URI's over the public Internet. Because SIP Witch does no media processing and supports direct peer to peer interconnect, true secure protocols such as ZRTP may be used in conjunction to offer Internet scalable secure VoIP & video services without the need for a central directory or service provider (such as Skype requires).
Owner
- Name: David Sugar
- email: dyfet@gnutelephony.org
Current status
- Targeted release: Fedora13
- Last updated: 2009-10-10
- Percentage of completion: 1%
Detailed Description
GNU SIP Witch can be used to offer a means to create scalable and secure VoIP services usable by everyone. This is done by using SIP Witch as a "domain" service for the SIP protocol, much like how Sendmail or Postfix do so for SMTP.
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". This is already completed with general availability of GNU SIP Witch which has initially been packaged since Fedora 10. 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, are the only two features proposed for the Fedora 13 timeline.
Benefit to Fedora
Offering a means to create and deploy scalable, secure, and publicly controlled alternative to Skype architecture as well as secure VoIP solutions for workgroups and other entities using entirely free software and ANY standard's compliant SIP client, many of which are already packaged for Fedora.
Scope
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
What is desired:
- 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
How To Test
install sipwitch service
$ yum install sipwitch*
start the daemon (as root)
# /etc/init.d/sipwitch start
test registration
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.
User Experience
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.
Dependencies
ucommon