Subject: RE: [Sipping] compression problems

From: Eric Burger <[email-masked]>
Date: Wed, 5 Jan 2005 21:48:06 -0500

TLS lets you negotiate the algorithm.  LZS is already registered (RFC2943),
and it should be easy to register LZJH.  There are still 222 slots for
compression schemes available :)

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, December 30, 2004 11:38 PM
> To: Eric Burger
> Cc: Cullen Jennings; sipping
> Subject: Re: [Sipping] compression problems
> 
> 
> Eric Burger wrote:
> 
> >This is exactly WHY lemonade is currently favoring the TLS 
> w/ null cipher
> >(or, you can have your security, too :) approach.  We were 
> looking at a ton
> >of ugly application-layer compression schemes, until we 
> realized that we
> >could get the same or better results with TLS.
> >
> >It is not a panacea for lemonade for exactly the reason TLS 
> *is* a panacea
> >for SIP...
> >
> 
> Well, actually, it isn't. The place that compression is most 
> needed is 
> over wireless (i.e. cellular) data links. Unfortunately, the 
> terminals 
> involved aren't necessarily up to the task of running a compression 
> algorithm as heavy as deflate (which, IIRC, is the only one currently 
> registered for use with TLS). I've had real-world experience 
> with such 
> handsets running SIP. There are many much cheaper algorithms 
> (I'll cite 
> LZJH as an example -- compression takes about 1/6th the time 
> as deflate, 
> albeit with slightly larger messages as a result) that are perfectly 
> appropriate for such low-end terminals.
> 
> So, for the time being, the approach that makes the most sense is the 
> one that SigComp has taken: allow each implementation to 
> determine what 
> an appropriate level of complexity is for their operating environment.
> 
> /a
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP