RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages

[Robert.Sugar@nokia.com]

Hi Zhigang,

 I don't think it is a problem with SigComp multiplexing, but more like a SIP internal issue. What if there is a TCP stream of SIP messages and the Content-Length header is missing or false? They will screw up the same way with or without SigComp. During normal functioning both SIP and SigComp provide their own flow separation mechanism and they work just fine.
 As for other applications the requirement is that the messages must not start with 11111xxx and the end of the messages must be detected. If that is assured binary content is not a problem anymore. Besides, whatever pattern you choose to distinguish SigComp it might appear in application messages <evil> for example if we attach a Sigcomp message as application/octet stream </evil>. Only the possibility for screwing up will be lower.

Best Regards,
Robert

> -----Original Message-----
> From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: March 28,2003 2:50
> To: Lars-Erik.Jonsson@epl.ericsson.se
> Cc: rohc@ietf.org; sipping@ietf.org
> Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP
> messages
> 
> 
> Lars-Erik,
> 
> IMO, binary content in application message is a general issue for
> SigComp multiplexing. It's not specific to SIP. I already explained 
> this in rohc and sipping mailing list. But here is a simple example. 
> 
> Let's say endpoint A already knows endpoint B supports SigComp on TCP 
> port number 5000. A sends, on port 5000, uncompressed message 
> 1 followed 
> by message 2 compressed using SigComp. From RFC 3320, message 2 starts
> with bit pattern 11111. So, if message 1 has no binary 
> content, endpoint
> B can easily detect the beginning of message 2 (i.e. end of message 1)
> by detecting 11111. However, if message 1 contains binary content,
> that means the (uncompressed) binary part may contain byte 11111xxx.
> This "mimicking" will make endpoint B mistakenly think a new SigComp
> message starts at that byte. Obviously, things will be messed up
> from that point.
> 
> This is what I referred to as the multiplexing issue. I hope 
> I explained
> it better this time for you. 
> 
> Anyway, I'll submit a personal draft to help the discussion, 
> although the 
> above example should make it obvious already.
> 
> Zhigang
> 
> 
> > -----Original Message-----
> > From: ext Lars-Erik Jonsson (EAB)
> > [mailto:Lars-Erik.Jonsson@epl.ericsson.se]
> > Sent: March 27, 2003 2:18 AM
> > To: Liu Zhigang.C (NRC/Dallas)
> > Cc: rohc@ietf.org
> > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary 
> content SIP
> > messages
> > 
> > 
> > Zhigang,
> > 
> > > My question is the handling of binary content in application 
> > > messages. In my view, this is a generic issue although it started
> > > with SIP. My thought was to have a *separate* document that
> > > addresses this issue (and perhaps other generic SigComp "bugs" if
> > > we find out).
> > 
> > First of all, it is not yet clear to me that this is a 
> general issue,
> > at least I have not been able to see consensus on that. Secondly, if
> > we have general unclear issues with SigComp, those would go into the
> > Implementer's guide at this point.
> > 
> > Currently, I therefore think we can and should avoid having 
> even more
> > documents.  However, you can always provide input by 
> writing a draft,
> > that is up to you.
> > 
> > Regarding the SigComp&SIP document, it does not matter much
> > in which WG it is "hosted", as long as it is written and well 
> > reviewed 
> > by people from both sides.
> > 
> > 
> > Rgds,
> > /L-E 
> > _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> > 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc