[VOIPSEC] 4G Issue Map: signaling complexity - more

[Paul E. Jones]

Geoff, et al,

Folks like to compare SIP to HTTP, for obvious historical (i.e., derivative)
reasons.  Do you recall how well the web browsers worked in the mid-90s?  I
think I had to upgrade about every 3 months.  Many web sites checked for the
browser version and provided different HTML or, in many cases, just told
users that the site only works with IE or Netscape.

Finally, Microsoft killed Netscape (and no, I'm not taking sides) and
brought about some stability through adoption of a single browser platform.
This has been tremendously helpful, really.

We're starting to see "problems" again as Firefox takes off.  The two
browsers implement some things differently and that has caused some
problems.  I had to "fix" a few things on my web sites (which were not
really broken, but just not supported by Firefox... and something were
broken, so I can thank Firefox for pointing those out).  Last week, I
visited a web site that just told me that I could not see any of the content
unless I use firefox.

So, back to the mid-90s we go.  (It is better, though: at least we only have
two major browsers to deal with.  Among most VoIP enthusiasts visiting
Packetizer, MS IE has 68.8% of the market share, Firefox with 20.3%, Opera
has a distant 1.8%, and it falls off from there.  Just in case folks wanted
to know.)

In short, your point is quite valid.  Unless you build a really, really
simple protocol that is virtually brain-dead and just can't be botched, you
will face these problems.  Putting a lot of intelligence into the endpoints
will mean that there will be very few endpoints that have a remote chance of
getting deployed in a commercial market and support many advanced features.
There is a reason why VoIP service providers today either severely limit the
endpoints they support or severely limit the features you get (or both).  By
and large, service today is simply cheap phone calls over IP... no real
thrill.  (No complaints, though: I appreciate the cost savings.)

If you put a lot of the intelligence into the endpoint for such things as
call transfer, call forwarding, etc., that's OK.  But, how do we define "in
the endpoint"?  SIP puts those services "in the endpoint", but what it
actually requires is support by the calling endpoint to have a bunch of
protocol necessary to make those features work.  So, where is the feature?
It's spread around a few endpoints that have to work in harmony.  If "in the
endpoint" meant that the endpoint actually handled everything, that would
have made interop a heck of a lot easier.  I would speak of billing issues
with REFER, but I might get Brian wound up ;-)

Paul

> -----Original Message-----
> From: Geoff Devine [mailto:gdevine at cedarpointcom.com]
> Sent: Thursday, August 24, 2006 7:25 PM
> To: Henry Sinnreich; Paul E. Jones; Brian Rosen; bill at flanagan-
> consulting.com
> Cc: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] 4G Issue Map: signaling complexity - more
> 
> Henry Sinnreich writes:
> > Such complexity is better placed in the endpoints, the only
> > ones that understand the application and that can be
> > developed in a controlled environment.
> 
> Right.  ...and what that means is any time you need to add a feature, you
> need to extend the protocol. When you extend the protocol, you need to
> ensure interoperability with potentially dozens of different client
> implementations and potentially dozens of different software revisions of
> each implementation.  Go look at what TISPAN or the PacketCable
> Residential SIP Telephony Spec (after the IPR review period expires next
> month) have done.  Unless you vendor lock on one client implementation, it
> will be wildly difficult to ever make the network stable.  The cell phone
> service providers can limit the damage by controlling the number of
> implementations and testing the heck out of everything.  They´ve also
> adopted a model where as many features as possible are done by the core
> network.  I don´t see that the fully distributed call processing model is
> workable in the general case.
> 
> Geoff
> 
>