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

[Carsten Bormann <cabo at tzi.org>]

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

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

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

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

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

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


_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc