« Telecom in China — After the dust settles | Main | Education due for radical disruption »

May 30, 2008

Comments

Aswath Rao

In the SIP Center article you state: "...with IMS there are no direct peer-to-peer connections. Instead everything is mediated by a service provider." SIP was coopted not by IMS; I contend that the originators of SIP contrary to their stated claim focused only on a service provider model. If you do not believe me, just look at the call model. As far back as 1999, I have done P2P calls using NetMeeting. So H.323 is not fatally flawed. SIP and H.323 have the same problems - directory service and NAT traversal. At the same time P2PSIP is a false promise. In my opinion it is better to focus on developing micro directories and micro ICE servers.

Brough Turner

Aswath, I agree that H.323 was peer-to-peer long before SIP existed, but it also suffers from NAT. I also recall that H.323 was adopted by the ETSA TISPAN group, at least initially, although I didn't follow that effort closely. I assume they did to H.323 roughly the same as happened to SIP.

You may well be correct that SIP was cooped from its start. My limited exposure was a half-day meeting with Henning Schulzrinne sometime in the 90s (after 1996 and before SIP's adoption in 1999). My impression from that meeting was that Henning was concerned that SIP be able to support various existing telephony services, but he was still committed to SIP being a peer-to-peer protocol where directories were a convenience, but a central service provider was not required. Obviously between 1996 and 1999 there were many people involved in ietf meetings, including many from the PSTN camp. I only attended 1 (or 2?) SIP meetings during that interval, so I'm not a good source on what really went on.

I'm curious about micro ICE servers? Run by whom? As I understand ICE, it still requires STUN and TURN servers in the cloud and may require relay servers (also in the cloud) if both parties are behind particularly egregious NATs. As a side issue, the P2PSIP group appears to be addressing this but I'm afraid my information here is also second hand as I'm not active in P2PSIP either. :(

I dont think the problem has anything to do with NAT or STUN or ICE or anything technical. Other than Skype, all commercial VOIP is built on SIP today, so these vendors are already dealing with the NAT/firewall issues. I think, on this point, Aswath and I agree. However, I dont believe there was a conspiracy at the IETF level (if thats what is being said). But in the end, the IETF, nor any standards body, decides what happens in the real world - those who spend money to push their products into the market define the landscape, in practice.

In this case, they decided to keep SIP behind the scenes. While it is used to enable the service, it is hidden from the customers, and therefore SIP to SIP has made no ground.

We saw community leaders and even open-source leaders embracing these closed solutions like Skype and Vonage when they came out. I dont know why there was no backlask from the community and almost no grassroots effort to push open interoperable SIP or to force providers like Vonage, that already used SIP, to expose it to end-users. But frankly, those community leaders should be ashamed and the VOIP userland is the worse for it.

Dan Wing

RSIP (RFC3103) is an experimental specification and not part of the ICE/STUN/TURN NAT traversal story.

It is true that STUN requires a server be available on the Internet. But the same is true of DNS, SMTP, HTTP, and SIP itself. Because a STUN server maintains no state whatsoever it is easier to run than a server running one of those other more commonly-known protocols. Some SIP servers run a STUN server on the same hardware or on the same port as SIP; see draft-ietf-sip-outbound.

Brough Turner

Dan, thanks. You are absolutely correct that RSIP is completely independent of ICE. I last looked at RSIP many years ago (2001 or 2002?), so I'm not sure what I was thinking of when I wrote that. The other perhaps remotely relevant item (again, not required for ICE) is the COMedia drafts which eventually generated RFC 4145. I haven't followed this in detail, but I have seen Comedia (draft 04) implementations included in commercial gateways.

Whether STUN servers become widely available because of P2PSIP or a SIP hardware vendor sponsors open STUN servers or something else happens, I'd love to see STUN servers as widely available as those for DNS or SMTP. As long as the STUN servers as associated with specific SIP telephony service providers (the most common case today), SIP looks like a telephony service not a web service. Oh well, I can hope...

anon

i really do not see skype's success related to presence, IM or any of the other things mentioned. they have simply had absolute rock bottom pricing when compared to the other competitors anywhere close to there scale.

the vast bulk of user want as close a duplication as they can get to there POTS line; at the cheapest possible price. SIP based services like vonage and packet8 may be closer duplicates; but skype has lower pricing. therefore the draw of customers.


David A. Bryan

Glad to see the interest in P2PSIP (I wrote the first IETF draft and academic paper proposing the idea, chair the P2PSIP working group over at IETF, and run the community site P2PSIP.org, so I have to admit I am biased toward P2PSIP up front -- thanks, and I love seeing coverage of the work!)

A few quick comments to share:

* Answath mentions "micro-ice" clients, and thinks that P2P won't solve the problem, but I think that the perfect location for these kind of devices is in the peer -- the peers help form a network of devices that can assist with NAT traversal. ICE is quite good reducing the need for relays, but in a P2P environment, some peers will be able to serve that role when needed. This is of course a statistical solution -- you can't have an cluster where ALL the peers are behind "bad" NATs.

* The P2PSIP WG is planning to use the ICE methodology. The idea is to embed ICE capabilities in some devices, however a provider could also provision stand-alone servers as well. One key thing to remember is that P2PSIP isn't just about having every peer in a big global cluster (although that is one application many of us have interest in). We also envision using P2PSIP in small clusters, such as an enterprise, among a group of friends or family, or even in the developing world in an isolated network. There will be many (interconnected, hopefully!) small clusters. Therefore, a carrier using this as infrastructure might provide the servers. A global, open "SIP-to-SIP" network would likely use the peers themselves. You can see some of the (many) ideas for how to use this that have proposed in the WG documented here: (very skeletally! This is document is more of a list of brainstorming ideas from the group collected by the editors than it is a real draft.)

http://www.p2psip.org/drafts/draft-bryan-p2psip-app-scenarios-00.txt

* There are actually a number of implementations out there today. Technically speaking, all are pre-standard, since we don't have an RFC yet. Some are open source, some commercial (in full disclosure one of the commercial companies listed is my company). We keep a list of all of them at P2PSIP.org, and there are more everyday:

http://www.p2psip.org/implementations.php


Brough Turner

David, Thanks for those pointers. I am personally very interested in several aspects of P2P infrastructure and P2PSIP, and especially in efforts that would facilitate ISPs making connectivity information available so P2P systems can optimize latency and minimize their impact on cooperating ISPs. From a quite look at the P2PSIP mail archives, it looks like there is a ton of interesting work going on. On the other hand, I don't currently have the time to participate or even to follow the mail list. Hopefully that will change but, for now, thank you and keep up the good work!

Brough Turner

Anon, I'm sorry I wasn't thinking about the low cost of using SkypeOut and SkypeIn. I started using Skype before SkypeOut or SkypeIn existed. At that time the #1 reason people were adopting Skype was that it "just worked." Subsequently, a lot of people found value in using Skype as an IM system and in using Skype's IM to coordinate voice cconnections (Skype-to-Skype).

I still make more Skype-to-Skype connections than I do SkypeIn or SkypeOut, but that's just me -- one isolated case. It would be nice to see survey data on a cross section of Skype users -- what they use the service for and why. But, unfortunately, I can't recall seeing anything like that.

The comments to this entry are closed.

My Photo

Search this Blog

Subscribe by Email

March 2014

Sun Mon Tue Wed Thu Fri Sat
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

Technorati


Site Meter

Upcoming Travel & Conferences


Twitter Feed

Become a Fan