GNU Free Call Announced

“Free as in freedom, and free as in no cost, too!”

GNU Free Call is a new project to develop and deploy secure self-organized communication services worldwide for private use and for public administration. We use the open standard SIP protocol and GNU SIP Witch to create secured peer-to-peer mesh calling networks, and we welcome all participation in our effort.

Who
Haakon Eriksen – Project Coordinator – haakon.eriksen@far.no

David Sugar – Project Architect – dyfet@gnu.org

What
Our goal is to make GNU Free Call ubiquitous in a manner and level of usability similar to Skype, that is, usable on all platforms, and directly by the general public for all manner of secure communication between known and anonymous parties, but without requiring a central service provider to register with, without using insecure source secret binary protocols that may have back-doors, and without having network control points of any kind that can be exploited or abused by external parties. By doing so as a self organizing meshed calling network, we further eliminate potential service control points such as through explicit routing peers even if networks are isolated in civil emergencies.

We do recognize this project has significant long term social and political implications. It also offers potentially essential utility in public service by enabling the continuation of emergency services without requiring existing communication infrastructure. There are many ordinary public service uses, such as the delivery of eHealth services, as well as medical, and legal communication, where it is essential to treat all with equal human dignity by maintaining privacy regardless of race, religion, or political affiliation. Equally important is the continuation of emergency medical services even when existing infrastructure is no longer available or has been deliberately disabled.

How
Initially we will extend sipwitch to become aware of peer nodes by supporting host caches, and then support publishing of routes to connected peers. This work builds upon the already existing routing foundation in sipwitch itself. The use of host caches is a mechanism used in older p2p networks, it is generally well understood, it would meet the initial goals of establishing a self organized mesh network, and it is rather easy to initially implement to fully demonstrate the potential of sipwitch as a mesh calling system. More advanced methodologies can then be added later on.

Related to this goal is having sipwitch operate as a SIP mediation service for desktops users and IP enabled cell phones such as Android. This introduces the needs for users to be able to “pilot” their local sipwitch instance through a desktop and cell phone gui, whether to see what calls are being placed through it, or to see the verification status of secure key exchange. There are today IPC interfaces in sipwitch to allow for desktop integration, but a specific GUI to use these interfaces and present server and call states in a manner for people to understand still needs to also be constructed, and hence this too is part of the plan of work for this project.

In addition we will be extending GNU SIP Witch to offer secure VoIP proxy. Much like what was done initially by Phil Zimmerman to develop ZRTP using zfone, this mode of operation will enable development of key elements of a secure infrastructure without having to also initially create new SIP user agent applications. By offering secure proxy through a SIP Witch instance running at the endpoint, any existing SIP standard compliant softphone or device will be able to establish a secure connection to another standard compliant SIP device or SIP peer that is using GNU SIP Witch at the destination.

This project’s definition of secure media is similar to Zimmermann’s work on ZRTP, in that we assure there is no forwarding knowledge by using uniquely generated keys for each communication session. Furthermore, we will use GNU Privacy Guard (GPG) to fully automate session validation. This will be done by extending the SIP protocol to exchange public keys for establishing secure media sessions that will be created by each instance of SIP Witch operating at the end points on behalf of local SIP user agents, and then verifying there is no man-in-the-middle by exchanging GPG signed hashes of the session keys that were visible at each end.

Why

1. Why GNU SIP Witch?
GNU SIP Witch is a destination router for the SIP protocol. This means it is primarily concern is not in making things interconnect “with” the SIP Witch Server, like say something like Asterisk does very well, but rather instead is designed to enable two (or more) endpoints to find and then directly connect with each other. By handing off media operations directly to communicating endpoints, GNU SIP Witch requires a minimum of system resources, making it very suitable even for low end embedded routers, as well as for freedom boxes, shared virtual server instances, desktop systems, and IP connected cell phones such as Android, rather than requiring a dedicated server.

2. Why on the desktop and cell phone?
Ultimately we want to be close to the user so that no third party or external service must be connected to before establishing secure sessions since we are using unmodified SIP clients. If an external party is required, the connection between the SIP client and that external service would of course be completely insecure. A user with their own local infrastructure can of course also run a single sipwitch server, such as on a freedom box or a virtual machine, to meet all their local connectivity needs rather than doing so on each machine or device. An organization can also run a sip witch server on a completely remote site, such as a public portal, when interconnecting existing security enabled SIP clients, such as SIP Communicator and Twinkle, which support the ZRTP protocol stack. Another side benefit of having SIP Witch on the desktop and cell phone is that as we develop SIPWitch NAT services, it can act as a single point of contact for mediating all SIP protocol services for a user, as well as offering a single place where NAT support and mobile re-connection will only need to be configured and implemented once, rather than in each SIP client separately.

