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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2001 18:18:58 -0400

> -----Original Message-----
> From: Michel de Boer [mailto:[email-masked]]
> Sent: Thursday, July 19, 2001 3:54 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [Sip] New I-D on compression of SIP
> 
> 
> 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? 

Simpler, perhaps not (although if you're using PER or BER, its not clear to
me that this is simpler, codewise). But, it totally breaks compatibility
with the existing protocol. By pushing this into a transport problem, it is
isolated to the two entities that need to worry about it.

> In my opinion this approach is more prone to 
> interoperability
> issues.

Thats not clear at all. Either way, we would require new code in
implementations. For a new binary coding, we would be back to square 1, so
that everyone would have to work out the kinks in their encoder/decoders for
every element in the syntax. However, with a shim, we leverage existing,
mature parsers and generators. We add a layer that is not specific to SIP,
so it has no syntax or anything else to get wrong. Its defined by a fairly
simple set of state machines, which should not be that hard to get correct.
I would argue its easier to get that right than it is to get a totally new
encoding of SIP right.

> Codebooks can get out of sync. 

Yes, and that does need to be handled in the protocol.

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

Well, the problem at hand is really a wireless phone talking to its local
outbound proxy. THus, the phone has only one relationship, and the proxy has
one with each phone it communicates with. This pushes the burden of
compression to the elements that benefit the most from it. From this point
onwards, normal SIP would be used, and so its compatible with existing
proxies and UAs.

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

The output of the decompressor would need to be monitored.

-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: Christer Holmberg <[email-masked]>
Date: Wed, 25 Jul 2001 17:25:46 +0300

Hi,

A few comments from me.

First, my personal opinion about the binary talk: let's skip the binary
talk. If we start talking about it, we will argue about it for at least
6 months (I think the people who have been involved in the MEGACO work
know what I'm talking about...) Then, IF we would decide to also go
binary, experience (read: MEGACO) has shown that it's not that easy to
define text- and binary rules that "match" 100%. Ok, SIP would probably
be a little easier than Megaco, since we don't have wildcard values etc,
but still. Then we would also have the encoding negotiation problem, and
the issue about which nodes MUST/SHALL/SHOULD support what... And, which
has been mentioned also by others, that we really don't transport that
much information in SIP, so would the gain (not very much, I'd say) be
worth the pain (very much, I'd say)?

Compression is more "flexible". For most networks/architectures I don't
think it will provide very much, but if peope want to use it they are
free to do so - but it would not affect the core protocol.

Then, if we assume that we need compression, we have the other
questions, which I think are more important to discuss:

1. Hop-to-hop vs end-to-end

2. Do we compress the whole message, or only parts of it (the message
body, for example)

3. Compression negotiation

   a) Do we use an external negotiation mechanism, and negotiate before
we start the SIP session. Since the             proxies in many cases
also must be involved in this negotiation we would probably need some
kind of 
      "centralized" function for this.

   b) Do we send the initial INVITE uncompressed (or partly compressed)
with a Supported/Require/Proxy-Require   
      header listing the supported compression algorithms. And again, if
the proxies must support the             compression, there must be a
way for them to indicate it (can be done for example either by
using             Proxy-Require, or some Record-Route parameter)

   c) Do we use "manual" configuration, either by hand or by using some
of the SIP extensions that have been       defined for remote
configuration.

My thoughts...

Regards,

Christer Holmberg
Ericsson Finland