Speaking of Standards

Over at Ars Technica, author Gilad Shaham has started a series of posts about the SIP protocol. So far the two installments are:

• Wired for sound: how SIP won the VoIP protocol wars
• VoIP in-depth: An introduction to the SIP protocol, Part 1

The first article gives some background about SIP and goes on to explain how SIP prevailed over H.323 as the dominant standard for VoIP traffic today. The second article goes through the details of basic SIP messaging and explains how SIP proxy servers and registrars fit into the picture, complete with some diagrams that nicely explain call flows. The author indicates that the next article in the series will dive into SIP calls in more detail.

If you are new to VoIP or to the SIP protocol, both of these articles are great tutorials that will help you learn more about what SIP is all about. If you are familiar with SIP, you still may find some interesting tidbits mixed into the text. The articles are good to see and I’m looking forward to reading the next installments!

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

Registration for the 77th meeting of the Internet Engineering Task Force (IETF) is now open. The IETF 77 event will take place March 21-26 in Anaheim, California (home of Disneyland).

Sadly, it looks like I personally will be missing this IETF meeting as I’ll be across the continent in the other home of Disney, Orlando, for VoiceCon Orlando 2010. I somehow don’t think the cross-country travel will work that week. The good news, though, is that the timezone will be such that I will be able to participate remotely. Remote participation wasn’t really an option for me with the recent IETF 76 in Japan.

One interesting point in the email announcement was that the IETF is offering essentially a “day pass” again for people who either want to just see what IETF is all about or who only care about sessions happening on a particular day. Per the email, for $200 you get:

1. Attend all sessions during any one day of the Meeting, and partake of the food and beverage during the breaks
2. You select which day to attend when you show up onsite to check-in
3. Payments may be made onsite without a late fee
4. Pass can be upgraded to a full Meeting Registration, however, late fee may apply if initial one-day payment not made before Early Bird deadline
5. Attend Sunday Tutorials at no additional charge
6. Attend Sunday Welcome Reception at no additional charge
7. Attend Wednesday and Thursday Plenaries at no additional charge

Seems like a nice option if all you just want to go to a day of sessions.

In any event, more information and the registration form can be found in links from the IETF 77 meeting page.

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

So what Twitter accounts are out there that write mostly about industry standards?

Thus far I’ve found:

@rfc
@w3c

I’ve added both to a new Twitter List to which you can subscribe, if you like, at:

http://twitter.com/voxeo/standards

If you know of other accounts, please let me know. (Thanks!) There is an @ietf account out there, but it’s only had one tweet back in November 2008.

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

Today the W3C’s Voice Browser Working Group released another draft of the VoiceXML3 specification. This one primarily adds a new section, 6.16, on Speaker Identification and Verification (SIV), part of what is often referred to as “voice biometrics”. If you haven’t been following the development of VoiceXML 3.0, the draft is worth a read, particularly the beginning where it talks about what the W3C is aiming to do with this new version of VoiceXML.

We’ll be writing more about VoiceXML 3 over the months ahead as the draft continues on it’s path toward becoming a specification. At a real high level, the goals the W3C has include:

• Flexibility – more powerful flow control
• Modularity and adaptability – ability to adapt to usage on everything from mobile devices to the IVR servers to network media servers
• Extensibility – ability to be extended as new technologies and communication means become available.

VXML3 will add SIV functionality, support for video and more. As you’ll note in the spec, it adds “profiles” to support different types of features and functions (to get to that “flexibility” goal).

Voxeo’s own Dan Burnett is co-editor-in-chief of the specification and has obviously been heavily involved over the past weeks and months in moving this work along. I’m hoping to get him on video soon giving more of an overview of what’s new in VXML3… stay tuned…

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

This week in New York City, Tim O’Reilly gave a keynote at the Web 2.0 event that I definitely put in my “must-see” category. Not because of anything visual… I mean, it’s just Tim standing on stage talking… but because of his message.

There is a war on out there on the Internet.

It’s a war between those who would like to keep the Internet as the open platform for innovation that it has been for decades… those who champion “The Internet Way” – and those who would like to return the Internet to the world of walled gardens from which it emerged. In his excellent piece published on Monday, “The War For The Web“, Tim speaks of the sides as “Small Pieces, Loosely Joined” and, of course, “One Ring To Rule Them All”. He concludes with:

