Speaking of Standards

Want to learn about the Session Initiation Protocol (SIP)? Would you like to understand how the SIP protocol works and why it is the dominant open standard for communication today? Want to understand the challenges SIP faces and what’s being done to overcome them?

If so… and if you will be attending VoiceCon in Orlando, FL, March 22-25, you’ll be able to join my (Dan York) 3-hour tutorial on “SIP Fundamentals and Prospects” on Tuesday, March 23rd, from 2-5pm. The abstract VoiceCon has posted is this:

SIP (Session Initiation Protocol) has become the dominant protocol for IP communications. This workshop explains SIP — how it works, the major issues impacting deployments and how SIP will evolve in the future.

The session focuses on the technical aspects of SIP and how it is used. It analyzes in detail the major components of SIP architecture, SIP addressing and registration, session establishment, SIP message routing and connecting SIP across the PSTN. You will learn about SIP extensions and how SIMPLE works for IM/presence. The workshop also examines some of the challenges SIP faces, including NAT traversal (and the tools developed to cope with it: STUN, TURN and ICE) and security. The tutorial concludes with an assessment of how SIP may evolve and its role in peer-to-peer environments. You will receive an inventory of SIP resources—books, papers and organizations.

I’m very much looking forward to the session… although I still do have some work to finish up on the materials. For the past while my friend David Bryan has given these tutorials at VoiceCon events, but given that he also chairs IETF working groups he would need to clone himself since this VoiceCon is the same week as IETF 77 in Anaheim, California. It’s a wee bit hard to flip between coasts… and as anyone who has ever been to an IETF event knows, the meetings are intense and he is needed out there.

If you can’t attend VoiceCon this year, I’ll probably do some SIP tutorial webinars in the future and perhaps you’ll see something popping up over at Voxeo University… stay tuned. And if you are at VoiceCon, please do stop by and say hello… or send me an email in advance letting me know.

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

FYI, a new version -08 of my P-Charge-Info Internet-Draft is now available:

http://www.ietf.org/id/draft-york-sipping-p-charge-info-08.txt

For an understanding of what P-Charge-Info is all about, read why I first wrote it, P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP, and then my update last year on the -07 draft.

Version -08 really only has a minor tweak to the ABNF notation for the “npi-value” and then a new Appendix A clarifying the npi-values and their relation to ANSI T1.113.

I am hoping that I can very shortly request IESG consideration to move this document along the path to being an RFC. The only remaining issue is that my co-author, Tolga Asveren, has brought forward a proposal for simplifying the parameters a bit. I’ve forwarded that proposal to several people I know are very interested in this draft. We’ll see where it goes from there. I’d very much like to move this along soon, so we’ll see.

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

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.

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.

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.

SIPit 25 starts four weeks from today at the University of New Hampshire’s InterOperability Lab (IOL). What is SIPit? As the UNH-IOL page for the event says:

SIPit’s, or Session Initiation Protocol Interoperability Tests, are weeklong events where people bring their SIP implementations to ensure they work together. SIPIT Events are open to anyone with a working SIP implementation. The goal of the events is to refine both the protocol and its implementations. The SIPIT events are a driving force shaping SIP into a globally interoperable protocol for real time Internet communication services.

Basically, they are a place where vendors can privately test their SIP implementations against each other. Results of the testing are not publicly released – other than an aggregate news release talking about what occurred overall. It’s a place where, as a vendor, you get a great chance to see how well your SIP-based product interoperates with that of other vendors. It’s also a place where vendors will often bring early implementations of new SIP standards to test those against other vendors working on early implementations. All in all, it definitely helps with moving us all along the path toward increasing SIP interconnection.

We’ll have a Voxeo team at this SIPit. We’ve been based on SIP since we started our company back in 1999 and we’re continually looking at ways to increase our performance and support for evolving SIP standards. We value the feedback we gain from these SIPit events and try to attend when we can.

You can attend, too, as there is still space available. The UNH IOL event page has more info and there is an online registration form as well. (Deadline to register, though, is September 4th.)

P.S. And yes, since yours truly lives about two hours west of UNH, I *am* planning to head over and meet our testing team for dinner probably in beautiful Portsmouth, NH… I’m in “marketing” now, so they don’t let me near the test equipment. I mean, in my world, all the tests just work, right? And they have really pretty charts to go with them…

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 morning I submitted a new version -07 of P-Charge-Info. Not much changed in the draft. Primarily I updated the IPR language to use the language of the IETF Trust as of February 2009 and added a reference pointing to RFC 3968.

