[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



SIP has this header called content-length that tells how long the body of a sip message is regardless of its binary of UTF-8 contents.

The SIP parser will read the content-length value and then take that many octets from whatever follows the sip headers as body. If the body has binary with pattern 11111, the parser doesn't care and doesn't even look in the body.

Any protocol that wants to make use of sigcomp should fix its own problems.

Regards,
Hisham

> -----Original Message-----
> From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: Friday, March 28, 2003 3:50 AM
> 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