[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages
Hi Carsten and Lars-Erik,
I've volunteered to submit a personal draft on this issue. From
ROHC WG chairs' point of view, do you think this is the way to proceed?
Of course, I understood during the IETF56 that Carsten had some
doubts on whether this is indeed an issue. My email below explained
the issue a bit. I don't know if it's clear. Either way, we can continue
discuss this in ROHC mailing list
http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg04115.html
BR,
Zhigang
> -----Original Message-----
> From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: March 13, 2003 9:55 AM
> To: Gonzalo.Camarillo@lmf.ericsson.se
> Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki);
> mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org
> Subject: [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
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc