P2PSIP: or how to write a thousand RFC’s and still not solve the problem

As a consequence of being stuck inside on a miserable Dublin December day and being away from my development machine I ended up spending the last few hours looking over some of the proposals that are around for Peer-to-Peer SIP (P2PSIP). My interest is mainly academic, I don’t have any work planned for sipsorcery in the area, but does partly derive from interest in contemplating how Goozimo will go about it in order to compete with Skype. One thing’s for sure they won’t be wasting too much time with the proposed P2PSIP enhancements that are floating around in the IETF space which are taking a bad situation, the existing bloated SIP standard and making it much, much worse!

What’s my problem with the P2PSIP efforts? It’s building a house on foundations of sand. The efforts are relying on a bloated set of SIP standards coupled with relying on hacks, and even hacks to hacks to overcome shortcomings in the original SIP standard in dealing with NAT.

The core SIP standard document is 269 pages long and deals with six request types: ACK, BYE, CANCEL, INVITE, OPTIONS and REGISTER; there are additional standards to deal with what are considered core SIP functionality REFER (aka transfers) (23 pages), INFO (9 pages), NOTIFY (38 pages) and more. Then there are the enhancement standards to fix the things the original SIP standard stuffed up rport (13 pages) and PRACK (14 pages). And only then do the extensions and options, including P2PSIP, come in. The size and complexity of the core SIP standard and the excess of addon SIP standards translates into big problems for implementors. A classic example is the SIP stack in the most popular VoIP server around, Asterisk, it’s taken a massive monolithic 27,000+ line C file to implement and has had some serious difficulties with even the core features; the best example is the 3+ years it took to write the SIP TCP implementation.

The P2PSIP efforts are taking a bad situation, the existing SIP standards and implementation difficulties, and building on top of it to make things worse. It’s not only server implementations like sipsorcery and Asterisk that are implementing SIP stacks but also the hundreds of SIP phones, ATAs and softphone manufacturers. In order to make SIP features work a majority of implementors must put the effort in to implement and test them. As the effort required continues to snowball two things are likely to happen: alternative standards will be developed (Skype’s proprietary protocol is an example); SIP device manufacturers will decide it’s all too hard and restrict themselves to the core standard and/or cherry pick SIP add-on standards thus creating big interoperability problems.

The other problem is that even with the reams of SIP and associated standard documents the NAT problem for even the simplest call scenario has not been solved, a very good and succinct explanation of the problem can be found here. As a consequence a further set of standards has sprung up to help SIP (or more correctly the media streams being initiated by SIP) to cope with NAT: STUN, TURN, and ICE being the most popular ones. The paradox is that in the most prevalent type of SIP calls on the internet today, the call between an end-user and a SIP Provider, the NAT mechanisms are often completely ignored and instead a SIP Provider will reflect the media stream back to the socket the client sends from, not a particularly secure mechanism but a pretty robust one and certainly a far superior one to those offered by STUN, TURN and ICE. So all these NAT standards really do is add to the implementation effort for SIP device manufacturers and while they help in some cases they don’t definitively solve the problem and therefore end up creating more confusion for poor users trying to ascertain why their calls have one way or no audio. A side effect I have observed of the failure of the NAT coping mechanisms is that public forums dealing with SIP services have people suggesting STUN settings for completely unrelated problems such as things like callerid.

The foundations of sand are constituted firstly by an overbloated set of SIP standards that are difficult and error prone to implement and secondly by a set of standards to deal with NAT that are not required in the majority of cases and fail to work in a large number of the remaining cases.

Those are the foundations the P2PSIP efforts are proposing to build on. P2P networks are difficult to design, the biggest problem is how to bootstrap peers into the network. To overcome that problem most P2P designs are actually hybrid P2P networks that rely on a central server for a number of critical functions. Napster is the original example of the hybrid P2P network and the failure of it. Napster facilitated mp3 file sharing, largely illegal sharing as it turned out, between peers in the network and because it relied on a central server to allow peers to join the network the authorities were able to easily shut it down. The networks that followed on from Napster, the likes of Gnutella operated without a central server. Without a central server the peer-to-peer networks are very difficult to shut down which is why these type of networks are still around today and largely immune to authorities.

