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

[Paulius.Meskauskas at nokia.com]

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
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc