
GNU SIP Witch 1.0 released for peer-to-peer next gen VoIP - Grauwolf
http://planet.gnu.org/gnutelephony/?p=18
======
viraptor
Does anyone know why is it "next gen"? And how does "peer-to-peer" mean in
this case?

The only description of sip witch with some actual content (that I could find)
is here: <http://www.slideshare.net/gnutelephony/harvard2010> However it's
missing some really important points and looks like technical issues are just
skipped:

\- How do users locate each other? (looks like user@domain is "known" somehow)
GNU telephony blog mentions "peer-to-peer mesh calling networks" but I can't
find any actual working prototype.

\- Why wouldn't I just use Freeswitch which can support both nat traversal and
ZRTP?

\- How do they imagine the initial connection with both sides behind the
firewall if no ports are mapped? (skype can do that due to known network of
hosts)

If they don't have some great solutions here, I'm not sure why are they
writing this from scratch instead of adding those "peer-to-peer mesh calling
networks" capabilities as a standardised protocol to PBXes which are used
nowadays (asterisk, freeswitch, yate).

~~~
MichaelGG
If it's user@domain, it's probably just using SIP URI routing. (You define
records in your domain to lookup the responsible SIP server, similar to how
email works, but more complicated just for the fun of it.)

FreeSWITCH is a great starting point, but NAT traversal isn't reliable for
point to point, for the general case. You have to consider symmetric NAT
without UPnP and firewalls that allow outbound+response, but no incoming. In
these cases, you are going to need a proxy with a public IP that can relay
audio. That's the only reliable thing that's going to work in all cases. (Just
look at the IETF's documents on NAT traversal where they come up with all
these complex ways to try to exploit limitations in certain NAT devices...)

Actual NAT traversal in SIP/RTP is very straightforward. You just ignore the
silly parts in spec that specify IPs, and just reply to the IP:port combo you
received from. For RTP, same deal. You know where you'll receive RTP, so as
soon as you get a packet there, you just reply to the IP:port it came from.

Skype's "breakthrough" that let them win so much early on was that they used
P2P to do public IP relays, since connectivity between any two points is not
guaranteed. (Had MS been smart enough to proxy audio/video in their clients
early on, they might have dominated this market to begin with...)

So, to overcome this with free software, they'd need a public IP relay system
that protects things end-to-end. If they do that, it could be worth watching.
But from that linked presentation, they expect Sipwitch to update the firewall
rules in such access. Good luck with that.

~~~
viraptor
I can't find the bits about updating firewall rules, but anyways... They keep
concentrating on the media path, while getting the signalling to the right
place is just as hard. They need some public relay and that's one part I still
haven't seen seriously mentioned yet. I disagree with "Actual NAT traversal in
SIP/RTP is very straightforward." - since there are many issues:

\- They can't use end-to-end encryption since public relay has to add
information about the public address the message came from (unless it wants to
transfer the media itself).

\- They can't allow random changes to addresses by intermediate nodes, since
that would allow trivial attack on the mesh infrastructure.

How will they stop a situation where someone creates lots of nodes, proxies
SIP, but randomises the media addresses? Media address can't be encoded at the
source, since it has to come from the relay. It wouldn't be hard for a
competing company to spawn thousands of nodes on EC2 and overload the network
with broken "relay" nodes.

~~~
MichaelGG
Sorry I should have made it clear. SIP/RTP don't work with NATs at all (public
IP and a NAT'd client) if you follow the spec. By NAT traversal with SIP, I'm
referring to this case, not NAT'd client to NAT'd client.

You're right that using relays requires some thought in order to keep it
secure.

------
advisedwang
The blog post tells us a release has occurred, who wrote it, who the FSF is,
what the relationship between Witch and Free Call is. However I can't for the
life of me figure out what GNU SIP Witch is.

~~~
p4bl0
Here: <http://www.gnutelephony.org/index.php/GNU_SIP_Witch> I found this by
following two links from the article. But it was random luck, I agree with you
that the article lack of some important informations.

------
zbowling
Asterisk not open enough for GNU?

~~~
viraptor
They might take issue with a couple of things like
<https://issues.asterisk.org/view_license_agreement.php> , "commercial
edition" based on the open one, deals between asterisk and skype which makes
closed-source skype channels available for asterisk (who knows how would it
affect skype-competitor plugins) and many others. While nothing critical, I
think GNU people might not entirely like it.

~~~
zbowling
The fsf/GNU isn't anti-commercial, just anti-proprietary. Free speech vs. Free
beer. I doubt Asterisk dealings with Skype for special access for it's
customers that pay a preium service fee really bothers them, except maybe
helping Skype propagate it's proprietary tech indirectly.

What asterisk does is no different than MySQL and QT.

------
alwillis
It’s kind of funny, but not really how they botch the description “Apple
OS/X”; all they has to say was Mac OS X.

