[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages
I agree. How to handling binary content is a generic issue for any
application messages. What I have in mind is to give generic
descriptions/requirements (mainly on the SigComp receiver parsing part),
then touch on SIP (perhaps RTSP too) as a particular example.
Unless someone objects, I'll submit it in ROHC.
Zhigang
> -----Original Message-----
> From: ext Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: March 13, 2003 5:36 AM
> To: Liu Zhigang.C (NRC/Dallas)
> Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki);
> mwatson@nortelnetworks.com; sipping@ietf.org
> Subject: Re: [Sipping] SIGCOMP and large binary content SIP messages
>
>
> Zhigang,
>
> you can submit that draft to ROHC. SIPPING can review it afterwards.
> IMO, the competence needed to generate this draft can be found more
> easily in ROHC than in SIPPING.
>
> Besides, you could use SigComp to compress RTSP messages, for instance
> And RTSP is not handle by SIPPING either.
>
> Gonzalo
>
> zhigang.c.liu@nokia.com wrote:
> >
> > Yes, that is also what I had in mind for SIP. But my point is that
> > a SigComp receiver now needs to have some knowledge about
> application
> > message format and do parsing to determine the end of an
> uncompressed
> > message. This is something new (or at least unspecified) in RFC 3320
> > and needs to be spelled out in a new (standard track) RFC.
> The document
> > will be short, but I think it's needed for interoperability.
> >
> > I'll write up an I-D and submit it after IETF 56. But I'd
> like to know
> > if folks in SIPPING think it should be done here or in ROHC.
> >
> > Zhigang
> >
> > > -----Original Message-----
> > > From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> > > Sent: March 11, 2003 9:03 PM
> > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus
> > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org
> > > Subject: RE: [Sipping] SIGCOMP and large binary content
> SIP messages
> > >
> > >
> > > > -----Original Message-----
> > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > > >
> > > > Having binary content in SIP messages may have two impacts on
> > > > SigComp:
> > > >
> > > > a) multiplexing of uncompressed messages with SigComp
> > > messages on the
> > > > same port.
> > > ...
> > > > For a), it is only an issue for SigComp/TCP, not
> > > SigComp/UDP (where one
> > > > SigComp message maps to one UDP packet). Adam's point 1 and
> > > 2 are related
> > > > to this. As to point 1, I think the SigComp receiver still
> > > needs to know
> > > > (somehow) the end of an uncompressed message, or at least
> > > the end of the
> > > > binary part of each SIP messages. Otherwise, a bit
> pattern 11111 in
> > > > the binary part will be mistaken by SigComp as the
> > > beginning of a SigComp
> > > > message. As to point 2, I would add that the delimiter
> > > 0xFFFF can appear
> > > > at the both the beginning and the end of a SigComp
> message. So, the
> > > > receiver needs to have the same parsing logic just
> mentioned for bit
> > > pattern
> > > > 11111.
> > >
> > > This isn't any more of an issue than it is without SigComp. SIP
> > > messages provide their own framing, and SigComp messages do the
> > > same. They can be trivially mixed on the same stream:
> > >
> > > 1. Peek at the first byte waiting in the stream.
> > >
> > > 2. If it is 0xf8 or higher, the next message in the stream is
> > > a SigComp message. The message continues until a 0xFFFF is
> > > encountered in the stream.
> > >
> > > 3. Otherwise, the next message in the stream is a SIP message.
> > > Read the stream until a CR/LF/CR/LF is encountered. Parse
> > > the headers, and then read the number of bytes specified
> > > in the "Content-Length" header.
> > >
> > > 4. Return to step 1.
> > >
> > > /a
> > >
> > _______________________________________________
> > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
>
> --
> Gonzalo Camarillo Phone : +358 9 299 33 71
> Oy L M Ericsson Ab Mobile: +358 40 702 35 35
> Telecom R&D Fax : +358 9 299 30 52
> FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com
> Finland http://www.hut.fi/~gonzalo
>
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc