[VOIPSEC] 4G Issue Map: signaling complexity

[Paul E. Jones]

Brian,

> Re: Text vs Binary.

:-) These debates are fun.

> I was there.  I was the IETF editor for the first Megaco RFC.  The design
> was a compromise.  You can say, after the fact we could have done better,
> and no doubt that was true.  However, the text guys will tell you the same
> thing: if they could have ignored the binary guys, they could have done
> better.

I was there, too, though I stayed out of the drafting sessions.  I was
attending both the ITU and IETF meetings at the time, though I decided the
politics were too much.  Neither I nor my company had any financial interest
in the work, so I just observed the activity.  I think it was the Redbank
meeting that was the pivotal point where things went mostly toward text
encoding, but I can't recall so well now.

In any case, I suspect you are entirely right about the protocol design
being better if there were not compromises in both directions for text and
binary.

> The only think I have heard that MAY have some validity is that the binary
> guys should have pushed PER instead of BER.

Even PER would not have helped much the way H.248 is defined currently.
 
> I don't understand the compress SIP issue.   If you have a SIP device on a
> network with hundreds of kilobits or megabits or gigabits of bandwidth,
> then
> you can ignore compression; not worth it.  When you are on a device that
> has
> kilobits of signaling channel, then compression is a good idea.  SIP
> compresses well, without significant compute expense.  I don't think ASN.1
> would compress well.  I'm not sure I've actually seen anyone try, but many
> the normal compression tricks wouldn't work well except on the obvious
> repeated URI stuff, which is text always.

SIP compression apparently came about because people felt like they needed
to consume less bandwidth over wireless links.  Why that matters when you
then send a bunch of RTP packets out seems illogical to me, but I suppose
that's why I'm not making wireless handsets.  (I have my own opinions of 3G
wireless using VoIP, but I'll not go off in that direction now.)

ASN.1 PER is designed to be compact in the first place.  If it's just a few
bits, it consumes a few bits.  A number like 334594 occupies just a couple
of octets, etc.  Little space is not wasted with PER.  It's an encoding
designed for machines.  Where PER is weak is when it has to encode text.  If
the protocol is primarily text (e.g., full of e-mail IDs, hostnames, or
URIs), then those just get transmitted as they are: no real benefit.  In
such cases, you might as well use a text protocol.

> What we have discovered about text encoding is that they are much easier
> to
> get right IN THE BIG PICTURE.  They are much, much easier to debug.

Perhaps, but machines do not get debugged all the time.  Further, I have
never had any trouble personally debugging protocols written in ASN.1.  When
messages are decoded, you can print the contents on the screen.

Only 2 or 3 times in my life have I ever seen the binary decode operation
fail.  The reason is that people generally use well-tested commercial
compilers and libraries from companies like OSS.

> The usual claimed ASN.1 advantage beyond message size is the automatic
> syntax correctness.  My personal experience with that is that it's true on
> the wire, but not in the implementation.  It takes more time to get an
> interoperable implementation with ASN.1, because it takes more time to get
> through the edit/compile/test loop, and it takes longer to diagnose.  Once
> you have the implementation working (and I mean interoperable) the
> correct-by-construction syntax advantage goes away.  The thing that
> surprised me the most was watching bakeoffs (sorry Pillsbury).  ASN.1
> based
> bakeoffs are painful, text ones are much, much easier.  Total time clearly
> favors text in a bakeoff.  Syntax errors are easy to diagnose and fix.
> Semantic errors are much harder, and diagnosing them when you fumble with
> your decoding tools is hard.

My experience has been quite opposite.  I have written protocols in ASN.1,
compiled them, written the code to exchange messages on the wire, etc. in a
matter of hours.  I think it all depends on whether you have much experience
with the tools or not.  My guess is that if there were a lot of problems
with ASN.1, it was the result of somebody deciding to write their own PER
encoder/decoder library (that, in my opinion, is not so trivial) and getting
it wrong.

> Also, of course, we're a whole lot better with our ABNF parser tools now.

The problem I've seen with ABNF is that not everything gets specified and
there are open holes.  For example, a field might be defined as just a
string of characters of some sort with no real semantics or way to check
what is valid and what is not.

The SIP parsing code, for example, can get rather nasty and I've not seen
any good automated tools for it.

> > > 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.
> Thank you.  Couldn't have picked a better example.
> 
> The bell heads forced sip to implement early media, because they have a
> very
> broken billing system, that they insisted had to be copied.
> 
> Your problem was your phone did not play early media.

They might have a broken system, but it's what we have to interface with
during this time of transition.  So, what choice did we have?

Even very recently, I've had discussions on this topic of offers in INVITEs,
need to support PRACK, etc.  All of this stuff is really complicates the SIP
signaling significantly, but there's no way around it for the moment without
breaking interoperability with the PSTN.  I'm not a bell head, but I am of
the mind that we must make sure the network transitions smoothly.

With that said, I do with we would not use RFC 2833... wait, I've already
complained about that. :-)

> The sip mechanism is that the end device gives you your error; there are
> no
> announcements in audio form played by the far end.  What if you were
> calling
> someone with a text phone because you are deaf?  Your phone could text you
> the proper message, the far end can't.

Having both a text and audio message would be nice: that's certainly the
direction we should be taking for the future.  However, some of the status
codes today are, by and large, cryptic and not something we can present to a
user.  Place a call to a device and it sends back a "500" with some goofy
internal server error message is entirely useless to most users.

So, I agree with you, but I think audio messages and more descriptive text
is really better than terse error codes.  It should be more user-friendly.

> If you want media, complete the call.  That's because SIP is a session
> establishment protocol, and the media is the session.  If you want media,
> create a session.  That, in and of itself, is not the problem.  The
> problem
> is the BILLING.  They want the session to NOT be established, and yet they
> want (one way, if you please) media.
> 
> Early media is a very, very bad idea, and has caused untold grief and
> complication in SIP.

I agree with you.  But now we're stuck with it.  That and a bunch of other
crap that made SIP three times more complicated than it was intended to be.

With that said, though, recent protocol development work around SIP (e.g.,
"SIMPLE") unrelated to PSTN interworking is far from "simple".  Why is there
this continued desire to create such complexity?  Has the IETF desire to
creating simple protocols been thrown out the window?

Paul