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

[Carsten Bormann <cabo at tzi.org>]

> thank you for the information. However, I want to point
> out that if the statement about the multiplexing in 
> draft-ietf-rohc-sigcomp-sip-01
> is the final one- it will cause unnecessary changes in the 
> implementations
> already supporting multiplexing (and will break backwards 
> compatibility).
> That's why I think that multiplexing should be allowed without any
> extra 'uncompressed SigComp headers".

Paulius,

this is surprising.
RFC3320 is quite clear about the way a stream-based (TCP) connection 
works: messages are delimited by the record marking scheme (section 
4.2.2).

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.

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.

(An extension that would be compatible would be to allow uncompressed 
messages in the second and following records in the SigComp TCP record 
marking syntax.
[You can allow uncompressed messages in the first message only if you 
don't need to differentiate between SIP and SigComp connections.]
This is trivial to implement, but still an extension.  Again, I'd like 
to hear arguments why you need to save those 13 bytes.)

Gruesse, Carsten


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