The P2PSIP documents propose a new type of hybrid P2P network that relies on a central server for boot strapping. The P2P network in P2PSIP is primarily a storage layer utilising a Distributed Hash Table (DHT) approach. The DHT replaces the function of a SIP Registrar and SIP Proxy in a traditional “client-server” SIP network (the inverted commas are because SIP is not a client-server protocol but user agents assume client or server roles for certain operations) and the DHT is used to store the contact details of peers that have joined the network. In theory it’s not a bad idea, SIP registrations are a big burden on traditional SIP networks and offloading them to a peer-to-peer network would seem to have merit. It comes down to a trade-off between the server load for SIP registrations and the complexity of implementing yet another new SIP standard in hundreds of SIP devices. If the P2PSIP proposals were restricted to SIP softphones which have the advantage of operating on flexible general purpose hardware then it would be a debate with merit but the strength of SIP is its universality and unless a new proposal is practical IP phones, ATAs, mobile device softphones etc. then it should not even be considered. Another point is a DHT even the best way to scale the storage SIP location information? A standard called ENUM already exists that utilises DNS, a proven scalable storage service, for location information. SIP user agents already need more sophisticated than normal DNS stacks in order to process SRV records that yet another supplementary SIP standard A DNS RR for specifying the location of services (DNS SRV) relies on and in this case one that is already well supported by existing implementations.

