Subject: [Sip] New I-D on compression of SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2001 16:08:43 -0400

Folks,

I've just submitted a new I-D on compression of SIP messages, particularly
for wireless links. Until the draft appears in the archives, you can pick up
a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-rohc-sip-udpcomp-00.txt

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Michel de Boer <[email-masked]>
Date: Thu, 19 Jul 2001 09:54:12 +0200

Jonathan,

You state that one of the ways to achieve message size reduction is to
define a binary encoding, but that this introduces interoperability
problems.

How can a compression scheme based on dynamically constructed codebooks
be simpler? In my opinion this approach is more prone to interoperability
issues.
Codebooks can get out of sync. As codebooks are specific to a sender-
receiver pair, an entity communicating with multiple other entities, i.e.
a proxy talking to many UA's must manage multiple codebooks.

For trouble shooting one might want to monitor a network interface and
analyze SIP messages coming in. It's impossible to read a compressed
message.

Regards,
Michel

---

From: Michael Thomas <[email-masked]>
Date: Sat, 21 Jul 2001 09:17:41 -0700 (PDT)

Jonathan,

To follow up on my passing comments, it should be
noted that IPsec already has compression
transforms which work in combination with
encryption/message integrity. I'm not sure if TLS
has this capability, but I wouldn't be surprised
(nor do I think it would be hard to add if
not). Thus, there's at least some amount of wheel
reinvention going on here.

That said, it may be interesting to consider
taking the same tack as IPsec compression for SIP
security which has the same problem as all
encryption/compression schemes which is that you
must compress before encrypting to do anything
useful. Thus, it would be natural for secure SIP
headers and bodies (attachments, as I propose) to
allow compression transforms as well.

The synergy between our two drafts, I think, may
lie in something that I've been toying with: the
ability to have a complete SIP application layer
security scheme which not only deals with the
problem which is clearly in the SIP domain (crypto
for parts of the SIP payload), but could also be
used to provide hop-by-hop
encryption/authentication as well negating the
need to require a base level secure transport
mechanism (eg, IPsec, TLS).  I think this is
possible by extending my current proposal to
insert a shim layer much like you propose in this
draft here. I haven't included this in the current
draft (mostly because it's not a baked idea), but
it would make sense to my mind that if we allow
compression, we ought to fold it into the security
framework mainly because of the compress-then-encrypt
problem.

		Mike