From Fedora Project Wiki
No edit summary
 
(85 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | 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.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR FEATURE.'''}}
= SIP Witch Domain Telephony =
 
== 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.
 
== Owner ==
* Name: [[User:dyfet| David Sugar]]
* email: dyfet@gnutelephony.org


{{admon/important | Set a ''watch'' on your new page so that you are notified of changes to it by others, including the Feature Wrangler}}
== Current status ==
* Targeted release: [[Releases/13 | Fedora 13 ]]
* Last updated: 2010-02-07
* Percentage of completion: 100%
* Upstream project status: Introduction of interum core NAT functionality completed (0.7.0)


{{admon/note | All sections of this template are required for review by FESCo.  If any sections are empty it will not be reviewed }}
We are essentially "feature complete" from the perspective of delivering Domain Telephony functionality for Fedora 13.  Immediate work on comps, on drafting an updated howto based on the new 0.7.x release, and especially on finding and resolving bugs with user deployment, can now begin.


Deferred features: gui setup.  New cli commands, siprealm and sippasswd, were introduced instead.  gui, and even a dbus applet, may be defined for F14.  NAT through ipfw was deferred to get NAT functionality immediately testable.  We are only offering generic RTP proxy for F13.


<!-- All fields on this form are required to be accepted by FESCo.
== Detailed Description ==
We also request that you maintain the same order of sections so that all of the feature pages are uniform.  -->


<!-- The actual name of your feature page should look something like: Features/YourFeatureName.  This keeps all features in the same namespace -->
GNU SIP Witch is to SIP much like what Jabber is for xmpp.  This feature is to setup, deploy, and manage sipwitch (or general VoIP) services in a manner consistent with other core Fedora services as well as to create a free public communication network anyone can participate in directly and securely to replace Skype.  Long term goals to further VoIP integration in Fedora 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.  This particular spec however focuses on a more limited feature for the F13 release timeframe that is also a FSF priority initiative.


= SIP Witch Domain Telephony =
This feature essentially requires a user to be able to easily 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.


== Summary ==
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.


GNU SIP Witch can be used to offer a means to create scalable and secure
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".
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 can media packet forward RTP for
Since SIP Witch tethers SIP clients and intercommunications entirely through standard SIP protocols, SIP Witch can also be used in conjunction with and to enhance existing IP-PBX solutions such as Asterisk.  There is also a sipwitch plugin that allows one to use SIP Witch to manage calls peer-to-peer to "secure" destinations using secure extension numbers while cross-registering sipwitch managed extensions to an insecure IP-PBX such as asterisk so that people can place calls to and receive calls from insecure destinations as well.  This use case is outside of this initial spec, but will likely be elaborated on post F13.
SIP devices behind a NAT while establishing direct peer-to-peer communication between endpoints, it has little overhead, has no issues with patent encumbered codecs, and can operate directly with 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.


== Owner ==
== Benefit to Fedora ==
<!--This should link to your home wiki page so we know who you are-->
* Name: [[User:dyfet| David Sugar]]


<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
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.
* email: dyfet@gnutelephony.org


== Current status ==
== Scope ==
* Targeted release: [[Releases/{{next}} | {{next}} ]]
What was already done (prior to F13 development):
* Last updated: (DATE)
* sipwitch packaged for fedora
* Percentage of completion: 1%
* plugable architecture
* server interfaces for statistics and running state
* xml based configuration files


<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
What was completed for F13 "SIPWitch Domain Calling" feature:
* rework to standardize user behavior and make all account types profilable
* inbound anonymous calling, internodal anonymous through new P_SIPWITCH_NODE header
* missing man pages added to help with improving documentation
* new and simpler packaging layout to support going forward
* new management utilities, sippasswd and siprealm
* basic integrated NAT proxy with sdp rewrite and RTP packet forward
* auto-configuration with user accounts added to @sipusers group or default 1000 uid


== Detailed Description ==
What is no longer required:
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
* swig interfaces to server for perl and python.


== Benefit to Fedora ==
What has been deferred to F14:
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
* password sync to digest through pam stack.
* gui admin page to set realm, passwd's, etc
* ipfw based NAT functionality


== Scope ==
What is desired (maybe after F14):
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
* 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 or dbus
* group calling and ACD functionality
* feature group calling
* user setable speed dial tables


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.


Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
=== install sipwitch service ===
<pre>$ yum install sipwitch*</pre>


A good "how to test" should answer these four questions:
=== start the daemon (as root) ===
<pre># /etc/init.d/sipwitch start</pre>


0. What special hardware / data / etc. is needed (if any)?
=== test registration ===
1. How do I prepare my system to test this feature? What packages
Configure test SIP client such as Twinkle...to be added....
need to be installed, config files edited, etc.?
 
2. What specific actions do I perform to check that the feature is
=== test local calling ===
working like it's supposed to?
Dial extension number of test client.  You should receive busy.
3. What are the expected results of those actions?
 
-->
Dial an unknown extension number like 777.  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 ==
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice. -->
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 (NOTE: NAT through ipfwadm has been deferred to F14, hence calls through NAT will die if the server dies in F13).
 
There is also a user experience associated with an admin application. This user experience is offered through siprealm and sippasswd utilities in F13.


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
ucommon
swig


== Contingency Plan ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. -->
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 ;).


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
 
*
Existing documentation:
* There is a basic howto at http://www.gnutelephony.org/index.php/Howto_Deploy_SIP_Witch_On_Ubuntu


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
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!
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
*


== Comments and Discussion ==
== Comments and Discussion ==
* See [[Talk:Features/YourFeatureName]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
* See [[Talk:Features/SIP_Witch_Domain_Telephony]]  <!-- This adds a link to the "discussion" tab associated with your page.  This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
 


[[Category:FeaturePageIncomplete]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
[[Category:FeatureAcceptedF13]]
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 00:36, 8 February 2010

SIP Witch Domain Telephony

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.

Owner

Current status

  • Targeted release: Fedora 13
  • Last updated: 2010-02-07
  • Percentage of completion: 100%
  • Upstream project status: Introduction of interum core NAT functionality completed (0.7.0)

We are essentially "feature complete" from the perspective of delivering Domain Telephony functionality for Fedora 13. Immediate work on comps, on drafting an updated howto based on the new 0.7.x release, and especially on finding and resolving bugs with user deployment, can now begin.

Deferred features: gui setup. New cli commands, siprealm and sippasswd, were introduced instead. gui, and even a dbus applet, may be defined for F14. NAT through ipfw was deferred to get NAT functionality immediately testable. We are only offering generic RTP proxy for F13.

Detailed Description

GNU SIP Witch is to SIP much like what Jabber is for xmpp. This feature is to setup, deploy, and manage sipwitch (or general VoIP) services in a manner consistent with other core Fedora services as well as to create a free public communication network anyone can participate in directly and securely to replace Skype. Long term goals to further VoIP integration in Fedora 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. This particular spec however focuses on a more limited feature for the F13 release timeframe that is also a FSF priority initiative.

This feature essentially requires a user to be able to easily 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".

Since SIP Witch tethers SIP clients and intercommunications entirely through standard SIP protocols, SIP Witch can also be used in conjunction with and to enhance existing IP-PBX solutions such as Asterisk. There is also a sipwitch plugin that allows one to use SIP Witch to manage calls peer-to-peer to "secure" destinations using secure extension numbers while cross-registering sipwitch managed extensions to an insecure IP-PBX such as asterisk so that people can place calls to and receive calls from insecure destinations as well. This use case is outside of this initial spec, but will likely be elaborated on post F13.

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.

Scope

What was already done (prior to F13 development):

  • sipwitch packaged for fedora
  • plugable architecture
  • server interfaces for statistics and running state
  • xml based configuration files

What was completed for F13 "SIPWitch Domain Calling" feature:

  • rework to standardize user behavior and make all account types profilable
  • inbound anonymous calling, internodal anonymous through new P_SIPWITCH_NODE header
  • missing man pages added to help with improving documentation
  • new and simpler packaging layout to support going forward
  • new management utilities, sippasswd and siprealm
  • basic integrated NAT proxy with sdp rewrite and RTP packet forward
  • auto-configuration with user accounts added to @sipusers group or default 1000 uid

What is no longer required:

  • swig interfaces to server for perl and python.

What has been deferred to F14:

  • password sync to digest through pam stack.
  • gui admin page to set realm, passwd's, etc
  • ipfw based NAT functionality

What is desired (maybe after 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 or dbus
  • group calling and ACD functionality
  • feature group calling
  • user setable speed dial tables

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 777. 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 (NOTE: NAT through ipfwadm has been deferred to F14, hence calls through NAT will die if the server dies in F13).

There is also a user experience associated with an admin application. This user experience is offered through siprealm and sippasswd utilities in F13.

Dependencies

ucommon swig

Contingency Plan

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 ;).

Documentation

Existing documentation:

Release Notes

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!

Comments and Discussion

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/SIP_Witch_Domain_Telephony&oldid=151125"