Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t hesame TCP connection

From: [email-masked]
Date: Wed, 15 Dec 2004 12:24:54 +0200

hello,

inline:

>
> 
> The proposal that later came up to mix this SigComp framing with SIP 
> framing on one connection has received nearly unanimous rejection by 
> SIP implementers.
> We have discussed this on the mailing list for a long time 
> and, despite 
> some vocal support for this, in each round this was generally seen as 
> the wrong way to do this.

Yes, I know that I'm late with my comments but I just want
to clarify things.

> 
> SigComp shim headers are a standard-conforming way to multiplex 
> compressed and uncompressed messages on one SigComp TCP 
> connection that 
> is interoperable today.
> I'd like to hear a good reason why we need something else that is not 
> compatible with the SigComp architecture.

Why it is not compatible with SigComp architecture? I interpreted
RFC3320 in such a way that you mark only compressed messages with
SigComp delimeters. (chapter 4.2.2).
I'd say that TCP connection is for SIP and it just uses SigComp
for compression/decompression services and therefore SIP
does not need to add SigComp delimeter is case it must send
SIP message uncompressed.

IMHO the problem if implementations follow the architecture depicted 
in the Figure 1 in RFC3320- in this case the usage
of SigComp header for uncompressed message is intelligible
i.e. the "SigComp TCP connection" for keeping SigComp-layer generic.

danke,
	paulius

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Dec 2004 12:31:16 +0100

> SigComp delimeters. (chapter 4.2.2).

That's not what 4.2.2 says, it says:

    For a stream-based transport, the dispatcher delimits messages by
    parsing the compressed data stream for instances of 0xFF and taking
    the following actions:

Of course, the assumption at the time was that you would decide wether 
a data stream is compressed or not at the outset (either by just 
declaring it compressed, e.g., by using a separate port, or from the 
first byte of the TCP connection).

> SIP message uncompressed.

Again, that's not what it says.  When TCP (or any other stream 
protocol) is used, it is used for the "compressed data stream".
You have to apply 4.2.2 before you have messages.

The text in 3.1 is unfortunate in that it talks about "multiplexing 
messages" (we were mainly concerning ourselves with UDP at the time).
But even if you take it for face value, you need 4.2.2 before you have 
"messages" on a compressed stream.
(Taking it for face value would mean that the "extension" referred to 
in my previous message is already foreseen by RFC3320.
I don't think so, but I don't have a hard position on this, and I 
actually think it would be a good way to handle the problem, once I 
understand what the problem is.)

> i.e. the "SigComp TCP connection" for keeping SigComp-layer generic.

Figure 1 is pretty much an illustrative figure, it can't tell the whole 
picture.
4.2.2 clearly says it is the dispatcher that parses the data stream.

The main point in the architecture is that SigComp handles the 
transport interface.
It cannot do this if it has to apply both SIP message parsing rules and 
SigComp message parsing rules -- then the SIP implementation comes in 
in a way that implementors did *not* like.

So in summary:

1) Mixing SIP message parsing and SigComp record marking in one 
connection: bad.

2) Mixing uncompressed and compressed messages in a SigComp record 
marked stream: good, but not necessarily already required by the 
standard.

3) Mixing compressed and uncompressed messages in a SigComp record 
marked stream by sending the latter with a SigComp shim header: 
standard, interoperable now.

Gruesse, Carsten