Subject: General Compression { Was Re: JPEG in INVITE}

From: [email-masked]
Date: Fri, 24 Dec 1999 11:22:08 +0530

Hi,
one more question.
Is there a possible way in which an entire SIP Message can be compressed in
a standard way ?
something like say,
COMPRESSED SIP/2.0 ;algo=gzip
<compressed msg>

Where  the compressed  message is the entire sip message (not only the body
- which can be done by application/gzip)
The receiver can then extract the compressed message, gunzip it, and get
back the actual SIP message and then push it
to decode ?

But on the other hand, I guess this takes away the advantage of a text
based protocol but also provides the user a new
method which can be used to send compact messages _if_ he so wants.

Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

Jonathan Rosenberg <[email-masked]> on 12/24/99 04:09:26 AM

To:   archow
cc:   Taji Rachid <[email-masked]>, "'Alvir Alisic (ECS)'"
      <[email-masked]>, [email-masked]

Subject:  Re: JPEG in INVITE

[email-masked] wrote:
>
> Hi,
>  I have one question:
> This is not protocol related. but  I guess its more implementation
related,
> and is relevant for UDP only:
> As it is, when a SIP message is received, the reciever does not know the
> size of the received message and hence I guess must allocate some fixed
> space for it before doing the n/w read as allocating 64k for a message
may
> not always be desirable.
>
> However, a typical _single_ sip message takes approx < 500 bytes.
However,
> if we allow JPEGS/(bitmaps - oops)  inside, the size of the message body
> can widely fluctuate.
>
> Then the only way for a person who really does not want to allocate 64k
is
> to read from the n/w till he gets a content-length, figure out
> the size and then read the rest of the body. this is kludgy at best.

SIP has a response code that is "message body too large". If you wish to
impose restrictions in your implementation, you can just read enough
bytes to get the header. This will tell you the size of the body. If
thats too much for your tastes, reject the message.

I agree that since SIP is not meant as a transfer protocol, including
lots of data in UDP can be bad for small implementations. There is
another issue, which is UDP message fragmentation at the IP layer.
Fragmentation causes an amplication effect in the loss probabilities, so
that a small loss probability can result in significant packet loss
(this is only true for independent packet losses; its not as bad for
highly correlated packet loss). Using lots of data in UDP will cause the
messages to be fragmented.

-Jonathan R.

--
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Dec 1999 10:27:23 -0500

I would advise against compression of this form at the SIP layer. The
headers must be readable by proxies.

You can compress the body itself. SIP supports the Content-Encoding
headers which allow you to apply transformations to the body, like gzip.
Accept-Encoding allows these encodings to be negotiated between UAC and
UAS.

Another approach is to compress the entire SIP message at the IP layer,
on a hop by hop basis. Check out rfc2393 which specifies a payload
compression mechanism for IP.

-Jonathan R.

---

From: [email-masked] (Henning Schulzrinne)
Date: Sun, 26 Dec 1999 11:59:39 +0100

To amplify: compression at the application layer may simply interfere
with compression in a lower layer for those links where it matters.
Thus, there may be no net gain at all, besides interfering with proxies,
transparent proxies and the like. (As far as I know, most PPP
implementations compress when possible, with methods tuned for text.
Obviously, this argument doesn't hold for lossy compression candidates
like audio or video.)

Also, application-layer compression for small UDP packets is probably
only modestly effective overall, due to the packet header overhead.