SIPDomainCalling

Differences between revisions 1 and 20 (spanning 19 versions)
Revision 1 as of 2009-11-16 17:09:10
Size: 4480
Editor: 63
Comment:
Revision 20 as of 2009-11-30 20:38:15
Size: 8186
Editor: pool-72-75-154-242
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
 * '''Launchpad Entry''': https://blueprints.launchpad.net/sipwitch/+spec/domain-calling-lucid  * '''Launchpad Entry''': UbuntuSpec:desktop-lucid-sip-domain-calling
Line 8: Line 8:
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. GNU SIP Witch is a service for the SIP protocol that is analogous to what Jabber does to XMPP, that is it offers registration, routing, and messaging between arbitrary SIP endpoints and resources. GNU SIP Witch was selected as part of the FSF initiative to replace Skype with free software, however there are additional opportunities that are very relevant to Ubuntu. SIP Witch can also be used as a local back-end to unify the telephony experience of desktop users in Telepathy and other desktop SIP user agents by automatically mediating access to local telephony resources such as SIP devices, desktop modems, gsm radio, idsn adapters, or local telephony servers, as well as remote VoIP service providers and enabling direct and secure call peering over the public Internet. The goal is to identify the work required to implement a flexible model allowing for an effective telephony experience for Ubuntu users.
Line 12: Line 12:
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! Desktop domain calling services will empower users to unify their telephony experience in new ways on Ubuntu. This includes creating and participating in secure calling networks over the Public Internet, as well as enabling access to both local and remote telephony resources and services in a unified client experience.
Line 16: Line 16:
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. There is need to be able to use any resource that is available for communicating with people, whether a local modem device, an existing service provider, a private IP-PBX, or even directly in a secure manner using the public Internet, and to be able to do so automatically without requiring user intervention when situations such as connectivity to external services change.

To enable a complete telephony experience we can begin with unifying the client experience such as with Telepathy. For example, we want to begin with one universal contact for telephony be it a phone number or a sip uri, and a consistent manner for a single client to connect to said user with a single contact without requiring our users to determine where or how the call is actually placed, what service entry to use, etc. The user experience should be seamless, and hence the purpose of proposing a local mediating service for the SIP protocol.
Line 22: Line 24:
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.
User wants to call other users at remote locations. This might be by SIP uri or by a telephone number. Whichever use, it should not matter for the user to have to think about which profile or account to "use" and hence should be handled consistently from the client perspective regardless if the call is ultimately handed off for completion using a modem device, gsm radio, some SIP service provider, a local or remote IP-PBX, or the public Internet directly for secure URI peer to peer calling. Nor should the user need to consider which set of SIP settings for NAT issues are required based on who the user is calling and how the call is being completed.
Line 34: Line 35:
For Lucid:
Line 37: Line 37:
 * 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
 * Possible debconf option for config file at package install
 * Basic documentation on how to setup and use with Empathy
Line 41: Line 40:

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
Line 49: Line 43:
Lucid:
Line 52: Line 45:
 * gui app time unknown
Line 58: Line 50:
 * New gui app for system-admin to create sipwitch configurations None anticipated for Lucid.
Line 62: Line 54:
All upstream, noted in effort.
Line 63: Line 57:

There is no data requiring migration.
Line 66: Line 62:
Basic connectivity can be tested with sipquery command. It is possible a special test site could be created to test dialing to an external domain.
Line 68: Line 66:
== Action Items ==  * Gateway support. This spec offers a way to unify client communication with IP-PBX services offering pstn gateways, that may also run on Ubuntu, but it does not define or address these. This will likely be addressed lucid + 1.

== BoF agenda and discussion ==

'''From UDS Lucid:'''

"or why the desktop telephony user experience has been miserable so far"

'''History:'''
 * Iphone in 1995 was offered by an Israeli company, worked on dialup
 * Gnomemeeting / ekiga / empathy
 * Secure voice call a few years back, but required knowledge of each party's IP

FSF is trying to replace skype with a Free software alternative (sip witch):
http://www.fsf.org/campaigns/priority.html#skypereplacement

'''Existing software:'''
 * SFLphone
  * Packaged, third-party, GPL, not for Karmic yet
 * GizmoProject / Gizmo5 http://www.gizmo5.com - not available anymore, non-free, acquired by Google
 * Qutecom (ex wengophone)
 * Twinkle
 * Empathy / telepathy
 * Ekiga

Empathy is our default app for communication, we should figure out how to make that experience good

'''Usability issues:'''
 * Too many options exposed in the UI
 * NAT problems
  * Even more problems when using multiple interfaces (vpn)
 * Google talk: enter username and password, and it just works
  * Have configurations for multiple providers, as a drop-file just as we do with broadband providers

'''SIP Witch:'''
SIP Witch will take care of encryption and NAT and finding an available service. So we tell telepathy to just talk to SIP Witch.
 * Integrate it to sofia-sip-bin / sophia-sip-telepathy ?
 
http://savannah.gnu.org/projects/sipwitch

Integration into Ubuntu One?

'''Issues:'''
 * Create desktop telephony use case that make sense
 * Current telepany does not provide secure calls

'''Action Items:'''
 * Make sure sip witch is packaged in Ubuntu
 * SIP Witch needs some improvements
  * Easier way to add provider information into sip witch
  * Document current SIP providers and how to use them with SIP Witch
  * Add logic to abstract using SIP providers (and help them add their config info)
  * Password synchronization (betwixt local user and service)
  * Work with more services
  
 * Make it easier for people to test, get lots of feedback/bugs
  * Add link to Answers in Launchpad so problems/info are *asked* first then
  * Add some documentation to the wiki, advertise its existence
  * Link to Freenode webchat for easy " I want to test " pairing
 
