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

From: [email-masked]
Date: Thu, 20 May 2004 12:34:24 -0400

Hello,

The discussions on this topic have been idle for a while (I myself
have been busy with other things). Let's see if we can progress to a 
conclusion. 

Below summarizes a few key points in my mind. Comments are welcome.

With the "SigComp encapsulation with NULL compression" (I coded this
term for convenience) described by Carsten and Mark, loss of state
synchronization can be handled already without multiplexing. So, to
me this doesn't look a strong argument for multiplexing.

The multiplexing seems to be needed in the following case:
- An endpoint A starts SIP message exchange with another endpoint B 
over a TCP connection. Since A does not know if B supports SigComp, 
it sends "plain" (i.e. non-SigComp) SIP messages.
- B indicates its support of SigComp following RFC 3486.
- If multiplexing is supported, A can start sending SigComp messages
on the same TCP connection right away. Without multiplexing, A has
to open a new TCP connection, which means extra delay due to 3-way
TCP handshake and probably delay due to IPsec as well.

Another argument that has been raised to have multiplexing is
the 64KB size limit on SigComp messages. However, the counter argument
could be that a large SIP message can be encapsulated into multiple
SigComp messages, each of which is smaller than 64KB. RFC 3320 does
not specify 1:1 mapping from SIP message to SigComp message for
stream based transport. So, this should be possible. However, the 
fragmentation might have security implications. I.e., under the 
security assumption in RFC 3320, can the SIP receiver authenticate 
fragments of a SIP message?

BR,
Zhigang

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