[VOIPSEC] 4G Issue Map: signaling complexity

[Paul E. Jones]

Henry,

I don't follow what you're saying.  I'm not reincarnating H.323 or H.248.
First, reincarnating would suggest they first died.  That's certainly not
the case with either, as they're both widely deployed in the market.

We just completed work on H.323v6 and at the ITU meeting next week, we have
some 70 documents or so related to enhancements to H.248.

In any case, I know you have some SIP boosting comment to make here, so I'll
go ahead and make mine ;-)

One of these days, SIP will work.  I'm working to try to make that happen.
I'm not sure how long before I pull out my hair with frustration, since it
seems that every vendor on the planet has a different interpretation of the
protocol.

Just recently, I was told that SIP now stands for the "Subject to
Interpretation Protocol".  In my experience, I think it's quite fitting.

Paul

> -----Original Message-----
> From: Henry Sinnreich [mailto:hsinnrei at adobe.com]
> Sent: Thursday, August 24, 2006 6:12 PM
> To: Paul E. Jones; Brian Rosen; bill at flanagan-consulting.com
> Cc: Geoff Devine; Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] 4G Issue Map: signaling complexity
> 
> Paul,
> 
> This reads like VoIP (revisionist) history.
> Good luck with the reincarnations of H.323 and H.248!
> 
> Henry
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Paul E. Jones
> Sent: Thursday, August 24, 2006 4:27 PM
> To: 'Brian Rosen'; bill at flanagan-consulting.com
> Cc: 'Geoff Devine'; Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] 4G Issue Map: signaling complexity
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>