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

[zhigang.c.liu@nokia.com]

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

Mark,

 

The problem I raised is how "to multiplex uncompressed application messages and SigComp messages on the same port" when application messages start with UTF-8 encoded text but contain binary data. For the problem itself, I don't assume where the demultiplexing is done (that goes to the solution space, see below). My point is that it needs to be done somewhere at the receiving endpoint (which by definition, is "one instance of an application, a SigComp layer, and a transport layer").

 

Now, the solutions:

 

- One is to let decompressor dispatcher do the demultiplexing (I won't repeat how it can be done), which means all bytes received on a port must go through SigComp layer first. This follows the SigComp architecture in RFC 3320. It makes the layering more clean, i.e., (de)compression and (de)multiplexing is handled completely by SigComp layer. The drawback is a bit redundancy in the sense that the decompressor dispatcher performs some parsing that the application layer will later do again.

 

- The other one is to let the application do the demultiplexing as you described below. That means all received data must go through application first.

 

In my view, either one will work and the choice is a local implementation issue (although the latter is not described in RFC 3320). The difference boils down to where do put the demultiplexing function. It's a matter of preference of SW coding. However, what is NOT an implementation issue is that - looking at transport layer - a receiving endpoint must expect it may receive uncompressed messages interspersed with SigComp messages on the same port and demultiplex them using either of the above approaches (or any other working solutions). This needs to be spelled out in a document.

 

BR,

Zhigang

 

-----Original Message-----
From: ext Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: April 03, 2003 8:24 AM
To: Liu Zhigang.C (NRC/Dallas); Sugar Robert (NET/Budapest)
Cc: rohc@ietf.org; sipping@ietf.org
Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages

Zhigang,

If I understand the solution described by Robert correctly, then the problem you describe below does not arise. Your problem seems to assume that demultiplexing of compressed and uncompressed messages will be done before the SIP parser is invoked, based on the 11111xxx delimiter.

My understanding is that messages are passed directly to the SIP parser. This software must be aware that SIGCOMP may be used, and checks the first octet of the input stream. If this is 11111xxx then it uses the sigcomp delimeter OxFFFF to find the end of the compressed message, and then sends it to the decompressor. If the first octets is not 11111xxx then it just starts parsing as normal.

The only assumption is that the SIP parser has its own way of recognising the end of an uncompressed message.

Regards...Mark

> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: 01 April 2003 14:44
> To: Robert.Sugar@nokia.com
> Cc: rohc@ietf.org; sipping@ietf.org
> Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP
> messages
>
>
> Robert,
>
> >  I don't think it is a problem with SigComp multiplexing, but
> > more like a SIP internal issue. What if there is a TCP stream
> > of SIP messages and the Content-Length header is missing or
> > false? They will screw up the same way with or without
> > SigComp.
>
> Since TCP is a reliable transport, this only happens for a
> mis-behaved SIP sender. But that is not the "multiplexing" problem
> I mentioned below, which happens even "during normal functioning"
> (see below).
>
> > During normal functioning both SIP and SigComp
> > provide their own flow separation mechanism and they work just fine.
>
> I don't think so. That is what I intended to show by the example,
> i.e. the issue to "multiplex uncompressed application messages and
> SigComp messages on the same port". One solution, as I mentioned
> before, is to require sigcomp receiver has the ability to parse
> uncompressed application messages and detect the end.
>
> (Of course, I saw Carsten's email and I need understand his
> point of view, which says there is no such "multiplexing" and
> it is not possible and necessary.)
>
> BR,
> Zhigang
> _______________________________________________
> 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
>