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).
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.
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.
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.
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.
viraptor|15 years ago
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|15 years ago
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.
advisedwang|15 years ago
p4bl0|15 years ago
zbowling|15 years ago
viraptor|15 years ago
alwillis|15 years ago