It could be that everyone will figure out how to play nicely with each other, and we’ll see a continuation of the interoperable web model we’ve enjoyed for the past two decades. But I’m betting that things are going to get ugly. We’re heading into a war for control of the web. And in the end, it’s more than that, it’s a war against the web as an interoperable platform. Instead, we’re facing the prospect of Facebook as the platform, Apple as the platform, Google as the platform, Amazon as the platform, where big companies slug it out until one is king of the hill.

And it’s time for developers to take a stand. If you don’t want a repeat of the PC era, place your bets now on open systems. Don’t wait till it’s too late.

This IS the battle that will frame the Internet in the next years. As I wrote a few months ago in ‘Of DDoSs and SPOFs: How Twitter and Facebook violate “The Internet Way”‘, the way of the Internet is to use “distributed and decentralized” services. That’s how email works… that’s how the “web” works… that’s what excites me about the promise of Google Wave – not just that it’s a great platform for collaboration (and as I show here, it is), but that the Wave protocol has been designed from the start to be about federation… to be about distributed and decentralized services.

This war is a large part of why I work here at Voxeo, where one of our core values is “Unlocked Communications“, where we are huge believer in open standards (and chair/co-chair many of the standards committees), where we do things like open source our Tropo cloud telephony platform (“The Cloud Must Be Open!”) and where, in contrast to Nuance and TellMe as Tim mentions at 13:22, we give away our speech recognition engine for free as part of our Prophecy IVR/application platform… that’s why I’m here at Voxeo. It’s a war for openness that I believe we must win!

But listen to Tim… and then ask yourself – which side of the war are you on?

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

The IETF today made a fairly major announcement:

The IAOC is pleased to announce the ancient and historic city of Beijing as the site for IETF 79 from 7 – 12 November 2010. This will be the IETF’s first meeting in China. The meeting will be held at the Shangri-La Beijing Hotel.

As noted, this will be the first time the IETF has met in China – and this announcement has not been without its share of controversy. Earlier during the negotiations with the hotel, the IAOC (the administrative arm of the IETF) asked the IETF committee for feedback on the venue and the terms under discussion. This set off a firestorm of discussion, as there was a clause in the hotel contract that allowed the hotel to terminate the proceedings if illegal content was discussed. The debate on the main IETF mailing list was extremely… um.. “vigorous” with all sorts of commentary around what constituted appropriate content, around “freedom of speech”, around censorship… and all the related topics. If you know anything about the IETF (or have been to an IETF meeting), you can appreciate the passion that this particular topic elicited.

In the end, the IAC reported that this specific clause was removed from the hotel contract:

During the course of contract negotiations with the hotel the community was asked via email lists and by survey about a specific provision in the contract. Your feedback guided us in our efforts. We are happy to report that the provision has been removed from the contract.

…

In response to concerns that the discussion of some IETF topics may violate the law, the IAOC has been assured by the Host that a normal IETF meeting can be legally held in China and that no pre-screening of material or monitoring of session content is required or will be done.

With that, the IAOC unanimously approved Beijing as the host of IETF 79.

Given that we have a Voxeo office in Beijing (which started with our Micromethod/SIPmethod team but has since expanded to include more folks working on all Voxeo products), we’re delighted that an IETF event will be happening there and look forward to having some of our folks attend.

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

NOTE: David Bryan, co-chair of the IETF’s P2PSIP Working Group, left this text as a comment to my earlier post about P2PSIP and Skype. Given it’s length and great content, I thought it should run as a guest post and David was fine with that. The text below is entirely his.

So a few points, in no particular order:

Lee mentioned (as have others before) that P2PSIP is “copy-cat Skype”. This always bothers me, not because we came first (we certainly didn’t) but because it wasn’t my vision for P2PSIP (although others certainly had that view) . When I came up with P2PSIP and brought it to the IETF, I wanted to do things SIP couldn’t do at all. SIP can theoretically build a system that looks like Skype. To me, the interesting areas for P2PSIP were distributed softswitches/corporate IM (config-free small office, etc.), rapid response (quickly set up a communications system after a natural disaster), ad-hoc clusters for IM/app sharing (think Google wave away from the Internet), and vendors adding voice to apps without becoming an ISP. You could do a Skype-like service with P2PSIP (sort of: see below) but that wasn’t really the idea that got me started creating P2PSIP.

