Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP

From: "Liu Zhigang.C (NRC/Dallas)" <[email-masked]>
Date: Wed, 26 Sep 2001 12:08:48 -0500

Hi,

I agree with Lawrence on the need of "out of band" negotiation.
Another reason is that the SigComp should be generic (i.e. not
only for SIP, also see notes below). During the negotiation, the 
two end systems can do the following:

1) Agree on whether to use compression

2) Agree on parameters. E.g. over which TCP or UDP port number
the payload should be compressed. What application-level protocol
is carried over that port number (SIP or something else). This
allows both end systems to setup the right static dictionary.
And perhaps other parameters related to the compression algorithm.

3) Pre-populate of the dictionary. This can boost the compression
ratio for the first several messages.

(Some of the ideas are described in SCRIBE,
http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-01.txt)

Note that although the negotiation procedure is out of SIP (again,
to be generic), it may be triggered by SIP as a service request. 
Also, the negotiation only needs to be done once if both endpoints 
agree to keep the negotiated results. However, the two endpoints 
should periodically verify they are still in sync (e.g. between 
sessions when traffic is relatively idle).

Re Markus' question about the requirement, the location of the peer
compression entities is not addressed (to make SigComp generic).
However, the need of negotiation is mentioned/implied in current
requirement draft (e.g. 3a - compatibility, 6 - Scalability).

BR,
Zhigang

> -----Original Message-----
> From: ext Lawrence Conroy [mailto:[email-masked]]
> Sent: September 26, 2001 10:52 AM
> To: Isomaki Markus (NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: [rohc] RE: [Simple] MESSAGE sessions - over TCP
> 
> 
> At 5:35 pm +0300 26/9/01, [email-masked] wrote:
> >Hi,
> >
> >>  However, SIP MESSAGE over TCP should be ok. Message overhead is an
> >>  issue only in wireless environment, but SIP compression (even
> >>  UDPcomp)
> >>  eliminates the overhead.
> >
> >If we have SIP MESSAGEs over TCP directly between UAs, is 
> SIP compression
> >applicable? Usually the compression is meant to be used 
> between a UA and the
> >(outbound) proxy, but is there anything hindering the 
> End-to-End case? I
> >suppose the UAs would have to agree to use compression in 
> SDP as part of the
> >transport description?
> >
> >Is this part of the signaling compression requirements?
> >
> >Rgs,
> >	Markus
> >
> Hi there,
>    my understanding was that: Initially, the end systems 
> agree "out of band"
> (e.g the SUAS listens on a particular port for compressed messages).
> This should work for TCP or UDP.
> 
> Don't believe that anyone has seriously suggested yet another 
> addition to
> SDP to indicate compressed SIP should be used (i.e. to negotiate).
> The goal is to compress even the initial SIP message; this 
> would not be
> possible if negotiation were carried in SDP (carried inside a 
> SIP message :).
> 
> BR,
>    Lawrence
> -- 
> [email-masked]: +44 1794 833666::<my opinions>:
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>

---

From: "Hans Hannu" <[email-masked]>
Date: Thu, 27 Sep 2001 17:10:28 +0200

Hi,

I agree that the negotiation whether to apply compression between two
parties or not should be taken care of before (in the case of SIP) the first
SIP INVITE messages. Thus, this can not be done by SigComp itself.

However, there might be a need to negotiate other parameters, e.g. The usage
of a Codebook/Byte-buffer, buffer memory etc., But, we have to think of the
complexity issue with too many parameters to set/negotiate, and also if
SigComp itself should do this kind of negotiation or if some other protocol
should do this, e.g. according to
http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiate-00.txt . My
belief is that SigComp should not have its own negotiation procedure.

> ratio for the first several messages.

Yes, this is true. And I believe that Jonathan had a good proposal for this:
http://www.cdt.luth.se/rohc/msg02593.html
"User specific and static dictionaries can all be supported by a single
decoder capability - the ability to set a codebook entry without
constructing decoder output. With this, the encoder could transfer the user
specific and static codebooks at init time of the session (presumably before
a call is made)."

Also how to decide to use a Codebook or a Byte-buffer is suggested by Jan
Christoffersson in:
http://www.cdt.luth.se/rohc/msg02686.html .

> to be generic), it may be triggered by SIP as a service request.

The scheme is still generic even though it uses e.g. SIP to negotiate its
usage. The same compression scheme can still be applied to e.g. RTSP. If we
define what has to be negotiated (if any) it should be up to the application
to make this happen.

> agree to keep the negotiated results.

Agree.

> However, the two endpoints

What should be verified? The settings of the compression scheme or its
dictionaries/Code-books.

> requirement draft (e.g. 3a - compatibility, 6 - Scalability).

Yes, negotiation is needed, but the question is how we do it.

BR
/Hans H