The P-Charge-Info draft has been rather delayed on its path to becoming an Informational RFC primarily because just as I was about to request “expert review” per the process in section 4.1 of RFC 3427, the SIP and SIPPING working groups decided to revisit RFC 3427 and restructure how changes are made to SIP in general.

The result has been “RFC 3427bis”, a.k.a. draft-peterson-rai-rfc3427bis and section 4 defines a new lighterweight process for registering SIP headers. (Well, it speaks of a “Designated Expert” process, but my criticism of the existing draft is that it doesn’t easily explain what someone has to do to register a new SIP header.) While this RFC3427bis draft has not been ratified as an RFC, the RAI area is proceeding as if it has been and has already replaced the SIP and SIPPING working groups with SIPCORE and DISPATCH.

At this point I’m done with P-Charge-Info in that I’ve incorporated all comments that people have had and all I am looking to do now is move it through the end of the process to an Informational RFC. I will be contacting the RAI Area Directors shortly to sort out exactly what the next step is to get this moving along. In my ideal world, I’d like to see this published by the end of this calendar year.

I do, though, still welcome comments, so if you have any please feel free to pass them along.

P.S. For info about why I originally wrote this draft, see “P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP

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

Otmar Lendl recently posted a thoughtful piece called “What’s wrong with Speermint and Drinks” that digs into the differences between and the challenges of the IETF’s Speermint and Drinks Working Groups. Otmar started out explaining why they are necessary:

First of all, why do we need these WGs at all? The quick answer is that VoIP interconnection based on plain SIP and ENUM did not work out as envisioned by the authors of the respective RFCs. There are a number of reasons for that (see draft-lendl-speermint-background), and I don’t expect that the IETF can do anything to change this.

He then points out the fundamental problem facing these groups and really the “SIP/VoIP space” in general:

Call routing was rather simple in the full mesh world (be it PSTN or RFC3263 SIP), it only needed some directory service to map Public Identities (PI = phone numbers or SIP URIs) to operators. In a lot of cases, these directories are static simple mappings like “route anything starting with +49 to Deutsche Telekom”.

This is no longer sufficient. Any solution to the current world-wide call routing problem needs to cope with arbitrary interconnection graphs, not just the trivial case of full meshes. A directory will not suffice any more: we need a full blown routing algorithm.

I repeat: The current graph of interconnection between carriers has no special properties any more. We have a text-book routing problem to solve.

That is the challenge. The old world of the PSTN was relatively simple. Fewer players in the interconnection game… and because there were so few they could do “full mesh” interconnectivity between the various players.

It’s a different world, today. There are many players in the call routing game and pretty much anyone can enter that game. Otmar’s point is that the current proposed solutions focus more on central registries and other mechanisms traditionally used in the world of the PSTN. He argues that we really need more of a “routing” solution that allows multiple registries and systems – and indeed works like other Internet routing protocols.

For those interested in the underlying SIP plumbing that is being built to better interconnect all of us using SIP out there, Otmar’s post is well worth a read (fair warning that it does dive into details and terminology).

I don’t know that there are any easy answers out there (or it would have been solved already)… but the conversation is ongoing and will continue for quite some time.

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

Long-time readers will know that I have a fascination with the ideas behind P2PSIP, which I explained once before in a post “P2PSIP and pushing voice down into local clouds”. While it has very little directly to do with my work here at Voxeo, I’ve continued to help a team of folks with the IETF who are working on an Internet-Draft providing an overview of the security concerns related to P2PSIP.

Given the upcoming IETF 75 meeting, I published an updated version of the Internet-Draft last week. It is available at:

http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements

Those of you interested in SIP, P2P networks or security in general may find it of interest. Here’s the abstract:

This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.

My particular contribution in this revision was writing a new section on “Interconnection to other networks“. Many, if not most, P2PSIP networks will want to interconnect with the legacy PSTN or with other SIP networks. This section takes a look at what the security ramifications are and what an implementor of a P2PSIP network should consider.

Comments and feedback about this draft are of course welcome. At IETF75 in Stockholm I know that members of the author team will be asking the P2PSIP Working Group to accept this as a “working group document” (another step on the path to becoming a RFC) and there will undoubtedly be further revisions of the document.

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

Technorati Tags: sip, p2p, p2psip, security, ietf, standards

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