To me, Skype’s success was solving the NAT issue and getting the user experience right. P2P was a means to an end/efficiency multiplier, but not the reason for the success. Skype just worked. SIP’s major flaw is embedded IP addresses. Skype avoids this, uses media relays (P2P, but could have been centralized) and “falls back” (in the worst case) to tunneling over port 80. Users love this. Administrators and protocol purists hate it as it breaks traffic characterization, shaping, etc. Skype’s closed garden (one protocol stack) also ensured things just worked. Closed gardens and HTTP tunnels are at odds with the SIP goal of vendor/carrier interoperability. The two achieve different goals. (Today, many folks believe ICE with ISP-provided relays has addressed the SIP NAT problem. It looks promising, but until we have a Skype-sized Internet deployment, some say the jury is out. Time will tell.)

You could theoretically deliver a Skype-like experience with either a SIP or P2PSIP solution. Pure P2PSIP is very decentralized (every node is a peer and central servers are only used for obtaining a certificate), so you would need a hybrid approach if you want to maintain customer control. You could also use regular SIP with ICE, and many, many servers if you could solve the scalability problems. The best approach might be conventional SIP between the endpoints and a cloud of servers, with the servers sharing information using P2P. This ends up looking much like a SIP version of Skype’s super-peer model, executed in the cloud.

All this still begs the question of what happens to the Skype ecosystem of hardware, etc. If you go SIP, what do you break in the process? As Dan York and Shidan Gouran point out, Skype has many options, lots of great engineers, and lots of cash, but nobody outside of Skype knows what they will do.

As an aside to Lee’s comment on P2PSIP as a standard (it is fair to say adoption in product has been very slow, I’m sorry to say): The standard is moving, just at the (glacial) pace of standards, which can be frustrating for idea guys like Lee or I. In the early days, P2PSIP had lots of ideas, chatter, and excited non-standards folks, so work moved quickly. Today, with an accepted draft in progress and a more mainstream standards audience, iterations have slowed. That said, things are moving, there is strong interest, and a lot of hard work by the editors and participants.

My biggest worry is the protocol becoming too cumbersome. We are building a very flexible, universal DHT protocol with mandatory ICE and TLS/DTLS security. This is great for some scenarios, but overkill for others (ad-hoc, for example), and I worry the bulk may make it unsuitable for some of the scenarios I first imagined. I think many of these may migrate to the cloud. DHTs will be used, but as a means to distribute data among servers, not all the way to the edge as I first anticipated. Things change. Progress is good. I’m very excited to see how DHT principals in the cloud might solve many of the problems posed of a pure P2P approach. (eComm talk for SF, Lee?)

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

Could Skype realistically replace its proprietary peer-to-peer (P2P) algorithm with P2PSIP?

Over on his Skype Journal site, Phil Wolff shows another example of why I’ve always followed the mantra “Never put online, in any form, anything you don’t want to appear on the front page of a news site” when Phil shows what was obviously intended to be a private email about ideas of what to do with Skype. (This has all surfaced as part of Skype’s ongoing legal battles on a number of different fronts, which I’m not going to dive into here.)

Per Phil’s article, the idea was this:

- buy skype, replace p2p with SIP (standard-based, open, can interwork with other VoIP systems – like the Cisco phones)

What’s perhaps most interesting about Phil’s post, though, were the comments that started with Lee Dryburgh of eComm fame weighing in saying that it makes ZERO sense (technically) and then went on from there. Lee and Shidan Gouran then got into a bit of a discussion in the comments.

Leaving the personal jabs aside, it’s actually an interesting discussion to consider. (And knowing both Lee and Shidan, I’m sure that they actually agree on way more than they disagree on.)

WHAT IS P2PSIP?

Lee’s right that there’s a difference between “SIP” as a protocol and all the overlays, DHTs and everything else that goes with “P2P” protocols. To Lee’s points about the difference, though, that is precisely what the “P2PSIP” work happening within the P2PSIP Working Group of the IETF is addressing. For those who want to read the proposed P2PSIP protocol itself, the latest draft is here in two parts:

http://tools.ietf.org/html/draft-ietf-p2psip-base
http://tools.ietf.org/html/draft-ietf-p2psip-sip

The first draft defines a P2P protocol called “REsource LOcation And Discovery (RELOAD)”. The second draft explains how RELOAD can be used with SIP.

To Lee’s points, RELOAD is a separate protocol from “SIP”. Now, RELOAD does indeed use a Chord-based DHT… though, the best place to start is probably the Architecture section at the beginning to understand how the pieces fit together.

So what is being called “P2PSIP” within the IETF is more this:

