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

From: [email-masked]
Date: Wed, 12 Mar 2003 10:25:44 -0600

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:[email-masked]]
> Sent: March 11, 2003 9:03 PM
> To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus
> (NRC/Helsinki); [email-masked]; [email-masked]
> Subject: RE: [Sipping] SIGCOMP and large binary content SIP messages
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > 
> > 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 13 Mar 2003 13:35:56 +0200

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

-- 
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 :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP