« 'Help! I Need Somebody!'...But do we really need Somebody to Micromanage Emergency Response Solutions for IP-Based Communications? | Main | Images of the Day - from Scottsdale, AZ »
April 28, 2005
Guest Blogger: Timothy D. Jasionowski - re: is SIP dead?
So, I'm reading the Pulver Report yesterday and pondering Jeff's newest
mystery of faith--is SIP dead? Of course, as someone who has spent
five years trying to make SIP-based solutions commercially deployable,
I should have immediately said "Bah!"
But I didn't. And that concerned me, since I'm not currently employed
by Skype.
So, I spent a little time trying to figure out why Skype has so many
end user agents (i.e. not intermediary equipment or bypass) and think
I've finally narrowed things down to the truly significant difference
between SIP and Skype. It's not signaling, CODEC licensing, NAT
transversal, session border controllers or anything we argue over
drinks at VON.
It's that, with Skype, when something doesn't work, they have an
arbitrator--namely the people who run Skype, who determine the
absolute. In my experience, particularly in a previous life building
an IP telephony interoperability product, there's far too many opinions
and, more importantly, too many decisions made at the margin (in both
directions) on what the RFC writers intended or, more importantly,
neglected to resolve. Skype doesn't have to worry about in-band or
out-of-band DTMF; both are technically acceptable in SIP (in the case
of out-of-band, there are even two approaches on how to do that).
Skype doesn't have to worry about whether RTP is suspended or left
intact on hold or transfer; again, both acceptable within SIP.
However, if two SIP developers decide to support a subset of these two
approaches, things don't interoperate. Obviously, bad.
Whenever we get to a point where an issue arises, everything goes to
the IETF and the SIP working groups, becomes a working group decision,
people discuss, propose and, usually compromise (which isn't always the
right way to approach the problem--i.e. ATM and 53 byte cells). Skype
doesn't have to do that. They just make the decision quickly and go.
There's something to be said to fixing a problem over lunch, even if
the solution isn't always the most elegant one.
Let me take an extreme approach to this problem (Who? ME?), just to
make a point. You want to fix SIP and counter the Skype threat? Sell
all the underlying intellectual property rights of SIP to me. I'll
license it to anyone who asks for US$1. Then I'd create two basic
rules: first, I don't have any say at all in how problems are solved;
second, SIP is now a product, rather than an academic or development
exercise. Everyone who works on it today, continues to work on it--I'd
even share the dollar licensing fee, though it would more likely end up
being spent on Ahi Tuna Tartare and 150th Anniversary Grand Marnier at
VON Happy Hours--but we agree on a strict development roadmap.
I'd create panels that arbitrate technical disputes quickly and, more
importantly, firmly. I'd take the SIP name and strictly trademark
it--if they haven't agreed to follow the decisions of my panel, they
can't claim to be SIP compliant and we'll sue them if they claim
otherwise (unfortunately, this will also end my practice of claiming
that my car is SIP compliant, as currently, no one can stop me). And,
I'd create the Jasionowski Test--if someone who claims to be SIP
complaint answers a customer care call about SIP interoperability with
third-party equipment and states that they don't support
interoperability outside of their equipment family, they aren't
compliant and they forfeit the license--unfortunately, in that camp
would be most of the people shipping premise-based PBX systems today.
If you don't believe me, call a few of them.
Sounds crazy, doesn't it? Sure... but you know in your heart that's
exactly what Skype is going to do. Want access to our users for your
premium, revenue-generating voice application? Here are my rules. If
you break them, you fix your application or I cut you off. If you have
a question about how to do something, call us and we'll give you an
unqualified answer. If we don't support something you need, we'll
either say no--quickly--or add it to the roadmap, with an estimated
time before it's available. Sounds like an incentive to develop to me.
Why is this? Skype is a product. A commercial proposition. SIP is
not.
I'm still firmly behind SIP, but I'm tired of hearing about and seeing
SIP "compliant" solutions. Compliance isn't good enough--If it was,
would we have had Enron? ;) What we need is consistency, expediency
and, occasionally, to hear the word "no." That's what beats Skype.
Please note--I'm not knocking the IETF. I believe in my heart in its
mission and its progressive standards, and as a former student of
institutional analysis, I also believe in the positive aspects of
policy lag. However, I also believe in creating approaches to
technology problems that are commercially viable, which is particularly
important for SIP to accomplish, since it's attempting to replace a
protocol suite that *is* reliable and commercially viable--the existing
PSTN's tapestry of SS7/C7, et. al.--and, as a standard, SIP is still
not, unfortunately, there yet.
And because of that, Skype is starting to sound pretty good--like a
tightly wrapped blanket and warm milk.
Timothy Jasionowski
sip(at)postpartisan.com
Share this post:
Digg |
del.icio.us |
Reddit |
Newsvine |
Google Bookmark |
Yahoo MyWeb |
StumbleUpon
Posted by jeff on April 28, 2005 11:42 AM | Permalink
Additional resources: Watch PrimeTime TV Shows | Watch the Jeff Pulver Show | Jeff's Qik Videos
Comments
OK. I have to say that's this is the best analysis of the problems of VoIP and the only progress in VoIP since we figured out that jitter was a problem with H.323 in the mid-1990s.
A similar story could be told of the begingings of IM, email, et. al.
-Victor
Posted by: Victor Blake at July 26, 2005 11:05 PM