[VOIPSEC] 4G Issue Map: signaling complexity

[Paul E. Jones]

Brian,

> 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.

Putting aside that I've seen reports that contradict this, let me say...

H.248 is really a poor example for comparison purposes.  The MEGACO protocol
was defined with text as the primary focus.  The ASN.1 was more or less an
afterthought and it's not the best example of ASN.1.  It looks like the
ASN.1 was written to try to align with the text: not the way I would define
an ASN.1 protocol.  It could have been defined much more efficiently.

If one needs to compress SIP, that would then immediately kill any
performance advantage if it did exist.

I'm a proponent for binary, whether ASN.1 BER or PER, or other.  Machines
don't speak text: they understand binary.  Hence, it is certainly possible
to create more efficient protocols designed for machines.  The only place
where text makes a lot of sense to me is where text is the primary component
of the message exchange.  So, I view it reasonable that SMTP is text, since
most of the protocol would necessarily be comprised of text.

But, place a video call, perhaps send a picture of yourself as you call,
etc., binary makes a lot more sense.  The only thing that ought to be text
in such session establishments is the user's address.

> > 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)

This is true, though users do expect that things do work, by and large, as
they do today.  Most importantly, users must not lose functionality without
having suitable alternatives.

Fax machines serve as a good example here.  Businesses would not be able to
function as well without fax, but IP fax machines (i.e., not tied into the
"phone system") could replace the legacy machines quite easily.

If users started adopting such newer technologies, it would smooth the way
to using VoIP systems on a wider scale, I think.  Much of what is possible
is encumbered by trying to bring forward a lot of old baggage that could be
done in other ways.

> 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.

:-)  Yes and no.  When the user attempts to call a remote party and a
recording says "the number you've dialed has been disconnected" is played,
that needs to be heard.  It's either that, or devices have to process a lot
of different (and equivalent) error codes.

I was once using a SIP phone that would not properly play in-band
announcements.  It was several days later (when I used my mobile phone)
before I discovered why the phone just kept ringing and ringing.

I think it was important, as a first generation of IP-based VoIP protocols,
to provide this kind of PSTN interworking for transition purposes.  Once the
transition is made (or partially made), we can then remove some of those
"odd" things in the signaling and do it right.

I'm still unhappy with the fact that RFC 2833 is used to convey DTMF.  That
was a direct carry over of PSTN "user input" into the media stream!  How
unfortunate.  So, future-generation systems now have to deal with that.
(One should never mix signaling and media.)

So, we let the current systems limp along.  I've been a proponent for "doing
it over again" for a four years now.  Doing it over again means doing
exactly what you said: don't just re-invent the PSTN over IP.  That's what
current VoIP systems do, by and large.  That's also why SIP has not been a
wild market success, in spite of the fact that I implemented my first SIP
code in 1999!  That was ages ago!

> 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.

This is certainly believable.  I cannot recall the * codes to dial to
activate one feature or another and don't care to.

Fortunately, we have Skype to tie us all together with a nice little GUI :-)

Seriously, some renewed thinking on this problem is necessary.  SIP is not
the "emerging" technology any longer.  (OK, perhaps it is emerging, but it
emerges at a rate not unlike evolution of life on earth.)

Paul