[VOIPSEC] 4G Issue Map: signaling complexity

[Brian Rosen]

Paul

Re: Text vs Binary.

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.

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

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.

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.  

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.

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

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

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.

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.