'''For Lucid+1?:'''
 * Add logic to telepathy to recognize sip witch to automatically configure
 * Integrated with UbuntuOne(?)
 * d-bus integration

 

Summary

GNU SIP Witch is a service for the SIP protocol that is analogous to what Jabber does to XMPP, that is it offers registration, routing, and messaging between arbitrary SIP endpoints and resources. GNU SIP Witch was selected as part of the FSF initiative to replace Skype with free software, however there are additional opportunities that are very relevant to Ubuntu. SIP Witch can also be used as a local back-end to unify the telephony experience of desktop users in Telepathy and other desktop SIP user agents by automatically mediating access to local telephony resources such as SIP devices, desktop modems, gsm radio, idsn adapters, or local telephony servers, as well as remote VoIP service providers and enabling direct and secure call peering over the public Internet. The goal is to identify the work required to implement a flexible model allowing for an effective telephony experience for Ubuntu users.

Release Note

Desktop domain calling services will empower users to unify their telephony experience in new ways on Ubuntu. This includes creating and participating in secure calling networks over the Public Internet, as well as enabling access to both local and remote telephony resources and services in a unified client experience.

Rationale

There is need to be able to use any resource that is available for communicating with people, whether a local modem device, an existing service provider, a private IP-PBX, or even directly in a secure manner using the public Internet, and to be able to do so automatically without requiring user intervention when situations such as connectivity to external services change.

To enable a complete telephony experience we can begin with unifying the client experience such as with Telepathy. For example, we want to begin with one universal contact for telephony be it a phone number or a sip uri, and a consistent manner for a single client to connect to said user with a single contact without requiring our users to determine where or how the call is actually placed, what service entry to use, etc. The user experience should be seamless, and hence the purpose of proposing a local mediating service for the SIP protocol.

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. This might be by SIP uri or by a telephone number. Whichever use, it should not matter for the user to have to think about which profile or account to "use" and hence should be handled consistently from the client perspective regardless if the call is ultimately handed off for completion using a modem device, gsm radio, some SIP service provider, a local or remote IP-PBX, or the public Internet directly for secure URI peer to peer calling. Nor should the user need to consider which set of SIP settings for NAT issues are required based on who the user is calling and how the call is being completed.

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

  • Packaging of sipwitch daemon (nearly done)
  • Completion of packet forward feature for proper NAT support
  • Possible debconf option for config file at package install
  • Basic documentation on how to setup and use with Empathy
  • Cache user sip hashes when user passwords change via pam stack and new /etc/sipwitch.db

Effort

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

UI Changes

None anticipated for Lucid.

Code Changes

All upstream, noted in effort.

Migration

There is no data requiring migration.

Test/Demo Plan

Basic connectivity can be tested with sipquery command. It is possible a special test site could be created to test dialing to an external domain.

Unresolved issues

  • Gateway support. This spec offers a way to unify client communication with IP-PBX services offering pstn gateways, that may also run on Ubuntu, but it does not define or address these. This will likely be addressed lucid + 1.

BoF agenda and discussion

From UDS Lucid:

"or why the desktop telephony user experience has been miserable so far"

History:

  • Iphone in 1995 was offered by an Israeli company, worked on dialup
  • Gnomemeeting / ekiga / empathy
  • Secure voice call a few years back, but required knowledge of each party's IP

FSF is trying to replace skype with a Free software alternative (sip witch): http://www.fsf.org/campaigns/priority.html#skypereplacement

Existing software:

  • SFLphone
    • Packaged, third-party, GPL, not for Karmic yet
  • GizmoProject / Gizmo5 http://www.gizmo5.com - not available anymore, non-free, acquired by Google

  • Qutecom (ex wengophone)
  • Twinkle
  • Empathy / telepathy
  • Ekiga

Empathy is our default app for communication, we should figure out how to make that experience good

Usability issues:

  • Too many options exposed in the UI
  • NAT problems
    • Even more problems when using multiple interfaces (vpn)
  • Google talk: enter username and password, and it just works
    • Have configurations for multiple providers, as a drop-file just as we do with broadband providers

SIP Witch: SIP Witch will take care of encryption and NAT and finding an available service. So we tell telepathy to just talk to SIP Witch.

  • Integrate it to sofia-sip-bin / sophia-sip-telepathy ?

http://savannah.gnu.org/projects/sipwitch

Integration into Ubuntu One?

Issues:

  • Create desktop telephony use case that make sense
  • Current telepany does not provide secure calls

Action Items:

  • Make sure sip witch is packaged in Ubuntu
  • SIP Witch needs some improvements
    • Easier way to add provider information into sip witch
    • Document current SIP providers and how to use them with SIP Witch
    • Add logic to abstract using SIP providers (and help them add their config info)
    • Password synchronization (betwixt local user and service)
    • Work with more services
  • Make it easier for people to test, get lots of feedback/bugs
    • Add link to Answers in Launchpad so problems/info are *asked* first then
    • Add some documentation to the wiki, advertise its existence
    • Link to Freenode webchat for easy " I want to test " pairing

For Lucid+1?:

  • Add logic to telepathy to recognize sip witch to automatically configure
  • Integrated with UbuntuOne(?)

  • d-bus integration

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