P2PSIP = SIP + P2P-protocol

More info about all things related to P2PSIP can be found at a great site maintained by David Bryan, co-chair of the IETF P2PSIP Working Group:

http://www.p2psip.org/

I’ve also written more about “P2PSIP” here on this blog, including this piece back in May 2008 about why I believe P2PSIP is important.

BUT COULD SKYPE REALLY USE P2PSIP?

Probably.

The question is really –

Could Skype swap out it’s proprietary P2P protocol for the P2P protocol proposed as part of P2PSIP?

That’s the larger issue. As Lee points out, SIP is “just” a signaling protocol for setting up communication sessions. The decentralized P2P nature of Skype is due to its proprietary P2P algorithm, not its session signaling.

That’s the key point, really – there are two different layers of communication going on here:

1. networking between the endpoints (the P2P layer)
2. call and chat signaling setup, modification, tear-down, etc.

The P2P layer is probably the hardest one to replace. The signaling layer is probably easier as there are any number of choices out there today, including SIP, XMPP and others.

Plus, as Shidan Gouran accurately points out, Skype’s current system is NOT entirely decentralized/P2P. It is much more of a hybrid system. There are centralized enrollment/authentication servers (as we learned in the multi-day outage a few years back), a centralized directory (although pieces of that could potentially be spread across the P2P overlay) and of course centralized PSTN interconnectivity.

Could all that be replaced with a different P2P protocol? Probably… although certainly not without a lot of work – and also the severe headaches of dealing with backward compatibility and getting the huge installed base of Skype users to upgrade to a new client.

Could that protocol be P2PSIP? Again, probably. The advantage would be that the SIP layer would give Skype interoperability with other systems, networks, devices, etc.

THE OTHER OPTION

I’d note, too, that the email Phil quotes says “replace p2p with SIP”. It does not say “replace p2p with p2psip”. There very well could be folks thinking of dumping the whole proprietary P2P protocol and dumping P2P in general and migrating to be a “standard” kind of SIP system like Gizmo (yes, which Skype has been rumored to be buying) or any of the other SIP-based consumer softphone services out there.

Sure, I’m sure they could technically do it. As an open standards guy, it would be great on one level in that it would help move us along toward the great big “interconnect” many of us so want to see. It would, though, require a much different architecture than what Skype has used so successfully today.

SO….

Will Skype replace their proprietary protocol with P2PSIP?

Ha… I haven’t a clue… nor does anyone else outside those walls. All we can do is have moments of technical amusement like this speculating on the possibility.

As I’ve noted before, Skype has been hiring in this year some great folks with lots of SIP experience… but… Skype is also a HUGE user of SIP on its backend for PSTN interconnectivity… plus they rolled out their Skype for SIP program this year…. so they have lots going on related to SIP.

We’ll see… all we can really say is that the time ahead will continue to be an interesting one for all things related to Skype…

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

For those watching IETF standards, the draft agenda is now out for the upcoming 76th meeting of the Internet Engineering Task Force from November 8th through 13th in Hiroshima, Japan. As usual, it will be a jam-packed week of activity. The IETF 76 host committee has a great web site up filled with info about the event (including the fact that if you need a visa, you had better start now!).

Sadly, due to some other events on my schedule, I don’t expect to be out there at IETF76. And, given the 13-hour difference from US Eastern time, I somehow don’t see me participating remotely. Ah, well, I’ll just have to catch up face-to-face with IETF 77 in March in Anaheim, California…

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

On Monday over on the Emerging Tech Talk video podcast, I posted a brief interview with SIPit coordinator Robert Sparks that I recorded at the SIPit 25 event held in September 2009 at the University of New Hampshire InterOperability Lab (IOL) in Durham, NH, USA.

In the interview, we covered questions such as: What is the SIPit test event all about? How does it make communications systems better? What do participants do at the event? How can companies get involved?

More information about SIPit can be found at http://www.sipit.net/
Robert Sparks has also posted a summary of the SIPit25 event at:
http://www.ietf.org/mail-archive/web/rai/current/msg00720.html

From a Voxeo perspective, I know that our test team gained some valuable insight into interoperabilty with products from other vendors. We’ll be incorporating what we learned into future versions of our product. Getting this type of real-time feedback is why the SIPit events are so powerful. We definitely hope that other vendors will join in to future SIPit sessions.

Meanwhile, here is Robert Sparks…

Technorati Tags: sip, sipit, ietf

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.