[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages
Zhigang,
Both Richard and Adam have expressed a different opinion on this issue,
and I fail to see how this can be addressed in general, as it is about
possible application messages, and thus would be application dependent.
Anyway, submit a draft, that might enhance discussions.
BR
/L-E
> 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