Going back to the original question pondered about how Goozimo will implement a peer-to-peer SIP mechanism in order to compete with Skype my guess is that they won’t go near the current P2PSIP efforts with a barge pole. Scaling server side is something Google are experts at so they’ll handle the SIP registrations using the existing mechanism. How they will deal with media and NAT is the big question. In fact it’s always the question when it comes to SIP and NAT. The paradox in this case is that the solution won’t be found by only considering SIP and NAT: NATs are already deployed everywhere and have to be considered a set fixture; as discussed above SIP is already complicated enough. Instead the media layer, in SIP’s case this is usually RTP, has to get smarter. The solution is not TURN which involves proxying the media or even a Skype like mechanism that uses a more scalable approach with super nodes doing the proxying. The media streams are only getting larger with video and conferences and it’s not scalable to proxy it and also not desireable as every extra hop the media goes through adds latency and potential degradation. The solution is to introduce a mechanism into the media carrying protocols that makes them able to cope with NAT instead of ignoring it. It will may mean the media protocol has to become aware of the signalling protocol, or at least some services offered by it, something which is undesirable from a design point of view with a clean separation of layers between protocols. However if it’s a means to fix the problem where all previous attempts have failed than violating a design principle is worth it. Apart from the time it has taken to write this paragraph I have not put any thought into what such a solution would even look like, perhaps some kind of broker service offered by the signalling layer where the media protocol could send a single rendezvous packet to the signalling server so that the public media socket is known and then can be used in the call request. Perhaps the signalling and media protocols can be multiplexed over a single socket although that would be a big change and I suspect there would be a portion of NATs that would fail to cope properly with a single private socket mapping to multiple public sockets. Fingers crossed the engineers at Goozimo will come up with not just a solution but a good solution and then use Google’s muscle power to prevail it on the industry and solve the abysmal vision of the SIP designers.

  1. doohickey’s avatar

    You’ve probably run into this already, but in case you haven’t you may find it interesting…or not. 🙂 The SIP provider SIP2SIP uses a P2P technique that they call SIP Thor.

    http://wiki.sip2sip.info/
    http://ag-projects.com/SIPThor.html

    Reply

    1. sipsorcery’s avatar

      I do recall looking at the site a while ago. There’s no doubt the AG Projects guys know their stuff and the SIP Thor project is intriguing however rather than P2PSIP it seems to be more of a P2P SIP Server layer. Maybe that’s what the P2PSIP groups are all about and I’ve missed the point. To me P2PSIP is about facilitating SIP between two peers where a peer is any old device on the internet. The challenge isn’t at the SIP layer – the SIP Thor project, hopefully SIP Sorcery in the near future and many others can provide a scalable and reliable SIP signalling service – but what’s needed is a way to robustly get the media off the SIP/Media Proxy servers and direct in a P2P fashion. AG Projects don’t look like they’ve solved that one.

      Reply

    2. ccutrer’s avatar

      … or just speed the transition to IPv6, and forget about NAT. I’m ready to go at my house. IPv6 capable router and network devices. Hooked up with DOCSIS 3.0, just need Comcast to flip the switch. (Well, technically I have an IPv6 tunnel to he.net, so I have IPv6 connectivity, but that isn’t as efficient as a native IPv6 connectivity).

      Reply

      1. sipsorcery’s avatar

        I agree IPv6 is the best solution of course that’s provided ISPs allow each device users connect to get it’s own IPv6 address and don’t take the easy and stupid option of continuing to rely on NATs. Unfortunately something tells me it will be the latter and only techies will bother getting themselves set up with IPv6 properly.

        Reply

      2. Wowed...’s avatar

        I’m much WOWed over you complete closed minded approach to reading standards, especially if you can’t understand something as simple as the RFCs for SIP. You speak of them being bloated with this and that… Is this the first time you have ever read a technical document about a protocol… Do you expect a protocol to be a simple send this receive that without any logic? If you don’t get or understand the SIP protocol why did you even write a SIP server? I’m assuming that your frustration with the SIP protocol is that it just completely overwhelms you.

        On to a different subject about NAT. You guys are complete idiots if you think NAT was created to fix the over usage of IPs for IPv4… That has NOTHING to do with why NAT was originated, that is merely a bonus to its functionality. NAT was created to easily separate public and private networks and to reduce the security footprint someone would need to secure for a network. There will still be NAT in a ipv6 world… And I can reliably tell you that every home router with ipv6 will still utilize NAT for the home user’s private network. There is NO need for a home user to need every computer in their house to be on the public internet network. If YOU need every computer at your house to have a public internet address then YOU need to get a normal router or simply turn NAT off in your current and run it with normal routing. But don’t be surprised if your internet provider still only gives you one IP per modem, they pay for those IPs… It costs money to request and register large blocks of IPs.

        Reply

        1. sipsorcery’s avatar

          Methinks your arguments are somewhat aggressive, somewhat flimsy and somewhat lacking in substance. I’ve been reading SIP RFC’s for 6 years, I’ve wholly or partially implemented over 10 of them (http://sipsorcery.codeplex.com/wikipage?title=Standards%20Support&referringTitle=Home) so at the very least I think that entitles me to a view on how well they are written. You’ll find plenty of references that disagree on your view as to the origin of NAT, for instance http://en.wikipedia.org/wiki/NAT, feel free to back your point up if you have any references. NAT’s aren’t needed to separate public and private networks, routers can do that. NATs are needed to share a single or small number of public IPs with a larger number of private hosts.

          IP’s issued from Internet Registries, RIPE, ARIN et al, do not cost anything, I’ve been the through the acquisition of a block of IPv4 PI space in the past so again you are wrong. Downstream ISP’s may charge but mostly that’s because IPv4’s are in such short supply that they can get away with it.

          You can’t reliably tell me every IPv6 home router will use NAT unless you are Nostradamus and can see the future. As soon as my ISP issues IPv6 I’ll be getting an IPv6 capable router without NAT.

          Reply

        2. Aviator168’s avatar

          Just saw this blog and implementing a sip ag stack. I have it working with * and trying to get it work with sip2sip. While debugging, I noticed sip2sip servers are sending some binary data in front of some of their requests. I real don’t know what they are. Anything I can get some info? Getting back to P2PSIP. Can the simple REFER method to used so an endpoint to endpoint can be established?

          Reply

          1. sipsorcery’s avatar

            I’ve never spotted any issues with sip2sip traffic, are you able to check with a wireshark packet trace? In my experience of developing a SIP stack oddities like that were normally caused by my own bugs.

            That’s a good question about the REFER request. I’m planning on sending a REFER request to my Cisco and Polycom IP phones to see if that will get them to initiate a call. At this point I don’t know either.

            Reply

            1. Aviator168’s avatar

              Yes. This was only brought to my attention when I monitored the traffic with Wireshark. My SIP AG lib work fine with sip2sip as that binary data is in front of the SIP packet. However, Wireshark cannot recognize them as the method does not start at the first byte of the UDP packet.

              I have two Cisco 7960s with an older SIP firmware. I remember I test the REFER method a few years ago but can’t remember if it work.

              Here is what I think about SIP. It’s direction had gotten too much inference from the traditional phone network. Hey, we are on the internet and some of the headers are totally unnecessary. As for billing. That only happens if you call a land line or mobile phone. Even that is big if as land lines and mobiles have started using VoIP. All we need is an application level ‘DNS’.

              Just my 2 c

              Reply

            2. sipsorcery’s avatar

              I’ve run a trace of a REGISTER to sip2sip.info and didn’t see any spurious data in the trace. Could you have a SIP ALG on your router that is messing things up?

              Reply

            3. Aviator168’s avatar

              The REGISTER is fine. The binary data shows up on requests comes from sip2sip.

              Reply

            4. Abrigado88’s avatar

              SIP Thor implemented NAT traversal by using ICE yet without a TURN server:

              The methodology is described here and is seems to be focused on results rather than blind implementation of the standards:

              http://mediaproxy-ng.org/wiki/ICE

              Reply

              1. sipsorcery’s avatar

                OpenSIPS use of a media proxy is a pragmatic approach but regardless of whether the media proxy is an official TURN server or not the fact is it’s proxying the media and that’s what I dislike.

                Reply

Reply

Your email address will not be published. Required fields are marked *