Live data from Hacker News

GNU SIP Witch 1.0 released for peer-to-peer next gen VoIP

planet.gnu.org

11–12 of 12 posts

Re: GNU SIP Witch 1.0 released for peer-to-peer next gen VoIP

#11
post #3

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 blo…

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 n…

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.

Re: GNU SIP Witch 1.0 released for peer-to-peer next gen VoIP

#12

Earlier quoted context omitted.

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 n…

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…

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.

Post reply on HN