3. How to get GNU SIP Witch?
GNU SIP Witch is formally distributed as a package that is part of the GNU Project. It is also packaged in a number of popular GNU/Linux distributions, including Ubuntu and Fedora, GNU SIP Witch can also be built on most BSD systems from source, including OS/X, and supports compilation on Microsoft Windows as well.

4. How to configure GNU SIP Witch?
In the past GNU SIP Witch has been difficult to configure, even for ordinary uses. To address this issue we are hoping to finally introduce a model public portal that anyone will also be able to download and use to construct and configure a SIP Witch site or private service. To address the needs of peer-to-peer calling, we are introducing a desktop and cell phone GUI interface.

5. Why do I need a local SIP account to use it?
Since GNU SIP Witch is a SIP service one needs a SIP identity to authenticate yourself to your own local SIP server. However, we wish to eliminate manually creating local SIP users by offering to automatically detect and generate a local user account with a matching SIP user agent configuration for you as a single click operation from the new GUI. Initial clients proposed for this include Android CSipSimple, which is also being extended with GNU ZRTP, the Twinkle Softphone, and perhaps SIP Communicator, which uses the GNU ZRTP4J stack. Other clients, like GNOME Empathy and Linphone, may also be supported in this way as well.

6. How can I participate?
We have a wiki site used for GNU Telephony as a whole (http://www.gnutelephony.org/), as well as a mailing list for sipwitch itself (sipwitch-devel@gnu.org). In addition, to discuss core architecture, privacy issues, and social consequences, we have another mailing list gnucomm-privacy@gnu.org.

78 Responses to “GNU Free Call Announced”

  1. Leo Says:

    I would like to propose, that the GUI code would be modular from the rest of the code base. This would allow for Gnu Free Call to appear to be (and behave) like a platform native app, instead of appearing to be a mish-mash of GTK, X11 and disease.

    If you’d like to get a good idea what i mean by GUI modular code, take a look at the Transmission BitTorrent client. It is a fine example of GPL’d software, that also has a native GUI for every platform it’s built for (Win, Mac OS, Linux etc.), that makes it look and feel like it was written for that platform alone.

    P.S.

    I know this is going to be rejected, because GPL developers will always have the need to school the foolish closed source OS users about their bad choices.

  2. dyfet Says:

    The GUI is going to be a separate application interfaced to sipwitch through sipwitch’s already existing control, shared memory, and events IPC services. It is already possible to build the GUI modularly and separately from the primary codebase.

  3. Nikos Says:

    I see you want to extend SIP to use GPG. There is RFC 5764 describing SRTP using Datagram TLS. TLS (and thus datagram TLS) can be used with openpgp keys (RFC 6091). Why define yet another security protocol and not use the existing ones?

  4. Flyser Says:

    Sounds awesome?
    Is there any kind of roadmap, which summarizes the milestones you want to achieve? What works at the moment? what do you want to achieve in a month? what in a year?

  5. Vuong Says:

    This news is really awesome. However, I am not sure if its quality is better than Skype or not. Anyways, another choice, another decision :-) . Thanks for your service and hope you will soon to be a next big thing!

  6. hapoo Says:

    If you want to make a true impact, make the protocol stealth. Encapsulate it in something like https so as to get around filters. As world changing as skype and sip may have been, they’ve been blocked and censored in the places which need them the most. Strive to make a protocol which can’t be blocked so easily.

  7. Andrew Burgess Says:

    those mailing lists took a little time to find.
    how about adding these links?

    http://lists.gnu.org/mailman/listinfo/sipwitch-devel
    http://lists.gnu.org/mailman/listinfo/gnucomm-privacy

  8. Patcito Says:

    How about video? If you want to compete with skype you’ll have to add support for video conference too. Is that on the road map? I don’t think people will give up on skype if they’ll use such an important feature as video.

  9. GNU Free Call « Events « Opensourcepedia – Where source code can run free! Says:

    [...] Free Call ShareToday GNU announced it’s Free Call project to develop and deploy secure self-organised communication services worldwide for private [...]

  10. GNU Free Call: un Skype en software libre — Bitelia Says:

    [...] etc pero ¿y si se crease una red alternativa a Skype totalmente libre y segura? Bueno, pues parece que este proyecto ya existe y se llama GNU Free Call.GNU Free Call pretende ser un servicio multiplataforma, orientado al usuario final y sin necesidad [...]

  11. GNUnet fan Says:

    Have you considered making it on top of GNUnet? I think it’s quite reasonable just to create a GNUnet VoiP application. Why create another P2P network? And AFAIK there guys are currently implementing a Mesh API.

  12. GNU lanza el proyecto Free Call, un Skype libre — ALT1040 Says:

    [...] | 14 de Marzo de 2011, 22:45 “Libre como la libertad, pero sin costes”. Así comienza el décálogo que acaban de publicar Haakon Eriksen y David Sugar, los dos nombres que se encuentran detrás de esta increíble y [...]

  13. Eric Says:

    So, will it be easy to use? After all, there is no freedom if people can’t figure out how to use it!

  14. В рамках проекта GNU Free Call создается свободная замена Skype | AllUNIX.ru – Всероссийский портал о UNIX-системах Says:

    [...] инициативы GNU Telephony представили новый проект – GNU Free Call, нацеленный на разработку и [...]

  15. dyfet Says:

    Video is a function of the user agent, not sipwitch. Since we do not transcode media but let the endpoints negotiate it directly, we do not have to implement code to support it or any other form of media. What we do need to do however is add code to the new gui to discover locally installed clients (such as ekiga, twinkle, empathy, etc, whatever can be supported this way) and then automatically configure your client for you to talk to sipwitch locally.

  16. Daily Dose #12 – GNU Free Call | Naidoo Says:

    [...] standards and protocol for secure, self-organized, open telephony communication. It’s called GNU Free Call. GNU (an iterative acronym that stands for “GNU Not Unix!”) is a Unix-like operating [...]

  17. Ralph V. Says:

    How about support for SIP adapters such as Cisco ATA-186 or linksys?

  18. Dag Says:

    How about support for zrtp?

  19. K_L_user Says:

    I hope there will be a Qt client. I don’t use skype, because of privacy, but I’ll use GNU Free Call!

  20. Voptop Says:

    Stop stealing ideas from voptop (http://www.voptop.com)! Use your own brains! And stop right now!

    This is an copyright infringement!

  21. dyfet Says:

    Has anyone ever even heard of a voptop? I certainly never have, nor is anything I am doing any different from anything I have written about over many years.

    In regards to ZRTP and ATA’s, since sipwitch is an interconnect service, and does so by letting endpoints negotiate a direct media path, it is very happy to use with ZRTP. The purpose of secure proxy is to give the same benefits to existing SIP devices and applications which are not ZRTP enabled.

    In regard to QT, that is what I am experimenting with currently. There will be a QT gui.

    Hmm…GNUnet, I will have to look at that.

  22. James Says:

    Reading this announcement, it sounds like a noble aim… but don’t forget about the aspect of end user acceptance, and marketing… this has to be at least as easy as Skype to install and use. Also, it needs not to have crazy omissions like some of the existing infrastructure, I can’t use SIP via Empathy because you cannot specify what audio device it uses… I’ve found numerous bug reports all being closed with “Use sound preferences to set the default sound device”.. which is of course useless if you have a headset that you want to use only for VoIP calls…

  23. NOvoptop Says:

    voptop seems like a vaporware, hence the name voptop.

  24. mitcoes Says:

    Thanks for the project, here is my wishlist:

    Another name, there is a company named Freecall, you can Google it, FREESPEAK is my suggestion as freecall, freecom, and freetalk are currently used. but another companies or projects any other would be good too.

    I would like that the program would allow virtual phone numbers to receive calls from “normal” phones and identify itself as a “normal” phone, and as a way of have some money selling this numbers and with agreements with phone companies.

    I also would like that in the identificator every user would have his name, alias or username, and a pseudo phone number (VoIP number) – plus the “normal” virtual phone number if it is adquired.

    And that from VoIP number to other it can be send color fax with PDF format to send docs from libreoffice and other apps as an alternative to the e-mail.

    Of course a message system as SMS and to SMS.

    And a cheap device, perhaps made with an arduino, to conect to a router and or a wifi where you can plug DECT “normal” phones to make it your home phone line.

  25. Yannick Says:

    Copyright infringement? voptop? C’mon this idea of having VoIP over P2P is there since long ago, and there is even an effort for IETF standardisation here: http://www.p2psip.org/

    Please, stop the FUD!

    Best regards,
    Yannick, from the Ekiga team.

  26. Ellis Rubio Says:

    Hello GNU Telephony, This is a new beginning to revolution the people communication around the world, hope poor village inside of developing countries find the way to open frontiers of knowledge and discrimination, deep inside of this project I see enlightenment of the Project Coordinator and Project Architect, good wind and good sea, please keep in touch and let me know your news, Ellis, engineer, Colombia.

  27. George Says:

    Sounds a little like the Serval Project : http://www.servalproject.org as they are doing a voip mesh network base with android, the key difference is that the handsets report their telephone numbers to the network and it aliases them over on the fly generated sip routes, so to the end user you just dial the persons telephone number. Might be something worth checking out.

  28. George Says:

    And at the person who mentioned votop, its a centralized server based mesh network, hardly what I want. In a perfect world it would be 100% decentralized, node based p2p.

  29. dyfet Says:

    I had learned from him that he first published sometime in 2009. Unfortunately, sip witch was already first released in April of 2008, explicitly at the time as a “secure peer-to-peer SIP server” (going back to the original freshmeat announcement and entry). But it does not even matter and there have been other people and groups working in this space too, serval being just one example. Only the proprietary software mindset looks to try to selfishly control what others can or can’t do.

  30. Voptop Says:

    Hi dyfet,

    think we could transfer the discussion from mail to here into the public. The Thesis was published 2009 the first papers and presentation were published in October 2005.
    But anyway, for me it was just hard to see that someone else published “my idea”, but after research it looks like you guys just had the same idea more or less parallel to me.
    I just needed a second to come over the first anger ;) . I think as developer you should understand the situation, if you work a long time at a project and than there is someone who takes the “results” (that was what it looked for me at first).

    regards,
    Robert S.

  31. ichat Says:

    1 thing that i would wish for is ‘end’ point selection from the start up.

    i mean that i would like the idea that compercial endpoint providers coud hook up to the network, and provide landline services. i would have sipswitch than select the right ‘connection / username / node’ based on rulez that i pecfiy in its config.

    it could at least
    > ask for a username to connect to.
    > how long (duration) i want to connect (mins / hours / unlimited)
    > based on witch filter (phone numbers) i want to sellect this provider.

    if you provide this from starters, and based on a single set of guide lines, than chances are that you wont get 20 diferend implementations / and clients for the same service….

    so if any modifications are required for such services do them now. so that it can REALY beat skype at every game

  32. ichat Says:

    @votop – this seems like a chance though, seeming that A you website at this time still lacks any defenit releases, and counting on that you have already worked on this … you may want to join up and help this project (and yourself) along.

    you may have noticed that a lot of companies can make a proffit of opensource support.

    you may already have tested stuf, and/or have expertise that coulg gain this project and your ideas. also you coul well be the first to support a commercial prouct (like land line sevices) based off this new network.

  33. Khudson Says:

    Hey guyz,this really good and when implemented very well it will have an impact,but i would encourage you to also some libraries of erlang like megaco,this is basically a media gateway controller,it will help in distribution and supervision of nodes and super node

  34. Funklord Says:

    What’s the reason you didn’t decide to use IAX2 instead?
    Or both?

  35. ? Says:

    Minisip has been around for a while and offers some of the things people here asks for. Check it out http://minisip.org/

    Any SIP-capable client should be able to connect to other given that they use the same codecs and encryption methods. Minisip offers several.

  36. John Bokma Says:

    Excellent news, can’t wait to replace Skype with this.

  37. Michael S Collins Says:

    David,

    This all sounds very interesting! The guys over at the FreeSWITCH project are always interested in secure communications and “free” speech. PRZ has made ZRTP available to all FreeSWITCH users (thanks Phil!) and we’re always looking to make secure communications more available. Let us know if there’s anything we can do to make sure that FreeSWITCH works well with GNU Free Call. Also, if you’d like to come to ClueCon this year and talk about this new endeavor that would be awesome!

    Michael S Collins
    FreeSWITCH Community Liaison
    http://www.freeswitch.org
    http://www.cluecon.com

  38. Yan Says:

    The top priority in this project is the support of nat and exotic firewall transversal. This is the number one reason why people use Skype : it works.
    I was thinking about a tunneled mode, where SIP+SDP is encapsulated into a TCP connection, with the optional possibility to go over HTTP protocol. OpenVPN can provide some code for this part or at least inspiration.
    After, the network of super nodes can be used to provide these facilities.
    UPNP and NAT-PMP management is also needed to elect client as super node when possible.
    Second reason is the codecs, but G722 is present and working really good.

  39. cbo Says:

    suggestion: it would be great to include a ptt mode to work like hamsphere, so as to be able to hear conversations or stay informed in emergency scenarios. A bittorrent streaming based on p2p could scale well, like swarmplayer.

    http://en.wikipedia.org/wiki/Tribler#SwarmPlayer

    Please talk with servalproject, it pursues same goals but had to discard sip for being too chatty (in their own words).

    good luck

  40. Mikhail Zabaluev Says:

    Sofia-SIP is a mature SIP protocol stack: http://sofia-sip.sourceforge.net/

    For desktop integration on UNIX-like systems, consider Telepathy: http://telepathy.freedesktop.org/

  41. patufet Says:

    What about “QuteCom”, isn’t a similar project?

  42. ab Says:

    The key win for Skype was their NAT traversal algorithms, and a sign up built into the client.

    If you don’t make it absolutely idiot proof (please — no client-server apps *needed* on the same host), then its just not going to take off. No opening ports, nothing but click click click, type username and go.

    That includes making cryptographic authentication *optional* (yeah, id like to talk to that guy on the other side of the planet, but I have to wait until he snail-mails me his public key.

    Now I have to import it by dragging it onto a seahorse, then I have to….)

  43. ab Says:

    Also, can you clarify your progress since the first post here about sip-witch in 2009?

  44. Pietro Says:

    Just stopping by to wish you guys luck!

  45. VPSLIST Says:

    I can’t wait to try it out. I’ve been wanting to use SIP / VoIP rather than Skype. Don’t get me wrong – I like Skype, it’s decently priced and it works but when I can do something on my own I prefer to do it!

  46. A Says:

    I love the idea!

    The impression that I get is that you intend for sipwitch installs to network and create some fancy mesh. If it is at all possible to use some “standard” like the proposed p2pSIP instead, that would be ideal, as it would be a lot easier to convince someone like Cisco to implement p2pSIP instead of installing sipwitch on their routers.

  47. Bob Robertson Says:

    The combination of GNUnet, TOR and GunFreeCall would be very, very interesting.

    It might also be completely impossible to hear anything!

    If I may, as a user, echo what some other people have said: Put this on top of existing infrastructure, rather than re-inventing. GNUnet looks interesting, as does TOR. For years I’ve wondered why no one wrote such a voice application on top of something like the Gnutella system.

  48. Darren Starr Says:

    SIP is the smallest of the problems involved in this project and frankly is not all that important.

    A SIP server does little more than negotiate connections between two or more clients and with the assistance of STUN, TURN, ICE, etc… punches holes in firewalls to allow calls to be made. The only real advantage of ICE over a good service like XMPP is that there are tons of clients for it and you can buy SIP based telephones for it.

    Instead of wasting time with making yet another sip service and running a sip network, focus more on making sip work instead. This would include the concept of a centralized account for a user. They should be able to enter their user name and password on to a device containing a SIP, XMPP or whatever client and instantly have access to their personal data.

    Your server doesn’t offer anything interesting as you’ve focused on technology and not usability. You’re simply advertising a SIP network for nerds. Security is interesting, in fact it’s quite fun. I’ve implemented both SRTP and ZRTP into SIP clients before. But, who really gives a rats ass? The server plays very little part of interest (at least in ZRTP) other than the SDP negotiation.

    If you want to make something that competes with Skype, you need to start with a server, yes. You need to assemble a list of clients. This means Windows, Mac, Linux, iPhone, Windows Mobile, Symbian, Blackberry and others. You need to work with the authors of each of these clients to integrate your telephone book servers into their systems. For open source clients, you can distribute your own. But since most SIP clients are provided by companies trying to make money by selling minutes to call to land lines, good luck with that. After all, you’re proposing :
    a) Decreasing the users’ dependency on land lines
    b) Unifying their clients with other service providers to bypass the need for a service provider such as themselves to call their friends.

    So, good luck with that.

    You have what I can only assume is good motives, but really, your project is purely academic. Assemble a business model for the project, file for an AS, then go to Innovasjon Norge and get funding for your project and actually make something happen with it. I’ll warn you though, Innovasjon Norge has stopped giving money to innovators and instead prefers to give money to companies that don’t need it but are glad to take money for projects they would have funded themselves anyway.

  49. luis hasbon Says:

    Hi comunity, I’ve read the specifications above and its good the effort of using standart protocols, I would suggest that as the GUI lib make use of Qt4, because of its portability and nice visual apealing. I want you to know I would be glad if I could join in as part of the comunity developers, anything just let me know. Greetings from Colombia.

  50. Eric Jacksch Says:

    Interesting idea, but:

    1) Skype is largely successful because it easily traverses firewalls and NAT gateways. Supporting SIP for mobile users is a nightmare. An new version of SIP or a well designed encapsulating protocol needs to be designed and built-in to a variety of hardware and software products.

    2) The last thing we need is yet another P2P network. We need a distributed way for SIP users to look each other up. How about DNS?

  51. Damian Pound Says:

    Could this project use openID to help people connect to eachother? I’m not saying as a requirement just a optional convenience. Also, would it be possible to integrate this with GNUnet? I think development could be easier that way because a lot of stuff is already “done” (never truly, but close) you just have to implement part of your project on top of that. GNUnet developers will probably help your project just because they see it in the repository.

    Over simplification most likely, but I can’t understand everything.

  52. Nick Says:

    Will FreeCall also encrypt the stream? If so you might want to take a look at the following:
    http://portal.acm.org/citation.cfm?doid=1880022.1880029

  53. Michis Says:

    Suggestion; a fast news over identi.ca will be great!, to know about all steps to this interesting project.

  54. Riccardo B. Says:

    Quite interesting news!
    We are an academic group working in signal processing that recently moved to P2P and other networking stuff. Our workforce is not huge, but we would like to jump aboard too.

    I would like to reinforce the proposal of A (March 13th, 3:13 am): if possible, let’s reuse the work of the P2PSIP IETF Working Group. I am not currently up-to-date about the status of their work, but we can check. If they have some working document ready, we avoid the work of inventing our own protocol (with many possible trapdoors along the path), if they have not… we can join the P2PSIP development too.

    If you want to join the P2PSIP ML:

    https://www.ietf.org/mailman/listinfo/p2psip

    Let me state the obvious: as a general rule, we should consider using already developed protocols, resorting to create our own only if unavoidable. We will reduce the required work, we will avoid trapdoors during the development and it will be easier to get a wider acceptance of our software.

    Habete Ludicrum! (have fun :-)

  55. chris g Says:

    Is SIP the best idea, due to NATing issue’s? Skype does a good job to avoid this, especially in the corporate environment.

  56. Natanael L Says:

    I saw that smoebody mentioned OpenID to connect to others. No, that wouldn’t work, but OTOH there ARE something similiar that can be used: WebID (FOAF)

    http://www.w3.org/wiki/WebID

    And #2: Include support for Codec2 by default – 2500 bits per second (!) with the goal to reach 2000 bps and even below in the future! This will make it worl very well even over absurdly slow connections. Like seriously, who doesn’t have at least a 2 kbps connection? Even over ham radio it works well!

  57. conwon Says:

    Hey why doesn’t Robert from Voptop and these people work together and achieve lots.
    That’d be nice, if results can replace egos. Life’s short make the most.
    Make love not war dudes

  58. Zintage Says:

    1: Great idea, it is a real pity nobody started it earlier, so to counteract skype spreading.
    2: don’t get me wrong, I use skype, but I would really love to have another option: a non-commercial one in particular …
    3: stop by TANGO.ME to see a nice competitor: will it conquer a position against skype?
    4: I would be very keen to help: what is there on the roadmap?
    5: as already somebody pointed before … in the group are there only software people involved or market advisors – founding krawlers – political researchers too? I think it would gratly help having big results in mind!
    All the best!

  59. ituba Says:

    Thank you for your great project. It is very exciting in many ways, especially the decentralised and security aspects. Skype, with its centralised server and closed source encryption, obviously fails on both points.

  60. Orlando Says:

    How can I collaborate? I am an avid believer of Open Source. I’m a web developer with a degree in Computer Engineering. I’ll be more than happy to help with the web site.

    Good luck with the project, small steps like these make the world better and hopefully one day, open software (even hardware) is the first choice. We got to cut the strings, one at a time.

    Regards.

  61. heri16 Says:

    Stop messing around from scratch. Just combine freeswitch fscomm and sip-witch and all-just-works. Fscomm is written in qt4 and compiles on unix, mac, linux, windows. Fscomm has the latest codec2 and opus codecs ready for use for low bandwidth channels.

    They both might already work together if sip-witch can work as a proxy.

  62. Mauricio F. V. Says:

    Hello guys, I wanted to thank you and congratulate you for your initiative. This will definitely be very useful for the whole mankind.

    As a GNU/Linux desktop user for 8 years, I’ve been facing too much problems with Skype. It never worked as good as on Windows. I always have to reboot and switch to Windows whenever I want to make a Skype call, and it has been so annoying for 8 years… I hope this will allow me to stay on GNU/Linux when I need to IP call somebody!

    Cheers and congratulations,

    Long live freedom!

  63. Yannick W. Says:

    I think the GNU project has a great role to play here as coordinator/support for a series of initiatives that could make it much faster to implement worldwide, distributed, free and open communication by providing a central support infrastructure and building a exchange framework together with projects like FreeSwitch, Asterisk, OLPC, BigBlueButton, Ekiga, etc. There are loads of free software projects that could really benefit from an organized support infrastructure.

    In any case, it would be nice to know how people outside the technical field of IP telephony (either financially or through promotion with some kind of easy demo software once ir is ready).

  64. Alvaro Cobo Says:

    Guys. I would like to make a small donation for the development of this project. I am sure there will be many people interested in making small donations. Please, let us know if you open a PayPal account.

    I am excited and waiting to see this software published. I am ready to advocate and participate in any campaign to promote its use.

    Thanks a lot for this innitiative!!!

  65. Kusanagi Yagami Kagura Says:

    Will GNU FREE CALL supports Micro$oft Window$?

  66. dyfet Says:

    Kusangi: Our principle concern is in freedom and in enabling freedom, and hence is not in specific “technologies” or platforms. All of our work is already cross-platform and of course we also give people the freedom to port and extend our code to other platforms as they may choose. I of course do principle development on GNU/Linux.

    Alvaro: I will discuss this with Haakon to see what can be arranged. I see no principle being violated in doing that, although I am not too keen on using PayPal specifically, if there is another intermediary we could select for that purpose.

    Yannick, Heri16: I think it is important we do work together or otherwise coordinate with other projects who’s interest are in enabling freedom too. Our interest is principally in changing the paradyne from one where users find each other by service providers, and thereby usability and freedom ultimately depends on the network effects of who is most able to corral the most users, to one whereby users can find each other directly and hence not subject to network effects that potentially lead to proprietary traps. This is different than what most of these other projects are doing, though absolutely where we can fully share code and core functionality we should do so. We are doing so at the protocol level already by explicitly using widely implemented and unencumbered standards and existing libraries.

    orlando: There are many places to start. All our code is hosted in public repositories. There is a wiki to coordinate design activities and documentation. There are many tasks that do not require coding that also need to be done. What would you like to do?

    chris: the ultimate solution to NAT, especially in regard to corporate uses, will likely require http proxying of SIP and even RTP. It certainly can be done. Other NAT issues can be solved with either ICE, port forwarding, or some form of designating “super nodes” to reflect packets. It is not easy, but at least when we do effectively solve them in sipwitch, it then becomes possible to solve them in one place for all potential clients and use cases, not just ours, since we are also using sipwitch as a kind of sip voip mediating service that users will run directly even to interconnect their desktop clients and devices with external service providers or servers such as asterisk, freeswitch, yate, etc.

    @damian: in the end, sipwitch, as a service, is principally concerned with resolving a SIP uri that is being requested into the ip address either of another server or a destination, and in setting up sdp as needed to interconnect to it as needed, such as for NAT issues. Anything that could be stuffed into a sip uri request to sipwitch potentially could be resolved by any means one desires so long as the end result is a sip connectable destination, and plugins can be used to facilitate this process.

    nick: we generally are recommending ZRTP enabled clients for this purpose, and we will later also add our own secure rtp proxying for insecure clients. But by default sipwitch simply enables endpoints to setup their preferred interconnect, including media and whatever kind of encoding desired directly, rather than processing media itself.

    eric: sipwitch already presently uses dns as it’s default means to lookup uri’s for external destinations.

  67. james Says:

    This is a great concept and it seems that the building blocks are in place for various protocols, especially given the work from several other projects. I’d like to second the following sentiments:

    Ab wrote:
    “The key win for Skype was their NAT traversal algorithms, and a sign up built into the client. If you don’t make it absolutely idiot proof (please — no client-server apps *needed* on the same host), then its just not going to take off. No opening ports, nothing but click click click, type username and go.

    and Yan wrote:
    “The top priority in this project is the support of nat and exotic firewall transversal. This is the number one reason why people use Skype : it works.”

    As a persistent NOOB, my take is that to get adoption to a critical mass point, you need to build something that your non-technical friend will use. I tried at several points over a few years to get a SIP client working with my firewall and while I may have been able to get a good result eventually, the ease of Skype made me move over. Since I’m constantly on the phone with people around the world, I’m in your early-adopter target market and I’m either on Android or Mac.

    You don’t need the adoption level of Skype, but to be usefully adopted you need to be simple enough for your noob friend to use.

    The distributed architecture you are proposing, if I get you, is to going to add a significant level of complexity to the project but has payoffs in other ways – for good or ill. It seems you want the technology to be the basis of the unassailable “free cost”. I think that is ambitious, AND glad you articulated re-use of existing technologies in the first phase.

    Best of luck. Send me the alpha release!

  68. Mark Doors Says:

    The world is hungry for a Skype alternative, more power to you.

  69. Dan M Says:

    Great Idea!!! This is good news for the open source world.

    The roadmap has been mentioned before in the comments. It is important to have a goal in mind. If the goal is a secure calling tool, you will go one way, if the goal is a skype alternative I imagine you would go another way. Ultimately, if you want to beat Skype, you would have to be able to accept calls from Skype as well.

  70. AI Says:

    Maemo (Debian-based) and MeeGo also need this kind of solutions in cell phone area.

  71. M> Says:

    We’re really following you and your efforts, people. It’s a great project, desperately needed out there, with millions of potential users fawning about the prospects of a telephony project like this.

  72. Anderson Julio Says:

    Hello, excuse my expression if I’m wrong, the question of security, can use a protocol that uses only one port to generate the less specific cosumo band how to improve the control of the package.
    Example IAX2.

    Thanks.

  73. Haakon Meland Eriksen Says:

    We are pleased to announce that you can help by donating to the Free Software Foundation, which now supports the work of GNU Telephony through its Working Together for Free Software fund – see further info at https://my.fsf.org/donate/working-together/telephony .

  74. John Durston Says:

    Hi, great idea, its good to see people working on a Skype alternative. I have a few friendly suggestions as someone who is a huge fan of GNU/Linux but has many friends who simply don’t get it. If you want mass-appeal (e.g. to compete with Skype):

    1.) Don’t call it ‘free’-anything. People who don’t know about free software immediately read this as ‘poorly-developed junk’ at best, and adware approaching worst. I’ve found it takes a commitment that most people are not willing to make in order to truly understand what the free software movement really means.
    2.) I don’t have a clue about your protocol/data transmission encoding etc. Sorry, but it had better be at least as good as Skype’s. People are absolutely ruthessly critical and will simply use Skype if it is of better quality.
    3.) It needs to be ‘fisher-price’-easy to install and configure. Again, average wIND0Zzz users have zero patience with software.

    Apologies if I have stated the absolute obvoius. I wish you good luck with the project and look forward to the results.

  75. alcazar Says:

    hi,
    i am new to linux, looking for skype alternatives, i run into this cool project but i have not understood how to install it.

    I would like just to chat with one or more friends.

    Is it possible to run “sudo apt-get install ….” ? Should i install GNU Bayonne on my pc before GNU Telephony ?

    thanks to all

  76. Hylton Conacher Says:

    The announcement of Gnu Free Call is excellent news.

    I would love to start using it but would hope that the app is able to import my current Skype and Google Chat contact details.

    Please establish an announcement mailing list, and possibly a users one too.

    I look forward to following the releases and learning from other users.

  77. damballa Says:

    Thanks for the hard work and great planning of all those involved in this Free Call and related projects! It is a super idea whose time has come. I wish it were released right now so I could download it and use it.

    When Free Call is released I am sure that Big Brother will be disappointed — but I and all who love freedom and privacy and know that they are human rights, will rejoice.

  78. Mike Says:

    Great to see people pursuing open standards for P2P communications, let us hope that it will not be too long before we can all start using it.
    Does anyone else remember “Peerio” ? This dates back to 2004 certainly and was a P2P telephony company who actually produced some interesting hardware which was demonstrated at CeBIT 2006. If anyone knows what happened to them please tell us !

Leave a Reply