[VOIPSEC] 4G Issue Map: signaling complexity

[Brian Rosen]

Clearly a bunch of spewing, but I'll take a little of the bait.

> SIP is a reinvention of SS7, using a verbose text-based syntax rather
> than the "bit setting" approach of the ITU.  
This is the "binary" vs "text" discussion.  It ragged 6 or so years ago when
SIP and Megaco/H.248 were developed.  It's been repeated periodically
thereafter.

Here are the facts.

Megaco/H.248 provided a clear opportunity to directly compare ASN.1 encoded
syntax to text syntax with exactly the same semantics.  The protocol was
designed with both encodings.  Although it's a lower level protocol than
SIP, the results are almost certain to be worse (for binary) than for
Megaco.

So, we tested it.  We took a bunch of representative real world messages,
coded them in text and in binary and looked at the result.

The bottom line: text takes FEWER bits than ASN.1 BER.  We were surprised.
We had been saying it would be no more than 25% or so more bits.  ASN.1 is
TLV with binary encoding.

Then, you can compress SIP quite easily.  The wireless guys do that.  When
you do, it gets waay more efficient than any form of binary TLV ever used in
an ITU protocol I know of.

So, I'd suggest stop pushing TLV or Binary, unless you have some actual
facts.
.
> 
> What would work for me is a new group with telephony experience to
> create a signaling protocol for IP networks, comparable to FR vs. ATM.
The problem, as Henry has repeatedly pointed out, is that most of the
complexity of SIP is related to two things:
1. The insistence of the telcos that every feature has to work the same way
as it does in the PSTN regardless of the wireless experience which showed
that it didn't (the "SEND" button for example)

2. The effect of breaking the Internet end to end model

If we were to start over in the IETF, the golden rule would be: This
protocol is NOT INTENDED to replace the PSTN, and any suggestion that a
feature is needed because the PSTN has it, or does it some particular way,
is sufficient reason for outright rejection of the feature or method.

Another minor factoid:
I've seen some useability tests with phone-like features.  These are the
tests where you take a subject into a room wired to the hilt with cameras,
give him a gadget, and watch them use it.  They tried several well known
PSTN feature implementations and some newer ways to get the same effect, but
different user interface. In nearly every case, there was a better way.
Sorry, can't reveal details (and it wasn't my work).  Point of the test
showed that user training (PSTN way to do it) was trumped by better design
and/or a better feature.  That's not always true.  Very often the way you
know is the only way you want it.