| Line 36: | Line 36: | ||
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. | 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 == | == Benefit to Fedora == | ||
Revision as of 22:26, 10 October 2009
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.